Network Working Group J. Ross Request for Comments: 3125 Security & Standards Category: Experimental D. Pinkas Integris N. Pope Security & Standards September 2001 Electronic Signature Policies Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements. A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation. The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied. To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1. The contents of this document is based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org. Ross, et al. Experimental [Page 1] RFC 3125 Electronic Signature Policies September 2001 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 Ross, et al. Experimental [Page 2] RFC 3125 Electronic Signature Policies September 2001 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 44 1. Introduction This document is intended to cover signature policies which can be used with electronic signatures for various types of transactions, including business transactions (e.g., purchase requisition, contract, and invoice applications). Electronic signatures can be used for any transaction between an individual and a company, between two companies, between an individual and a governmental body, etc. This document is independent of any environment. It can be applied to any environment e.g., smart cards, GSM SIM cards, special programs for electronic signatures etc. 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]. 2. Major Parties The document uses the following terms: * the Signature Policy Issuer; * the Signer; * the Verifier; * the Arbitrator; * Trusted Service Providers (TSP); The Signature Policy Issuer (which is a Trusted Service Provider (TSP)) issues signatures policies that define the technical and procedural requirements for electronic signature creation, and validation/ verification, in order to meet a particular business need. The Signer is the entity that creates the electronic signature. When the signer digitally signs over an signature policy identifier, it represents a commitment on behalf of the signing entity that the data being signed is signed under the rules defined by the signature policy. The Verifier is the entity that validates the electronic signature, it may be a single entity or multiple entities. The verifier MUST validate the electronic signature under the rules defined by the electronic signature policy for the signature to be valid. Ross, et al. Experimental [Page 3] RFC 3125 Electronic Signature Policies September 2001 An arbitrator, is an entity which arbitrates disputes between a signer and a verifier. It acts as verifier when it verifies the electronic signature after it has been previously validated. The Trusted Service Providers (TSPs) are one or more entities that help to build trust relationships between the signer and verifier. Use of TSP specific services MAY be mandated by signature policy. TSP supporting services include: user certificates, cross- certificates, time-stamping tokens,CRLs, ARLs, OCSP responses. A Trusted Service Providers (TSPs) 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. The following 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 provide users with public key certificates. Registration Authorities allows the registration of entities 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) provide information about the status (i.e., revoked, not revoked, unknown) of a particular certificate. Attributes Authorities provide users with attributes linked to public key certificates An Arbitrator is an entity that arbitrates disputes between a signer and a verifier. Ross, et al. Experimental [Page 4] RFC 3125 Electronic Signature Policies September 2001 3. Signature Policy Specification A signature policy specification includes general information about the policy, the validation policy rules and other signature policy information. 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. This document defines but does not mandate the form of the signature policy specification. 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 defines an ASN.1 based syntax that may be used to define a structured signature policy. Future versions of this document may include structured a signature policy specification using XML. 3.1 Overall ASN.1 Structure The overall structure of a signature policy defined using ASN.1 is given in this section. 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 is preceded by an identifier for the hashing algorithm used to protect the signature policy and followed by the hash value which must be re-calculated and checked whenever the signature policy is passed between the issuer and signer/verifier. The hash is calculated without the outer type and length fields. Ross, et al. Experimental [Page 5] RFC 3125 Electronic Signature Policies September 2001 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 The policyIssuerName field identifies the policy issuer in one or more of the general name forms. The fieldofApplication is a description of the expected application of this policy. The signature validation policy rules are fully processable to allow the validation of electronic signatures issued under that form of signature policy. They are described in the rest of this section. The signPolExtensions is a generic way to extend the definition of any sub-component of a signature policy. 3.2 Signature Validation Policy The signature validation policy defines for the signer which data elements must be present in the electronic signature he provides and for the verifier which data elements must be present under that signature policy for an electronic signature to be potentially valid. The signature validation policy is described as follows: Ross, et al. Experimental [Page 6] RFC 3125 Electronic Signature Policies September 2001 SignatureValidationPolicy ::= SEQUENCE { signingPeriod SigningPeriod, commonRules CommonRules, commitmentRules CommitmentRules, signPolExtensions SignPolExtensions OPTIONAL } The signingPeriod identifies the date and time before which the signature policy SHOULD NOT be used for creating signatures, and an optional date after which it should not be used for creating signatures. SigningPeriod ::= SEQUENCE { notBefore GeneralizedTime, notAfter GeneralizedTime OPTIONAL } 3.3 Common Rules The CommonRules define rules that are common to all commitment types. These rules are defined in terms of trust conditions for certificates, time-stamps and attributes, along with any constraints on attributes that may be included in the electronic signature. 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 } If a field is present in CommonRules then the equivalent field must not be present in any of the CommitmentRules (see below). If any of the following fields are not present in CommonRules then it must be present in each CommitmentRule: * signerAndVeriferRules; * signingCertTrustCondition; * timeStampTrustCondition. Ross, et al. Experimental [Page 7] RFC 3125 Electronic Signature Policies September 2001 3.4 Commitment Rules The CommitmentRules consists of the validation rules which apply to given commitment types: CommitmentRules ::= SEQUENCE OF CommitmentRule The CommitmentRule for given commitment types are defined in terms of trust conditions for certificates, time-stamps and attributes, along with any constraints on attributes that may be included 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 } If the SelectedCommitmentTypes indicates "empty" then this rule applied when a commitment type is not present (i.e., the type of commitment is indicated in the semantics of the message). Otherwise, the electronic signature must contain a commitment type indication that must fit one of the commitments types that are mentioned in CommitmentType. 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 } Ross, et al. Experimental [Page 8] RFC 3125 Electronic Signature Policies September 2001 The fieldOfApplication and semantics fields define the specific use and meaning of the commitment within the overall field of application defined for the policy. 3.5 Signer and Verifier Rules The following rules apply to the format of electronic signatures defined using [ES-FORMATS]. The SignerAndVerifierRules consists of signer rule and verification rules as defined 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 Ross, et al. Experimental [Page 9] RFC 3125 Electronic Signature Policies September 2001 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, -- Mandated Certificate Info signPolExtensions [2] SignPolExtensions OPTIONAL } CMSattrs ::= SEQUENCE OF OBJECT IDENTIFIER The mandated SignedAttr field must include the object identifier for all those signed attributes required by this document as well as additional attributes required by this policy. The mandatedUnsignedAttr field must include the object identifier for all those unsigned attributes required by this document as well as additional attributes required by this policy. For example, if a signature time-stamp