RFC 3125
Electronic Signature Policies
RFC 3125: Electronic Signature Policies 🎀
Okay bestie, this is RFC 3125 and it's giving Experimental energy 🧪✨. It's from the Network Working Group, dated September 2001, and the authors are J. Ross (Security & Standards), D. Pinkas (Integris), and N. Pope (Security & Standards). The category is Experimental, and the header doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC. 💅
Status of this Memo 📜
This memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind, so don't treat it like one 🙈. Discussion and suggestions for improvement are requested, so send your feedback! Distribution of this memo is unlimited 🌈.
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract 🦋
Okay so this document is all about signature policies for electronic signatures 🔏. A signature policy is basically a rulebook for how an electronic signature gets created and validated, and it's the rulebook that decides whether the signature counts as valid at all 💖. A legal or contractual setting can look at a specific signature policy and say "yep, that meets what we need" 👑.
Every signature policy gets a globally unique reference, and the signer binds that reference to the electronic signature as part of the signature calculation 🔗. It's giving permanent receipt 🧾.
The policy also needs to be readable by humans, so people can check whether it fits the legal and contractual context it's being used in 🧐. Then, for the computers, another part of the policy spells out the electronic rules for creating and validating the signature in a form software can process 🤖. In this document, that machine-readable format is defined using ASN.1 🧩.
Fun fact, the contents here are based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C) 🌸. You can download individual copies of that ETSI deliverable from http://www.etsi.org 🌐.
Table of Contents 🗂️
1. Introduction 3
2. Major Parties 3
3. Signature Policy Specification 5
3.1 Overall ASN.1 Structure 5
3.2 Signature Validation Policy 6
3.3 Common Rules 7
3.4 Commitment Rules 8
3.5 Signer and Verifier Rules 9
3.5.1 Signer Rules 9
3.5.2 Verifier Rules 11
3.6 Certificate and Revocation Requirements 11
3.6.1 Certificate Requirements 11
3.6.2 Revocation Requirements 13
3.7 Signing Certificate Trust Conditions 14
3.8 Time-Stamp Trust Conditions 15
3.9 Attribute Trust Conditions 16
3.10 Algorithm Constraints 17
3.11 Signature Policy Extensions 18
4. Security Considerations 18
4.1 Protection of Private Key 18
4.2 Choice of Algorithms 18
5. Conformance Requirements 19
6. References 19
7. Authors' Addresses 20
Annex A (normative): 21
A.1 Definitions Using X.208 (1988) ASN.1 Syntax 21
A.2 Definitions Using X.680 (1997) ASN.1 Syntax 27
Annex B (informative): 34
B.1 Signature Policy and Signature Validation Policy 34
B.2 Identification of Signature Policy 36
B.3 General Signature Policy Information 36
B.4 Recognized Commitment Types 37
B.5 Rules for Use of Certification Authorities 37
B.5.1 Trust Points 38
B.5.2 Certification Path 38
B.6 Revocation Rules 39
B.7 Rules for the Use of Roles 39
B.7.1 Attribute Values 39
B.7.2 Trust Points for Certified Attributes 40
B.7.3 Certification Path for Certified Attributes 40
B.8 Rules for the Use of Time-Stamping and Timing 40
B.8.1 Trust Points and Certificate Paths 41
B.8.2 Time-Stamping Authority Names 41
B.8.3 Timing Constraints - Caution Period 41
B.8.4 Timing Constraints - Time-Stamp Delay 41
B.9 Rules for Verification Data to be followed 41
B.10 Rules for Algorithm Constraints and Key Lengths 42
B.11 Other Signature Policy Rules 42
B.12 Signature Policy Protection 42
Full Copyright Statement 441. Introduction ✨
Okay so this doc is meant to cover signature policies that can be used with electronic signatures for all sorts of transactions 💼. Think business stuff like purchase requisitions, contracts, and invoices 🧾. Electronic signatures can show up in basically any transaction, whether it's between you and a company, between two companies, or between you and a government body 🏛️.
It's also totally independent of any environment 🌍. It works with smart cards, GSM SIM cards, special electronic-signature programs, and more, so it's giving flexible 🦋.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119] 📖. Those capitals are the special ones, so keep an eye out for them 👀.
2. Major Parties 👥
The document uses these terms, so let's meet the cast 🎭:
- the Signature Policy Issuer;
- the Signer;
- the Verifier;
- the Arbitrator;
- Trusted Service Providers (TSP);
The Signature Policy Issuer is a Trusted Service Provider (TSP) that issues signature policies. These policies lay out the technical and procedural requirements for creating an electronic signature and for validating/verifying it, all to meet a particular business need 💅.
The Signer is the entity that creates the electronic signature 🖊️. When the signer digitally signs over a signature policy identifier, that's a commitment on behalf of the signing entity that the data being signed was signed under the rules in the signature policy. Big commitment energy 💍.
The Verifier is the entity that validates the electronic signature. It could be one entity or several 🫂. The verifier MUST validate the electronic signature under the rules defined by the electronic signature policy for the signature to be valid ✅. No skipping steps, periodt 💀.
An Arbitrator is an entity that settles disputes between a signer and a verifier ⚖️. It acts as a verifier when it checks the electronic signature after it's already been validated once 🔍.
Trusted Service Providers (TSPs) are one or more entities that help build trust between the signer and the verifier 🤝. Use of TSP-specific services MAY be mandated by the signature policy 🧾. TSP supporting services include user certificates, cross-certificates, time-stamping tokens, CRLs, ARLs, and OCSP responses 🌟.
A Trusted Service Provider (TSP) MAY be a Signature Policy Issuer. As such, the TSP MUST define the technical and procedural requirements for electronic signature creation and validation, in order to meet a particular business need 🎯.
These other TSPs are used to support the functions defined in this document 🌸:
- Certification Authorities;
- Registration Authorities;
- Repository Authorities (e.g., a Directory);
- Time-Stamping Authorities;
- One-line Certificate Status Protocol responders;
- Attribute Authorities.
Certification Authorities hand users their public key certificates 🔑. Registration Authorities let entities register before a CA generates certificates 📝.
Repository Authorities publish CRLs issued by CAs, cross-certificates (i.e., CA certificates) issued by CAs, signature policies issued by Signature Policy Issuers, and optionally public key certificates (i.e., leaf certificates) issued by CAs 📚.
Time-Stamping Authorities attest that some data was formed before a given trusted time ⏰.
One-line Certificate Status Protocol responders (OSCP responders) tell you the status of a particular certificate: revoked, not revoked, or unknown 🚦.
Attribute Authorities give users attributes linked to public key certificates 🏷️.
And finally, an Arbitrator is an entity that arbitrates disputes between a signer and a verifier 👑.
3. Signature Policy Specification 📋
A signature policy specification includes general information about the policy, the validation policy rules, and other signature policy info 🗒️.
This document mandates that:
- an electronic signature must be processed by the signer and verifier in accordance with the signature policy referenced by the signer;
- the signature policy referenced by the signer must be identifiable by an Object Identifier;
- there must exist a specification of the signature policy;
- for a given signature policy there must be one definitive form of the specification which has a unique binary encoding;
- a hash of the definitive specification, using an agreed algorithm, must be provided by the signer and checked by the verifier.
Lowkey, the document doesn't mandate what form the signature policy specification takes 🤷♀️. The signature policy may be specified either:
- in a free form document for human interpretation; or
- in a structured form using an agreed syntax and encoding.
This document does define an ASN.1 based syntax that may be used to define a structured signature policy 🧩. Future versions of this document may include a structured signature policy specification using XML 🔮.
3.1 Overall ASN.1 Structure 🏗️
This section gives the overall structure of a signature policy defined using ASN.1. Use of this ASN.1 structure is optional 💖.
This ASN.1 syntax is encoded using the Distinguished Encoding Rules (DER) 🧁.
In this structure, the policy information comes after an identifier for the hashing algorithm used to protect the signature policy, and it's followed by the hash value. That hash value must be re-calculated and checked whenever the signature policy is passed between the issuer and the signer/verifier 🔁.
The hash is calculated without the outer type and length fields 🙈.
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRINGThat's the end of part 1! 🌈🎀
SignPolInfo ::= SEQUENCE {Okay wait, I need to fix that opener. The block should pick up exactly where the last part stopped, so here's the real continuation:
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryStringHere's the vibe check on that struct 💅✨ policyIssuerName is the bestie who tells you who made the policy, using one or more of the general name forms 🎀. fieldofApplication is the little blurb about what the policy is actually for 🌸. Then signatureValidationPolicy is the rulebook that's fully processable 🔥, so you can validate signatures issued under that policy. Lowkey the whole point of this section 💜. And signPolExtensions is the generic escape hatch 🦋, a way to extend any sub-component of a signature policy. Iconic extensibility, no cap.
3.2. Signature Validation Policy
Okay so the signature validation policy is where it gets spicy 🌶️💖. It tells the signer which data elements have to show up in the electronic signature they produce, and it tells the verifier which data elements have to be there under that policy for a signature to count as potentially valid. Main character energy for the rules 👑.
The structure looks like this:
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}The signingPeriod is giving time window 🧚. It says the date and time before which the signature policy SHOULD NOT be used for creating signatures, plus an optional date after which it should not be used for creating signatures either. So there's a start and maybe an end 🕰️💀.
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }3.3. Common Rules
The CommonRules are the rules that apply to all commitment types 🌈. They're written in terms of trust conditions for certificates, time-stamps and attributes, plus any constraints on attributes that might be included in the electronic signature. Very "one rule to rule them all" ✨.
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}Here's the no-doubles rule 🙈: if a field is present in CommonRules, the equivalent field must not be present in any of the CommitmentRules. And if any of the following fields are not present in CommonRules, then each CommitmentRule must have it:
signerAndVeriferRules;signingCertTrustCondition;timeStampTrustCondition.
3.4. Commitment Rules
The CommitmentRules are the validation rules that apply to given commitment types 💅. They're a list:
CommitmentRules ::= SEQUENCE OF CommitmentRuleEach CommitmentRule for a given commitment type is defined in terms of trust conditions for certificates, time-stamps and attributes, along with any constraints on attributes that may show up in the electronic signature 🎀.
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }So if the SelectedCommitmentTypes says "empty", this rule applies when a commitment type is not present, meaning the type of commitment is indicated in the semantics of the message 🧠. Otherwise, the electronic signature must contain a commitment type indication, and it has to fit one of the commitment types mentioned in CommitmentType 💖.
One identifier, one home 🏡: a specific commitment type identifier must not appear in more than one commitment rule.
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }The fieldOfApplication and semantics fields are where the specific use and meaning of the commitment gets defined, inside the overall field of application set for the policy 🦋.
3.5. Signer and Verifier Rules
These rules apply to the format of electronic signatures defined using [ES-FORMATS] 🌸.
The SignerAndVerifierRules is made of a signer rule and verification rules, as shown below:
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }3.5.1. Signer Rules
The signer rules identify:
- if the eContent is empty and the signature is calculated using a hash of signed data external to CMS structure.
- the CMS signed attributes that must be provided by the signer under this policy;
- the CMS unsigned attribute that must be provided by the signer under this policy;
- whether the certificate identifiers from the full certification path up to the trust point must be provided by the signer in the SigningCertificate attribute;
- whether a signer's certificate, or all certificates in the certification path to the trust point must be by the signer in the certificates field of SignedData.
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- Not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
CMSattrs ::= SEQUENCE OF OBJECT IDENTIFIERThe mandatedSignedAttr field must include the object identifier for all the signed attributes required by this document, plus any additional attributes required by this policy 🎀.
The mandatedUnsignedAttr field must include the object identifier for all the unsigned attributes required by this document, plus any additional attributes required by this policy. For example, if a signature time-stamp <see section 1.1) is required by the signer, the object identifier for this attribute must be included 🧚.
The mandatedCertificateRef identifies whether just the signer's certificate, or the full certificate path, must be provided by the signer 🔥.
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullpath (2)
-- References for full cert path up to a trust point required
}The mandatedCertificateInfo field identifies whether a signer's certificate, or all certificates in the certification path to the trust point, must be provided by the signer in the certificates field of SignedData 💖.
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory requirements
signerOnly (1) ,
-- Only reference to signer cert mandated
fullpath (2)
-- References for full cert path up to a
-- trust point mandated
}3.5.2. Verifier Rules
The verifier rules identify:
- The CMS unsigned attributes that must be present under this policy and must be added by the verifier if not added by the signer.
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed3.6. Certificate and Revocation Requirement
The SigningCertTrustCondition, TimestampTrustCondition and AttributeTrustCondition (defined in the subsequent sub-sections) make use of two ASN.1 structures, which are defined below: CertificateTrustTrees and CertRevReq 🌈✨.
3.6.1. Certificate Requirements
The certificateTrustTrees identifies a set of self signed certificates for the trust points used to start (or end) certificate path processing, and the initial conditions for certificate path validation, as defined RFC 2459 [7] section 4 🎀. This ASN.1 structure is used to define policy for validating the signing certificate, the TSA's certificate and attribute certificates 💜.
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPointokay so this is where the trust point gets its whole personality 💅🎀
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }ok the trustPoint field is the self-signed cert for the CA that starts off certificate path processing 🌸 it's the main character of the whole chain fr
the pathLenConstraint field tells you how many CA certs are allowed to sit in a cert path after the trustpoint 🧚 if it's zero, only the trustpoint cert and an end-entity cert can be used, which is giving very strict bestie energy 💀 if it's there, it has to be zero or bigger. if it's not there, the path can be as long as it wants ✨
PathLenConstraint ::= INTEGER (0..MAX)the acceptablePolicySet field lists the starting set of certificate policies. any one of them is good enough under the signature policy 🦋
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIERthe nameConstraints field sets up a namespace where every subject name in the later certs of the path has to live 🏡 it can limit the subject distinguished name or the subject alternative names. the limits only kick in when that name form is actually in the cert. if there's no name of that type, the cert is totally fine 🙌
restrictions are built out of permitted and excluded name subtrees. and here's the drama: any name that matches something in excludedSubtrees is invalid no matter what permittedSubtrees says 😭 excluded always wins, periodt
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)the policyConstraints extension is a two-way boss 👑 it can stop policy mapping, or it can demand that every cert in the path has an acceptable policy identifier. if the policyConstraints field is there, it says you need explicit policy indication, and/or limits on policy mapping, iykyk 🫶
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)so the inhibitPolicyMapping number counts how many more certs can show up in the path (the trustpoint's self cert counts too 🙈) before policy mapping is shut down. say it's one: mapping can happen in certs issued by the subject of this cert, but not in any extra certs after that 🍓
and requireExplicitPolicy says the certs after this point have to include an acceptable policy identifier 🎀 its number is how many more certs (again, trustpoint self cert included) can show up before explicit policy becomes mandatory. an acceptable policy identifier is either one the path's user actually asked for, or one that got declared equivalent through policy mapping 💜
3.6.2. Revocation Requirements
okay now we're talking revocation, the whole "is this cert still legit??" question 🕵️♀️ the RevocRequirements field sets the minimum requirements for revocation info, from CRLs and/or OCSP responses, that you use to check whether a cert has been revoked. this ASN.1 structure defines the policy for validating the signing cert, the TSA's cert, and attribute certs 🦋
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}certificate revocation requirements are set by the checks required on two things 👀
- endCertRevReq: the end certs (so the signer's cert, the attribute cert, or the time-stamping authority cert) 🎀
- caCerts: the CA certs 🏛️
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}an authority certificate is a cert issued to an authority, like a certification authority or an attribute authority (AA) 🧚
a Time-Stamping Authority (TSA) is a trusted third party that makes time-stamp tokens to show that some data existed at a particular point in time. see [TSP] 🕰️✨
EnuRevReq ::= ENUMERATED {
clrCheck (0),
--Checks must be made against current CRLs
-- (or authority revocation lists (ARL))
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol
-- (OCSP),RFC 2450.
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be
-- carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy
-- extension
}the revocation requirements are described with these options 🌈
- clrCheck: checks must be made against current CRLs (or authority revocation lists) 📜
- ocspCheck: the revocation status must be checked using the Online Certificate Status Protocol (RFC 2450) 🔎
- bothCheck: both OCSP and CRL checks must be carried out 👯
- eitherCheck: either OCSP or CRL checks must be carried out 🤷♀️
- noCheck: no check is mandated 😌
3.7. Signing Certificate Trust Conditions
the SigningCertTrustCondition field says what trust conditions apply to cert path processing when validating the signing cert 💖
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}3.8. Time-Stamp Trust Conditions
the TimeStampTrustCondition field says what trust conditions apply to cert path processing when authenticating the time-stamping authority, plus any limits on the TSA's name. this applies to the time-stamp that has to be in every ES-T ⏰🫶
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }if ttsCertificateTrustTrees isn't there, the same rule as certificateTrustCondition applies to certifying the time-stamping authority's public key 🔑
the tstrRevReq field gives the minimum revocation info requirements, from CRLs and/or OCSP responses, for checking the revocation status of the time-stamp that has to be in the ES-T 🧾
if ttsNameConstraints isn't there, there are no extra naming constraints on the trusted TSA beyond what ttsCertificateTrustTrees already implies 💅
the cautionPeriod field is a caution period that starts after the signing time. the verifier is required to wait it out to get high assurance that the signer's key is valid and that any relevant revocation has been announced 😤 the revocation status info that forms an ES with Complete validation data must not be collected and used to validate the electronic signature until after this caution period is over. no shortcuts, bestie 🚫
the signatureTimestampDelay field is the max time you're allowed between the signing time and the moment the signature time-stamp is created for the verifier (the one used to form the ES Time-Stamped). if the signature time-stamp is later than the signing-time attribute by more than the signatureTimestampDelay value, the signature must be considered invalid. 💀
3.9. Attribute Trust Conditions
if the attributeTrustCondition field isn't present, then any certified attributes may not be considered valid under this validation policy 🙅♀️ the AttributeTrustCondition field is defined like this:
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }if attributeMandated is true, then an attribute certified within the following constraints must be present. if it's false, the signature is still valid even if no attribute is specified 🦋
the howCertAttribute field says whether the attributes are uncertified attributes "claimed" by the signer, certified attributes (i.e., Attribute Certificates), or either one. it uses the signer attributes attribute defined in [ES-FORMATS] section 3.12.3 🎀
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }the attrCertificateTrustTrees field sets the cert path conditions for any attribute cert. if it's not there, the same rules as certificateTrustCondition apply 🌸
the attrRevReq field gives the minimum revocation info requirements, from CRLs and/or OCSP responses, for checking the revocation status of Attribute Certificates, if any are present 🔍
if the attributeConstraints field isn't there, then there are no constraints on which attributes can be validated under this policy. the attributeConstraints field is defined as follows: 🧚
AttributeConstraints ::= SEQUENCE { attributeTypeConstarints [0] AttributeTypeConstraints OPTIONAL, attributeValueConstarints [1] AttributeValueConstraints OPTIONAL }
okay so the attributeTypeConstarints field is optional (yes, that's the spelling in the spec, we're not touching it 🙈). if it shows up, it lists the attribute types that count as valid under the signature policy. and for those types? any value is valid, no notes 💅
AttributeTypeConstraints ::= SEQUENCE OF AttributeTypeif the attributeTypeConstraints field is present, it pins down the specific attribute values that are considered valid under the policy. ngl the text literally says attributeTypeConstraints here even though it's describing values, so we're keeping it exactly as written 🤓
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue3.10 Algorithm Constraints 🔥
the algorithmConstrains fields, if they're there, say which signing algorithms are allowed (hash, public key cryptography, or the combined hash and public key stuff) for specific purposes, plus any minimum length. no field means the policy applies no constraints at all 🦋
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- Time-Stamping Authority
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}an Attribute Authority (AA) is an authority that hands out privileges by issuing attribute certificates 🎀
3.11 Signature Policy Extensions 🌸
extra signature policy rules can be added to:
- the overall signature policy structure, as defined in section 3.1;
- the signature validation policy structure, as defined in section 3.2;
- the common rules, as defined in section 3.3;
- the commitment rules, as defined in section 3.4;
- the signer rules, as defined in section 3.5.1;
- the verifier rules, as defined in section 3.5.2;
- the revocation requirements in section 3.6.2;
- the algorithm constraints in section 3.10.
these extensions to the signature policy rules must be defined using an ASN.1 syntax, with an associated object identifier carried in the SignPolExtn as defined below:
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }the extnID field must contain the object identifier for the extension. the extnValue field must contain the DER (see ITU-T Recommendation X.690 [4]) encoded value of the extension. the definition of an extension, as identified by extnID, must include a definition of the syntax and semantics of the extension 📜
4. Security Considerations 😭
4.1 Protection of Private Key 🔐
okay this part is dramatic but it's true: the security of the electronic signature mechanism defined in this document depends on the privacy of the signer's private key. implementations must take steps to ensure that private keys cannot be compromised. no cap, that's the whole ballgame 💀
4.2 Choice of Algorithms 🧠
implementers should be aware that cryptographic algorithms become weaker with time. as new cryptanalysis techniques get developed and computing performance improves, the work factor to break a particular cryptographic algorithm goes down. so cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. basically implementers should be prepared for the set of mandatory to implement algorithms to change over time ✨
5. Conformance Requirements 💅
signer and verifier systems shall be able to process an electronic signature in accordance with the specification of the signature policy (the signature policy referenced and identifiable by an Object Identifier, see section 3) 🫶
6. References 📚
- [TS101733] ETSI Standard TS 101 733 V.1.2.2 (2000-12) Electronic Signature Formats. Note: copies of ETSI TS 101 733 can be freely download from the ETSI web site www.etsi.org.
- [ES-FORMATS] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature Formats for Long Term Electronic Signatures", RFC 3126, June 2001.
- [TSP] Adams, C, Pinkas, D., Zuccherato, R. and P. Cain, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001.
- [OCSP] Myers, M., Ankney, R., Malpani, R., Galperin, S. and C. Adams, "On-line Status Certificate Protocol", RFC 2560, June 1999.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
- [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
- [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile," RFC 2459, January 1999.
- [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release.
- [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. Non-Repudiation Framework. April 1997.
7. Authors' Addresses 🧚
this Experimental RFC was produced inside ETSI TC-SEC, so here are the squad's details 💜
ETSI
F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles - Sophia Antipolis
Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
secretariat@etsi.fr
http://www.etsi.orgContact Point
Harri Rasilainen
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex
FRANCE
EMail: harri.rasilainen@etsi.fr
John Ross
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
EMail: ross@secstan.com
Denis Pinkas
Integris, Bull.
68, Route de Versailles
78434 Louveciennes CEDEX
FRANCE
EMail: Denis.Pinkas@bull.net
Nick Pope
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
EMail: pope@secstan.comAnnex A (normative): ✨
ASN.1 Definitions. this annex gives the reference definition of the ASN.1 syntax for the signature policies, covering the new syntax defined in this document 🎀
A.1 Definitions Using X.208 (1988) ASN.1 Syntax 🌈
NOTE: The ASN.1 Module defined in section A.1 has precedence over that defined in Annex A-2 in the case of any conflict. (yes, that's the wording, and yes it matters 😤)
ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0)
7}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All
IMPORTS
-- Internet X.509 Public Key Infrastructure
- Certificate and CRL Profile: RFC 2560
Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString,Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation, BMPString, UTF8String
FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
;
-- Signature Policy Specification
-- ==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions
OPTIONAL
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }Okay bestie, we're deep in the ASN.1 zone now 💅✨ The first chunk is all about signer and verifier rules 🎀, what a signer has to do, what a verifier has to check, plus the trust trees, revocation checks, and algorithm constraints. It's a lot, but it's giving very organised 🧚 Just copy it character for character, babe.
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions
OPTIONAL}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust point required
}
CertInfoReq ::= ENUMERATED {
none (0),
-- No mandatory requirements
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust point mandated
}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
EnuRevReq ::= ENUMERATED {
clrCheck (0), --Checks must be made against current CRLs
-- (or authority revocation lists)
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol (RFC 2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy extension
}
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- Time-Stamping Authority
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits other
SignPolExtensions OPTIONAL
}
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
END -- ETS-ElectronicSignaturePolicies-88syntax --Next up is the A.2 section 🦋 which uses the newer X.680 1997 ASN.1 syntax, and there's one super important note 🙈 If the A.1 module and the A.2 module ever disagree, A.1 wins, no debate 👑
A.2. Definitions Using X.680 1997 ASN.1 Syntax
NOTE: The ASN.1 module defined in section A.1 has precedence over that defined in section A.2 in the case of any conflict.
ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All -
IMPORTS
-- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC 2560
Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString, Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation
FROM PKIX1Explicit93
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
nid-pkix1-explicit-88(1)}
;
-- S/MIME Object Identifier arcs used in the present document
-- ==================================================================
-- S/MIME OID arc used in the present document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier
-- Signature Policy Specification
-- ==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommitmentRules ::= SEQUENCE OF CommitmentRuleOkay bestie, the ASN.1 module keeps going, and now we're getting into the trust conditions and algorithm constraints 🧚💅
Here's the commitment rule, which is the main bundle of stuff a policy can require:
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust
-- point required
}
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory requirements
signerOnly (1) ,
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a
-- trust point mandated
}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributedNext up are the certificate trust trees, the trust points, and all the name and policy constraints that come along for the ride 🌸
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)Now the revocation checking bits, which are very much a vibe 🙈
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
EnuRevReq ::= ENUMERATED {
clrCheck (0),
-- Checks must be made against current CRLs
-- (or authority revocation lists)
ocspCheck (1),
-- The revocation status must be checked using
-- the Online Certificate Status Protocol (RFC 2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be
-- carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy
-- extension
}
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }Attribute trust is next, and it's giving a whole vibe with the claimed versus certified attributes 💅
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValueAnd finally, the algorithm constraints and the extensions, which is where we wrap up the module 🎀
AlgorithmConstraintSet ::= SEQUENCE {
-- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- Time-Stamping Authority
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
END -- ETS-ElectronicPolicies-97SyntaxAnnex B (informative): 🦋
B.1 Signature Policy and Signature Validation Policy ✨
okay so the definition of electronic signature says: "a commitment has been explicitly endorsed under a "Signature Policy", at a given time, by a signer under an identifier, e.g., a name or a pseudonym, and optionally a role." 🎀
Electronic signatures are usually applied inside a legal or contractual framework 💅. That framework sets the requirements on the electronic signatures and any special meaning they carry (e.g., agreement, intent). Those requirements can be very general and abstract, or they can be spelled out as detailed rules 📜. The specific meaning a legal or contractual framework gives to an electronic signature is outside the scope of this document 🙈.
If the signature policy is recognized, within the legal/contractual context, as providing commitment, then the signer explicitly agrees with the terms and conditions that are implicitly or explicitly part of the signed data 💖.
When two independent parties want to evaluate an electronic signature, it is fundamental that they get the same result 🔥. So it's important that the conditions the signer agreed to at the time of signing are shown to the verifier and to any arbitrator. The signature policy is what lets everyone know those conditions 👑. The technical implications of the signature policy on the electronic signature, along with all the validation data, are called the "Signature Validation Policy". The signature validation policy specifies the rules used to validate the signature ✨.
This document does not mandate the form and encoding of the specification of the signature policy. However, for a given signature policy there must be one definitive form that has a unique binary encoded value 🦋.
This document includes, as an option, a formal structure for a signature validation policy based on the use of Abstract Syntax Notation 1 (ASN.1) 🧚.
Given the specification of the signature policy and its hash value, an implementation of a verification process must obey the rules defined in the specification 💜.
This document places no restriction on how it should be implemented. Provided the implementation conforms to the conformance requirements as defined in section 5, implementation options include:
- A validation process that supports a specific signature policy as identified by the signature policy OID. Such an implementation should conform to a human readable description, provided all the processing rules of the signature policy are clearly defined. However, if additional policies need to be supported, then such an implementation would need to be customized for each additional policy. This type of implementation may be simpler to implement initially, but can be difficult to enhance to support numerous additional signature policies 🌸.
- A validation process that is dynamically programmable and able to adapt its validation rules in accordance with a description of the signature policy provided in a computer-processable language. This present document defines such a policy using an ASN.1 structure (see 6.1). This type of implementation could support multiple signature policies without being modified every time, provided all the validation rules specified as part of the signature policy are known by the implementation (i.e., it only requires modification if there are additional rules specified) 🌈.
The precise content of a signature policy is not mandated by the current document. However, a signature policy must be sufficiently definitive to avoid any ambiguity as to its implementation requirements. It must be absolutely clear under which conditions an electronic signature should be accepted. For this reason, it should contain the following information 🎀:
- General information about the signature policy, which includes:
- a unique identifier of the policy;
- the name of the issuer of the policy;
- the date the policy was issued;
- the field of application of the policy.
- The signature verification policy, which includes:
- the signing period,
- a list of recognized commitment types;
- rules for Use of Certification Authorities;
- rules for Use of Revocation Status Information;
- rules for Use of Roles;
- rules for use of Time-Stamping and Timing;
- signature verification data to be provided by the signer/collected by verifier;
- any constraints on signature algorithms and key lengths.
- Other signature policy rules required to meet the objectives of the signature.
Variations of the validation policy rules may apply to different commitment types 🦋.
B.2 Identification of Signature Policy 🫶
When data is signed, the signer indicates the signature policy applicable to that electronic signature by including an object identifier for the signature policy with the signature 💅. The signer and verifier must apply the rules specified by the identified policy. In addition to the identifier of the signature policy, the signer must include the hash of the signature policy, so it can be verified that the policy selected by the signer is the identical to the one being used by the verifier 🔍.
A signature policy may be qualified by additional information. This can include:
- A URL where a copy of the Signature Policy may be obtained;
- A user notice that should be displayed when the signature is verified.
If no signature policy is identified, then the signature may be assumed to have been generated/verified without any policy constraints, and hence may be given no specific legal or contractual significance through the context of a signature policy 🙈.
A "Signature Policy" will be identifiable by an OID (Object Identifier) and verifiable using a hash of the signature policy 💜.
B.3 General Signature Policy Information 🌸
General information should be recorded about the signature policy, along with the definition of the rules which form the signature policy as described in the subsequent subsections. This should include:
- Policy Object Identifier: The "Signature Policy" will be identifiable by an OID (Object Identifier) whose last component (i.e., right-most) is an integer that is specific to a particular version issued on the given date.
- Date of issue: When the "Signature Policy" was issued.
- Signature Policy Issuer name: An identifier for the body responsible for issuing the Signature Policy. This may be used by the signer or verifier in deciding if a policy is to be trusted, in which case the signer/verifier must authenticate the origin of the signature policy as coming from the identified issuer 👑.
- Signing period: The start time and date, optionally with an end time and date, for the period over which the signature policy may be used to generate electronic signatures.
- Field of application: This defines in general terms the general legal/contract/application contexts in which the signature policy is to be used, and the specific purposes for which the electronic signature is to be applied ✨.
B.4 Recognized Commitment Types 🎀
The signature validation policy may recognize one or more types of commitment as being supported by electronic signatures produced under the security policy. If an electronic signature does not contain a recognized commitment type, then the semantics of the electronic signature are dependent on the data being signed and the context in which it is being used 🧚.
Only recognized commitment types are allowed in an electronic signature 🔥.
The definition of a commitment type includes:
- the object identifier for the commitment;
- the contractual/legal/application context in which the signature may be used (e.g., submission of messages);
- a description of the support provided within the terms of the context (e.g., proof that the identified source submitted the message, if the signature is created when message submission is initiated).
The definition of a commitment type can be registered:
- as part of the validation policy;
- as part of the application/contract/legal environment;
- as part of a generic register of definitions.
The legal/contractual context will determine the rules applied to the signature, as defined by the signature policy and its recognized commitment types, to make it fit for the purpose intended 💖.
B.5 Rules for Use of Certification Authorities 🦋
The certificate validation process of the verifier, and hence the certificates that may be used by the signer for a valid electronic signature, may be constrained by the combination of the trust point and certificate path constraints in the signature validation policy 🌈.
B.5.1 Trust Points 💅
The signature validation policy defines the certification authority trust points that are to be used for signature verification. Several trust points may be specified under one signature policy. Specific trust points may be specified for a particular type of commitment defined under the signature policy. For a signature to be valid, a certification path must exist between the Certification Authority that has granted the certificate selected by the signer (i.e., the used user-certificate) and one of the trust points of the "Signature Validation Policy" 👑.
B.5.2 Certification Path ✨
Okay so, there can be constraints on the certificates issued by the CA(s) in the chain and the trust points 🔗. The two big ones are certificate policy constraints and naming constraints:
- Certificate policy constraints limit the certification chain between the user certificate and the certificate of the trusted point to a given set of certificate policies, or equivalents identified through certificate policy mapping. 💅
- The naming constraints limit the forms of names that the CA is allowed to certify. 🎀
Name constraints are especially important when a "Signature policy" identifies more than one trust point. Then a certificate from a particular trusted point may only be used to verify signatures from users whose names are permitted under that name constraint 🫶
CAs can be arranged in a tree, which shows the trust relationship between the various CAs and the user's CA 🌳. Or you can get a mesh, where tree and peer cross-certificates get mixed together 🕸️. The requirement in this document is that the certificate path shows the trust relationship between all the CAs and the signer's user certificate. The starting point from the verifier's side is the "trust point", which is usually a CA that publishes self-certified certificates. It's where the verifier starts walking the chain 🚶♀️. Naming constraints may apply from the trust point, and if they do, they apply across the whole certificate path, all the way down to the signer's user certificate 🙈
Policy constraints are easier to process, but to actually work they need a certificate policy identifier to be present in the certificates used in a certification path 📜
Path processing generally starts at one of the trust points from the signature policy and ends at the user certificate. The procedures in RFC 2459 section 6 list these initial parameters that the verifier selects:
- acceptable certificate policies;
- naming constraints in terms of constrained and excluded naming subtrees;
- requirements for explicit certificate policy indication and whether certificate policy mapping is allowed;
- restrictions on the certificate path length.
The signature validation policy puts constraints on those parameters. 👑
B.6 Revocation Rules ⛔
The signature policy should define rules for using certificate revocation lists (CRLs) and/or online certificate status check services to check whether a certificate is still valid. These rules set out the mandated minimum checks that must be carried out.
It's expected that in lots of cases either check may be selected, with CRL checks being done for certificate status that's unavailable from OCSP servers. The verifier may take into account information in the certificate when deciding how best to check revocation status (for example, a certificate extension field about authority information access, or a CRL distribution point), as long as it doesn't conflict with the signature policy revocation rules 🔍
B.7 Rules for the Use of Roles 👑
Roles can be supported as claimed roles or as certified roles using Attribute Certificates 🎀
B.7.1 Attribute Values 💜
When a signature under a role is mandated by the signature policy, then either Attribute Certificates may be used or the signer may provide a claimed role attribute. The acceptable attribute types or values may depend on the type of commitment. For example, a user may have several roles that let them sign data, and those roles imply commitments based on one or more of them 🦋
B.7.2 Trust Points for Certified Attributes 🌸
When a signature under a certified role is mandated by the signature policy, Attribute Authorities are used and need to be validated as part of the overall validation of the electronic signature. The trust points for Attribute Authorities don't need to be the same as the trust points for evaluating a certificate from the signer's CA. So the trust point for verifying roles need not be the same as the trust point used to validate the certificate path of the user's key 🫶
Naming and certification policy constraints may apply to the AA in similar circumstances to when they apply to the CA. Constraints on the AA and CA need not be exactly the same.
AA(s) may be used when a signer creates a signature on behalf of an organization, and they can be especially useful when the signature represents an organizational role. AA(s) may or may not be the same authority as CA(s).
So the Signature Policy identifies trust points that can be used for Attribute Authorities, either by reference to the same trust points used for Certification Authorities, or by an independent list 🧚
B.7.3 Certification Path for Certified Attributes 🍓
Attribute Authorities may be organized in a tree structure, similar to CAs, where the AAs are the leaves of such a tree. Naming and other constraints may be required on attribute certificate paths, in a similar way to other electronic signature certificate paths.
So the Signature Policy identifies constraints on the following parameters used as input to certificate path processing:
- acceptable certificate policies, including requirements for explicit certificate policy indication and whether certificate policy mapping is allowed;
- naming constraints in terms of constrained and excluded naming subtrees;
- restrictions on the certificate path length.
B.8 Rules for the Use of Time-Stamping and Timing ⏰
The following rules should be used when specifying constraints on the certificate paths for time-stamping authorities, constraints on the time-stamping authority names, and general timing constraints 🕰️
B.8.1 Trust Points and Certificate Paths 🌈
Signature keys from time-stamping authorities will need to be supported by a certification path. The certification path used for time-stamping authorities requires a trust point and possibly path constraints, in the same way as the certificate path for the signer's key 🔑
B.8.2 Time-Stamping Authority Names 🙈
Restrictions may need to be placed by the validation policy on the named entities that may act as time-stamping authorities.
B.8.3 Timing Constraints - Caution Period ⚠️
Before an electronic signature can really be valid, the verifier has to be sure the holder of the private key was truly the only one in possession of the key at the time of signing. But there's an inevitable delay between a compromise or loss of a key being noticed and a report of revocation being distributed. So to allow greater confidence in a signature's validity, a "cautionary period" may be identified before a signature can be said to be valid with high confidence. A verifier may revalidate a signature after this cautionary period, or wait for this period before validating a signature 🧐
The validation policy may specify such a cautionary period.
B.8.4 Timing Constraints - Time-Stamp Delay ⌛
There will be some delay between the time a signature is created and the time the signer's digital signature is time-stamped. However, the longer this elapsed period, the greater the risk of the signature being invalidated due to compromise or deliberate revocation of its private signing key by the signer 😭 So the signature policy should specify a maximum acceptable delay between the signing time claimed by the signer and the time included within the time-stamp ✨
B.9 Rules for Verification Data to be followed 📋
By specifying the requirements on the signer and verifier, the responsibilities of the two parties can be clearly defined so that all the necessary information gets established 💖
These verification data rules should include:
- requirements on the signer to provide given signed attributes;
- requirements on the verifier to obtain additional certificates, CRLs, results of online certificate status checks, and to use time-stamps (if not already provided by the signer).
B.10 Rules for Algorithm Constraints and Key Lengths 🔐
The signature validation policy may identify a set of signing algorithms (hashing, public key, combinations) and minimum key lengths that may be used:
- by the signer in creating the signature;
- in end entity public key Certificates;
- CA Certificates;
- attribute Certificates;
- by the time-stamping authority.
B.11 Other Signature Policy Rules 🌟
The signature policy may specify additional policy rules, for example rules that relate to the environment used by the signer. These additional rules may be defined in computer processable and/or human readable form 🧩
B.12 Signature Policy Protection 🛡️
When a signer or verifier obtains a copy of the Signature Policy from an issuer, the source should be authenticated (for example by using electronic signatures). When the signer references a signature policy, the Object Identifier (OID) of the policy, the hash value and the hash algorithm OID of that policy must be included in the Electronic Signature 🫶
It is a mandatory requirement of this present document that the signature policy value computes to one, and only one hash value using the specified hash algorithm. This means there must be a single binary value of the encoded form of the signature policy for the unique hash value to be calculated. For example, there may exist a particular file type, length and format on which the hash value is calculated, which is fixed and definitive for a particular signature policy 💅
The hash value may be obtained by:
- the signer performing his own computation of the hash over the signature policy, using his preferred hash algorithm permitted by the signature policy, and the definitive binary encoded form;
- the signer, having verified the source of the policy, may use both the hash algorithm and the hash value included in the computer processable form of the policy (see section 6.1).
Full Copyright Statement ✨
Copyright (C) The Internet Society (2001). All Rights Reserved.
okay bestie, the legal bit 💅 Anyone can copy this document and share it, translations included. You can also write derivative works that comment on or explain it or help people implement it, and publish and distribute those in whole or in part, no restrictions, as long as the copyright notice and this paragraph stay on every copy. BUT the document itself can't be changed in any way, like deleting the copyright notice or the references to the Internet Society or other Internet orgs. The exceptions are developing Internet standards (then the copyright procedures in the Internet Standards process have to be followed) or translating it into a language that isn't English. 🌸
These permissions are perpetual 💖 which means the Internet Society and its successors or assigns won't ever revoke them.
Now the disclaimer, which is in all caps for a reason 🙈
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🫶🦋
📦 where this page comes from
- ietf: rfc3125 2001-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms