S/MIME Working Group J. L. Hernandez-Ardieta Internet Draft University Carlos III of Madrid Intended Status: Experimental A. I. Gonzalez-Tablas University Carlos III of Madrid Expires: June 26, 2011 December 23, 2010 Extended Electronic Signature Policies draft-hernandez-ardieta-smime-eesp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 26, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 1] Internet Draft Extended Electronic Signature Policies December 2010 Abstract This document defines extended electronic signature policies (ext-SP) that extend the boundaries of the electronic signature policy defined in [RFC3125] in a manner that the relationships and dependences among multiple electronic signatures generated within the scope of the same electronic transaction can be established. A given legal/contractual context may recognize a particular ext-SP as meeting its requirements. An ext-SP has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation. The ext-SP can be defined 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, the ext-SP specifies, using a computer processable form, the timing and sequence dependencies of the set of signatures that must be generated to make the transaction effective along with the set of attributes and rules that each signature must comply with. In the current document the format of the ext-SP is defined using ASN.1. The content of this document is based on the requirements and needs established in ETSI TR 102 045 V1.1.1 (2003-03) Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org. Discussion This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to smime-request@ietf.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at https://www.ietf.org/mailman/listinfo/smime. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 2] Internet Draft Extended Electronic Signature Policies December 2010 Table of Contents 1. Introduction 4 2. Major Parties 5 3. Extended Signature Policy Specification 6 3.1. Overall ASN.1 Structure 7 3.2. Extended Signature Policy Identifier 8 3.3. Validation Policy 8 3.3.1. Trees of Solutions 9 3.4. Business and Transactional Domains 13 3.5. Signing Roles 14 3.6. Extended Signature Policy Extensions 14 4. Validity Conditions 14 5. Integration in AdES formats 15 6. Security Considerations 16 6.1. Protection of Private Key 16 6.2. Extended Signature Policy Protection 16 7. IANA Considerations 17 8. References 17 8.1. Normative References 17 8.2. Informative References 17 9. Authors' Addresses 18 Annex A (normative): ASN.1 Definitions Using X.680 1997 ASN.1 Syntax 19 Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 3] Internet Draft Extended Electronic Signature Policies December 2010 1. Introduction An electronic signature policy, as defined in [RFC3125], is a document that collects a set of rules to create and validate electronic signatu- res, under which an electronic signature can be deemed valid in a parti- cular transaction context. Thereby, transacting parties are able to determine the conditions under which an electronic signature becomes binding in a given business context. The policy is used by the signer in order to generate the signature according to its requirements. Afterwards, the verifier must use the policy to decide whether the signature is valid or not. However, the increase of paper-based processes being transposed into the digital realm makes current signature policy definition insufficient to cope with the new needs that arise. Frenquently, documents require more than one signature to give it legal validity or to make a transaction effective. For instance, a transaction where a contract of sale is to be signed may be considered complete if and only if the signature of both buyer and seller is present. Sometimes, the signature of an e-notary on each signature may be required as well. This document extends the boundaries of the electronic signature policy defined in [RFC3125] in order to permit the establishment of the relationships and dependencies of multiple signatures that are required to make a transaction effective. In this document, extended electronic signature policies (ext-SP) are defined, using an approach based on three different levels of abstraction: - Business Level. The first level defines the business and transactional context that apply to the electronic signatures generated according to the ext-SP. - Inter-relationships Level. The second level establishes the set of electronic signatures that must be present in order to give legal effectiveness to the transaction as well as the relationships and dependences that are accepted among these signatures. - Atomic Level. In the third level, the requirements to be fulfilled by each electronic signature are defined. In practice, this level is implemented by signature policies as defined in [RFC3125]. Any electronic signature generated under the conditions established in an ext-SP must not be deemed valid, and, therefore, the commitments made by the signer enforced, until the complete set of signatures defined in the ext-SP content has been correctly generated. This document is intended to cover extended electronic signature policies that 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 Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 4] Internet Draft Extended Electronic Signature Policies December 2010 applied to any environment e.g., e-commerce, e-Government, contract signing etc. The definition of the ext-SP is contained in next Sections. Appendix A contains the ASN.1 module. In this document we refer to current signature policy definition [RFC3125] as signature policy, and to the policy defined herein, the extended signature policy or ext-SP. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Major Parties The document uses the following terms: * the Signature Policy Issuer; * the Extended 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 [RFC3125] that define the technical and procedural requirements for electronic signature creation, and validation/ verification, in order to meet a particular business need. The Extended Signature Policy Issuer (which is a Trusted Service Provider (TSP)) issues extended signatures policies that define the relationships and dependencies between the electronic signatures required in order to meet a particular business need. The Signer is the entity that creates one or more electronic signatures represented in the ext-SP content. The signer MUST digitally sign over a signature policy identifier and an extended signature policy identifier. In the case of the signature policy reference, 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. In the case of the extended signature policy, it assures that the signer MUST NOT be held liable for any commitment made in such signature until the rest of electronic signatures identified in the ext-SP content have been correctly generated. The Verifier is the entity that validates a partial or complete set of signatures according to the content of the ext-SP. The verifier MUST validate the set of electronic signature under the rules defined by the ext-SP, and each electronic signature according to the rules established in the corresponding signature policy in order to conclude that the set of signatures is valid, and thus each signer can be held liable for the Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 5] Internet Draft Extended Electronic Signature Policies December 2010 commitments made. The verifier may be a single entity or multiple entities. An Arbitrator is an entity that arbitrates disputes between a signer or signers, and a verifier. It acts as verifier when it verifies the set of signatures taking into account the referenced signature policies and extended signature policy. 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 the signature policies referenced from the ext-SP content. 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, or an Extended Signature Policy Issuer. 3. Extended Signature Policy Specification An extended signature policy (ext-SP) specification includes general information about the policy, the relationships and conditions among the electronic signatures to be generated in the electronic transaction, and the transactional and business context, among other information. This document mandates that: * an electronic signature must be processed by the signer and verifier in accordance with the signature policy and the extended electronic signature referenced by the signer; * the signature policy referenced by the signer must be identifiable by an Object Identifier; * the extended signature policy referenced by the signer must be identifiable by an Object Identifier; * there must exist a specification of every signature policy referenced from the extended signature policy; * there must exist a specification of the extended signature policy; * for a given signature policy there must be one definitive form of the specification which has a unique binary encoding; * for a given extended 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 ext-SP 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 an ext-SP specification using XML. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 6] Internet Draft Extended Electronic Signature Policies December 2010 3.1 Overall ASN.1 Structure The overall structure of an ext-SP 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). ExtSignaturePolicy ::= SEQUENCE { extSignPolicyInfo ExtSignPolicyInfo, extSignPolicyProtection ExtSignPolicyProtection OPTIONAL } The whole information about the ext-SP is collected in the extSignPolicyInfo field , which ASN.1 structure is defined as follows: ExtSignPolicyInfo ::= SEQUENCE { extSignPolicyIdentifier ExtSignPolicyIdentifier, extSignValidationPolicy ExtSignValidationPolicy, extSignContext [0] ExtSignContext OPTIONAL, extSignPolExtensions [1] SignPolExtensions OPTIONAL } On the other hand, extSignPolicyProtection field includes the information about the cryptographic algorithm applied to protect the ext-SP, as well as the cryptographic result after applying such algorithm. If this field is not included in the ext-SP, then an external protection mechanism MUST be used by the parties when transmitting the ext-SP through insecure means. ExtSignPolicyProtection type is defined as follows: ExtSignPolicyProtection ::= SEQUENCE { protectionAlg AlgorithmIdentifier, protection BIT STRING } The protection algorithm, defined in protectionAlg field (AlgorithmIdentifier ASN.1 type, as defined in [RFC5280]) must be applied on the DER encoding [X.690] of the extSignPolicyInfo field. Different cryptographic algorithms could be used, like hash functions or digital signature algorithms. The ext-SP MUST be protected by other means if the applied protection algorithm does not suffice in certain circumstances (see Section 6.2). If a hash function is used, the hash MUST be calculated without the outer type and length fields, and the value obtained MUST be encoded in the protection field. If a digital signature algorithm is used (e.g. sha1withRSAEncryption), then the requirements for hash functions applies, and the digital signature value MUST be encoded in the protection field. In this case, the digital certificate that wraps the public key corresponding to the signing private key MUST be provided by other means. The subjectDN field of the certificate SHOULD correspond to the policyIssuerName further defined. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 7] Internet Draft Extended Electronic Signature Policies December 2010 The next Sections describe the fields indicated in the ExtSignPolicyInfo ASN.1 type. An optional extension field named extSignPolExtensions of SignPolExtensions ASN.1 type (as defined in [RFC3125]) is included for future needs in most of ASN.1 types defined in this document. 3.2 Extended Signature Policy Identifier The ext-SP must be uniquely identified by both signers and verifiers. The extSignPolicyIdentifier field of ExtSignPolicyIdentifier ASN.1 type is included for that purpose: ExtSignPolicyIdentifier ::= SEQUENCE { extSignPolicyId ExtSignPolicyId, dateOfIssue GeneralizedTime, policyIssuerName PolicyIssuerName, extSigPolicyQualifiers [0] SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL, extSignPolExtensions [1] SignPolExtensions OPTIONAL } ExtSignPolicyId ::= OBJECT IDENTIFIER PolicyIssuerName ::= GeneralNames The extSignPolicyId field is an Object Identifier (OID) that uniquely identifies this ext-SP among all policies issued by the issuer identified by policyIssuerName field. The dateOfIssue field indicates the date when this policy was issued. The policyIssuerName field identifies the extended electronic signature policy issuer in one or more of the general name forms. The extSigPolicyQualifiers field includes additional qualifying information, like the location where the ext-SP can be retrieved from. SigPolicyQualifierInfo ASN.1 type is defined in [RFC5126]. The extSignPolExtensions is a generic way to extend the definition of any sub-component of an extended signature policy. 3.3 Validation Policy The ExtSignValidationPolicy is the core of the ext-SP, and describes the rules and conditions to be fulfilled by the set of signatures in order to give effectiveness to the transaction. The validation policy provides signers with the information to generate an electronic signature according to the requirements established in the atomic and inter-relationships levels, and within the scope of the transaction and business context specified in the business level of the ext-SP. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 8] Internet Draft Extended Electronic Signature Policies December 2010 The validation policy also provides verifiers and arbitrators the information to ascertain whether a set of electronic signatures generated according to a given ext-SP are complete and valid. The validation policy is described as follows: ExtSignValidationPolicy ::= SEQUENCE { signingPeriod [0] SigningPeriod, treesOfSolutions [1] TreesOfSolutions, extSignPolExtensions [2] SignPolExtensions OPTIONAL } SigningPeriod ::= SEQUENCE { notBefore GeneralizedTime, notAfter GeneralizedTime OPTIONAL } The signingPeriod identifies the date and time before which the ext-SP MUST NOT be used for creating signatures, and an optional date after which it MUST NOT be used for creating signatures. It should be noted that a set of signatures created under a valid ext-SP can still be verified against the policy after its expiration date. The treesOfSolutions field, detailed in Section 3.3.1, contains a set of graphs where each one represents a tree of signatures that defines the dependences and relationships among them. This field implements the Inter-relationships Level mentioned in the Introduction of this document. 3.3.1 Trees of Solutions A set of signatures MAY consist of the next types of electronic signatures: - Parallel signatures, which are applied on the same piece of information. They are mutually independent signatures where the order of the signatures is not important. For instance, a document may be electronically signed by two or more parties, like in a contract sale example. - Sequential signatures, which differ from parallel signatures in that the order is significant (e.g. a data flow or transaction chain). - Embedded signatures, where one signature is applied to another. The sequence in which the signatures are applied is important and there is a strong interrelationship. An example is a process where an electronic signature must be signed (authorized) by another (e.g. an e-notary signature applied to another). A set of signatures can thus derive in a tree graph. A tree is a connected graph with n vertices (nodes) and n-1 edges, and where there are no cycles. In particular, the tree that represents the set of signatures has the next specific properties: Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 9] Internet Draft Extended Electronic Signature Policies December 2010 - The tree is a rooted tree in which the root node (level 0) represents the original signed document and the rest of nodes correspond to signatures. - The edges have a natural orientation away from the root. The tree expands from the root towards the leaf nodes, which are nodes with no child. - The graph is unweighted, that is, there are no edge weights. - The tree is irregular: each node (signature) not being a leaf node can have a different positive degree, that is, it can have as many children as needed. Leaf nodes have positive degree 0. - Every node has a negative degree 1 (number of parent nodes), except the root node which has negative degree 0. Next Figure depicts an example of a set of signatures in tree form: ----------- |SignedData| ----------- | | ----------------- | | | \/ \/ \/ PS1 PS2 PS3 | | ------ | | \/ \/ CS1 CS2 Electronic signatures in level 1 of the tree correspond to primary signatures (PS), which are either parallel or sequential signatures. The rest of signatures correspond to countersignatures (CS), which are embedded signatures that can be applied to either a PS or another CS. Besides, signatures which are children of the same parent behave as PS among them. The difference is that the signatures are applied to another signature instead of the document. In the example above, the tree graph represents a set of signatures where there are three primary signatures generated over the root node (SignedData), and two countersignatures generated over the second primary signature. Though the arrows are shown following a top-down direction, a signature in level n is applied to the parent signature in level n-1. In certain scenarios, more than one tree of signatures can make the same transaction be legally effective. E.g. in fair exchange and fair non- repudiation protocols, a transaction can be finished (becomes effective) either by completing the main protocol or one of the specified subprotocols. Many other scenarios can be customized to follow this Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 10] Internet Draft Extended Electronic Signature Policies December 2010 approach. For instance, an e-commerce protocol where two parties must sign a document can decide to either countersigning each others signature or let an authorized e-notary to do it. In order to support this type of transactions, the Trees of Solutions (TSo) consists of a sequence of trees, each of which (named TSi) as represented in previous Figure. During the validation stage, the verifier must check if the evaluated set of signatures matches one of the trees defined in TSo. The transaction is made effective provided that one TSi is completely satisfied. TreesOfSolutions ::= SEQUENCE OF treeOfSignatures TreeOfSignatures TreeOfSignatures ::= SEQUENCE OF signature Signature The Signature ASN.1 type defines the information of a particular node (signature) in a tree of signatures: Signature ::= SEQUENCE { identifier INTEGER (0..MAX), signer INTEGER (0..MAX), acceptableSignPolicies AcceptableSignPolicies, allowedCommitmentTypes SelectedCommitmentTypes, counterSignatures [0] TreeOfSignatures OPTIONAL, timingAndSequence [1] TimingAndSequence OPTIONAL, extSignPolExtensions [2] SignPolExtensions OPTIONAL } Each node (signature) is uniquely identified by the identifier field. This information is used to specify timing and sequence dependences, further explained. The signer that must perform this signature is uniquely represented in a figurative sense by the signer field. No signer specific information MUST be used (e.g. subject distinguished name or subject alternative name) as the ext-SP issuer does not know a priori which signer will actually perform the signature. A signer MAY appear in as many signatures of the tree as needed, but signatures to be generated by different signers MUST contain different signer values. AcceptableSignPolicies ::= SEQUENCE OF signPolicyId SignPolicyId SignPolicyId ::= OBJECT IDENTIFIER The acceptableSignPolicies field contains the signature policies (SP) OIDs [RFC3125] that can be used by the signer when creating this signature. This field implements the Atomic Level mentioned in the Introduction of this document. The allowedCommitmentTypes field restricts the commitment types that can be assumed by the signer when producing this specific signature. This field is of SelectedCommitmentTypes ASN.1 type, as defined in [RFC3125]. These commitment types must be consistent with those included in the acceptable signature policies herein indicated. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 11] Internet Draft Extended Electronic Signature Policies December 2010 Each signature can have a finite number of child nodes, which are represented by a TreeOfSignatures in the counterSignatures field. As a result, the tree is represented by following a recursive method, in which the leaf nodes of the tree will not have the counterSignatures field. TimingAndSequence ::= CHOICE { absoluteTimingAndSequence [0] SigningPeriod, relativeTimingAndSequence [1] SEQUENCE OF RelativeTimingAndSequence } The time frame during which a signature must be generated and the sequential relationships with other signatures are described in timingAndSequence field. The TimingAndSequence type supports the specification of sequential signatures. It allows any signature to have as many timing and sequence dependences on other signatures as needed. There are three possibilities: - A signature has no actual dependence on any other signature (e.g. primary signatures). - A signature has no dependence on other signatures but it must be performed within a period of time (e.g. a primary signature to be performed not before 17/07/1997 00:00:00 GMT and not after 17/07/2007 00:00:00 GMT). We define this dependence as an absolute dependence. - A signature has certain dependences on other signatures, either sequential or embedded. These are considered as relative dependences. The first case is achieved by omitting the timingAndSequence field of Signature type above. The second case is implemented by selecting absoluteTimingAndSequence field in TimingAndSequence type. To define one or more relative dependences, the relativeTimingAndSequence field must be selected, which ASN.1 type is the next: RelativeTimingAndSequence ::= SEQUENCE { pathToRefSignature SEQUENCE OF INTEGER, maxDelta DeltaTime OPTIONAL } The pathToRefSignature field indicates the path of node identifier field values from a signature located in level one of the tree to the signature with which there is timing and sequence dependence. The maxDelta field indicates the maximum time delay allowed from the referenced signature's signing time during which this signature can be performed. That is, this signature must be performed in a period of time defined by [t0, t0 + maxDelta] where t0 is the referenced signature's signing time. If this field is omitted, it means that this signature must be generated after the referenced signature but with no time limit. In order to obtain accurate and reliable time references, signatures SHOULD be time stamped, following the requirements specified in the TimestampTrustCondition ASN.1 type [RFC3125]. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 12] Internet Draft Extended Electronic Signature Policies December 2010 3.4 Business and Transactional Domains The context in which the extended signature policy applies is defined in the field extSignContext of ExtSignPolicyInfo ASN.1 structure. This field is of ExtSignContext type, and implements the Business Level mentioned in the Introduction of this document. ExtSignContext ::= SEQUENCE { businessApplicationDomain [0] SigPolicyQualifierInfo OPTIONAL, transactionalContext [1] SigPolicyQualifierInfo OPTIONAL, disputeResolution [2] SigPolicyQualifierInfo OPTIONAL, audienceConditions [3] SigPolicyQualifierInfo OPTIONAL, extSignPolExtensions [4] SignPolExtensions OPTIONAL } The businessApplicationDomain field outlines the business domain in which the ext-SP is suitable for use, e.g. sale of goods/international trade transactions, e-Government transactions between citizens and e- Administration, e-health services, etc. It covers high-level and sector- oriented domains. On the contrary, the transactionalContext field provides additional information about the transactional context (e.g. draft of a contract, purchase by means of online service, exchange of design documents, etc.). This information SHOULD match with the fieldOfApplication field of each signature policy, described in SignPolicyInfo ASN.1 type in [RFC3125]. Disputes on a specific event or action taken by any party in a transaction may arise in a future. A dispute must be resolved by a third party with authority to do so, taking as information for the resolution the evidence generated in the transaction. Electronic signatures may act as non-repudiation evidence if adequate policies used by the parties enforce them. In that case, the third party must consider if the conditions established for the transactions have been fulfilled by the parties. The dispute resolution procedures are contained in the disputeResolution field. It allows the ext-SP issuer to specify a binding text to be considered by the parties when using this policy for generating and validating signatures, and by the third party for resolving a dispute. Finally, audienceConditions states the conditions under which a signature may be relied upon, e.g. the signature only valid in a specified jurisdiction, where laws exist which recognize the legal validity of signatures created under conditions as specified in the policy. This field may include provisions relating to the intended effectiveness of signatures, where multiple signatures are required, e.g. the signature must be countersigned to be relied upon. Each field, except extSignPolExtensions field, is of SigPolicyQualifierInfo ASN.1 type, defined in [RFC5126]. Therefore, the information for each field could be available at a Web URI or URL reference (specified by SPuri type of qualifier), or explicitly contained in the qualifier through the SPUserNotice qualifier, which may Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 13] Internet Draft Extended Electronic Signature Policies December 2010 contain a reference to the organization notice and an explicit text. Please refer to Section 5.8.1 of [IETF:RFC5126] for further information. 3.5 Signing Roles A signing role is a role allocated to or adopted by a signer, and which defines the relationship between its signature and the rest of signatures [TR102045]. A signing role is mainly a Primary Signature (PS) or a CounterSignature (CS). In this document, the signing role is implicitly assigned to a signer by means of the position that his corresponding signature has in the concrete tree of signatures (TSi). Therefore, a signature mapped to a node in level one of TSi implies that the signer is assuming a PS signing role. Otherwise, the signing role is a CS. This behavior completely satisfies the requirements respecting signing roles given in Section 9.4.1 of [TR102045]. 3.6 Extended Signature Policy Extensions Additional information MAY be added to: * the overall extended signature policy structure, as defined in section 3.1; * the extended signature policy identifier structure, as defined in section 3.2; * the validation policy structure, as defined in section 3.3; * the signature structure, as defined in section 3.3.1; * the extended signature context structure, as defined in section 3.4. These extensions to the structures of the extended signature policy must be defined using 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 [X.690]) 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. Validity Conditions For validation purposes, it could be used any tree matching algorithm, or a different approach, capable of verifying the correctness and validity of a set of signatures against the requirements imposed in the extended signature policy, and, in particular, the trees of signatures defined in the tree of solutions field. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 14] Internet Draft Extended Electronic Signature Policies December 2010 In this sense, a set of signatures (SSi) is compliant with an extended signature policy if at least one tree of signatures (TSi) is completely satisfied. A TSi is satisfied if the number of signatures in the SSi and nodes in one TSi are the same, and the structure of both graphs is the same (homomorphic graphs). Besides, after having applied the validation algorithm, every signature of SSi MUST be mapped to only one node of the satisfied TSi, every node of such TSi MUST be mapped to only one signature of SSi, and no signature of SSi nor node of TSi MUST be without a mapping. The SSi can be complete - every signature needed to complete the transaction has been generated (TSi completely satisfied) - or incomplete - there are still some required signatures left (TSi partially satisfied). Besides, every signature of the SSi MUST be validated against the rules imposed in the signature policy to which it adheres. 5. Integration in AdES formats Advanced Electronic Signature Formats (AdES) like CAdES [RFC5126] have adopted the inclusion of the signature policy reference as a signed attribute in their EPES version. By signing over the signature policy identifier, the signer explicitly indicates that he has applied the signature policy in creating the signature. The verifier is also able to retrieve the referenced signature policy content and thus validate the signature accordingly. In order to unambiguously identify the referenced signature policy that is to be used to verify the signature, the signed attribute includes an identifier unique in the domain of the signature policy issuer and a hash of the signature policy document. In order to support the usage of extended signature policies in the same way, signed attribute extended-signature-policy-identifier is defined. The object identifier for this attribute is: id-aa-ets-extSigPolicyId OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 49 } extended-signature-policy-identifier attribute values have ASN.1 type SignaturePolicyIdentifier, as defined in [RFC5126]: ExtSignaturePolicyIdentifier ::= SignaturePolicyIdentifier SignaturePolicyIdentifier ::= CHOICE { SignaturePolicyId SignaturePolicyId, SignaturePolicyImplied SignaturePolicyImplied } Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 15] Internet Draft Extended Electronic Signature Policies December 2010 SignaturePolicyId ::= SEQUENCE { sigPolicyId SigPolicyId, sigPolicyHash SigPolicyHash, sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL} SignaturePolicyImplied ::= NULL 6. Security Considerations 6.1 Protection of Private Key The reliability of an electronic signature highly depends on the diligence to protect the privacy and access to the signer's private key. Implementations must take steps to ensure, with a sufficient level of guarantee, that private keys cannot be compromised or used without proper authorization. 6.2 Extended Signature Policy Protection When a signer or verifier obtains a copy of the extended signature policy (ext-SP) from an issuer, the source SHOULD be authenticated and the integrity of the ext-SP content verified. For this purpose, it is RECOMMENDED to use the field extSignPolicyProtection. Otherwise, other means SHOULD be used to assure the integrity and authenticity of the ext-SP. It is RECOMMENDED to use digital signatures to adequately protect the ext-SP. A hash value calculated over the policy content does not prevent an attacker from modifying it if the ext-SP is transmitted through insecure means, like a TCP/IP connection without SSL/TLS. If a protected and authenticated channel is used, the hash value MAY be used by the signer to verify the integrity of the policy content by: - Performing his own computation of the hash on the DER encoding of the extSignPolicyInfo field, and using the hash algorithm indicated in the field protectionAlg indicated in the extSignPolicyProtection field. - Verifying that the value obtained matches the value encoded in the protection field of the extSignPolicyProtection. Besides, when the signer references an extended 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 document that the extended signature policy value computes to one, and only one hash value using the specified hash algorithm. This means that there must be a single binary value of the encoded form of the extended 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 Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 16] Internet Draft Extended Electronic Signature Policies December 2010 calculated which is fixed and definitive for a particular extended signature policy. 7. IANA Considerations This document has no actions for IANA. 8. References 8.1. Normative References [X.690] ITU-T Recommendation X.690. Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). 2002. [TR102045] ETSI Technical Report TR 102 045 V.1.1.1 (2003-03) Electronic Signatures and Infrastructures (ESI); Signature policy for extended business model. Note: copies of ETSI TS 101 733 can be freely download from the ETSI web site www.etsi.org. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5280] Cooper, D., Santesson, S., Farrel, S., Boeyen, S., Housley, R., and Polk, W., "Internet X.509 Public Key Infrastructure. Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. 8.2. Informative References [RFC3125] Ross, J., Pinkas, D., and Pope, N., "Electronic Signature Policies", RFC 3125, September 2001. [RFC5126] Pinkas, D., Pope, N., and Ross, J., "CMS Advanced Electronic Signatures (CAdES)", RFC 5126, February 2008. [HAGTRR09] Hernandez-Ardieta, J. L., Gonzalez-Tablas, A. I., Ramos, B., and Ribagorda, A., "Extended Electronic Signature Policies", In Proceedings of the 2nd ACM International Conference on Security of Information and Networks (SIN 2009), pp. 268-277, ACM Press, 2009. Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 17] Internet Draft Extended Electronic Signature Policies December 2010 9. Authors' Addresses This Internet Draft has been produced by the next authors. Jorge Lopez Hernandez-Ardieta University Carlos III of Madrid Av. de la Universidad, 30. 28911, Leganes (Madrid) SPAIN EMail: jlhernan@inf.uc3m.es Ana Isabel Gonzalez-Tablas Ferreres University Carlos III of Madrid Av. de la Universidad, 30. 28911, Leganes (Madrid) SPAIN EMail: aigonzal@inf.uc3m.es Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 18] Internet Draft Extended Electronic Signature Policies December 2010 Annex A (normative): ASN.1 Definitions Using X.680 1997 ASN.1 Syntax This annex provides the reference definition of the ASN.1 syntax for extended electronic signature policies definitions. ETS-ExtendedElectronicSignaturePolicies-97Syntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 30 } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS All IMPORTS -- ===================================================================== -- Internet X.509 Public Key Infrastructure-Certificate and CRL Profile -- RFC 2459 or RFC 3280 or RFC 5280 -- ===================================================================== AlgorithmIdentifier, GeneralNames, DirectoryString FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)} -- ===================================================================== -- CAdES: RFC 5126 -- ===================================================================== SigPolicyQualifierInfo FROM PKIXCAdES08 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 15 } -- ===================================================================== -- Electronic Signature Policies : RFC 3125 -- ===================================================================== SelectedCommitmentTypes, SigningPeriod, SignPolExtensions, DeltaTime FROM ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8} ; Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 19] Internet Draft Extended Electronic Signature Policies December 2010 -- ===================================================================== -- 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-spq OBJECT IDENTIFIER ::= { id-smime 5 } signature policy qualifier id-cti OBJECT IDENTIFIER ::= { id-smime 6 } commitment type identifier -- ===================================================================== -- ===================================================================== -- Extended Signature Policy Specification -- ===================================================================== ExtSignaturePolicy ::= SEQUENCE { extSignPolicyInfo ExtSignPolicyInfo, extSignPolicyProtection ExtSignPolicyProtection OPTIONAL } ExtSignPolicyInfo ::= SEQUENCE { extSignPolicyIdentifier ExtSignPolicyIdentifier, extSignValidationPolicy ExtSignValidationPolicy, extSignContext [0] ExtSignContext OPTIONAL, extSignPolExtensions [1] SignPolExtensions OPTIONAL } ExtSignPolicyProtection ::= SEQUENCE { protectionAlg AlgorithmIdentifier, protection BIT STRING } ExtSignPolicyIdentifier ::= SEQUENCE { extSignPolicyId ExtSignPolicyId, dateOfIssue GeneralizedTime, policyIssuerName GeneralNames, extSigPolicyQualifiers [0] SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL, extSignPolExtensions [1] SignPolExtensions OPTIONAL } ExtSignPolicyId ::= OBJECT IDENTIFIER Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 20] Internet Draft Extended Electronic Signature Policies December 2010 ExtSignValidationPolicy ::= SEQUENCE { signingPeriod [0] SigningPeriod, treesOfSolutions [1] TreesOfSolutions, extSignPolExtensions [2] SignPolExtensions OPTIONAL } TreesOfSolutions ::= SEQUENCE OF treeOfSignature TreeOfSignatures TreeOfSignatures ::= SEQUENCE OF signature Signature Signature ::= SEQUENCE { identifier INTEGER (0..MAX), signer INTEGER (0..MAX), acceptableSignPolicies AcceptableSignPolicies, allowedCommitmentTypes SelectedCommitmentTypes, counterSignatures [0] TreeOfSignatures OPTIONAL, timingAndSequence [1] TimingAndSequence OPTIONAL, extSignPolExtensions [2] SignPolExtensions OPTIONAL } AcceptableSignPolicies ::= SEQUENCE OF signPolicyId SignPolicyId SignPolicyId ::= OBJECT IDENTIFIER TimingAndSequence ::= CHOICE { absoluteTimingAndSequence [0] SigningPeriod, relativeTimingAndSequence [1] SEQUENCE OF RelativeTimingAndSequence } RelativeTimingAndSequence ::= SEQUENCE { pathToRefSignature SEQUENCE OF INTEGER, maxDelta DeltaTime OPTIONAL } ExtSignContext ::= SEQUENCE { businessApplicationDomain [0] SigPolicyQualifierInfo OPTIONAL, transactionalContext [1] SigPolicyQualifierInfo OPTIONAL, disputeResolution [2] SigPolicyQualifierInfo OPTIONAL, audienceConditions [3] SigPolicyQualifierInfo OPTIONAL, extSignPolExtensions [4] SignPolExtensions OPTIONAL } END -- ETS-ExtendedElectronicSignaturePolicies-97Syntax -- Hernandez-Ardieta, et al. Expires June 26, 2011 [Page 21]