idnits 2.17.1 draft-ietf-smime-cades-05.txt: -(1637): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6690. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 26 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([4], [5], [TS101733]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1531: '...fication process MUST be the signer's ...' RFC 2119 keyword, line 1536: '...gningCertificate MUST be the key used ...' RFC 2119 keyword, line 1590: '... MUST be used if the SHA-1 hashing...' RFC 2119 keyword, line 1593: '... Adding CertID Algorithm Agility�, RFC 5035 [15] which SHALL be...' RFC 2119 keyword, line 1688: '...SEQUENCE OF PolicyInformation OPTIONAL...' (49 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC3126, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1750 has weird spacing: '...icyHash max b...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2007) is 6061 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ISO13888-1' is mentioned on line 534, but not defined == Missing Reference: 'CWA 14171' is mentioned on line 1097, but not defined == Missing Reference: 'RFC 2634' is mentioned on line 1589, but not defined == Missing Reference: '0' is mentioned on line 4089, but not defined == Missing Reference: 'RFC2743' is mentioned on line 6218, but not defined == Missing Reference: 'ISO9796' is mentioned on line 6534, but not defined == Missing Reference: 'ISO 15946-3' is mentioned on line 6582, but not defined == Unused Reference: 'TS102023' is defined on line 3149, but no explicit reference was found in the text == Unused Reference: 'ISO15946-3' is defined on line 3233, but no explicit reference was found in the text == Unused Reference: 'X690' is defined on line 3239, but no explicit reference was found in the text == Unused Reference: 'CWA14171' is defined on line 3242, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (ref. '2') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2560 (ref. '3') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3852 (ref. '4') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 3281 (ref. '13') (Obsoleted by RFC 5755) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2437 (Obsoleted by RFC 3447) -- Obsolete informational reference (is this intentional?): RFC 2510 (Obsoleted by RFC 4210) -- Obsolete informational reference (is this intentional?): RFC 2559 (Obsoleted by RFC 3494) -- Obsolete informational reference (is this intentional?): RFC 2587 (Obsoleted by RFC 4523) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group D.Pinkas (Bull SAS) 2 INTERNET-DRAFT N.Pope (Thales eSecurity) 3 Expires March 2008 J.Ross (Security and Standards) 4 Obsoletes: RFC 3126 September 2007 5 Target Category: Informational 7 CMS Advanced Electronic Signatures (CAdES) 8 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 Months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document defines the format of an electronic signature that can 41 remain valid over long periods. This includes evidence as to its 42 validity even if the signer or verifying party later attempts to deny 43 (i.e., repudiates the validity of the signature). 45 The format can be considered as an extension to RFC 3852 [4] and 46 RFC 2634 [5], where, when appropriate additional signed and 47 unsigned attributes have been defined. 49 The contents of this Informational RFC amounts to a 50 transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced 51 Electronic Signatures - CAdES) [TS101733] and is technically 52 equivalent to it. 54 Internet-draft CMS Advanced Electronic Signatures September 2007 56 Table of Contents 58 1. Introduction 6 60 2. Scope 6 62 3. Definitions and abbreviations 8 63 3.1 Definitions 8 64 3.2 Abbreviations 11 66 4. Overview 12 67 4.1 Major parties 12 68 4.2 Signatures policies 14 69 4.3 Electronic signature formats 14 70 4.3.1 CAdES Basic Electronic Signature (CAdES-BES) 14 71 4.3.2 CAdES Explicit Policy Electronic Signatures (CAdES-EPES) 17 72 4.4 Electronic signature formats with validation data 18 73 4.4.1 Electronic Signature with Time (CAdES-T) 19 74 4.4.2 ES with Complete validation data references (CAdES-C) 20 75 4.4.3 Extended electronic signature formats 22 76 4.4.4 Archival Electronic Signature (CAdES-A) 26 77 4.5 Arbitration 27 78 4.6 Validation process 28 80 5. Electronic signature attributes 29 81 5.1 General syntax 29 82 5.2 Data content type 29 83 5.3 Signed-data content type 29 84 5.4 SignedData type 29 85 5.5 EncapsulatedContentInfo type 30 86 5.6 SignerInfo type 30 87 5.6.1 Message digest calculation process 31 88 5.6.2 Message signature generation process 31 89 5.6.3 Message signature verification process 31 90 5.7 Basic ES mandatory present attributes 31 91 5.7.1 Content type 31 92 5.7.2 Message digest 32 93 5.7.3 Signing certificate reference attribute 32 94 5.8 Additional mandatory attributes for Explicit Policy-based 95 Electronic Signatures 34 96 5.8.1 Signature policy identifier 34 97 5.9 CMS imported optional attributes 36 98 5.9.1 Signing time 36 99 5.9.2 Countersignature 36 100 5.10 ESS imported optional attributes 37 101 5.10.1 Content reference attribute 37 102 5.10.2 Content identifier attribute 37 103 5.10.3 Content hints attribute 37 104 Internet-draft CMS Advanced Electronic Signatures September 2007 106 5.11 Additional optional attributes defined in the present document 38 107 5.11.1 Commitment type indication attribute 38 108 5.11.2 Signer location attribute 40 109 5.11.3 Signer attributes attribute 40 110 5.11.4 Content time-stamp 41 111 5.12 Support for multiple signatures 41 112 5.12.1 Independent signatures 41 113 5.12.2 Embedded signatures 42 115 6. Additional Electronic Signature validation attributes 42 116 6.1 Electronic Signature Time-stamped (CAdES-T) 43 117 6.1.1 Signature time- stamp attribute definition 44 118 6.2 Complete validation reference data (CAdES-C) 44 119 6.2.1 Complete certificate references attribute definition 45 120 6.2.2 Complete Revocation References attribute definition 45 121 6.2.3 Attribute certificate references attribute definition 47 122 6.2.4 Attribute revocation references attribute definition 48 123 6.3 Extended validation data (CAdES-X) 48 124 6.3.1 Time-stamped validation data (CAdES-X Type 1 or Type 2) 48 125 6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2) 48 126 6.3.3 Certificate values attribute definition 49 127 6.3.4 Revocation values attribute definition 50 128 6.3.5 CAdES-C time-stamp attribute definition 51 129 6.3.6 Time-stamped certificates and crls references attribute 130 definition 52 131 6.4 Archive validation data 53 132 6.4.1 Archive time-stamp attribute definition 53 134 7. Other standard data structures 55 135 7.1 Public-key certificate format 55 136 7.2 Certificate revocation list format 55 137 7.3 OCSP response format 55 138 7.4 Time-stamp token format 55 139 7.5 Name and attribute formats 55 140 7.6 Attribute certificate 56 142 8. Conformance requirements 56 143 8.1 CAdES-Basic Electronic Signature (CAdES-BES) 56 144 8.2 CAdES-Explicit Policy-based Electronic Signature 57 145 8.3 Verification using time-stamping 57 146 8.4 Verification using secure records 58 148 9. Security considerations 58 149 9.1 Protection of private key 58 150 9.2 Choice of algorithms 58 152 10. IANA Considerations 59 154 11. References 59 155 11.1 Normative references 58 156 11.2 Informative references 60 158 12. Authors' addresses 62 159 Internet-draft CMS Advanced Electronic Signatures September 2007 161 13. Acknowledgments 63 163 Annex A (normative): ASN.1 definitions 64 164 A.1 Signature format definitions using X.208 ASN.1 syntax 64 165 A.2 Signature format definitions using X.680 ASN.1 syntax 72 167 Annex B (informative): Extended forms of Electronic Signatures 81 168 B.1 Extended forms of validation data 81 169 B.1.1 CAdES-X Long 82 170 B.1.2 CAdES-X Type 1 83 171 B.1.3 CAdES-X Type 2 84 172 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 85 173 B.2 Timestamp extensions 87 174 B.3 Archive validation data (CAdES-A) 88 175 B.4 Example validation sequence 90 176 B.5 Additional optional features 95 178 Annex C (informative):General description 96 179 C.1 The signature policy 96 180 C.2 Signed information 97 181 C.3 Components of an electronic signature 97 182 C.3.1 Reference to the signature policy 97 183 C.3.2 Commitment type indication 98 184 C.3.3 Certificate identifier from the signer 98 185 C.3.4 Role attributes 99 186 C.3.4.1 Claimed role 99 187 C.3.4.2 Certified role 100 188 C.3.5 Signer location 100 189 C.3.6 Signing time 100 190 C.3.7 Content format 101 191 C.3.8 Content hints 101 192 C.3.9 Content cross referencing 101 193 C.4 Components of validation data 101 194 C.4.1 Revocation status information 101 195 C.4.1.1 CRL information 102 196 C.4.1.2 OCSP information 102 197 C.4.2 Certification path 103 198 C.4.3 Time-stamping for long life of signatures 103 199 C.4.4 Time-stamping for long life of signature before CA key 200 compromises 104 201 C.4.4.1 Time-stamping the ES with complete validation data 105 202 C.4.4.2 Time-stamping certificates and revocation information 203 references 106 204 C.4.5 Time-stamping for archive of signature 107 205 C.4.6 Reference to additional data 108 206 C.4.7 Time-stamping for mutual recognition 108 207 C.4.8 TSA key compromise 109 208 C.5 Multiple signatures 109 210 Annex D (informative):Data protocols to interoperate with TSPs 110 211 D.1 Operational protocols 110 212 D.1.1 Certificate retrieval 110 213 D.1.2 CRL retrieval 110 214 Internet-draft CMS Advanced Electronic Signatures September 2007 216 D.1.3 OnLine certificate status 110 217 D.1.4 Time-stamping 110 218 D.2 Management protocols 110 219 D.2.1 Request for certificate revocation 110 221 Annex E (informative): Guidance on naming 111 222 E.1 Allocation of names 111 223 E.2 Providing access to registration information 111 224 E.3 Naming schemes 112 225 E.3.1 Naming schemes for individual citizens 112 226 E.3.2 Naming schemes for employees of an organization 113 228 Annex F (informative): Example structured contents and MIME 114 229 F.1 General description 114 230 F.2 Header information 114 231 F.3 Content encoding 116 232 F.4 Multi-part content 116 233 F.5 S/MIME 116 235 Annex G (informative): Relationship to the European Directive 236 And EESSI 119 237 G.1 Introduction 119 238 G.2 Electronic signatures and the directive 119 239 G.3 ETSI electronic signature formats and the directive 120 240 G.4 EESSI standards and classes of electronic signature 120 241 G.4.1 Structure of EESSI standardization 120 242 G.4.2 Classes of electronic signatures 121 243 G.4.3 EESSI classes and the ETSI electronic signature format 121 245 Annex H (informative): APIs for the generation and verification 246 of electronic signatures tokens 121 247 H.1 Data framing 122 248 H.2 IDUP-GSS-APIs defined by the IETF 123 249 H.3 CORBA security interfaces defined by the OMG 124 251 Annex I (informative):Cryptographic algorithms 126 252 I.1 Digest algorithms 126 253 I.1.1 SHA-1 126 254 I.1.2 General 126 255 I.2 Digital signature algorithms 127 256 I.2.1 DSA 127 257 I.2.2 RSA 127 258 I.2.3 General 128 260 Annex J (informative): Changes from the previous version 130 262 Full Copyright Statement 131 264 Disclaimer 131 266 Intellectual Property 131 267 Internet-draft CMS Advanced Electronic Signatures September 2007 269 1. Introduction 271 This document is intended to cover electronic signatures for various 272 types of transactions, including business transactions (e.g. purchase 273 requisition, contract, and invoice applications) where long term 274 validity of such signatures is important. This includes evidence as 275 to its validity even if the signer or verifying party later attempts 276 to deny (i.e., repudiates, see ISO/IEC 10181-5 [ISO10181-5]) the 277 validity of the signature). 279 Thus the present document can be used for any transaction between an 280 individual and a company, between two companies, between an individual 281 and a governmental body, etc. The present document is independent of 282 any environment. It can be applied to any environment e.g. smart cards, 283 GSM SIM cards, special programs for electronic signatures, etc. 285 The European Directive on a community framework for Electronic 286 Signatures defines an electronic signature as: "Data in electronic form 287 which is attached to or logically associated with other electronic data 288 and which serves as a method of authentication". 290 An electronic signature as used in the present document is a form 291 of advanced electronic signature as defined in the Directive. 293 2. Scope 295 The scope of the present document covers Electronic Signature Formats 296 only. The aspects of Electronic Signature Policies are defined in 297 RFC 3125 [RFC3125] and in ETSI TR 102 272 [TR102272]. 299 The present document defines a number of Electronic Signature Formats, 300 including electronic signature that can remain valid over long periods. 301 This includes evidence as to its validity even if the signer or 302 verifying party later attempts to deny (repudiates) the validity of the 303 electronic signature. 305 The present document specifies use of trusted service providers (e.g. 306 Time-Stamping Authorities), and the data that needs to be archived 307 (e.g. cross certificates and revocation lists) to meet the requirements 308 of long term electronic signatures. 310 An electronic signature defined by the present document can be used for 311 arbitration in case of a dispute between the signer and verifier, which 312 may occur at some later time, even years later. 314 The present document includes the concept of signature policies that 315 can be used to establish technical consistency when validating 316 electronic signatures but does not mandate their use. 318 Internet-draft CMS Advanced Electronic Signatures September 2007 320 The present document is based on the use of public key cryptography to 321 produce digital signatures, supported by public key certificates. 322 The present document also specifies the use of time-stamping and time- 323 marking services to prove the validity of a signature long after the 324 normal lifetime of critical elements of an electronic signature. It 325 also, as an option, defines ways to provide very long-term protection 326 against key compromise or weakened algorithms. 328 The present document builds on existing standards that are widely 329 adopted. This includes: 331 - RFC 3852 [4] "Cryptographic Message Syntax (CMS)"; 333 - ISO/IEC 9594-8/ITU-T Recommendation X.509 [1]: "Information 334 technology - Open Systems Interconnection - The Directory: 335 Authentication framework"; 337 - RFC 3280 [2] "Internet X.509 Public Key Infrastructure (PKIX) 338 Certificate and CRL Profile"; 340 - RFC 3161 [7] "Internet X.509 Public Key Infrastructure Time-Stamp 341 Protocol". 343 NOTE: See section 11 for a full set of references. 345 The present document describes formats for advanced electronic 346 signatures using ASN.1 (Abstract Syntax Notation 1) [14]. ASN.1 347 is encoded using X.209 [X.209]. 349 These formats are based on CMS (Cryptographic Message Syntax) defined 350 in RFC 3852 [4]. These electronic signatures are thus called CAdES, 351 for "CMS Advanced Electronic Signatures". 353 Another document, TS 101 903 [TS101903], describes formats for XML 354 advanced electronic signatures (XAdES) built on XMLDSIG [XMLDSIG]. 356 In addition, the present document identifies other documents that 357 define formats for Public Key Certificates, Attribute Certificates, 358 Certificate Revocation Lists and supporting protocols, including, 359 protocols for use of trusted third parties to support the operation of 360 electronic signature creation and validation. 362 Internet-draft CMS Advanced Electronic Signatures September 2007 364 Informative annexes include: 366 - illustrations of extended forms of extended Electronic Signatures 367 formats that protect against various vulnerabilities and examples 368 of validation processes (Annex B); 370 - descriptions and explanations of some of the concepts used in the 371 present document, giving a rationale for normative parts of the 372 present document (Annex C); 374 - information on protocols to interoperate with Trusted Service 375 Providers (Annex D); 377 - guidance on naming (Annex E); 379 - an example structured content and MIME (Annex F); 381 - the relationship between the present document and the directive 382 on electronic signature and associated standardization 383 initiatives (Annex G); 384 - APIs to support the generation and the verification of electronic 385 signatures (Annex H); 387 - cryptographic algorithms that may be used (Annex I); and 389 - changes from the previous version (see Annex J). 391 3 Definitions and abbreviations 393 3.1 Definitions 395 For the purposes of the present document, the following terms and 396 definitions apply: 398 Arbitrator: arbitrator entity may be used to arbitrate a dispute 399 between a signer and verifier when there is a disagreement on the 400 validity of a digital signature. 402 Attribute Authority (AA): authority which assigns privileges by issuing 403 attribute certificates. 405 Authority certificate: certificate issued to an authority (e.g. either 406 to a certification authority or to an attribute authority). 408 Attribute Authority Revocation List (AARL): revocation list containing 409 a list of references to certificates issued to AAs, that are no longer 410 considered valid by the issuing authority. 412 Internet-draft CMS Advanced Electronic Signatures September 2007 414 Attribute Certificate Revocation List (ACRL): revocation list 415 containing a list of references to attribute certificates that are no 416 longer considered valid by the issuing authority. 418 Certification Authority Revocation List (CARL): revocation list 419 containing a list of public-key certificates issued to certification 420 authorities, that are no longer considered valid by the certificate 421 issuer. 422 Certification Authority (CA): authority trusted by one or more users to 423 create and assign public key certificates, optionally the certification 424 authority may create the users' keys. 426 NOTE: See ITU-T Recommendation X.509 [1]. 428 Certificate Revocation List (CRL): signed list indicating a set of 429 public key certificates that are no longer considered valid by the 430 certificate issuer. 432 Digital signature: data appended to, or a cryptographic transformation 433 of, a data unit that allows a recipient of the data unit to prove the 434 source and integrity of the data unit and protect against forgery, e.g. 435 by the recipient. 437 NOTE: See ISO 7498-2 [ISO7498-2]. 439 Electronic signature: data in electronic form which are attached to or 440 logically associated with other electronic data and which serve as a 441 method of authentication. 443 NOTE: See Directive 1999/93/EC of the European Parliament and of the 444 Council of 13 December 1999 on a Community framework for 445 electronic signatures [EU Directive]. 447 Enhanced electronic signatures: electronic signatures enhanced by 448 complementing the baseline requirements with additional data, such as 449 time tamp tokens and certificate revocation data, to address commonly 450 recognized threats. 452 Explicit Policy-based Electronic Signature (EPES): an electronic 453 signature where the signature policy is explicitly specified that shall 454 be used to validate it. 456 Grace period: time period which permits the certificate revocation 457 information to propagate through the revocation process to relying 458 parties. 460 Initial verification: a process performed by a verifier done after an 461 electronic signature is generated in order to capture additional 462 information that could make it valid for long term verification. 464 Internet-draft CMS Advanced Electronic Signatures September 2007 466 Public Key Certificate (PKC): public keys of a user, together with some 467 other information, rendered unforgeable by encipherment with the 468 private key of the certification authority which issued it. 470 NOTE: See ITU-T Recommendation X.509 [1]. 472 Rivest-Shamir-Adleman (RSA): asymmetric cryptography algorithm based on 473 the difficulty to factor very large numbers, using a key pair: a 475 private key and a public key. 477 Signature policy: set of rules for the creation and validation of an 478 electronic signature, that defines the technical and procedural 479 requirements for electronic signature creation and validation, in order 480 to meet a particular business need, and under which the signature can 481 be determined to be valid. 483 Signature policy issuer: entity that defines and issues a signature 484 policy. 486 Signature validation policy: part of the signature policy which 487 specifies the technical requirements on the signer in creating a 488 signature and verifier when validating a signature. 490 Signer: entity that creates an electronic signature. 492 Subsequent Verification: a process performed by a verifier to assess 493 the signature validity. 495 NOTE: It may be done even years after the electronic signature was 496 produced by the signer and completed by the Initial 497 Verification and it might not need to capture more data than 498 those captured at the time of initial verification. 500 Time-Stamp token: data object that binds a representation of a datum to 501 a particular time, thus establishing evidence that the datum existed 502 before that time. 504 Time-Mark: information in an audit trail from a Trusted Service 505 Provider that binds a representation of a datum to a particular time, 506 thus establishing evidence that the datum existed before that time. 508 Time-Marking Authority: trusted third party that creates records in an 509 audit trail in order to indicate that a datum existed before a 510 particular point in time. 512 Time-Stamping Authority (TSA): trusted third party that creates time- 513 stamp tokens in order to indicate that a datum existed at a particular 514 point in time. 516 Internet-draft CMS Advanced Electronic Signatures September 2007 518 Time-Stamping Unit (TSU): set of hardware and software which is managed 519 as a unit and has a single time-stamp token signing key active at a 520 time. 522 Trusted Service Provider (TSP): entity that helps to build trust 523 relationships by making available or providing some information upon 524 request. 526 Validation data: additional data that may be used by a verifier of 527 electronic signatures to determine the signature is valid. 529 Valid electronic signature: electronic signature which passes 530 validation. 532 Verifier: entity that verifies evidence. 534 NOTE 1: See ISO/IEC 13888-1 [ISO13888-1]. 536 NOTE 2: Within the context of the present document this is an entity 537 that validates an electronic signature. 539 3.2 Abbreviations 541 For the purposes of the present document, the following abbreviations 542 apply: 544 AA Attribute Authority 546 AARL Attribute Authority Revocation List 547 ACRL Attribute Certificate Revocation List 548 API Application Program Interface 549 ASCII American Standard Code for Information Interchange 550 ASN.1 Abstract Syntax Notation 1 551 CA Certification Authority 552 CAD Card Accepting Device 553 CAdES CMS Advanced Electronic Signature 554 CAdES-A CAdES with Archive validation data 555 CAdES-BES CAdES Basic Electronic Signature 556 CAdES-C CAdES with Complete validation data 557 CAdES-EPES CAdES Explicit Policy Electronic Signature 558 CAdES-T CAdES with Time-stamp 559 CAdES-X CAdES with eXtended validation data 560 CARL Certification Authority Revocation List 561 CMS Cryptographic Message Syntax 562 CRL Certificate Revocation List 563 CWA CEN Workshop Agreement 564 DER Distinguished Encoding Rules (for ASN.1) 565 DSA Digital Signature Algorithm 566 EDIFACT Electronic Data Interchange For Administration, Commerce 567 and Transport 569 Internet-draft CMS Advanced Electronic Signatures September 2007 571 EESSI European Electronic Signature Standardization Initiative 572 EPES Explicit Policy-based Electronic Signature 573 ES Electronic Signature 574 ESS Enhanced Security Services (enhances CMS) 575 IDL Interface Definition Language 576 MIME Multipurpose Internet Mail Extensions 577 OCSP Online Certificate Status Provider 578 OID Object IDentifier 579 PKC Public Key Certificate 580 PKIX Public Key Infrastructure using X.509 (IETF Working Group) 581 RSA Rivest-Shamir-Adleman 582 SHA-1 Secure Hash Algorithm 1 583 TSA Time-Stamping Authority 584 TSP Trusted Service Provider 585 TST Time-Stamp Token 586 TSU Time-Stamping Unit 587 URI Uniform Resource Identifier 588 URL Uniform Resource Locator 589 XML eXtended Mark up Language 590 XMLDSIG XML-Signature Syntax and Processing 592 4 Overview 594 The present document defines a number of Electronic Signature (ES) 595 formats that build on CMS (RFC 3852 [4]) by adding signed and unsigned 596 attributes. 598 This section provides an introduction to the major parties involved 599 (section 4.1), the concept of Signature Policies (section 4.2), provides 600 an overview of the various ES formats (section 4.3), introduces the 601 concept of validation data and provides an overview of formats that 602 incorporate validation data (section 4.4), presents relevant 603 considerations on arbitration (section 4.5) and for the validation 604 process (section 4.6). 606 The formal specifications of the attributes are specified in sections 5 607 and 6, annexes C and D provide rationale for the definitions of the 608 different ES forms. 610 4.1 Major parties 612 The major parties involved in a business transaction supported by 613 electronic signatures as defined in the present document are: 615 - the Signer; 616 - the Verifier; 617 - Trusted Service Providers (TSP); and 618 - the Arbitrator. 620 Internet-draft CMS Advanced Electronic Signatures September 2007 622 The signer is the entity that creates the electronic signature. When 623 the signer digitally signs over data using the prescribed format, this 624 represents a commitment on behalf of the signing entity to the data 625 being signed. 627 The verifier is the entity that validates the electronic signature, it 628 may be a single entity or multiple entities. 630 The Trusted Service Providers (TSPs) are one or more entities that help 631 to build trust relationships between the signer and verifier. They 632 support the signer and verifier by means of supporting services 633 including: user certificates, cross-certificates, time-stamp tokens, 634 CRLs, ARLs, OCSP responses. The following TSPs are used to support the 635 functions defined in the present document: 637 - Certification Authorities; 638 - Registration Authorities; 639 - CRL Issuers; 640 - OCSP Responders; 641 - Repository Authorities (e.g. a Directory); 642 - Time-Stamping Authorities; 643 - Time-Marking Authorities; and 644 - Signature Policy Issuers. 646 Certification Authorities provide users with public key certificates 647 and with a revocation service. 649 Registration Authorities allow the identification and registration of 650 entities before a CA generates certificates. 652 Repository Authorities publish CRLs issued by CAs, signature policies 653 issued by Signature Policy Issuers and optionally public key 654 certificates. 656 Time-Stamping Authorities attest that some data was formed before a 657 given trusted time. 659 Time-Marking Authorities record that some data was formed before a 660 given trusted time. 662 Signature Policy Issuers define the signature policies to be used by 663 signers and verifiers. 665 In some cases the following additional TSPs are needed: 667 - Attribute Authorities. 669 Attributes Authorities provide users with attributes linked to public 670 key certificates. 672 An Arbitrator is an entity that arbitrates in disputes between a signer 673 and a verifier. 675 Internet-draft CMS Advanced Electronic Signatures September 2007 677 4.2 Signatures policies 679 The present document includes the concept of signature policies that 680 can be used to establish technical consistency when validating 681 electronic signatures. 683 When a comprehensive signature policy used by the verifier is either 684 explicitly indicated by the signer or implied by the data being signed, 685 then a consistent result can be obtained when validating an electronic 686 signature. 688 When the signature policy being used by the verifier is neither 689 indicated by the signer nor can be derived from other data, or the 690 signature policy is incomplete then verifiers, including arbitrators, 691 may obtain different results when validating an electronic signature. 692 Therefore, comprehensive signature policies that ensure consistency of 693 signature validation are recommended from both the signers and 694 verifiers point of view. 696 Further information on signature policies is provided in: 698 - TR 102 038 [TR102038]; 699 - sections 5.8.1, C.1 and C.3.1 of the present document; 700 - RFC 3125 [RFC3125]; and 701 - TR 102 272 [TR102272]. 703 4.3 Electronic signature formats 705 The current document sectionprovides an overview for two forms of CMS 706 advanced electronic signature specified in the present document, 707 namely, the CAdES Basic Electronic Signature (CAdES-BES) and the 708 CAdES Explicit Policy-based Electronic Signature (CAdES-EPES). 709 Conformance to the present document mandates the signer creates one of 710 these formats. 712 4.3.1 CAdES Basic Electronic Signature (CAdES-BES) 714 A CAdES Basic Electronic Signature (CAdES-BES) in accordance with the 715 present contains: 717 - The signed user data (e.g. the signer's document) as defined in 718 CMS (RFC 3852 [4]); 720 - A collection of mandatory signed attributes as defined in CMS 721 (RFC 3852 [4]) and in ESS (RFC 2634 [5]); 723 - Additional mandatory signed attributes defined in the present 724 document; and 726 Internet-draft CMS Advanced Electronic Signatures September 2007 728 - The digital signature value computed on the user data and, when 729 present, on the signed attributes, as defined in CMS (RFC 3852 730 [4]). 732 A CAdES Basic Electronic Signature (CAdES-BES) in accordance with the 733 present document may contain: 735 - a collection of additional signed attributes; and 736 - a collection of optional unsigned attributes. 738 The mandatory signed attributes are: 740 - Content-type. It is defined in RFC 3852 [4] and specifies the 741 type of the EncapsulatedContentInfo value being signed. Details 742 are provided in 5.7.1. Rationale for its inclusion is provided 743 in section C.3.7; 745 - Message-digest. It is defined in RFC 3852 [4] and specifies the 746 message digest of the eContent OCTET STRING within 747 encapContentInfo being signed. Details are provided in section 748 5.7.2; 750 - ESS signing-certificate OR ESS signing-certificate v2. The ESS 751 signing-certificate attribute is defined in Enhanced Security 752 Services (ESS), RFC 2634 [5] and only allows for the use of SHA-1 753 as digest algorithm. The ESS signing-certificate attribute V2 754 is defined in �ESS Update: Adding CertID Algorithm Agility� 755 RFC 5035 [15], and allows for the use of any digest algorithm. 756 A CAdES-BES claiming compliance with the present document must 757 include one of them. Section 5.7.3 provides the details of 758 these attributes. Rationale for its inclusion is provided in 759 section C.3.3. 761 Optional signed attributes may be added to the CAdES-BES, including 762 optional signed attributes defined in CMS (RFC 3852 [4]), ESS (RFC 2634 763 [5]) and the present document. Listed below are optional attributes 764 that are defined in section 5 and have a rational provided in annex C: 766 - Signing-time: as defined in CMS (RFC 3852 [4]) indicates the time 767 of the signature as claimed by the signer. Details and short 768 rationale are provided in section 5.9.1. Section C.3.6 provides 769 the rationale. 771 - Content-hints as defined in ESS (RFC 2634 [5]) provides 772 information that describes the innermost signed content of a 773 multi-layer message where one content is encapsulated in another. 774 Section 5.10.1 provides the specification details. Section C.3.8 775 provides the rationale. 777 - Content-reference. as defined in ESS (RFC 2634 [5]) can be 778 incorporated as a way to link request and reply messages in an 779 exchange between two parties. Section 5.10.1 provides the 780 specification details. Section C.3.9 provides the rationale. 782 Internet-draft CMS Advanced Electronic Signatures September 2007 784 - Content-identifier. as defined in ESS (RFC 2634 [5]) contains an 785 identifier that may be used later on in the previous content- 786 reference attribute. Section 5.10.2 provides the specification 787 details. Section C.3.8 provides the rationale. 789 - Commitment-type-indication. This attribute is defined by the 790 present document as a way to indicate the commitment endorsed by 791 the signer when producing the signature. Section 5.11.1 provides 792 the specification details. Section C.3.2 provides the 793 rationale. 795 - Signer-location. This attribute is defined by the present 796 document. It allows the signer to indicate the place where the 797 signer purportedly produced the signature. Section 5.11.2 798 provides the specification details. Section C.3.5 provides the 799 rationale. 801 - Signer-attributes. This attribute is defined by the present 802 document. It allows a claimed or certified role to be 803 incorporated into the signed information. Section 5.11.3 provides 804 the specification details. Section C.3.4 provides the rationale. 806 - Content-time-stamp. This attribute is defined by the present 807 document. It allows a time-stamp token of the data to be signed 808 to be incorporated into the signed information. It provides 809 proof of the existence of the data before the signature was 810 created. Section 5.11.4 provides the specification details. 811 Section C.3.6 provides the rationale. 813 A CAdES-BES form can also incorporate instances of unsigned attributes 814 as defined in CMS (RFC 3852 [4]) and ESS (RFC 2634 [5]). 816 - CounterSignature, as defined in CMS (RFC 3852 [4]). It can be 817 incorporated wherever embedded signatures (i.e. a signature on 818 a previous signature) are needed. Section 5.9.2 provides the 819 specification details. Section C.5 in annex C provides the 820 rationale. 822 The structure of the CAdES-BES is illustrated in figure 1. 824 +------Elect.Signature (CAdES-BES)------+ 825 |+----------------------------------- + | 826 ||+---------+ +----------+ | | 827 |||Signer's | | Signed | Digital | | 828 |||Document | |Attributes| Signature | | 829 ||| | | | | | 830 ||+---------+ +----------+ | | 831 |+------------------------------------+ | 832 +---------------------------------------+ 834 Figure 1: Illustration of a CAdES-BES 836 Internet-draft CMS Advanced Electronic Signatures September 2007 838 The signer's conformance requirements of a CAdES-BES are defined in 839 section 8.1. 841 NOTE: The CAdES-BES is the minimum format for an electronic signature 842 to be generated by the signer. On its own, it does not 843 provide enough information for it to be verified in the longer 844 term. For example, revocation information issued by the 845 relevant certificate status information issuer needs to be 846 available for long term validation (see section 4.4.2). 848 The CAdES-BES satisfies the legal requirements for electronic 849 signatures as defined in the European Directive on electronic 850 signatures, (see annex C for further discussion on relationship of the 851 present document to the Directive). It provides basic authentication 852 and integrity protection. 854 The semantics of the signed data of a CAdES-BES or its context may 855 implicitly indicate a signature policy to the verifier. Specification 856 of the contents of signature policies is outside the scope of the 857 present document. However, further information on signature policies 858 is provided in TR 102 038 [TR102038], RFC 3125 [RFC3125] and sections 859 5.8.1, C.1 and C.3.1 of the present document. 861 4.3.2 CAdES Explicit Policy Electronic Signatures (CAdES-EPES) 863 A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES) in 864 accordance with the present document, extends the definition of an 865 electronic signature to conform to the identified signature policy. 867 A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES) 868 incorporates a signed attribute (signature-policy-identifier) 869 indicating that a signature policy that is mandatory to use to validate 870 the signature and specifies explicitly the signature policy that shall 871 be used. This signed attribute is protected by the signature. The 872 signature may also have other signed attributes required to conform to 873 the mandated signature policy. 875 Section 5.7.3 provides the details on the specification of signature- 876 policy-identifier attribute. Section C.1 provides a short rationale. 877 Specification of the contents of signature policies is outside the 878 scope of the present document. 880 Further information on signature policies is provided in TR 102 038 881 [TR102038] and sections 5.8.1, C.1 and C.3.1 of the present document. 883 Internet-draft CMS Advanced Electronic Signatures September 2007 885 The structure of the CAdES-EPES is illustrated in figure 2. 887 +------------- Elect.Signature (CAdES-EPES) ---------------+ 888 | | 889 |+-------------------------------------------------------+ | 890 || +-----------+ | | 891 || | | +---------------------------+ | | 892 || | | | +----------+ | | | 893 || | Signer's | | |Signature | Signed | Digital | | 894 || | Document | | |Policy ID | Attributes |Signature| | 895 || | | | +----------+ | | | 896 || | | +---------------------------+ | | 897 || +-----------+ | | 898 |+-------------------------------------------------------+ | 899 | | 900 +----------------------------------------------------------+ 902 Figure 2: Illustration of a CAdES-EPES 904 The signer's conformance requirements of CAdES-EPES are defined in 905 section 8.2. 907 4.4 Electronic signature formats with validation data 909 Validation of an electronic signature in accordance with the present 910 document requires additional data needed to validate the electronic 911 signature. This additional data is called validation data; and 912 includes: 914 - Public Key Certificates (PKCs); 916 - revocation status information for each PKC; 918 - trusted time-stamps applied to the digital signature or a time- 919 mark shall be available in an audit log; and 921 - when appropriate, the details of a signature policy to be used to 922 verify the electronic signature. 924 The validation data may be collected by the signer and/or the verifier. 925 When the signature-policy-identifier signed attribute is present, it 926 shall meet the requirements of the signature policy. 928 Validation data includes CA certificates as well as revocation status 929 information in the form of Certificate Revocation Lists (CRLs) or 930 certificate status information (OCSP) provided by an on-line service. 931 Validation data also includes evidence that the signature was created 932 before a particular point in time this may be either a time-stamp 933 token or time-mark. 935 Internet-draft CMS Advanced Electronic Signatures September 2007 937 The present document defines unsigned attributes able to contain 938 validation data that can be added to CAdES-BES and CAdES-EPES leading 939 to electronic signature formats that include validation data. Sections 940 below summarize these formats and their most relevant characteristics. 942 4.4.1 Electronic Signature with Time (CAdES-T) 944 Electronic Signature with Time (CAdES-T) in accordance with the present 945 document is when there exits trusted time associated with the ES. 947 The trusted time may be provided by: 949 - the signature-time-stamp as an unsigned attribute added to the 950 ES; and 952 - A time mark of the ES provided by a trusted service provider. 954 The signature-time-stamp attribute contains a time-stamp token of the 955 electronic signature value. Section 6.1.1 provides the specification 956 details. Section C.4.3 in provides the rationale. 958 A time-mark provided by a Trusted Service would have similar effect to 959 the signature-time-stamp attribute but in this case no attribute is 960 added to the ES as it is the responsibility of the TSP to provide 961 evidence of a time mark when required to do so. The management of time 962 marks is outside the scope of the present document. 964 Trusted time provides the initial steps towards providing long term 965 validity. Electronic signatures with the time stamp attribute forming 966 the CAdES-T is illustrated in figure 3. 968 +-------------------------------------------------CAdES-T ---------+ 969 |+------ CAdES-BES or CAdES-EPES -------+ | 970 ||+-----------------------------------+ | +----------------------+ | 971 |||+---------+ +----------+ | | | | | 972 ||||Signer's | | Signed | Digital | | | Signature-time-stamp | | 973 ||||Document | |Attributes| Signature | | | attribute required | | 974 |||| | | | | | | when using time | | 975 |||+---------+ +----------+ | | | stamps. | | 976 ||+-----------------------------------+ | | | | 977 |+--------------------------------------+ | or the BES/EPES | | 978 | | shall be time marked | | 979 | | | | 980 | | Management and | | 981 | | provision of time | | 982 | | mark is the | | 983 | | responsibility of | | 984 | | the TSP. | | 985 | +----------------------+ | 986 +------------------------------------------------------------------+ 988 Figure 3: Illustration of CAdES-T formats 990 Internet-draft CMS Advanced Electronic Signatures September 2007 992 NOTE 1 : A time stamp token is added to the CAdES-BES or CAdES-EPES 993 as an unsigned attribute. 995 NOTE 2 : Timestamp tokens that may themselves include unsigned 996 attributes required to validate the timestamp token, such 997 as the complete-certificate-references and complete- 998 revocation-references attributes as defined by the present 999 document. 1001 4.4.2 ES with Complete validation data references (CAdES-C) 1003 Electronic Signature with Complete validation data references (CAdES-C) 1004 in accordance with the present document adds to the CAdES-T the 1005 complete-certificate-references and complete-revocation-references 1006 attributes as defined by the present document. The complete- 1007 certificate-references attribute contain references to all the 1008 certificates present in the certification path used for verifying the 1009 signature. The complete-revocation-references attribute contains 1010 references to the CRLs and/or OCSP responses used for verifying the 1011 signature. Section 6.2 provides the specification details. Storing the 1012 references allows the values of the certification path and the CRLs or 1013 OCSPs responses to be stored elsewhere, reducing the size of a stored 1014 electronic signature format. 1016 Sections C.4.1 to C.4.2 provide rationale on the usage of validation 1017 data and when it is suitable to generate the CAdES-C form. 1018 Electronic signatures with the additional validation data forming the 1019 CAdES-C are illustrated in figure 4. 1021 +------------------------- CAdES-C --------------------------------+ 1022 |+----------------------------- CAdES-T ---------+ | 1023 || +----------+ | +-------------+ | 1024 || |Timestamp | | | | | 1025 || |attribute | | | | | 1026 ||+- CAdES-BES or CAdES-EPES ------+|over | | | | | 1027 ||| ||digital | | | Complete | | 1028 |||+---------++----------+ ||signature | | | certificate | | 1029 ||||Signer's || Signed | Digital ||is | | | and | | 1030 ||||Document ||Attributes|Signature||mandatory | | | revocation | | 1031 |||| || | ||if is not | | | references | | 1032 |||+---------++----------+ ||timemarked| | | | | 1033 ||+--------------------------------++----------+ | | | | 1034 |+-----------------------------------------------+ +-------------+ | 1035 +------------------------------------------------------------------+ 1037 Figure 4: Illustration of CAdES-C format 1039 NOTE 1: The complete certificate and revocation references are added 1040 to the CAdES-T as an unsigned attribute. 1042 Internet-draft CMS Advanced Electronic Signatures September 2007 1044 NOTE 2: As a minimum, the signer will provide the CAdES-BES or when 1045 indicating that the signature conforms to an explicit signing 1046 policy the CAdES-EPES. 1047 NOTE 3: To reduce the risk of repudiating signature creation, the 1048 trusted time indication needs to be as close as possible to 1049 the time the signature was created. The signer or a TSP could 1050 provide the CAdES-T, if not the verifier should create the 1051 CAdES-T on first receipt of an electronic signature because 1052 the CAdES-T provides independent evidence of the existence of 1053 the signature prior to the trusted time indication. 1055 NOTE 4: An CAdES-T trusted time indications must be created before a 1056 certificate has been revoked or expired. 1058 NOTE 5: The signer and TSP could provide the CAdES-C, to minimize 1059 this risk and when the signer does not provide the CAdES-C, 1061 the verifier should create the CAdES-C when the required 1062 component of revocation and validation data become available, 1063 this may require a grace period. 1065 NOTE 6: A grace period permits certificate revocation information to 1066 propagate through the revocation processes. This period could 1067 extend from the time an authorized entity requests certificate 1068 revocation, to when the information is available for the 1069 relying party to use. In order to make sure that the 1070 certificate was not revoked at the time the signature was 1071 time-marked or time-stamped, verifiers should wait until the 1072 end of the grace period. A signature policy may define 1073 specific values for grace periods. 1075 An illustration of a grace period is provided in figure 5. 1077 +<--------------Grace Period --------->+ 1078 ----+-------+-------+--------+---------------------+----------+ 1079 ^ ^ ^ ^ ^ ^ 1080 | | | | | | 1081 | | | | | | 1082 Signature | First | Second | 1083 creation | revocation | revocation | 1084 time | status | status | 1085 | checking | checking | 1086 | | | 1087 Time-stamp Certification Build 1088 or path CAdES-C 1089 time-mark construction 1090 over & verification 1091 signature 1093 Figure 5: Illustration of a grace period 1095 Internet-draft CMS Advanced Electronic Signatures September 2007 1097 NOTE 7: CWA 14171 [CWA 14171] specifies a signature validation 1098 process using CAdES-T, CAdES-C and a grace period. 1099 Annex B provides example validation processes. Section C.4 1100 provides additional information about applying grace periods 1101 during the validation process. 1103 The verifier's conformance requirements are defined in section 8.3 for 1104 time stamped CAdES-C and section 8.4 for time marked CAdES-C. The 1105 present document only defines conformance requirements for the verifier 1106 up to an ES with complete validation data (CAdES-C). This means that 1107 none of the extended and archive forms of Electronic Signature as 1108 defined in sections 4.4.3 to 4.4.4) need to be implemented to achieve 1109 conformance to the present document. 1111 4.4.3 Extended electronic signature formats 1113 CAdES-C can be extended by adding unsigned attributes to the electronic 1114 signature. The present document defines various unsigned attributes 1115 that are applicable for very long term verification, and for preventing 1116 some disaster situations which are discussed in annex C. Annex B 1117 provides the details of the various extended formats, all the required 1118 unsigned attributes for each type and how they can be used within the 1119 electronic signature validation process. The sections below give an 1120 overview of the various forms of extended signature formats in the 1121 present document. 1123 4.4.3.1 EXtended Long Electronic Signature (CAdES-X Long) 1125 Extended Long format (CAdES-X Long) in accordance with the present 1126 document adds to the CAdES-C format the certificate-values and 1127 revocation-values attributes. The first one contains the whole 1128 certificate path required for verifying the signature; the second one 1129 the CRLs and/OCSP responses required for the validation of the 1130 signature. This provides a known repository of certificate and 1131 revocation information required to validate an CAdES-C and prevents 1132 such information getting lost. Sections 6.3.3 and 6.3.4 give 1133 specification details. Section B.1.1 gives details on the production 1134 of the format. Sections C4.1 to C.4.2 provide the rationale. 1136 Internet-draft CMS Advanced Electronic Signatures September 2007 1138 The structure of the CAdES-X Long format is illustrated in figure 6. 1140 +----------------------- CAdES-X-Long -----------------------------+ 1141 |+------------------------------------ CadES-C --+ | 1142 || +----------+ | +-------------+ | 1143 ||+------ CAdES -------------------+|Timestamp | | | | | 1144 ||| || over | | | Complete | | 1145 |||+---------++----------+ ||digital | | | certificate | | 1146 ||||Signer's || Signed | Digital ||signature | | | and | | 1147 ||||Document ||Attributes|Signature|| | | | revocation | | 1148 |||| || | ||Optional | | | data | | 1149 |||+---------++----------+ ||when | | | | | 1150 ||+--------------------------------+|timemarked| | | | | 1151 || +----------+ | | | | 1152 || +-------------+ | +-------------+ | 1153 || | Complete | | | 1154 || | certificate | | | 1155 || | and | | | 1156 || | revocation | | | 1157 || | references | | | 1158 || +-------------+ | | 1159 |+-----------------------------------------------+ | 1160 | | 1161 +------------------------------------------------------------------+ 1163 Figure 6: Illustration of CAdES-X-Long 1165 4.4.3.2 EXtended Electronic Signature with Time Type 1 1166 (CAdES-X Type 1) 1168 Extended format with time type 1 (CAdES-X Type 1) in accordance with 1169 the present document adds to the CAdES-C format the CAdES-C-time-stamp 1170 attribute, whose content is a time-stamp token on the CAdES-C itself. 1172 This provides an integrity and trusted time protection over all the 1173 elements and references. It may protect the certificates, CRLs and 1174 OCSP responses in case of a later compromise of a CA key, CRL key or 1175 OCSP issuer key. Section 6.3.5 provides the specification details. 1177 Section B.1.2 gives details on the production of the time-stamping 1178 process. Sections C.4.4.1 provides the rationale. 1180 Internet-draft CMS Advanced Electronic Signatures September 2007 1182 The structure of the CAdES-X Type 1 format is illustrated in figure 7. 1184 +----------------------- CAdES-X-Type 1 ------------------------------+ 1185 |+-------------------------------------- CAdES-C -----+ | 1186 || +-------------+ | +-----------+ | 1187 ||+--------- CAdES ------------------+| Timestamp | | | | | 1188 ||| || over | | | | | 1189 |||+---------++----------+ || digital | | | | | 1190 ||||Signer's || Signed | Digital || signature | | | Timestamp | | 1191 ||||Document ||Attributes| Signature || | | | over | | 1192 |||| || | || Optional | | | CAdES-C | | 1193 |||+---------++----------+ || when | | | | | 1194 ||+----------------------------------+| time-marked | | | | | 1195 || +-------------+ | | | | 1196 || +-------------+ | +-----------+ | 1197 || | Complete | | | 1198 || | certificate | | | 1199 || | and | | | 1200 || | revocation | | | 1201 || | references | | | 1202 || +-------------+ | | 1203 |+----------------------------------------------------+ | 1204 +---------------------------------------------------------------------+ 1206 Figure 7: Illustration of CAdES-X Type 1 1208 4.4.3.3 EXtended Electronic Signature with Time Type 2 1209 (CAdES-X Type 2) 1211 Extended format with time type 2 (CAdES-X Type 2) in accordance with 1212 the present document adds to the CAdES-C format the CAdES-C-time- 1213 stamped-certs-crls-references attribute, whose content is a time-stamp 1214 token on the certification path and revocation information references. 1215 This provides an integrity and trusted time protection over all the 1216 references. 1218 It may protect the certificates, CRLs and OCSP responses in case of a 1219 later compromise of a CA key, CRL key or OCSP issuer key. 1221 Both CAdES-X Type 1 and CAdES-X Type 2 counter the same threats and the 1222 usage of one or the other depends on the environment. Section 6.3.5 1223 provides the specification details. Section B.1.3 gives details on the 1224 production of the time-stamping process. Section C.4.4.2 provides the 1225 rationale. 1227 Internet-draft CMS Advanced Electronic Signatures September 2007 1229 The structure of the CAdES-X Type 2 format is illustrated in figure 8. 1231 +------------------------- CAdES-X-Type 2 ----------------------------+ 1232 |+----------------------------------------CAdES-C ---+ | 1233 || +------------+| | 1234 ||+----- CAdES -----------------------+| Timmestamp || | 1235 ||| || over || | 1236 |||+---------+ +----------+ || digital || +-------------+| 1237 ||||Signer's | | Signed | Digital || signature || | Time-stamp || 1238 ||||Document | |Attributes| signature || || | only over || 1239 |||| | | | || optional || | complete || 1240 |||+---------+ +----------+ || when || | certificate || 1241 ||+-----------------------------------+| timemarked || | and || 1242 || +------------+| | revocation || 1243 || +-------------+ | | references || 1244 || | Complete | | +-------------+| 1245 || | certificate | | | 1246 || | and | | | 1247 || | revocation | | | 1248 || | references | | | 1249 || +-------------+ | | 1250 |+---------------------------------------------------+ | 1251 +---------------------------------------------------------------------+ 1253 Figure 8: Illustration of CAdES-X Type 2 1255 4.4.3.4 EXtended Long Electronic Signature with Time (CAdES-X Long Type 1256 1 or 2) 1258 Extended Long with Time (CAdES-X Long Type 1 or 2) in accordance with 1259 the present document is a combination of CAdES-X Long and one of the 1260 two former types (CAdES-X Type 1 and CAdES-X Type 2). Section B.1.4 1261 gives details on the production of the time-stamping process. Section 1262 C4.8 in annex C provides the rationale. 1264 Internet-draft CMS Advanced Electronic Signatures September 2007 1266 The structure of the CAdES-X Long Type 1 and CAdES-X Long Type 2. 1267 format is illustrated in figure 9. 1269 +------------------ CAdES-X Long Type 1 or 2 -----------------------+ 1270 | +--------------+| 1271 |+-------------------------------------- CAdES-C --+|+------------+|| 1272 || ||| Timestamp ||| 1273 ||+------- CAdES --------------------++----------+ ||| over ||| 1274 ||| ||Timestamp | ||| CAdES-C ||| 1275 ||| ||over | ||+------------+|| 1276 |||+---------++----------+ ||digital | || OR || 1277 ||||Signer's || Signed | Digital ||signature | ||+------------+|| 1278 ||||Document ||Attributes| signature || | ||| Timestamp ||| 1279 |||| || | ||Optional | ||| only over ||| 1280 |||+---------++----------+ ||when | ||| complete ||| 1281 ||+----------------------------------+|timemarked| ||| certificate||| 1282 || +----------+ ||| and ||| 1283 || ||| Revocation ||| 1284 || +-------------+ ||| References ||| 1285 || | Complete | ||+------------+|| 1286 || | certificate | |+--------------+| 1287 || | and | | +------------+ | 1288 || | revocation | | | Complete | | 1289 || | references | | |certificate | | 1290 || +-------------+ | | and | | 1291 |+-------------------------------------------------+ |revocation | | 1292 | | value | | 1293 | +------------+ | 1294 +-------------------------------------------------------------------+ 1296 Figure 9: Illustration of CAdES-X Long Type 1 and CAdES Long Type 2 1298 4.4.4 Archival Electronic Signature (CAdES-A) 1300 Archival Form (CAdES-A) in accordance with the present document builds 1301 on a CAdES-X Long or a CAdES-X Long Type 1 or 2 by adding one or more 1302 archive-time-stamp attributes. This form is used for archival of long- 1303 term signatures. Successive time-stamps protect the whole material 1304 against vulnerable hashing algorithms or the breaking of the 1305 cryptographic material or algorithms. Section 6.4 contains the 1306 specification details. Sections C.4.5 and C.4.8 provide the rationale. 1308 The structure of the CAdES-A form is illustrated in figure 10. 1310 Internet-draft CMS Advanced Electronic Signatures September 2007 1312 +---------------------------CAdES-A ---------------------------------+ 1313 |+----------------------------------------------------+ | 1314 || +--------------+| +----------+ | 1315 ||+----------------------CAdES-C ----+|+------------+|| | | | 1316 ||| +----------+ ||| Timestamp ||| | | | 1317 |||+---- CAdES-BES ----+|Timestamp | ||| over ||| | | | 1318 |||| or CAdeS-EPES || over | ||| CAdES-C ||| | Archive | | 1319 |||| ||digital | ||+------------+|| | | | 1320 |||| ||signature | || or || |Timestamp | | 1321 |||| || | ||+------------+|| | | | 1322 |||| ||Optional | ||| Timestamp ||| | | | 1323 |||| ||when | ||| only over ||| | | | 1324 |||| ||Timemarked| ||| complete ||| | | | 1325 |||+-------------------+| | ||| certificate||| +----------+ | 1326 ||| +----------+ ||| and ||| | 1327 ||| +-------------+ ||| revocation ||| | 1328 ||| | Complete | ||| references ||| | 1329 ||| | certificate | ||+------------+|| | 1330 ||| | and | |+--------------+| | 1331 ||| | revocation | | +------------+ | | 1332 ||| | references | | | Complete | | | 1333 ||| +-------------+ | |certificate | | | 1334 ||| | | and | | | 1335 ||+----------------------------------+ |revocation | | | 1336 || | values | | | 1337 || +------------+ | | 1338 |+----------------------------------------------------+ | 1339 +--------------------------------------------------------------------+ 1341 Figure 10: Illustration of CAdES-A 1343 4.5 Arbitration 1345 The CAdES-C may be used for arbitration should there be a dispute 1346 between the signer and verifier, provided that: 1348 - the arbitrator knows where to retrieve the signer's certificate 1349 (if not already present), all the cross-certificates and the 1350 required CRLs, ACRLs or OCSP responses referenced in the CAdES-C; 1352 - when time-stamping in the CAdES-T is being used, the certificate 1353 from the TSU that has issued the time-stamp token in the CAdES-T 1354 format is still within its validity period; 1356 Internet-draft CMS Advanced Electronic Signatures September 2007 1358 - when time-stamping in the CAdES-T is being used, the certificate 1359 from the TSU that has issued the time-stamp token in the CAdES-T 1360 format is not revoked at the time of arbitration; 1362 - when time-marking in the CAdES-T is being used, a reliable audit 1363 trail from the Time-Marking Authority is available for 1364 examination regarding the time; 1366 - none of the private keys corresponding to the certificates used 1367 to verify the signature chain have ever been compromised; 1369 - the cryptography used at the time the CAdES-C was built has not 1370 been broken at the time the arbitration is performed; and 1372 - If the signature policy can be explicit or implicitly identified 1373 then an arbitrator is able to determine the rules required to 1374 validate the electronic signature. 1376 4.6 Validation process 1378 The Validation Process validates an electronic signature, the output 1379 status of the validation process can be: 1381 - invalid; 1383 - incomplete validation; or 1385 - valid. 1387 An Invalid response indicates that either the signature format is 1388 incorrect or that the digital signature value fails verification (e.g. 1389 the integrity check on the digital signature value fails or any of the 1390 certificates on which the digital signature verification depends is 1391 known to be invalid or revoked). 1393 An Incomplete Validation response indicates that the signature 1394 validation status is currently unknown. In the case of incomplete 1395 validation, additional information may be made available to the 1396 application or user, thus allowing them to decide what to do with the 1397 electronic signature. In the case of incomplete validation, the 1398 electronic signature may be checked again at some later time when 1399 additional information becomes available. 1401 NOTE: For example; an incomplete validation may be because all the 1402 required certificates are not available or the grace period is 1403 not completed. 1405 A Valid response indicates that the signature has passed verification 1406 and it complies with the signature validation policy. 1408 Internet-draft CMS Advanced Electronic Signatures September 2007 1410 Example validation sequences are illustrated in annex B. 1412 5 Electronic signature attributes 1414 This section builds upon the existing Cryptographic Message Syntax 1415 (CMS), as defined in RFC 3852 [4], and Enhanced Security Services 1416 (ESS), as defined in RFC 2634 [5]. The overall structure of Electronic 1417 Signature is as defined in CMS. The Electronic Signature (ES) uses 1418 attributes defined in CMS, ESS and the present document. The present 1419 document defines ES attributes which it uses and are not defined 1420 elsewhere. 1422 The mandated set of attributes and the digital signature value is 1423 defined as the minimum Electronic Signature (ES) required by the 1424 present document. A signature policy may mandate that other signed 1425 attributes are present. 1427 5.1 General syntax 1429 The general syntax of the ES is as defined in CMS (RFC 3852 [4]). 1431 NOTE: CMS defines content types for id-data, id-signedData, id- 1432 envelopedData, id-digestedData, id-encryptedData, and id- 1433 authenticatedData. Although CMS permits other documents to 1434 define other content types, the ASN.1 type defined should not 1435 be a CHOICE type. The present document does not define other 1436 content types. 1438 5.2 Data content type 1440 The data content type of the ES is as defined in CMS (RFC 3852 [4]). 1442 NOTE: If the content type is id-data, it is recommended that the 1443 content is encoded using MIME and that the MIME type is used 1444 to identify the presentation format of the data. See annex F.1 1445 for an example of using MIME to identify encoding type. 1447 5.3 Signed-data content type 1449 The signed-data content type of the ES is as defined in CMS (RFC 3852 1450 [4]). 1452 5.4 SignedData type 1454 The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 1455 [4]). 1457 The fields of type SignedData have the meanings as defined in CMS 1458 (RFC 3852 [4]). 1460 Internet-draft CMS Advanced Electronic Signatures September 2007 1462 The identification of signer's certificate used to create the signature 1463 is always signed (see section 5.7.3). The validation policy may specify 1464 requirements for the presence of certain certificates. The degenerate case 1465 where there are no signers is not valid in the present document. 1467 5.5 EncapsulatedContentInfo type 1469 The syntax of the EncapsulatedContentInfo type ES is as defined in CMS 1470 (RFC 3852 [4]). 1472 For the purpose of long term validation as defined by the present 1473 document, it is advisable that either the eContent is present, or the 1474 data which is signed is archived in such as way as to preserve any data 1475 encoding. It is important that the OCTET STRING used to generate the 1476 signature remains the same every time either the verifier or an 1477 arbitrator validates the signature. 1479 NOTE: The eContent is optional in CMS : 1481 - When it is present, this allows the signed data to be 1482 encapsulated in the SignedData structure, which then 1483 contains both the signed data and the signature. However, 1484 the signed data may only be accessed by a verifier able to 1485 decode the ASN.1 encoded SignedData structure. 1487 - When it is missing, this allows the signed data to be sent 1488 or stored separately from the signature and the SignedData 1489 structure only contains the signature. It is in the case 1490 of signature only that the data which is signed needs to be 1491 stored and distributed in such as way as to preserve any 1492 data encoding. 1494 The degenerate case where there are no signers is not valid in the 1495 present document. 1497 5.6 SignerInfo type 1499 The syntax of the SignerInfo type ES is as defined in CMS (RFC 3852 1500 [4]). 1502 Per-signer information is represented in the type SignerInfo. In the 1503 case of multiple independent signatures (see section B.5), there is an 1504 instance of this field for each signer. 1506 The fields of type SignerInfo have the meanings defined in CMS (RFC 1507 3852 [4]) but the signedAttrs field shall contain the following 1508 attributes: 1510 - content-type as defined in section 5.7.1; and 1511 - message-digest as defined in section 5.7.2; 1513 - signing-certificate as defined in section 5.7.3. 1515 Internet-draft CMS Advanced Electronic Signatures September 2007 1517 5.6.1 Message digest calculation process 1519 The message digest calculation process is as defined in CMS (RFC 3852 1520 [4]). 1522 5.6.2 Message signature generation process 1524 The input to the message signature generation process is as defined in 1525 CMS (RFC 3852 [4]). 1527 5.6.3 Message signature verification process 1529 The procedures for message signature verification are defined in CMS 1530 (RFC 3852 [4]) and enhanced in the present document: the input to the 1531 signature verification process MUST be the signer's public key which 1532 SHALL be verified as correct using the signing certificate reference 1533 attribute containing a reference to the signing certificate, e.g. when 1534 SigningCertificate from ESS [RFC 2634] is used, the public key from 1535 the first certificate identified in the sequence of certificate 1536 identifiers from SigningCertificate MUST be the key used to verify the 1537 digital signature. 1539 5.7 Basic ES mandatory present attributes 1541 The following attributes shall be present with the signed-data defined 1542 by the present document. The attributes are defined in CMS (RFC 3852 1543 [4]). 1545 5.7.1 Content type 1547 The content-type attribute indicates the type of the signed content. 1548 The syntax of the content-type attribute type is as defined in CMS 1549 (RFC 3852 [4]) section 11.1. 1551 Note 1 : As stated in RFC 3852 [4] , the content-type attribute 1552 must have its value (i.e. ContentType) equal to the 1553 eContentType of the EncapsulatedContentInfo value being 1554 signed. 1556 Note 2 : For implementations supporting signature generation, if 1557 the content-type attribute is id-data, then it is 1558 recommended that the eContent be encoded using MIME. 1559 For implementations supporting signature verification, if 1560 the signed data (i.e. eContent) is MIME-encoded, then the 1561 OID of the content-type attribute must be id-data. 1562 In both cases, the MIME content-type(s) must be used to 1563 identify the presentation format of the data. See Annex F 1564 for further details about the use of MIME. 1566 Internet-draft CMS Advanced Electronic Signatures September 2007 1568 5.7.2 Message digest 1570 The syntax of the message-digest attribute type of the ES is as defined 1571 in CMS (RFC 3852 [4]). 1573 5.7.3 Signing certificate reference attributes 1575 The Signing certificate reference attributes are supported by using 1576 either the ESS signing-certificate attribute or the ESS-signing- 1577 certificate-v2 attribute. 1579 These attributes shall contain a reference to the signer's certificate, 1580 they are designed to prevent the simple substitution and re-issue 1581 attacks and to allow for a restricted set of certificates to be used in 1582 verifying a signature. They have a compact form (much shorter than the 1583 full certificate) that allows to a certificate to be unambiguously 1584 identified. 1586 One, and only one, of the following alternative attributes shall be 1587 present with the signedData defined by the present document. 1589 - The ESS signing-certificate attribute, defined in ESS [RFC 2634], 1590 MUST be used if the SHA-1 hashing algorithm is used. 1592 - The ESS signing-certificate attribute v2, defined in �ESS Update: 1593 Adding CertID Algorithm Agility�, RFC 5035 [15] which SHALL be 1594 used when other hashing algorithms are to be used. 1596 The certificate to be used to verify the signature shall be identified 1597 in the sequence (i.e. the certificate from the signer) and the sequence 1598 shall not be empty. The signature validation policy may mandate other 1599 certificates be present that may include all the certificates up to the 1600 trust anchor. 1602 5.7.3.1 ESS signing certificate attribute definition 1604 The syntax of the signing-certificate attribute type of the ES is as 1605 defined in Enhanced Security Services (ESS), RFC 2634 [5] and further 1606 qualified in the present document. 1608 The sequence of policy information field is not used in the present 1609 document. 1611 The ESS signing-certificate attribute shall be a signed attribute. 1612 The encoding of the ESSCertID for this certificate shall include the 1613 issuerSerial field. 1615 If present, the issuerAndSerialNumber in SignerIdentifier field of the 1616 SignerInfo shall match the issuerSerial field present in ESSCertID. 1617 In addition the certHash from ESSCertID shall match the SHA-1 hash of 1618 the certificate. The certificate identified shall be used during the 1619 signature verification process. If the hash of the certificate does 1620 not match the certificate used to verify the signature, the signature 1621 shall be considered invalid. 1623 Internet-draft CMS Advanced Electronic Signatures September 2007 1625 NOTE: Where an attribute certificate is used by the signer to 1626 associate a role, or other attributes of the signer, with the 1627 electronic signature, this is placed in the signer-attributes 1628 attribute as defined in section 5.8.3. 1630 5.7.3.2 ESS signing certificate v2 attribute definition 1632 The ESS signing-certificate v2 attribute is similar to the ESS 1633 signing-certificate defined above, except that this attribute can be 1634 used with hashing algorithms other than SHA-1. 1636 The syntax of the signing-certificate v2 attribute type of the ES is as 1637 defined in �ESS Update: Adding CertID Algorithm Agility�, RFC 5035 [15] 1638 and further qualified in the present document. 1640 The sequence of policy information field is not used in the present 1641 document. 1643 This attribute shall be used in the same manner as defined above for 1644 the ESS signing-certificate attribute. 1646 The object identifier for this attribute is: 1647 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= 1648 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1649 smime(16) id-aa(2) 47 } 1651 If present, the issuerAndSerialNumber in SignerIdentifier field of the 1652 SignerInfo shall match the issuerSerial field present in ESSCertID. 1653 In addition the certHash from ESSCertID shall match the SHA-1 hash of 1654 the certificate. The certificate identified shall be used during the 1655 signature verification process. If the hash of the certificate does 1656 not match the certificate used to verify the signature, the signature 1657 shall be considered invalid. 1659 Note 1 : Where an attribute certificate is used by the signer to 1660 associate a role, or other attributes of the signer, with the 1661 electronic signature, this is placed in the signer-attributes 1662 attribute as defined in section 5.8.3. 1664 Note 2 : RFC 3126 was using the other signing certificate attribute 1665 (see section 5.7.3.3) for the same purpose. Its use is now 1666 deprecated, since this structure is simpler. 1668 5.7.3.3 Other signing certificate attribute definition 1670 RFC 3126 was using the other signing certificate attribute as 1671 an alternative to the ESS signing-certificate when hashing algorithms 1672 other than SHA-1 were being used. Its use is now deprecated, since 1673 the structure of the general-signing-certificate-v2 attribute is 1674 simpler. Its description is however still present in this version for 1675 backwards compatibility. 1677 Internet-draft CMS Advanced Electronic Signatures September 2007 1679 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 1680 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1681 smime(16) id-aa(2) 19 } 1683 The other-signing-certificate attribute value has the ASN.1 syntax 1684 OtherSigningCertificate: 1686 OtherSigningCertificate ::= SEQUENCE { 1687 certs SEQUENCE OF OtherCertID, 1688 policies SEQUENCE OF PolicyInformation OPTIONAL 1689 -- NOT USED IN THE PRESENT DOCUMENT } 1691 OtherCertID ::= SEQUENCE { 1692 otherCertHash OtherHash, 1693 issuerSerial IssuerSerial OPTIONAL } 1695 OtherHash ::= CHOICE { 1696 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 1697 otherHash OtherHashAlgAndValue} 1699 OtherHashValue ::= OCTET STRING 1701 OtherHashAlgAndValue ::= SEQUENCE { 1702 hashAlgorithm AlgorithmIdentifier, 1703 hashValue OtherHashValue } 1705 5.8 Additional mandatory attributes for Explicit Policy-based 1706 Electronic Signatures 1708 5.8.1 Signature policy identifier 1710 The present document mandates that for CAdES-EPES a reference to the 1711 signature policy is included in the signedData. This reference is 1712 explicitly identified. A signature policy defines the rules for 1713 creation and validation of an electronic signature, is included as a 1714 signed attribute with every Explicit Policy-based Electronic Signature. 1715 The signature-policy-identifier shall be a signed attribute. 1717 The following object identifier identifies signature-policy-identifier 1718 attribute: 1720 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 1721 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1722 smime(16) id-aa(2) 15 } 1724 signature-policy-identifier attribute values have ASN.1 type 1725 SignaturePolicyIdentifier: 1727 SignaturePolicyIdentifier ::= CHOICE { 1728 signaturePolicyId SignaturePolicyId, 1729 signaturePolicyImplied SignaturePolicyImplied 1730 -- not used in this version 1731 } 1732 Internet-draft CMS Advanced Electronic Signatures September 2007 1734 SignaturePolicyId ::= SEQUENCE { 1735 sigPolicyId SigPolicyId, 1736 sigPolicyHash SigPolicyHash, 1737 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 1738 SigPolicyQualifierInfo OPTIONAL} 1740 SignaturePolicyImplied ::= NULL 1742 The sigPolicyId field contains an object-identifier which uniquely 1743 identifies a specific version of the signature policy. The syntax of 1744 this field is as follows: 1746 SigPolicyId ::= OBJECT IDENTIFIER 1748 The sigPolicyHash field optionally contains the identifier of the hash 1749 algorithm and the hash of the value of the signature policy. The 1750 hashValue within the sigPolicyHash max be set to zero to indicate 1751 that the policy hash value is not known. 1753 NOTE: The use of zero policy hash value is to ensure backward 1754 compatibility with earlier versions of the current document. 1755 If hashValue is zero then the hash value should not be checked 1756 against the calculated hash value of signature policy. 1758 If the signature policy is defined using ASN.1, then the hash is 1759 calculated on the value without the outer type and length fields and 1760 the hashing algorithm shall be as specified in the field sigPolicyHash. 1762 If the signature policy is defined using another structure, the type of 1763 structure and the hashing algorithm shall be either specified as part 1764 of the signature policy, or indicated using a signature policy qualifier. 1766 SigPolicyHash ::= OtherHashAlgAndValue 1768 OtherHashAlgAndValue ::= SEQUENCE { 1769 hashAlgorithm AlgorithmIdentifier, 1770 hashValue OtherHashValue } 1772 OtherHashValue ::= OCTET STRING 1774 A signature policy identifier may be qualified with other information 1775 about the qualifier. The semantics and syntax of the qualifier is as 1776 associated with the object-identifier in the sigPolicyQualifierId 1777 field. The general syntax of this qualifier is as follows: 1779 SigPolicyQualifierInfo ::= SEQUENCE { 1780 sigPolicyQualifierId SigPolicyQualifierId, 1781 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 1783 The present document specifies the following qualifiers: 1785 - spuri: this contains the web URI or URL reference to the 1786 signature policy, and 1788 Internet-draft CMS Advanced Electronic Signatures September 2007 1790 - sp-user-notice: this contains a user notice which should be 1791 displayed whenever the signature is validated. 1793 sigpolicyQualifierIds defined in the present document: 1794 SigPolicyQualifierId ::= OBJECT IDENTIFIER 1796 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 1797 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1798 smime(16) id-spq(5) 1 } 1800 SPuri ::= IA5String 1802 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 1803 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1804 smime(16) id-spq(5) 2 } 1806 SPUserNotice ::= SEQUENCE { 1807 noticeRef NoticeReference OPTIONAL, 1808 explicitText DisplayText OPTIONAL} 1810 NoticeReference ::= SEQUENCE { 1811 organization DisplayText, 1812 noticeNumbers SEQUENCE OF INTEGER } 1814 DisplayText ::= CHOICE { 1815 visibleString VisibleString (SIZE (1..200)), 1816 bmpString BMPString (SIZE (1..200)), 1817 utf8String UTF8String (SIZE (1..200)) } 1819 5.9 CMS imported optional attributes 1821 The following attributes may be present with the signed-data, the 1822 attributes are defined in CMS (RFC 3852 [4]) and are imported into the 1823 present document. Were appropriated the attributes are qualified and 1824 profiled by the present document. 1826 5.9.1 Signing time 1828 The signing-time attribute specifies the time at which the signer 1829 claims to have performed the signing process. 1831 Signing-time attribute values for ES have the ASN.1 type SigningTime 1832 as defined in CMS (RFC 3852 [4]). 1834 NOTE: RFC 3852 [4] states that dates between 1 January 1950 and 31 1835 December 2049 (inclusive) MUST be encoded as UTCTime. Any dates 1836 with year values before 1950 or after 2049 MUST be encoded as 1837 GeneralizedTime. 1839 5.9.2 Countersignature 1841 The counterSignature attribute values for ES have ASN.1 type 1842 CounterSignature as defined in CMS (RFC 3852 [4]). A counterSignature 1843 attribute shall be an unsigned attribute. 1845 Internet-draft CMS Advanced Electronic Signatures September 2007 1847 5.10 ESS imported optional attributes 1849 The following attributes may be present with the signed-data defined by 1850 the present document. The attributes are defined in ESS and are 1851 imported into the present document and were appropriate qualified and 1852 profiled by the present document. 1854 5.10.1 Content reference attribute 1856 The content-reference attribute is a link from one SignedData to 1857 another. It may be used to link a reply to the original message to 1858 which it refers, or to incorporate by reference one SignedData into 1859 another. The content-reference attribute shall be a signed attribute. 1861 Content-reference attribute values for ES have ASN.1 type 1862 ContentReference as defined in ESS (RFC 2634 [5]). 1864 The content-reference attribute shall be used as defined in ESS (RFC 1865 2634 [5]). 1867 5.10.2 Content identifier attribute 1869 The content-identifier attribute provides an identifier for the signed 1870 content for use when reference may be later required to that content, 1871 for example in the content reference attribute in other signed data 1872 sent later. The content-identifier shall be a signed attribute. 1874 content-identifier attribute type values for of the ES have ASN.1 type 1875 ContentIdentifier as defined in ESS (RFC 2634 [5]). 1877 The minimal content-identifier attribute should contain a concatenation 1878 of user-specific identification information (such as a user name or 1879 public keying material identification information), a GeneralizedTime 1880 string, and a random number. 1882 5.10.3 Content hints attribute 1884 The content-hints attribute provides information on the innermost 1885 signed content of a multi-layer message where one content is 1886 encapsulated in another. 1888 The syntax of the content-hints attribute type of the ES as defined in 1889 ESS (RFC 2634 [5]). 1891 When used to indicate the precise format of the data to be presented to 1892 the user the following rules apply: 1894 - the contentType indicates the type of the associated content. It 1895 is an object identifier (i.e. a unique string of integers) 1896 assigned by an authority that defines the content type; and 1898 - when the contentType is id-data the contentDescription shall 1899 define the presentation format, the format may be defined by MIME 1900 types. 1902 Internet-draft CMS Advanced Electronic Signatures September 2007 1904 When the format of the content is defined by MIME types the following 1905 rules apply: 1907 - the contentType shall be id-data as defined in CMS (RFC 3852 1908 [4]); 1910 - the contentDescription shall be used to indicate the encoding of 1911 the data in accordance with the rules defined RFC 2045 [6], see 1912 annex F for an example structured contents and MIME. 1914 NOTE 1: id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1915 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1917 NOTE 2: contentDescription is optional in ESS (RFC 2634 [5]). It may 1918 be used to complement contentTypes defined elsewhere , such 1919 definitions are outside the scope of the present document. 1921 5.11 Additional optional attributes defined in the present document 1923 This section defines a number of attributes that may be used to 1924 indicate additional information to a verifier : 1926 a) the type of commitment from the signer, and/or 1927 b) the claimed location where the signature is performed, and/or 1928 c) claimed attributes or certified attributes of the signer, and/or 1929 d) a content time-stamp applied before the content was signed. 1931 5.11.1 Commitment type indication attribute 1933 There may be situations where a signer wants to explicitly indicate to 1934 a verifier that by signing the data, it illustrates a type of 1935 commitment on behalf of the signer. The commitment-type-indication 1936 attribute conveys such information. 1938 The commitment-type-indication attribute shall be a signed attribute. 1939 The commitment type may be: 1941 - defined as part of the signature policy, in which case the 1942 commitment type has precise semantics that is defined as part of 1943 the signature policy; and 1945 - be a registered type, in which case the commitment type has 1946 precise semantics defined by registration, under the rules of the 1947 registration authority. Such a registration authority may be a 1948 trading association or a legislative authority. 1950 The signature policy specifies a set of attributes that it 1951 "recognizes". This "recognized" set includes all those commitment 1952 types defined as part of the signature policy as well as any externally 1953 defined commitment types that the policy may choose to recognize. Only 1954 recognized commitment types are allowed in this field. 1956 Internet-draft CMS Advanced Electronic Signatures September 2007 1958 The following object identifier identifies the commitment-type- 1959 indication attribute: 1961 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1962 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 1964 commitment-type-indication attribute values have ASN.1 type 1965 CommitmentTypeIndication. 1967 CommitmentTypeIndication ::= SEQUENCE { 1968 commitmentTypeId CommitmentTypeIdentifier, 1969 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 1970 CommitmentTypeQualifier OPTIONAL} 1972 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 1974 CommitmentTypeQualifier ::= SEQUENCE { 1975 commitmentTypeIdentifier CommitmentTypeIdentifier, 1976 qualifier ANY DEFINED BY commitmentTypeIdentifier } 1978 The use of any qualifiers to the commitment type is outside the scope 1979 of the present document. 1981 The following generic commitment types are defined in the present 1982 document: 1984 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1985 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 1987 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1988 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 1990 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 1991 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1992 cti(6) 3} 1994 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1995 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 1997 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) 1998 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1999 cti(6) 5} 2000 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) 2001 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2002 cti(6) 6} 2004 These generic commitment types have the following meaning: 2006 Proof of origin indicates that the signer recognizes to have created, 2007 approved and sent the message. 2009 Proof of receipt indicates that signer recognizes to have received the 2010 content of the message. 2012 Internet-draft CMS Advanced Electronic Signatures September 2007 2014 Proof of delivery indicates that the TSP providing that indication has 2015 delivered a message in a local store accessible to the recipient of the 2016 message. 2018 Proof of sender indicates that the entity providing that indication has 2019 sent the message (but not necessarily created it). 2021 Proof of approval indicates that the signer has approved the content of 2022 the message. 2024 Proof of creation indicates that the signer has created the message 2025 (but not necessarily approved, nor sent it). 2027 5.11.2 Signer location attribute 2029 The signer-location attribute specifies a mnemonic for an address 2030 associated with the signer at a particular geographical (e.g. city) 2031 location. The mnemonic is registered in the country in which the 2032 signer is located and is used in the provision of the Public Telegram 2033 Service (according to ITU-T Recommendation F.1 [11]). 2035 The signer-location attribute shall be a signed attribute. The 2036 following object identifier identifies the signer-location attribute: 2038 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2039 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 2041 Signer-location attribute values have ASN.1 type SignerLocation: 2042 SignerLocation ::= SEQUENCE { -- at least one of the following shall be 2043 present 2045 countryName [0] DirectoryString OPTIONAL, 2046 -- As used to name a Country in X.500 2047 localityName [1] DirectoryString OPTIONAL, 2048 -- As used to name a locality in X.500 2049 postalAdddress [2] PostalAddress OPTIONAL } 2051 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 2053 5.11.3 Signer attributes attribute 2055 The signer-attributes attribute specifies additional attributes of the 2056 signer (e.g. role). 2058 It may be either: 2060 - claimed attributes of the signer; or 2061 - certified attributes of the signer. 2063 The signer-attributes attribute shall be a signed attribute. 2064 The following object identifier identifies the signer-attribute 2065 attribute: 2067 Internet-draft CMS Advanced Electronic Signatures September 2007 2069 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2070 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 2072 signer-attributes values have ASN.1 type SignerAttribute: 2073 SignerAttribute ::= SEQUENCE OF CHOICE { 2074 claimedAttributes [0] ClaimedAttributes, 2075 certifiedAttributes [1] CertifiedAttributes } 2077 ClaimedAttributes ::= SEQUENCE OF Attribute 2079 CertifiedAttributes ::= AttributeCertificate 2080 -- as defined in RFC 3281 : see section 4.1. 2082 NOTE 1: Only a single signer-attributes can be used 2084 NOTE 2: The claimedAttributes and certifiedAttributes fields are as 2085 defined in ITU-T Recommendations X.501 [9] and X.509 [1]. 2087 5.11.4 Content time-stamp 2089 The content-time-stamp attribute is an attribute which is the time- 2090 stamp token of the signed data content before it is signed. 2091 The content-time-stamp attribute shall be a signed attribute. 2093 The following object identifier identifies the content-time-stamp 2094 attribute: 2096 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= 2097 { iso(1) member- body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2098 smime(16) id-aa(2) 20} 2100 Content-time-stamp attribute values have ASN.1 type ContentTimestamp: 2101 ContentTimestamp ::= TimeStampToken 2103 The value of messageImprint of TimeStampToken (as described in RFC 3161 2104 [7]) shall be a hash of the value of eContent field within 2105 encapContentInfo in the signedData. 2107 For further information and definition of TimeStampToken see 2108 section 7.4. 2110 NOTE: Content-time-stamp indicates that the signed information was 2112 formed before the date included in the Content-time-stamp. 2114 5.12 Support for multiple signatures 2116 5.12.1 Independent signatures 2118 Multiple independent signatures (see section B.5) are supported by 2119 independent SignerInfo from each signer. 2121 Each SignerInfo shall include all the attributes required under the 2122 present document and shall be processed independently by the verifier. 2124 Internet-draft CMS Advanced Electronic Signatures September 2007 2126 Note: Independent signatures may be used to provide independent 2127 signatures from different parties with different signed attributes, or 2128 to provide multiple signatures from the same party using alternative 2129 signature algorithms in which case the other attributes, excluding 2130 time values and signature policy information, will generally be the 2131 same. 2133 5.12.2 Embedded signatures 2135 Multiple embedded signatures (see section C.5) are supported using the 2136 countersignature unsigned attribute (see section 5.9.2). Each counter 2137 signature is carried in Countersignature held as an unsigned attribute 2138 to the SignerInfo to which the counter-signature is applied. 2140 Note: Counter signatures may be used to provide signatures from 2141 different parties with different signed attributes, or to provide 2142 multiple signatures from the same party using alternative signature 2143 algorithms in which case the other attributes, excluding time values 2144 and signature policy information, will generally be the same. 2146 6 Additional Electronic Signature validation attributes 2148 This section specifies attributes that contain different types of 2149 validation data. These attributes build on the electronic signature 2150 specified in section 5. This includes: 2152 - Signature-time-stamp applied to the electronic signature value or 2153 a Time-Mark in an audit trail. This is defined as the Electronic 2154 Signature with Time (CAdES-T); and 2156 - complete validation data references which comprises the time- 2157 stamp of the signature value (CAdES-T), plus references to all 2158 the certificates (complete-certificate-references) and revocation 2159 (complete-revocation-references) information used for full 2160 validation of the electronic signature. This is defined as the 2161 Electronic Signature with Complete data references (CAdES-C). 2163 NOTE 1: Formats for CAdES-T are illustrated in section 4.4 and the 2164 attribute are defined in section 6.1.1. 2166 NOTE 2: Formats for CAdES-C are illustrated in section 4.4. The 2167 required attributes for the CAdES-C signature format are 2168 defined in section 6.2.1 to 6.2.2, optional attributes are 2169 defined in sections 6.2.3 and 6.2.4. 2171 In addition the following optional eXtended forms of validation data 2172 are also defined, see annex B for an overview the eXtended forms of 2173 validation data: 2175 - CAdES-X with time stamp: there are two types of time-stamp used 2176 in extended validation data defined by the present document: 2178 - Type 1(CAdES-X Type 1): comprises a time-stamp over the ES 2179 with complete validation data (CAdES-C); and 2181 Internet-draft CMS Advanced Electronic Signatures September 2007 2183 - Type 2 (CAdES-X Type2): comprises a time-stamp over the 2184 certification path references and the revocation information 2185 references used to support the CAdES-C. 2187 NOTE 3: Formats for CAdES-X Type 1 and CAdES-X Type 2 are illustrated 2188 in sections B.1.2 and B.1.3, respectively. 2190 - CAdES-X Long :comprises the complete validation data references 2191 (CAdES-C) plus the actual values of all the certificates and 2192 revocation information used in the CAdES-C. 2194 NOTE 4: Formats for CAdES-X Long are illustrated in section B.1.1. 2196 - CAdES-X Long Type 1 or CAdES-X Long Type 2: comprises an X-Time- 2197 Stamp (Type 1 or Type 2) plus the actual values of all the 2198 certificates and revocation information used in the CAdES-C as 2199 per CAdES-X Long. 2201 This section also specifies the data structures used in Archive 2202 validation data format (CAdES-A)of eXtended forms: 2204 - Archive form of electronic signature (CAdES-A) comprises the 2205 complete validation data references (CAdES-C), the certificate 2206 and revocation values (as in a CAdES-X Long ), if present any 2207 existing extended electronic signature timestamps (CAdES-X Type 1 2208 or CAdES-X Type 2), plus the signed user data and an additional 2209 archive time-stamp applied over all that data. An archive time- 2210 stamp may be repeatedly applied after long periods to maintain 2211 validity when electronic signature and time-stamping algorithms 2212 weaken. 2214 The additional data required to create the forms of electronic 2215 signature identified above is carried as unsigned attributes associated 2216 with an individual signature by being placed in the unsignedAttrs field 2217 of SignerInfo. Thus all the attributes defined in section 6 are 2218 unsigned attributes. 2220 NOTE 5: Where multiple signatures are to be supported, as described 2221 in section 5.12, each signature has a separate SignerInfo. 2222 Thus, each signature requires its own unsigned attribute 2223 values to create CAdES-T, CAdES-C, etc. 2225 NOTE 6: the optional attributes of the extended validation data are 2226 defined in sections 6.3 and 6.4. 2228 6.1 Electronic Signature Time-stamped (CAdES-T) 2230 An Electronic Signature with time-stamp is an electronic signature for 2231 which part, but not all, of the additional data required for validation 2232 is available (i.e. some certificates and revocation information are 2233 available but not all). 2235 Internet-draft CMS Advanced Electronic Signatures September 2007 2237 The minimum structure time-stamp validation data is: 2239 - the Signature Time-stamp Attribute as defined in section 6.1.1 2240 over the ES signature value. 2242 6.1.1 Signature time- stamp attribute definition 2244 The signature-time-stamp attribute is a TimeStampToken computed on the 2245 signature value for a specific signer. It is an unsigned attribute. 2246 Several instances of this attribute may occur with an electronic 2247 signature, from different TSAs. 2249 The following object identifier identifies the signature-time-stamp 2250 attribute: 2252 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= 2253 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2254 smime(16) id-aa(2) 14} 2256 The signature-time-stamp attribute value has ASN.1 type 2257 SignatureTimeStampToken: 2259 SignatureTimeStampToken ::= TimeStampToken 2261 The value of messageImprint field within TimeStampToken shall be a 2262 hash of the value of the signature field within SignerInfo for the 2263 signedData being time-stamped. 2265 For further information and definition of TimeStampToken see 2266 section 7.4. 2268 NOTE 1: In the case of multiple signatures it is possible to have a 2270 TimeStampToken computed for each and all signers, or 2271 TimeStampToken computed on one signer's signature and no 2272 TimeStampToken on another signer's signature. 2274 NOTE 2: In the case of multiple signatures, several TSTs, issued by 2275 different TSAs, may be present within the same signerInfo 2276 (see RFC 3852 [4]). 2278 6.2 Complete validation reference data (CAdES-C) 2280 An electronic signature with complete validation data references 2281 (CAdES-C) is an Electronic Signature for which all the additional data 2282 required for validation (i.e. all certificates and revocation 2283 information) is available. This form is built on the CAdES-T form 2284 defined above. 2286 As a minimum, the complete validation data shall include the following: 2287 - a time, which shall either be a signature-timestamp attribute, as 2288 defined in section 6.1.1, or a time mark operated by a Time- 2289 Marking Authority; 2291 Internet-draft CMS Advanced Electronic Signatures September 2007 2293 - complete-certificate-references, as defined in section 6.2.1; 2295 - complete-revocation-references , as defined in section 6.2.2. 2297 6.2.1 Complete certificate references attribute definition 2299 The complete-certificate-references attribute is an unsigned attribute. 2300 It references the full set of CA certificates that have been used to 2301 validate an ES with Complete validation data up to (but not including) 2302 the signer's certificate. Only a single instance of this attribute 2303 shall occur with an electronic signature. 2305 NOTE 1: The signer's certificate is referenced in the signing 2306 certificate attribute (see section 5.7.3). 2308 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2309 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 2311 The complete-certificate-references attribute value has the ASN.1 2312 syntax CompleteCertificateRefs. 2314 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 2316 OtherCertID is defined in section 5.7.3.2. 2318 The IssuerSerial that shall be present in OtherCertID. The certHash 2319 shall match the hash of the certificate referenced. 2321 NOTE 2: Copies of the certificate values may be held using the 2322 certificate-values attribute defined in section 6.3.3. 2324 This attribute may include references to the certification 2325 chain for any TSUs that provides time-stamp tokens. In this 2326 case the unsigned attribute shall be added to the signedData 2327 of the relevant times tamp token as an unsignedAttrs in the 2328 signerInfos field. 2330 6.2.2 Complete Revocation References attribute definition 2332 The complete-revocation-references attribute is an unsigned attribute. 2333 Only a single instance of this attribute shall occur with an electronic 2334 signature. It references the full set of the CRL, ACRL or OCSP 2335 responses that have been used in the validation of the signer and CA 2336 certificates used in ES with Complete validation data. 2338 This attribute can be used to illustrate that the verifier has taken 2339 due diligence of the available revocation information and then to be 2340 able to retrieve that information when stored elsewhere. 2342 The following object identifier identifies the complete-revocation- 2343 references attribute: 2345 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2346 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 2347 Internet-draft CMS Advanced Electronic Signatures September 2007 2349 The complete-revocation-references attribute value has the ASN.1 syntax 2350 CompleteRevocationRefs: 2352 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 2354 CrlOcspRef ::= SEQUENCE { 2355 crlids [0] CRLListID OPTIONAL, 2356 ocspids [1] OcspListID OPTIONAL, 2357 otherRev [2] OtherRevRefs OPTIONAL 2358 } 2360 CompleteRevocationRefs shall contain one CrlOcspRef for the signing- 2361 certificate, followed by one for each OtherCertID in the 2362 CompleteCertificateRefs attribute. The second and subsequent 2363 CrlOcspRef fields shall be in the same order as the OtherCertID to 2364 which they relate. At least one of CRLListID or OcspListID or 2365 OtherRevRefs should be present for all but the "trusted" CA of the 2366 certificate path. 2368 CRLListID ::= SEQUENCE { 2369 crls SEQUENCE OF CrlValidatedID } 2371 CrlValidatedID ::= SEQUENCE { 2372 crlHash OtherHash, 2373 crlIdentifier CrlIdentifier OPTIONAL } 2375 CrlIdentifier ::= SEQUENCE { 2376 crlissuer Name, 2377 crlIssuedTime UTCTime, 2378 crlNumber INTEGER OPTIONAL } 2380 OcspListID ::= SEQUENCE { 2381 ocspResponses SEQUENCE OF OcspResponsesID } 2383 OcspResponsesID ::= SEQUENCE { 2384 ocspIdentifier OcspIdentifier, 2385 ocspRepHash OtherHash OPTIONAL 2386 } 2388 OcspIdentifier ::= SEQUENCE { 2389 ocspResponderID ResponderID, 2390 -- As in OCSP response data 2391 producedAt GeneralizedTime 2392 -- As in OCSP response data 2393 } 2395 When creating a crlValidatedID, the crlHash is computed over the entire 2396 DER encoded CRL including the signature. The crlIdentifier would 2397 normally be present unless the CRL can be inferred from other 2398 information. 2400 The crlIdentifier is to identify the CRL using the issuer name and the 2401 CRL issued time, which shall correspond to the time thisUpdate 2402 contained in the issued CRL, and if present, the crlNumber. The 2403 Internet-draft CMS Advanced Electronic Signatures September 2007 2405 crlListID attribute is an unsigned attribute. In the case that the 2406 identified CRL is a Delta CRL then references to the set of CRLs to 2407 provide a complete revocation list shall be included. 2409 The OcspIdentifier is to identify the OCSP response using the issuer 2410 name and the time of issue of the OCSP response which shall correspond 2411 to the time producedAt contained in the issued OCSP response. Since it 2412 may be needed to make the difference between two OCSP responses 2413 received within the same second, then the hash of the response 2414 contained in the OcspResponsesID may be needed to solve the ambiguity. 2416 NOTE 1: Copies of the CRL and OCSP responses values may be held using 2417 the revocation-values attribute defined in section 6.3.4. 2419 NOTE 2: It is recommended that this attribute is used in preference to 2420 The OtherRevocationInfoFormat specified in RFC 3852 to 2421 Maintain backward compatibility with earlier version of this 2422 specification. 2424 The syntax and semantics of other revocation references is outside the 2425 scope of the present document. The definition of the syntax of the 2426 other form of revocation information is as identified by 2427 OtherRevRefType. 2429 This attribute may include the references to the full set of the CRL, 2430 ACRL or OCSP responses that have been used to verify the certification 2431 chain for any TSUs that provides time-stamp tokens. In this case the 2432 unsigned attribute shall be added to the signedData of the relevant 2433 timestamp token as an unsignedAttrs in the signerInfos field. 2435 6.2.3 Attribute certificate references attribute definition 2437 This attribute is only used when a user attribute certificate is 2438 present in the electronic signature. 2440 The attribute-certificate-references attribute is an unsigned 2441 attribute. It references the full set of AA certificates that have 2442 been used to validate the attribute certificate. Only a single 2443 instance of this attribute shall occur with an electronic signature. 2445 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= 2446 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2447 smime(16) id-aa(2) 44} 2449 The attribute-certificate-references attribute value has the ASN.1 2450 syntax AttributeCertificateRefs: 2452 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 2454 OtherCertID is defined in section 5.8.2. 2456 NOTE: Copies of the certificate values may be held using the 2457 certificate-values attribute defined in section 6.3.3. 2459 Internet-draft CMS Advanced Electronic Signatures September 2007 2461 6.2.4 Attribute revocation references attribute definition 2463 This attribute is only used when a user attribute certificate is 2464 present in the electronic signature and when that attribute certificate 2465 can be revoked. 2467 The attribute-revocation-references attribute is an unsigned attribute. 2468 Only a single instance of this attribute shall occur with an 2469 electronic signature. It references the full set of the ACRL or OCSP 2470 responses that have been used in the validation of the attribute 2471 certificate. This attribute can be used to illustrate that the 2472 verifier has taken due diligence of the available revocation 2473 information. 2475 The following object identifier identifies the attribute-revocation- 2476 references attribute: 2478 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) 2479 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2480 id-aa(2) 45} 2482 The attribute-revocation-references attribute value has the ASN.1 2483 syntax AttributeRevocationRefs: 2485 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 2487 6.3 Extended validation data (CAdES-X) 2489 This section specifies a number of optional attributes that are used 2490 by extended forms of electronic signatures (see annex B for an 2491 overview these forms of validation data). 2493 6.3.1 Time-stamped validation data (CAdES-X Type 1 or Type 2) 2494 The extended validation data may include one of the following 2495 additional attributes, forming a CAdES-X Time-Stamp validation data 2496 (CAdES-X Type 1 or CAdES-X Type 2), to provide additional protection 2497 against later CA compromise and provide integrity of the validation 2498 data used: 2500 - CAdES-C Time-stamp, as defined in section 6.3.5 (CAdES-X Type 1); 2501 or 2503 - Time-Stamped Certificates and CRLs references, as defined in 2504 section 6.3.6 (CAdES-X Type 2). 2506 6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2) 2508 The extended validation data may also include the following additional 2509 information, forming a CAdES-X Long, for use if later validation 2510 processes may not have access to this information: 2512 Internet-draft CMS Advanced Electronic Signatures September 2007 2514 - certificate-values as defined in section 6.3.3; and 2515 - revocation-values as defined in section 6.3.4. 2517 The extended validation data may in addition to certificate-values and 2518 revocation-values as defined in sections 6.3.3 and 6.3.4 include one of 2519 the following additional attributes, forming an CAdES-X Long Type 1 or 2520 CAdES-X Long Type 2. 2522 - CAdES-C Time-stamp, as defined in section 6.3.3 (CAdES-X long 2523 Type 1); or 2525 - Time-Stamped Certificates and CRLs references, as defined in 2526 section 6.3.4 (CAdES-X Long Type 2). 2528 The CAdES-X Long Type 1 or CAdES-X Long Type 2 provide additional 2529 protection against later CA compromise and provide integrity of the 2530 validation data used. 2532 NOTE 1: The CAdES-X-Long signature provides long term proof of the 2533 validity of the signature for as long as the CA keys, CRL 2534 Issuers keys and OCSP responder keys are not compromised and 2535 are resistant to cryptographic attacks. 2537 NOTE 2: As long as the time stamp data remains valid, the CAdES-X 2538 Long Type 1 and the CAdES-X Long Type 2 provides the following 2539 important property for long standing signatures; that having 2540 been found once to be valid, it shall continue to be so months 2541 or years later, long after the validity period of the 2542 certificates have expired, or after the user key has been 2543 compromised. 2545 6.3.3 Certificate values attribute definition 2547 This attribute may be used to contain the certificate information 2548 required for the following forms of eXtended Electronic Signature: 2549 CAdES-X Long , ES X-Long Type 1 and CAdES-X Long Type 2, see section 2550 B.1.1 for an illustration of this form of electronic signature. 2552 The certificate-values attribute is an unsigned attribute. Only a 2553 single instance of this attribute shall occur with an electronic 2554 signature. It holds the values of certificates referenced in the 2555 complete-certificate-references attribute. 2557 NOTE: If an attribute certificate is used, it is not provided in this 2558 structure but shall be provided by the signer as a signer- 2559 attributes attribute (see section 5.11.3). 2561 The following object identifier identifies the certificate-values 2562 attribute: 2564 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2565 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 2566 Internet-draft CMS Advanced Electronic Signatures September 2007 2568 The certificate-values attribute value has the ASN.1 syntax 2569 CertificateValues. 2571 CertificateValues ::= SEQUENCE OF Certificate 2573 Certificate is defined in section 7.1. (which is as defined in ITU-T 2574 Recommendation X.509 [1]. 2576 This attribute may include the certification information for any TSUs 2577 that have provided the time-stamp tokens if these certificates are not 2578 already included in the TSTs as part of the TSUs signatures. In this 2579 case the unsigned attribute shall be added to the signedData of the 2580 relevant timestamp token. 2582 6.3.4 Revocation values attribute definition 2584 This attribute is used to contain the revocation information required 2585 for the following forms of eXtended Electronic Signature: CAdES-X Long, 2586 ES X-Long Type 1 and CAdES-X Long Type 2, see section B.1.1 for an 2587 illustration of this form of electronic signature. 2589 The revocation-values attribute is an unsigned attribute. Only a 2590 single instance of this attribute shall occur with an electronic 2591 signature. It holds the values of CRLs and OCSP referenced in the 2592 complete-revocation-references attribute. 2594 NOTE : It is recommended that this attribute is used in preference to 2595 the OtherRevocationInfoFormat specified in RFC 3852 to maintain 2596 backward compatibility with earlier version of this 2597 specification. 2599 The following object identifier identifies the revocation-values 2600 attribute: 2602 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 2603 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2604 smime(16) id-aa(2) 24} 2606 The revocation-values attribute value has the ASN.1 syntax 2607 RevocationValues 2609 RevocationValues ::= SEQUENCE { 2610 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 2611 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 2612 otherRevVals [2] OtherRevVals OPTIONAL } 2614 OtherRevVals ::= SEQUENCE { 2615 OtherRevValType OtherRevValType, 2616 OtherRevVals ANY DEFINED BY OtherRevValType } 2618 OtherRevValType ::= OBJECT IDENTIFIER 2620 The syntax and semantics of the other revocation values (OtherRevVals) 2621 is outside the scope of the present document. 2623 Internet-draft CMS Advanced Electronic Signatures September 2007 2625 The definition of the syntax of the other form of revocation 2626 information is as identified by OtherRevRefType. 2628 CertificateList is defined in section 7.2. (which as defined in ITU-T 2629 Recommendation X.509 [1]). 2631 BasicOCSPResponse is defined in section 7.3. (which as defined in 2632 RFC 2560 [3]). 2634 This attribute may include the values of revocation data including CRLs 2635 and OCSP for any TSUs that have provided the time-stamp tokens if these 2636 certificates are not already included in the TSTs as part of the TSUs 2637 signatures. In this case the unsigned attribute shall be added to the 2638 signedData of the relevant timestamp token. 2640 6.3.5 CAdES-C time-stamp attribute definition 2642 This attribute is used to protect against CA key compromise. 2644 This attribute is used for the time stamping the complete electronic 2645 signature (CAdES-C). It is used in the following forms of eXtended 2646 Electronic Signature; CAdES-X Type 1 and CAdES-X Long Type 1, see 2647 section B.1.2 for an illustration of this form of electronic signature. 2649 The CAdES-C-timestamp attribute is an unsigned attribute. It is a 2650 time-stamp token of the hash of the electronic signature and the 2651 complete validation data (CAdES-C). It is a special purpose 2652 TimeStampToken Attribute which time-stamps the CAdES-C. Several 2653 instances of this attribute may occur with an electronic signature from 2654 different TSAs. 2656 NOTE 1: It is recommended that the attributes being time-stamped are 2657 encoded in DER. If DER is not employed then the binary encoding 2658 of the ASN.1structures being time-stamped should be preserved to 2659 ensure that the recalculation of the data hash is consistent. 2661 NOTE 2: Each attribute is included in the hash with the attrType and 2662 attrValues (including type and length) but without the type and 2663 length of the outer SEQUENCE. 2665 The following object identifier identifies the CAdES-C-Timestamp 2666 attribute: 2668 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2669 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 2671 The CAdES-C-timestamp attribute value has the ASN.1 syntax 2672 ESCTimeStampToken : 2674 ESCTimeStampToken ::= TimeStampToken 2676 The value of messageImprint field within TimeStampToken shall be a hash 2677 of the concatenated values (without the type or length encoding for 2678 that value) of the following data objects: 2680 Internet-draft CMS Advanced Electronic Signatures September 2007 2682 - OCTETSTRING of the SignatureValue field within SignerInfo; 2684 - signature-time-stamp, or a time mark operated by a Time-Marking 2685 Authority; 2687 - complete-certificate-references s attribute; and 2689 - complete-revocation-references attribute. 2691 For further information and definition of the TimeStampToken, see 2692 clause 7.4. 2694 6.3.6 Time-stamped certificates and crls references attribute 2695 definition 2697 This attribute is used to protect against CA key compromise. This 2698 attribute is used for the time stamping certificate and revocation 2699 references. It is used in the following forms of eXtended Electronic 2700 Signature; CAdES-X Type 2 and CAdES-X Long Type 2, see section B.1.3 2701 for an illustration of this form of electronic signature. 2703 A time-stamped-certs-crls-references attribute is an unsigned 2704 attribute. It is a time-stamp token issued for a list of referenced 2705 certificates and OCSP responses or/and CRLs to protect against certain 2706 CA compromises. Its syntax is as follows: 2708 NOTE 1: It is recommended that the attributes being time-stamped are 2709 encoded in DER. If DER is not employed then the binary encoding 2710 of the ASN.1structures being time-stamped should be preserved to 2711 ensure that the recalculation of the data hash is consistent. 2713 NOTE 2: Each attribute is included in the hash with the attrType and 2714 attrValues (including type and length) but without the type and 2715 length of the outer SEQUENCE 2717 The following object identifier identifies the time-stamped-certs-crls- 2718 references attribute: 2720 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member 2721 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} 2723 The attribute value has the ASN.1 syntax TimestampedCertsCRLs : 2725 TimestampedCertsCRLs ::= TimeStampToken 2727 The value of messageImprint field within TimeStampToken shall be a hash 2728 of the concatenated values (without the type or length encoding for 2729 that value) of the following data objects as present in the ES with 2730 Complete validation data (CAdES-C): 2732 - complete-certificate-references attribute; and 2734 - complete-revocation-references attribute. 2736 Internet-draft CMS Advanced Electronic Signatures September 2007 2738 6.4 Archive validation data 2740 Where an electronic signature is required to last for a very long time, 2741 and a the time-stamp token on an electronic signature is in danger of 2742 being invalidated due to algorithm weakness or limits in the validity 2743 period of the TSA certificate, then it may be required to time-stamp 2744 the electronic signature several times. When this is required an 2745 archive time-stamp attribute may be required for the archive form of 2746 electronic signature (CAdES-A). This archive time-stamp attribute may 2747 be repeatedly applied over a period of time. 2749 6.4.1 Archive time-stamp attribute definition 2751 The archive-time-stamp attribute is a time-stamp token of many of the 2752 elements of the signedData in the electronic signature. If the 2753 certificate-values and revocation-values attributes are not present in 2754 the CAdES-BES or CAdES-EPES, then they shall be added to the electronic 2755 signature prior to computing the archive time-stamp token. 2757 The archive-time-stamp attribute is an unsigned attribute. Several 2758 instances of this attribute may occur with an electronic signature 2759 both over time and from different TSUs. 2761 The following object identifier identifies the nested 2762 archive-time-stamp attribute: 2764 id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::= 2765 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2766 smime(16) id-aa(2) 48} 2768 Archive-time-stamp attribute values have the ASN.1 syntax 2769 ArchiveTimeStampToken 2771 ArchiveTimeStampToken ::= TimeStampToken 2773 The value of messageImprint field within TimeStampToken shall be a hash 2774 of the concatenation of: 2776 - The encapContentInfo element of the SignedData sequence; 2778 - If the eContent element of the encapContentInfo is omitted, 2779 any external content being protected by the signature; 2781 - When present, the Certificates and crls elements of the 2782 SignedData sequence; and 2784 - Together with all data elements in the SignerInfo sequence 2785 including all signed and unsigned attributes. 2787 NOTE 1: An alternative archiveTimestamp attribute, identified by 2788 object identifier { iso(1) member-body(2) us(840) 2789 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27, is 2790 defined in prior versions of TS 101 733 and in RFC 3126. 2792 Internet-draft CMS Advanced Electronic Signatures September 2007 2794 The archiveTimestamp attribute defined in versions of 2795 TS 101 733 prior to 1.5.1 and in RFC 3126 is not compatible 2796 with the attribute defined in the current document. The 2797 archiveTimestamp attribute defined in versions 1.5.1 to 1.7.3 2798 of TS 101 733 is compatible with the current document if the 2799 content is internal to encapContentInfo. Unless the version 2800 of TS 101 733 employed by the signing party is known by all 2801 recipients, use of the archiveTimestamp attribute defined in 2802 prior versions of TS 101 733 is deprecated. 2804 NOTE 2: Counter signatures held as countersignature attributes do not 2805 require independent archive time-stamps as they are protected 2806 by the archive time-stamp against the containing signedData 2807 structure. 2809 NOTE 3: Unless DER is used throughout, it is recommended that the 2810 binary encoding of the ASN.1 structures being time-stamped are 2811 preserved when being archived to ensure that the recalculation 2812 of the data hash is consistent. 2814 NOTE 4: The hash is calculated over the concatenated data elements as 2815 received / stored including the Type and Length encoding. 2817 NOTE 5: Whilst it is recommended that unsigned attributes are DER 2818 encoded it cannot generally be so guaranteed except by prior 2819 arrangement. Further information and definition of 2820 TimeStampToken see section 7.4. The timestamp should be 2821 created using stronger algorithms (or longer key lengths) than 2822 in the original electronic signatures and weak algorithm (key 2823 length) timestamps. 2825 NOTE 6: This form of ES also provides protection against a TSP key 2826 compromise. 2828 The ArchiveTimeStamp will be added as an unsigned attribute in the 2829 SignerInfo sequence. For the validation of one ArchiveTimeStamp the 2830 data elements of the SignerInfo must be concatenated excluding all 2831 later ArchivTimeStampToken attributes. 2833 Certificates and revocation information required to validate the 2834 ArchiveTimeStamp shall be provided by one of the following methods: 2836 - The TSU provides the information in the SignedData of the 2837 timestamp token; 2839 - Adding the complete-certificate-references attribute and the 2840 complete-revocation-references attribute of the TSP as an 2841 unsigned attribute within TimeStampToken, when the required 2842 information is store elsewhere; or 2844 - Adding the certificate-values attribute and the revocation-values 2845 attribute of the TSP as an unsigned attribute within 2846 TimeStampToken, when the required information is store elsewhere. 2848 Internet-draft CMS Advanced Electronic Signatures September 2007 2850 7 Other standard data structures 2852 7.1 Public-key certificate format 2854 The X.509 v3 certificate basis syntax is defined in ITU-T 2855 Recommendation X.509 [1]. A profile of the X.509 v3 certificate is 2856 defined in RFC 3280 [2]. 2858 7.2 Certificate revocation list format 2860 The X.509 v2 CRL syntax is defined in ITU-T Recommendation X.509 [1]. 2861 A profile of the X.509 v2 CRL is defined in RFC 3280 [2]. 2863 7.3 OCSP response format 2865 The format of an OCSP token is defined in RFC 2560 [3]. 2867 7.4 Time-stamp token format 2869 The format of a TimeStampToken type is defined in RFC 3161 [7] and 2870 profiled in ETSI TS 101 861 [TS101861]. 2872 7.5 Name and attribute formats 2874 The syntax of the naming and other attributes is defined in ITU-T 2875 Recommendation X.509 [1]. 2877 Note: The name used by the signer, held as the subject in the signer's 2878 certificate, is allocated and verified on registration with the 2879 Certification Authority, either directly or indirectly through a 2880 Registration Authority, before being issued with a Certificate. 2882 The present document places no restrictions on the form of the name. 2883 The subject's name may be a distinguished name, as defined in ITU-T 2884 Recommendation X.500 [12], held in the subject field of the 2885 certificate, or any other name form held in the subjectAltName 2886 certificate extension field as defined in ITU-T Recommendation X.509 2887 [1]. In the case that the subject has no distinguished name, the 2888 subject name can be an empty sequence and the subjectAltName extension 2889 shall be critical. 2891 All Certification Authorities, Attribute Authorities and Time Stamping 2892 Authorities shall use distinguished names in the subject field of 2893 their certificate. 2895 The distinguished name shall include identifiers for the organization 2896 providing the service and the legal jurisdiction (e.g. country) under 2897 which it operates. 2899 Where a signer signs as an individual but wishes to also identify 2900 him/herself as acting on behalf of an organization, it may be necessary 2901 to provide two independent forms of identification. The first 2902 identity, with is directly associated with the signing key identifies 2903 Internet-draft CMS Advanced Electronic Signatures September 2007 2905 him/her as an individual. The second, which is managed independently, 2906 identifies that person acting as part of the organization, possibly 2907 with a given role. In this case one of the two identities is carried 2908 in the subject/subjectAltName field of the signer's certificate as 2909 described above. 2911 The present document does not specify the format of signer's attribute 2912 that may be included in public key certificates. 2914 NOTE : Signer's attribute may be supported by using a claimed role in 2915 the CMS signed attributes field or by placing an attribute 2916 certificate containing a certified role in the CMS signed 2917 attributes field, see section 7.6. 2919 7.6 Attribute certificate 2921 The syntax of the AttributeCertificate type is defined in RFC 3281 [13]. 2923 8. Conformance requirements 2925 For implementations supporting signature generation, the present 2926 document defines conformance requirements for the generation of two 2927 forms of basic electronic signature, one of the two forms must be 2928 implemented. 2930 For implementations supporting signature verification, the present 2931 document defines conformance requirements for the verification of two 2932 forms of basic electronic signature, one of the two forms must be 2933 implemented. 2935 The present document only defines conformance requirements up to an ES 2936 with Complete validation data (CAdES-C). This means that none of the 2937 extended and archive forms of Electronic Signature (CAdES-X, CAdES-A) 2938 need to be implemented to get conformance to the present document. 2940 On verification the inclusion of optional signed and unsigned 2941 attributes must be supported only to the extended that the signature is 2942 verifiable. The semantics of optional attributes may be unsupported, 2943 unless specified otherwise by a signature policy. 2945 8.1 CAdES-Basic Electronic Signature (CAdES-BES) 2947 A system supporting CAdES-BES signers according to the present 2948 document shall, at a minimum, support generation of an electronic 2949 signature consisting of the following components: 2951 - The general CMS syntax and content type as defined in RFC 3852 2952 [4] (see sections 5.1 and 5.2); 2954 - CMS SignedData as defined in RFC 3852 [4] with version set to 3 2955 and at least one SignerInfo shall be present (see sections 5.3 to 2956 5.6); 2958 Internet-draft CMS Advanced Electronic Signatures September 2007 2960 - The following CMS attributes as defined in RFC 3852 [4]: 2962 - content-type; this shall always be present 2963 (see section 5.7.1); and 2965 - message-digest; this shall always be present (see section 2966 5.7.2). 2968 - One of following attributes as defined in the present document: 2970 - signing-certificate: as defined in section 5.7.3.1; or 2971 - signing-certificate v2 : as defined in section 5.7.3.2. 2973 Note : RFC 3126 was using the other signing certificate attribute 2974 (see section 5.7.3.3). Its use is now deprecated, since the 2975 structure of the signing-certificate v2 attribute is simpler 2976 than the other signing certificate attribute. 2978 8.2 CAdES-Explicit Policy-based Electronic Signature 2980 A system supporting Policy-based signers according to the present 2981 document shall, at a minimum, support generation of an electronic 2982 signature consisting of the previous components defined for the basic 2983 signer, plus: 2985 - The following attributes as defined in section 5.9: 2987 - signature-policy-identifier; this shall always be present (see 2988 section 5.8.1). 2990 8.3 Verification using time-stamping 2992 A system supporting verifiers according to the present document with 2993 time-stamping facilities shall, at a minimum, support: 2995 - verification of the mandated components of an electronic 2996 signature, as defined in section 8.1; 2998 - signature-time-stamp attribute, as defined in section 6.1.1; 3000 - complete-certificate-references, attribute as defined in 3001 section 6.2.1; 3003 - complete-revocation-references attribute, as defined in 3004 section 6.2.2; 3006 - Public Key Certificates, as defined in ITU-T Recommendation X.509 3007 [1] (see section 8.1); and 3009 - either of: 3011 - Certificate Revocation Lists. as defined in ITU-T 3012 Recommendation X.509 [1] (see section 8.2); or 3014 Internet-draft CMS Advanced Electronic Signatures September 2007 3016 - on-line Certificate Status Protocol, as defined in RFC 2560 3017 [3] (see section 8.3). 3019 8.4 Verification using secure records 3021 A system supporting verifiers according to the present document shall, 3022 at a minimum, support: 3024 - verification of the mandated components of an electronic 3025 signature, as defined in section 8.1; 3027 - complete-certificate-references attribute, as defined in 3028 section 6.2.1; 3030 - complete-revocation-references attribute, as defined in 3031 section 6.2.2; 3033 - a record of the electronic signature and the time when the 3034 signature was first validated using the referenced certificates 3035 and revocation information must be maintained such that records 3036 cannot be undetectable modified; 3038 - Public Key Certificates, as defined in ITU-T Recommendation X.509 3039 [1] (see section 8.1); and 3041 - either of: 3043 - Certificate Revocation Lists. as defined in ITU-T 3044 Recommendation X.509 [1] (see section 8.2); or 3046 - on-line Certificate Status Protocol, as defined in RFC 2560 3047 [3] (see section 8.3). 3049 9. Security considerations 3051 9.1 Protection of private key 3053 The security of the electronic signature mechanism defined in the 3054 present document depends on the privacy of the signer's private key. 3056 Implementations should take steps to ensure that private keys cannot 3057 be compromised. 3059 9.2 Choice of algorithms 3061 Implementers should be aware that cryptographic algorithms become 3062 weaker with time. As new cryptoanalysis techniques are developed and 3063 computing performance improves, the work factor to break a particular 3064 cryptographic algorithm will reduce. Therefore, cryptographic 3066 algorithm implementations should be modular allowing new algorithms to 3067 be readily inserted. That is, implementers should be prepared for the 3068 set of mandatory to implement algorithms to change over time. 3070 Internet-draft CMS Advanced Electronic Signatures September 2007 3072 10. IANA Considerations 3074 No IANA actions required. 3076 11. References 3078 11.1 Normative references 3080 [1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001): 3081 "Information technology - Open Systems Interconnection - 3082 The Directory: Authentication framework". 3084 [2] IETF RFC 3280 (2002): "Internet X.509 Public Key 3085 Infrastructure Certificate and Certificate Revocation List 3086 (CRL) Profile". 3088 [3] IETF RFC 2560 (1999): "X.509 Internet Public Key 3089 Infrastructure Online Certificate Status Protocol - OCSP". 3091 [4] IETF RFC 3852 (2004): "Cryptographic Message Syntax (CMS)". 3093 [5] IETF RFC 2634 (1999): "Enhanced Security Services for 3094 S/MIME". 3096 [6] IETF RFC 2045 (1996): "Multipurpose Internet Mail Extensions 3097 (MIME) Part One: Format of Internet Message Bodies". 3099 [7] IETF RFC 3161 (2001): "Internet X.509 Public Key 3100 Infrastructure Time-Stamp Protocol ". 3102 [8] ITU-T Recommendation X.680 (1997): "Information technology - 3103 Abstract Syntax Notation One (ASN.1): Specification of basic 3104 notation". 3106 [9] ITU-T Recommendation X.501 (2000)/ISO/IEC 9594-1 (2001): 3107 "Information technology - Open Systems Interconnection - 3108 Directory models ". 3110 [10] IETF RFC 3370 (2002): "Cryptographic Message Syntax (CMS) 3111 Algorithms". 3113 [11] ITU-T Recommendation F.1: "Operational provisions for the 3114 international public telegram service". 3116 [12] ITU-T Recommendation X.500: "Information technology - Open 3117 Systems Interconnection - The Directory: Overview of 3118 concepts, models and services". 3120 [13] IETF RFC 3281 (2002): "An Internet Attribute Certificate 3121 Profile for Authorization". 3123 [14] ITU-T Recommendation X.208 (1988): "Specification of Abstract 3124 Syntax Notation One (ASN.1)". 3126 Internet-draft CMS Advanced Electronic Signatures September 2007 3128 [15] IETF RFC 5035 (2007). ESS Update: Adding CertID Algorithm 3129 Agility. 3131 11.2 Informative references 3133 ETSI technical specifications can be downloaded free of charge 3134 via the Services and Products Download Area at: 3135 http://www.etsi.org/services_products/freestandard/home.htm 3137 [EU Directive] Directive 1999/93/EC of the European Parliament and 3138 of the Council of 13 December 1999 on a Community framework for 3139 electronic signatures. 3141 [TS101733] ETSI Standard TS 101 733 V.1.7.3 (2005-06) Electronic 3142 Signature Formats. 3144 [TS101861] ETSI TS 101 861: "Time stamping profile". 3146 [TS101903] ETSI TS 101 903: "XML Advanced Electronic Signatures 3147 (XAdES)". 3149 [TS102023] ETSI TS 102 023: "Electronic Signatures and 3150 Infrastructures (ESI); Policy requirements for time-stamping 3151 authorities". 3153 [TR102038] ETSI TR 102 038: "Electronic Signatures and 3154 Infrastructures (ESI); XML format for signature policies". 3156 [TR102272] ETSI TR 102 272 V1.1.1 (2003-12). "Electronic Signatures 3157 and Infrastructures (ESI); ASN.1 format for signature policies". 3159 [RFC2246] IETF RFC 2246 (1999): "The TLS Protocol Version 1.0". 3161 [RFC2437] IETF RFC 2437 (1998): "PKCS #1: RSA Cryptography 3162 Specifications Version 2.0". 3164 [RFC2479] IETF RFC 2479 (1998): "Independent Data Unit Protection 3165 Generic Security Service Application Program Interface 3166 (IDUP-GSS-API)". 3168 [RFC2510] IETF RFC 2510 (1999): "Internet X.509 Public Key 3169 Infrastructure Certificate Management Protocols". 3171 [RFC2559] IETF RFC 2559 (2003): "Internet X.509 Public Key 3172 Infrastructure Operational Protocols - LDAPv2". 3174 [RFC2587] IETF RFC 2587 (1999): "Internet X.509 Public Key 3175 Infrastructure LDAPv2 Schema". 3177 [RFC3125] IETF RFC 3125 (2000): "Electronic Signature Policies". 3179 [RFC3851] IETF RFC 3851 (2004): �SMIME Version 3.1 Message 3180 Specification�. 3182 Internet-draft CMS Advanced Electronic Signatures September 2007 3184 [ISO7498-2] ISO 7498-2 (1989): "Information processing systems � 3185 Open Systems Interconnection - Basic Reference Model - Part 2: 3186 Security Architecture". 3188 [ISO9796-2] ISO/IEC 9796-2 (2002): "Information technology � 3189 Security techniques - Digital signature schemes giving message 3190 recovery - Part 2: Integer factorization based mechanisms". 3192 [ISO9796-4] ISO/IEC 9796-4 (1998): "Digital signature schemes 3193 giving message recovery - Part 4: Discrete logarithm based 3194 mechanisms". 3196 [ISO10118-1] ISO/IEC 10118-1 (2000): "Information technology � 3197 Security techniques - Hash-functions - Part 1: General". 3199 [ISO10118-2] ISO/IEC 10118-2 (2000): "Information technology � 3200 Security techniques - Hash-functions - Part 2: Hash-functions using 3201 an n-bit block cipher algorithm". 3203 [ISO10118-3] ISO/IEC 10118-3 (2004): "Information technology � 3204 Security techniques - Hash-functions - Part 3: Dedicated 3205 hash-functions". 3207 [ISO10118-4] ISO/IEC 10118-4 (1998): "Information technology � 3208 Security techniques - Hash-functions - Part 4: Hash-functions using 3209 modular arithmetic". 3211 [ISO10181-5] ISO/IEC 10181-5: Security Frameworks in Open Systems. 3212 Non-Repudiation Framework. April 1997. 3214 [ISO13888-1]ISO/IEC 13888-1 (2004): "IT security techniques � 3215 Non-repudiation - Part 1: General". 3217 [ISO14888-1] ISO/IEC 14888-1 (1998): "Information technology � 3218 Security techniques - Digital signatures with appendix - Part 1: 3219 General". 3221 [ISO14888-2] ISO/IEC 14888-2 (1999): "Information technology � 3222 Security techniques - Digital signatures with appendix - Part 2: 3223 Identity-based mechanisms". 3225 [ISO14888-3] ISO/IEC 14888-3 (1998): "Information technology � 3226 Security techniques - Digital signatures with appendix - Part 3: 3227 Certificate-based mechanisms". 3229 [ISO15946-2] ISO/IEC 15946-2 (2002): "Information technology � 3230 Security techniques - Cryptographic techniques based on elliptic 3231 curves - Part 2: Digital signatures". 3233 [ISO15946-3] ISO/IEC 15946-3 (2002): "Information technology � 3234 Security techniques - Cryptographic techniques based on elliptic 3235 curves - Part 3: Key establishment". 3237 Internet-draft CMS Advanced Electronic Signatures September 2007 3239 [X690] ITU-T Recommendation X.690 (2002): "Specification of basic 3240 encoding rules for Abstract Syntax Notation One (ASN.1)". 3242 [CWA14171] CWA 14171 CEN Workshop Agreements: "General Guidelines 3243 for Electronic Signature Verification". 3245 [XMLDSIG] XMLDSIG: W3C/IETF Recommendation (February 2002): 3246 "XML-Signature Syntax and Processing". 3248 [X9.30-1] ANSI X9.30-1 (1997): "Public Key Cryptography for the 3250 Financial Services Industry - Part 1: The Digital Signature 3251 Algorithm (DSA)". 3253 [X9.30-2] ANSI X9.30-2 (1997): "Public Key Cryptography for the 3254 Financial Services Industry - Part 2: The Secure Hash Algorithm 3255 (SHA-1)". 3257 [X9.31-1] ANSI X9.31-1 (1997): "Public Key Cryptography Using 3258 Reversible Algorithms for the Financial Services Industry - 3259 Part 1: The RSA Signature Algorithm". 3261 [X9.31-2] ANSI X9.31-2 (1996): "Public Key Cryptography Using 3262 Reversible Algorithms for the Financial Services Industry - 3263 Part 2: Hash Algorithms". 3265 [X9.62] ANSI X9.62 (1998): "Public Key Cryptography for the 3266 Financial Services Industry - The Elliptic Curve Digital Signature 3267 Algorithm (ECDSA)". 3269 [X.209] CCITT Recommendation X.209: Specification of Basic Encoding 3270 Rules for Abstract Syntax Notation One (ASN.1) 1988. 3272 [P1363] IEEE P1363 (2000): "Standard Specifications for Public-Key 3273 Cryptography". 3275 12. Authors' addresses 3277 Denis Pinkas 3278 Bull S.A.S. 3279 Rue Jean-Jaures 3280 78340 Les Clayes sous Bois CEDEX 3281 FRANCE 3282 EMail: Denis.Pinkas@bull.net 3284 Nick Pope 3285 Thales eSecurity 3286 Meadow View House 3287 Long Crendon 3288 Aylesbury 3289 Buck 3290 HP18 9EQ 3291 United Kingdom 3292 EMail: nick.pope@thales-esecurity.com 3294 Internet-draft CMS Advanced Electronic Signatures September 2007 3296 John Ross 3298 Security & Standards Consultancy Ltd 3299 The Waterhouse Business Centre 3300 2 Cromer Way 3301 Chelmsford 3302 Essex 3303 CM1 2QE 3304 United Kingdom 3305 EMail: ross@secstan.com 3307 13. Acknowledgments 3309 Special thanks to Russ Housley for reviewing the document. 3311 Internet-draft CMS Advanced Electronic Signatures September 2007 3313 Annex A (normative): ASN.1 definitions 3315 This annex provides a summary of all the ASN.1 syntax definitions for 3316 new syntax defined in the present document. 3318 A.1 Signature format definitions using X.208 ASN.1 syntax 3320 NOTE: The ASN.1 module defined in section A.1 using syntax defined in 3321 ITU-T Recommendation X.208 [14] has precedence over that 3322 defined in section A.2 in the case of any conflict. 3324 ETS-ElectronicSignatureFormats-ExplicitSyntax88 { iso(1) member-body(2) 3325 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 3326 eSignature-explicit88(28)} 3328 DEFINITIONS EXPLICIT TAGS ::= 3330 BEGIN 3332 -- EXPORTS All 3334 IMPORTS 3336 -- Cryptographic Message Syntax (CMS): RFC 3852 3338 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3339 EncapsulatedContentInfo, SignerInfo, id-contentType, 3340 id-messageDigest, MessageDigest, id-signingTime, SigningTime, 3341 id-countersignature, Countersignature 3342 FROM CryptographicMessageSyntax2004 3343 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3344 smime(16) modules(0) cms-2004(24) } 3346 -- ESS Defined attributes: ESS Update 3347 -- RFC 5035 (Adding CertID Algorithm Agility) 3349 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3350 id-aa-contentReference, ContentReference, id-aa-contentIdentifier, 3351 ContentIdentifier, id-aa-signingCertificatev2 3352 FROM ExtendedSecurityServices-2006 3353 { iso(1) member-body(2) us(840) rsadsi(113549) 3354 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 3356 -- Internet X.509 Public Key Infrastructure - Certificate and CRL 3357 -- Profile: RFC 3280 3359 Certificate, AlgorithmIdentifier, CertificateList, Name, 3360 DirectoryString, Attribute, BMPString, UTF8String 3361 FROM PKIX1Explicit88 3362 {iso(1) identified-organization(3) dod(6) internet(1) 3363 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} 3365 Internet-draft CMS Advanced Electronic Signatures September 2007 3367 GeneralNames, GeneralName, PolicyInformation 3368 FROM PKIX1Implicit88 3369 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 3370 mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit (19)} 3372 -- Internet Attribute Certificate Profile for Authorization - RFC 3281 3374 AttributeCertificate 3375 FROM PKIXAttributeCertificate {iso(1) identified-organization(3) 3376 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3377 id-mod(0) id-mod-attribute-cert(12)} 3379 -- OCSP - RFC 2560 3381 BasicOCSPResponse, ResponderID 3382 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 3383 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 3385 -- Time Stamp Protocol RFC 3161 3387 TimeStampToken 3388 FROM PKIXTSP 3389 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 3390 mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 3392 ; 3394 -- Definitions of Object Identifier arcs used in the present document 3395 -- ================================================================== 3397 -- OID used referencing electronic signature mechanisms based on 3398 -- the present document for use with the IDUP API (see annex D) 3400 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3401 { itu-t(0) identified-organization(4) etsi(0) 3402 electronic-signature-standard (1733) part1 (1) idupMechanism (4) 3403 etsiESv1(1) } 3405 -- Basic ES CMS Attributes Defined in the present document 3406 -- ======================================================= 3408 -- OtherSigningCertificate - deprecated 3410 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= 3411 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3412 smime(16) id-aa(2) 19 } 3414 Internet-draft CMS Advanced Electronic Signatures September 2007 3416 OtherSigningCertificate ::= SEQUENCE { 3417 certs SEQUENCE OF OtherCertID, 3418 policies SEQUENCE OF PolicyInformation OPTIONAL 3419 -- NOT USED IN THE PRESENT DOCUMENT 3420 } 3422 OtherCertID ::= SEQUENCE { 3423 otherCertHash OtherHash, 3424 issuerSerial IssuerSerial OPTIONAL } 3426 OtherHash ::= CHOICE { 3427 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3428 otherHash OtherHashAlgAndValue} 3430 -- Policy ES Attributes Defined in the present document 3431 -- ==================================================== 3433 -- Mandatory Basic Electronic Signature Attributes as above, 3434 -- plus in addition. 3436 -- Signature Policy Identifier 3438 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= 3439 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3440 smime(16) id-aa(2) 15 } 3442 SignaturePolicy ::= CHOICE { 3443 signaturePolicyId SignaturePolicyId, 3444 signaturePolicyImplied SignaturePolicyImplied 3445 -- not used in this version 3446 } 3448 SignaturePolicyId ::= SEQUENCE { 3449 sigPolicyId SigPolicyId, 3450 sigPolicyHash SigPolicyHash, 3451 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3452 SigPolicyQualifierInfo OPTIONAL 3453 } 3455 SignaturePolicyImplied ::= NULL 3457 SigPolicyId ::= OBJECT IDENTIFIER 3459 SigPolicyHash ::= OtherHashAlgAndValue 3461 OtherHashAlgAndValue ::= SEQUENCE { 3462 hashAlgorithm AlgorithmIdentifier, 3463 hashValue OtherHashValue } 3465 Internet-draft CMS Advanced Electronic Signatures September 2007 3467 OtherHashValue ::= OCTET STRING 3469 SigPolicyQualifierInfo ::= SEQUENCE { 3470 sigPolicyQualifierId SigPolicyQualifierId, 3471 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 3473 SigPolicyQualifierId ::= OBJECT IDENTIFIER 3475 id-spq-ets-uri OBJECT IDENTIFIER ::= 3476 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3477 smime(16) id-spq(5) 1 } 3479 SPuri ::= IA5String 3481 id-spq-ets-unotice OBJECT IDENTIFIER ::= 3482 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3483 smime(16) id-spq(5) 2 } 3485 SPUserNotice ::= SEQUENCE { 3486 noticeRef NoticeReference OPTIONAL, 3487 explicitText DisplayText OPTIONAL} 3489 NoticeReference ::= SEQUENCE { 3490 organization DisplayText, 3491 noticeNumbers SEQUENCE OF INTEGER } 3493 DisplayText ::= CHOICE { 3494 visibleString VisibleString (SIZE (1..200)), 3495 bmpString BMPString (SIZE (1..200)), 3497 utf8String UTF8String (SIZE (1..200)) } 3499 -- Optional Electronic Signature Attributes 3501 -- Commitment Type 3503 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3504 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3506 CommitmentTypeIndication ::= SEQUENCE { 3507 commitmentTypeId CommitmentTypeIdentifier, 3508 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3509 CommitmentTypeQualifier OPTIONAL} 3511 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3513 CommitmentTypeQualifier ::= SEQUENCE { 3514 commitmentTypeIdentifier CommitmentTypeIdentifier, 3515 qualifier ANY DEFINED BY commitmentTypeIdentifier } 3517 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3518 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 3519 Internet-draft CMS Advanced Electronic Signatures September 2007 3521 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3522 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 3524 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= 3525 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3526 smime(16) cti(6) 3} 3528 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3529 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 3531 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= 3532 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3533 smime(16) cti(6) 5} 3535 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= 3536 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3537 smime(16) cti(6) 6} 3539 -- Signer Location 3541 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3542 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3544 SignerLocation ::= SEQUENCE { 3545 -- at least one of the following shall be present 3546 countryName [0] DirectoryString OPTIONAL, 3547 -- As used to name a Country in X.500 3548 localityName [1] DirectoryString OPTIONAL, 3549 -- As used to name a locality in X.500 3550 postalAdddress [2] PostalAddress OPTIONAL } 3552 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 3554 -- Signer Attributes 3556 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3557 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3559 SignerAttribute ::= SEQUENCE OF CHOICE { 3560 claimedAttributes [0] ClaimedAttributes, 3561 certifiedAttributes [1] CertifiedAttributes } 3563 ClaimedAttributes ::= SEQUENCE OF Attribute 3565 CertifiedAttributes ::= AttributeCertificate 3566 -- as defined in RFC 3281 : see section 4.1 3568 -- Content Timestamp 3570 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= 3571 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3572 smime(16) id-aa(2) 20} 3574 ContentTimestamp ::= TimeStampToken 3576 Internet-draft CMS Advanced Electronic Signatures September 2007 3578 -- Signature Timestamp 3580 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= 3581 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3582 smime(16) id-aa(2) 14} 3584 SignatureTimeStampToken ::= TimeStampToken 3586 -- Complete Certificate Refs. 3588 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3589 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3591 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 3593 -- Complete Revocation Refs 3595 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3596 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3598 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3600 CrlOcspRef ::= SEQUENCE { 3601 crlids [0] CRLListID OPTIONAL, 3602 ocspids [1] OcspListID OPTIONAL, 3603 otherRev [2] OtherRevRefs OPTIONAL 3604 } 3606 CRLListID ::= SEQUENCE { 3607 crls SEQUENCE OF CrlValidatedID} 3609 CrlValidatedID ::= SEQUENCE { 3610 crlHash OtherHash, 3611 crlIdentifier CrlIdentifier OPTIONAL} 3613 CrlIdentifier ::= SEQUENCE { 3614 crlissuer Name, 3615 crlIssuedTime UTCTime, 3616 crlNumber INTEGER OPTIONAL } 3618 OcspListID ::= SEQUENCE { 3619 ocspResponses SEQUENCE OF OcspResponsesID} 3621 OcspResponsesID ::= SEQUENCE { 3622 ocspIdentifier OcspIdentifier, 3623 ocspRepHash OtherHash OPTIONAL 3624 } 3626 OcspIdentifier ::= SEQUENCE { 3627 ocspResponderID ResponderID, 3628 -- As in OCSP response data 3629 producedAt GeneralizedTime 3630 -- As in OCSP response data 3631 } 3633 Internet-draft CMS Advanced Electronic Signatures September 2007 3635 OtherRevRefs ::= SEQUENCE { 3636 otherRevRefType OtherRevRefType, 3637 otherRevRefs ANY DEFINED BY otherRevRefType 3638 } 3640 OtherRevRefType ::= OBJECT IDENTIFIER 3642 -- Certificate Values 3644 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3645 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3647 CertificateValues ::= SEQUENCE OF Certificate 3649 -- Certificate Revocation Values 3651 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 3652 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3653 smime(16) id-aa(2) 24} 3655 RevocationValues ::= SEQUENCE { 3656 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3657 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3658 otherRevVals [2] OtherRevVals OPTIONAL} 3660 OtherRevVals ::= SEQUENCE { 3661 otherRevValType OtherRevValType, 3662 otherRevVals ANY DEFINED BY otherRevValType 3663 } 3665 OtherRevValType ::= OBJECT IDENTIFIER 3667 -- CAdES-C Timestamp 3669 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3670 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 3672 ESCTimeStampToken ::= TimeStampToken 3674 -- Time-Stamped Certificates and CRLs 3676 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) 3677 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3678 smime(16) id-aa(2) 26} 3680 TimestampedCertsCRLs ::= TimeStampToken 3682 -- Archive Timestamp 3684 id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::= { iso(1) 3685 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3686 smime(16) id-aa(2) 48} 3687 Internet-draft CMS Advanced Electronic Signatures September 2007 3689 ArchiveTimeStampToken ::= TimeStampToken 3691 -- Attribute certificate references 3693 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) 3694 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3695 smime(16) id-aa(2) 44} 3697 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 3699 -- Attribute revocation references 3701 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) 3702 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3703 smime(16) id-aa(2) 45} 3705 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 3707 END 3708 Internet-draft CMS Advanced Electronic Signatures September 2007 3710 A.2 Signature format definitions using X.680 ASN.1 syntax 3712 NOTE: The ASN.1 module defined in section A.1 has precedence over that 3713 defined in section A.2 using syntax defined in ITU-T 3714 Recommendation X.680 (1997) [8] in the case of any conflict. 3716 ETS-ElectronicSignatureFormats-ExplicitSyntax97 { iso(1) member-body(2) 3717 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 3718 eSignature-explicit97(29)} 3720 DEFINITIONS EXPLICIT TAGS ::= 3722 BEGIN 3724 -- EXPORTS All - 3726 IMPORTS 3728 -- Cryptographic Message Syntax (CMS): RFC 3852 3730 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3731 EncapsulatedContentInfo, SignerInfo, 3732 id-contentType, id-messageDigest, MessageDigest, id-signingTime, 3733 SigningTime, id-countersignature, Countersignature 3734 FROM CryptographicMessageSyntax2004 3735 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3736 smime(16) modules(0) cms-2004(24) } 3738 -- ESS Defined attributes: ESS Update 3739 -- RFC 5035 (Adding CertID Algorithm Agility) 3741 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3742 id-aa-contentReference, ContentReference, id-aa-contentIdentifier, 3743 ContentIdentifier, id-aa-signingCertificatev2 3744 FROM ExtendedSecurityServices-2006 3745 { iso(1) member-body(2) us(840) rsadsi(113549) 3746 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 3748 -- Internet X.509 Public Key Infrastructure 3749 -- Certificate and CRL Profile: RFC 3280 3751 Certificate, AlgorithmIdentifier, CertificateList, Name, 3752 Attribute 3754 FROM PKIX1Explicit88 3755 {iso(1) identified-organization(3) dod(6) internet(1) 3756 security(5) mechanisms(5) pkix(7) id-mod(0) 3757 id-pkix1-explicit(18)} 3759 Internet-draft CMS Advanced Electronic Signatures September 2007 3761 GeneralNames, GeneralName, PolicyInformation 3762 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3763 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3764 id-pkix1-implicit(19)} 3766 -- Internet Attribute Certificate Profile for Authorization - RFC 3281 3768 AttributeCertificate 3769 FROM PKIXAttributeCertificate {iso(1) identified-organization(3) 3770 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3771 id-mod-attribute-cert(12)} 3773 -- OCSP RFC 2560 3775 BasicOCSPResponse, ResponderID 3776 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 3777 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 3779 -- RFC 3161 Internet X.509 Public Key Infrastructure 3780 -- Time-Stamp Protocol 3782 TimeStampToken 3783 FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) 3784 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 3786 -- X.520 3788 DirectoryString {} 3789 FROM SelectedAttributeTypes 3790 {joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4} 3792 ; 3794 -- Definitions of Object Identifier arcs used in the present document 3795 -- ================================================================== 3797 -- OID used referencing electronic signature mechanisms based 3798 -- on the present document for use with the IDUP API (see annex D) 3800 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3801 { itu-t(0) identified-organization(4) etsi(0) 3802 electronic-signature-standard (1733) part1 (1) idupMechanism (4) 3803 etsiESv1(1) } 3805 -- Basic ES Attributes Defined in the present document 3806 -- =================================================== 3808 -- CMS Attributes defined in the present document 3809 Internet-draft CMS Advanced Electronic Signatures September 2007 3811 -- OtherSigningCertificate - deprecated 3813 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 3814 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3815 smime(16) id-aa(2) 19 } 3817 OtherSigningCertificate ::= SEQUENCE { 3818 certs SEQUENCE OF OtherCertID, 3819 policies SEQUENCE OF PolicyInformation OPTIONAL 3820 -- NOT USED IN THE PRESENT DOCUMENT 3821 } 3823 OtherCertID ::= SEQUENCE { 3824 otherCertHash OtherHash, 3825 issuerSerial IssuerSerial OPTIONAL } 3827 OtherHash ::= CHOICE { 3828 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3829 otherHash OtherHashAlgAndValue} 3831 -- Policy ES Attributes Defined in the present document 3832 -- ==================================================== 3834 -- Mandatory Basic Electronic Signature Attributes, plus in addition. 3835 -- Signature Policy Identifier 3837 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 3838 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3839 smime(16) id-aa(2) 15 } 3841 SignaturePolicy ::= CHOICE { 3842 signaturePolicyId SignaturePolicyId, 3843 signaturePolicyImplied SignaturePolicyImplied 3844 -- not used in this version 3845 } 3847 SignaturePolicyId ::= SEQUENCE { 3848 sigPolicyId SigPolicyId, 3849 sigPolicyHash SigPolicyHash, 3850 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3851 SigPolicyQualifierInfo OPTIONAL 3852 } 3854 SignaturePolicyImplied ::= NULL 3856 SigPolicyId ::= OBJECT IDENTIFIER 3858 SigPolicyHash ::= OtherHashAlgAndValue 3860 OtherHashAlgAndValue ::= SEQUENCE { 3861 hashAlgorithm AlgorithmIdentifier, 3862 hashValue OtherHashValue 3863 } 3865 Internet-draft CMS Advanced Electronic Signatures September 2007 3867 OtherHashValue ::= OCTET STRING 3869 SigPolicyQualifierInfo ::= SEQUENCE { 3870 sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id 3871 ({SupportedSigPolicyQualifiers}), 3872 qualifier SIG-POLICY-QUALIFIER.&Qualifier 3873 ({SupportedSigPolicyQualifiers} 3874 {@sigPolicyQualifierId})OPTIONAL } 3876 SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 3877 { noticeToUser | pointerToSigPolSpec } 3879 SIG-POLICY-QUALIFIER ::= CLASS { 3880 &id OBJECT IDENTIFIER UNIQUE, 3881 &Qualifier OPTIONAL } 3882 WITH SYNTAX { 3883 SIG-POLICY-QUALIFIER-ID &id 3884 [SIG-QUALIFIER-TYPE &Qualifier] } 3886 noticeToUser SIG-POLICY-QUALIFIER ::= { 3887 SIG-POLICY-QUALIFIER-ID id-spq-ets-unotice SIG-QUALIFIER-TYPE 3888 SPUserNotice } 3890 pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { 3891 SIG-POLICY-QUALIFIER-ID id-spq-ets-uri SIG-QUALIFIER-TYPE SPuri } 3893 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 3894 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3895 smime(16) id-spq(5) 1 } 3897 SPuri ::= IA5String 3899 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 3900 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3901 smime(16) id-spq(5) 2 } 3903 SPUserNotice ::= SEQUENCE { 3904 noticeRef NoticeReference OPTIONAL, 3905 explicitText DisplayText OPTIONAL} 3907 NoticeReference ::= SEQUENCE { 3908 organization DisplayText, 3909 noticeNumbers SEQUENCE OF INTEGER } 3911 DisplayText ::= CHOICE { 3912 visibleString VisibleString (SIZE (1..200)), 3913 bmpString BMPString (SIZE (1..200)), 3914 utf8String UTF8String (SIZE (1..200)) } 3916 -- Optional Electronic Signature Attributes 3917 Internet-draft CMS Advanced Electronic Signatures September 2007 3919 -- Commitment Type 3921 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3922 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3924 CommitmentTypeIndication ::= SEQUENCE { 3925 commitmentTypeId CommitmentTypeIdentifier, 3926 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3927 CommitmentTypeQualifier OPTIONAL} 3929 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3931 CommitmentTypeQualifier ::= SEQUENCE { 3932 commitmentQualifierId COMMITMENT-QUALIFIER.&id, 3933 qualifier COMMITMENT-QUALIFIER.&Qualifier OPTIONAL } 3935 COMMITMENT-QUALIFIER ::= CLASS { 3936 &id OBJECT IDENTIFIER UNIQUE, 3937 &Qualifier OPTIONAL } 3938 WITH SYNTAX { 3939 COMMITMENT-QUALIFIER-ID &id 3940 [COMMITMENT-TYPE &Qualifier] } 3942 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3943 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 3945 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3946 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 3948 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 3949 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3950 cti(6) 3} 3952 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3953 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 3955 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= 3956 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3957 smime(16) cti(6) 5} 3959 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= 3960 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3961 smime(16) cti(6) 6} 3963 -- Signer Location 3965 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3966 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3967 Internet-draft CMS Advanced Electronic Signatures September 2007 3969 SignerLocation ::= SEQUENCE { 3970 -- at least one of the following shall be present 3971 countryName [0] DirectoryString{maxSize} OPTIONAL, 3972 -- as used to name a Country in X.520 3973 localityName [1] DirectoryString{maxSize} OPTIONAL, 3974 -- as used to name a locality in X.520 3975 postalAdddress [2] PostalAddress OPTIONAL } 3977 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize} 3978 -- maxSize parametrization as specified in X.683 3980 -- Signer Attributes 3982 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3983 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3985 SignerAttribute ::= SEQUENCE OF CHOICE { 3986 claimedAttributes [0] ClaimedAttributes, 3987 certifiedAttributes [1] CertifiedAttributes } 3989 ClaimedAttributes ::= SEQUENCE OF Attribute 3991 CertifiedAttributes ::= AttributeCertificate 3992 -- as defined in RFC 3281 : see section 4.1 3994 -- Content Timestamp 3996 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= 3997 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3998 smime(16) id-aa(2) 20} 4000 ContentTimestamp ::= TimeStampToken 4002 -- Signature Timestamp 4004 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= 4005 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 4006 smime(16) id-aa(2) 14} 4008 SignatureTimeStampToken ::= TimeStampToken 4010 -- Complete Certificate Refs. 4012 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 4013 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 4015 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 4017 -- Complete Revocation Refs 4019 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 4020 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 4022 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 4024 Internet-draft CMS Advanced Electronic Signatures September 2007 4026 CrlOcspRef ::= SEQUENCE { 4027 crlids [0] CRLListID OPTIONAL, 4028 ocspids [1] OcspListID OPTIONAL, 4029 otherRev [2] OtherRevRefs OPTIONAL 4030 } 4032 CRLListID ::= SEQUENCE { 4033 crls SEQUENCE OF CrlValidatedID 4034 } 4036 CrlValidatedID ::= SEQUENCE { 4037 crlHash OtherHash, 4038 crlIdentifier CrlIdentifier OPTIONAL 4039 } 4041 CrlIdentifier ::= SEQUENCE { 4042 crlissuer Name, 4043 crlIssuedTime UTCTime, 4044 crlNumber INTEGER OPTIONAL 4045 } 4047 OcspListID ::= SEQUENCE { 4048 ocspResponses SEQUENCE OF OcspResponsesID 4049 } 4051 OcspResponsesID ::= SEQUENCE { 4052 ocspIdentifier OcspIdentifier, 4053 ocspRepHash OtherHash OPTIONAL 4054 } 4056 OcspIdentifier ::= SEQUENCE { 4057 ocspResponderID ResponderID, 4058 -- As in OCSP response data 4059 producedAt GeneralizedTime 4060 -- As in OCSP response data 4061 } 4063 OtherRevRefs ::= SEQUENCE { 4064 otherRevRefType OTHER-REVOCATION-REF.&id, 4065 otherRevRefs SEQUENCE OF OTHER-REVOCATION-REF.&Type 4066 } 4068 OTHER-REVOCATION-REF ::= CLASS { 4069 &Type, 4070 &id OBJECT IDENTIFIER UNIQUE } 4071 WITH SYNTAX { 4072 WITH SYNTAX &Type ID &id } 4074 -- Certificate Values 4076 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 4077 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 4079 CertificateValues ::= SEQUENCE OF Certificate 4080 Internet-draft CMS Advanced Electronic Signatures September 2007 4082 -- Certificate Revocation Values 4084 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= 4085 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 4086 smime(16) id-aa(2) 24} 4088 RevocationValues ::= SEQUENCE { 4089 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 4090 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 4091 otherRevVals [2] OtherRevVals OPTIONAL 4092 } 4094 OtherRevVals ::= SEQUENCE { 4095 otherRevValType OTHER-REVOCATION-VAL.&id, 4096 otherRevVals SEQUENCE OF OTHER-REVOCATION-REF.&Type 4097 } 4099 OTHER-REVOCATION-VAL ::= CLASS { 4100 &Type, 4101 &id OBJECT IDENTIFIER UNIQUE } 4102 WITH SYNTAX { 4103 WITH SYNTAX &Type ID &id } 4105 -- CAdES-C Timestamp 4106 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 4107 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 4109 ESCTimeStampToken ::= TimeStampToken 4111 -- Time-Stamped Certificates and CRLs 4113 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= 4114 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 4115 smime(16) id-aa(2) 26} 4117 TimestampedCertsCRLs ::= TimeStampToken 4119 -- Archive Timestamp 4121 id-aa-ets-archiveTimestampV2 OBJECT IDENTIFIER ::= 4122 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 4123 smime(16) id-aa(2) 48} 4125 ArchiveTimeStampToken ::= TimeStampToken 4127 -- Attribute certificate references 4129 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= 4130 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 4131 smime(16) id-aa(2) 44} 4133 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 4135 Internet-draft CMS Advanced Electronic Signatures September 2007 4137 -- Attribute revocation references 4139 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= 4140 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 4141 smime(16) id-aa(2) 45} 4143 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 4145 END 4146 Internet-draft CMS Advanced Electronic Signatures September 2007 4148 Annex B (informative): Extended forms of Electronic Signatures 4150 Section 4 provides on overview of the various formats of electronic 4151 signatures included in the present document. This annex lists the 4152 attributes that need to be present in the various extended electronic 4153 signature formats and provide example validation sequences using the 4154 extended formats. 4156 B.1 Extended forms of validation data 4158 The complete validation data (CAdES-C) described in section 4.3 and 4159 illustrated in figure 3 may be extended to create Electronic Signatures 4160 with extended validation data. Some Electronic Signatures forms that 4161 include extended validation are explained below. 4163 An X-Long electronic signature (CAdES-X Long) is when the values of the 4164 certificates and revocation information are added to the CAdES-C. 4166 This form of Electronic Signature can be useful when the verifier does 4167 not have direct access to the following information: 4169 - the signer's certificate; 4171 - all the CA certificates that make up the full certification path; 4173 - all the associated revocation status information, as referenced 4174 in the CAdES-C. 4176 In some situations additional time-stamps may be created and added to 4177 the Electronic Signatures as additional attributes. For example: 4179 - time-stamping all the validation data as held with the ES (CAdES- 4180 C), this eXtended validation data is called a CAdES-X Type 1; or 4182 - time-stamping individual reference data as used for complete 4183 validation. This form of eXtended validation data is called an 4184 CAdES-X Type 2. 4186 NOTE 1: The advantages/drawbacks for CAdES-X Type 1 and CAdES-X Type 2 4187 are discussed in section C.4.4. 4189 The above time-stamp forms can be useful when it is required to counter 4190 the risk that any CA keys used in the certificate chain may be 4191 compromised. 4193 A combination of the two formats above may be used. This form of 4194 eXtended validation data is called an ES X-Long Type 1 or CAdES-X Long 4195 Type 2. This form of Electronic Signature can be useful when the 4196 verifier needs both the values and proof of when the validation data 4197 existed. 4199 Internet-draft CMS Advanced Electronic Signatures September 2007 4201 NOTE 2: The advantages/drawbacks for CAdES-X long Type 1 and CAdES-X 4202 long Type 2 are discussed in section C.4.6. 4204 B.1.1 CAdES-X Long 4206 An Electronic Signature with the additional validation data forming the 4207 CAdES-X Long form (CAdES-X-Long)) is illustrated in figure B.1 and 4208 comprises the following: 4210 - CAdES-BES or CAdES-EPES as defined in sections 4.3 , 5.7 or 5.8; 4212 - complete-certificate-references attribute as defined in section 4213 6.2.1; 4215 - complete-revocation-references attribute as defined in section 4216 6.2.2. 4218 The following attributes are required if a TSP is not providing a time- 4219 mark of the ES: 4221 - signature-time-stamp attribute as defined in section 6.1.1. 4223 The following attributes are required if the full certificate values 4224 and revocation values are not already included in the CAdES-BES or 4225 CAdES-EPES: 4227 - certificate-values attribute as defined in section 6.3.3; 4228 - revocation-values attribute, as defined in section 6.3.4. 4230 If attributes certificates are used then the following attributes may 4231 be present: 4233 - attribute-certificate-references attribute defined in section 4234 6.2.3; 4236 - attribute-revocation-references attribute as defined in section 4237 6.2.4. 4239 Other unsigned attributes may be present, but are not required. 4241 NOTE: Attribute certificate and revocation references are only 4242 present if a user attribute certificate is present in the 4243 electronic signature, see sections 6.2.2 and 6.2.3. 4245 Internet-draft CMS Advanced Electronic Signatures September 2007 4247 +---------------------- CAdES-X-Long --------------------------------+ 4248 |+-------------------------------------- CAdES-C ---+ | 4249 || +----------+ | +-------------+| 4250 ||+----- CAdES-BES or CAdES-EPES ----+ |Timestamp | | | || 4251 ||| | |over | | | Complete || 4252 |||+---------++----------++---------+| |digital | | | certificate || 4253 |||| || || || |signature | | | and || 4254 ||||Signer's || Signed ||Digital || | | | | revocation || 4255 ||||Document ||Attributes||signature|| |Optional | | | data || 4256 |||| || || || |when | | | || 4257 |||+---------++----------++---------+| |timemarked| | | || 4258 ||+----------------------------------+ +----------+ | | || 4259 || +-----------+| +-------------+| 4260 || |Complete || | 4261 || |certificate|| | 4262 || |and || | 4263 || |revocation || | 4264 || |references || | 4265 || +-----------+| | 4266 |+--------------------------------------------------+ | 4267 | | 4268 +--------------------------------------------------------------------+ 4270 Figure B.1 : Illustration of CAdES-X-Long 4272 B.1.2 CAdES-X Type 1 4274 An Electronic Signature with the additional validation data forming the 4275 eXtended Validation Data - Type 1 X is illustrated in figure B.2 and 4276 comprises the following: 4278 - the CAdES-BES or CAdES-EPES as defined in sections 4.2, 5.7 or 4279 5.8; 4281 - complete-certificate-references attribute as defined in section 4282 6.2.1; 4284 - complete-revocation-references attribute as defined in section 4285 6.2.2; 4287 - CAdES-C-Timestamp attribute, as defined in section 6.3.5. 4289 The following attributes are required if a TSP is not providing a time- 4290 mark of the ES: 4292 - signature-time-stamp attribute as defined in section 6.1.1. 4294 Internet-draft CMS Advanced Electronic Signatures September 2007 4296 If attributes certificates are used then the following attributes may 4297 be present: 4299 - attribute-certificate-references attribute defined in section 4300 6.2.3; 4302 - attribute-revocation-references attribute as defined in section 4303 6.2.4. 4305 Other unsigned attributes may be present, but are not required. 4307 +------------------------ CAdES-X-Type 1 ----------------------------+ 4308 |+---------------------------------- CAdES-C ------+ | 4309 || +----------+ | +-------------+ | 4310 ||+--- CAdES-BES or CAdES-EPES ------+|Timestamp | | | | | 4311 ||| ||over | | | | | 4312 |||+---------++----------++---------+||digital | | | | | 4313 ||||Signer's || Signed || Digital |||signature | | | Timestamp | | 4314 ||||Document ||Attributes||signature||| | | | over | | 4315 |||| || || |||Optional | | | CAdES-C | | 4316 |||+---------++----------++---------+||when | | | | | 4317 ||+----------------------------------+|timemarked| | | | | 4318 || +----------+ | | | | 4319 || +-----------+| +-------------+ | 4320 || |Complete || | 4321 || |certificate|| | 4322 || | and || | 4323 || |revocation || | 4324 || |references || | 4325 || +-----------+| | 4326 |+-------------------------------------------------+ | 4327 | | 4328 +--------------------------------------------------------------------+ 4330 Figure B.2 : Illustration of CAdES-X Type 1 4332 B.1.3 CAdES-X Type 2 4334 An Electronic Signature with the additional validation data forming the 4335 eXtended Validation Data - Type 2 X is illustrated in figure B.3. and 4336 comprises the following: 4338 - CAdES-BES or CAdES-EPES as defined in sections 4.2, 5.7 or 5.8; 4340 - complete-certificate-references attribute as defined in section 4341 6.2.1; 4343 - complete-revocation-references attribute as defined in section 4344 6.2.2; 4346 Internet-draft CMS Advanced Electronic Signatures September 2007 4348 - time-stamped-certs-crls-references attribute as defined in section 4349 6.3.6. 4351 The following attributes are required if a TSP is not providing a time- 4352 mark of the ES: 4354 - signature-time-stamp attribute as defined in section 6.1.1. 4356 If attributes certificates are used then the following attributes may 4357 be present: 4359 - attribute-certificate-references attribute defined in section 4360 6.2.3; 4362 - attribute-revocation-references attribute as defined in section 4363 6.2.4. 4365 Other unsigned attributes may be present, but are not required. 4367 +----------------------- CAdES-X-Type 2 -----------------------------+ 4368 |+-------------------------------------- CAdES-C --+ | 4369 || +----------+ | | 4370 ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | | | 4371 ||| ||over | | | 4372 |||+---------++----------++---------+||digital | | +-------------+ | 4373 |||| || || |||Signature | | | Timestamp | | 4374 ||||Signer's || Signed || Digital ||| | | | only over | | 4375 ||||Document ||Attributes||signature|||Optional | | | Complete | | 4376 |||| || || |||when | | | certificate | | 4377 |||+---------++----------++---------+||Timemarked| | | and | | 4378 ||+----------------------------------++----------+ | | revocation | | 4379 || +-----------+| | references | | 4380 || |Complete || +-------------+ | 4381 || |certificate|| | 4382 || |and || | 4383 || |revocation || | 4384 || |references || | 4385 || +-----------+| | 4386 |+-------------------------------------------------+ | 4387 | | 4388 +--------------------------------------------------------------------+ 4390 Figure B.3 : Illustration of CAdES-X Type 2 4392 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 4394 An Electronic Signature with the additional validation data forming the 4395 CAdES-X Long Type 1 and CAdES-X Long Type 2 is illustrated in 4396 figure B.4 and comprises the following: 4398 Internet-draft CMS Advanced Electronic Signatures September 2007 4400 - CAdES-BES or CAdES-EPES as defined in sections 4.3, 5.7 or 5.8; 4402 - complete-certificate-references attribute as defined in section 4403 6.2.1; 4405 - complete-revocation-references attribute as defined in section 4406 6.2.2; 4408 The following attributes are required if a TSP is not providing a time- 4409 mark of the ES: 4411 - signature-time-stamp attribute as defined in section 6.1.1. 4413 The following attributes are required if the full certificate values 4414 and revocation values are not already included in the CAdES-BES or 4415 CAdES-EPES: 4416 - certificate-values attribute as defined in section 6.3.3; 4417 - revocation-values attribute, as defined in section 6.3.4. 4419 If attributes certificates are used then the following attributes may 4420 be present: 4422 - attribute-certificate-references attribute defined in section 4423 6.2.3; 4425 - attribute-revocation-references attribute as defined in section 4426 6.2.4. 4428 Plus one of the following attributes is required: 4430 - CAdES-C-Timestamp attribute, as defined in section 6.3.5; 4431 - time-stamped-certs-crls-references attribute as defined in section 4432 6.3.6. 4434 Other unsigned attributes may be present, but are not required. 4436 Internet-draft CMS Advanced Electronic Signatures September 2007 4438 +---------------------- CAdES-X-Type 1 or 2 ------------------------+ 4439 | +--------------+| 4440 |+-------------------------------------- CAdES-C --+|+------------+|| 4441 || +----------+ ||| Timestamp ||| 4442 ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | ||| over ||| 4443 ||| ||over | ||| CAdES-C ||| 4444 |||+---------++----------++---------+||digital | | +------------+ | 4445 |||| || || |||signature | || or || 4446 ||||Signer's || Signed || Digital ||| | ||+------------+|| 4447 ||||Document ||Attributes||Signature|||Optional | ||| Timestamp ||| 4448 |||| || || |||when | ||| only over ||| 4449 |||+---------++----------++---------+||timemarked| ||| complete ||| 4450 ||+----------------------------------++----------+ ||| certificate||| 4451 || ||| and ||| 4452 || +-----------+||| revocation ||| 4453 || |Complete |||| references ||| 4454 || |certificate|||+------------+|| 4455 || |and ||+--------------+| 4456 || |revocation || +------------+ | 4457 || |references || |Complete | | 4458 || +-----------+| |certificate | | 4459 |+-------------------------------------------------+ | and | | 4460 | |revocation | | 4461 | | values | | 4462 | +------------+ | 4463 +-------------------------------------------------------------------+ 4465 Figure B.4 : Illustration of CAdES-X Long Type 1 4466 and CAdES-X Long Type 2 4468 B.2 Timestamp extensions 4470 Each instance of time-stamp attribute may include as unsigned 4471 attributes in the signedData of the timestamp the following attribute 4472 related to the TSU: 4474 - complete-certificate-references attribute of the TSU as defined 4475 in section 6.2.1; 4477 - complete-revocation-references attribute of the TSU as defined in 4478 section 6.2.2; 4480 - certificate-values attribute; of the TSU as defined in section 4481 6.3.3; 4483 - revocation-values attribute, of the TSU as defined in section 4484 6.3.4. 4486 Other unsigned attributes may be present, but are not required. 4488 Internet-draft CMS Advanced Electronic Signatures September 2007 4490 B.3 Archive validation data (CAdES-A) 4492 Before the algorithms, keys and other cryptographic data used at the 4493 time the CAdES-C was built become weak and the cryptographic functions 4494 become vulnerable, or the certificates supporting previous time-stamps 4495 expires, the signed data, the CAdES-C and any additional information 4496 (i.e. any CAdES-X) should be time-stamped. If possible this should use 4497 stronger algorithms (or longer key lengths) than in the original time- 4498 stamp. This additional data and time-stamp is called Archive 4499 Validation Data required for the ES Archive format (CAdES-A). The 4500 Time-stamping process may be repeated every time the protection used to 4501 time-stamp a previous CAdES-A becomes weak. An CAdES-A may thus bear 4502 multiple embedded time stamps. 4504 An example of an Electronic Signature (ES), with the additional 4505 validation data for the CAdES-C and CAdES-X forming the CAdES-A is 4506 illustrated in figure B.5. 4508 +--------------------------- CAdES-A---------------------------------+ 4509 |+----------------------------------------------------+ | 4510 || +--------------+| +----------+ | 4511 ||+--------------------- CAdES-C ----+|+------------+|| | | | 4512 ||| +----------+ ||| Timestamp ||| | | | 4513 |||+-- CAdES-BES ------+|Timestamp | ||| over ||| | | | 4514 |||| or CAdES-EPES ||over | ||| CAdES-C ||| | Archive | | 4515 |||| ||digital | ||+------------+|| | | | 4516 |||| ||signature | || or || |Timestamp | | 4517 |||| || | ||+------------+|| | | | 4518 |||| ||optional | ||| Timestamp ||| | | | 4519 |||| ||when | ||| only over ||| | | | 4520 |||| ||timemarked| ||| complete ||| | | | 4521 |||+-------------------++----------+ ||| certificate||| +----------+ | 4522 ||| ||| and ||| | 4523 ||| +-------------+||| revocation ||| | 4524 ||| | Complete |||| references ||| | 4525 ||| | certificate |||+------------+|| | 4526 ||| | and ||+--------------+| | 4527 ||| | revocation || +------------+ | | 4528 ||| | references || |Complete | | | 4529 ||| +-------------+| |certificate | | | 4530 ||+----------------------------------+ | and | | | 4531 || |revocation | | | 4532 || | values | | | 4533 || +------------+ | | 4534 |+----------------------------------------------------+ | 4535 +--------------------------------------------------------------------+ 4537 Figure B.5 : Illustration of CAdES-A 4539 Internet-draft CMS Advanced Electronic Signatures September 2007 4541 The CAdES-A comprises the following elements: 4543 - the CAdES-BES or CAdES-EPES including their signed and unsigned 4544 attributes; 4546 - complete-certificate-references attribute as defined in section 4547 6.2.1; 4549 - complete-revocation-references attribute as defined in section 4550 6.2.2. 4552 The following attributes are required if a TSP is not providing a time- 4553 mark of the ES: 4554 - signature-time-stamp attribute as defined in section 6.1.1. 4556 If attributes certificates are used then the following attributes may 4557 be present: 4559 - attribute-certificate-references attribute defined in section 4560 6.2.3; 4561 - attribute-revocation-references attribute as defined in section 4562 6.2.4. 4564 The following attributes are required if the full certificate values 4565 and revocation values are not already included in the CAdES-BES or 4566 CAdES-EPES: 4568 - certificate-values attribute as defined in section 6.3.3; 4569 - revocation-values attribute as defined in section 6.3.4. 4571 At least one of the following two attributes is required: 4573 - CAdES-C-Timestamp attribute as defined in section 6.3.5; 4575 - time-stamped-certs-crls-references attribute as defined in section 4576 6.3.6. 4578 The following attribute is required: 4580 - archive-time-stamp attributes defined in section 6.4.1. 4582 Several instances of archive-time-stamp attribute may occur with an 4583 electronic signature both over time and from different TSUs. The time- 4584 stamp should be created using stronger algorithms (or longer key 4585 lengths) than in the original electronic signatures or time-stamps. 4587 Other unsigned attributes of the ES may be present, but are not 4588 required. 4590 Internet-draft CMS Advanced Electronic Signatures September 2007 4592 The archive timestamp will itself contain the certificate and 4593 revocation information required to validate the archive timestamp, this 4594 may include the following unsigned attributes: 4596 - complete-certificate-references attribute of the TSU as defined 4597 in section 6.2.1; 4599 - complete-revocation-references attribute of the TSU as defined in 4600 section 6.2.2; 4602 - certificate-values attribute of the TSU as defined in section 4603 6.3.3; 4605 - revocation-values attribute of the TSU as defined in section 4606 6.3.4. 4608 Other unsigned attributes may be present, but are not required. 4610 B.4 Example validation sequence 4612 As described earlier the signer or initial verifier may collect all the 4613 additional data that forms the electronic signature. Figure B.6, and 4614 subsequent description, describes how the validation process may build 4615 up a complete electronic signature over time. 4617 Internet-draft CMS Advanced Electronic Signatures September 2007 4619 +------------------------------------------ CAdES-C -------------+ 4620 |+------------------------------- CAdES-T ------+ | 4621 ||+-------------- CAdES ------------+ | | 4622 |||+--------------------++---------+|+---------+| +-----------+ | 4623 |||| ________ || |||Timestamp|| |Complete | | 4624 |||||Sign.Pol| ||Digital |||over || |certificate| | 4625 ||||| Id. | Signed ||signature|||digital || | and | | 4626 ||||| option.|attributes|| |||signature|| |revocation | | 4627 |||||________| |+---------+|+---------+| |references | | 4628 |||+--------------------+ | ^ | +-----------+ | 4629 ||+---------------------------------+ | | ^ | 4630 || 1 | / | | | 4631 |+---------------------- | ------------/--------+ | | 4632 +----------------------- | ---------- / --------------- / -------+ 4633 | /2 ----3-------- 4634 +----------+ | / / 4635 | | v / | 4636 | Signer's | +---------------------+ +-------------+ 4637 | document |----->| Validation Process |---->|- Valid | 4638 | | +---------------------+ 4 |- Invalid | 4639 +----------+ | ^ | ^ |- Validation | 4640 v | v | | Incomplete | 4641 +---------+ +--------+ +-------------+ 4642 |Signature| |Trusted | 4643 | Policy | |Service | 4644 | Issuer | |Provider| 4645 +---------+ +--------+ 4647 Figure B.6 : Illustration of a CAdES validation sequence 4649 Soon after receiving the Electronic Signature (CAdES) from the signer 4650 (1), the digital signature value may be checked; the validation process 4651 shall at least add a time-stamp (2), unless the signer has provided one 4652 which is trusted by the verifier. The validation process may also 4653 validate the electronic signature, using additional data (e.g. 4654 certificates, CRL, etc.) provided by trusted service providers. When 4655 applicable, the validation process will also need to conform to the 4656 requirements specified in a signature policy. If the validation 4657 process is validation incomplete, then the output from this stage is 4658 the CAdES-T. 4660 To ascertain the validity status as Valid or Invalid and communicate 4661 that to the user (4) all the additional data required to validate the 4662 CAdES-C, must be available (e.g. the complete certificate and 4663 revocation information). 4665 Once the data needed to complete validation data references (CAdES-C) 4666 is available then the validation process should: 4668 - obtain all the necessary additional certificate and revocation 4669 status information; 4671 Internet-draft CMS Advanced Electronic Signatures September 2007 4673 - complete all the validation checks on the ES, using the complete 4674 certificate and revocation information (if a time-stamp is not 4675 already present, this may be added at the same stage combining 4676 CAdES-T and CAdES-C process); 4678 - record the complete certificate and revocation references (3); 4680 - indicate the validity status to the user (4). 4682 At the same time as the validation process creates the CAdES-C, the 4683 validation process may provide and/or record the values of certificates 4684 and revocation status information used in CAdES-C, called the CAdES-X 4685 Long (5). 4687 This is illustrated in figure B.7. 4689 +----------------------------------------------------- CAdES-X Long -+ 4690 |+------------------------------- CAdES-C -------------+ | 4691 ||+-------------- CAdES ------------+ | | 4692 |||+--------------------++---------+|+---------+ |+-----------+| 4693 |||| ________ || |||Timestamp| ||Complete || 4694 |||||Sign.Pol| ||Digital |||over | ||certificate|| 4695 ||||| Id. | Signed ||signature|||digital | || and || 4696 ||||| option.|attributes|| |||signature| ||revocation || 4697 |||||________| || ||+---------+ || values || 4698 |||+--------------------++---------+| ^ +-----------+|+-----------+| 4699 ||+---------------------------------+ | |Complete || ^ | 4700 || | | |certificate|| | | 4701 || | 2 | | and || | | 4702 || | | |revocation || | | 4703 || | | |references || | | 4704 || 1 | / +-----------+| | | 4705 |+------------------------ | ------- / --------- ^-----+ / | 4706 +------------------------- | ------ / ---------- |--------- / -------+ 4707 | / ----- / ------- / 4708 +----------+ | / / 3 / 5 4709 | | v | | | 4710 | Signer's | +--------------------+ +-----------+ 4711 | document |----->| Validation Process |----->| - Valid | 4712 | | +--------------------+ 4 | - Invalid | 4713 +----------+ | ^ | ^ +-----------+ 4714 v | v | 4715 +---------+ +--------+ 4716 |Signature| |Trusted | 4717 | Policy | |Service | 4718 | Issuer | |Provider| 4719 +---------+ +--------+ 4721 Figure B.7 : Illustration of a CAdES validation sequence 4722 with CAdES-X Long 4724 Internet-draft CMS Advanced Electronic Signatures September 2007 4726 When the validation process creates the CAdES-C it may also create 4727 extended forms of validation data. 4729 A first alternative is to time-stamp all data forming the CAdES-X Type 4730 1 (6). 4732 This is illustrated in figure B.8. 4734 +------------------------------------------------ CAdES-X Type 1 -----+ 4735 |+------------------------------- CAdES-C ------------------+ | 4736 ||+-------------- CAdES ------------+ | | 4737 |||+--------------------++---------+|+---------++----------+|+-------+| 4738 |||| ________ || |||Timestamp|| Complete ||| || 4739 |||||Sign.Pol| ||Digital |||over || cert. |||Time- || 4740 ||||| Id. | Signed ||signature|||digital || and |||stamp || 4741 ||||| option.|attributes|| |||signature|| revoc. ||| over || 4742 |||||________| |+---------+|+---------+|references|||CAdES-C|| 4743 |||+--------------------+ | ^ | ||| || 4744 ||+---------------------------------+ | +----------+|+-------+| 4745 || | | ^ | ^ | 4746 || 1 | / | | | | 4747 |+------------------------ | --------- / ----------- / -----+ | | 4748 +------------------------- | -------- / ----------- / --------- / ----+ 4749 | 2 / ---3---- / 4750 +----------+ | / / -----------5------ 4751 | | v | | / 4752 | Signer's | +--------------------+ +-----------+ 4753 | document |----->| Validation Process |-----> | - Valid | 4754 | | +--------------------+ 4 | - Invalid | 4755 +----------+ | ^ | ^ +-----------+ 4756 v | v | 4757 +---------+ +--------+ 4758 |Signature| |Trusted | 4759 | Policy | |Service | 4760 | Issuer | |Provider| 4761 +---------+ +--------+ 4763 Figure B.8 : Illustration of CAdES with eXtended Validation Data 4764 CAdES-X Type 1 4766 Another alternative is to time-stamp the certificate and revocation 4767 information references used to validate the electronic signature (but 4768 not the signature) (6'); this is called CAdES-X Type 2. 4770 This is illustrated in figure B.9. 4772 Internet-draft CMS Advanced Electronic Signatures September 2007 4774 +-------------------------------------------- CAdES-X Type 2 --------+ 4775 |+------------------------------- CAdES-C -------------+ | 4776 ||+-------------- CAdES ------------+ | | 4777 |||+--------------------++---------+|+---------+ |+-----------+| 4778 |||| ________ || |||Timestamp| ||Timestamp || 4779 |||||Sign.Pol| || |||over | || over || 4780 ||||| Id. | Signed ||Digital |||digital | ||complete || 4781 ||||| option.|attributes||signature|||signature| ||certificate|| 4782 |||||________| || ||| | || || 4783 |||+--------------------++---------+|+---------+ || and || 4784 ||+---------------------------------+ ^ +-----------+||revocation || 4785 || | | |Complete |||references || 4786 || | | |certificate||+-----------+| 4787 || | | | and || ^ | 4788 || 1 | 2 | |revocation || | | 4789 || | | |references || | | 4790 || | | +-----------+| | | 4791 |+------------------------ | --------- | --- ^ --------+ | | 4792 | | | 3 | / | 4793 | | | / ---------- | 4794 | | / / / 5 | 4795 | | / / / | 4796 | | / / / | 4797 +------------------------- | ----- | -- | -- / ----------------------+ 4798 | | | | 4799 v | | | 4800 +--------------------+ +-----------+ 4801 | Validation Process |----->| - Valid | 4802 +--------------------+ 4 | - Invalid | 4803 | ^ | ^ +-----------+ 4804 v | v | 4805 +---------+ +--------+ 4806 |Signature| |Trusted | 4807 | Policy | |Service | 4808 | Issuer | |Provider| 4809 +---------+ +--------+ 4811 Figure B.9: Illustration of CAdES with eXtended Validation Data 4812 CAdES-X Type 2 4814 Before the algorithms used in any of electronic signatures become or 4815 are likely, to be compromised or rendered vulnerable in the future, it 4816 may be necessary to time-stamp the entire electronic signature, 4817 including all the values of the validation and user data as an ES with 4818 Archive Validation Data (CAdES-A) (7). 4820 Internet-draft CMS Advanced Electronic Signatures September 2007 4822 An CAdES-A is illustrated in figure B.10. 4824 +----------------------------- CAdES-A ---------------------------+ 4825 | | 4826 | +-- CAdES-X Long Type 1 or 2 ----------+ | 4827 | | | +------------+ | 4828 | | | | | | 4829 | | | | Archive | | 4830 | | | | Time-stamp | | 4831 | | | | | | 4832 | | | +------------+ | 4833 | +---------------------------------------+ ^ | 4834 | +----------+ ^ ^ ^ ^ | | 4835 | | | | | | | / | 4836 | | Signers' | | | | | / | 4837 | | Document |\ | | | | / | 4838 | | | \ 1 2 | 3 | 5 | 6 | 7 / | 4839 | +----------+ \ | | | | / | 4840 | \ | | | | / | 4841 +----------------- \ --- | - | - | - | ------ / ------------------+ 4842 \ | | | | | 4843 | | | | | | 4844 | | | | | | 4845 v v | | | | 4846 +-----------------------------+ +-----------+ 4847 | Validation Process |----->| - Valid | 4848 +-----------------------------+ 4 | - Invalid | 4849 | ^ | ^ +-----------+ 4850 v | v | 4851 +---------+ +--------+ 4852 |Signature| |Trusted | 4853 | Policy | |Service | 4854 | Issuer | |Provider| 4855 +---------+ +--------+ 4857 Figure B.10: Illustration of CAdES-A 4859 B.5 Additional optional features 4861 The present document also defines additional optional features to: 4863 - indicate a commitment type being made by the signer; 4865 - indicate the claimed time when the signature was done; 4867 - indicate the claimed location of the signer; 4869 - indicate the claimed or certified role under which a signature 4870 was created; 4872 - support counter signatures; 4874 - support multiple signatures. 4876 Internet-draft CMS Advanced Electronic Signatures September 2007 4878 Annex C (informative):General description 4880 This annex explains some of the concepts and provides the rational for 4881 normative parts of the present document. 4883 The specification below includes a description why and when the each 4884 component of an electronic signature is useful, with a brief 4885 description of the vulnerabilities and threats and the manner by which 4886 they are countered. 4888 C.1 The signature policy 4890 The signature policy is a set of rules for the creation and validation 4891 of an electronic signature, under which the signature can be determined 4892 to be valid. A given legal/contractual context may recognize a 4893 particular signature policy as meeting its requirements. A signature 4894 policy may be issued, for example, by a party relying on the electronic 4895 signatures and selected by the signer for use with that relying party. 4896 Alternatively, a signature policy may be established through an 4897 electronic trading association for use amongst its members. Both the 4898 signer and verifier use the same signature policy. 4900 The signature policy may be explicitly identified or may be implied by 4901 the semantics of the data being signed and other external data like a 4902 contract being referenced which itself refers to a signature policy. 4903 An explicit signature policy has a globally unique reference, which is 4904 bound to an electronic signature by the signer as part of the signature 4905 calculation. 4907 The signature policy needs to be available in human readable form so 4908 that it can be assessed to meet the requirements of the legal and 4909 contractual context in which it is being applied. To facilitate the 4910 automatic processing of an electronic signature the parts of the 4911 signature policy which specifies the electronic rules for the creation 4912 and validation of the electronic signature also needs to be 4913 comprehensively defined and in a computer processable form. 4915 The signature policy thus includes the following: 4917 - rules, which apply to technical validation of a particular 4918 signature; 4920 - rules which may be implied through adoption of Certificate 4921 Policies that apply to the electronic signature (e.g. rules for 4922 ensuring the secrecy of the private signing key); 4924 - rules, which relate to the environment used by the signer, e.g. 4925 the use of an agreed CAD (Card Accepting Device) used in 4926 conjunction with a smart card. 4928 Internet-draft CMS Advanced Electronic Signatures September 2007 4930 For example, the major rules required for technical validation can 4931 include: recognized root keys or "top-level certification authorities", 4932 acceptable certificate policies (if any), necessary certificate 4933 extensions and values (if any), the need for the revocation status for 4934 each component of the certification tree, acceptable TSAs (if time- 4935 stamp tokens are being used), acceptable organizations for keeping the 4936 audit trails with time-marks (if time-marking is being used), 4937 acceptable AAs (if any are being used).as well as rules defining the 4938 components of the electronic signature that shall be provided by the 4939 signer with data required by the verifier when required to provide long 4940 term proof. 4942 C.2 Signed information 4944 The information being signed may be defined as a MIME-encapsulated 4945 message which can be used to signal the format of the content in order 4946 to select the right display or application. It can be composed of 4947 formatted data, free text or fields from an electronic form (e-form). 4948 For example, the Adobe(tm) format "pdf" may be used or the eXtensible 4949 Mark up Language (XML). Annex D defines how the content may be 4950 structured to indicate the type of signed data using MIME. 4952 C.3 Components of an electronic signature 4954 C.3.1 Reference to the signature policy 4956 When two independent parties want to evaluate an electronic signature, 4957 it is fundamental that they get the same result. This requirement can 4958 be met using comprehensive signature policies that ensure consistency 4959 of signature validation. Signature policies can be identified 4960 implicitly by the data being signed or they can be explicitly 4961 identified using the CAdES-EPES form of electronic signature, the 4962 CAdES-EPES mandates a consistent signature policy must be used by both 4963 the signer and verifier. 4965 By signing over the signature policy identifier in the CAdES-EPES the 4966 signer explicitly indicates that he or she has applied the signature 4967 policy in creating the signature. 4969 In order to unambiguously identify the details of an explicit signature 4970 policy that is to be used to verify a CAdES-EPES the signature an 4971 identifier and hash of the "Signature policy" shall be part of the 4972 signed data. Additional information about the explicit policy (e.g. 4973 web reference to the document) may be carried as "qualifiers" to the 4974 signature policy identifier. 4976 In order to unambiguously identify the authority responsible for 4977 defining an explicit signature policy the "Signature policy" can be 4978 signed. 4980 Internet-draft CMS Advanced Electronic Signatures September 2007 4982 C.3.2 Commitment type indication 4984 The commitment type can be indicated in the electronic signature 4985 either: 4987 - explicitly using a "commitment type indication" in the electronic 4988 signature; 4990 - implicitly or explicitly from the semantics of the signed data. 4992 If the indicated commitment type is explicit using a "commitment type 4993 indication" in the electronic signature, acceptance of a verified 4994 signature implies acceptance of the semantics of that commitment type. 4995 The semantics of explicit commitment types indications may be subject 4996 to signer and verifier agreement, specified as part of the signature 4997 policy or registered for generic use across multiple policies. 4999 If a CAdES-EPES electronic signature format is used and the electronic 5000 signature includes a commitment type indication other than one of those 5001 recognized under the signature policy the signature shall be treated as 5002 invalid. 5004 How commitment is indicated using the semantics of the data being 5005 signed is outside the scope of the present document. 5007 NOTE: Examples of commitment indicated through the semantics of the 5008 data being signed, are: 5010 - an explicit commitment made by the signer indicated by the type 5011 of data being signed over. Thus, the data structure being signed 5012 can have an explicit commitment within the context of the 5013 application (e.g. EDIFACT purchase order); 5015 - an implicit commitment which is a commitment made by the signer 5016 because the data being signed over has specific semantics 5017 (meaning) which is only interpretable by humans, (i.e. free 5018 text). 5020 C.3.3 Certificate identifier from the signer 5022 In many real life environments users will be able to get from different 5023 CAs or even from the same CA, different certificates containing the 5024 same public key for different names. The prime advantage is that a 5025 user can use the same private key for different purposes. Multiple use 5026 of the private key is an advantage when a smart card is used to protect 5027 the private key, since the storage of a smart card is always limited. 5028 When several CAs are involved, each different certificate may contain a 5029 different identity, e.g. as a national or as an employee from a 5030 company. Thus when a private key is used for various purposes, the 5031 certificate is needed to clarify the context in which the private key 5032 was used when generating the signature. Where there is the possibility 5033 that multiple private keys are used, it is necessary for the signer to 5034 indicate to the verifier the precise certificate to be used. 5036 Internet-draft CMS Advanced Electronic Signatures September 2007 5038 Many current schemes simply add the certificate after the signed data 5039 and thus are vulnerable to substitution attacks. If the certificate 5040 from the signer was simply appended to the signature and thus not 5041 protected by the signature, any one could substitute one certificate by 5042 another and the message would appear to be signed by some one else. In 5043 order to counter this kind of attack, the identifier of the signer has 5044 to be protected by the digital signature from the signer. 5046 In order to identify unambiguously the certificate to be used for the 5047 verification of the signature an identifier of the certificate from the 5048 signer shall be part of the signed data. 5050 C.3.4 Role attributes 5052 While the name of the signer is important, the position of the signer 5053 within a company or an organization of paramount importance as well. 5054 Some information (i.e. a contract) may only be valid if signed by a 5055 user in a particular role, e.g. a Sales Director. In many cases who 5056 the sales Director really is, is not that important but being sure that 5057 the signer is empowered by his company to be the Sales Director is 5058 fundamental. 5060 The present document defines two different ways for providing this 5061 feature: 5063 - by placing a claimed role name in the CMS signed attributes 5064 field; 5066 - by placing an attribute certificate containing a certified role 5067 name in the CMS signed attributes field. 5069 NOTE: Another possible approach would have been to use additional 5070 attributes containing the roles name(s) in the signer's 5071 identity certificate However, it was decided not to follow 5072 this approach as it significantly complicates the management 5073 of certificates. For example by using separate certificates 5074 for signer's identity and roles means new identity keys need 5075 not be issued if a user's role changes. 5077 C.3.4.1 Claimed role 5079 The signer may be trusted to state his own role without any certificate 5080 to corroborate this claim. In which case the claimed role can be added 5081 to the signature as a signed attribute. 5083 Internet-draft CMS Advanced Electronic Signatures September 2007 5085 C.3.4.2 Certified role 5087 Unlike public key certificates that bind an identifier to a public key, 5088 Attribute Certificates bind the identifier of a certificate to some 5089 attributes, like a role. An Attribute Certificate is NOT issued by a 5090 CA but by an Attribute Authority (AA). The Attribute Authority in most 5091 cases might be under the control of an organization or a company that 5092 is best placed to know which attributes are relevant for which 5093 individual. The Attribute Authority may use or point to public key 5094 certificates issued by any CA, provided that the appropriate trust may 5095 be placed in that CA. Attribute Certificates may have various periods 5096 of validity. That period may be quite short, e.g. one day. While this 5098 requires that a new Attribute Certificate be obtained every day, valid 5099 for that day, this can be advantageous since revocation of such 5100 certificates may not be needed. When signing, the signer will have to 5101 specify which Attribute Certificate it selects. In order to do so, the 5102 Attribute Certificate will have to be included in the signed data in 5103 order to be protected by the digital signature from the signer. 5105 In order to identify unambiguously the attribute certificate(s) to be 5106 used for the verification of the signature an identifier of the 5107 attribute certificate(s) from the signer shall be part of the signed 5108 data. 5110 C.3.5 Signer location 5112 In some transactions the purported location of the signer at the time 5113 he or she applies his signature may need to be indicated. For this 5114 reason an optional location indicator shall be able to be included. 5116 In order to provide indication of the location of the signer at the 5117 time he or she applied his signature a location attribute may be 5118 included in the signature. 5120 C.3.6 Signing time 5122 The present document provides the capability to include a claimed 5123 signing time as an attribute of an electronic signature. 5125 Using this attribute a signer may sign over a time which is the claimed 5126 signing time. When an ES with Time-stamp is created (CAdES-T) then 5127 either a trusted time stamp is obtained and added to the ES or a 5128 trusted time mark exists in an audit trail. When a verifier accepts a 5129 signature, the two times shall be within acceptable limits. 5131 A further optional attribute is defined in the present document to 5132 timestamp the content, to provide proof of the existence of the 5133 content, at the time indicated by the time-stamp token. 5135 Internet-draft CMS Advanced Electronic Signatures September 2007 5137 Using this optional attribute a trusted secure time may be obtained 5138 before the document is signed and included under the digital signature. 5139 This solution requires an on-line connection to a trusted time-stamping 5140 service before generating the signature and may not represent the 5141 precise signing time, since it can be obtained in advance. However, 5142 this optional attribute may be used by the signer to prove that the 5143 signed object existed before the date included in the time-stamp (see 5144 section 5.11.4). 5146 C.3.7 Content format 5148 When presenting signed data to a human user it may be important that 5149 there is no ambiguity as to the presentation of the signed information 5150 to the relying party. In order for the appropriate representation 5151 (text, sound or video) to be selected by the relying party when data 5152 (as opposed to data which has been further signed or encrypted) 5153 is encapsulated in the SignedData (indicated by the eContentType 5154 within EncapsulatedContentInfo being set to id-data), further typing 5155 information should be used to identify the type of document being 5156 signed. This is generally achieved using the MIME content typing and 5157 encoding mechanism defined in RFC 2045 [6]). Further information on 5158 the use of MIME is given in Annex F. 5160 C.3.8 Content hints 5162 The contents hints attribute provides information on the innermost 5163 signed content of a multilayer message where one content is 5164 encapsulated in another. This may be useful if the signed data is 5165 itself encrypted. 5167 C.3.9 Content cross referencing 5169 When presenting a signed data is in related to another signed data, it 5170 may be important to identify the signed data to which it relates to. 5171 The Content-reference and Content-identifier attributes as defined in 5172 ESS (RFC 2634 [5]) provide the ability to link a request and reply 5173 messages in an exchange between two parties. 5175 C.4 Components of validation data 5177 C.4.1 Revocation status information 5179 A verifier will have to ascertain that the certificate of the signer 5180 was valid at the time of the signature. This can be done by either: 5182 - using Certificate Revocation Lists (CRLs); 5184 - using responses from an on-line certificate status server (for 5185 example; obtained through the OCSP protocol). 5187 Internet-draft CMS Advanced Electronic Signatures September 2007 5189 NOTE 1: The time of the signature may not be know, so time-stamping 5190 or time-marking may be used to provide the time indication of 5191 when it was known the signature existed. 5193 NOTE 2: When validating an electronic signature and checking 5194 revocation status information a "grace period" is required 5195 which needs to be suitably long enough to allow the involved 5196 authority to process a "last minute" revocation request and 5197 for the request to propagate through the revocation system. 5198 This grace period is to be added to the time included with the 5199 timestamp token or the time mark and thus the revocation 5200 status information should be captured after the end of the 5201 grace period. 5203 C.4.1.1 CRL information 5205 When using CRLs to get revocation information, a verifier will have to 5206 make sure that he or she gets at the time of the first verification the 5207 appropriate certificate revocation information from the signer's CA. 5208 This should be done as soon as possible to minimize the time delay 5209 between the generation and verification of the signature. However, a 5210 "grace period" is required to allow CAs time to process revocation 5211 requests. 5213 For example, a revocation request may arrive at a CA just before 5214 issuing the next CRL and there may not enough time to include the 5215 revised revocation status information. This involves checking that the 5216 signer certificate serial number is not included in the CRL. The 5217 signer, the initial or subsequent verifier may obtain either this CRL. 5218 If obtained by the signer, then it shall be conveyed to the verifier. 5219 It may be convenient to archive the CRL for ease of subsequent 5220 verification or arbitration. Alternatively, provided the CRL is 5221 archived elsewhere which is accessible for the purpose of arbitration, 5222 then the serial number of the CRL used may be archived together with 5223 the verified electronic signature as an CAdES-C form. 5225 Even if the certificate serial number appears in the CRL with the 5226 status "suspended" (i.e. on hold), the signature is not to be deemed as 5227 valid since a suspended certificate is not supposed to be used even by 5228 its rightful owner. 5230 C.4.1.2 OCSP information 5232 When using OCSP to get revocation information, a verifier will have to 5233 make sure that he or she gets at the time of the first verification an 5234 OCSP response that contains the status "valid". This should be done as 5235 soon as possible after the generation of the signature, still providing 5236 a "grace period" suitable enough to allow the involved authority to 5237 process a "last minute" revocation request The signer, the verifier or 5238 any other third party may fetch this OCSP response. Since OCSP 5239 responses are transient and thus are not archived by any TSP including 5240 CA, it is the responsibility of every verifier to make sure that it is 5241 Internet-draft CMS Advanced Electronic Signatures September 2007 5243 stored in a safe place. The simplest way is to store them associated 5244 with the electronic signature. An alternative would be to store them 5245 in some storage so that they can then be easily retrieved, and 5246 incorporate references to them in the electronic signature itself as an 5247 CAdES-C form. 5249 In the same way as for the case of the CRL, it may happen that the 5250 certificate is declared as invalid but with the secondary status 5251 "suspended". In such a case, same comment as for CRL applies. 5253 C.4.2 Certification path 5255 A verifier may have to ascertain that the certification path was valid, 5256 at the time of the signature, up to a trust point according to the: 5258 - naming constraints; 5259 - certificate policy constraints; 5260 - Signature Policy, when applicable. 5262 Since the time of the signature cannot be known with certainty, an 5263 upper limit of it should be used as indicated by either the time stamp 5264 or time mark. 5266 In this case it will be necessary to capture all the certificates from 5267 the certification path, starting with those from the signer and ending 5268 up with those of the self-signed certificate from one trusted root, 5269 when applicable this may be specified as part of the Signature Policy. 5270 In addition, it will be necessary to capture the Certificate Authority 5271 Revocation Lists (CARLs) to prove than none of the CAs from the chain 5272 was revoked at the time of the signature. Again, all this material may 5273 be incorporated in the electronic signature (ES X forms). An 5274 alternative would be to store it in some storage so that they can it be 5275 easily retrieved, and incorporate references to it in the electronic 5276 signature itself as a CAdES-C form. 5278 C.4.3 Time-stamping for long life of signatures 5280 An important property for long standing signatures is that a signature, 5281 having been found once to be valid, shall continue to be so months or 5282 years later. 5284 A signer, verifier or both may be required to provide on request, proof 5285 that a digital signature was created or verified during the validity 5286 period of the all the certificates that make up the certificate path. 5287 In this case, the signer, verifier or both will also be required to 5288 provide proof that the signer's certificate and all the CA certificates 5289 used to form a valid certification path were not revoked when the 5290 signature was created or verified. 5292 It would be quite unacceptable, to consider a signature as invalid even 5293 if the keys or certificates were later compromised. Thus there is a 5294 need to be able to demonstrate that the signature keys was valid at the 5295 time that the signature was created to provide long term evidence of 5296 the validity of a signature. 5298 Internet-draft CMS Advanced Electronic Signatures September 2007 5300 It could be the case that a certificate was valid at the time of the 5301 signature but revoked some time later. In this event, evidence shall 5302 be provided that the document was signed before the signing key was 5303 revoked. Time-stamping by a Time-Stamping Authority (TSA) can provide 5304 such evidence. A time stamp is obtained by sending the hash value of 5305 the given data to the TSA. The returned "time-stamp" is a signed 5306 document that contains the hash value, the identity of the TSA, and the 5307 time of stamping. This proves that the given data existed before the 5308 time of stamping. Time-stamping a digital signature (by sending a hash 5309 of the signature to the TSA) before the revocation of the signer's 5310 private key, provides evidence that the signature has been created 5311 before the key was revoked. 5313 If a recipient wants to hold a valid electronic signature he will have 5314 to ensure that he has obtained a valid time stamp for it, before that 5315 key (and any key involved in the validation) is revoked. The sooner 5316 the time-stamp is obtained after the signing time, the better. Any 5317 time stamp or time mark that is taken after the expiration date of any 5318 certificate in the certification path has no value in proving the 5319 validity of a signature. 5321 It is important to note that signatures may be generated "off-line" and 5322 time-stamped at a later time by anyone, for example by the signer or 5323 any recipient interested in the value of the signature. The time stamp 5324 can thus be provided by the signer together with the signed document, 5325 or obtained by the recipient following receipt of the signed document. 5327 The time stamp is NOT a component of the Basic Electronic Signature, 5328 but the essential component of the ES with Time-stamp. 5330 It is required in the present document that if a signer's digital 5331 signature value is to be time-stamped, the Time-Stamp Token is issued 5332 by a trusted source, known as a Time-stamping Authority. 5334 The present document requires that the signer's digital signature value 5335 is time-stamped by a trusted source before the electronic signature can 5336 become an ES with Complete validation data. Acceptable TSAs may be 5337 specified in a Signature Validation Policy. 5339 This technique is referred to as CAdES-C in the present document. 5340 Should both the signer and verifier be required to time-stamp the 5341 signature value to meet the requirements of the signature policy, the 5342 signature policy may specify a permitted time delay between the two 5343 time stamps. 5345 C.4.4 Time-stamping for long life of signature before CA key 5346 compromises 5348 Time-stamped extended electronic signatures are needed when there is a 5349 requirement to safeguard against the possibility of a CA key in the 5350 certificate chain ever being compromised. A verifier may be required 5351 to provide on request, proof that the certification path and the 5352 revocation information used a the time of the signature were valid, 5353 Internet-draft CMS Advanced Electronic Signatures September 2007 5355 even in the case where one of the issuing keys or OCSP responder keys 5356 is later compromised. 5358 The present document defines two ways of using time-stamps to protect 5359 against this compromise: 5361 - time-stamp the ES with Complete validation data, when an OCSP 5362 response is used to get the status of the certificate from the 5363 signer (CAdES-X Type 1). This format is suitable to be used with 5364 an OCSP response and offers the additional advantage to provide 5365 an integrity protection over the whole data; 5367 - time-stamp only the certification path and revocation information 5368 references when a CRL is used to get the status of the 5369 certificate from the signer (CAdES-X Type2). This format is 5370 suitable to be used with CRLs, since the time-stamped information 5371 may be used for more than one signature (when signers have their 5372 certificates issued by the same CA and when signatures can be 5373 checked using the same CRLs). 5375 NOTE: The signer, verifier or both may obtain the time-stamp. 5377 C.4.4.1 Time-stamping the ES with complete validation data 5378 (CAdES-X Type 1) 5380 When an OCSP response is used, it is necessary to time stamp in 5381 particular that response in the case the key from the responder would 5382 be compromised. Since the information contained in the OCSP response 5383 is user specific and time specific, an individual time stamp is needed 5384 for every signature received. Instead of placing the time stamp only 5385 over the certification path references and the revocation information 5386 references, which include the OCSP response, the time stamp is placed 5387 on the CAdES-C. Since the certification path and revocation 5388 information references are included in the ES with Complete validation 5389 data they are also protected. For the same cryptographic price, this 5390 provides an integrity mechanism over the ES with Complete validation 5391 data. Any modification can be immediately detected. It should be 5392 noticed that other means of protecting/detecting the integrity of the 5393 ES with Complete Validation Data exist and could be used. 5394 Although the technique requires a time stamp for every signature, it is 5395 well suited for individual users wishing to have an integrity protected 5396 copy of all the validated signatures they have received. 5398 By time-stamping the complete electronic signature, including the 5399 digital signature as well as the references to the certificates and 5400 revocation status information used to support validation of that 5401 signature, the time-stamp ensures that there is no ambiguity in the 5402 means of validating that signature. 5404 This technique is referred to as CAdES-X Type 1 in the present 5405 document. 5407 NOTE: Trust is achieved in the references by including a hash of the 5408 data being referenced. 5410 Internet-draft CMS Advanced Electronic Signatures September 2007 5412 If it is desired for any reason to keep a copy of the additional data 5413 being referenced, the additional data may be attached to the electronic 5414 signature, in which case the electronic signature becomes an CAdES-X 5415 Long Type 1 as defined by the present document. 5417 An CAdES-X Long Type 1 is simply the concatenation of an CAdES-X Type 1 5418 with a copy of the additional data being referenced. 5420 C.4.4.2 Time-stamping certificates and revocation information 5421 references (CAdES-X Type 2) 5423 Time-stamping each ES with Complete Validation Data as defined above 5424 may not be efficient, particularly when the same set of CA certificates 5425 and CRL information is used to validate many signatures. 5427 Time-stamping CA certificates will stop any attacker from issuing bogus 5428 CA certificates that could be claimed to exist before the CA key was 5429 compromised. Any bogus time-stamped CA certificates will show that the 5430 certificate was created after the legitimate CA key was compromised. 5431 In the same way, time-stamping CA CRLs, will stop any attacker from 5432 issuing bogus CA CRLs which could be claimed to exist before the CA key 5433 was compromised. 5435 Time-stamping of commonly used certificates and CRLs can be done 5436 centrally, e.g. inside a company or by a service provider. This method 5437 reduces the amount of data the verifier has to time-stamp, for example 5438 it could reduce to just one time stamp per day (i.e. in the case were 5439 all the signers use the same CA and the CRL applies for the whole day). 5440 The information that needs to be time stamped is not the actual 5441 certificates and CRLs but the unambiguous references to those 5442 certificates and CRLs. 5444 This technique is referred to as CAdES-X Type 2 in the present document 5445 and requires the following: 5447 - all the CA certificates references and revocation information 5448 references (i.e. CRLs) used in validating the CAdES-C are covered 5449 by one or more time-stamp. 5451 Thus an CAdES-C with a time-stamp signature value at time T1, can be 5452 proved valid if all the CA and CRL references are time-stamped at time 5453 T1+. 5455 Internet-draft CMS Advanced Electronic Signatures September 2007 5457 C.4.5 Time-stamping for archive of signature 5459 Advances in computing increase the probability of being able to break 5460 algorithms and compromise keys. There is therefore a requirement to be 5461 able to protect electronic signatures against this possibility. 5463 Over a period of time weaknesses may occur in the cryptographic 5464 algorithms used to create an electronic signature (e.g. due to the time 5465 available for crypto analysis, or improvements in crypto analytical 5466 techniques). Before such weaknesses become likely, a verifier should 5467 take extra measures to maintain the validity of the electronic 5468 signature. Several techniques could be used to achieve this goal 5469 depending on the nature of the weakened cryptography. In order to 5470 simplify matters, a single technique, called Archive validation data, 5471 covering all the cases is being used in the present document. 5473 Archive validation data consists of the validation data and the 5474 complete certificate and revocation data, time stamped together with 5475 the electronic signature. The Archive validation data is necessary if 5476 the hash function and the crypto algorithms that were used to create 5477 the signature are no longer secure. Also, if it cannot be assumed that 5478 the hash function used by the Time Stamping Authority is secure, then 5479 nested time-stamps of Archived Electronic Signature are required. 5481 The potential for Trusted Service Provider (TSP) key compromise should 5482 be significantly lower than user keys, because TSP(s) are expected to 5483 use stronger cryptography and better key protection. It can be 5484 expected that new algorithms (or old ones with greater key lengths) 5485 will be used. In such a case, a sequence of time-stamps will protect 5486 against forgery. Each time-stamp needs to be affixed before either the 5487 compromise of the signing key or of the cracking of the algorithms used 5488 by the TSA. TSAs (Time-stamping Authorities) should have long keys 5489 (e.g. which at the time of drafting the present document was at least 5490 2048 bits for the signing RSA algorithm) and/or a "good" or different 5491 algorithm. 5493 Nested time-stamps will also protect the verifier against key 5494 compromise or cracking the algorithm on the old electronic signatures. 5496 The process will need to be performed and iterated before the 5497 cryptographic algorithms used for generating the previous time stamp 5498 are no longer secure. Archive validation data may thus bear multiple 5499 embedded time stamps. 5501 This technique is referred to as CAdES-A in the present document. 5503 Internet-draft CMS Advanced Electronic Signatures September 2007 5505 C.4.6 Reference to additional data 5507 Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data 5508 verifiers still needs to keep track of all the components that were 5509 used to validate the signature, in order to be able to retrieve them 5510 again later on. These components may be archived by an external source 5511 like a trusted service provider, in which case referenced information 5512 that is provided as part of the ES with Complete validation data 5513 (CAdES-C) is adequate. The actual certificates and CRL information 5514 reference in the CAdES-C can be gathered when needed for arbitration. 5516 If references to additional data are not adequate, then the actual 5517 values of all the certificates and revocation information required may 5518 be part of the electronic signature. This technique is referred to as 5519 CAdES-X Long Type 1 or CAdES-X Long Type 2 in the present document. 5521 C.4.7 Time-stamping for mutual recognition 5523 In some business scenarios both the signer and the verifier need to 5524 time-stamp their own copy of the signature value. Ideally the two 5525 time-stamps should be as close as possible to each other. 5527 EXAMPLE: A contract is signed by two parties A and B representing 5528 their respective organizations, to time-stamp the signer 5529 and verifier data two approaches are possible: 5531 - under the terms of the contract pre-defined common 5532 "trusted" TSA may be used; 5534 - if both organizations run their own time-stamping 5535 services, A and B can have the transaction 5536 time-stamped by these two time-stamping services. 5538 In the latter case, the electronic signature will only be considered as 5539 valid, if both time-stamps were obtained in due time (i.e. there should 5540 not be a long delay between obtaining the two time-stamps). Thus, 5541 neither A nor B can repudiate the signing time indicated by their own 5542 time-stamping service. Therefore, A and B do not need to agree on a 5543 common "trusted" TSA to get a valid transaction. 5545 It is important to note that signatures may be generated "off-line" and 5546 time-stamped at a later time by anyone, e.g. by the signer or any 5547 recipient interested in validating the signature. The time-stamp over 5548 the signature from the signer can thus be provided by the signer 5549 together with the signed document, and/or obtained by the verifier 5550 following receipt of the signed document. 5552 The business scenarios may thus dictate that one or more of the long- 5553 term signature time-stamping methods describe above be used. This may 5554 be part of a mutually agreed Signature Validation Policy which is part 5555 of an agreed signature policy under which digital signature may be used 5556 to support the business relationship between the two parties. 5558 Internet-draft CMS Advanced Electronic Signatures September 2007 5560 C.4.8 TSA key compromise 5562 TSA servers should be built in such a way that once the private 5563 signature key is installed, there is minimal likelihood of compromise 5564 over as long as possible period. Thus the validity period for the 5565 TSA's keys should be as long as possible. 5567 Both the CAdES-T and the CAdES-C contain at least one time stamp over 5568 the signer's signature. In order to protect against the compromise of 5569 the private signature key used to produce that time-stamp, the Archive 5570 validation data can be used when a different Time-Stamping Authority 5571 key is involved to produce the additional time-stamp. If it is 5572 believed that the TSA key used in providing an earlier time-stamp may 5573 ever be compromised (e.g. outside its validity period), then the CAdES- 5574 A should be used. For extremely long periods this may be applied 5575 repeatedly using new TSA keys. 5577 This technique is referred to as a nested CAdES-A in the present 5578 document. 5580 C.5 Multiple signatures 5582 Some electronic signatures may only be valid if they bear more than one 5583 signature. This is the case generally when a contract is signed 5584 between two parties. The ordering of the signatures may or may not be 5585 important, i.e. one may or may not need to be applied before the other. 5587 Several forms of multiple and counter signatures need to be supported, 5588 which fall into two basic categories: 5589 - independent signatures; 5590 - embedded signatures. 5592 Independent signatures are parallel signatures where the ordering of 5593 the signatures is not important. The capability to have more than one 5594 independent signature over the same data shall be provided. 5596 Embedded signatures are applied one after the other and are used where 5597 the order the signatures are applied is important. The capability to 5598 sign over signed data shall be provided. 5600 These forms are described in section 5.13. All other multiple signature 5601 schemes, e.g. a signed document with a countersignature, double 5602 countersignatures or multiple signatures, can be reduced to one or more 5603 occurrence of the above two cases. 5605 Internet-draft CMS Advanced Electronic Signatures September 2007 5607 Annex D (informative):Data protocols to interoperate with TSPs 5609 D.1 Operational protocols 5611 The following protocols can be used by signers and verifiers to 5612 interoperate with Trusted Service Providers during the electronic 5613 signature creation and validation. 5615 D.1.1 Certificate retrieval 5617 User certificates, CA certificate and cross-certificates can be 5618 retrieved from a repository using the Lightweight Directory Access 5619 Protocol as defined in as defined RFC 2559 (RFC2559], with the schema 5620 defined in RFC 2587 [RFC2587]. 5622 D.1.2 CRL retrieval 5624 Certificate revocation lists, including authority revocation lists and 5625 partial CRL variants, can be retrieved from a repository using the 5626 Lightweight Directory Access Protocol as defined in RFC 2559 5627 [RFC2559], with the schema defined in RFC 2587 [RFC2587]. 5629 D.1.3 OnLine certificate status 5631 As an alternative to use of certificate revocation lists the status of 5632 certificate can be checked using the OnLine Certificate Status Protocol 5633 (OCSP) as defined in RFC 2560 [3]. 5635 D.1.4 Time-stamping 5637 The time-stamping service can be accessed using the Time-Stamping 5638 Protocol defined in RFC 3161 [7]. 5640 D.2 Management protocols 5642 Signers and verifiers can use the following management protocols to 5643 manage the use of certificates. 5645 D.2.1 Request for certificate revocation 5647 Request for a certificate to be revoked can be made using the 5648 revocation request and response messages defined in 5649 RFC 2510 [RFC2510]. 5651 Internet-draft CMS Advanced Electronic Signatures September 2007 5653 Annex E (informative): Guidance on naming 5655 E.1 Allocation of names 5657 The subject name shall be allocated through a registration scheme 5658 administered through a Registration Authority (RA) to ensure 5659 uniqueness. This RA may be an independent body or a function carried 5660 out by the Certification Authority. 5662 In addition to ensuring uniqueness, the RA shall verify that the name 5663 allocated properly identifies the applicant and that authentication 5664 checks are carried out to protect against masquerade. 5666 The name allocated by an RA is based on registration information 5667 provided by, or relating to, the applicant (e.g. his personal name, 5668 date of birth, residence address) and information allocated by the RA. 5669 Three variations commonly exist: 5671 - the name is based entirely on registration information which 5672 uniquely identifies the applicant (e.g. "Pierre Durand (born on) 5673 July 6, 1956"); 5675 - the name is based on registration information with the addition 5676 of qualifiers added by the registration authority to ensure 5677 uniqueness (e.g. "Pierre Durand 12"); 5679 - the registration information is kept private by the registration 5680 authority and the registration authority allocates a "pseudonym". 5682 E.2 Providing access to registration information 5684 Under certain circumstances it may be necessary for information used 5685 during registration, but not published in the certificate, to be made 5686 available to third parties (e.g. to an arbitrator to resolve a dispute 5687 or for law enforcement). This registration information is likely to 5688 include personal and sensitive information. 5690 Thus the RA needs to establish a policy for: 5692 - whether the registration information should be disclosed; 5693 - to whom such information should be disclosed; 5694 - under what circumstances such information should be disclosed. 5696 This policy may be different whether the RA is being used only within a 5697 company or for public use. The policy will have to take into account 5698 national legislation and in particular any data protection and privacy 5699 legislation. 5701 Internet-draft CMS Advanced Electronic Signatures September 2007 5703 Currently, the provision of access to registration is a local matter 5704 for the RA. However, if open access is required, standard protocols 5705 such as HTTP - RFC 2068 (Internet Web Access Protocol) may be employed 5706 with the addition of security mechanisms necessary to meet the data 5707 protection requirements (e.g. Transport Layer Security - RFC 2246 5708 [RFC2246] with client authentication). 5710 E.3 Naming schemes 5712 E.3.1 Naming schemes for individual citizens 5714 In some cases the subject name that is contained in a public key 5715 certificate may not be meaningful enough. This may happen because of 5716 the existence of homonyms or because of the use of pseudonyms. A 5717 distinction could be made if more attributes were present. However, 5718 adding more attributes to a public key certificate placed in a public 5719 repository would be going against the privacy protection requirements. 5721 In any case the Registration Authority will get information at the time 5722 of registration but not all that information will be placed in the 5723 certificate. In order to achieve a balance between these two opposite 5724 requirements the hash values of some additional attributes can be 5725 placed in a public key certificate. When the certificate owner 5726 provides these additional attributes, then they can be verified. Using 5727 biometrics attributes may unambiguously identify a person. Example of 5728 biometrics attributes that can be used include: a picture or a manual 5729 signature from the certificate owner. 5731 NOTE: Using hash values protects privacy only if the possible inputs 5732 are large enough. For example, using the hash of a person's 5733 social security number is generally not sufficient since it 5734 can easily be reversed. 5736 A picture can be used if the verifier once met the person and later on 5737 wants to verify that the certificate that he or she got relates to the 5738 person whom was met. In such a case, at the first exchange the picture 5739 is sent and the hash contained in the certificate may be used by the 5740 verifier to verify that it is the right person. At the next exchange 5741 the picture does not need to be sent again. 5743 A manual signature may be used if a signed document has been received 5744 beforehand. In such a case, at the first exchange the drawing of the 5745 manual signature is sent and the hash contained in the certificate may 5746 be used by the verifier to verify that it is the right manual 5747 signature. At the next exchange the manual signature does not need to 5748 be sent again. 5750 Internet-draft CMS Advanced Electronic Signatures September 2007 5752 E.3.2 Naming schemes for employees of an organization 5754 The name of an employee within an organization is likely to be some 5755 combination of the name of the organization and the identifier of the 5756 employee within that organization. 5758 An organization name is usually a registered name, i.e. business or 5759 trading name used in day to day business. This name is registered by a 5760 Naming Authority, which guarantees that the organization's registered 5761 name is unambiguous and cannot be confused with another organization. 5762 In order to get more information about a given registered organization 5763 name, it is necessary to go back to a publicly available directory 5764 maintained by the Naming Authority. 5766 The identifier may be a name or a pseudonym (e.g. a nickname or a 5767 employee number). When it is a name, it is supposed to be descriptive 5768 enough to unambiguously identify the person. When it is a pseudonym, 5769 the certificate does not disclose the identity of the person. However 5770 it ensures that the person has been correctly authenticated at the time 5771 of registration and therefore may be eligible to some advantages 5772 implicitly or explicitly obtained through the possession of the 5773 certificate. In either case, however, this can be insufficient because 5774 of the existence of homonyms. 5776 Placing more attributes in the certificate may be one solution, for 5777 example by giving the organization unit of the person or the name of a 5778 city where the office is located. However the more information is 5779 placed in the certificate the more problems arise if there is a change 5780 in the organization structure or the place of work. So this may not be 5781 the best solution. An alternative is to provide more attributes (like 5782 the organization unit and the place of work) through access to a 5783 directory maintained by the company. It is likely that at the time of 5784 registration the Registration Authority got more information than what 5785 was placed in the certificate, if such additional information is placed 5786 in a repository accessible only to the organization. 5788 Internet-draft CMS Advanced Electronic Signatures September 2007 5790 Annex F (informative): Example structured contents and MIME 5792 F.1 Use of MIME to encode data 5794 The signed content may be structured as using MIME (Multipurpose 5795 Internet Mail Extensions - RFC 2045 [6]. Whilst the MIME structure was 5796 initially developed for Internet e-mail, it has a number of features 5797 which make it useful to provide a common structure for encoding a range 5798 of electronic documents and other multi-media data (e.g. photographs, 5799 video). These features include: 5801 - it provides a means of signalling the type of "object" being 5802 carried (e.g. text, image, ZIP file, application data); 5804 - it provides a means of associating a file name with an object; 5806 - it can associate several independent "objects" (e.g. a document 5807 and image) to form a multi-part object; 5809 - it can handle data encoded in text or binary and, if necessary, 5810 re-encode the binary as text. 5812 When encoding a single object MIME consists of: 5814 - header information, followed by; 5815 - encoded content. 5817 This structure can be extended to support multi-part content. 5819 F.1.1 Header information 5821 A MIME header includes: 5823 MIME Version information: e.g.: MIME-Version: 1.0 5825 Content type information which includes information describing the 5826 content sufficient for it to presented to a user or application 5827 process as required. This includes information on the "media type" 5828 (e.g. text, image, audio) or whether the data is for passing to a 5829 particular type of application. In the case of text the content type 5830 includes information on the character set used, e.g. 5831 Content-Type: text/plain; charset="us-ascii" 5833 Content encoding information, which defines how the content is 5834 encoded. (See below about encoding supported by MIME). 5836 Other information about the content such as a description, or an 5837 associated file name. 5839 An example MIME header for text object is: 5841 Mime-Version: 1.0 5842 Content-Type: text/plain; charset=ISO-8859-1 5843 Content-Transfer-Encoding: quoted-printable 5844 Internet-draft CMS Advanced Electronic Signatures September 2007 5846 An example MIME header for a binary file containing a pdf document is: 5848 Content-Type: application/pdf 5849 Content-Transfer-Encoding: base64 5850 Content-Description: JCFV201.pdf 5851 Content-Disposition: filename="JCFV201.pdf" 5853 F.1.2 Content encoding 5855 MIME supports a range of mechanisms for encoding the both text and 5856 binary data. 5858 Text data can be carried transparently as lines of text data encoded 5859 in 7 or 8 bit ASCII characters. MIME also includes a 5860 "quoted-printable" encoding which converts characters other than the 5861 basic ASCII into an ASCII sequence. 5863 Binary can either be carried: 5865 - transparently a 8 bit octets; or 5866 - converted to a basic set of characters using a system called 5867 Base64. 5869 NOTE: As there are some mail relays which can only handle 7 bit 5870 ASCII, Base64 encoding is usually used on the Internet. 5872 F1.3 Multi-part content 5874 Several objects (e.g. text and a file attachment) can be associated 5875 together using a special "multi-part" content type. This is indicated 5876 by the content type "multipart" with an indication of the string to be 5877 used indicate a separation between each part. 5879 In addition to a header for the overall multipart content, each part 5880 includes its own header information indicating the inner content type 5881 and encoding. 5883 An example of a multipart content is: 5885 Mime-Version: 1.0 5886 Content-Type: multipart/mixed; boundary="---- 5887 =_NextPart_000_01BC4599.98004A80" 5888 Content-Transfer-Encoding: 7bit 5890 ------=_NextPart_000_01BC4599.98004A80 5891 Content-Type: text/plain; charset=ISO-8859-1 5892 Content-Transfer-Encoding: 7bit 5894 Per your request, I've attached our proposal for the Java Card Version 5895 2.0 API and the Java Card FAQ. 5897 Internet-draft CMS Advanced Electronic Signatures September 2007 5899 ------=_NextPart_000_01BC4599.98004A80 5900 Content-Type: application/pdf; name="JCFV201.pdf" 5901 Content-Transfer-Encoding: base64 5902 Content-Description: JCFV201.pdf 5903 Content-Disposition: attachment; filename="JCFV201.pdf" 5905 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA 5906 AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// 5907 //////////AANhAAQAYg== 5909 ------=_NextPart_000_01BC4599.98004A80-- 5911 Multipart content can be nested. So a set of associated objects (e.g. 5912 HTML text and images) can be handled as a single attachment to another 5913 object (e.g. text). 5915 The Content-Type from each part of the S/MIME message indicates the 5916 type of content. 5918 F.2 S/MIME 5920 The specific use of MIME to carry CMS (extended as defined in the 5921 present document) secured data is called S/MIME (see [RFC3851]). 5923 S/MIME carries electronic signatures as either: 5925 - an "application/pkcs7-mime" object with the CMS carried as binary 5926 attachment (PKCS7 is the name of the early version of CMS). 5928 The signed data may be included in the SignedData, which itself 5929 may be included in a single S/MIME object. See [RFC3851], 5930 section 3.4.2 �Signing Using application/pkcs7-mime with 5931 SignedData� and figure F.1 hereafter. 5933 or 5935 - a "multipart/signed" object with the signed data and the 5936 signature encoded as separate MIME objects. 5938 The signed data is not included in the SignedData, and the CMS 5939 structure only includes the signature. See [RFC3851], 5940 section 3.4.3 �Signing Using the multipart/signed Format� and 5941 figure F.2 hereafter. 5943 Internet-draft CMS Advanced Electronic Signatures September 2007 5945 +-------------++----------++-------------++------------+ 5946 | || || || | 5947 | S/MIME || CAdES || MIME || pdf file | 5948 | || || || | 5949 |Content-Type=||SignedData||Content-Type=||Dear MrSmith| 5950 |application/ || eContent ||application/ ||Received | 5951 |pkcs7-mime || ||pdf || 100 tins | 5952 | || || || | 5953 |smime-type= || /| || /| || Mr.Jones | 5954 |signed-data || / -----+ / ------+ | 5955 | || \ -----+ \ ------+ | 5956 | || \| || \| |+------------+ 5957 | || |+-------------+ 5958 | |+----------+ 5959 +-------------+ 5961 Figure F.1 Signing Using application/pkcs7-mime 5963 F.2.1 Using application/pkcs7-mime 5965 This approach is similar to handling signed data as any other binary 5966 file attachment. 5968 An example of signed data encoded using this approach is: 5970 Content-Type: application/pkcs7-mime; smime-type=signed-data; 5971 Content-Transfer-Encoding: base64 5972 Content-Disposition: attachment; filename=smime.p7m 5974 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 5975 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 5976 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 5977 6YT64V0GhIGfHfQbnj75 5979 F.2.1 Using application/pkcs7-signature 5981 CMS also supports an alternative structure where the signature and 5982 data being protected are separate MIME objects carried within a single 5983 message. In this case the signed data is not included in the 5984 SignedData, and the CMS structure only includes the signature. See 5985 [RFC3851], section 3.4.3 �Signing Using the multipart/signed Format� 5986 and figure F.2 herafter. 5988 An example of signed data encoded this approach is: 5990 Content-Type: multipart/signed; 5991 protocol="application/pkcs7-signature"; 5992 micalg=sha1; boundary=boundary42 5994 Internet-draft CMS Advanced Electronic Signatures September 2007 5996 --boundary42 5997 Content-Type: text/plain 5999 This is a clear-signed message. 6001 --boundary42 6003 Content-Type: application/pkcs7-signature; name=smime.p7s 6004 Content-Transfer-Encoding: base64 6005 Content-Disposition: attachment; filename=smime.p7s 6007 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 6008 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 6009 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 6010 7GhIGfHfYT64VQbnj756 6012 --boundary42-- 6014 With this second approach MIME the signed data passes through the CMS 6015 process and is carried as part of a muliple parts signed MIME 6016 structure as illustrated in figure F.2. The CMS structure just holds 6017 the electronic signature. 6019 +---------------++----------++-------------++------------+ 6020 | || || || | 6021 | MIME || CAdES || MIME || pdf file | 6022 | || || || | 6023 |Content-Type= ||SignedData||Content-Type=||Dear MrSmith| 6024 |multipart/ || ||application/ ||Received | 6025 |signed || ||pdf || 100 tins | 6026 | /| || || || | 6027 | / -------------------+ /| || Mr.Jones | 6028 | \ -------------------+ / -----+ | 6029 | \| || || \ -----+ | 6030 |Content-Type= || || \| |+------------+ 6031 |application/ || |+-------------+ 6032 |pdf || | 6033 | || | |Content-Type= || | 6034 |application/ || | 6035 |pkcs7-signature|| | 6036 | || | 6037 | /| || | 6038 | / -------+ | 6039 | \ -------+ | 6040 | \| ||----------+ | | 6041 +---------------+ 6043 Figure F.2. Signing Using application/pkcs7-signature 6045 This second approach (multipart/signed) has the advantage that the 6046 signed data can be decoded by any MIME compatible system even if 6047 it does not recognize CMS encoded electronic signatures. 6049 Internet-draft CMS Advanced Electronic Signatures September 2007 6051 Annex G (informative): Relationship to the European Directive and EESSI 6053 G.1 Introduction 6055 This annex provides an indication of the relationship between 6056 electronic signatures created under the present document and 6057 requirements under the European Parliament and Council Directive on a 6058 Community framework for electronic signatures. 6060 NOTE: Legal advice should be sought on the specific national 6061 legislation regarding use of electronic signatures. 6063 The present document is one of a set of standards being defined under 6064 the "European Electronic Signature Standardization Initiative" (EESSI) 6065 for electronic signature products and solutions compliant with the 6066 European Directive for electronic signatures. 6068 G.2 Electronic signatures and the directive 6070 This directive defines electronic signatures as: 6072 - "data in electronic form which are attached to or logically 6073 associated with other electronic data and which serve as a method 6074 of authentication". 6076 The directive states that an electronic signature should not be denied 6077 "legal effectiveness and admissibility as evidence in legal 6078 proceedings" solely on the grounds that it is in electronic form. 6080 The directive identifies an electronic signature as having equivalence 6081 to a hand-written signature if it meets specific criteria: 6082 - it is an "advanced electronic signature" with the following 6083 properties: 6085 a) it is uniquely linked to the signatory; 6087 b) it is capable of identifying the signatory; 6089 c) it is created using means that the signatory can maintain 6090 under his sole control; and 6092 d) it is linked to the data to which it relates in such a 6093 manner that any subsequent change of the data is detectable. 6095 - it is based on a certificate which meets detailed criteria given 6096 in annex I to the directive and is issued by a "certification- 6097 service-provider" which meets requirements given in annex II to 6098 the directive. Such a certificate is referred to as a "qualified 6099 certificate"; 6101 Internet-draft CMS Advanced Electronic Signatures September 2007 6103 - it is created by a "device" which detailed criteria given in 6104 annex III to the directive. Such a device is referred to a 6105 "secure-signature-creation device"; 6107 This form of electronic signature is referred to as a "qualified 6108 electronic signature" in EESSI (see below). 6110 G.3 ETSI electronic signature formats and the directive 6112 An electronic signature created in accordance with the present document 6113 is: 6115 a) considered to be an "electronic signature" under the terms of 6116 the Directive; 6118 b) considered to be an "advanced electronic signature" under the 6119 terms of the Directive; 6121 c) considered to be a "Qualified Electronic Signature" provided the 6122 additional requirements in annex I, II and III of the Directive 6123 are met. The requirements in annex I, II and III of the 6124 Directive are outside the scope of the present document, and are 6125 subject to further standardization. 6127 G.4 EESSI standards and classes of electronic signature 6129 G.4.1 Structure of EESSI standardization 6131 EESSI looks at standards in several areas. See the ETSI ESI and CEN 6132 web sites for the latest list of standards and their versions 6134 - use of X.509 public key certificates as qualified certificates; 6136 - security Management and Certificate Policy for CSPs Issuing 6137 Qualified Certificates; 6139 - security requirements for trustworthy systems used by CSPs 6140 Issuing Qualified Certificates; 6142 - security requirements for Secure Signature Creation Devices; 6144 - security requirements for Signature Creation Systems; 6146 - procedures for Electronic Signature Verification; 6148 - electronic signature syntax and encoding formats; 6150 - protocol to interoperate with a Time Stamping Authority; 6152 - Policy requirements for Time-Stamping Authorities; 6154 - XML electronic signature formats. 6156 Internet-draft CMS Advanced Electronic Signatures September 2007 6158 Each of these standards addresses a range of requirements including 6159 the requirements of Qualified Electronic Signatures as specified in 6160 article 5.1 of the Directive. However, some of them also address 6161 general requirements of electronic signatures for business and 6162 electronic commerce which all fall into the category of article 5.2 of 6163 the Directive. Such variation in the requirements may be identified 6164 either as different levels or different options. 6166 G.4.2 Classes of electronic signatures 6168 Since some of these standards address a range of requirements, it may 6169 be useful to identify a set of standards to address a specific 6170 business need. Such a set of standards and their uses defines a class 6171 of electronic signature. The first class already identified is the 6172 qualified electronic signature, fulfilling the requirements of article 6173 5.1 of the Directive. 6175 A limited number of "classes of electronic signatures" and 6176 corresponding profiles could be defined by EESSI, in close 6177 co-operation with actors on the market (business, users, suppliers). 6178 Need for such standards is envisaged, in addition to those for 6179 qualified electronic signatures, in areas such as: 6181 - different classes of electronic signatures with long term 6182 validity; 6184 - electronic signatures for business transactions with limited 6185 value. 6187 G.4.3 EESSI classes and the ETSI electronic signature format 6188 The electronic signature format defined in the present document is 6189 applicable to the EESSI area "electronic signature and encoding 6190 formats". 6192 An electronic signature produced by a signer (see section 5 and 6193 conformance section 10.1) is applicable to the proposed class of 6194 electronic signature: "qualified electronic signatures fulfilling 6195 article 5.1". 6197 With the addition of validation data by the verifier (see section 6 6198 and conformance section 10.2) this would become applicable electronic 6199 signatures adding long-term validity attributes to the qualified 6200 electronic signature. 6202 Annex H (informative):APIs for the generation and verification of 6203 electronic signatures tokens 6205 While the present document describes the data format of an electronic 6206 signature, the question is whether there exists APIs (Application 6207 Programming Interfaces) able to manipulate these structures. At least 6208 two such APIs have been defined. One set by the IETF and another set 6209 by the OMG (Object Management Group). 6211 Internet-draft CMS Advanced Electronic Signatures September 2007 6213 H.1 Data framing 6215 In order to be able to use either of these APIs, it will be necessary 6216 to frame the previously defined electronic signature data structures 6217 using a mechanism-independent token format. Section 3.1 of RFC 2743 6218 [RFC2743] describes that framing incorporating an identifier of the 6219 mechanism type to be used and enabling tokens to be interpreted 6220 unambiguously. 6222 In order to be processable by these APIs, all electronic signature data 6223 formats that are defined in the present document shall be framed 6224 following that description. 6226 The encoding format for the token tag is derived from ASN.1 and DER, 6227 but its concrete representation is defined directly in terms of octets 6228 rather than at the ASN.1 level in order to facilitate interoperable 6229 implementation without use of general ASN.1 processing code. The token 6230 tag consists of the following elements, in order: 6232 1) 0x60 -- Tag for RFC 2743 SEQUENCE; indicates that constructed 6233 form, definite length encoding follows. 6235 2) Token length octets, specifying length of subsequent data (i.e. 6236 the summed lengths of elements 3 to 5 in this list, and of the 6237 mechanism-defined token object following the tag). This element 6238 comprises a variable number of octets: 6240 a) If the indicated value is less than 128, it shall be 6241 represented in a single octet with bit 8 (high order) set to 6242 "0" and the remaining bits representing the value. 6244 b) If the indicated value is 128 or more, it shall be represented 6245 in two or more octets, with bit 8 of the first octet set to 6246 "1" and the remaining bits of the first octet specifying the 6247 number of additional octets. The subsequent octets carry the 6248 value, 8 bits per octet, most significant digit first. The 6249 minimum number of octets shall be used to encode the length 6250 (i.e. no octets representing leading zeros shall be included 6251 within the length encoding). 6253 3) 0x06 -- Tag for OBJECT IDENTIFIER. 6255 4) Object identifier length -- length (number of octets) of the 6256 encoded object identifier contained in element 5, encoded per 6257 rules as described in 2a) and 2b) above. 6259 5) object identifier octets -- variable number of octets, encoded 6260 per ASN.1 BER rules: 6262 Internet-draft CMS Advanced Electronic Signatures September 2007 6264 - The first octet contains the sum of two values: 6266 (1) the top-level object identifier component, multiplied by 6267 40 (decimal); and 6269 (2) the second-level object identifier component. 6271 This special case is the only point within an object 6272 identifier encoding where a single octet represents contents 6273 of more than one component. 6275 - Subsequent octets, if required, encode successively-lower 6276 components in the represented object identifier. A 6277 component's encoding may span multiple octets, encoding 7 bits 6278 per octet (most significant bits first) and with bit 8 set to 6279 "1" on all but the final octet in the component's encoding. 6280 The minimum number of octets shall be used to encode each 6281 component (i.e. no octets representing leading zeros shall be 6282 included within a component's encoding). 6284 NOTE: In many implementations, elements 3 to 5 may be stored and 6285 referenced as a contiguous string constant. 6287 The token tag is immediately followed by a mechanism-defined token 6288 object. Note that no independent size specifier intervenes following 6289 the object identifier value to indicate the size of the mechanism- 6290 defined token object. 6292 Tokens conforming to the present document shall have the following OID 6293 in order to be processable by IDUP-APIs: 6295 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 6296 { itu-t(0) identified-organization(4) etsi(0) 6297 electronic-signature-standard (1733) part1 (1) IDUPMechanism (4) 6298 etsiESv1(1) } 6300 H.2 IDUP-GSS-APIs defined by the IETF 6302 The IETF CAT WG has produced in December 1998 an RFC (RFC 2479 6303 [RFC2479]) under the name of IDUP-GSS-API (Independent Data Unit 6304 Protection) able to handle the electronic signature data format 6305 defined in the present document. 6307 The IDUP-GSS-API includes support for non-repudiation services. 6309 It supports evidence generation, where "evidence" is information that 6310 either by itself, or when used in conjunction with other information, 6311 is used to establish proof about an event or action, as well a evidence 6312 verification. 6314 Internet-draft CMS Advanced Electronic Signatures September 2007 6316 IDUP supports various types of evidences. All the types defined in 6317 IDUP are supported in the present document through the commitment type 6318 parameter. 6320 Section 2.3.3 of IDUP describes the specific calls needed to handle 6321 evidences ("EV" calls). The "EV" group of calls provides a simple, 6322 high-level interface to underlying IDUP mechanisms when application 6323 developers need to deal only with evidences but not with encryption or 6324 integrity services. 6326 All generations and verification are performed according to the content 6327 of a NR policy that is referenced in the context. 6329 Get_token_details is used to return to an application the attributes 6330 that correspond to a given input token. Since IDUP-GSS- API tokens are 6331 meant to be opaque to the calling application, this function allows the 6332 application to determine information about the token without having to 6333 violate the opaqueness intention of IDUP. Of primary importance is the 6334 mechanism type, which the application can then use as input to the 6335 IDUP_Establish_Env() call in order to establish the correct environment 6336 in which to have the token processed. 6338 Generate_token generates a non-repudiation token using the current 6339 environment. 6341 Verify_evidence verifies the evidence token using the current 6342 environment. This operation returns a major_status code which can be 6343 used to determine whether the evidence contained in a token is complete 6344 (i.e. can be successfully verified (perhaps years) later). If a 6345 token's evidence is not complete, the token can be passed to another 6346 API: form_complete_pidu to complete it. This happens when a status 6347 "conditionally valid" is returned. That status corresponds to the 6348 status "validation incomplete" of the present document. 6350 Form_complete_PIDU is used primarily when the evidence token itself 6351 does not contain all the data required for its verification and it is 6352 anticipated that some of the data not stored in the token may become 6353 unavailable during the interval between generation of the evidence 6354 token and verification unless it is stored in the token. The 6355 Form_Complete_PIDU operation gathers the missing information and 6356 includes it in the token so that verification can be guaranteed to be 6357 possible at any future time. 6359 H.3 CORBA security interfaces defined by the OMG 6361 Non-repudiation interfaces have been defined in "CORBA Security", a 6362 document produced by the OMG (Object Management Group). These 6363 interfaces are described in IDL (Interface Definition Language) and are 6364 optional. 6366 Internet-draft CMS Advanced Electronic Signatures September 2007 6368 The handling of "tokens" supporting non-repudiation is done through the 6369 following interfaces: 6371 - set_NR_features specifies the features to apply to future 6372 evidence generation and verification operations; 6374 - get_NR_features returns the features which will be applied to 6375 future evidence generation and verification operations; 6377 - generate_token generates a Non-repudiation token using the 6378 current Non-repudiation features; 6380 - verify_evidence verifies the evidence token using the current 6381 Non-repudiation features; 6383 - get_tokens_details returns information about an input Non- 6384 repudiation token. The information returned depends upon the 6385 type of token; 6387 - form_complete_evidence is used when the evidence token itself 6388 does not contain all the data required for its verification, and 6389 it is anticipated that some of the data not stored in the token 6390 may become unavailable during the interval between generation of 6391 the evidence token and verification unless it is stored in the 6392 token. The form_complete_evidence operation gathers the missing 6393 information and includes it in the token so that verification can 6394 be guaranteed to be possible at any future time. 6396 NOTE: The similarity between the two sets of APIs is noticeable. 6398 Internet-draft CMS Advanced Electronic Signatures September 2007 6400 Annex I (informative):Cryptographic algorithms 6402 RFC 3370 [10] describes the conventions for using several cryptographic 6403 algorithms with the Crytographic Message Syntax (CMS). Only the 6404 hashing and signing algorithms are appropriate for use with the present 6405 document. 6407 Since the publication of RFC 3370 [10], MD5 has been broken. This 6408 algorithm is no more considered as appropriate and has been deleted 6409 from the list of algorithms. 6411 I.1 Digest algorithms 6413 I.1.1 SHA-1 6415 The SHA-1 digest algorithm is defined in FIPS Pub 180-1. The algorithm 6416 identifier for SHA-1 is: 6418 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) 6419 secsig(3) algorithm(2) 26 } 6421 The AlgorithmIdentifier parameters field is optional. If present, the 6422 parameters field shall contain an ASN.1 NULL. Implementations should 6423 accept SHA-1 AlgorithmIdentifiers with absent parameters as well as 6424 NULL parameters. Implementations should generate SHA-1 6425 AlgorithmIdentifiers with NULL parameters. 6427 I.1.2 General 6429 The following is a selection of work that has been done in the area of 6430 digest algorithms or, as they are often called, hash functions: 6432 - ISO/IEC 10118-1 (1994) [ISO10118-1]: "Information technology - 6433 Security techniques - Hash-functions - Part 1: General". 6434 ISO/IEC 10118-1 contains definitions and describes basic concepts. 6436 - ISO/IEC 10118-2 (1994) [ISO10118-2]: "Information technology - 6437 Security techniques - Hash-functions - Part 2: Hash-functions 6438 using an n-bit block cipher algorithm". ISO/IEC 10118-2 specifies 6439 two ways to construct a hash-function from a block cipher. 6441 - ISO/IEC 10118-3 (1997) [ISO10118-3]: "Information technology - 6442 Security techniques - Hash-functions - Part 3: Dedicated 6443 hash-functions". ISO/IEC 10118-3 specifies the following 6444 dedicated hash-functions: 6446 - SHA-1 (FIPS 180-1); 6447 - RIPEMD-128; 6448 - RIPEMD-160. 6450 Internet-draft CMS Advanced Electronic Signatures September 2007 6452 - ISO/IEC 10118-4 (1998) [ISO10118-4]: "Information technology - 6453 Security techniques - Hash-functions - Part 4: Hash-functions 6454 using modular arithmetic". 6456 - RFC 1320 (PS 1992): "The MD4 Message-Digest Algorithm". RFC 1320 6457 specifies the hash-function MD4. Today, MD4 is considered out- 6458 dated. 6460 - RFC 1321 (I 1992): "The MD5 Message-Digest Algorithm". RFC 1321 6461 (informational) specifies the hash-unction MD5. Today, MD5 is 6462 not recommended for new implementations. 6464 - FIPS Publication 180-1 (1995): "Secure Hash Standard". FIPS 180-1 6465 specifies the Secure Hash Algorithm (SHA), dedicated hash- 6466 function developed for use with the DSA. The original SHA 6467 published in 1993 was slightly revised in 1995 and renamed SHA-1. 6469 - ANSI X9.30-2 (1997) [X9.30-2]: "Public Key Cryptography for the 6470 Financial Services Industry - Part 2: The Secure Hash Algorithm 6471 (SHA-1)". X9.30-2 specifies the ANSI-Version of SHA-1. 6473 - ANSI X9.31-2 (1996) [X9.31-2]: "Public Key Cryptography Using 6474 Reversible Algorithms for the Financial Services Industry � 6475 Part 2: Hash Algorithms". X9.31-2 specifies hash algorithms. 6477 I.2 Digital signature algorithms 6479 I.2.1 DSA 6481 The DSA signature algorithm is defined in FIPS Pub 186. DSA is always 6482 used with the SHA-1 message digest algorithm. The algorithm identifier 6483 for DSA is: 6485 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 6486 x9-57 (10040) x9cm(4) 3 } 6488 The AlgorithmIdentifier parameters field shall not be present. 6490 I.2.2 RSA 6492 The RSA signature algorithm is defined in RFC 2437 [RFC2437]. 6493 RFC 3370 [10] specifies the use of the RSA signature algorithm with 6494 the SHA-1 algorithm. The algorithm identifier for RSA with SHA-1 is: 6496 Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 6497 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 6499 NOTE: RFC 3370 [10] recommends that MD5 is not used for new 6500 implementations. 6502 Internet-draft CMS Advanced Electronic Signatures September 2007 6504 I.2.3 General 6506 The following is a selection of work that has been done in the area of 6507 digital signature mechanisms: 6509 - FIPS Publication 186 (1994): "Digital Signature Standard". 6510 NIST's Digital Signature Algorithm (DSA) is a variant of 6511 ElGamal's Discrete Logarithm based digital signature mechanism. 6512 The DSA requires a 160-bit hash-function and mandates SHA-1. 6514 - IEEE P1363 (2000) [P1363]: "Standard Specifications for 6515 Public-Key Cryptography". IEEE P1363 contains mechanisms for 6516 digital signatures, key establishment, and encipherment based on 6517 three families of public-key schemes: 6519 - "Conventional" Discrete Logarithm (DL) based techniques, i.e. 6520 Diffie-Hellman (DH) key agreement, Menezes-Qu-Vanstone (MQV) 6521 key agreement, the Digital Signature Algorithm (DSA), and 6522 Nyberg-Rueppel (NR) digital signatures; 6524 - Elliptic Curve (EC) based variants of the DL-mechanisms 6525 specified above, i.e. EC-DH, EC-MQV, EC-DSA, and EC-NR. For 6526 elliptic curves, implementation options include mod p and 6527 characteristic 2 with polynomial or normal basis 6528 representation; 6530 - Integer Factoring (IF) based techniques including RSA 6531 encryption, RSA digital signatures, and RSA-based key 6532 transport. 6534 - ISO/IEC 9796 (1991) [ISO9796]: "Information technology - Security 6535 techniques - Digital signature scheme giving message recovery". 6536 ISO/IEC 9796 specifies a digital signature mechanism based on the 6537 RSA public-key technique and a specifically designed redundancy 6538 function. 6540 - ISO/IEC 9796-2 (1997) [ISO9796-2]: "Information technology - 6541 Security techniques - Digital signature schemes giving message 6542 recovery - Part 2: Mechanisms using a hash-function". 6543 ISO/IEC 9796-2 specifies digital signature mechanisms with 6544 partial message recovery that are also based on the RSA technique 6545 but make use of a hash-function. 6547 - ISO/IEC 9796-4 (1998) [ISO9796-4]: "Digital signature schemes 6548 giving message recovery - Part 4: Discrete logarithm based 6549 mechanisms". ISO/IEC 9796-4 specifies digital signature 6550 mechanisms with partial message recovery that are based on 6551 Discrete Logarithm techniques. The document includes the 6552 Nyberg-Rueppel scheme. 6554 - ISO/IEC 14888-1 [ISO14888-1]: "Digital signatures with appendix - 6555 Part 1: General". ISO/IEC 14888-1 contains definitions and 6556 describes the basic concepts of digital signatures with appendix. 6558 Internet-draft CMS Advanced Electronic Signatures September 2007 6560 - ISO/IEC 14888-2 [ISO14888-2]: "Digital signatures with appendix - 6561 Part 2: Identity-based mechanisms". ISO/IEC 14888-2 specifies 6562 digital signature schemes with appendix that make use of 6563 identity-based keying material. The document includes the 6564 zero-knowledge techniques of Fiat-Shamir and Guillou-Quisquater. 6566 - ISO/IEC 14888-3 [ISO14888-3]: "Digital signatures with appendix - 6567 Part 3: Certificate-based mechanisms". ISO/IEC 14888-3 specifies 6568 digital signature schemes with appendix that make use of 6569 certificate-based keying material. The document includes five 6570 schemes: 6572 - DSA; 6573 - EC-DSA, an elliptic curve based analog of NIST's Digital 6574 Signature Algorithm; 6575 - Pointcheval-Vaudeney signatures; 6576 - RSA signatures; 6577 - ESIGN. 6579 - ISO/IEC 15946-2 (2002) [ISO15946-2]: "Cryptographic techniques 6580 based on elliptic curves - Part 2: Digital signatures". 6582 - ISO/IEC 15946-3 (2002) [ISO 15946-3] specifies digital signature 6583 schemes with appendix using elliptic curves. 6585 - The document includes two schemes: 6587 - EC-DSA, an elliptic curve based analog of NIST's Digital 6588 Signature Algorithm; 6590 - EC-AMV, an elliptic curve based analog of the Agnew-Muller- 6591 Vanstone signature algorithm. 6593 - ANSI X9.31-1 (1997) [X9.31-1]: "Public Key Cryptography Using 6594 Reversible Algorithms for the Financial Services Industry � 6595 Part 1: The RSA Signature Algorithm". ANSI X9.31-1 specifies a 6596 digital signature mechanism with appendix using the RSA 6597 public-key technique. 6599 - ANSI X9.30-1 (1997) [X9.30-1]: "Public Key Cryptography Using 6600 Irreversible Algorithms for the Financial Services Industry � 6601 Part 1: The Digital Signature Algorithm (DSA)". ANSI X9.30-1 6602 specifies the DSA, NIST's Digital Signature Algorithm. 6604 - ANSI X9.62 (1998) [X9.62]: "Public Key Cryptography for the 6605 Financial Services Industry - The Elliptic Curve Digital 6606 Signature Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic 6607 Curve Digital Signature Algorithm, an analog of NIST's Digital 6608 Signature Algorithm (DSA) using elliptic curves. The appendices 6609 provide tutorial information on the underlying mathematics for 6610 elliptic curve cryptography and many examples. 6612 Internet-draft CMS Advanced Electronic Signatures September 2007 6614 Annex J (informative): Changes from the previous version 6616 The title of the document has changed to be aligned with the title 6617 of XAdES (XML Advanced Electronic Signatures), the vocabulary used 6618 within the present document has been aligned with the vocabulary 6620 used in XAdES, 6622 If the hash of the signature policy is unknown, then, by 6623 convention, the sigPolicyHash shall be set to all zeros. 6625 The OIDs from the ASN.1 modules have changed for the following 6626 reasons: 6628 - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have been 6629 included. 6631 - since RFC 2459 and RFC 3852 has been obsoleted by RFC 3280 and 6632 RFC 3852 respectively, there was the need to refer to the OIDs 6633 of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the 6634 OIDs of the ASN.1 modules of RFC 2459 and RFC 3852. 6636 - other changes are related to the addition of the signing- 6637 certificate attribute, where the ESS signing-certificate 6638 attribute defined in RFC 2634, shall be used if the SHA-1 6639 hashing algorithm is used, while the ESS signing-certificate 6640 attribute v2, defined in �ESS Update: Adding CertID Algorithm 6641 Agility RFC 5035 shall be used when other hashing algorithms 6642 are to be used. 6644 - the definition of the Archive time-stamp attribute has been 6645 changed in section 6.4.1. to protect all signed and unsined 6646 attributes. A new object identifier has been assigned to this 6647 attribute. 6649 Internet-draft CMS Advanced Electronic Signatures September 2007 6651 Full Copyright Statement 6653 Copyright (C) The IETF Trust (2007). 6655 This document is subject to the rights, licenses and restrictions 6656 contained in BCP 78, and except as set forth therein, the authors 6657 retain all their rights. 6659 This document and the information contained herein are provided on 6660 An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 6661 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 6662 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 6663 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 6664 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 6665 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 6666 FOR A PARTICULAR PURPOSE. 6668 Intellectual Property 6670 The IETF takes no position regarding the validity or scope of any 6671 Intellectual Property Rights or other rights that might be claimed 6672 to pertain to the implementation or use of the technology described 6673 in this document or the extent to which any license under such 6674 rights might or might not be available; nor does it represent that 6675 it has made any independent effort to identify any such rights. 6676 Information on the procedures with respect to rights in RFC 6677 documents can be found in BCP 78 and BCP 79. 6679 Copies of IPR disclosures made to the IETF Secretariat and any 6680 assurances of licenses to be made available, or the result of an 6681 attempt made to obtain a general license or permission for the use 6682 of such proprietary rights by implementers or users of this 6683 specification can be obtained from the IETF on-line IPR repository 6684 at http://www.ietf.org/ipr. 6686 The IETF invites any interested party to bring to its attention any 6687 copyrights, patents or patent applications, or other proprietary 6688 rights that may cover technology that may be required to implement 6689 this standard. Please address the information to the IETF at 6690 ietf-ipr@ietf.org. 6692 ETSI takes no position regarding the validity or scope of any 6693 Intellectual Property Rights or other rights that might be claimed 6694 to pertain to the implementation or use of the technology described 6695 in this document or the extent to which any license under such 6696 rights might or might not be available; nor does it represent that 6697 it has made any independent effort to identify any such rights. 6699 Information on the ETSI Intellectual Property Rights Policy may be 6700 obtained from . The document is 6701 an extract from Annex 6 of the ETSI Rules of Procedure that are 6702 available at : . 6704 Internet-draft CMS Advanced Electronic Signatures September 2007 6706 The ETSI IPR database http://webapp.etsi.org/IPR/home.asp contains 6707 IPRs, particularly patents and patent applications, which have been 6708 notified to ETSI as being essential, or potentially essential, to 6709 ETSI standards. Unless otherwise specified, all IPRs contained 6710 herein have been notified to ETSI, with an undertaking from the 6711 owner to grant licenses according to the terms and conditions of 6712 Article 6.1 of Annex 6 of the ETSI Rules of the ETSI IPR Policy. 6714 The ETSI IPR database provides data that is based on the information 6715 received. ETSI has not checked the validity of the information, nor 6716 the relevance of the identified patents/patent applications to the 6717 ETSI Standards and cannot confirm, or deny, that the patents/patent 6718 applications are, in fact, essential, or potentially essential. No 6719 investigation, or IPR searches, have been carried out by ETSI and 6720 therefore no guarantee can be given concerning the existence of 6721 other IPRs which are, or may become, essential. 6723 Potential Licensees should use the information in this database at 6724 their discretion and should contact the patent holder. 6726 Acknowledgements 6728 Funding for the RFC Editor function is currently provided by the 6729 Internet Society. 6731 Funding for the publication of the previous RFC has been provided 6732 by ETSI and the European Commision.