idnits 2.17.1 draft-ietf-smime-cades-04.txt: -(1573): 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 6412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6425. ** 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 1471: '...fication process MUST be the signer's ...' RFC 2119 keyword, line 1476: '...gningCertificate MUST be the key used ...' RFC 2119 keyword, line 1528: '... MUST be used if the SHA-1 hashing...' RFC 2119 keyword, line 1531: '... Adding CertID Algorithm Agility�, RFC 5035 [15] which SHALL be...' RFC 2119 keyword, line 1622: '...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 1682 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 6067 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ISO13888-1' is mentioned on line 514, but not defined == Missing Reference: 'CWA 14171' is mentioned on line 1055, but not defined == Missing Reference: 'RFC 2634' is mentioned on line 1527, but not defined == Missing Reference: '0' is mentioned on line 3928, but not defined == Missing Reference: 'RFC2743' is mentioned on line 5971, but not defined == Missing Reference: 'ISO9796' is mentioned on line 6275, but not defined == Missing Reference: 'ISO 15946-3' is mentioned on line 6321, but not defined == Unused Reference: 'TS102023' is defined on line 3030, but no explicit reference was found in the text == Unused Reference: 'ISO15946-3' is defined on line 3112, but no explicit reference was found in the text == Unused Reference: 'X690' is defined on line 3116, but no explicit reference was found in the text == Unused Reference: 'CWA14171' is defined on line 3119, 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 Table of Contents 56 1. Introduction 6 58 2. Scope 6 60 3. Definitions and abbreviations 8 61 3.1 Definitions 8 62 3.2 Abbreviations 11 64 4. Overview 12 65 4.1 Major parties 12 66 4.2 Signatures policies 14 67 4.3 Electronic signature formats 14 68 4.3.1 CAdES Basic Electronic Signature (CAdES-BES) 14 69 4.3.2 CAdES Explicit Policy Electronic Signatures (CAdES-EPES) 17 70 4.4 Electronic signature formats with validation data 18 71 4.4.1 Electronic Signature with Time (CAdES-T) 19 72 4.4.2 ES with Complete validation data references (CAdES-C) 20 73 4.4.3 Extended electronic signature formats 22 74 4.4.4 Archival Electronic Signature (CAdES-A) 26 75 4.5 Arbitration 27 76 4.6 Validation process 28 78 5. Electronic signature attributes 29 79 5.1 General syntax 29 80 5.2 Data content type 29 81 5.3 Signed-data content type 29 82 5.4 SignedData type 29 83 5.5 EncapsulatedContentInfo type 30 84 5.6 SignerInfo type 30 85 5.6.1 Message digest calculation process 31 86 5.6.2 Message signature generation process 31 87 5.6.3 Message signature verification process 31 88 5.7 Basic ES mandatory present attributes 31 89 5.7.1 Content type 31 90 5.7.2 Message digest 32 91 5.7.3 Signing certificate reference attribute 32 92 5.8 Additional mandatory attributes for Explicit Policy-based 93 Electronic Signatures 34 94 5.8.1 Signature policy identifier 34 95 5.9 CMS imported optional attributes 36 96 5.9.1 Signing time 36 97 5.9.2 Countersignature 36 98 5.10 ESS imported optional attributes 37 99 5.10.1 Content reference attribute 37 100 5.10.2 Content identifier attribute 37 101 5.10.3 Content hints attribute 37 102 5.11 Additional optional attributes defined in the present document 38 103 5.11.1 Commitment type indication attribute 38 104 5.11.2 Signer location attribute 40 105 5.11.3 Signer attributes attribute 40 106 5.11.4 Content time-stamp 41 107 5.12 Support for multiple signatures 41 108 5.12.1 Independent signatures 41 109 5.12.2 Embedded signatures 42 111 6. Additional Electronic Signature validation attributes 42 112 6.1 Electronic Signature Time-stamped (CAdES-T) 43 113 6.1.1 Signature time- stamp attribute definition 44 114 6.2 Complete validation reference data (CAdES-C) 44 115 6.2.1 Complete certificate references attribute definition 45 116 6.2.2 Complete Revocation References attribute definition 45 117 6.2.3 Attribute certificate references attribute definition 47 118 6.2.4 Attribute revocation references attribute definition 48 119 6.3 Extended validation data (CAdES-X) 48 120 6.3.1 Time-stamped validation data (CAdES-X Type 1 or Type 2) 48 121 6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2) 48 122 6.3.3 Certificate values attribute definition 49 123 6.3.4 Revocation values attribute definition 50 124 6.3.5 CAdES-C time-stamp attribute definition 51 125 6.3.6 Time-stamped certificates and crls references attribute 126 definition 52 127 6.4 Archive validation data 53 128 6.4.1 Archive time-stamp attribute definition 53 130 7. Other standard data structures 55 131 7.1 Public-key certificate format 55 132 7.2 Certificate revocation list format 55 133 7.3 OCSP response format 55 134 7.4 Time-stamp token format 55 135 7.5 Name and attribute formats 55 136 7.6 Attribute certificate 56 138 8. Conformance requirements 56 139 8.1 CAdES-Basic Electronic Signature (CAdES-BES) 56 140 8.2 CAdES-Explicit Policy-based Electronic Signature 57 141 8.3 Verification using time-stamping 57 142 8.4 Verification using secure records 58 144 9. Security considerations 58 145 9.1 Protection of private key 58 146 9.2 Choice of algorithms 58 148 10. IANA Considerations 59 150 11. References 59 151 11.1 Normative references 58 152 11.2 Informative references 60 154 12. Authors' addresses 62 155 13. Acknowledgments 63 157 Annex A (normative): ASN.1 definitions 64 158 A.1 Signature format definitions using X.208 ASN.1 syntax 64 159 A.2 Signature format definitions using X.680 ASN.1 syntax 72 161 Annex B (informative): Extended forms of Electronic Signatures 81 162 B.1 Extended forms of validation data 81 163 B.1.1 CAdES-X Long 82 164 B.1.2 CAdES-X Type 1 83 165 B.1.3 CAdES-X Type 2 84 166 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 85 167 B.2 Timestamp extensions 87 168 B.3 Archive validation data (CAdES-A) 88 169 B.4 Example validation sequence 90 170 B.5 Additional optional features 95 172 Annex C (informative):General description 96 173 C.1 The signature policy 96 174 C.2 Signed information 97 175 C.3 Components of an electronic signature 97 176 C.3.1 Reference to the signature policy 97 177 C.3.2 Commitment type indication 98 178 C.3.3 Certificate identifier from the signer 98 179 C.3.4 Role attributes 99 180 C.3.4.1 Claimed role 99 181 C.3.4.2 Certified role 100 182 C.3.5 Signer location 100 183 C.3.6 Signing time 100 184 C.3.7 Content format 101 185 C.3.8 Content hints 101 186 C.3.9 Content cross referencing 101 187 C.4 Components of validation data 101 188 C.4.1 Revocation status information 101 189 C.4.1.1 CRL information 102 190 C.4.1.2 OCSP information 102 191 C.4.2 Certification path 103 192 C.4.3 Time-stamping for long life of signatures 103 193 C.4.4 Time-stamping for long life of signature before CA key 194 compromises 104 195 C.4.4.1 Time-stamping the ES with complete validation data 105 196 C.4.4.2 Time-stamping certificates and revocation information 197 references 106 198 C.4.5 Time-stamping for archive of signature 107 199 C.4.6 Reference to additional data 108 200 C.4.7 Time-stamping for mutual recognition 108 201 C.4.8 TSA key compromise 109 202 C.5 Multiple signatures 109 204 Annex D (informative):Data protocols to interoperate with TSPs 110 205 D.1 Operational protocols 110 206 D.1.1 Certificate retrieval 110 207 D.1.2 CRL retrieval 110 208 D.1.3 OnLine certificate status 110 209 D.1.4 Time-stamping 110 210 D.2 Management protocols 110 211 D.2.1 Request for certificate revocation 110 213 Annex E (informative): Guidance on naming 111 214 E.1 Allocation of names 111 215 E.2 Providing access to registration information 111 216 E.3 Naming schemes 112 217 E.3.1 Naming schemes for individual citizens 112 218 E.3.2 Naming schemes for employees of an organization 113 220 Annex F (informative): Example structured contents and MIME 114 221 F.1 General description 114 222 F.2 Header information 114 223 F.3 Content encoding 116 224 F.4 Multi-part content 116 225 F.5 S/MIME 116 227 Annex G (informative): Relationship to the European Directive 228 And EESSI 119 229 G.1 Introduction 119 230 G.2 Electronic signatures and the directive 119 231 G.3 ETSI electronic signature formats and the directive 120 232 G.4 EESSI standards and classes of electronic signature 120 233 G.4.1 Structure of EESSI standardization 120 234 G.4.2 Classes of electronic signatures 121 235 G.4.3 EESSI classes and the ETSI electronic signature format 121 237 Annex H (informative): APIs for the generation and verification 238 of electronic signatures tokens 121 239 H.1 Data framing 122 240 H.2 IDUP-GSS-APIs defined by the IETF 123 241 H.3 CORBA security interfaces defined by the OMG 124 243 Annex I (informative):Cryptographic algorithms 126 244 I.1 Digest algorithms 126 245 I.1.1 SHA-1 126 246 I.1.2 General 126 247 I.2 Digital signature algorithms 127 248 I.2.1 DSA 127 249 I.2.2 RSA 127 250 I.2.3 General 128 252 Annex J (informative): Changes from the previous version 130 254 Full Copyright Statement 131 256 Disclaimer 131 258 Intellectual Property 131 259 1. Introduction 261 This document is intended to cover electronic signatures for various 262 types of transactions, including business transactions (e.g. purchase 263 requisition, contract, and invoice applications) where long term 264 validity of such signatures is important. This includes evidence as 265 to its validity even if the signer or verifying party later attempts 266 to deny (i.e., repudiates, see ISO/IEC 10181-5 [ISO10181-5]) the 267 validity of the signature). 269 Thus the present document can be used for any transaction between an 270 individual and a company, between two companies, between an individual 271 and a governmental body, etc. The present document is independent of 272 any environment. It can be applied to any environment e.g. smart cards, 273 GSM SIM cards, special programs for electronic signatures, etc. 275 The European Directive on a community framework for Electronic 276 Signatures defines an electronic signature as: "Data in electronic form 277 which is attached to or logically associated with other electronic data 278 and which serves as a method of authentication". 280 An electronic signature as used in the present document is a form 281 of advanced electronic signature as defined in the Directive. 283 2. Scope 285 The scope of the present document covers Electronic Signature Formats 286 only. The aspects of Electronic Signature Policies are defined in 287 RFC 3125 [RFC3125] and in ETSI TR 102 272 [TR102272]. 289 The present document defines a number of Electronic Signature Formats, 290 including electronic signature that can remain valid over long periods. 291 This includes evidence as to its validity even if the signer or 292 verifying party later attempts to deny (repudiates) the validity of the 293 electronic signature. 295 The present document specifies use of trusted service providers (e.g. 296 Time-Stamping Authorities), and the data that needs to be archived 297 (e.g. cross certificates and revocation lists) to meet the requirements 298 of long term electronic signatures. 300 An electronic signature defined by the present document can be used for 301 arbitration in case of a dispute between the signer and verifier, which 302 may occur at some later time, even years later. 304 The present document includes the concept of signature policies that 305 can be used to establish technical consistency when validating 306 electronic signatures but does not mandate their use. 308 The present document is based on the use of public key cryptography to 309 produce digital signatures, supported by public key certificates. 310 The present document also specifies the use of time-stamping and time- 311 marking services to prove the validity of a signature long after the 312 normal lifetime of critical elements of an electronic signature. It 313 also, as an option, defines ways to provide very long-term protection 314 against key compromise or weakened algorithms. 316 The present document builds on existing standards that are widely 317 adopted. This includes: 319 - RFC 3852 [4] "Cryptographic Message Syntax (CMS)"; 321 - ISO/IEC 9594-8/ITU-T Recommendation X.509 [1]: "Information 322 technology - Open Systems Interconnection - The Directory: 323 Authentication framework"; 325 - RFC 3280 [2] "Internet X.509 Public Key Infrastructure (PKIX) 326 Certificate and CRL Profile"; 328 - RFC 3161 [7] "Internet X.509 Public Key Infrastructure Time-Stamp 329 Protocol". 331 NOTE: See section 11 for a full set of references. 333 The present document describes formats for advanced electronic 334 signatures using ASN.1 (Abstract Syntax Notation 1) [14]. ASN.1 335 is encoded using X.209 [X.209]. 337 These formats are based on CMS (Cryptographic Message Syntax) defined 338 in RFC 3852 [4]. These electronic signatures are thus called CAdES, 339 for "CMS Advanced Electronic Signatures". 341 Another document, TS 101 903 [TS101903], describes formats for XML 342 advanced electronic signatures (XAdES) built on XMLDSIG [XMLDSIG]. 344 In addition, the present document identifies other documents that 345 define formats for Public Key Certificates, Attribute Certificates, 346 Certificate Revocation Lists and supporting protocols, including, 347 protocols for use of trusted third parties to support the operation of 348 electronic signature creation and validation. 350 Informative annexes include: 352 - illustrations of extended forms of extended Electronic Signatures 353 formats that protect against various vulnerabilities and examples 354 of validation processes (Annex B); 356 - descriptions and explanations of some of the concepts used in the 357 present document, giving a rationale for normative parts of the 358 present document (Annex C); 360 - information on protocols to interoperate with Trusted Service 361 Providers (Annex D); 363 - guidance on naming (Annex E); 365 - an example structured content and MIME (Annex F); 367 - the relationship between the present document and the directive 368 on electronic signature and associated standardization 369 initiatives (Annex G); 370 - APIs to support the generation and the verification of electronic 371 signatures (Annex H); 373 - cryptographic algorithms that may be used (Annex I); and 375 - changes from the previous version (see Annex J). 377 3 Definitions and abbreviations 379 3.1 Definitions 381 For the purposes of the present document, the following terms and 382 definitions apply: 384 Arbitrator: arbitrator entity may be used to arbitrate a dispute 385 between a signer and verifier when there is a disagreement on the 386 validity of a digital signature. 388 Attribute Authority (AA): authority which assigns privileges by issuing 389 attribute certificates. 391 Authority certificate: certificate issued to an authority (e.g. either 392 to a certification authority or to an attribute authority). 394 Attribute Authority Revocation List (AARL): revocation list containing 395 a list of references to certificates issued to AAs, that are no longer 396 considered valid by the issuing authority. 398 Attribute Certificate Revocation List (ACRL): revocation list 399 containing a list of references to attribute certificates that are no 400 longer considered valid by the issuing authority. 402 Certification Authority Revocation List (CARL): revocation list 403 containing a list of public-key certificates issued to certification 404 authorities, that are no longer considered valid by the certificate 405 issuer. 406 Certification Authority (CA): authority trusted by one or more users to 407 create and assign public key certificates, optionally the certification 408 authority may create the users' keys. 410 NOTE: See ITU-T Recommendation X.509 [1]. 412 Certificate Revocation List (CRL): signed list indicating a set of 413 public key certificates that are no longer considered valid by the 414 certificate issuer. 416 Digital signature: data appended to, or a cryptographic transformation 417 of, a data unit that allows a recipient of the data unit to prove the 418 source and integrity of the data unit and protect against forgery, e.g. 419 by the recipient. 421 NOTE: See ISO 7498-2 [ISO7498-2]. 423 Electronic signature: data in electronic form which are attached to or 424 logically associated with other electronic data and which serve as a 425 method of authentication. 427 NOTE: See Directive 1999/93/EC of the European Parliament and of the 428 Council of 13 December 1999 on a Community framework for 429 electronic signatures [EU Directive]. 431 Enhanced electronic signatures: electronic signatures enhanced by 432 complementing the baseline requirements with additional data, such as 433 time tamp tokens and certificate revocation data, to address commonly 434 recognized threats. 436 Explicit Policy-based Electronic Signature (EPES): an electronic 437 signature where the signature policy is explicitly specified that shall 438 be used to validate it. 440 Grace period: time period which permits the certificate revocation 441 information to propagate through the revocation process to relying 442 parties. 444 Initial verification: a process performed by a verifier done after an 445 electronic signature is generated in order to capture additional 446 information that could make it valid for long term verification. 448 Public Key Certificate (PKC): public keys of a user, together with some 449 other information, rendered unforgeable by encipherment with the 450 private key of the certification authority which issued it. 452 NOTE: See ITU-T Recommendation X.509 [1]. 454 Rivest-Shamir-Adleman (RSA): asymmetric cryptography algorithm based on 455 the difficulty to factor very large numbers, using a key pair: a 457 private key and a public key. 459 Signature policy: set of rules for the creation and validation of an 460 electronic signature, that defines the technical and procedural 461 requirements for electronic signature creation and validation, in order 462 to meet a particular business need, and under which the signature can 463 be determined to be valid. 465 Signature policy issuer: entity that defines and issues a signature 466 policy. 468 Signature validation policy: part of the signature policy which 469 specifies the technical requirements on the signer in creating a 470 signature and verifier when validating a signature. 472 Signer: entity that creates an electronic signature. 474 Subsequent Verification: a process performed by a verifier to assess 475 the signature validity. 477 NOTE: It may be done even years after the electronic signature was 478 produced by the signer and completed by the Initial 479 Verification and it might not need to capture more data than 480 those captured at the time of initial verification. 482 Time-Stamp token: data object that binds a representation of a datum to 483 a particular time, thus establishing evidence that the datum existed 484 before that time. 486 Time-Mark: information in an audit trail from a Trusted Service 487 Provider that binds a representation of a datum to a particular time, 488 thus establishing evidence that the datum existed before that time. 490 Time-Marking Authority: trusted third party that creates records in an 491 audit trail in order to indicate that a datum existed before a 492 particular point in time. 494 Time-Stamping Authority (TSA): trusted third party that creates time- 495 stamp tokens in order to indicate that a datum existed at a particular 496 point in time. 498 Time-Stamping Unit (TSU): set of hardware and software which is managed 499 as a unit and has a single time-stamp token signing key active at a 500 time. 502 Trusted Service Provider (TSP): entity that helps to build trust 503 relationships by making available or providing some information upon 504 request. 506 Validation data: additional data that may be used by a verifier of 507 electronic signatures to determine the signature is valid. 509 Valid electronic signature: electronic signature which passes 510 validation. 512 Verifier: entity that verifies evidence. 514 NOTE 1: See ISO/IEC 13888-1 [ISO13888-1]. 516 NOTE 2: Within the context of the present document this is an entity 517 that validates an electronic signature. 519 3.2 Abbreviations 521 For the purposes of the present document, the following abbreviations 522 apply: 524 AA Attribute Authority 526 AARL Attribute Authority Revocation List 527 ACRL Attribute Certificate Revocation List 528 API Application Program Interface 529 ASCII American Standard Code for Information Interchange 530 ASN.1 Abstract Syntax Notation 1 531 CA Certification Authority 532 CAD Card Accepting Device 533 CAdES CMS Advanced Electronic Signature 534 CAdES-A CAdES with Archive validation data 535 CAdES-BES CAdES Basic Electronic Signature 536 CAdES-C CAdES with Complete validation data 537 CAdES-EPES CAdES Explicit Policy Electronic Signature 538 CAdES-T CAdES with Time-stamp 539 CAdES-X CAdES with eXtended validation data 540 CARL Certification Authority Revocation List 541 CMS Cryptographic Message Syntax 542 CRL Certificate Revocation List 543 CWA CEN Workshop Agreement 544 DER Distinguished Encoding Rules (for ASN.1) 545 DSA Digital Signature Algorithm 546 EDIFACT Electronic Data Interchange For Administration, Commerce 547 and Transport 549 EESSI European Electronic Signature Standardization Initiative 550 EPES Explicit Policy-based Electronic Signature 551 ES Electronic Signature 552 ESS Enhanced Security Services (enhances CMS) 553 IDL Interface Definition Language 554 MIME Multipurpose Internet Mail Extensions 555 OCSP Online Certificate Status Provider 556 OID Object IDentifier 557 PKC Public Key Certificate 558 PKIX Public Key Infrastructure using X.509 (IETF Working Group) 559 RSA Rivest-Shamir-Adleman 560 SHA-1 Secure Hash Algorithm 1 561 TSA Time-Stamping Authority 562 TSP Trusted Service Provider 563 TST Time-Stamp Token 564 TSU Time-Stamping Unit 565 URI Uniform Resource Identifier 566 URL Uniform Resource Locator 567 XML eXtended Mark up Language 568 XMLDSIG XML-Signature Syntax and Processing 570 4 Overview 572 The present document defines a number of Electronic Signature (ES) 573 formats that build on CMS (RFC 3852 [4]) by adding signed and unsigned 574 attributes. 576 This section provides an introduction to the major parties involved 577 (section 4.1), the concept of Signature Policies (section 4.2), provides 578 an overview of the various ES formats (section 4.3), introduces the 579 concept of validation data and provides an overview of formats that 580 incorporate validation data (section 4.4), presents relevant 581 considerations on arbitration (section 4.5) and for the validation 582 process (section 4.6). 584 The formal specifications of the attributes are specified in sections 5 585 and 6, annexes C and D provide rationale for the definitions of the 586 different ES forms. 588 4.1 Major parties 590 The major parties involved in a business transaction supported by 591 electronic signatures as defined in the present document are: 593 - the Signer; 594 - the Verifier; 595 - Trusted Service Providers (TSP); and 596 - the Arbitrator. 598 The signer is the entity that creates the electronic signature. When 599 the signer digitally signs over data using the prescribed format, this 600 represents a commitment on behalf of the signing entity to the data 601 being signed. 603 The verifier is the entity that validates the electronic signature, it 604 may be a single entity or multiple entities. 606 The Trusted Service Providers (TSPs) are one or more entities that help 607 to build trust relationships between the signer and verifier. They 608 support the signer and verifier by means of supporting services 609 including: user certificates, cross-certificates, time-stamp tokens, 610 CRLs, ARLs, OCSP responses. The following TSPs are used to support the 611 functions defined in the present document: 613 - Certification Authorities; 614 - Registration Authorities; 615 - CRL Issuers; 616 - OCSP Responders; 617 - Repository Authorities (e.g. a Directory); 618 - Time-Stamping Authorities; 619 - Time-Marking Authorities; and 620 - Signature Policy Issuers. 622 Certification Authorities provide users with public key certificates 623 and with a revocation service. 625 Registration Authorities allow the identification and registration of 626 entities before a CA generates certificates. 628 Repository Authorities publish CRLs issued by CAs, signature policies 629 issued by Signature Policy Issuers and optionally public key 630 certificates. 632 Time-Stamping Authorities attest that some data was formed before a 633 given trusted time. 635 Time-Marking Authorities record that some data was formed before a 636 given trusted time. 638 Signature Policy Issuers define the signature policies to be used by 639 signers and verifiers. 641 In some cases the following additional TSPs are needed: 643 - Attribute Authorities. 645 Attributes Authorities provide users with attributes linked to public 646 key certificates. 648 An Arbitrator is an entity that arbitrates in disputes between a signer 649 and a verifier. 651 4.2 Signatures policies 653 The present document includes the concept of signature policies that 654 can be used to establish technical consistency when validating 655 electronic signatures. 657 When a comprehensive signature policy used by the verifier is either 658 explicitly indicated by the signer or implied by the data being signed, 659 then a consistent result can be obtained when validating an electronic 660 signature. 662 When the signature policy being used by the verifier is neither 663 indicated by the signer nor can be derived from other data, or the 664 signature policy is incomplete then verifiers, including arbitrators, 665 may obtain different results when validating an electronic signature. 666 Therefore, comprehensive signature policies that ensure consistency of 667 signature validation are recommended from both the signers and 668 verifiers point of view. 670 Further information on signature policies is provided in: 672 - TR 102 038 [TR102038]; 673 - sections 5.8.1, C.1 and C.3.1 of the present document; 674 - RFC 3125 [RFC3125]; and 675 - TR 102 272 [TR102272]. 677 4.3 Electronic signature formats 679 The current document sectionprovides an overview for two forms of CMS 680 advanced electronic signature specified in the present document, 681 namely, the CAdES Basic Electronic Signature (CAdES-BES) and the 682 CAdES Explicit Policy-based Electronic Signature (CAdES-EPES). 683 Conformance to the present document mandates the signer creates one of 684 these formats. 686 4.3.1 CAdES Basic Electronic Signature (CAdES-BES) 688 A CAdES Basic Electronic Signature (CAdES-BES) in accordance with the 689 present contains: 691 - The signed user data (e.g. the signer's document) as defined in 692 CMS (RFC 3852 [4]); 694 - A collection of mandatory signed attributes as defined in CMS 695 (RFC 3852 [4]) and in ESS (RFC 2634 [5]); 697 - Additional mandatory signed attributes defined in the present 698 document; and 700 - The digital signature value computed on the user data and, when 701 present, on the signed attributes, as defined in CMS (RFC 3852 702 [4]). 704 A CAdES Basic Electronic Signature (CAdES-BES) in accordance with the 705 present document may contain: 707 - a collection of additional signed attributes; and 708 - a collection of optional unsigned attributes. 710 The mandatory signed attributes are: 712 - Content-type. It is defined in RFC 3852 [4] and specifies the 713 type of the EncapsulatedContentInfo value being signed. Details 714 are provided in 5.7.1. Rationale for its inclusion is provided 715 in section C.3.7; 717 - Message-digest. It is defined in RFC 3852 [4] and specifies the 718 message digest of the eContent OCTET STRING within 719 encapContentInfo being signed. Details are provided in section 720 5.7.2; 722 - ESS signing-certificate OR ESS signing-certificate v2. The ESS 723 signing-certificate attribute is defined in Enhanced Security 724 Services (ESS), RFC 2634 [5] and only allows for the use of SHA-1 725 as digest algorithm. The ESS signing-certificate attribute V2 726 is defined in �ESS Update: Adding CertID Algorithm Agility� 727 RFC 5035 [15], and allows for the use of any digest algorithm. 728 A CAdES-BES claiming compliance with the present document must 729 include one of them. Section 5.7.3 provides the details of 730 these attributes. Rationale for its inclusion is provided in 731 section C.3.3. 733 Optional signed attributes may be added to the CAdES-BES, including 734 optional signed attributes defined in CMS (RFC 3852 [4]), ESS (RFC 2634 735 [5]) and the present document. Listed below are optional attributes 736 that are defined in section 5 and have a rational provided in annex C: 738 - Signing-time: as defined in CMS (RFC 3852 [4]) indicates the time 739 of the signature as claimed by the signer. Details and short 740 rationale are provided in section 5.9.1. Section C.3.6 provides 741 the rationale. 743 - Content-hints as defined in ESS (RFC 2634 [5]) provides 744 information that describes the innermost signed content of a 745 multi-layer message where one content is encapsulated in another. 746 Section 5.10.1 provides the specification details. Section C.3.8 747 provides the rationale. 749 - Content-reference. as defined in ESS (RFC 2634 [5]) can be 750 incorporated as a way to link request and reply messages in an 751 exchange between two parties. Section 5.10.1 provides the 752 specification details. Section C.3.9 provides the rationale. 754 - Content-identifier. as defined in ESS (RFC 2634 [5]) contains an 755 identifier that may be used later on in the previous content- 756 reference attribute. Section 5.10.2 provides the specification 757 details. Section C.3.8 provides the rationale. 759 - Commitment-type-indication. This attribute is defined by the 760 present document as a way to indicate the commitment endorsed by 761 the signer when producing the signature. Section 5.11.1 provides 762 the specification details. Section C.3.2 provides the 763 rationale. 765 - Signer-location. This attribute is defined by the present 766 document. It allows the signer to indicate the place where the 767 signer purportedly produced the signature. Section 5.11.2 768 provides the specification details. Section C.3.5 provides the 769 rationale. 771 - Signer-attributes. This attribute is defined by the present 772 document. It allows a claimed or certified role to be 773 incorporated into the signed information. Section 5.11.3 provides 774 the specification details. Section C.3.4 provides the rationale. 776 - Content-time-stamp. This attribute is defined by the present 777 document. It allows a time-stamp token of the data to be signed 778 to be incorporated into the signed information. It provides 779 proof of the existence of the data before the signature was 780 created. Section 5.11.4 provides the specification details. 781 Section C.3.6 provides the rationale. 783 A CAdES-BES form can also incorporate instances of unsigned attributes 784 as defined in CMS (RFC 3852 [4]) and ESS (RFC 2634 [5]). 786 - CounterSignature, as defined in CMS (RFC 3852 [4]). It can be 787 incorporated wherever embedded signatures (i.e. a signature on 788 a previous signature) are needed. Section 5.9.2 provides the 789 specification details. Section C.5 in annex C provides the 790 rationale. 792 The structure of the CAdES-BES is illustrated in figure 1. 794 +------Elect.Signature (CAdES-BES)------+ 795 |+----------------------------------- + | 796 ||+---------+ +----------+ | | 797 |||Signer's | | Signed | Digital | | 798 |||Document | |Attributes| Signature | | 799 ||| | | | | | 800 ||+---------+ +----------+ | | 801 |+------------------------------------+ | 802 +---------------------------------------+ 804 Figure 1: Illustration of a CAdES-BES 806 The signer's conformance requirements of a CAdES-BES are defined in 807 section 8.1. 809 NOTE: The CAdES-BES is the minimum format for an electronic signature 810 to be generated by the signer. On its own, it does not 811 provide enough information for it to be verified in the longer 812 term. For example, revocation information issued by the 813 relevant certificate status information issuer needs to be 814 available for long term validation (see section 4.4.2). 816 The CAdES-BES satisfies the legal requirements for electronic 817 signatures as defined in the European Directive on electronic 818 signatures, (see annex C for further discussion on relationship of the 819 present document to the Directive). It provides basic authentication 820 and integrity protection. 822 The semantics of the signed data of a CAdES-BES or its context may 823 implicitly indicate a signature policy to the verifier. Specification 824 of the contents of signature policies is outside the scope of the 825 present document. However, further information on signature policies 826 is provided in TR 102 038 [TR102038], RFC 3125 [RFC3125] and sections 827 5.8.1, C.1 and C.3.1 of the present document. 829 4.3.2 CAdES Explicit Policy Electronic Signatures (CAdES-EPES) 831 A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES) in 832 accordance with the present document, extends the definition of an 833 electronic signature to conform to the identified signature policy. 835 A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES) 836 incorporates a signed attribute (signature-policy-identifier) 837 indicating that a signature policy that is mandatory to use to validate 838 the signature and specifies explicitly the signature policy that shall 839 be used. This signed attribute is protected by the signature. The 840 signature may also have other signed attributes required to conform to 841 the mandated signature policy. 843 Section 5.7.3 provides the details on the specification of signature- 844 policy-identifier attribute. Section C.1 provides a short rationale. 845 Specification of the contents of signature policies is outside the 846 scope of the present document. 848 Further information on signature policies is provided in TR 102 038 849 [TR102038] and sections 5.8.1, C.1 and C.3.1 of the present document. 851 The structure of the CAdES-EPES is illustrated in figure 2. 853 +------------- Elect.Signature (CAdES-EPES) ---------------+ 854 | | 855 |+-------------------------------------------------------+ | 856 || +-----------+ | | 857 || | | +---------------------------+ | | 858 || | | | +----------+ | | | 859 || | Signer's | | |Signature | Signed | Digital | | 860 || | Document | | |Policy ID | Attributes |Signature| | 861 || | | | +----------+ | | | 862 || | | +---------------------------+ | | 863 || +-----------+ | | 864 |+-------------------------------------------------------+ | 865 | | 866 +----------------------------------------------------------+ 868 Figure 2: Illustration of a CAdES-EPES 870 The signer's conformance requirements of CAdES-EPES are defined in 871 section 8.2. 873 4.4 Electronic signature formats with validation data 875 Validation of an electronic signature in accordance with the present 876 document requires additional data needed to validate the electronic 877 signature. This additional data is called validation data; and 878 includes: 880 - Public Key Certificates (PKCs); 882 - revocation status information for each PKC; 884 - trusted time-stamps applied to the digital signature or a time- 885 mark shall be available in an audit log; and 887 - when appropriate, the details of a signature policy to be used to 888 verify the electronic signature. 890 The validation data may be collected by the signer and/or the verifier. 891 When the signature-policy-identifier signed attribute is present, it 892 shall meet the requirements of the signature policy. 894 Validation data includes CA certificates as well as revocation status 895 information in the form of Certificate Revocation Lists (CRLs) or 896 certificate status information (OCSP) provided by an on-line service. 897 Validation data also includes evidence that the signature was created 898 before a particular point in time this may be either a time-stamp 899 token or time-mark. 901 The present document defines unsigned attributes able to contain 902 validation data that can be added to CAdES-BES and CAdES-EPES leading 903 to electronic signature formats that include validation data. Sections 904 below summarize these formats and their most relevant characteristics. 906 4.4.1 Electronic Signature with Time (CAdES-T) 908 Electronic Signature with Time (CAdES-T) in accordance with the present 909 document is when there exits trusted time associated with the ES. 911 The trusted time may be provided by: 913 - the signature-time-stamp as an unsigned attribute added to the 914 ES; and 916 - A time mark of the ES provided by a trusted service provider. 918 The signature-time-stamp attribute contains a time-stamp token of the 919 electronic signature value. Section 6.1.1 provides the specification 920 details. Section C.4.3 in provides the rationale. 922 A time-mark provided by a Trusted Service would have similar effect to 923 the signature-time-stamp attribute but in this case no attribute is 924 added to the ES as it is the responsibility of the TSP to provide 925 evidence of a time mark when required to do so. The management of time 926 marks is outside the scope of the present document. 928 Trusted time provides the initial steps towards providing long term 929 validity. Electronic signatures with the time stamp attribute forming 930 the CAdES-T is illustrated in figure 3. 932 +-------------------------------------------------CAdES-T ---------+ 933 |+------ CAdES-BES or CAdES-EPES -------+ | 934 ||+-----------------------------------+ | +----------------------+ | 935 |||+---------+ +----------+ | | | | | 936 ||||Signer's | | Signed | Digital | | | Signature-time-stamp | | 937 ||||Document | |Attributes| Signature | | | attribute required | | 938 |||| | | | | | | when using time | | 939 |||+---------+ +----------+ | | | stamps. | | 940 ||+-----------------------------------+ | | | | 941 |+--------------------------------------+ | or the BES/EPES | | 942 | | shall be time marked | | 943 | | | | 944 | | Management and | | 945 | | provision of time | | 946 | | mark is the | | 947 | | responsibility of | | 948 | | the TSP. | | 949 | +----------------------+ | 950 +------------------------------------------------------------------+ 952 Figure 3: Illustration of CAdES-T formats 954 NOTE 1 : A time stamp token is added to the CAdES-BES or CAdES-EPES 955 as an unsigned attribute. 957 NOTE 2 : Timestamp tokens that may themselves include unsigned 958 attributes required to validate the timestamp token, such 959 as the complete-certificate-references and complete- 960 revocation-references attributes as defined by the present 961 document. 963 4.4.2 ES with Complete validation data references (CAdES-C) 965 Electronic Signature with Complete validation data references (CAdES-C) 966 in accordance with the present document adds to the CAdES-T the 967 complete-certificate-references and complete-revocation-references 968 attributes as defined by the present document. The complete- 969 certificate-references attribute contain references to all the 970 certificates present in the certification path used for verifying the 971 signature. The complete-revocation-references attribute contains 972 references to the CRLs and/or OCSP responses used for verifying the 973 signature. Section 6.2 provides the specification details. Storing the 974 references allows the values of the certification path and the CRLs or 975 OCSPs responses to be stored elsewhere, reducing the size of a stored 976 electronic signature format. 978 Sections C.4.1 to C.4.2 provide rationale on the usage of validation 979 data and when it is suitable to generate the CAdES-C form. 980 Electronic signatures with the additional validation data forming the 981 CAdES-C are illustrated in figure 4. 983 +------------------------- CAdES-C --------------------------------+ 984 |+----------------------------- CAdES-T ---------+ | 985 || +----------+ | +-------------+ | 986 || |Timestamp | | | | | 987 || |attribute | | | | | 988 ||+- CAdES-BES or CAdES-EPES ------+|over | | | | | 989 ||| ||digital | | | Complete | | 990 |||+---------++----------+ ||signature | | | certificate | | 991 ||||Signer's || Signed | Digital ||is | | | and | | 992 ||||Document ||Attributes|Signature||mandatory | | | revocation | | 993 |||| || | ||if is not | | | references | | 994 |||+---------++----------+ ||timemarked| | | | | 995 ||+--------------------------------++----------+ | | | | 996 |+-----------------------------------------------+ +-------------+ | 997 +------------------------------------------------------------------+ 999 Figure 4: Illustration of CAdES-C format 1001 NOTE 1: The complete certificate and revocation references are added 1002 to the CAdES-T as an unsigned attribute. 1004 NOTE 2: As a minimum, the signer will provide the CAdES-BES or when 1005 indicating that the signature conforms to an explicit signing 1006 policy the CAdES-EPES. 1007 NOTE 3: To reduce the risk of repudiating signature creation, the 1008 trusted time indication needs to be as close as possible to 1009 the time the signature was created. The signer or a TSP could 1010 provide the CAdES-T, if not the verifier should create the 1011 CAdES-T on first receipt of an electronic signature because 1012 the CAdES-T provides independent evidence of the existence of 1013 the signature prior to the trusted time indication. 1015 NOTE 4: An CAdES-T trusted time indications must be created before a 1016 certificate has been revoked or expired. 1018 NOTE 5: The signer and TSP could provide the CAdES-C, to minimize 1019 this risk and when the signer does not provide the CAdES-C, 1021 the verifier should create the CAdES-C when the required 1022 component of revocation and validation data become available, 1023 this may require a grace period. 1025 NOTE 6: A grace period permits certificate revocation information to 1026 propagate through the revocation processes. This period could 1027 extend from the time an authorized entity requests certificate 1028 revocation, to when the information is available for the 1029 relying party to use. In order to make sure that the 1030 certificate was not revoked at the time the signature was 1031 time-marked or time-stamped, verifiers should wait until the 1032 end of the grace period. A signature policy may define 1033 specific values for grace periods. 1035 An illustration of a grace period is provided in figure 5. 1037 +<--------------Grace Period --------->+ 1038 ----+-------+-------+--------+---------------------+----------+ 1039 ^ ^ ^ ^ ^ ^ 1040 | | | | | | 1041 | | | | | | 1042 Signature | First | Second | 1043 creation | revocation | revocation | 1044 time | status | status | 1045 | checking | checking | 1046 | | | 1047 Time-stamp Certification Build 1048 or path CAdES-C 1049 time-mark construction 1050 over & verification 1051 signature 1053 Figure 5: Illustration of a grace period 1055 NOTE 7: CWA 14171 [CWA 14171] specifies a signature validation 1056 process using CAdES-T, CAdES-C and a grace period. 1057 Annex B provides example validation processes. Section C.4 1058 provides additional information about applying grace periods 1059 during the validation process. 1061 The verifier's conformance requirements are defined in section 8.3 for 1062 time stamped CAdES-C and section 8.4 for time marked CAdES-C. The 1063 present document only defines conformance requirements for the verifier 1064 up to an ES with complete validation data (CAdES-C). This means that 1065 none of the extended and archive forms of Electronic Signature as 1066 defined in sections 4.4.3 to 4.4.4) need to be implemented to achieve 1067 conformance to the present document. 1069 4.4.3 Extended electronic signature formats 1071 CAdES-C can be extended by adding unsigned attributes to the electronic 1072 signature. The present document defines various unsigned attributes 1073 that are applicable for very long term verification, and for preventing 1074 some disaster situations which are discussed in annex C. Annex B 1075 provides the details of the various extended formats, all the required 1076 unsigned attributes for each type and how they can be used within the 1077 electronic signature validation process. The sections below give an 1078 overview of the various forms of extended signature formats in the 1079 present document. 1081 4.4.3.1 EXtended Long Electronic Signature (CAdES-X Long) 1083 Extended Long format (CAdES-X Long) in accordance with the present 1084 document adds to the CAdES-C format the certificate-values and 1085 revocation-values attributes. The first one contains the whole 1086 certificate path required for verifying the signature; the second one 1087 the CRLs and/OCSP responses required for the validation of the 1088 signature. This provides a known repository of certificate and 1089 revocation information required to validate an CAdES-C and prevents 1090 such information getting lost. Sections 6.3.3 and 6.3.4 give 1091 specification details. Section B.1.1 gives details on the production 1092 of the format. Sections C4.1 to C.4.2 provide the rationale. 1094 The structure of the CAdES-X Long format is illustrated in figure 6. 1096 +----------------------- CAdES-X-Long -----------------------------+ 1097 |+------------------------------------ CadES-C --+ | 1098 || +----------+ | +-------------+ | 1099 ||+------ CAdES -------------------+|Timestamp | | | | | 1100 ||| || over | | | Complete | | 1101 |||+---------++----------+ ||digital | | | certificate | | 1102 ||||Signer's || Signed | Digital ||signature | | | and | | 1103 ||||Document ||Attributes|Signature|| | | | revocation | | 1104 |||| || | ||Optional | | | data | | 1105 |||+---------++----------+ ||when | | | | | 1106 ||+--------------------------------+|timemarked| | | | | 1107 || +----------+ | | | | 1108 || +-------------+ | +-------------+ | 1109 || | Complete | | | 1110 || | certificate | | | 1111 || | and | | | 1112 || | revocation | | | 1113 || | references | | | 1114 || +-------------+ | | 1115 |+-----------------------------------------------+ | 1116 | | 1117 +------------------------------------------------------------------+ 1119 Figure 6: Illustration of CAdES-X-Long 1121 4.4.3.2 EXtended Electronic Signature with Time Type 1 1122 (CAdES-X Type 1) 1124 Extended format with time type 1 (CAdES-X Type 1) in accordance with 1125 the present document adds to the CAdES-C format the CAdES-C-time-stamp 1126 attribute, whose content is a time-stamp token on the CAdES-C itself. 1128 This provides an integrity and trusted time protection over all the 1129 elements and references. It may protect the certificates, CRLs and 1130 OCSP responses in case of a later compromise of a CA key, CRL key or 1131 OCSP issuer key. Section 6.3.5 provides the specification details. 1133 Section B.1.2 gives details on the production of the time-stamping 1134 process. Sections C.4.4.1 provides the rationale. 1136 The structure of the CAdES-X Type 1 format is illustrated in figure 7. 1138 +----------------------- CAdES-X-Type 1 ------------------------------+ 1139 |+-------------------------------------- CAdES-C -----+ | 1140 || +-------------+ | +-----------+ | 1141 ||+--------- CAdES ------------------+| Timestamp | | | | | 1142 ||| || over | | | | | 1143 |||+---------++----------+ || digital | | | | | 1144 ||||Signer's || Signed | Digital || signature | | | Timestamp | | 1145 ||||Document ||Attributes| Signature || | | | over | | 1146 |||| || | || Optional | | | CAdES-C | | 1147 |||+---------++----------+ || when | | | | | 1148 ||+----------------------------------+| time-marked | | | | | 1149 || +-------------+ | | | | 1150 || +-------------+ | +-----------+ | 1151 || | Complete | | | 1152 || | certificate | | | 1153 || | and | | | 1154 || | revocation | | | 1155 || | references | | | 1156 || +-------------+ | | 1157 |+----------------------------------------------------+ | 1158 +---------------------------------------------------------------------+ 1160 Figure 7: Illustration of CAdES-X Type 1 1162 4.4.3.3 EXtended Electronic Signature with Time Type 2 1163 (CAdES-X Type 2) 1165 Extended format with time type 2 (CAdES-X Type 2) in accordance with 1166 the present document adds to the CAdES-C format the CAdES-C-time- 1167 stamped-certs-crls-references attribute, whose content is a time-stamp 1168 token on the certification path and revocation information references. 1169 This provides an integrity and trusted time protection over all the 1170 references. 1172 It may protect the certificates, CRLs and OCSP responses in case of a 1173 later compromise of a CA key, CRL key or OCSP issuer key. 1175 Both CAdES-X Type 1 and CAdES-X Type 2 counter the same threats and the 1176 usage of one or the other depends on the environment. Section 6.3.5 1177 provides the specification details. Section B.1.3 gives details on the 1178 production of the time-stamping process. Section C.4.4.2 provides the 1179 rationale. 1181 The structure of the CAdES-X Type 2 format is illustrated in figure 8. 1183 +------------------------- CAdES-X-Type 2 ----------------------------+ 1184 |+----------------------------------------CAdES-C ---+ | 1185 || +------------+| | 1186 ||+----- CAdES -----------------------+| Timmestamp || | 1187 ||| || over || | 1188 |||+---------+ +----------+ || digital || +-------------+| 1189 ||||Signer's | | Signed | Digital || signature || | Time-stamp || 1190 ||||Document | |Attributes| signature || || | only over || 1191 |||| | | | || optional || | complete || 1192 |||+---------+ +----------+ || when || | certificate || 1193 ||+-----------------------------------+| timemarked || | and || 1194 || +------------+| | revocation || 1195 || +-------------+ | | references || 1196 || | Complete | | +-------------+| 1197 || | certificate | | | 1198 || | and | | | 1199 || | revocation | | | 1200 || | references | | | 1201 || +-------------+ | | 1202 |+---------------------------------------------------+ | 1203 +---------------------------------------------------------------------+ 1205 Figure 8: Illustration of CAdES-X Type 2 1207 4.4.3.4 EXtended Long Electronic Signature with Time (CAdES-X Long Type 1208 1 or 2) 1210 Extended Long with Time (CAdES-X Long Type 1 or 2) in accordance with 1211 the present document is a combination of CAdES-X Long and one of the 1212 two former types (CAdES-X Type 1 and CAdES-X Type 2). Section B.1.4 1213 gives details on the production of the time-stamping process. Section 1214 C4.8 in annex C provides the rationale. 1216 The structure of the CAdES-X Long Type 1 and CAdES-X Long Type 2. 1217 format is illustrated in figure 9. 1219 +------------------ CAdES-X Long Type 1 or 2 -----------------------+ 1220 | +--------------+| 1221 |+-------------------------------------- CAdES-C --+|+------------+|| 1222 || ||| Timestamp ||| 1223 ||+------- CAdES --------------------++----------+ ||| over ||| 1224 ||| ||Timestamp | ||| CAdES-C ||| 1225 ||| ||over | ||+------------+|| 1226 |||+---------++----------+ ||digital | || OR || 1227 ||||Signer's || Signed | Digital ||signature | ||+------------+|| 1228 ||||Document ||Attributes| signature || | ||| Timestamp ||| 1229 |||| || | ||Optional | ||| only over ||| 1230 |||+---------++----------+ ||when | ||| complete ||| 1231 ||+----------------------------------+|timemarked| ||| certificate||| 1232 || +----------+ ||| and ||| 1233 || ||| Revocation ||| 1234 || +-------------+ ||| References ||| 1235 || | Complete | ||+------------+|| 1236 || | certificate | |+--------------+| 1237 || | and | | +------------+ | 1238 || | revocation | | | Complete | | 1239 || | references | | |certificate | | 1240 || +-------------+ | | and | | 1241 |+-------------------------------------------------+ |revocation | | 1242 | | value | | 1243 | +------------+ | 1244 +-------------------------------------------------------------------+ 1246 Figure 9: Illustration of CAdES-X Long Type 1 and CAdES Long Type 2 1248 4.4.4 Archival Electronic Signature (CAdES-A) 1250 Archival Form (CAdES-A) in accordance with the present document builds 1251 on a CAdES-X Long or a CAdES-X Long Type 1 or 2 by adding one or more 1252 archive-time-stamp attributes. This form is used for archival of long- 1253 term signatures. Successive time-stamps protect the whole material 1254 against vulnerable hashing algorithms or the breaking of the 1255 cryptographic material or algorithms. Section 6.4 contains the 1256 specification details. Sections C.4.5 and C.4.8 provide the rationale. 1258 The structure of the CAdES-A form is illustrated in figure 10. 1260 +---------------------------CAdES-A ---------------------------------+ 1261 |+----------------------------------------------------+ | 1262 || +--------------+| +----------+ | 1263 ||+----------------------CAdES-C ----+|+------------+|| | | | 1264 ||| +----------+ ||| Timestamp ||| | | | 1265 |||+---- CAdES-BES ----+|Timestamp | ||| over ||| | | | 1266 |||| or CAdeS-EPES || over | ||| CAdES-C ||| | Archive | | 1267 |||| ||digital | ||+------------+|| | | | 1268 |||| ||signature | || or || |Timestamp | | 1269 |||| || | ||+------------+|| | | | 1270 |||| ||Optional | ||| Timestamp ||| | | | 1271 |||| ||when | ||| only over ||| | | | 1272 |||| ||Timemarked| ||| complete ||| | | | 1273 |||+-------------------+| | ||| certificate||| +----------+ | 1274 ||| +----------+ ||| and ||| | 1275 ||| +-------------+ ||| revocation ||| | 1276 ||| | Complete | ||| references ||| | 1277 ||| | certificate | ||+------------+|| | 1278 ||| | and | |+--------------+| | 1279 ||| | revocation | | +------------+ | | 1280 ||| | references | | | Complete | | | 1281 ||| +-------------+ | |certificate | | | 1282 ||| | | and | | | 1283 ||+----------------------------------+ |revocation | | | 1284 || | values | | | 1285 || +------------+ | | 1286 |+----------------------------------------------------+ | 1287 +--------------------------------------------------------------------+ 1289 Figure 10: Illustration of CAdES-A 1291 4.5 Arbitration 1293 The CAdES-C may be used for arbitration should there be a dispute 1294 between the signer and verifier, provided that: 1296 - the arbitrator knows where to retrieve the signer's certificate 1297 (if not already present), all the cross-certificates and the 1298 required CRLs, ACRLs or OCSP responses referenced in the CAdES-C; 1300 - when time-stamping in the CAdES-T is being used, the certificate 1301 from the TSU that has issued the time-stamp token in the CAdES-T 1302 format is still within its validity period; 1304 - when time-stamping in the CAdES-T is being used, the certificate 1305 from the TSU that has issued the time-stamp token in the CAdES-T 1306 format is not revoked at the time of arbitration; 1308 - when time-marking in the CAdES-T is being used, a reliable audit 1309 trail from the Time-Marking Authority is available for 1310 examination regarding the time; 1312 - none of the private keys corresponding to the certificates used 1313 to verify the signature chain have ever been compromised; 1315 - the cryptography used at the time the CAdES-C was built has not 1316 been broken at the time the arbitration is performed; and 1318 - If the signature policy can be explicit or implicitly identified 1319 then an arbitrator is able to determine the rules required to 1320 validate the electronic signature. 1322 4.6 Validation process 1324 The Validation Process validates an electronic signature, the output 1325 status of the validation process can be: 1327 - invalid; 1329 - incomplete validation; or 1331 - valid. 1333 An Invalid response indicates that either the signature format is 1334 incorrect or that the digital signature value fails verification (e.g. 1335 the integrity check on the digital signature value fails or any of the 1336 certificates on which the digital signature verification depends is 1337 known to be invalid or revoked). 1339 An Incomplete Validation response indicates that the signature 1340 validation status is currently unknown. In the case of incomplete 1341 validation, additional information may be made available to the 1342 application or user, thus allowing them to decide what to do with the 1343 electronic signature. In the case of incomplete validation, the 1344 electronic signature may be checked again at some later time when 1345 additional information becomes available. 1347 NOTE: For example; an incomplete validation may be because all the 1348 required certificates are not available or the grace period is 1349 not completed. 1351 A Valid response indicates that the signature has passed verification 1352 and it complies with the signature validation policy. 1354 Example validation sequences are illustrated in annex B. 1356 5 Electronic signature attributes 1358 This section builds upon the existing Cryptographic Message Syntax 1359 (CMS), as defined in RFC 3852 [4], and Enhanced Security Services 1360 (ESS), as defined in RFC 2634 [5]. The overall structure of Electronic 1361 Signature is as defined in CMS. The Electronic Signature (ES) uses 1362 attributes defined in CMS, ESS and the present document. The present 1363 document defines ES attributes which it uses and are not defined 1364 elsewhere. 1366 The mandated set of attributes and the digital signature value is 1367 defined as the minimum Electronic Signature (ES) required by the 1368 present document. A signature policy may mandate that other signed 1369 attributes are present. 1371 5.1 General syntax 1373 The general syntax of the ES is as defined in CMS (RFC 3852 [4]). 1375 NOTE: CMS defines content types for id-data, id-signedData, id- 1376 envelopedData, id-digestedData, id-encryptedData, and id- 1377 authenticatedData. Although CMS permits other documents to 1378 define other content types, the ASN.1 type defined should not 1379 be a CHOICE type. The present document does not define other 1380 content types. 1382 5.2 Data content type 1384 The data content type of the ES is as defined in CMS (RFC 3852 [4]). 1386 NOTE: If the content type is id-data, it is recommended that the 1387 content is encoded using MIME and that the MIME type is used 1388 to identify the presentation format of the data. See annex F.1 1389 for an example of using MIME to identify encoding type. 1391 5.3 Signed-data content type 1393 The signed-data content type of the ES is as defined in CMS (RFC 3852 1394 [4]). 1396 5.4 SignedData type 1398 The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 1399 [4]). 1401 The fields of type SignedData have the meanings as defined in CMS 1402 (RFC 3852 [4]). 1404 The identification of signer's certificate used to create the signature 1405 is always signed (see section 5.7.3). The validation policy may specify 1406 requirements for the presence of certain certificates. The degenerate case 1407 where there are no signers is not valid in the present document. 1409 5.5 EncapsulatedContentInfo type 1411 The syntax of the EncapsulatedContentInfo type ES is as defined in CMS 1412 (RFC 3852 [4]). 1414 For the purpose of long term validation as defined by the present 1415 document, it is advisable that either the eContent is present, or the 1416 data which is signed is archived in such as way as to preserve any data 1417 encoding. It is important that the OCTET STRING used to generate the 1418 signature remains the same every time either the verifier or an 1419 arbitrator validates the signature. 1421 NOTE: The eContent is optional in CMS : 1423 - When it is present, this allows the signed data to be 1424 encapsulated in the SignedData structure, which then 1425 contains both the signed data and the signature. However, 1426 the signed data may only be accessed by a verifier able to 1427 decode the ASN.1 encoded SignedData structure. 1429 - When it is missing, this allows the signed data to be sent 1430 or stored separately from the signature and the SignedData 1431 structure only contains the signature. It is in the case 1432 of signature only that the data which is signed needs to be 1433 stored and distributed in such as way as to preserve any 1434 data encoding. 1436 The degenerate case where there are no signers is not valid in the 1437 present document. 1439 5.6 SignerInfo type 1441 The syntax of the SignerInfo type ES is as defined in CMS (RFC 3852 1442 [4]). 1444 Per-signer information is represented in the type SignerInfo. In the 1445 case of multiple independent signatures (see section B.5), there is an 1446 instance of this field for each signer. 1448 The fields of type SignerInfo have the meanings defined in CMS (RFC 1449 3852 [4]) but the signedAttrs field shall contain the following 1450 attributes: 1452 - content-type as defined in section 5.7.1; and 1453 - message-digest as defined in section 5.7.2; 1455 - signing-certificate as defined in section 5.7.3. 1457 5.6.1 Message digest calculation process 1459 The message digest calculation process is as defined in CMS (RFC 3852 1460 [4]). 1462 5.6.2 Message signature generation process 1464 The input to the message signature generation process is as defined in 1465 CMS (RFC 3852 [4]). 1467 5.6.3 Message signature verification process 1469 The procedures for message signature verification are defined in CMS 1470 (RFC 3852 [4]) and enhanced in the present document: the input to the 1471 signature verification process MUST be the signer's public key which 1472 SHALL be verified as correct using the signing certificate reference 1473 attribute containing a reference to the signing certificate, e.g. when 1474 SigningCertificate from ESS [RFC 2634] is used, the public key from 1475 the first certificate identified in the sequence of certificate 1476 identifiers from SigningCertificate MUST be the key used to verify the 1477 digital signature. 1479 5.7 Basic ES mandatory present attributes 1481 The following attributes shall be present with the signed-data defined 1482 by the present document. The attributes are defined in CMS (RFC 3852 1483 [4]). 1485 5.7.1 Content type 1487 The content-type attribute indicates the type of the signed content. 1488 The syntax of the content-type attribute type is as defined in CMS 1489 (RFC 3852 [4]) section 11.1. 1491 Note 1 : As stated in RFC 3852 [4] , the content-type attribute 1492 must have its value (i.e. ContentType) equal to the 1493 eContentType of the EncapsulatedContentInfo value being 1494 signed. 1496 Note 2 : For implementations supporting signature generation, if 1497 the content-type attribute is id-data, then it is 1498 recommended that the eContent be encoded using MIME. 1499 For implementations supporting signature verification, if 1500 the signed data (i.e. eContent) is MIME-encoded, then the 1501 OID of the content-type attribute must be id-data. 1502 In both cases, the MIME content-type(s) must be used to 1503 identify the presentation format of the data. See Annex F 1504 for further details about the use of MIME. 1506 5.7.2 Message digest 1508 The syntax of the message-digest attribute type of the ES is as defined 1509 in CMS (RFC 3852 [4]). 1511 5.7.3 Signing certificate reference attributes 1513 The Signing certificate reference attributes are supported by using 1514 either the ESS signing-certificate attribute or the ESS-signing- 1515 certificate-v2 attribute. 1517 These attributes shall contain a reference to the signer's certificate, 1518 they are designed to prevent the simple substitution and re-issue 1519 attacks and to allow for a restricted set of certificates to be used in 1520 verifying a signature. They have a compact form (much shorter than the 1521 full certificate) that allows to a certificate to be unambiguously 1522 identified. 1524 One, and only one, of the following alternative attributes shall be 1525 present with the signedData defined by the present document. 1527 - The ESS signing-certificate attribute, defined in ESS [RFC 2634], 1528 MUST be used if the SHA-1 hashing algorithm is used. 1530 - The ESS signing-certificate attribute v2, defined in �ESS Update: 1531 Adding CertID Algorithm Agility�, RFC 5035 [15] which SHALL be 1532 used when other hashing algorithms are to be used. 1534 The certificate to be used to verify the signature shall be identified 1535 in the sequence (i.e. the certificate from the signer) and the sequence 1536 shall not be empty. The signature validation policy may mandate other 1537 certificates be present that may include all the certificates up to the 1538 trust anchor. 1540 5.7.3.1 ESS signing certificate attribute definition 1542 The syntax of the signing-certificate attribute type of the ES is as 1543 defined in Enhanced Security Services (ESS), RFC 2634 [5] and further 1544 qualified in the present document. 1546 The sequence of policy information field is not used in the present 1547 document. 1549 The ESS signing-certificate attribute shall be a signed attribute. 1550 The encoding of the ESSCertID for this certificate shall include the 1551 issuerSerial field. 1553 If present, the issuerAndSerialNumber in SignerIdentifier field of the 1554 SignerInfo shall match the issuerSerial field present in ESSCertID. 1555 In addition the certHash from ESSCertID shall match the SHA-1 hash of 1556 the certificate. The certificate identified shall be used during the 1557 signature verification process. If the hash of the certificate does 1558 not match the certificate used to verify the signature, the signature 1559 shall be considered invalid. 1561 NOTE: Where an attribute certificate is used by the signer to 1562 associate a role, or other attributes of the signer, with the 1563 electronic signature, this is placed in the signer-attributes 1564 attribute as defined in section 5.8.3. 1566 5.7.3.2 ESS signing certificate v2 attribute definition 1568 The ESS signing-certificate v2 attribute is similar to the ESS 1569 signing-certificate defined above, except that this attribute can be 1570 used with hashing algorithms other than SHA-1. 1572 The syntax of the signing-certificate v2 attribute type of the ES is as 1573 defined in �ESS Update: Adding CertID Algorithm Agility�, RFC 5035 [15] 1574 and further qualified in the present document. 1576 The sequence of policy information field is not used in the present 1577 document. 1579 This attribute shall be used in the same manner as defined above for 1580 the ESS signing-certificate attribute. 1582 The object identifier for this attribute is: 1583 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= 1584 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1585 smime(16) id-aa(2) 47 } 1587 If present, the issuerAndSerialNumber in SignerIdentifier field of the 1588 SignerInfo shall match the issuerSerial field present in ESSCertID. 1589 In addition the certHash from ESSCertID shall match the SHA-1 hash of 1590 the certificate. The certificate identified shall be used during the 1591 signature verification process. If the hash of the certificate does 1592 not match the certificate used to verify the signature, the signature 1593 shall be considered invalid. 1595 Note 1 : Where an attribute certificate is used by the signer to 1596 associate a role, or other attributes of the signer, with the 1597 electronic signature, this is placed in the signer-attributes 1598 attribute as defined in section 5.8.3. 1600 Note 2 : RFC 3126 was using the other signing certificate attribute 1601 (see section 5.7.3.3) for the same purpose. Its use is now 1602 deprecated, since this structure is simpler. 1604 5.7.3.3 Other signing certificate attribute definition 1606 RFC 3126 was using the other signing certificate attribute as 1607 an alternative to the ESS signing-certificate when hashing algorithms 1608 other than SHA-1 were being used. Its use is now deprecated, since 1609 the structure of the general-signing-certificate-v2 attribute is 1610 simpler. Its description is however still present in this version for 1611 backwards compatibility. 1613 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 1614 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1615 smime(16) id-aa(2) 19 } 1617 The other-signing-certificate attribute value has the ASN.1 syntax 1618 OtherSigningCertificate: 1620 OtherSigningCertificate ::= SEQUENCE { 1621 certs SEQUENCE OF OtherCertID, 1622 policies SEQUENCE OF PolicyInformation OPTIONAL 1623 -- NOT USED IN THE PRESENT DOCUMENT } 1625 OtherCertID ::= SEQUENCE { 1626 otherCertHash OtherHash, 1627 issuerSerial IssuerSerial OPTIONAL } 1629 OtherHash ::= CHOICE { 1630 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 1631 otherHash OtherHashAlgAndValue} 1633 OtherHashValue ::= OCTET STRING 1635 OtherHashAlgAndValue ::= SEQUENCE { 1636 hashAlgorithm AlgorithmIdentifier, 1637 hashValue OtherHashValue } 1639 5.8 Additional mandatory attributes for Explicit Policy-based 1640 Electronic Signatures 1642 5.8.1 Signature policy identifier 1644 The present document mandates that for CAdES-EPES a reference to the 1645 signature policy is included in the signedData. This reference is 1646 explicitly identified. A signature policy defines the rules for 1647 creation and validation of an electronic signature, is included as a 1648 signed attribute with every Explicit Policy-based Electronic Signature. 1649 The signature-policy-identifier shall be a signed attribute. 1651 The following object identifier identifies signature-policy-identifier 1652 attribute: 1654 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 1655 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1656 smime(16) id-aa(2) 15 } 1658 signature-policy-identifier attribute values have ASN.1 type 1659 SignaturePolicyIdentifier: 1661 SignaturePolicyIdentifier ::= CHOICE { 1662 signaturePolicyId SignaturePolicyId, 1663 signaturePolicyImplied SignaturePolicyImplied 1664 -- not used in this version 1665 } 1666 SignaturePolicyId ::= SEQUENCE { 1667 sigPolicyId SigPolicyId, 1668 sigPolicyHash SigPolicyHash, 1669 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 1670 SigPolicyQualifierInfo OPTIONAL} 1672 SignaturePolicyImplied ::= NULL 1674 The sigPolicyId field contains an object-identifier which uniquely 1675 identifies a specific version of the signature policy. The syntax of 1676 this field is as follows: 1678 SigPolicyId ::= OBJECT IDENTIFIER 1680 The sigPolicyHash field optionally contains the identifier of the hash 1681 algorithm and the hash of the value of the signature policy. The 1682 hashValue within the sigPolicyHash max be set to zero to indicate 1683 that the policy hash value is not known. 1685 NOTE: The use of zero policy hash value is to ensure backward 1686 compatibility with earlier versions of the current document. 1687 If hashValue is zero then the hash value should not be checked 1688 against the calculated hash value of signature policy. 1690 If the signature policy is defined using ASN.1, then the hash is 1691 calculated on the value without the outer type and length fields and 1692 the hashing algorithm shall be as specified in the field sigPolicyHash. 1694 If the signature policy is defined using another structure, the type of 1695 structure and the hashing algorithm shall be either specified as part 1696 of the signature policy, or indicated using a signature policy qualifier. 1698 SigPolicyHash ::= OtherHashAlgAndValue 1700 OtherHashAlgAndValue ::= SEQUENCE { 1701 hashAlgorithm AlgorithmIdentifier, 1702 hashValue OtherHashValue } 1704 OtherHashValue ::= OCTET STRING 1706 A signature policy identifier may be qualified with other information 1707 about the qualifier. The semantics and syntax of the qualifier is as 1708 associated with the object-identifier in the sigPolicyQualifierId 1709 field. The general syntax of this qualifier is as follows: 1711 SigPolicyQualifierInfo ::= SEQUENCE { 1712 sigPolicyQualifierId SigPolicyQualifierId, 1713 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 1715 The present document specifies the following qualifiers: 1717 - spuri: this contains the web URI or URL reference to the 1718 signature policy, and 1720 - sp-user-notice: this contains a user notice which should be 1721 displayed whenever the signature is validated. 1723 sigpolicyQualifierIds defined in the present document: 1724 SigPolicyQualifierId ::= OBJECT IDENTIFIER 1726 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 1727 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1728 smime(16) id-spq(5) 1 } 1730 SPuri ::= IA5String 1732 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 1733 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1734 smime(16) id-spq(5) 2 } 1736 SPUserNotice ::= SEQUENCE { 1737 noticeRef NoticeReference OPTIONAL, 1738 explicitText DisplayText OPTIONAL} 1740 NoticeReference ::= SEQUENCE { 1741 organization DisplayText, 1742 noticeNumbers SEQUENCE OF INTEGER } 1744 DisplayText ::= CHOICE { 1745 visibleString VisibleString (SIZE (1..200)), 1746 bmpString BMPString (SIZE (1..200)), 1747 utf8String UTF8String (SIZE (1..200)) } 1749 5.9 CMS imported optional attributes 1751 The following attributes may be present with the signed-data, the 1752 attributes are defined in CMS (RFC 3852 [4]) and are imported into the 1753 present document. Were appropriated the attributes are qualified and 1754 profiled by the present document. 1756 5.9.1 Signing time 1758 The signing-time attribute specifies the time at which the signer 1759 claims to have performed the signing process. 1761 Signing-time attribute values for ES have the ASN.1 type SigningTime 1762 as defined in CMS (RFC 3852 [4]). 1764 NOTE: RFC 3852 [4] states that dates between 1 January 1950 and 31 1765 December 2049 (inclusive) MUST be encoded as UTCTime. Any dates 1766 with year values before 1950 or after 2049 MUST be encoded as 1767 GeneralizedTime. 1769 5.9.2 Countersignature 1771 The counterSignature attribute values for ES have ASN.1 type 1772 CounterSignature as defined in CMS (RFC 3852 [4]). A counterSignature 1773 attribute shall be an unsigned attribute. 1775 5.10 ESS imported optional attributes 1777 The following attributes may be present with the signed-data defined by 1778 the present document. The attributes are defined in ESS and are 1779 imported into the present document and were appropriate qualified and 1780 profiled by the present document. 1782 5.10.1 Content reference attribute 1784 The content-reference attribute is a link from one SignedData to 1785 another. It may be used to link a reply to the original message to 1786 which it refers, or to incorporate by reference one SignedData into 1787 another. The content-reference attribute shall be a signed attribute. 1789 Content-reference attribute values for ES have ASN.1 type 1790 ContentReference as defined in ESS (RFC 2634 [5]). 1792 The content-reference attribute shall be used as defined in ESS (RFC 1793 2634 [5]). 1795 5.10.2 Content identifier attribute 1797 The content-identifier attribute provides an identifier for the signed 1798 content for use when reference may be later required to that content, 1799 for example in the content reference attribute in other signed data 1800 sent later. The content-identifier shall be a signed attribute. 1802 content-identifier attribute type values for of the ES have ASN.1 type 1803 ContentIdentifier as defined in ESS (RFC 2634 [5]). 1805 The minimal content-identifier attribute should contain a concatenation 1806 of user-specific identification information (such as a user name or 1807 public keying material identification information), a GeneralizedTime 1808 string, and a random number. 1810 5.10.3 Content hints attribute 1812 The content-hints attribute provides information on the innermost 1813 signed content of a multi-layer message where one content is 1814 encapsulated in another. 1816 The syntax of the content-hints attribute type of the ES as defined in 1817 ESS (RFC 2634 [5]). 1819 When used to indicate the precise format of the data to be presented to 1820 the user the following rules apply: 1822 - the contentType indicates the type of the associated content. It 1823 is an object identifier (i.e. a unique string of integers) 1824 assigned by an authority that defines the content type; and 1826 - when the contentType is id-data the contentDescription shall 1827 define the presentation format, the format may be defined by MIME 1828 types. 1830 When the format of the content is defined by MIME types the following 1831 rules apply: 1833 - the contentType shall be id-data as defined in CMS (RFC 3852 1834 [4]); 1836 - the contentDescription shall be used to indicate the encoding of 1837 the data in accordance with the rules defined RFC 2045 [6], see 1838 annex F for an example structured contents and MIME. 1840 NOTE 1: id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1841 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1843 NOTE 2: contentDescription is optional in ESS (RFC 2634 [5]). It may 1844 be used to complement contentTypes defined elsewhere , such 1845 definitions are outside the scope of the present document. 1847 5.11 Additional optional attributes defined in the present document 1849 This section defines a number of attributes that may be used to 1850 indicate additional information to a verifier : 1852 a) the type of commitment from the signer, and/or 1853 b) the claimed location where the signature is performed, and/or 1854 c) claimed attributes or certified attributes of the signer, and/or 1855 d) a content time-stamp applied before the content was signed. 1857 5.11.1 Commitment type indication attribute 1859 There may be situations where a signer wants to explicitly indicate to 1860 a verifier that by signing the data, it illustrates a type of 1861 commitment on behalf of the signer. The commitment-type-indication 1862 attribute conveys such information. 1864 The commitment-type-indication attribute shall be a signed attribute. 1865 The commitment type may be: 1867 - defined as part of the signature policy, in which case the 1868 commitment type has precise semantics that is defined as part of 1869 the signature policy; and 1871 - be a registered type, in which case the commitment type has 1872 precise semantics defined by registration, under the rules of the 1873 registration authority. Such a registration authority may be a 1874 trading association or a legislative authority. 1876 The signature policy specifies a set of attributes that it 1877 "recognizes". This "recognized" set includes all those commitment 1878 types defined as part of the signature policy as well as any externally 1879 defined commitment types that the policy may choose to recognize. Only 1880 recognized commitment types are allowed in this field. 1882 The following object identifier identifies the commitment-type- 1883 indication attribute: 1885 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1886 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 1888 commitment-type-indication attribute values have ASN.1 type 1889 CommitmentTypeIndication. 1891 CommitmentTypeIndication ::= SEQUENCE { 1892 commitmentTypeId CommitmentTypeIdentifier, 1893 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 1894 CommitmentTypeQualifier OPTIONAL} 1896 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 1898 CommitmentTypeQualifier ::= SEQUENCE { 1899 commitmentTypeIdentifier CommitmentTypeIdentifier, 1900 qualifier ANY DEFINED BY commitmentTypeIdentifier } 1902 The use of any qualifiers to the commitment type is outside the scope 1903 of the present document. 1905 The following generic commitment types are defined in the present 1906 document: 1908 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1909 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 1911 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1912 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 1914 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 1915 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1916 cti(6) 3} 1918 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1919 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 1921 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) 1922 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1923 cti(6) 5} 1924 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) 1925 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1926 cti(6) 6} 1928 These generic commitment types have the following meaning: 1930 Proof of origin indicates that the signer recognizes to have created, 1931 approved and sent the message. 1933 Proof of receipt indicates that signer recognizes to have received the 1934 content of the message. 1936 Proof of delivery indicates that the TSP providing that indication has 1937 delivered a message in a local store accessible to the recipient of the 1938 message. 1940 Proof of sender indicates that the entity providing that indication has 1941 sent the message (but not necessarily created it). 1943 Proof of approval indicates that the signer has approved the content of 1944 the message. 1946 Proof of creation indicates that the signer has created the message 1947 (but not necessarily approved, nor sent it). 1949 5.11.2 Signer location attribute 1951 The signer-location attribute specifies a mnemonic for an address 1952 associated with the signer at a particular geographical (e.g. city) 1953 location. The mnemonic is registered in the country in which the 1954 signer is located and is used in the provision of the Public Telegram 1955 Service (according to ITU-T Recommendation F.1 [11]). 1957 The signer-location attribute shall be a signed attribute. The 1958 following object identifier identifies the signer-location attribute: 1960 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1961 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 1963 Signer-location attribute values have ASN.1 type SignerLocation: 1964 SignerLocation ::= SEQUENCE { -- at least one of the following shall be 1965 present 1967 countryName [0] DirectoryString OPTIONAL, 1968 -- As used to name a Country in X.500 1969 localityName [1] DirectoryString OPTIONAL, 1970 -- As used to name a locality in X.500 1971 postalAdddress [2] PostalAddress OPTIONAL } 1973 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 1975 5.11.3 Signer attributes attribute 1977 The signer-attributes attribute specifies additional attributes of the 1978 signer (e.g. role). 1980 It may be either: 1982 - claimed attributes of the signer; or 1983 - certified attributes of the signer. 1985 The signer-attributes attribute shall be a signed attribute. 1986 The following object identifier identifies the signer-attribute 1987 attribute: 1989 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1990 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 1992 signer-attributes values have ASN.1 type SignerAttribute: 1993 SignerAttribute ::= SEQUENCE OF CHOICE { 1994 claimedAttributes [0] ClaimedAttributes, 1995 certifiedAttributes [1] CertifiedAttributes } 1997 ClaimedAttributes ::= SEQUENCE OF Attribute 1999 CertifiedAttributes ::= AttributeCertificate 2000 -- as defined in RFC 3281 : see section 4.1. 2002 NOTE 1: Only a single signer-attributes can be used 2004 NOTE 2: The claimedAttributes and certifiedAttributes fields are as 2005 defined in ITU-T Recommendations X.501 [9] and X.509 [1]. 2007 5.11.4 Content time-stamp 2009 The content-time-stamp attribute is an attribute which is the time- 2010 stamp token of the signed data content before it is signed. 2011 The content-time-stamp attribute shall be a signed attribute. 2013 The following object identifier identifies the content-time-stamp 2014 attribute: 2016 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= 2017 { iso(1) member- body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2018 smime(16) id-aa(2) 20} 2020 Content-time-stamp attribute values have ASN.1 type ContentTimestamp: 2021 ContentTimestamp ::= TimeStampToken 2023 The value of messageImprint of TimeStampToken (as described in RFC 3161 2024 [7]) shall be a hash of the value of eContent field within 2025 encapContentInfo in the signedData. 2027 For further information and definition of TimeStampToken see 2028 section 7.4. 2030 NOTE: Content-time-stamp indicates that the signed information was 2032 formed before the date included in the Content-time-stamp. 2034 5.12 Support for multiple signatures 2036 5.12.1 Independent signatures 2038 Multiple independent signatures (see section B.5) are supported by 2039 independent SignerInfo from each signer. 2041 Each SignerInfo shall include all the attributes required under the 2042 present document and shall be processed independently by the verifier. 2044 Note: Independent signatures may be used to provide independent 2045 signatures from different parties with different signed attributes, or 2046 to provide multiple signatures from the same party using alternative 2047 signature algorithms in which case the other attributes, excluding 2048 time values and signature policy information, will generally be the 2049 same. 2051 5.12.2 Embedded signatures 2053 Multiple embedded signatures (see section C.5) are supported using the 2054 countersignature unsigned attribute (see section 5.9.2). Each counter 2055 signature is carried in Countersignature held as an unsigned attribute 2056 to the SignerInfo to which the counter-signature is applied. 2058 Note: Counter signatures may be used to provide signatures from 2059 different parties with different signed attributes, or to provide 2060 multiple signatures from the same party using alternative signature 2061 algorithms in which case the other attributes, excluding time values 2062 and signature policy information, will generally be the same. 2064 6 Additional Electronic Signature validation attributes 2066 This section specifies attributes that contain different types of 2067 validation data. These attributes build on the electronic signature 2068 specified in section 5. This includes: 2070 - Signature-time-stamp applied to the electronic signature value or 2071 a Time-Mark in an audit trail. This is defined as the Electronic 2072 Signature with Time (CAdES-T); and 2074 - complete validation data references which comprises the time- 2075 stamp of the signature value (CAdES-T), plus references to all 2076 the certificates (complete-certificate-references) and revocation 2077 (complete-revocation-references) information used for full 2078 validation of the electronic signature. This is defined as the 2079 Electronic Signature with Complete data references (CAdES-C). 2081 NOTE 1: Formats for CAdES-T are illustrated in section 4.4 and the 2082 attribute are defined in section 6.1.1. 2084 NOTE 2: Formats for CAdES-C are illustrated in section 4.4. The 2085 required attributes for the CAdES-C signature format are 2086 defined in section 6.2.1 to 6.2.2, optional attributes are 2087 defined in sections 6.2.3 and 6.2.4. 2089 In addition the following optional eXtended forms of validation data 2090 are also defined, see annex B for an overview the eXtended forms of 2091 validation data: 2093 - CAdES-X with time stamp: there are two types of time-stamp used 2094 in extended validation data defined by the present document: 2096 - Type 1(CAdES-X Type 1): comprises a time-stamp over the ES 2097 with complete validation data (CAdES-C); and 2099 - Type 2 (CAdES-X Type2): comprises a time-stamp over the 2100 certification path references and the revocation information 2101 references used to support the CAdES-C. 2103 NOTE 3: Formats for CAdES-X Type 1 and CAdES-X Type 2 are illustrated 2104 in sections B.1.2 and B.1.3, respectively. 2106 - CAdES-X Long :comprises the complete validation data references 2107 (CAdES-C) plus the actual values of all the certificates and 2108 revocation information used in the CAdES-C. 2110 NOTE 4: Formats for CAdES-X Long are illustrated in section B.1.1. 2112 - CAdES-X Long Type 1 or CAdES-X Long Type 2: comprises an X-Time- 2113 Stamp (Type 1 or Type 2) plus the actual values of all the 2114 certificates and revocation information used in the CAdES-C as 2115 per CAdES-X Long. 2117 This section also specifies the data structures used in Archive 2118 validation data format (CAdES-A)of eXtended forms: 2120 - Archive form of electronic signature (CAdES-A) comprises the 2121 complete validation data references (CAdES-C), the certificate 2122 and revocation values (as in a CAdES-X Long ), if present any 2123 existing extended electronic signature timestamps (CAdES-X Type 1 2124 or CAdES-X Type 2), plus the signed user data and an additional 2125 archive time-stamp applied over all that data. An archive time- 2126 stamp may be repeatedly applied after long periods to maintain 2127 validity when electronic signature and time-stamping algorithms 2128 weaken. 2130 The additional data required to create the forms of electronic 2131 signature identified above is carried as unsigned attributes associated 2132 with an individual signature by being placed in the unsignedAttrs field 2133 of SignerInfo. Thus all the attributes defined in section 6 are 2134 unsigned attributes. 2136 NOTE 5: Where multiple signatures are to be supported, as described 2137 in section 5.12, each signature has a separate SignerInfo. 2138 Thus, each signature requires its own unsigned attribute 2139 values to create CAdES-T, CAdES-C, etc. 2141 NOTE 6: the optional attributes of the extended validation data are 2142 defined in sections 6.3 and 6.4. 2144 6.1 Electronic Signature Time-stamped (CAdES-T) 2146 An Electronic Signature with time-stamp is an electronic signature for 2147 which part, but not all, of the additional data required for validation 2148 is available (i.e. some certificates and revocation information are 2149 available but not all). 2151 The minimum structure time-stamp validation data is: 2153 - the Signature Time-stamp Attribute as defined in section 6.1.1 2154 over the ES signature value. 2156 6.1.1 Signature time- stamp attribute definition 2158 The signature-time-stamp attribute is a TimeStampToken computed on the 2159 signature value for a specific signer. It is an unsigned attribute. 2160 Several instances of this attribute may occur with an electronic 2161 signature, from different TSAs. 2163 The following object identifier identifies the signature-time-stamp 2164 attribute: 2166 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= 2167 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2168 smime(16) id-aa(2) 14} 2170 The signature-time-stamp attribute value has ASN.1 type 2171 SignatureTimeStampToken: 2173 SignatureTimeStampToken ::= TimeStampToken 2175 The value of messageImprint field within TimeStampToken shall be a 2176 hash of the value of the signature field within SignerInfo for the 2177 signedData being time-stamped. 2179 For further information and definition of TimeStampToken see 2180 section 7.4. 2182 NOTE 1: In the case of multiple signatures it is possible to have a 2184 TimeStampToken computed for each and all signers, or 2185 TimeStampToken computed on one signer's signature and no 2186 TimeStampToken on another signer's signature. 2188 NOTE 2: In the case of multiple signatures, several TSTs, issued by 2189 different TSAs, may be present within the same signerInfo 2190 (see RFC 3852 [4]). 2192 6.2 Complete validation reference data (CAdES-C) 2194 An electronic signature with complete validation data references 2195 (CAdES-C) is an Electronic Signature for which all the additional data 2196 required for validation (i.e. all certificates and revocation 2197 information) is available. This form is built on the CAdES-T form 2198 defined above. 2200 As a minimum, the complete validation data shall include the following: 2201 - a time, which shall either be a signature-timestamp attribute, as 2202 defined in section 6.1.1, or a time mark operated by a Time- 2203 Marking Authority; 2205 - complete-certificate-references, as defined in section 6.2.1; 2207 - complete-revocation-references , as defined in section 6.2.2. 2209 6.2.1 Complete certificate references attribute definition 2211 The complete-certificate-references attribute is an unsigned attribute. 2212 It references the full set of CA certificates that have been used to 2213 validate an ES with Complete validation data up to (but not including) 2214 the signer's certificate. Only a single instance of this attribute 2215 shall occur with an electronic signature. 2217 NOTE 1: The signer's certificate is referenced in the signing 2218 certificate attribute (see section 5.7.3). 2220 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2221 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 2223 The complete-certificate-references attribute value has the ASN.1 2224 syntax CompleteCertificateRefs. 2226 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 2228 OtherCertID is defined in section 5.7.3.2. 2230 The IssuerSerial that shall be present in OtherCertID. The certHash 2231 shall match the hash of the certificate referenced. 2233 NOTE 2: Copies of the certificate values may be held using the 2234 certificate-values attribute defined in section 6.3.3. 2236 This attribute may include references to the certification 2237 chain for any TSUs that provides time-stamp tokens. In this 2238 case the unsigned attribute shall be added to the signedData 2239 of the relevant times tamp token as an unsignedAttrs in the 2240 signerInfos field. 2242 6.2.2 Complete Revocation References attribute definition 2244 The complete-revocation-references attribute is an unsigned attribute. 2245 Only a single instance of this attribute shall occur with an electronic 2246 signature. It references the full set of the CRL, ACRL or OCSP 2247 responses that have been used in the validation of the signer and CA 2248 certificates used in ES with Complete validation data. 2250 This attribute can be used to illustrate that the verifier has taken 2251 due diligence of the available revocation information and then to be 2252 able to retrieve that information when stored elsewhere. 2254 The following object identifier identifies the complete-revocation- 2255 references attribute: 2257 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2258 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 2259 The complete-revocation-references attribute value has the ASN.1 syntax 2260 CompleteRevocationRefs: 2262 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 2264 CrlOcspRef ::= SEQUENCE { 2265 crlids [0] CRLListID OPTIONAL, 2266 ocspids [1] OcspListID OPTIONAL, 2267 otherRev [2] OtherRevRefs OPTIONAL 2268 } 2270 CompleteRevocationRefs shall contain one CrlOcspRef for the signing- 2271 certificate, followed by one for each OtherCertID in the 2272 CompleteCertificateRefs attribute. The second and subsequent 2273 CrlOcspRef fields shall be in the same order as the OtherCertID to 2274 which they relate. At least one of CRLListID or OcspListID or 2275 OtherRevRefs should be present for all but the "trusted" CA of the 2276 certificate path. 2278 CRLListID ::= SEQUENCE { 2279 crls SEQUENCE OF CrlValidatedID } 2281 CrlValidatedID ::= SEQUENCE { 2282 crlHash OtherHash, 2283 crlIdentifier CrlIdentifier OPTIONAL } 2285 CrlIdentifier ::= SEQUENCE { 2286 crlissuer Name, 2287 crlIssuedTime UTCTime, 2288 crlNumber INTEGER OPTIONAL } 2290 OcspListID ::= SEQUENCE { 2291 ocspResponses SEQUENCE OF OcspResponsesID } 2293 OcspResponsesID ::= SEQUENCE { 2294 ocspIdentifier OcspIdentifier, 2295 ocspRepHash OtherHash OPTIONAL 2296 } 2298 OcspIdentifier ::= SEQUENCE { 2299 ocspResponderID ResponderID, 2300 -- As in OCSP response data 2301 producedAt GeneralizedTime 2302 -- As in OCSP response data 2303 } 2305 When creating a crlValidatedID, the crlHash is computed over the entire 2306 DER encoded CRL including the signature. The crlIdentifier would 2307 normally be present unless the CRL can be inferred from other 2308 information. 2310 The crlIdentifier is to identify the CRL using the issuer name and the 2311 CRL issued time, which shall correspond to the time thisUpdate 2312 contained in the issued CRL, and if present, the crlNumber. The 2313 crlListID attribute is an unsigned attribute. In the case that the 2314 identified CRL is a Delta CRL then references to the set of CRLs to 2315 provide a complete revocation list shall be included. 2317 The OcspIdentifier is to identify the OCSP response using the issuer 2318 name and the time of issue of the OCSP response which shall correspond 2319 to the time producedAt contained in the issued OCSP response. Since it 2320 may be needed to make the difference between two OCSP responses 2321 received within the same second, then the hash of the response 2322 contained in the OcspResponsesID may be needed to solve the ambiguity. 2324 NOTE 1: Copies of the CRL and OCSP responses values may be held using 2325 the revocation-values attribute defined in section 6.3.4. 2327 NOTE 2: It is recommended that this attribute is used in preference to 2328 The OtherRevocationInfoFormat specified in RFC 3852 to 2329 Maintain backward compatibility with earlier version of this 2330 specification. 2332 The syntax and semantics of other revocation references is outside the 2333 scope of the present document. The definition of the syntax of the 2334 other form of revocation information is as identified by 2335 OtherRevRefType. 2337 This attribute may include the references to the full set of the CRL, 2338 ACRL or OCSP responses that have been used to verify the certification 2339 chain for any TSUs that provides time-stamp tokens. In this case the 2340 unsigned attribute shall be added to the signedData of the relevant 2341 timestamp token as an unsignedAttrs in the signerInfos field. 2343 6.2.3 Attribute certificate references attribute definition 2345 This attribute is only used when a user attribute certificate is 2346 present in the electronic signature. 2348 The attribute-certificate-references attribute is an unsigned 2349 attribute. It references the full set of AA certificates that have 2350 been used to validate the attribute certificate. Only a single 2351 instance of this attribute shall occur with an electronic signature. 2353 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= 2354 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2355 smime(16) id-aa(2) 44} 2357 The attribute-certificate-references attribute value has the ASN.1 2358 syntax AttributeCertificateRefs: 2360 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 2362 OtherCertID is defined in section 5.8.2. 2364 NOTE: Copies of the certificate values may be held using the 2365 certificate-values attribute defined in section 6.3.3. 2367 6.2.4 Attribute revocation references attribute definition 2369 This attribute is only used when a user attribute certificate is 2370 present in the electronic signature and when that attribute certificate 2371 can be revoked. 2373 The attribute-revocation-references attribute is an unsigned attribute. 2374 Only a single instance of this attribute shall occur with an 2375 electronic signature. It references the full set of the ACRL or OCSP 2376 responses that have been used in the validation of the attribute 2377 certificate. This attribute can be used to illustrate that the 2378 verifier has taken due diligence of the available revocation 2379 information. 2381 The following object identifier identifies the attribute-revocation- 2382 references attribute: 2384 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) 2385 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2386 id-aa(2) 45} 2388 The attribute-revocation-references attribute value has the ASN.1 2389 syntax AttributeRevocationRefs: 2391 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 2393 6.3 Extended validation data (CAdES-X) 2395 This section specifies a number of optional attributes that are used 2396 by extended forms of electronic signatures (see annex B for an 2397 overview these forms of validation data). 2399 6.3.1 Time-stamped validation data (CAdES-X Type 1 or Type 2) 2400 The extended validation data may include one of the following 2401 additional attributes, forming a CAdES-X Time-Stamp validation data 2402 (CAdES-X Type 1 or CAdES-X Type 2), to provide additional protection 2403 against later CA compromise and provide integrity of the validation 2404 data used: 2406 - CAdES-C Time-stamp, as defined in section 6.3.5 (CAdES-X Type 1); 2407 or 2409 - Time-Stamped Certificates and CRLs references, as defined in 2410 section 6.3.6 (CAdES-X Type 2). 2412 6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2) 2414 The extended validation data may also include the following additional 2415 information, forming a CAdES-X Long, for use if later validation 2416 processes may not have access to this information: 2418 - certificate-values as defined in section 6.3.3; and 2419 - revocation-values as defined in section 6.3.4. 2421 The extended validation data may in addition to certificate-values and 2422 revocation-values as defined in sections 6.3.3 and 6.3.4 include one of 2423 the following additional attributes, forming an CAdES-X Long Type 1 or 2424 CAdES-X Long Type 2. 2426 - CAdES-C Time-stamp, as defined in section 6.3.3 (CAdES-X long 2427 Type 1); or 2429 - Time-Stamped Certificates and CRLs references, as defined in 2430 section 6.3.4 (CAdES-X Long Type 2). 2432 The CAdES-X Long Type 1 or CAdES-X Long Type 2 provide additional 2433 protection against later CA compromise and provide integrity of the 2434 validation data used. 2436 NOTE 1: The CAdES-X-Long signature provides long term proof of the 2437 validity of the signature for as long as the CA keys, CRL 2438 Issuers keys and OCSP responder keys are not compromised and 2439 are resistant to cryptographic attacks. 2441 NOTE 2: As long as the time stamp data remains valid, the CAdES-X 2442 Long Type 1 and the CAdES-X Long Type 2 provides the following 2443 important property for long standing signatures; that having 2444 been found once to be valid, it shall continue to be so months 2445 or years later, long after the validity period of the 2446 certificates have expired, or after the user key has been 2447 compromised. 2449 6.3.3 Certificate values attribute definition 2451 This attribute may be used to contain the certificate information 2452 required for the following forms of eXtended Electronic Signature: 2453 CAdES-X Long , ES X-Long Type 1 and CAdES-X Long Type 2, see section 2454 B.1.1 for an illustration of this form of electronic signature. 2456 The certificate-values attribute is an unsigned attribute. Only a 2457 single instance of this attribute shall occur with an electronic 2458 signature. It holds the values of certificates referenced in the 2459 complete-certificate-references attribute. 2461 NOTE: If an attribute certificate is used, it is not provided in this 2462 structure but shall be provided by the signer as a signer- 2463 attributes attribute (see section 5.11.3). 2465 The following object identifier identifies the certificate-values 2466 attribute: 2468 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2469 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 2470 The certificate-values attribute value has the ASN.1 syntax 2471 CertificateValues. 2473 CertificateValues ::= SEQUENCE OF Certificate 2475 Certificate is defined in section 7.1. (which is as defined in ITU-T 2476 Recommendation X.509 [1]. 2478 This attribute may include the certification information for any TSUs 2479 that have provided the time-stamp tokens if these certificates are not 2480 already included in the TSTs as part of the TSUs signatures. In this 2481 case the unsigned attribute shall be added to the signedData of the 2482 relevant timestamp token. 2484 6.3.4 Revocation values attribute definition 2486 This attribute is used to contain the revocation information required 2487 for the following forms of eXtended Electronic Signature: CAdES-X Long, 2488 ES X-Long Type 1 and CAdES-X Long Type 2, see section B.1.1 for an 2489 illustration of this form of electronic signature. 2491 The revocation-values attribute is an unsigned attribute. Only a 2492 single instance of this attribute shall occur with an electronic 2493 signature. It holds the values of CRLs and OCSP referenced in the 2494 complete-revocation-references attribute. 2496 NOTE : It is recommended that this attribute is used in preference to 2497 the OtherRevocationInfoFormat specified in RFC 3852 to maintain 2498 backward compatibility with earlier version of this 2499 specification. 2501 The following object identifier identifies the revocation-values 2502 attribute: 2504 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 2505 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2506 smime(16) id-aa(2) 24} 2508 The revocation-values attribute value has the ASN.1 syntax 2509 RevocationValues 2511 RevocationValues ::= SEQUENCE { 2512 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 2513 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 2514 otherRevVals [2] OtherRevVals OPTIONAL } 2516 OtherRevVals ::= SEQUENCE { 2517 OtherRevValType OtherRevValType, 2518 OtherRevVals ANY DEFINED BY OtherRevValType } 2520 OtherRevValType ::= OBJECT IDENTIFIER 2522 The syntax and semantics of the other revocation values (OtherRevVals) 2523 is outside the scope of the present document. 2525 The definition of the syntax of the other form of revocation 2526 information is as identified by OtherRevRefType. 2528 CertificateList is defined in section 7.2. (which as defined in ITU-T 2529 Recommendation X.509 [1]). 2531 BasicOCSPResponse is defined in section 7.3. (which as defined in 2532 RFC 2560 [3]). 2534 This attribute may include the values of revocation data including CRLs 2535 and OCSP for any TSUs that have provided the time-stamp tokens if these 2536 certificates are not already included in the TSTs as part of the TSUs 2537 signatures. In this case the unsigned attribute shall be added to the 2538 signedData of the relevant timestamp token. 2540 6.3.5 CAdES-C time-stamp attribute definition 2542 This attribute is used to protect against CA key compromise. 2544 This attribute is used for the time stamping the complete electronic 2545 signature (CAdES-C). It is used in the following forms of eXtended 2546 Electronic Signature; CAdES-X Type 1 and CAdES-X Long Type 1, see 2547 section B.1.2 for an illustration of this form of electronic signature. 2549 The CAdES-C-timestamp attribute is an unsigned attribute. It is a 2550 time-stamp token of the hash of the electronic signature and the 2551 complete validation data (CAdES-C). It is a special purpose 2552 TimeStampToken Attribute which time-stamps the CAdES-C. Several 2553 instances of this attribute may occur with an electronic signature from 2554 different TSAs. 2556 NOTE 1: It is recommended that the attributes being time-stamped are 2557 encoded in DER. If DER is not employed then the binary encoding 2558 of the ASN.1structures being time-stamped should be preserved to 2559 ensure that the recalculation of the data hash is consistent. 2561 NOTE 2: Each attribute is included in the hash with the attrType and 2562 attrValues (including type and length) but without the type and 2563 length of the outer SEQUENCE. 2565 The following object identifier identifies the CAdES-C-Timestamp 2566 attribute: 2568 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2569 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 2571 The CAdES-C-timestamp attribute value has the ASN.1 syntax 2572 ESCTimeStampToken : 2574 ESCTimeStampToken ::= TimeStampToken 2576 The value of messageImprint field within TimeStampToken shall be a hash 2577 of the concatenated values (without the type or length encoding for 2578 that value) of the following data objects: 2580 - OCTETSTRING of the SignatureValue field within SignerInfo; 2582 - signature-time-stamp, or a time mark operated by a Time-Marking 2583 Authority; 2585 - complete-certificate-references s attribute; and 2587 - complete-revocation-references attribute. 2589 For further information and definition of the TimeStampToken, see 2590 clause 7.4. 2592 6.3.6 Time-stamped certificates and crls references attribute 2593 definition 2595 This attribute is used to protect against CA key compromise. This 2596 attribute is used for the time stamping certificate and revocation 2597 references. It is used in the following forms of eXtended Electronic 2598 Signature; CAdES-X Type 2 and CAdES-X Long Type 2, see section B.1.3 2599 for an illustration of this form of electronic signature. 2601 A time-stamped-certs-crls-references attribute is an unsigned 2602 attribute. It is a time-stamp token issued for a list of referenced 2603 certificates and OCSP responses or/and CRLs to protect against certain 2604 CA compromises. Its syntax is as follows: 2606 NOTE 1: It is recommended that the attributes being time-stamped are 2607 encoded in DER. If DER is not employed then the binary encoding 2608 of the ASN.1structures being time-stamped should be preserved to 2609 ensure that the recalculation of the data hash is consistent. 2611 NOTE 2: Each attribute is included in the hash with the attrType and 2612 attrValues (including type and length) but without the type and 2613 length of the outer SEQUENCE 2615 The following object identifier identifies the time-stamped-certs-crls- 2616 references attribute: 2618 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member 2619 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} 2621 The attribute value has the ASN.1 syntax TimestampedCertsCRLs : 2623 TimestampedCertsCRLs ::= TimeStampToken 2625 The value of messageImprint field within TimeStampToken shall be a hash 2626 of the concatenated values (without the type or length encoding for 2627 that value) of the following data objects as present in the ES with 2628 Complete validation data (CAdES-C): 2630 - complete-certificate-references attribute; and 2632 - complete-revocation-references attribute. 2634 6.4 Archive validation data 2636 Where an electronic signature is required to last for a very long time, 2637 and a the time-stamp token on an electronic signature is in danger of 2638 being invalidated due to algorithm weakness or limits in the validity 2639 period of the TSA certificate, then it may be required to time-stamp 2640 the electronic signature several times. When this is required an 2641 archive time-stamp attribute may be required for the archive form of 2642 electronic signature (CAdES-A). This archive time-stamp attribute may 2643 be repeatedly applied over a period of time. 2645 6.4.1 Archive time-stamp attribute definition 2647 The archive-time-stamp attribute is a time-stamp token of many of the 2648 elements of the signedData in the electronic signature. If the 2649 certificate-values and revocation-values attributes are not present in 2650 the CAdES-BES or CAdES-EPES, then they shall be added to the electronic 2651 signature prior to computing the archive time-stamp token. 2653 The archive-time-stamp attribute is an unsigned attribute. Several 2654 instances of this attribute may occur with an electronic signature 2655 both over time and from different TSUs. 2657 The following object identifier identifies the nested 2658 archive-time-stamp attribute: 2660 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= 2661 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2662 smime(16) id-aa(2) 48} 2664 Archive-time-stamp attribute values have the ASN.1 syntax 2665 ArchiveTimeStampToken 2667 ArchiveTimeStampToken ::= TimeStampToken 2669 The value of messageImprint field within TimeStampToken shall be a hash 2670 of the concatenation of: 2672 - The encapContentInfo element of the SignedData sequence; 2674 - If the eContent element of the encapContentInfo is omitted, 2675 any external content being protected by the signature; 2677 - When present, the Certificates and crls elements of the 2678 SignedData sequence; and 2680 - Together with all data elements in the SignerInfo sequence 2681 including all signed and unsigned attributes. 2683 NOTE 1: An alternative archiveTimestamp attribute, identified by 2684 object identifier { iso(1) member-body(2) us(840) 2685 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27, is 2686 defined in prior versions of TS 101 733. The archiveTimestamp 2687 attribute defined in versions of TS 101 733 prior to 1.5.1 is 2688 not compatible with the attribute defined in the current 2689 document. The archiveTimestamp attribute defined in versions 2690 1.5.1 to 1.7.3 of TS 101 733 is compatible with current 2691 document if the content is internal to encapContentInfo. 2692 Unless the version of TS 101 733 employed by the signing party 2693 is known by all recipients, use of the archiveTimestamp 2694 attribute defined in prior versions of TS 101 733 is 2695 deprecated. 2697 NOTE 2: Counter signatures held as countersignature attributes do not 2698 require independent archive time-stamps as they are protected 2699 by the archive time-stamp against the containing signedData 2700 structure. 2702 NOTE 3: Unless DER is used throughout, it is recommended that the 2703 binary encoding of the ASN.1 structures being time-stamped are 2704 preserved when being archived to ensure that the recalculation 2705 of the data hash is consistent. 2707 NOTE 4: The hash is calculated over the concatenated data elements as 2708 received / stored including the Type and Length encoding. 2710 NOTE 5: Whilst it is recommended that unsigned attributes are DER 2711 encoded it cannot generally be so guaranteed except by prior 2712 arrangement. Further information and definition of 2713 TimeStampToken see section 7.4. The timestamp should be 2714 created using stronger algorithms (or longer key lengths) than 2715 in the original electronic signatures and weak algorithm (key 2716 length) timestamps. 2718 NOTE 6: This form of ES also provides protection against a TSP key 2719 compromise. 2721 The ArchiveTimeStamp will be added as an unsigned attribute in the 2722 SignerInfo sequence. For the validation of one ArchiveTimeStamp the 2723 data elements of the SignerInfo must be concatenated excluding all 2724 later ArchivTimeStampToken attributes. 2726 Certificates and revocation information required to validate the 2727 ArchiveTimeStamp shall be provided by one of the following methods: 2729 - The TSU provides the information in the SignedData of the 2730 timestamp token; 2732 - Adding the complete-certificate-references attribute and the 2733 complete-revocation-references attribute of the TSP as an 2734 unsigned attribute within TimeStampToken, when the required 2735 information is store elsewhere; or 2737 - Adding the certificate-values attribute and the revocation-values 2738 attribute of the TSP as an unsigned attribute within 2739 TimeStampToken, when the required information is store elsewhere. 2741 7 Other standard data structures 2743 7.1 Public-key certificate format 2745 The X.509 v3 certificate basis syntax is defined in ITU-T 2746 Recommendation X.509 [1]. A profile of the X.509 v3 certificate is 2747 defined in RFC 3280 [2]. 2749 7.2 Certificate revocation list format 2751 The X.509 v2 CRL syntax is defined in ITU-T Recommendation X.509 [1]. 2752 A profile of the X.509 v2 CRL is defined in RFC 3280 [2]. 2754 7.3 OCSP response format 2756 The format of an OCSP token is defined in RFC 2560 [3]. 2758 7.4 Time-stamp token format 2760 The format of a TimeStampToken type is defined in RFC 3161 [7] and 2761 profiled in ETSI TS 101 861 [TS101861]. 2763 7.5 Name and attribute formats 2765 The syntax of the naming and other attributes is defined in ITU-T 2766 Recommendation X.509 [1]. 2768 Note: The name used by the signer, held as the subject in the signer's 2769 certificate, is allocated and verified on registration with the 2770 Certification Authority, either directly or indirectly through a 2771 Registration Authority, before being issued with a Certificate. 2773 The present document places no restrictions on the form of the name. 2774 The subject's name may be a distinguished name, as defined in ITU-T 2775 Recommendation X.500 [12], held in the subject field of the 2776 certificate, or any other name form held in the subjectAltName 2777 certificate extension field as defined in ITU-T Recommendation X.509 2778 [1]. In the case that the subject has no distinguished name, the 2779 subject name can be an empty sequence and the subjectAltName extension 2780 shall be critical. 2782 All Certification Authorities, Attribute Authorities and Time Stamping 2783 Authorities shall use distinguished names in the subject field of 2784 their certificate. 2786 The distinguished name shall include identifiers for the organization 2787 providing the service and the legal jurisdiction (e.g. country) under 2788 which it operates. 2790 Where a signer signs as an individual but wishes to also identify 2791 him/herself as acting on behalf of an organization, it may be necessary 2792 to provide two independent forms of identification. The first 2793 identity, with is directly associated with the signing key identifies 2794 him/her as an individual. The second, which is managed independently, 2795 identifies that person acting as part of the organization, possibly 2796 with a given role. In this case one of the two identities is carried 2797 in the subject/subjectAltName field of the signer's certificate as 2798 described above. 2800 The present document does not specify the format of signer's attribute 2801 that may be included in public key certificates. 2803 NOTE : Signer's attribute may be supported by using a claimed role in 2804 the CMS signed attributes field or by placing an attribute 2805 certificate containing a certified role in the CMS signed 2806 attributes field, see section 7.6. 2808 7.6 Attribute certificate 2810 The syntax of the AttributeCertificate type is defined in RFC 3281 [13]. 2812 8. Conformance requirements 2814 For implementations supporting signature generation, the present 2815 document defines conformance requirements for the generation of two 2816 forms of basic electronic signature, one of the two forms must be 2817 implemented. 2819 For implementations supporting signature verification, the present 2820 document defines conformance requirements for the verification of two 2821 forms of basic electronic signature, one of the two forms must be 2822 implemented. 2824 The present document only defines conformance requirements up to an ES 2825 with Complete validation data (CAdES-C). This means that none of the 2826 extended and archive forms of Electronic Signature (CAdES-X, CAdES-A) 2827 need to be implemented to get conformance to the present document. 2829 On verification the inclusion of optional signed and unsigned 2830 attributes must be supported only to the extended that the signature is 2831 verifiable. The semantics of optional attributes may be unsupported, 2832 unless specified otherwise by a signature policy. 2834 8.1 CAdES-Basic Electronic Signature (CAdES-BES) 2836 A system supporting CAdES-BES signers according to the present 2837 document shall, at a minimum, support generation of an electronic 2838 signature consisting of the following components: 2840 - The general CMS syntax and content type as defined in RFC 3852 2841 [4] (see sections 5.1 and 5.2); 2843 - CMS SignedData as defined in RFC 3852 [4] with version set to 3 2844 and at least one SignerInfo shall be present (see sections 5.3 to 2845 5.6); 2847 - The following CMS attributes as defined in RFC 3852 [4]: 2849 - content-type; this shall always be present 2850 (see section 5.7.1); and 2852 - message-digest; this shall always be present (see section 2853 5.7.2). 2855 - One of following attributes as defined in the present document: 2857 - signing-certificate: as defined in section 5.7.3.1; or 2858 - signing-certificate v2 : as defined in section 5.7.3.2. 2860 Note : RFC 3126 was using the other signing certificate attribute 2861 (see section 5.7.3.3). Its use is now deprecated, since the 2862 structure of the signing-certificate v2 attribute is simpler 2863 than the other signing certificate attribute. 2865 8.2 CAdES-Explicit Policy-based Electronic Signature 2867 A system supporting Policy-based signers according to the present 2868 document shall, at a minimum, support generation of an electronic 2869 signature consisting of the previous components defined for the basic 2870 signer, plus: 2872 - The following attributes as defined in section 5.9: 2874 - signature-policy-identifier; this shall always be present (see 2875 section 5.8.1). 2877 8.3 Verification using time-stamping 2879 A system supporting verifiers according to the present document with 2880 time-stamping facilities shall, at a minimum, support: 2882 - verification of the mandated components of an electronic 2883 signature, as defined in section 8.1; 2885 - signature-time-stamp attribute, as defined in section 6.1.1; 2887 - complete-certificate-references, attribute as defined in 2888 section 6.2.1; 2890 - complete-revocation-references attribute, as defined in 2891 section 6.2.2; 2893 - Public Key Certificates, as defined in ITU-T Recommendation X.509 2894 [1] (see section 8.1); and 2896 - either of: 2898 - Certificate Revocation Lists. as defined in ITU-T 2899 Recommendation X.509 [1] (see section 8.2); or 2901 - on-line Certificate Status Protocol, as defined in RFC 2560 2902 [3] (see section 8.3). 2904 8.4 Verification using secure records 2906 A system supporting verifiers according to the present document shall, 2907 at a minimum, support: 2909 - verification of the mandated components of an electronic 2910 signature, as defined in section 8.1; 2912 - complete-certificate-references attribute, as defined in 2913 section 6.2.1; 2915 - complete-revocation-references attribute, as defined in 2916 section 6.2.2; 2918 - a record of the electronic signature and the time when the 2919 signature was first validated using the referenced certificates 2920 and revocation information must be maintained such that records 2921 cannot be undetectable modified; 2923 - Public Key Certificates, as defined in ITU-T Recommendation X.509 2924 [1] (see section 8.1); and 2926 - either of: 2928 - Certificate Revocation Lists. as defined in ITU-T 2929 Recommendation X.509 [1] (see section 8.2); or 2931 - on-line Certificate Status Protocol, as defined in RFC 2560 2932 [3] (see section 8.3). 2934 9. Security considerations 2936 9.1 Protection of private key 2938 The security of the electronic signature mechanism defined in the 2939 present document depends on the privacy of the signer's private key. 2941 Implementations should take steps to ensure that private keys cannot 2942 be compromised. 2944 9.2 Choice of algorithms 2946 Implementers should be aware that cryptographic algorithms become 2947 weaker with time. As new cryptoanalysis techniques are developed and 2948 computing performance improves, the work factor to break a particular 2949 cryptographic algorithm will reduce. Therefore, cryptographic 2951 algorithm implementations should be modular allowing new algorithms to 2952 be readily inserted. That is, implementers should be prepared for the 2953 set of mandatory to implement algorithms to change over time. 2955 10. IANA Considerations 2957 No IANA actions required. 2959 11. References 2961 11.1 Normative references 2963 [1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001): 2964 "Information technology - Open Systems Interconnection - 2965 The Directory: Authentication framework". 2967 [2] IETF RFC 3280 (2002): "Internet X.509 Public Key 2968 Infrastructure Certificate and Certificate Revocation List 2969 (CRL) Profile". 2971 [3] IETF RFC 2560 (1999): "X.509 Internet Public Key 2972 Infrastructure Online Certificate Status Protocol - OCSP". 2974 [4] IETF RFC 3852 (2004): "Cryptographic Message Syntax (CMS)". 2976 [5] IETF RFC 2634 (1999): "Enhanced Security Services for 2977 S/MIME". 2979 [6] IETF RFC 2045 (1996): "Multipurpose Internet Mail Extensions 2980 (MIME) Part One: Format of Internet Message Bodies". 2982 [7] IETF RFC 3161 (2001): "Internet X.509 Public Key 2983 Infrastructure Time-Stamp Protocol ". 2985 [8] ITU-T Recommendation X.680 (1997): "Information technology - 2986 Abstract Syntax Notation One (ASN.1): Specification of basic 2987 notation". 2989 [9] ITU-T Recommendation X.501 (2000)/ISO/IEC 9594-1 (2001): 2990 "Information technology - Open Systems Interconnection - 2991 Directory models ". 2993 [10] IETF RFC 3370 (2002): "Cryptographic Message Syntax (CMS) 2994 Algorithms". 2996 [11] ITU-T Recommendation F.1: "Operational provisions for the 2997 international public telegram service". 2999 [12] ITU-T Recommendation X.500: "Information technology - Open 3000 Systems Interconnection - The Directory: Overview of 3001 concepts, models and services". 3003 [13] IETF RFC 3281 (2002): "An Internet Attribute Certificate 3004 Profile for Authorization". 3006 [14] ITU-T Recommendation X.208 (1988): "Specification of Abstract 3007 Syntax Notation One (ASN.1)". 3009 [15] IETF RFC 5035 (2007). ESS Update: Adding CertID Algorithm 3010 Agility. 3012 11.2 Informative references 3014 ETSI technical specifications can be downloaded free of charge 3015 via the Services and Products Download Area at: 3016 http://www.etsi.org/services_products/freestandard/home.htm 3018 [EU Directive] Directive 1999/93/EC of the European Parliament and 3019 of the Council of 13 December 1999 on a Community framework for 3020 electronic signatures. 3022 [TS101733] ETSI Standard TS 101 733 V.1.7.3 (2005-06) Electronic 3023 Signature Formats. 3025 [TS101861] ETSI TS 101 861: "Time stamping profile". 3027 [TS101903] ETSI TS 101 903: "XML Advanced Electronic Signatures 3028 (XAdES)". 3030 [TS102023] ETSI TS 102 023: "Electronic Signatures and 3031 Infrastructures (ESI); Policy requirements for time-stamping 3032 authorities". 3034 [TR102038] ETSI TR 102 038: "Electronic Signatures and 3035 Infrastructures (ESI); XML format for signature policies". 3037 [TR102272] ETSI TR 102 272 V1.1.1 (2003-12). "Electronic Signatures 3038 and Infrastructures (ESI); ASN.1 format for signature policies". 3040 [RFC2246] IETF RFC 2246 (1999): "The TLS Protocol Version 1.0". 3042 [RFC2437] IETF RFC 2437 (1998): "PKCS #1: RSA Cryptography 3043 Specifications Version 2.0". 3045 [RFC2479] IETF RFC 2479 (1998): "Independent Data Unit Protection 3046 Generic Security Service Application Program Interface 3047 (IDUP-GSS-API)". 3049 [RFC2510] IETF RFC 2510 (1999): "Internet X.509 Public Key 3050 Infrastructure Certificate Management Protocols". 3052 [RFC2559] IETF RFC 2559 (2003): "Internet X.509 Public Key 3053 Infrastructure Operational Protocols - LDAPv2". 3055 [RFC2587] IETF RFC 2587 (1999): "Internet X.509 Public Key 3056 Infrastructure LDAPv2 Schema". 3058 [RFC3125] IETF RFC 3125 (2000): "Electronic Signature Policies". 3060 [RFC3851] IETF RFC 3851 (2004): �SMIME Version 3.1 Message 3061 Specification�. 3063 [ISO7498-2] ISO 7498-2 (1989): "Information processing systems � 3064 Open Systems Interconnection - Basic Reference Model - Part 2: 3065 Security Architecture". 3067 [ISO9796-2] ISO/IEC 9796-2 (2002): "Information technology � 3068 Security techniques - Digital signature schemes giving message 3069 recovery - Part 2: Integer factorization based mechanisms". 3071 [ISO9796-4] ISO/IEC 9796-4 (1998): "Digital signature schemes 3072 giving message recovery - Part 4: Discrete logarithm based 3073 mechanisms". 3075 [ISO10118-1] ISO/IEC 10118-1 (2000): "Information technology � 3076 Security techniques - Hash-functions - Part 1: General". 3078 [ISO10118-2] ISO/IEC 10118-2 (2000): "Information technology � 3079 Security techniques - Hash-functions - Part 2: Hash-functions using 3080 an n-bit block cipher algorithm". 3082 [ISO10118-3] ISO/IEC 10118-3 (2004): "Information technology � 3083 Security techniques - Hash-functions - Part 3: Dedicated 3084 hash-functions". 3086 [ISO10118-4] ISO/IEC 10118-4 (1998): "Information technology � 3087 Security techniques - Hash-functions - Part 4: Hash-functions using 3088 modular arithmetic". 3090 [ISO10181-5] ISO/IEC 10181-5: Security Frameworks in Open Systems. 3091 Non-Repudiation Framework. April 1997. 3093 [ISO13888-1]ISO/IEC 13888-1 (2004): "IT security techniques � 3094 Non-repudiation - Part 1: General". 3096 [ISO14888-1] ISO/IEC 14888-1 (1998): "Information technology � 3097 Security techniques - Digital signatures with appendix - Part 1: 3098 General". 3100 [ISO14888-2] ISO/IEC 14888-2 (1999): "Information technology � 3101 Security techniques - Digital signatures with appendix - Part 2: 3102 Identity-based mechanisms". 3104 [ISO14888-3] ISO/IEC 14888-3 (1998): "Information technology � 3105 Security techniques - Digital signatures with appendix - Part 3: 3106 Certificate-based mechanisms". 3108 [ISO15946-2] ISO/IEC 15946-2 (2002): "Information technology � 3109 Security techniques - Cryptographic techniques based on elliptic 3110 curves - Part 2: Digital signatures". 3112 [ISO15946-3] ISO/IEC 15946-3 (2002): "Information technology � 3113 Security techniques - Cryptographic techniques based on elliptic 3114 curves - Part 3: Key establishment". 3116 [X690] ITU-T Recommendation X.690 (2002): "Specification of basic 3117 encoding rules for Abstract Syntax Notation One (ASN.1)". 3119 [CWA14171] CWA 14171 CEN Workshop Agreements: "General Guidelines 3120 for Electronic Signature Verification". 3122 [XMLDSIG] XMLDSIG: W3C/IETF Recommendation (February 2002): 3123 "XML-Signature Syntax and Processing". 3125 [X9.30-1] ANSI X9.30-1 (1997): "Public Key Cryptography for the 3127 Financial Services Industry - Part 1: The Digital Signature 3128 Algorithm (DSA)". 3130 [X9.30-2] ANSI X9.30-2 (1997): "Public Key Cryptography for the 3131 Financial Services Industry - Part 2: The Secure Hash Algorithm 3132 (SHA-1)". 3134 [X9.31-1] ANSI X9.31-1 (1997): "Public Key Cryptography Using 3135 Reversible Algorithms for the Financial Services Industry - 3136 Part 1: The RSA Signature Algorithm". 3138 [X9.31-2] ANSI X9.31-2 (1996): "Public Key Cryptography Using 3139 Reversible Algorithms for the Financial Services Industry - 3140 Part 2: Hash Algorithms". 3142 [X9.62] ANSI X9.62 (1998): "Public Key Cryptography for the 3143 Financial Services Industry - The Elliptic Curve Digital Signature 3144 Algorithm (ECDSA)". 3146 [X.209] CCITT Recommendation X.209: Specification of Basic Encoding 3147 Rules for Abstract Syntax Notation One (ASN.1) 1988. 3149 [P1363] IEEE P1363 (2000): "Standard Specifications for Public-Key 3150 Cryptography". 3152 12. Authors' addresses 3154 Denis Pinkas 3155 Bull S.A.S. 3156 Rue Jean-Jaures 3157 78340 Les Clayes sous Bois CEDEX 3158 FRANCE 3159 EMail: Denis.Pinkas@bull.net 3161 Nick Pope 3162 Thales eSecurity 3163 Meadow View House 3164 Long Crendon 3165 Aylesbury 3166 Buck 3167 HP18 9EQ 3168 United Kingdom 3169 EMail: nick.pope@thales-esecurity.com 3170 John Ross 3172 Security & Standards Consultancy Ltd 3173 The Waterhouse Business Centre 3174 2 Cromer Way 3175 Chelmsford 3176 Essex 3177 CM1 2QE 3178 United Kingdom 3179 EMail: ross@secstan.com 3181 13. Acknowledgments 3183 Special thanks to Russ Housley for reviewing the document. 3185 Annex A (normative): ASN.1 definitions 3187 This annex provides a summary of all the ASN.1 syntax definitions for 3188 new syntax defined in the present document. 3190 A.1 Signature format definitions using X.208 ASN.1 syntax 3192 NOTE: The ASN.1 module defined in section A.1 using syntax defined in 3193 ITU-T Recommendation X.208 [14] has precedence over that 3194 defined in section A.2 in the case of any conflict. 3196 ETS-ElectronicSignatureFormats-ExplicitSyntax88 { iso(1) member-body(2) 3197 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 3198 eSignature-explicit88(28)} 3200 DEFINITIONS EXPLICIT TAGS ::= 3202 BEGIN 3204 -- EXPORTS All 3206 IMPORTS 3208 -- Cryptographic Message Syntax (CMS): RFC 3852 3210 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3211 EncapsulatedContentInfo, SignerInfo, id-contentType, 3212 id-messageDigest, MessageDigest, id-signingTime, SigningTime, 3213 id-countersignature, Countersignature 3214 FROM CryptographicMessageSyntax2004 3215 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3216 smime(16) modules(0) cms-2004(24) } 3218 -- ESS Defined attributes: ESS Update 3219 -- RFC 5035 (Adding CertID Algorithm Agility) 3221 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3222 id-aa-contentReference, ContentReference, id-aa-contentIdentifier, 3223 ContentIdentifier, id-aa-signingCertificatev2 3224 FROM ExtendedSecurityServices-2006 3225 { iso(1) member-body(2) us(840) rsadsi(113549) 3226 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 3228 -- Internet X.509 Public Key Infrastructure - Certificate and CRL 3229 -- Profile: RFC 3280 3231 Certificate, AlgorithmIdentifier, CertificateList, Name, 3232 DirectoryString, Attribute, BMPString, UTF8String 3233 FROM PKIX1Explicit88 3234 {iso(1) identified-organization(3) dod(6) internet(1) 3235 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} 3237 GeneralNames, GeneralName, PolicyInformation 3238 FROM PKIX1Implicit88 3239 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 3240 mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit (19)} 3242 -- Internet Attribute Certificate Profile for Authorization - RFC 3281 3244 AttributeCertificate 3245 FROM PKIXAttributeCertificate {iso(1) identified-organization(3) 3246 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3247 id-mod(0) id-mod-attribute-cert(12)} 3249 -- OCSP - RFC 2560 3251 BasicOCSPResponse, ResponderID 3252 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 3253 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 3255 -- Time Stamp Protocol RFC 3161 3257 TimeStampToken 3258 FROM PKIXTSP 3259 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 3260 mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 3262 ; 3264 -- Definitions of Object Identifier arcs used in the present document 3265 -- ================================================================== 3267 -- OID used referencing electronic signature mechanisms based on 3268 -- the present document for use with the IDUP API (see annex D) 3270 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3271 { itu-t(0) identified-organization(4) etsi(0) 3272 electronic-signature-standard (1733) part1 (1) idupMechanism (4) 3273 etsiESv1(1) } 3275 -- Basic ES CMS Attributes Defined in the present document 3276 -- ======================================================= 3278 -- OtherSigningCertificate - deprecated 3280 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= 3281 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3282 smime(16) id-aa(2) 19 } 3284 OtherSigningCertificate ::= SEQUENCE { 3285 certs SEQUENCE OF OtherCertID, 3286 policies SEQUENCE OF PolicyInformation OPTIONAL 3287 -- NOT USED IN THE PRESENT DOCUMENT 3288 } 3290 OtherCertID ::= SEQUENCE { 3291 otherCertHash OtherHash, 3292 issuerSerial IssuerSerial OPTIONAL } 3294 OtherHash ::= CHOICE { 3295 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3296 otherHash OtherHashAlgAndValue} 3298 -- Policy ES Attributes Defined in the present document 3299 -- ==================================================== 3301 -- Mandatory Basic Electronic Signature Attributes as above, 3302 -- plus in addition. 3304 -- Signature Policy Identifier 3306 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= 3307 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3308 smime(16) id-aa(2) 15 } 3310 SignaturePolicy ::= CHOICE { 3311 signaturePolicyId SignaturePolicyId, 3312 signaturePolicyImplied SignaturePolicyImplied 3313 -- not used in this version 3314 } 3316 SignaturePolicyId ::= SEQUENCE { 3317 sigPolicyId SigPolicyId, 3318 sigPolicyHash SigPolicyHash, 3319 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3320 SigPolicyQualifierInfo OPTIONAL 3321 } 3323 SignaturePolicyImplied ::= NULL 3325 SigPolicyId ::= OBJECT IDENTIFIER 3327 SigPolicyHash ::= OtherHashAlgAndValue 3329 OtherHashAlgAndValue ::= SEQUENCE { 3330 hashAlgorithm AlgorithmIdentifier, 3331 hashValue OtherHashValue } 3333 OtherHashValue ::= OCTET STRING 3335 SigPolicyQualifierInfo ::= SEQUENCE { 3336 sigPolicyQualifierId SigPolicyQualifierId, 3337 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 3339 SigPolicyQualifierId ::= OBJECT IDENTIFIER 3341 id-spq-ets-uri OBJECT IDENTIFIER ::= 3342 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3343 smime(16) id-spq(5) 1 } 3345 SPuri ::= IA5String 3347 id-spq-ets-unotice OBJECT IDENTIFIER ::= 3348 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3349 smime(16) id-spq(5) 2 } 3351 SPUserNotice ::= SEQUENCE { 3352 noticeRef NoticeReference OPTIONAL, 3353 explicitText DisplayText OPTIONAL} 3355 NoticeReference ::= SEQUENCE { 3356 organization DisplayText, 3357 noticeNumbers SEQUENCE OF INTEGER } 3359 DisplayText ::= CHOICE { 3360 visibleString VisibleString (SIZE (1..200)), 3361 bmpString BMPString (SIZE (1..200)), 3363 utf8String UTF8String (SIZE (1..200)) } 3365 -- Optional Electronic Signature Attributes 3367 -- Commitment Type 3369 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3370 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3372 CommitmentTypeIndication ::= SEQUENCE { 3373 commitmentTypeId CommitmentTypeIdentifier, 3374 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3375 CommitmentTypeQualifier OPTIONAL} 3377 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3379 CommitmentTypeQualifier ::= SEQUENCE { 3380 commitmentTypeIdentifier CommitmentTypeIdentifier, 3381 qualifier ANY DEFINED BY commitmentTypeIdentifier } 3383 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3384 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 3385 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3386 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 3388 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= 3389 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3390 smime(16) cti(6) 3} 3392 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3393 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 3395 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= 3396 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3397 smime(16) cti(6) 5} 3399 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= 3400 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3401 smime(16) cti(6) 6} 3403 -- Signer Location 3405 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3406 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3408 SignerLocation ::= SEQUENCE { 3409 -- at least one of the following shall be present 3410 countryName [0] DirectoryString OPTIONAL, 3411 -- As used to name a Country in X.500 3412 localityName [1] DirectoryString OPTIONAL, 3413 -- As used to name a locality in X.500 3414 postalAdddress [2] PostalAddress OPTIONAL } 3416 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 3418 -- Signer Attributes 3420 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3421 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3423 SignerAttribute ::= SEQUENCE OF CHOICE { 3424 claimedAttributes [0] ClaimedAttributes, 3425 certifiedAttributes [1] CertifiedAttributes } 3427 ClaimedAttributes ::= SEQUENCE OF Attribute 3429 CertifiedAttributes ::= AttributeCertificate 3430 -- as defined in RFC 3281 : see section 4.1 3432 -- Content Timestamp 3434 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= 3435 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3436 smime(16) id-aa(2) 20} 3438 ContentTimestamp ::= TimeStampToken 3440 -- Signature Timestamp 3442 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= 3443 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3444 smime(16) id-aa(2) 14} 3446 SignatureTimeStampToken ::= TimeStampToken 3448 -- Complete Certificate Refs. 3450 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3451 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3453 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 3455 -- Complete Revocation Refs 3457 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3458 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3460 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3462 CrlOcspRef ::= SEQUENCE { 3463 crlids [0] CRLListID OPTIONAL, 3464 ocspids [1] OcspListID OPTIONAL, 3465 otherRev [2] OtherRevRefs OPTIONAL 3466 } 3468 CRLListID ::= SEQUENCE { 3469 crls SEQUENCE OF CrlValidatedID} 3471 CrlValidatedID ::= SEQUENCE { 3472 crlHash OtherHash, 3473 crlIdentifier CrlIdentifier OPTIONAL} 3475 CrlIdentifier ::= SEQUENCE { 3476 crlissuer Name, 3477 crlIssuedTime UTCTime, 3478 crlNumber INTEGER OPTIONAL } 3480 OcspListID ::= SEQUENCE { 3481 ocspResponses SEQUENCE OF OcspResponsesID} 3483 OcspResponsesID ::= SEQUENCE { 3484 ocspIdentifier OcspIdentifier, 3485 ocspRepHash OtherHash OPTIONAL 3486 } 3488 OcspIdentifier ::= SEQUENCE { 3489 ocspResponderID ResponderID, 3490 -- As in OCSP response data 3491 producedAt GeneralizedTime 3492 -- As in OCSP response data 3493 } 3494 OtherRevRefs ::= SEQUENCE { 3495 otherRevRefType OtherRevRefType, 3496 otherRevRefs ANY DEFINED BY otherRevRefType 3497 } 3499 OtherRevRefType ::= OBJECT IDENTIFIER 3501 -- Certificate Values 3503 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3504 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3506 CertificateValues ::= SEQUENCE OF Certificate 3508 -- Certificate Revocation Values 3510 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 3511 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3512 smime(16) id-aa(2) 24} 3514 RevocationValues ::= SEQUENCE { 3515 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3516 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3517 otherRevVals [2] OtherRevVals OPTIONAL} 3519 OtherRevVals ::= SEQUENCE { 3520 otherRevValType OtherRevValType, 3521 otherRevVals ANY DEFINED BY otherRevValType 3522 } 3524 OtherRevValType ::= OBJECT IDENTIFIER 3526 -- CAdES-C Timestamp 3528 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3529 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 3531 ESCTimeStampToken ::= TimeStampToken 3533 -- Time-Stamped Certificates and CRLs 3535 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) 3536 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3537 smime(16) id-aa(2) 26} 3539 TimestampedCertsCRLs ::= TimeStampToken 3541 -- Archive Timestamp 3543 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) 3544 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3545 smime(16) id-aa(2) 48} 3546 ArchiveTimeStampToken ::= TimeStampToken 3548 -- Attribute certificate references 3550 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) 3551 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3552 smime(16) id-aa(2) 44} 3554 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 3556 -- Attribute revocation references 3558 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) 3559 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3560 smime(16) id-aa(2) 45} 3562 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 3564 END 3565 A.2 Signature format definitions using X.680 ASN.1 syntax 3567 NOTE: The ASN.1 module defined in section A.1 has precedence over that 3568 defined in section A.2 using syntax defined in ITU-T 3569 Recommendation X.680 (1997) [8] in the case of any conflict. 3571 ETS-ElectronicSignatureFormats-ExplicitSyntax97 { iso(1) member-body(2) 3572 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 3573 eSignature-explicit97(29)} 3575 DEFINITIONS EXPLICIT TAGS ::= 3577 BEGIN 3579 -- EXPORTS All - 3581 IMPORTS 3583 -- Cryptographic Message Syntax (CMS): RFC 3852 3585 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3586 EncapsulatedContentInfo, SignerInfo, 3587 id-contentType, id-messageDigest, MessageDigest, id-signingTime, 3588 SigningTime, id-countersignature, Countersignature 3589 FROM CryptographicMessageSyntax2004 3590 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3591 smime(16) modules(0) cms-2004(24) } 3593 -- ESS Defined attributes: ESS Update 3594 -- RFC 5035 (Adding CertID Algorithm Agility) 3596 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3597 id-aa-contentReference, ContentReference, id-aa-contentIdentifier, 3598 ContentIdentifier, id-aa-signingCertificatev2 3599 FROM ExtendedSecurityServices-2006 3600 { iso(1) member-body(2) us(840) rsadsi(113549) 3601 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 3603 -- Internet X.509 Public Key Infrastructure 3604 -- Certificate and CRL Profile: RFC 3280 3606 Certificate, AlgorithmIdentifier, CertificateList, Name, 3607 Attribute 3609 FROM PKIX1Explicit88 3610 {iso(1) identified-organization(3) dod(6) internet(1) 3611 security(5) mechanisms(5) pkix(7) id-mod(0) 3612 id-pkix1-explicit(18)} 3614 GeneralNames, GeneralName, PolicyInformation 3615 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3616 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3617 id-pkix1-implicit(19)} 3619 -- Internet Attribute Certificate Profile for Authorization - RFC 3281 3621 AttributeCertificate 3622 FROM PKIXAttributeCertificate {iso(1) identified-organization(3) 3623 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3624 id-mod-attribute-cert(12)} 3626 -- OCSP RFC 2560 3628 BasicOCSPResponse, ResponderID 3629 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 3630 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 3632 -- RFC 3161 Internet X.509 Public Key Infrastructure 3633 -- Time-Stamp Protocol 3635 TimeStampToken 3636 FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) 3637 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 3639 -- X.520 3641 DirectoryString {} 3642 FROM SelectedAttributeTypes 3643 {joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4} 3645 ; 3647 -- Definitions of Object Identifier arcs used in the present document 3648 -- ================================================================== 3650 -- OID used referencing electronic signature mechanisms based 3651 -- on the present document for use with the IDUP API (see annex D) 3653 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3654 { itu-t(0) identified-organization(4) etsi(0) 3655 electronic-signature-standard (1733) part1 (1) idupMechanism (4) 3656 etsiESv1(1) } 3658 -- Basic ES Attributes Defined in the present document 3659 -- =================================================== 3661 -- CMS Attributes defined in the present document 3662 -- OtherSigningCertificate - deprecated 3664 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 3665 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3666 smime(16) id-aa(2) 19 } 3668 OtherSigningCertificate ::= SEQUENCE { 3669 certs SEQUENCE OF OtherCertID, 3670 policies SEQUENCE OF PolicyInformation OPTIONAL 3671 -- NOT USED IN THE PRESENT DOCUMENT 3672 } 3674 OtherCertID ::= SEQUENCE { 3675 otherCertHash OtherHash, 3676 issuerSerial IssuerSerial OPTIONAL } 3678 OtherHash ::= CHOICE { 3679 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3680 otherHash OtherHashAlgAndValue} 3682 -- Policy ES Attributes Defined in the present document 3683 -- ==================================================== 3685 -- Mandatory Basic Electronic Signature Attributes, plus in addition. 3686 -- Signature Policy Identifier 3688 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 3689 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3690 smime(16) id-aa(2) 15 } 3692 SignaturePolicy ::= CHOICE { 3693 signaturePolicyId SignaturePolicyId, 3694 signaturePolicyImplied SignaturePolicyImplied 3695 -- not used in this version 3696 } 3698 SignaturePolicyId ::= SEQUENCE { 3699 sigPolicyId SigPolicyId, 3700 sigPolicyHash SigPolicyHash, 3701 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3702 SigPolicyQualifierInfo OPTIONAL 3703 } 3705 SignaturePolicyImplied ::= NULL 3707 SigPolicyId ::= OBJECT IDENTIFIER 3709 SigPolicyHash ::= OtherHashAlgAndValue 3711 OtherHashAlgAndValue ::= SEQUENCE { 3712 hashAlgorithm AlgorithmIdentifier, 3713 hashValue OtherHashValue 3714 } 3715 OtherHashValue ::= OCTET STRING 3717 SigPolicyQualifierInfo ::= SEQUENCE { 3718 sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id 3719 ({SupportedSigPolicyQualifiers}), 3720 qualifier SIG-POLICY-QUALIFIER.&Qualifier 3721 ({SupportedSigPolicyQualifiers} 3722 {@sigPolicyQualifierId})OPTIONAL } 3724 SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 3725 { noticeToUser | pointerToSigPolSpec } 3727 SIG-POLICY-QUALIFIER ::= CLASS { 3728 &id OBJECT IDENTIFIER UNIQUE, 3729 &Qualifier OPTIONAL } 3730 WITH SYNTAX { 3731 SIG-POLICY-QUALIFIER-ID &id 3732 [SIG-QUALIFIER-TYPE &Qualifier] } 3734 noticeToUser SIG-POLICY-QUALIFIER ::= { 3735 SIG-POLICY-QUALIFIER-ID id-spq-ets-unotice SIG-QUALIFIER-TYPE 3736 SPUserNotice } 3738 pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { 3739 SIG-POLICY-QUALIFIER-ID id-spq-ets-uri SIG-QUALIFIER-TYPE SPuri } 3741 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 3742 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3743 smime(16) id-spq(5) 1 } 3745 SPuri ::= IA5String 3747 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 3748 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3749 smime(16) id-spq(5) 2 } 3751 SPUserNotice ::= SEQUENCE { 3752 noticeRef NoticeReference OPTIONAL, 3753 explicitText DisplayText OPTIONAL} 3755 NoticeReference ::= SEQUENCE { 3756 organization DisplayText, 3757 noticeNumbers SEQUENCE OF INTEGER } 3759 DisplayText ::= CHOICE { 3760 visibleString VisibleString (SIZE (1..200)), 3761 bmpString BMPString (SIZE (1..200)), 3762 utf8String UTF8String (SIZE (1..200)) } 3764 -- Optional Electronic Signature Attributes 3765 -- Commitment Type 3767 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3768 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3770 CommitmentTypeIndication ::= SEQUENCE { 3771 commitmentTypeId CommitmentTypeIdentifier, 3772 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3773 CommitmentTypeQualifier OPTIONAL} 3775 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3777 CommitmentTypeQualifier ::= SEQUENCE { 3778 commitmentQualifierId COMMITMENT-QUALIFIER.&id, 3779 qualifier COMMITMENT-QUALIFIER.&Qualifier OPTIONAL } 3781 COMMITMENT-QUALIFIER ::= CLASS { 3782 &id OBJECT IDENTIFIER UNIQUE, 3783 &Qualifier OPTIONAL } 3784 WITH SYNTAX { 3785 COMMITMENT-QUALIFIER-ID &id 3786 [COMMITMENT-TYPE &Qualifier] } 3788 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3789 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 3791 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3792 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 3794 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 3795 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3796 cti(6) 3} 3798 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3799 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 3801 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= 3802 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3803 smime(16) cti(6) 5} 3805 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= 3806 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3807 smime(16) cti(6) 6} 3809 -- Signer Location 3811 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3812 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3813 SignerLocation ::= SEQUENCE { 3814 -- at least one of the following shall be present 3815 countryName [0] DirectoryString{maxSize} OPTIONAL, 3816 -- as used to name a Country in X.520 3817 localityName [1] DirectoryString{maxSize} OPTIONAL, 3818 -- as used to name a locality in X.520 3819 postalAdddress [2] PostalAddress OPTIONAL } 3821 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize} 3822 -- maxSize parametrization as specified in X.683 3824 -- Signer Attributes 3826 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3827 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3829 SignerAttribute ::= SEQUENCE OF CHOICE { 3830 claimedAttributes [0] ClaimedAttributes, 3831 certifiedAttributes [1] CertifiedAttributes } 3833 ClaimedAttributes ::= SEQUENCE OF Attribute 3835 CertifiedAttributes ::= AttributeCertificate 3836 -- as defined in RFC 3281 : see section 4.1 3838 -- Content Timestamp 3840 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= 3841 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3842 smime(16) id-aa(2) 20} 3844 ContentTimestamp ::= TimeStampToken 3846 -- Signature Timestamp 3848 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= 3849 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3850 smime(16) id-aa(2) 14} 3852 SignatureTimeStampToken ::= TimeStampToken 3854 -- Complete Certificate Refs. 3856 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3857 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3859 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 3861 -- Complete Revocation Refs 3863 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3864 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3866 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3867 CrlOcspRef ::= SEQUENCE { 3868 crlids [0] CRLListID OPTIONAL, 3869 ocspids [1] OcspListID OPTIONAL, 3870 otherRev [2] OtherRevRefs OPTIONAL 3871 } 3873 CRLListID ::= SEQUENCE { 3874 crls SEQUENCE OF CrlValidatedID 3875 } 3877 CrlValidatedID ::= SEQUENCE { 3878 crlHash OtherHash, 3879 crlIdentifier CrlIdentifier OPTIONAL 3880 } 3882 CrlIdentifier ::= SEQUENCE { 3883 crlissuer Name, 3884 crlIssuedTime UTCTime, 3885 crlNumber INTEGER OPTIONAL 3886 } 3888 OcspListID ::= SEQUENCE { 3889 ocspResponses SEQUENCE OF OcspResponsesID 3890 } 3892 OcspResponsesID ::= SEQUENCE { 3893 ocspIdentifier OcspIdentifier, 3894 ocspRepHash OtherHash OPTIONAL 3895 } 3897 OcspIdentifier ::= SEQUENCE { 3898 ocspResponderID ResponderID, 3899 -- As in OCSP response data 3900 producedAt GeneralizedTime 3901 -- As in OCSP response data 3902 } 3904 OtherRevRefs ::= SEQUENCE { 3905 otherRevRefType OTHER-REVOCATION-REF.&id, 3906 otherRevRefs SEQUENCE OF OTHER-REVOCATION-REF.&Type 3907 } 3909 OTHER-REVOCATION-REF ::= CLASS { 3910 &Type, 3911 &id OBJECT IDENTIFIER UNIQUE } 3912 WITH SYNTAX { 3913 WITH SYNTAX &Type ID &id } 3915 -- Certificate Values 3917 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3918 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3920 CertificateValues ::= SEQUENCE OF Certificate 3921 -- Certificate Revocation Values 3923 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= 3924 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3925 smime(16) id-aa(2) 24} 3927 RevocationValues ::= SEQUENCE { 3928 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3929 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3930 otherRevVals [2] OtherRevVals OPTIONAL 3931 } 3933 OtherRevVals ::= SEQUENCE { 3934 otherRevValType OTHER-REVOCATION-VAL.&id, 3935 otherRevVals SEQUENCE OF OTHER-REVOCATION-REF.&Type 3936 } 3938 OTHER-REVOCATION-VAL ::= CLASS { 3939 &Type, 3940 &id OBJECT IDENTIFIER UNIQUE } 3941 WITH SYNTAX { 3942 WITH SYNTAX &Type ID &id } 3944 -- CAdES-C Timestamp 3945 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3946 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 3948 ESCTimeStampToken ::= TimeStampToken 3950 -- Time-Stamped Certificates and CRLs 3952 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= 3953 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3954 smime(16) id-aa(2) 26} 3956 TimestampedCertsCRLs ::= TimeStampToken 3958 -- Archive Timestamp 3960 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= 3961 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3962 smime(16) id-aa(2) 48} 3964 ArchiveTimeStampToken ::= TimeStampToken 3966 -- Attribute certificate references 3968 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= 3969 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3970 smime(16) id-aa(2) 44} 3972 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 3974 -- Attribute revocation references 3976 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= 3977 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3978 smime(16) id-aa(2) 45} 3980 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 3982 END 3983 Annex B (informative): Extended forms of Electronic Signatures 3985 Section 4 provides on overview of the various formats of electronic 3986 signatures included in the present document. This annex lists the 3987 attributes that need to be present in the various extended electronic 3988 signature formats and provide example validation sequences using the 3989 extended formats. 3991 B.1 Extended forms of validation data 3993 The complete validation data (CAdES-C) described in section 4.3 and 3994 illustrated in figure 3 may be extended to create Electronic Signatures 3995 with extended validation data. Some Electronic Signatures forms that 3996 include extended validation are explained below. 3998 An X-Long electronic signature (CAdES-X Long) is when the values of the 3999 certificates and revocation information are added to the CAdES-C. 4001 This form of Electronic Signature can be useful when the verifier does 4002 not have direct access to the following information: 4004 - the signer's certificate; 4006 - all the CA certificates that make up the full certification path; 4008 - all the associated revocation status information, as referenced 4009 in the CAdES-C. 4011 In some situations additional time-stamps may be created and added to 4012 the Electronic Signatures as additional attributes. For example: 4014 - time-stamping all the validation data as held with the ES (CAdES- 4015 C), this eXtended validation data is called a CAdES-X Type 1; or 4017 - time-stamping individual reference data as used for complete 4018 validation. This form of eXtended validation data is called an 4019 CAdES-X Type 2. 4021 NOTE 1: The advantages/drawbacks for CAdES-X Type 1 and CAdES-X Type 2 4022 are discussed in section C.4.4. 4024 The above time-stamp forms can be useful when it is required to counter 4025 the risk that any CA keys used in the certificate chain may be 4026 compromised. 4028 A combination of the two formats above may be used. This form of 4029 eXtended validation data is called an ES X-Long Type 1 or CAdES-X Long 4030 Type 2. This form of Electronic Signature can be useful when the 4031 verifier needs both the values and proof of when the validation data 4032 existed. 4034 NOTE 2: The advantages/drawbacks for CAdES-X long Type 1 and CAdES-X 4035 long Type 2 are discussed in section C.4.6. 4037 B.1.1 CAdES-X Long 4039 An Electronic Signature with the additional validation data forming the 4040 CAdES-X Long form (CAdES-X-Long)) is illustrated in figure B.1 and 4041 comprises the following: 4043 - CAdES-BES or CAdES-EPES as defined in sections 4.3 , 5.7 or 5.8; 4045 - complete-certificate-references attribute as defined in section 4046 6.2.1; 4048 - complete-revocation-references attribute as defined in section 4049 6.2.2. 4051 The following attributes are required if a TSP is not providing a time- 4052 mark of the ES: 4054 - signature-time-stamp attribute as defined in section 6.1.1. 4056 The following attributes are required if the full certificate values 4057 and revocation values are not already included in the CAdES-BES or 4058 CAdES-EPES: 4060 - certificate-values attribute as defined in section 6.3.3; 4061 - revocation-values attribute, as defined in section 6.3.4. 4063 If attributes certificates are used then the following attributes may 4064 be present: 4066 - attribute-certificate-references attribute defined in section 4067 6.2.3; 4069 - attribute-revocation-references attribute as defined in section 4070 6.2.4. 4072 Other unsigned attributes may be present, but are not required. 4074 NOTE: Attribute certificate and revocation references are only 4075 present if a user attribute certificate is present in the 4076 electronic signature, see sections 6.2.2 and 6.2.3. 4078 +---------------------- CAdES-X-Long --------------------------------+ 4079 |+-------------------------------------- CAdES-C ---+ | 4080 || +----------+ | +-------------+| 4081 ||+----- CAdES-BES or CAdES-EPES ----+ |Timestamp | | | || 4082 ||| | |over | | | Complete || 4083 |||+---------++----------++---------+| |digital | | | certificate || 4084 |||| || || || |signature | | | and || 4085 ||||Signer's || Signed ||Digital || | | | | revocation || 4086 ||||Document ||Attributes||signature|| |Optional | | | data || 4087 |||| || || || |when | | | || 4088 |||+---------++----------++---------+| |timemarked| | | || 4089 ||+----------------------------------+ +----------+ | | || 4090 || +-----------+| +-------------+| 4091 || |Complete || | 4092 || |certificate|| | 4093 || |and || | 4094 || |revocation || | 4095 || |references || | 4096 || +-----------+| | 4097 |+--------------------------------------------------+ | 4098 | | 4099 +--------------------------------------------------------------------+ 4101 Figure B.1 : Illustration of CAdES-X-Long 4103 B.1.2 CAdES-X Type 1 4105 An Electronic Signature with the additional validation data forming the 4106 eXtended Validation Data - Type 1 X is illustrated in figure B.2 and 4107 comprises the following: 4109 - the CAdES-BES or CAdES-EPES as defined in sections 4.2, 5.7 or 4110 5.8; 4112 - complete-certificate-references attribute as defined in section 4113 6.2.1; 4115 - complete-revocation-references attribute as defined in section 4116 6.2.2; 4118 - CAdES-C-Timestamp attribute, as defined in section 6.3.5. 4120 The following attributes are required if a TSP is not providing a time- 4121 mark of the ES: 4123 - signature-time-stamp attribute as defined in section 6.1.1. 4125 If attributes certificates are used then the following attributes may 4126 be present: 4128 - attribute-certificate-references attribute defined in section 4129 6.2.3; 4131 - attribute-revocation-references attribute as defined in section 4132 6.2.4. 4134 Other unsigned attributes may be present, but are not required. 4136 +------------------------ CAdES-X-Type 1 ----------------------------+ 4137 |+---------------------------------- CAdES-C ------+ | 4138 || +----------+ | +-------------+ | 4139 ||+--- CAdES-BES or CAdES-EPES ------+|Timestamp | | | | | 4140 ||| ||over | | | | | 4141 |||+---------++----------++---------+||digital | | | | | 4142 ||||Signer's || Signed || Digital |||signature | | | Timestamp | | 4143 ||||Document ||Attributes||signature||| | | | over | | 4144 |||| || || |||Optional | | | CAdES-C | | 4145 |||+---------++----------++---------+||when | | | | | 4146 ||+----------------------------------+|timemarked| | | | | 4147 || +----------+ | | | | 4148 || +-----------+| +-------------+ | 4149 || |Complete || | 4150 || |certificate|| | 4151 || | and || | 4152 || |revocation || | 4153 || |references || | 4154 || +-----------+| | 4155 |+-------------------------------------------------+ | 4156 | | 4157 +--------------------------------------------------------------------+ 4159 Figure B.2 : Illustration of CAdES-X Type 1 4161 B.1.3 CAdES-X Type 2 4163 An Electronic Signature with the additional validation data forming the 4164 eXtended Validation Data - Type 2 X is illustrated in figure B.3. and 4165 comprises the following: 4167 - CAdES-BES or CAdES-EPES as defined in sections 4.2, 5.7 or 5.8; 4169 - complete-certificate-references attribute as defined in section 4170 6.2.1; 4172 - complete-revocation-references attribute as defined in section 4173 6.2.2; 4175 - time-stamped-certs-crls-references attribute as defined in section 4176 6.3.6. 4178 The following attributes are required if a TSP is not providing a time- 4179 mark of the ES: 4181 - signature-time-stamp attribute as defined in section 6.1.1. 4183 If attributes certificates are used then the following attributes may 4184 be present: 4186 - attribute-certificate-references attribute defined in section 4187 6.2.3; 4189 - attribute-revocation-references attribute as defined in section 4190 6.2.4. 4192 Other unsigned attributes may be present, but are not required. 4194 +----------------------- CAdES-X-Type 2 -----------------------------+ 4195 |+-------------------------------------- CAdES-C --+ | 4196 || +----------+ | | 4197 ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | | | 4198 ||| ||over | | | 4199 |||+---------++----------++---------+||digital | | +-------------+ | 4200 |||| || || |||Signature | | | Timestamp | | 4201 ||||Signer's || Signed || Digital ||| | | | only over | | 4202 ||||Document ||Attributes||signature|||Optional | | | Complete | | 4203 |||| || || |||when | | | certificate | | 4204 |||+---------++----------++---------+||Timemarked| | | and | | 4205 ||+----------------------------------++----------+ | | revocation | | 4206 || +-----------+| | references | | 4207 || |Complete || +-------------+ | 4208 || |certificate|| | 4209 || |and || | 4210 || |revocation || | 4211 || |references || | 4212 || +-----------+| | 4213 |+-------------------------------------------------+ | 4214 | | 4215 +--------------------------------------------------------------------+ 4217 Figure B.3 : Illustration of CAdES-X Type 2 4219 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 4221 An Electronic Signature with the additional validation data forming the 4222 CAdES-X Long Type 1 and CAdES-X Long Type 2 is illustrated in 4223 figure B.4 and comprises the following: 4225 - CAdES-BES or CAdES-EPES as defined in sections 4.3, 5.7 or 5.8; 4227 - complete-certificate-references attribute as defined in section 4228 6.2.1; 4230 - complete-revocation-references attribute as defined in section 4231 6.2.2; 4233 The following attributes are required if a TSP is not providing a time- 4234 mark of the ES: 4236 - signature-time-stamp attribute as defined in section 6.1.1. 4238 The following attributes are required if the full certificate values 4239 and revocation values are not already included in the CAdES-BES or 4240 CAdES-EPES: 4241 - certificate-values attribute as defined in section 6.3.3; 4242 - revocation-values attribute, as defined in section 6.3.4. 4244 If attributes certificates are used then the following attributes may 4245 be present: 4247 - attribute-certificate-references attribute defined in section 4248 6.2.3; 4250 - attribute-revocation-references attribute as defined in section 4251 6.2.4. 4253 Plus one of the following attributes is required: 4255 - CAdES-C-Timestamp attribute, as defined in section 6.3.5; 4256 - time-stamped-certs-crls-references attribute as defined in section 4257 6.3.6. 4259 Other unsigned attributes may be present, but are not required. 4261 +---------------------- CAdES-X-Type 1 or 2 ------------------------+ 4262 | +--------------+| 4263 |+-------------------------------------- CAdES-C --+|+------------+|| 4264 || +----------+ ||| Timestamp ||| 4265 ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | ||| over ||| 4266 ||| ||over | ||| CAdES-C ||| 4267 |||+---------++----------++---------+||digital | | +------------+ | 4268 |||| || || |||signature | || or || 4269 ||||Signer's || Signed || Digital ||| | ||+------------+|| 4270 ||||Document ||Attributes||Signature|||Optional | ||| Timestamp ||| 4271 |||| || || |||when | ||| only over ||| 4272 |||+---------++----------++---------+||timemarked| ||| complete ||| 4273 ||+----------------------------------++----------+ ||| certificate||| 4274 || ||| and ||| 4275 || +-----------+||| revocation ||| 4276 || |Complete |||| references ||| 4277 || |certificate|||+------------+|| 4278 || |and ||+--------------+| 4279 || |revocation || +------------+ | 4280 || |references || |Complete | | 4281 || +-----------+| |certificate | | 4282 |+-------------------------------------------------+ | and | | 4283 | |revocation | | 4284 | | values | | 4285 | +------------+ | 4286 +-------------------------------------------------------------------+ 4288 Figure B.4 : Illustration of CAdES-X Long Type 1 4289 and CAdES-X Long Type 2 4291 B.2 Timestamp extensions 4293 Each instance of time-stamp attribute may include as unsigned 4294 attributes in the signedData of the timestamp the following attribute 4295 related to the TSU: 4297 - complete-certificate-references attribute of the TSU as defined 4298 in section 6.2.1; 4300 - complete-revocation-references attribute of the TSU as defined in 4301 section 6.2.2; 4303 - certificate-values attribute; of the TSU as defined in section 4304 6.3.3; 4306 - revocation-values attribute, of the TSU as defined in section 4307 6.3.4. 4309 Other unsigned attributes may be present, but are not required. 4311 B.3 Archive validation data (CAdES-A) 4313 Before the algorithms, keys and other cryptographic data used at the 4314 time the CAdES-C was built become weak and the cryptographic functions 4315 become vulnerable, or the certificates supporting previous time-stamps 4316 expires, the signed data, the CAdES-C and any additional information 4317 (i.e. any CAdES-X) should be time-stamped. If possible this should use 4318 stronger algorithms (or longer key lengths) than in the original time- 4319 stamp. This additional data and time-stamp is called Archive 4320 Validation Data required for the ES Archive format (CAdES-A). The 4321 Time-stamping process may be repeated every time the protection used to 4322 time-stamp a previous CAdES-A becomes weak. An CAdES-A may thus bear 4323 multiple embedded time stamps. 4325 An example of an Electronic Signature (ES), with the additional 4326 validation data for the CAdES-C and CAdES-X forming the CAdES-A is 4327 illustrated in figure B.5. 4329 +--------------------------- CAdES-A---------------------------------+ 4330 |+----------------------------------------------------+ | 4331 || +--------------+| +----------+ | 4332 ||+--------------------- CAdES-C ----+|+------------+|| | | | 4333 ||| +----------+ ||| Timestamp ||| | | | 4334 |||+-- CAdES-BES ------+|Timestamp | ||| over ||| | | | 4335 |||| or CAdES-EPES ||over | ||| CAdES-C ||| | Archive | | 4336 |||| ||digital | ||+------------+|| | | | 4337 |||| ||signature | || or || |Timestamp | | 4338 |||| || | ||+------------+|| | | | 4339 |||| ||optional | ||| Timestamp ||| | | | 4340 |||| ||when | ||| only over ||| | | | 4341 |||| ||timemarked| ||| complete ||| | | | 4342 |||+-------------------++----------+ ||| certificate||| +----------+ | 4343 ||| ||| and ||| | 4344 ||| +-------------+||| revocation ||| | 4345 ||| | Complete |||| references ||| | 4346 ||| | certificate |||+------------+|| | 4347 ||| | and ||+--------------+| | 4348 ||| | revocation || +------------+ | | 4349 ||| | references || |Complete | | | 4350 ||| +-------------+| |certificate | | | 4351 ||+----------------------------------+ | and | | | 4352 || |revocation | | | 4353 || | values | | | 4354 || +------------+ | | 4355 |+----------------------------------------------------+ | 4356 +--------------------------------------------------------------------+ 4358 Figure B.5 : Illustration of CAdES-A 4360 The CAdES-A comprises the following elements: 4362 - the CAdES-BES or CAdES-EPES including their signed and unsigned 4363 attributes; 4365 - complete-certificate-references attribute as defined in section 4366 6.2.1; 4368 - complete-revocation-references attribute as defined in section 4369 6.2.2. 4371 The following attributes are required if a TSP is not providing a time- 4372 mark of the ES: 4373 - signature-time-stamp attribute as defined in section 6.1.1. 4375 If attributes certificates are used then the following attributes may 4376 be present: 4378 - attribute-certificate-references attribute defined in section 4379 6.2.3; 4380 - attribute-revocation-references attribute as defined in section 4381 6.2.4. 4383 The following attributes are required if the full certificate values 4384 and revocation values are not already included in the CAdES-BES or 4385 CAdES-EPES: 4387 - certificate-values attribute as defined in section 6.3.3; 4388 - revocation-values attribute as defined in section 6.3.4. 4390 At least one of the following two attributes is required: 4392 - CAdES-C-Timestamp attribute as defined in section 6.3.5; 4394 - time-stamped-certs-crls-references attribute as defined in section 4395 6.3.6. 4397 The following attribute is required: 4399 - archive-time-stamp attributes defined in section 6.4.1. 4401 Several instances of archive-time-stamp attribute may occur with an 4402 electronic signature both over time and from different TSUs. The time- 4403 stamp should be created using stronger algorithms (or longer key 4404 lengths) than in the original electronic signatures or time-stamps. 4406 Other unsigned attributes of the ES may be present, but are not 4407 required. 4409 The archive timestamp will itself contain the certificate and 4410 revocation information required to validate the archive timestamp, this 4411 may include the following unsigned attributes: 4413 - complete-certificate-references attribute of the TSU as defined 4414 in section 6.2.1; 4416 - complete-revocation-references attribute of the TSU as defined in 4417 section 6.2.2; 4419 - certificate-values attribute of the TSU as defined in section 4420 6.3.3; 4422 - revocation-values attribute of the TSU as defined in section 4423 6.3.4. 4425 Other unsigned attributes may be present, but are not required. 4427 B.4 Example validation sequence 4429 As described earlier the signer or initial verifier may collect all the 4430 additional data that forms the electronic signature. Figure B.6, and 4431 subsequent description, describes how the validation process may build 4432 up a complete electronic signature over time. 4434 +------------------------------------------ CAdES-C -------------+ 4435 |+------------------------------- CAdES-T ------+ | 4436 ||+-------------- CAdES ------------+ | | 4437 |||+--------------------++---------+|+---------+| +-----------+ | 4438 |||| ________ || |||Timestamp|| |Complete | | 4439 |||||Sign.Pol| ||Digital |||over || |certificate| | 4440 ||||| Id. | Signed ||signature|||digital || | and | | 4441 ||||| option.|attributes|| |||signature|| |revocation | | 4442 |||||________| |+---------+|+---------+| |references | | 4443 |||+--------------------+ | ^ | +-----------+ | 4444 ||+---------------------------------+ | | ^ | 4445 || 1 | / | | | 4446 |+---------------------- | ------------/--------+ | | 4447 +----------------------- | ---------- / --------------- / -------+ 4448 | /2 ----3-------- 4449 +----------+ | / / 4450 | | v / | 4451 | Signer's | +---------------------+ +-------------+ 4452 | document |----->| Validation Process |---->|- Valid | 4453 | | +---------------------+ 4 |- Invalid | 4454 +----------+ | ^ | ^ |- Validation | 4455 v | v | | Incomplete | 4456 +---------+ +--------+ +-------------+ 4457 |Signature| |Trusted | 4458 | Policy | |Service | 4459 | Issuer | |Provider| 4460 +---------+ +--------+ 4462 Figure B.6 : Illustration of a CAdES validation sequence 4464 Soon after receiving the Electronic Signature (CAdES) from the signer 4465 (1), the digital signature value may be checked; the validation process 4466 shall at least add a time-stamp (2), unless the signer has provided one 4467 which is trusted by the verifier. The validation process may also 4468 validate the electronic signature, using additional data (e.g. 4469 certificates, CRL, etc.) provided by trusted service providers. When 4470 applicable, the validation process will also need to conform to the 4471 requirements specified in a signature policy. If the validation 4472 process is validation incomplete, then the output from this stage is 4473 the CAdES-T. 4475 To ascertain the validity status as Valid or Invalid and communicate 4476 that to the user (4) all the additional data required to validate the 4477 CAdES-C, must be available (e.g. the complete certificate and 4478 revocation information). 4480 Once the data needed to complete validation data references (CAdES-C) 4481 is available then the validation process should: 4483 - obtain all the necessary additional certificate and revocation 4484 status information; 4486 - complete all the validation checks on the ES, using the complete 4487 certificate and revocation information (if a time-stamp is not 4488 already present, this may be added at the same stage combining 4489 CAdES-T and CAdES-C process); 4491 - record the complete certificate and revocation references (3); 4493 - indicate the validity status to the user (4). 4495 At the same time as the validation process creates the CAdES-C, the 4496 validation process may provide and/or record the values of certificates 4497 and revocation status information used in CAdES-C, called the CAdES-X 4498 Long (5). 4500 This is illustrated in figure B.7. 4502 +----------------------------------------------------- CAdES-X Long -+ 4503 |+------------------------------- CAdES-C -------------+ | 4504 ||+-------------- CAdES ------------+ | | 4505 |||+--------------------++---------+|+---------+ |+-----------+| 4506 |||| ________ || |||Timestamp| ||Complete || 4507 |||||Sign.Pol| ||Digital |||over | ||certificate|| 4508 ||||| Id. | Signed ||signature|||digital | || and || 4509 ||||| option.|attributes|| |||signature| ||revocation || 4510 |||||________| || ||+---------+ || values || 4511 |||+--------------------++---------+| ^ +-----------+|+-----------+| 4512 ||+---------------------------------+ | |Complete || ^ | 4513 || | | |certificate|| | | 4514 || | 2 | | and || | | 4515 || | | |revocation || | | 4516 || | | |references || | | 4517 || 1 | / +-----------+| | | 4518 |+------------------------ | ------- / --------- ^-----+ / | 4519 +------------------------- | ------ / ---------- |--------- / -------+ 4520 | / ----- / ------- / 4521 +----------+ | / / 3 / 5 4522 | | v | | | 4523 | Signer's | +--------------------+ +-----------+ 4524 | document |----->| Validation Process |----->| - Valid | 4525 | | +--------------------+ 4 | - Invalid | 4526 +----------+ | ^ | ^ +-----------+ 4527 v | v | 4528 +---------+ +--------+ 4529 |Signature| |Trusted | 4530 | Policy | |Service | 4531 | Issuer | |Provider| 4532 +---------+ +--------+ 4534 Figure B.7 : Illustration of a CAdES validation sequence 4535 with CAdES-X Long 4537 When the validation process creates the CAdES-C it may also create 4538 extended forms of validation data. 4540 A first alternative is to time-stamp all data forming the CAdES-X Type 4541 1 (6). 4543 This is illustrated in figure B.8. 4545 +------------------------------------------------ CAdES-X Type 1 -----+ 4546 |+------------------------------- CAdES-C ------------------+ | 4547 ||+-------------- CAdES ------------+ | | 4548 |||+--------------------++---------+|+---------++----------+|+-------+| 4549 |||| ________ || |||Timestamp|| Complete ||| || 4550 |||||Sign.Pol| ||Digital |||over || cert. |||Time- || 4551 ||||| Id. | Signed ||signature|||digital || and |||stamp || 4552 ||||| option.|attributes|| |||signature|| revoc. ||| over || 4553 |||||________| |+---------+|+---------+|references|||CAdES-C|| 4554 |||+--------------------+ | ^ | ||| || 4555 ||+---------------------------------+ | +----------+|+-------+| 4556 || | | ^ | ^ | 4557 || 1 | / | | | | 4558 |+------------------------ | --------- / ----------- / -----+ | | 4559 +------------------------- | -------- / ----------- / --------- / ----+ 4560 | 2 / ---3---- / 4561 +----------+ | / / -----------5------ 4562 | | v | | / 4563 | Signer's | +--------------------+ +-----------+ 4564 | document |----->| Validation Process |-----> | - Valid | 4565 | | +--------------------+ 4 | - Invalid | 4566 +----------+ | ^ | ^ +-----------+ 4567 v | v | 4568 +---------+ +--------+ 4569 |Signature| |Trusted | 4570 | Policy | |Service | 4571 | Issuer | |Provider| 4572 +---------+ +--------+ 4574 Figure B.8 : Illustration of CAdES with eXtended Validation Data 4575 CAdES-X Type 1 4577 Another alternative is to time-stamp the certificate and revocation 4578 information references used to validate the electronic signature (but 4579 not the signature) (6'); this is called CAdES-X Type 2. 4581 This is illustrated in figure B.9. 4583 +-------------------------------------------- CAdES-X Type 2 --------+ 4584 |+------------------------------- CAdES-C -------------+ | 4585 ||+-------------- CAdES ------------+ | | 4586 |||+--------------------++---------+|+---------+ |+-----------+| 4587 |||| ________ || |||Timestamp| ||Timestamp || 4588 |||||Sign.Pol| || |||over | || over || 4589 ||||| Id. | Signed ||Digital |||digital | ||complete || 4590 ||||| option.|attributes||signature|||signature| ||certificate|| 4591 |||||________| || ||| | || || 4592 |||+--------------------++---------+|+---------+ || and || 4593 ||+---------------------------------+ ^ +-----------+||revocation || 4594 || | | |Complete |||references || 4595 || | | |certificate||+-----------+| 4596 || | | | and || ^ | 4597 || 1 | 2 | |revocation || | | 4598 || | | |references || | | 4599 || | | +-----------+| | | 4600 |+------------------------ | --------- | --- ^ --------+ | | 4601 | | | 3 | / | 4602 | | | / ---------- | 4603 | | / / / 5 | 4604 | | / / / | 4605 | | / / / | 4606 +------------------------- | ----- | -- | -- / ----------------------+ 4607 | | | | 4608 v | | | 4609 +--------------------+ +-----------+ 4610 | Validation Process |----->| - Valid | 4611 +--------------------+ 4 | - Invalid | 4612 | ^ | ^ +-----------+ 4613 v | v | 4614 +---------+ +--------+ 4615 |Signature| |Trusted | 4616 | Policy | |Service | 4617 | Issuer | |Provider| 4618 +---------+ +--------+ 4620 Figure B.9: Illustration of CAdES with eXtended Validation Data 4621 CAdES-X Type 2 4623 Before the algorithms used in any of electronic signatures become or 4624 are likely, to be compromised or rendered vulnerable in the future, it 4625 may be necessary to time-stamp the entire electronic signature, 4626 including all the values of the validation and user data as an ES with 4627 Archive Validation Data (CAdES-A) (7). 4629 An CAdES-A is illustrated in figure B.10. 4631 +----------------------------- CAdES-A ---------------------------+ 4632 | | 4633 | +-- CAdES-X Long Type 1 or 2 ----------+ | 4634 | | | +------------+ | 4635 | | | | | | 4636 | | | | Archive | | 4637 | | | | Time-stamp | | 4638 | | | | | | 4639 | | | +------------+ | 4640 | +---------------------------------------+ ^ | 4641 | +----------+ ^ ^ ^ ^ | | 4642 | | | | | | | / | 4643 | | Signers' | | | | | / | 4644 | | Document |\ | | | | / | 4645 | | | \ 1 2 | 3 | 5 | 6 | 7 / | 4646 | +----------+ \ | | | | / | 4647 | \ | | | | / | 4648 +----------------- \ --- | - | - | - | ------ / ------------------+ 4649 \ | | | | | 4650 | | | | | | 4651 | | | | | | 4652 v v | | | | 4653 +-----------------------------+ +-----------+ 4654 | Validation Process |----->| - Valid | 4655 +-----------------------------+ 4 | - Invalid | 4656 | ^ | ^ +-----------+ 4657 v | v | 4658 +---------+ +--------+ 4659 |Signature| |Trusted | 4660 | Policy | |Service | 4661 | Issuer | |Provider| 4662 +---------+ +--------+ 4664 Figure B.10: Illustration of CAdES-A 4666 B.5 Additional optional features 4668 The present document also defines additional optional features to: 4670 - indicate a commitment type being made by the signer; 4672 - indicate the claimed time when the signature was done; 4674 - indicate the claimed location of the signer; 4676 - indicate the claimed or certified role under which a signature 4677 was created; 4679 - support counter signatures; 4681 - support multiple signatures. 4683 Annex C (informative):General description 4685 This annex explains some of the concepts and provides the rational for 4686 normative parts of the present document. 4688 The specification below includes a description why and when the each 4689 component of an electronic signature is useful, with a brief 4690 description of the vulnerabilities and threats and the manner by which 4691 they are countered. 4693 C.1 The signature policy 4695 The signature policy is a set of rules for the creation and validation 4696 of an electronic signature, under which the signature can be determined 4697 to be valid. A given legal/contractual context may recognize a 4698 particular signature policy as meeting its requirements. A signature 4699 policy may be issued, for example, by a party relying on the electronic 4700 signatures and selected by the signer for use with that relying party. 4701 Alternatively, a signature policy may be established through an 4702 electronic trading association for use amongst its members. Both the 4703 signer and verifier use the same signature policy. 4705 The signature policy may be explicitly identified or may be implied by 4706 the semantics of the data being signed and other external data like a 4707 contract being referenced which itself refers to a signature policy. 4708 An explicit signature policy has a globally unique reference, which is 4709 bound to an electronic signature by the signer as part of the signature 4710 calculation. 4712 The signature policy needs to be available in human readable form so 4713 that it can be assessed to meet the requirements of the legal and 4714 contractual context in which it is being applied. To facilitate the 4715 automatic processing of an electronic signature the parts of the 4716 signature policy which specifies the electronic rules for the creation 4717 and validation of the electronic signature also needs to be 4718 comprehensively defined and in a computer processable form. 4720 The signature policy thus includes the following: 4722 - rules, which apply to technical validation of a particular 4723 signature; 4725 - rules which may be implied through adoption of Certificate 4726 Policies that apply to the electronic signature (e.g. rules for 4727 ensuring the secrecy of the private signing key); 4729 - rules, which relate to the environment used by the signer, e.g. 4730 the use of an agreed CAD (Card Accepting Device) used in 4731 conjunction with a smart card. 4733 For example, the major rules required for technical validation can 4734 include: recognized root keys or "top-level certification authorities", 4735 acceptable certificate policies (if any), necessary certificate 4736 extensions and values (if any), the need for the revocation status for 4737 each component of the certification tree, acceptable TSAs (if time- 4738 stamp tokens are being used), acceptable organizations for keeping the 4739 audit trails with time-marks (if time-marking is being used), 4740 acceptable AAs (if any are being used).as well as rules defining the 4741 components of the electronic signature that shall be provided by the 4742 signer with data required by the verifier when required to provide long 4743 term proof. 4745 C.2 Signed information 4747 The information being signed may be defined as a MIME-encapsulated 4748 message which can be used to signal the format of the content in order 4749 to select the right display or application. It can be composed of 4750 formatted data, free text or fields from an electronic form (e-form). 4751 For example, the Adobe(tm) format "pdf" may be used or the eXtensible 4752 Mark up Language (XML). Annex D defines how the content may be 4753 structured to indicate the type of signed data using MIME. 4755 C.3 Components of an electronic signature 4757 C.3.1 Reference to the signature policy 4759 When two independent parties want to evaluate an electronic signature, 4760 it is fundamental that they get the same result. This requirement can 4761 be met using comprehensive signature policies that ensure consistency 4762 of signature validation. Signature policies can be identified 4763 implicitly by the data being signed or they can be explicitly 4764 identified using the CAdES-EPES form of electronic signature, the 4765 CAdES-EPES mandates a consistent signature policy must be used by both 4766 the signer and verifier. 4768 By signing over the signature policy identifier in the CAdES-EPES the 4769 signer explicitly indicates that he or she has applied the signature 4770 policy in creating the signature. 4772 In order to unambiguously identify the details of an explicit signature 4773 policy that is to be used to verify a CAdES-EPES the signature an 4774 identifier and hash of the "Signature policy" shall be part of the 4775 signed data. Additional information about the explicit policy (e.g. 4776 web reference to the document) may be carried as "qualifiers" to the 4777 signature policy identifier. 4779 In order to unambiguously identify the authority responsible for 4780 defining an explicit signature policy the "Signature policy" can be 4781 signed. 4783 C.3.2 Commitment type indication 4785 The commitment type can be indicated in the electronic signature 4786 either: 4788 - explicitly using a "commitment type indication" in the electronic 4789 signature; 4791 - implicitly or explicitly from the semantics of the signed data. 4793 If the indicated commitment type is explicit using a "commitment type 4794 indication" in the electronic signature, acceptance of a verified 4795 signature implies acceptance of the semantics of that commitment type. 4796 The semantics of explicit commitment types indications may be subject 4797 to signer and verifier agreement, specified as part of the signature 4798 policy or registered for generic use across multiple policies. 4800 If a CAdES-EPES electronic signature format is used and the electronic 4801 signature includes a commitment type indication other than one of those 4802 recognized under the signature policy the signature shall be treated as 4803 invalid. 4805 How commitment is indicated using the semantics of the data being 4806 signed is outside the scope of the present document. 4808 NOTE: Examples of commitment indicated through the semantics of the 4809 data being signed, are: 4811 - an explicit commitment made by the signer indicated by the type 4812 of data being signed over. Thus, the data structure being signed 4813 can have an explicit commitment within the context of the 4814 application (e.g. EDIFACT purchase order); 4816 - an implicit commitment which is a commitment made by the signer 4817 because the data being signed over has specific semantics 4818 (meaning) which is only interpretable by humans, (i.e. free 4819 text). 4821 C.3.3 Certificate identifier from the signer 4823 In many real life environments users will be able to get from different 4824 CAs or even from the same CA, different certificates containing the 4825 same public key for different names. The prime advantage is that a 4826 user can use the same private key for different purposes. Multiple use 4827 of the private key is an advantage when a smart card is used to protect 4828 the private key, since the storage of a smart card is always limited. 4829 When several CAs are involved, each different certificate may contain a 4830 different identity, e.g. as a national or as an employee from a 4831 company. Thus when a private key is used for various purposes, the 4832 certificate is needed to clarify the context in which the private key 4833 was used when generating the signature. Where there is the possibility 4834 that multiple private keys are used, it is necessary for the signer to 4835 indicate to the verifier the precise certificate to be used. 4837 Many current schemes simply add the certificate after the signed data 4838 and thus are vulnerable to substitution attacks. If the certificate 4839 from the signer was simply appended to the signature and thus not 4840 protected by the signature, any one could substitute one certificate by 4841 another and the message would appear to be signed by some one else. In 4842 order to counter this kind of attack, the identifier of the signer has 4843 to be protected by the digital signature from the signer. 4845 In order to identify unambiguously the certificate to be used for the 4846 verification of the signature an identifier of the certificate from the 4847 signer shall be part of the signed data. 4849 C.3.4 Role attributes 4851 While the name of the signer is important, the position of the signer 4852 within a company or an organization of paramount importance as well. 4853 Some information (i.e. a contract) may only be valid if signed by a 4854 user in a particular role, e.g. a Sales Director. In many cases who 4855 the sales Director really is, is not that important but being sure that 4856 the signer is empowered by his company to be the Sales Director is 4857 fundamental. 4859 The present document defines two different ways for providing this 4860 feature: 4862 - by placing a claimed role name in the CMS signed attributes 4863 field; 4865 - by placing an attribute certificate containing a certified role 4866 name in the CMS signed attributes field. 4868 NOTE: Another possible approach would have been to use additional 4869 attributes containing the roles name(s) in the signer's 4870 identity certificate However, it was decided not to follow 4871 this approach as it significantly complicates the management 4872 of certificates. For example by using separate certificates 4873 for signer's identity and roles means new identity keys need 4874 not be issued if a user's role changes. 4876 C.3.4.1 Claimed role 4878 The signer may be trusted to state his own role without any certificate 4879 to corroborate this claim. In which case the claimed role can be added 4880 to the signature as a signed attribute. 4882 C.3.4.2 Certified role 4884 Unlike public key certificates that bind an identifier to a public key, 4885 Attribute Certificates bind the identifier of a certificate to some 4886 attributes, like a role. An Attribute Certificate is NOT issued by a 4887 CA but by an Attribute Authority (AA). The Attribute Authority in most 4888 cases might be under the control of an organization or a company that 4889 is best placed to know which attributes are relevant for which 4890 individual. The Attribute Authority may use or point to public key 4891 certificates issued by any CA, provided that the appropriate trust may 4892 be placed in that CA. Attribute Certificates may have various periods 4893 of validity. That period may be quite short, e.g. one day. While this 4895 requires that a new Attribute Certificate be obtained every day, valid 4896 for that day, this can be advantageous since revocation of such 4897 certificates may not be needed. When signing, the signer will have to 4898 specify which Attribute Certificate it selects. In order to do so, the 4899 Attribute Certificate will have to be included in the signed data in 4900 order to be protected by the digital signature from the signer. 4902 In order to identify unambiguously the attribute certificate(s) to be 4903 used for the verification of the signature an identifier of the 4904 attribute certificate(s) from the signer shall be part of the signed 4905 data. 4907 C.3.5 Signer location 4909 In some transactions the purported location of the signer at the time 4910 he or she applies his signature may need to be indicated. For this 4911 reason an optional location indicator shall be able to be included. 4913 In order to provide indication of the location of the signer at the 4914 time he or she applied his signature a location attribute may be 4915 included in the signature. 4917 C.3.6 Signing time 4919 The present document provides the capability to include a claimed 4920 signing time as an attribute of an electronic signature. 4922 Using this attribute a signer may sign over a time which is the claimed 4923 signing time. When an ES with Time-stamp is created (CAdES-T) then 4924 either a trusted time stamp is obtained and added to the ES or a 4925 trusted time mark exists in an audit trail. When a verifier accepts a 4926 signature, the two times shall be within acceptable limits. 4928 A further optional attribute is defined in the present document to 4929 timestamp the content, to provide proof of the existence of the 4930 content, at the time indicated by the time-stamp token. 4932 Using this optional attribute a trusted secure time may be obtained 4933 before the document is signed and included under the digital signature. 4934 This solution requires an on-line connection to a trusted time-stamping 4935 service before generating the signature and may not represent the 4936 precise signing time, since it can be obtained in advance. However, 4937 this optional attribute may be used by the signer to prove that the 4938 signed object existed before the date included in the time-stamp (see 4939 section 5.11.4). 4941 C.3.7 Content format 4943 When presenting signed data to a human user it may be important that 4944 there is no ambiguity as to the presentation of the signed information 4945 to the relying party. In order for the appropriate representation 4946 (text, sound or video) to be selected by the relying party when data 4947 (as opposed to data which has been further signed or encrypted) 4948 is encapsulated in the SignedData (indicated by the eContentType 4949 within EncapsulatedContentInfo being set to id-data), further typing 4950 information should be used to identify the type of document being 4951 signed. This is generally achieved using the MIME content typing and 4952 encoding mechanism defined in RFC 2045 [6]). Further information on 4953 the use of MIME is given in Annex F. 4955 C.3.8 Content hints 4957 The contents hints attribute provides information on the innermost 4958 signed content of a multilayer message where one content is 4959 encapsulated in another. This may be useful if the signed data is 4960 itself encrypted. 4962 C.3.9 Content cross referencing 4964 When presenting a signed data is in related to another signed data, it 4965 may be important to identify the signed data to which it relates to. 4966 The Content-reference and Content-identifier attributes as defined in 4967 ESS (RFC 2634 [5]) provide the ability to link a request and reply 4968 messages in an exchange between two parties. 4970 C.4 Components of validation data 4972 C.4.1 Revocation status information 4974 A verifier will have to ascertain that the certificate of the signer 4975 was valid at the time of the signature. This can be done by either: 4977 - using Certificate Revocation Lists (CRLs); 4979 - using responses from an on-line certificate status server (for 4980 example; obtained through the OCSP protocol). 4982 NOTE 1: The time of the signature may not be know, so time-stamping 4983 or time-marking may be used to provide the time indication of 4984 when it was known the signature existed. 4986 NOTE 2: When validating an electronic signature and checking 4987 revocation status information a "grace period" is required 4988 which needs to be suitably long enough to allow the involved 4989 authority to process a "last minute" revocation request and 4990 for the request to propagate through the revocation system. 4991 This grace period is to be added to the time included with the 4992 timestamp token or the time mark and thus the revocation 4993 status information should be captured after the end of the 4994 grace period. 4996 C.4.1.1 CRL information 4998 When using CRLs to get revocation information, a verifier will have to 4999 make sure that he or she gets at the time of the first verification the 5000 appropriate certificate revocation information from the signer's CA. 5001 This should be done as soon as possible to minimize the time delay 5002 between the generation and verification of the signature. However, a 5003 "grace period" is required to allow CAs time to process revocation 5004 requests. 5006 For example, a revocation request may arrive at a CA just before 5007 issuing the next CRL and there may not enough time to include the 5008 revised revocation status information. This involves checking that the 5009 signer certificate serial number is not included in the CRL. The 5010 signer, the initial or subsequent verifier may obtain either this CRL. 5011 If obtained by the signer, then it shall be conveyed to the verifier. 5012 It may be convenient to archive the CRL for ease of subsequent 5013 verification or arbitration. Alternatively, provided the CRL is 5014 archived elsewhere which is accessible for the purpose of arbitration, 5015 then the serial number of the CRL used may be archived together with 5016 the verified electronic signature as an CAdES-C form. 5018 Even if the certificate serial number appears in the CRL with the 5019 status "suspended" (i.e. on hold), the signature is not to be deemed as 5020 valid since a suspended certificate is not supposed to be used even by 5021 its rightful owner. 5023 C.4.1.2 OCSP information 5025 When using OCSP to get revocation information, a verifier will have to 5026 make sure that he or she gets at the time of the first verification an 5027 OCSP response that contains the status "valid". This should be done as 5028 soon as possible after the generation of the signature, still providing 5029 a "grace period" suitable enough to allow the involved authority to 5030 process a "last minute" revocation request The signer, the verifier or 5031 any other third party may fetch this OCSP response. Since OCSP 5032 responses are transient and thus are not archived by any TSP including 5033 CA, it is the responsibility of every verifier to make sure that it is 5034 stored in a safe place. The simplest way is to store them associated 5035 with the electronic signature. An alternative would be to store them 5036 in some storage so that they can then be easily retrieved, and 5037 incorporate references to them in the electronic signature itself as an 5038 CAdES-C form. 5040 In the same way as for the case of the CRL, it may happen that the 5041 certificate is declared as invalid but with the secondary status 5042 "suspended". In such a case, same comment as for CRL applies. 5044 C.4.2 Certification path 5046 A verifier may have to ascertain that the certification path was valid, 5047 at the time of the signature, up to a trust point according to the: 5049 - naming constraints; 5050 - certificate policy constraints; 5051 - Signature Policy, when applicable. 5053 Since the time of the signature cannot be known with certainty, an 5054 upper limit of it should be used as indicated by either the time stamp 5055 or time mark. 5057 In this case it will be necessary to capture all the certificates from 5058 the certification path, starting with those from the signer and ending 5059 up with those of the self-signed certificate from one trusted root, 5060 when applicable this may be specified as part of the Signature Policy. 5061 In addition, it will be necessary to capture the Certificate Authority 5062 Revocation Lists (CARLs) to prove than none of the CAs from the chain 5063 was revoked at the time of the signature. Again, all this material may 5064 be incorporated in the electronic signature (ES X forms). An 5065 alternative would be to store it in some storage so that they can it be 5066 easily retrieved, and incorporate references to it in the electronic 5067 signature itself as a CAdES-C form. 5069 C.4.3 Time-stamping for long life of signatures 5071 An important property for long standing signatures is that a signature, 5072 having been found once to be valid, shall continue to be so months or 5073 years later. 5075 A signer, verifier or both may be required to provide on request, proof 5076 that a digital signature was created or verified during the validity 5077 period of the all the certificates that make up the certificate path. 5078 In this case, the signer, verifier or both will also be required to 5079 provide proof that the signer's certificate and all the CA certificates 5080 used to form a valid certification path were not revoked when the 5081 signature was created or verified. 5083 It would be quite unacceptable, to consider a signature as invalid even 5084 if the keys or certificates were later compromised. Thus there is a 5085 need to be able to demonstrate that the signature keys was valid at the 5086 time that the signature was created to provide long term evidence of 5087 the validity of a signature. 5089 It could be the case that a certificate was valid at the time of the 5090 signature but revoked some time later. In this event, evidence shall 5091 be provided that the document was signed before the signing key was 5092 revoked. Time-stamping by a Time-Stamping Authority (TSA) can provide 5093 such evidence. A time stamp is obtained by sending the hash value of 5094 the given data to the TSA. The returned "time-stamp" is a signed 5095 document that contains the hash value, the identity of the TSA, and the 5096 time of stamping. This proves that the given data existed before the 5097 time of stamping. Time-stamping a digital signature (by sending a hash 5098 of the signature to the TSA) before the revocation of the signer's 5099 private key, provides evidence that the signature has been created 5100 before the key was revoked. 5102 If a recipient wants to hold a valid electronic signature he will have 5103 to ensure that he has obtained a valid time stamp for it, before that 5104 key (and any key involved in the validation) is revoked. The sooner 5105 the time-stamp is obtained after the signing time, the better. Any 5106 time stamp or time mark that is taken after the expiration date of any 5107 certificate in the certification path has no value in proving the 5108 validity of a signature. 5110 It is important to note that signatures may be generated "off-line" and 5111 time-stamped at a later time by anyone, for example by the signer or 5112 any recipient interested in the value of the signature. The time stamp 5113 can thus be provided by the signer together with the signed document, 5114 or obtained by the recipient following receipt of the signed document. 5116 The time stamp is NOT a component of the Basic Electronic Signature, 5117 but the essential component of the ES with Time-stamp. 5119 It is required in the present document that if a signer's digital 5120 signature value is to be time-stamped, the Time-Stamp Token is issued 5121 by a trusted source, known as a Time-stamping Authority. 5123 The present document requires that the signer's digital signature value 5124 is time-stamped by a trusted source before the electronic signature can 5125 become an ES with Complete validation data. Acceptable TSAs may be 5126 specified in a Signature Validation Policy. 5128 This technique is referred to as CAdES-C in the present document. 5129 Should both the signer and verifier be required to time-stamp the 5130 signature value to meet the requirements of the signature policy, the 5131 signature policy may specify a permitted time delay between the two 5132 time stamps. 5134 C.4.4 Time-stamping for long life of signature before CA key 5135 compromises 5137 Time-stamped extended electronic signatures are needed when there is a 5138 requirement to safeguard against the possibility of a CA key in the 5139 certificate chain ever being compromised. A verifier may be required 5140 to provide on request, proof that the certification path and the 5141 revocation information used a the time of the signature were valid, 5142 even in the case where one of the issuing keys or OCSP responder keys 5143 is later compromised. 5145 The present document defines two ways of using time-stamps to protect 5146 against this compromise: 5148 - time-stamp the ES with Complete validation data, when an OCSP 5149 response is used to get the status of the certificate from the 5150 signer (CAdES-X Type 1). This format is suitable to be used with 5151 an OCSP response and offers the additional advantage to provide 5152 an integrity protection over the whole data; 5154 - time-stamp only the certification path and revocation information 5155 references when a CRL is used to get the status of the 5156 certificate from the signer (CAdES-X Type2). This format is 5157 suitable to be used with CRLs, since the time-stamped information 5158 may be used for more than one signature (when signers have their 5159 certificates issued by the same CA and when signatures can be 5160 checked using the same CRLs). 5162 NOTE: The signer, verifier or both may obtain the time-stamp. 5164 C.4.4.1 Time-stamping the ES with complete validation data 5165 (CAdES-X Type 1) 5167 When an OCSP response is used, it is necessary to time stamp in 5168 particular that response in the case the key from the responder would 5169 be compromised. Since the information contained in the OCSP response 5170 is user specific and time specific, an individual time stamp is needed 5171 for every signature received. Instead of placing the time stamp only 5172 over the certification path references and the revocation information 5173 references, which include the OCSP response, the time stamp is placed 5174 on the CAdES-C. Since the certification path and revocation 5175 information references are included in the ES with Complete validation 5176 data they are also protected. For the same cryptographic price, this 5177 provides an integrity mechanism over the ES with Complete validation 5178 data. Any modification can be immediately detected. It should be 5179 noticed that other means of protecting/detecting the integrity of the 5180 ES with Complete Validation Data exist and could be used. 5181 Although the technique requires a time stamp for every signature, it is 5182 well suited for individual users wishing to have an integrity protected 5183 copy of all the validated signatures they have received. 5185 By time-stamping the complete electronic signature, including the 5186 digital signature as well as the references to the certificates and 5187 revocation status information used to support validation of that 5188 signature, the time-stamp ensures that there is no ambiguity in the 5189 means of validating that signature. 5191 This technique is referred to as CAdES-X Type 1 in the present 5192 document. 5194 NOTE: Trust is achieved in the references by including a hash of the 5195 data being referenced. 5197 If it is desired for any reason to keep a copy of the additional data 5198 being referenced, the additional data may be attached to the electronic 5199 signature, in which case the electronic signature becomes an CAdES-X 5200 Long Type 1 as defined by the present document. 5202 An CAdES-X Long Type 1 is simply the concatenation of an CAdES-X Type 1 5203 with a copy of the additional data being referenced. 5205 C.4.4.2 Time-stamping certificates and revocation information 5206 references (CAdES-X Type 2) 5208 Time-stamping each ES with Complete Validation Data as defined above 5209 may not be efficient, particularly when the same set of CA certificates 5210 and CRL information is used to validate many signatures. 5212 Time-stamping CA certificates will stop any attacker from issuing bogus 5213 CA certificates that could be claimed to exist before the CA key was 5214 compromised. Any bogus time-stamped CA certificates will show that the 5215 certificate was created after the legitimate CA key was compromised. 5216 In the same way, time-stamping CA CRLs, will stop any attacker from 5217 issuing bogus CA CRLs which could be claimed to exist before the CA key 5218 was compromised. 5220 Time-stamping of commonly used certificates and CRLs can be done 5221 centrally, e.g. inside a company or by a service provider. This method 5222 reduces the amount of data the verifier has to time-stamp, for example 5223 it could reduce to just one time stamp per day (i.e. in the case were 5224 all the signers use the same CA and the CRL applies for the whole day). 5225 The information that needs to be time stamped is not the actual 5226 certificates and CRLs but the unambiguous references to those 5227 certificates and CRLs. 5229 This technique is referred to as CAdES-X Type 2 in the present document 5230 and requires the following: 5232 - all the CA certificates references and revocation information 5233 references (i.e. CRLs) used in validating the CAdES-C are covered 5234 by one or more time-stamp. 5236 Thus an CAdES-C with a time-stamp signature value at time T1, can be 5237 proved valid if all the CA and CRL references are time-stamped at time 5238 T1+. 5240 C.4.5 Time-stamping for archive of signature 5242 Advances in computing increase the probability of being able to break 5243 algorithms and compromise keys. There is therefore a requirement to be 5244 able to protect electronic signatures against this possibility. 5246 Over a period of time weaknesses may occur in the cryptographic 5247 algorithms used to create an electronic signature (e.g. due to the time 5248 available for crypto analysis, or improvements in crypto analytical 5249 techniques). Before such weaknesses become likely, a verifier should 5250 take extra measures to maintain the validity of the electronic 5251 signature. Several techniques could be used to achieve this goal 5252 depending on the nature of the weakened cryptography. In order to 5253 simplify matters, a single technique, called Archive validation data, 5254 covering all the cases is being used in the present document. 5256 Archive validation data consists of the validation data and the 5257 complete certificate and revocation data, time stamped together with 5258 the electronic signature. The Archive validation data is necessary if 5259 the hash function and the crypto algorithms that were used to create 5260 the signature are no longer secure. Also, if it cannot be assumed that 5261 the hash function used by the Time Stamping Authority is secure, then 5262 nested time-stamps of Archived Electronic Signature are required. 5264 The potential for Trusted Service Provider (TSP) key compromise should 5265 be significantly lower than user keys, because TSP(s) are expected to 5266 use stronger cryptography and better key protection. It can be 5267 expected that new algorithms (or old ones with greater key lengths) 5268 will be used. In such a case, a sequence of time-stamps will protect 5269 against forgery. Each time-stamp needs to be affixed before either the 5270 compromise of the signing key or of the cracking of the algorithms used 5271 by the TSA. TSAs (Time-stamping Authorities) should have long keys 5272 (e.g. which at the time of drafting the present document was at least 5273 2048 bits for the signing RSA algorithm) and/or a "good" or different 5274 algorithm. 5276 Nested time-stamps will also protect the verifier against key 5277 compromise or cracking the algorithm on the old electronic signatures. 5279 The process will need to be performed and iterated before the 5280 cryptographic algorithms used for generating the previous time stamp 5281 are no longer secure. Archive validation data may thus bear multiple 5282 embedded time stamps. 5284 This technique is referred to as CAdES-A in the present document. 5286 C.4.6 Reference to additional data 5288 Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data 5289 verifiers still needs to keep track of all the components that were 5290 used to validate the signature, in order to be able to retrieve them 5291 again later on. These components may be archived by an external source 5292 like a trusted service provider, in which case referenced information 5293 that is provided as part of the ES with Complete validation data 5294 (CAdES-C) is adequate. The actual certificates and CRL information 5295 reference in the CAdES-C can be gathered when needed for arbitration. 5297 If references to additional data are not adequate, then the actual 5298 values of all the certificates and revocation information required may 5299 be part of the electronic signature. This technique is referred to as 5300 CAdES-X Long Type 1 or CAdES-X Long Type 2 in the present document. 5302 C.4.7 Time-stamping for mutual recognition 5304 In some business scenarios both the signer and the verifier need to 5305 time-stamp their own copy of the signature value. Ideally the two 5306 time-stamps should be as close as possible to each other. 5308 EXAMPLE: A contract is signed by two parties A and B representing 5309 their respective organizations, to time-stamp the signer 5310 and verifier data two approaches are possible: 5312 - under the terms of the contract pre-defined common 5313 "trusted" TSA may be used; 5315 - if both organizations run their own time-stamping 5316 services, A and B can have the transaction 5317 time-stamped by these two time-stamping services. 5319 In the latter case, the electronic signature will only be considered as 5320 valid, if both time-stamps were obtained in due time (i.e. there should 5321 not be a long delay between obtaining the two time-stamps). Thus, 5322 neither A nor B can repudiate the signing time indicated by their own 5323 time-stamping service. Therefore, A and B do not need to agree on a 5324 common "trusted" TSA to get a valid transaction. 5326 It is important to note that signatures may be generated "off-line" and 5327 time-stamped at a later time by anyone, e.g. by the signer or any 5328 recipient interested in validating the signature. The time-stamp over 5329 the signature from the signer can thus be provided by the signer 5330 together with the signed document, and/or obtained by the verifier 5331 following receipt of the signed document. 5333 The business scenarios may thus dictate that one or more of the long- 5334 term signature time-stamping methods describe above be used. This may 5335 be part of a mutually agreed Signature Validation Policy which is part 5336 of an agreed signature policy under which digital signature may be used 5337 to support the business relationship between the two parties. 5339 C.4.8 TSA key compromise 5341 TSA servers should be built in such a way that once the private 5342 signature key is installed, there is minimal likelihood of compromise 5343 over as long as possible period. Thus the validity period for the 5344 TSA's keys should be as long as possible. 5346 Both the CAdES-T and the CAdES-C contain at least one time stamp over 5347 the signer's signature. In order to protect against the compromise of 5348 the private signature key used to produce that time-stamp, the Archive 5349 validation data can be used when a different Time-Stamping Authority 5350 key is involved to produce the additional time-stamp. If it is 5351 believed that the TSA key used in providing an earlier time-stamp may 5352 ever be compromised (e.g. outside its validity period), then the CAdES- 5353 A should be used. For extremely long periods this may be applied 5354 repeatedly using new TSA keys. 5356 This technique is referred to as a nested CAdES-A in the present 5357 document. 5359 C.5 Multiple signatures 5361 Some electronic signatures may only be valid if they bear more than one 5362 signature. This is the case generally when a contract is signed 5363 between two parties. The ordering of the signatures may or may not be 5364 important, i.e. one may or may not need to be applied before the other. 5366 Several forms of multiple and counter signatures need to be supported, 5367 which fall into two basic categories: 5368 - independent signatures; 5369 - embedded signatures. 5371 Independent signatures are parallel signatures where the ordering of 5372 the signatures is not important. The capability to have more than one 5373 independent signature over the same data shall be provided. 5375 Embedded signatures are applied one after the other and are used where 5376 the order the signatures are applied is important. The capability to 5377 sign over signed data shall be provided. 5379 These forms are described in section 5.13. All other multiple signature 5380 schemes, e.g. a signed document with a countersignature, double 5381 countersignatures or multiple signatures, can be reduced to one or more 5382 occurrence of the above two cases. 5384 Annex D (informative):Data protocols to interoperate with TSPs 5386 D.1 Operational protocols 5388 The following protocols can be used by signers and verifiers to 5389 interoperate with Trusted Service Providers during the electronic 5390 signature creation and validation. 5392 D.1.1 Certificate retrieval 5394 User certificates, CA certificate and cross-certificates can be 5395 retrieved from a repository using the Lightweight Directory Access 5396 Protocol as defined in as defined RFC 2559 (RFC2559], with the schema 5397 defined in RFC 2587 [RFC2587]. 5399 D.1.2 CRL retrieval 5401 Certificate revocation lists, including authority revocation lists and 5402 partial CRL variants, can be retrieved from a repository using the 5403 Lightweight Directory Access Protocol as defined in RFC 2559 5404 [RFC2559], with the schema defined in RFC 2587 [RFC2587]. 5406 D.1.3 OnLine certificate status 5408 As an alternative to use of certificate revocation lists the status of 5409 certificate can be checked using the OnLine Certificate Status Protocol 5410 (OCSP) as defined in RFC 2560 [3]. 5412 D.1.4 Time-stamping 5414 The time-stamping service can be accessed using the Time-Stamping 5415 Protocol defined in RFC 3161 [7]. 5417 D.2 Management protocols 5419 Signers and verifiers can use the following management protocols to 5420 manage the use of certificates. 5422 D.2.1 Request for certificate revocation 5424 Request for a certificate to be revoked can be made using the 5425 revocation request and response messages defined in 5426 RFC 2510 [RFC2510]. 5428 Annex E (informative): Guidance on naming 5430 E.1 Allocation of names 5432 The subject name shall be allocated through a registration scheme 5433 administered through a Registration Authority (RA) to ensure 5434 uniqueness. This RA may be an independent body or a function carried 5435 out by the Certification Authority. 5437 In addition to ensuring uniqueness, the RA shall verify that the name 5438 allocated properly identifies the applicant and that authentication 5439 checks are carried out to protect against masquerade. 5441 The name allocated by an RA is based on registration information 5442 provided by, or relating to, the applicant (e.g. his personal name, 5443 date of birth, residence address) and information allocated by the RA. 5444 Three variations commonly exist: 5446 - the name is based entirely on registration information which 5447 uniquely identifies the applicant (e.g. "Pierre Durand (born on) 5448 July 6, 1956"); 5450 - the name is based on registration information with the addition 5451 of qualifiers added by the registration authority to ensure 5452 uniqueness (e.g. "Pierre Durand 12"); 5454 - the registration information is kept private by the registration 5455 authority and the registration authority allocates a "pseudonym". 5457 E.2 Providing access to registration information 5459 Under certain circumstances it may be necessary for information used 5460 during registration, but not published in the certificate, to be made 5461 available to third parties (e.g. to an arbitrator to resolve a dispute 5462 or for law enforcement). This registration information is likely to 5463 include personal and sensitive information. 5465 Thus the RA needs to establish a policy for: 5467 - whether the registration information should be disclosed; 5468 - to whom such information should be disclosed; 5469 - under what circumstances such information should be disclosed. 5471 This policy may be different whether the RA is being used only within a 5472 company or for public use. The policy will have to take into account 5473 national legislation and in particular any data protection and privacy 5474 legislation. 5476 Currently, the provision of access to registration is a local matter 5477 for the RA. However, if open access is required, standard protocols 5478 such as HTTP - RFC 2068 (Internet Web Access Protocol) may be employed 5479 with the addition of security mechanisms necessary to meet the data 5480 protection requirements (e.g. Transport Layer Security - RFC 2246 5481 [RFC2246] with client authentication). 5483 E.3 Naming schemes 5485 E.3.1 Naming schemes for individual citizens 5487 In some cases the subject name that is contained in a public key 5488 certificate may not be meaningful enough. This may happen because of 5489 the existence of homonyms or because of the use of pseudonyms. A 5490 distinction could be made if more attributes were present. However, 5491 adding more attributes to a public key certificate placed in a public 5492 repository would be going against the privacy protection requirements. 5494 In any case the Registration Authority will get information at the time 5495 of registration but not all that information will be placed in the 5496 certificate. In order to achieve a balance between these two opposite 5497 requirements the hash values of some additional attributes can be 5498 placed in a public key certificate. When the certificate owner 5499 provides these additional attributes, then they can be verified. Using 5500 biometrics attributes may unambiguously identify a person. Example of 5501 biometrics attributes that can be used include: a picture or a manual 5502 signature from the certificate owner. 5504 NOTE: Using hash values protects privacy only if the possible inputs 5505 are large enough. For example, using the hash of a person's 5506 social security number is generally not sufficient since it 5507 can easily be reversed. 5509 A picture can be used if the verifier once met the person and later on 5510 wants to verify that the certificate that he or she got relates to the 5511 person whom was met. In such a case, at the first exchange the picture 5512 is sent and the hash contained in the certificate may be used by the 5513 verifier to verify that it is the right person. At the next exchange 5514 the picture does not need to be sent again. 5516 A manual signature may be used if a signed document has been received 5517 beforehand. In such a case, at the first exchange the drawing of the 5518 manual signature is sent and the hash contained in the certificate may 5519 be used by the verifier to verify that it is the right manual 5520 signature. At the next exchange the manual signature does not need to 5521 be sent again. 5523 E.3.2 Naming schemes for employees of an organization 5525 The name of an employee within an organization is likely to be some 5526 combination of the name of the organization and the identifier of the 5527 employee within that organization. 5529 An organization name is usually a registered name, i.e. business or 5530 trading name used in day to day business. This name is registered by a 5531 Naming Authority, which guarantees that the organization's registered 5532 name is unambiguous and cannot be confused with another organization. 5533 In order to get more information about a given registered organization 5534 name, it is necessary to go back to a publicly available directory 5535 maintained by the Naming Authority. 5537 The identifier may be a name or a pseudonym (e.g. a nickname or a 5538 employee number). When it is a name, it is supposed to be descriptive 5539 enough to unambiguously identify the person. When it is a pseudonym, 5540 the certificate does not disclose the identity of the person. However 5541 it ensures that the person has been correctly authenticated at the time 5542 of registration and therefore may be eligible to some advantages 5543 implicitly or explicitly obtained through the possession of the 5544 certificate. In either case, however, this can be insufficient because 5545 of the existence of homonyms. 5547 Placing more attributes in the certificate may be one solution, for 5548 example by giving the organization unit of the person or the name of a 5549 city where the office is located. However the more information is 5550 placed in the certificate the more problems arise if there is a change 5551 in the organization structure or the place of work. So this may not be 5552 the best solution. An alternative is to provide more attributes (like 5553 the organization unit and the place of work) through access to a 5554 directory maintained by the company. It is likely that at the time of 5555 registration the Registration Authority got more information than what 5556 was placed in the certificate, if such additional information is placed 5557 in a repository accessible only to the organization. 5559 Annex F (informative): Example structured contents and MIME 5561 F.1 Use of MIME to encode data 5563 The signed content may be structured as using MIME (Multipurpose 5564 Internet Mail Extensions - RFC 2045 [6]. Whilst the MIME structure was 5565 initially developed for Internet e-mail, it has a number of features 5566 which make it useful to provide a common structure for encoding a range 5567 of electronic documents and other multi-media data (e.g. photographs, 5568 video). These features include: 5570 - it provides a means of signalling the type of "object" being 5571 carried (e.g. text, image, ZIP file, application data); 5573 - it provides a means of associating a file name with an object; 5575 - it can associate several independent "objects" (e.g. a document 5576 and image) to form a multi-part object; 5578 - it can handle data encoded in text or binary and, if necessary, 5579 re-encode the binary as text. 5581 When encoding a single object MIME consists of: 5583 - header information, followed by; 5584 - encoded content. 5586 This structure can be extended to support multi-part content. 5588 F.1.1 Header information 5590 A MIME header includes: 5592 MIME Version information: e.g.: MIME-Version: 1.0 5594 Content type information which includes information describing the 5595 content sufficient for it to presented to a user or application 5596 process as required. This includes information on the "media type" 5597 (e.g. text, image, audio) or whether the data is for passing to a 5598 particular type of application. In the case of text the content type 5599 includes information on the character set used, e.g. 5600 Content-Type: text/plain; charset="us-ascii" 5602 Content encoding information, which defines how the content is 5603 encoded. (See below about encoding supported by MIME). 5605 Other information about the content such as a description, or an 5606 associated file name. 5608 An example MIME header for text object is: 5610 Mime-Version: 1.0 5611 Content-Type: text/plain; charset=ISO-8859-1 5612 Content-Transfer-Encoding: quoted-printable 5613 An example MIME header for a binary file containing a pdf document is: 5615 Content-Type: application/pdf 5616 Content-Transfer-Encoding: base64 5617 Content-Description: JCFV201.pdf 5618 Content-Disposition: filename="JCFV201.pdf" 5620 F.1.2 Content encoding 5622 MIME supports a range of mechanisms for encoding the both text and 5623 binary data. 5625 Text data can be carried transparently as lines of text data encoded 5626 in 7 or 8 bit ASCII characters. MIME also includes a 5627 "quoted-printable" encoding which converts characters other than the 5628 basic ASCII into an ASCII sequence. 5630 Binary can either be carried: 5632 - transparently a 8 bit octets; or 5633 - converted to a basic set of characters using a system called 5634 Base64. 5636 NOTE: As there are some mail relays which can only handle 7 bit 5637 ASCII, Base64 encoding is usually used on the Internet. 5639 F1.3 Multi-part content 5641 Several objects (e.g. text and a file attachment) can be associated 5642 together using a special "multi-part" content type. This is indicated 5643 by the content type "multipart" with an indication of the string to be 5644 used indicate a separation between each part. 5646 In addition to a header for the overall multipart content, each part 5647 includes its own header information indicating the inner content type 5648 and encoding. 5650 An example of a multipart content is: 5652 Mime-Version: 1.0 5653 Content-Type: multipart/mixed; boundary="---- 5654 =_NextPart_000_01BC4599.98004A80" 5655 Content-Transfer-Encoding: 7bit 5657 ------=_NextPart_000_01BC4599.98004A80 5658 Content-Type: text/plain; charset=ISO-8859-1 5659 Content-Transfer-Encoding: 7bit 5661 Per your request, I've attached our proposal for the Java Card Version 5662 2.0 API and the Java Card FAQ. 5664 ------=_NextPart_000_01BC4599.98004A80 5665 Content-Type: application/pdf; name="JCFV201.pdf" 5666 Content-Transfer-Encoding: base64 5667 Content-Description: JCFV201.pdf 5668 Content-Disposition: attachment; filename="JCFV201.pdf" 5670 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA 5671 AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// 5672 //////////AANhAAQAYg== 5674 ------=_NextPart_000_01BC4599.98004A80-- 5676 Multipart content can be nested. So a set of associated objects (e.g. 5677 HTML text and images) can be handled as a single attachment to another 5678 object (e.g. text). 5680 The Content-Type from each part of the S/MIME message indicates the 5681 type of content. 5683 F.2 S/MIME 5685 The specific use of MIME to carry CMS (extended as defined in the 5686 present document) secured data is called S/MIME (see [RFC3851]). 5688 S/MIME carries electronic signatures as either: 5690 - an "application/pkcs7-mime" object with the CMS carried as binary 5691 attachment (PKCS7 is the name of the early version of CMS). 5693 The signed data may be included in the SignedData, which itself 5694 may be included in a single S/MIME object. See [RFC3851], 5695 section 3.4.2 �Signing Using application/pkcs7-mime with 5696 SignedData� and figure F.1 hereafter. 5698 or 5700 - a "multipart/signed" object with the signed data and the 5701 signature encoded as separate MIME objects. 5703 The signed data is not included in the SignedData, and the CMS 5704 structure only includes the signature. See [RFC3851], 5705 section 3.4.3 �Signing Using the multipart/signed Format� and 5706 figure F.2 hereafter. 5708 +-------------++----------++-------------++------------+ 5709 | || || || | 5710 | S/MIME || CAdES || MIME || pdf file | 5711 | || || || | 5712 |Content-Type=||SignedData||Content-Type=||Dear MrSmith| 5713 |application/ || eContent ||application/ ||Received | 5714 |pkcs7-mime || ||pdf || 100 tins | 5715 | || || || | 5716 |smime-type= || /| || /| || Mr.Jones | 5717 |signed-data || / -----+ / ------+ | 5718 | || \ -----+ \ ------+ | 5719 | || \| || \| |+------------+ 5720 | || |+-------------+ 5721 | |+----------+ 5722 +-------------+ 5724 Figure F.1 Signing Using application/pkcs7-mime 5726 F.2.1 Using application/pkcs7-mime 5728 This approach is similar to handling signed data as any other binary 5729 file attachment. 5731 An example of signed data encoded using this approach is: 5733 Content-Type: application/pkcs7-mime; smime-type=signed-data; 5734 Content-Transfer-Encoding: base64 5735 Content-Disposition: attachment; filename=smime.p7m 5737 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 5738 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 5739 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 5740 6YT64V0GhIGfHfQbnj75 5742 F.2.1 Using application/pkcs7-signature 5744 CMS also supports an alternative structure where the signature and 5745 data being protected are separate MIME objects carried within a single 5746 message. In this case the signed data is not included in the 5747 SignedData, and the CMS structure only includes the signature. See 5748 [RFC3851], section 3.4.3 �Signing Using the multipart/signed Format� 5749 and figure F.2 herafter. 5751 An example of signed data encoded this approach is: 5753 Content-Type: multipart/signed; 5754 protocol="application/pkcs7-signature"; 5755 micalg=sha1; boundary=boundary42 5757 --boundary42 5758 Content-Type: text/plain 5760 This is a clear-signed message. 5762 --boundary42 5764 Content-Type: application/pkcs7-signature; name=smime.p7s 5765 Content-Transfer-Encoding: base64 5766 Content-Disposition: attachment; filename=smime.p7s 5768 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 5769 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 5770 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 5771 7GhIGfHfYT64VQbnj756 5773 --boundary42-- 5775 With this second approach MIME the signed data passes through the CMS 5776 process and is carried as part of a muliple parts signed MIME 5777 structure as illustrated in figure F.2. The CMS structure just holds 5778 the electronic signature. 5780 +---------------++----------++-------------++------------+ 5781 | || || || | 5782 | MIME || CAdES || MIME || pdf file | 5783 | || || || | 5784 |Content-Type= ||SignedData||Content-Type=||Dear MrSmith| 5785 |multipart/ || ||application/ ||Received | 5786 |signed || ||pdf || 100 tins | 5787 | /| || || || | 5788 | / -------------------+ /| || Mr.Jones | 5789 | \ -------------------+ / -----+ | 5790 | \| || || \ -----+ | 5791 |Content-Type= || || \| |+------------+ 5792 |application/ || |+-------------+ 5793 |pdf || | 5794 | || | |Content-Type= || | 5795 |application/ || | 5796 |pkcs7-signature|| | 5797 | || | 5798 | /| || | 5799 | / -------+ | 5800 | \ -------+ | 5801 | \| ||----------+ | | 5802 +---------------+ 5804 Figure F.2. Signing Using application/pkcs7-signature 5806 This second approach (multipart/signed) has the advantage that the 5807 signed data can be decoded by any MIME compatible system even if 5808 it does not recognize CMS encoded electronic signatures. 5810 Annex G (informative): Relationship to the European Directive and EESSI 5812 G.1 Introduction 5814 This annex provides an indication of the relationship between 5815 electronic signatures created under the present document and 5816 requirements under the European Parliament and Council Directive on a 5817 Community framework for electronic signatures. 5819 NOTE: Legal advice should be sought on the specific national 5820 legislation regarding use of electronic signatures. 5822 The present document is one of a set of standards being defined under 5823 the "European Electronic Signature Standardization Initiative" (EESSI) 5824 for electronic signature products and solutions compliant with the 5825 European Directive for electronic signatures. 5827 G.2 Electronic signatures and the directive 5829 This directive defines electronic signatures as: 5831 - "data in electronic form which are attached to or logically 5832 associated with other electronic data and which serve as a method 5833 of authentication". 5835 The directive states that an electronic signature should not be denied 5836 "legal effectiveness and admissibility as evidence in legal 5837 proceedings" solely on the grounds that it is in electronic form. 5839 The directive identifies an electronic signature as having equivalence 5840 to a hand-written signature if it meets specific criteria: 5841 - it is an "advanced electronic signature" with the following 5842 properties: 5844 a) it is uniquely linked to the signatory; 5846 b) it is capable of identifying the signatory; 5848 c) it is created using means that the signatory can maintain 5849 under his sole control; and 5851 d) it is linked to the data to which it relates in such a 5852 manner that any subsequent change of the data is detectable. 5854 - it is based on a certificate which meets detailed criteria given 5855 in annex I to the directive and is issued by a "certification- 5856 service-provider" which meets requirements given in annex II to 5857 the directive. Such a certificate is referred to as a "qualified 5858 certificate"; 5860 - it is created by a "device" which detailed criteria given in 5861 annex III to the directive. Such a device is referred to a 5862 "secure-signature-creation device"; 5864 This form of electronic signature is referred to as a "qualified 5865 electronic signature" in EESSI (see below). 5867 G.3 ETSI electronic signature formats and the directive 5869 An electronic signature created in accordance with the present document 5870 is: 5872 a) considered to be an "electronic signature" under the terms of 5873 the Directive; 5875 b) considered to be an "advanced electronic signature" under the 5876 terms of the Directive; 5878 c) considered to be a "Qualified Electronic Signature" provided the 5879 additional requirements in annex I, II and III of the Directive 5880 are met. The requirements in annex I, II and III of the 5881 Directive are outside the scope of the present document, and are 5882 subject to further standardization. 5884 G.4 EESSI standards and classes of electronic signature 5886 G.4.1 Structure of EESSI standardization 5888 EESSI looks at standards in several areas. See the ETSI ESI and CEN 5889 web sites for the latest list of standards and their versions 5891 - use of X.509 public key certificates as qualified certificates; 5893 - security Management and Certificate Policy for CSPs Issuing 5894 Qualified Certificates; 5896 - security requirements for trustworthy systems used by CSPs 5897 Issuing Qualified Certificates; 5899 - security requirements for Secure Signature Creation Devices; 5901 - security requirements for Signature Creation Systems; 5903 - procedures for Electronic Signature Verification; 5905 - electronic signature syntax and encoding formats; 5907 - protocol to interoperate with a Time Stamping Authority; 5909 - Policy requirements for Time-Stamping Authorities; 5911 - XML electronic signature formats. 5913 Each of these standards addresses a range of requirements including 5914 the requirements of Qualified Electronic Signatures as specified in 5915 article 5.1 of the Directive. However, some of them also address 5916 general requirements of electronic signatures for business and 5917 electronic commerce which all fall into the category of article 5.2 of 5918 the Directive. Such variation in the requirements may be identified 5919 either as different levels or different options. 5921 G.4.2 Classes of electronic signatures 5923 Since some of these standards address a range of requirements, it may 5924 be useful to identify a set of standards to address a specific 5925 business need. Such a set of standards and their uses defines a class 5926 of electronic signature. The first class already identified is the 5927 qualified electronic signature, fulfilling the requirements of article 5928 5.1 of the Directive. 5930 A limited number of "classes of electronic signatures" and 5931 corresponding profiles could be defined by EESSI, in close 5932 co-operation with actors on the market (business, users, suppliers). 5933 Need for such standards is envisaged, in addition to those for 5934 qualified electronic signatures, in areas such as: 5936 - different classes of electronic signatures with long term 5937 validity; 5939 - electronic signatures for business transactions with limited 5940 value. 5942 G.4.3 EESSI classes and the ETSI electronic signature format 5943 The electronic signature format defined in the present document is 5944 applicable to the EESSI area "electronic signature and encoding 5945 formats". 5947 An electronic signature produced by a signer (see section 5 and 5948 conformance section 10.1) is applicable to the proposed class of 5949 electronic signature: "qualified electronic signatures fulfilling 5950 article 5.1". 5952 With the addition of validation data by the verifier (see section 6 5953 and conformance section 10.2) this would become applicable electronic 5954 signatures adding long-term validity attributes to the qualified 5955 electronic signature. 5957 Annex H (informative):APIs for the generation and verification of 5958 electronic signatures tokens 5960 While the present document describes the data format of an electronic 5961 signature, the question is whether there exists APIs (Application 5962 Programming Interfaces) able to manipulate these structures. At least 5963 two such APIs have been defined. One set by the IETF and another set 5964 by the OMG (Object Management Group). 5966 H.1 Data framing 5968 In order to be able to use either of these APIs, it will be necessary 5969 to frame the previously defined electronic signature data structures 5970 using a mechanism-independent token format. Section 3.1 of RFC 2743 5971 [RFC2743] describes that framing incorporating an identifier of the 5972 mechanism type to be used and enabling tokens to be interpreted 5973 unambiguously. 5975 In order to be processable by these APIs, all electronic signature data 5976 formats that are defined in the present document shall be framed 5977 following that description. 5979 The encoding format for the token tag is derived from ASN.1 and DER, 5980 but its concrete representation is defined directly in terms of octets 5981 rather than at the ASN.1 level in order to facilitate interoperable 5982 implementation without use of general ASN.1 processing code. The token 5983 tag consists of the following elements, in order: 5985 1) 0x60 -- Tag for RFC 2743 SEQUENCE; indicates that constructed 5986 form, definite length encoding follows. 5988 2) Token length octets, specifying length of subsequent data (i.e. 5989 the summed lengths of elements 3 to 5 in this list, and of the 5990 mechanism-defined token object following the tag). This element 5991 comprises a variable number of octets: 5993 a) If the indicated value is less than 128, it shall be 5994 represented in a single octet with bit 8 (high order) set to 5995 "0" and the remaining bits representing the value. 5997 b) If the indicated value is 128 or more, it shall be represented 5998 in two or more octets, with bit 8 of the first octet set to 5999 "1" and the remaining bits of the first octet specifying the 6000 number of additional octets. The subsequent octets carry the 6001 value, 8 bits per octet, most significant digit first. The 6002 minimum number of octets shall be used to encode the length 6003 (i.e. no octets representing leading zeros shall be included 6004 within the length encoding). 6006 3) 0x06 -- Tag for OBJECT IDENTIFIER. 6008 4) Object identifier length -- length (number of octets) of the 6009 encoded object identifier contained in element 5, encoded per 6010 rules as described in 2a) and 2b) above. 6012 5) object identifier octets -- variable number of octets, encoded 6013 per ASN.1 BER rules: 6015 - The first octet contains the sum of two values: 6017 (1) the top-level object identifier component, multiplied by 6018 40 (decimal); and 6020 (2) the second-level object identifier component. 6022 This special case is the only point within an object 6023 identifier encoding where a single octet represents contents 6024 of more than one component. 6026 - Subsequent octets, if required, encode successively-lower 6027 components in the represented object identifier. A 6028 component's encoding may span multiple octets, encoding 7 bits 6029 per octet (most significant bits first) and with bit 8 set to 6030 "1" on all but the final octet in the component's encoding. 6031 The minimum number of octets shall be used to encode each 6032 component (i.e. no octets representing leading zeros shall be 6033 included within a component's encoding). 6035 NOTE: In many implementations, elements 3 to 5 may be stored and 6036 referenced as a contiguous string constant. 6038 The token tag is immediately followed by a mechanism-defined token 6039 object. Note that no independent size specifier intervenes following 6040 the object identifier value to indicate the size of the mechanism- 6041 defined token object. 6043 Tokens conforming to the present document shall have the following OID 6044 in order to be processable by IDUP-APIs: 6046 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 6047 { itu-t(0) identified-organization(4) etsi(0) 6048 electronic-signature-standard (1733) part1 (1) IDUPMechanism (4) 6049 etsiESv1(1) } 6051 H.2 IDUP-GSS-APIs defined by the IETF 6053 The IETF CAT WG has produced in December 1998 an RFC (RFC 2479 6054 [RFC2479]) under the name of IDUP-GSS-API (Independent Data Unit 6055 Protection) able to handle the electronic signature data format 6056 defined in the present document. 6058 The IDUP-GSS-API includes support for non-repudiation services. 6060 It supports evidence generation, where "evidence" is information that 6061 either by itself, or when used in conjunction with other information, 6062 is used to establish proof about an event or action, as well a evidence 6063 verification. 6065 IDUP supports various types of evidences. All the types defined in 6066 IDUP are supported in the present document through the commitment type 6067 parameter. 6069 Section 2.3.3 of IDUP describes the specific calls needed to handle 6070 evidences ("EV" calls). The "EV" group of calls provides a simple, 6071 high-level interface to underlying IDUP mechanisms when application 6072 developers need to deal only with evidences but not with encryption or 6073 integrity services. 6075 All generations and verification are performed according to the content 6076 of a NR policy that is referenced in the context. 6078 Get_token_details is used to return to an application the attributes 6079 that correspond to a given input token. Since IDUP-GSS- API tokens are 6080 meant to be opaque to the calling application, this function allows the 6081 application to determine information about the token without having to 6082 violate the opaqueness intention of IDUP. Of primary importance is the 6083 mechanism type, which the application can then use as input to the 6084 IDUP_Establish_Env() call in order to establish the correct environment 6085 in which to have the token processed. 6087 Generate_token generates a non-repudiation token using the current 6088 environment. 6090 Verify_evidence verifies the evidence token using the current 6091 environment. This operation returns a major_status code which can be 6092 used to determine whether the evidence contained in a token is complete 6093 (i.e. can be successfully verified (perhaps years) later). If a 6094 token's evidence is not complete, the token can be passed to another 6095 API: form_complete_pidu to complete it. This happens when a status 6096 "conditionally valid" is returned. That status corresponds to the 6097 status "validation incomplete" of the present document. 6099 Form_complete_PIDU is used primarily when the evidence token itself 6100 does not contain all the data required for its verification and it is 6101 anticipated that some of the data not stored in the token may become 6102 unavailable during the interval between generation of the evidence 6103 token and verification unless it is stored in the token. The 6104 Form_Complete_PIDU operation gathers the missing information and 6105 includes it in the token so that verification can be guaranteed to be 6106 possible at any future time. 6108 H.3 CORBA security interfaces defined by the OMG 6110 Non-repudiation interfaces have been defined in "CORBA Security", a 6111 document produced by the OMG (Object Management Group). These 6112 interfaces are described in IDL (Interface Definition Language) and are 6113 optional. 6115 The handling of "tokens" supporting non-repudiation is done through the 6116 following interfaces: 6118 - set_NR_features specifies the features to apply to future 6119 evidence generation and verification operations; 6121 - get_NR_features returns the features which will be applied to 6122 future evidence generation and verification operations; 6124 - generate_token generates a Non-repudiation token using the 6125 current Non-repudiation features; 6127 - verify_evidence verifies the evidence token using the current 6128 Non-repudiation features; 6130 - get_tokens_details returns information about an input Non- 6131 repudiation token. The information returned depends upon the 6132 type of token; 6134 - form_complete_evidence is used when the evidence token itself 6135 does not contain all the data required for its verification, and 6136 it is anticipated that some of the data not stored in the token 6137 may become unavailable during the interval between generation of 6138 the evidence token and verification unless it is stored in the 6139 token. The form_complete_evidence operation gathers the missing 6140 information and includes it in the token so that verification can 6141 be guaranteed to be possible at any future time. 6143 NOTE: The similarity between the two sets of APIs is noticeable. 6145 Annex I (informative):Cryptographic algorithms 6147 RFC 3370 [10] describes the conventions for using several cryptographic 6148 algorithms with the Crytographic Message Syntax (CMS). Only the 6149 hashing and signing algorithms are appropriate for use with the present 6150 document. 6152 Since the publication of RFC 3370 [10], MD5 has been broken. This 6153 algorithm is no more considered as appropriate and has been deleted 6154 from the list of algorithms. 6156 I.1 Digest algorithms 6158 I.1.1 SHA-1 6160 The SHA-1 digest algorithm is defined in FIPS Pub 180-1. The algorithm 6161 identifier for SHA-1 is: 6163 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) 6164 secsig(3) algorithm(2) 26 } 6166 The AlgorithmIdentifier parameters field is optional. If present, the 6167 parameters field shall contain an ASN.1 NULL. Implementations should 6168 accept SHA-1 AlgorithmIdentifiers with absent parameters as well as 6169 NULL parameters. Implementations should generate SHA-1 6170 AlgorithmIdentifiers with NULL parameters. 6172 I.1.2 General 6174 The following is a selection of work that has been done in the area of 6175 digest algorithms or, as they are often called, hash functions: 6177 - ISO/IEC 10118-1 (1994) [ISO10118-1]: "Information technology - 6178 Security techniques - Hash-functions - Part 1: General". 6179 ISO/IEC 10118-1 contains definitions and describes basic concepts. 6181 - ISO/IEC 10118-2 (1994) [ISO10118-2]: "Information technology - 6182 Security techniques - Hash-functions - Part 2: Hash-functions 6183 using an n-bit block cipher algorithm". ISO/IEC 10118-2 specifies 6184 two ways to construct a hash-function from a block cipher. 6186 - ISO/IEC 10118-3 (1997) [ISO10118-3]: "Information technology - 6187 Security techniques - Hash-functions - Part 3: Dedicated 6188 hash-functions". ISO/IEC 10118-3 specifies the following 6189 dedicated hash-functions: 6191 - SHA-1 (FIPS 180-1); 6192 - RIPEMD-128; 6193 - RIPEMD-160. 6195 - ISO/IEC 10118-4 (1998) [ISO10118-4]: "Information technology - 6196 Security techniques - Hash-functions - Part 4: Hash-functions 6197 using modular arithmetic". 6199 - RFC 1320 (PS 1992): "The MD4 Message-Digest Algorithm". RFC 1320 6200 specifies the hash-function MD4. Today, MD4 is considered out- 6201 dated. 6203 - RFC 1321 (I 1992): "The MD5 Message-Digest Algorithm". RFC 1321 6204 (informational) specifies the hash-unction MD5. Today, MD5 is 6205 not recommended for new implementations. 6207 - FIPS Publication 180-1 (1995): "Secure Hash Standard". FIPS 180-1 6208 specifies the Secure Hash Algorithm (SHA), dedicated hash- 6209 function developed for use with the DSA. The original SHA 6210 published in 1993 was slightly revised in 1995 and renamed SHA-1. 6212 - ANSI X9.30-2 (1997) [X9.30-2]: "Public Key Cryptography for the 6213 Financial Services Industry - Part 2: The Secure Hash Algorithm 6214 (SHA-1)". X9.30-2 specifies the ANSI-Version of SHA-1. 6216 - ANSI X9.31-2 (1996) [X9.31-2]: "Public Key Cryptography Using 6217 Reversible Algorithms for the Financial Services Industry � 6218 Part 2: Hash Algorithms". X9.31-2 specifies hash algorithms. 6220 I.2 Digital signature algorithms 6222 I.2.1 DSA 6224 The DSA signature algorithm is defined in FIPS Pub 186. DSA is always 6225 used with the SHA-1 message digest algorithm. The algorithm identifier 6226 for DSA is: 6228 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 6229 x9-57 (10040) x9cm(4) 3 } 6231 The AlgorithmIdentifier parameters field shall not be present. 6233 I.2.2 RSA 6235 The RSA signature algorithm is defined in RFC 2437 [RFC2437]. 6236 RFC 3370 [10] specifies the use of the RSA signature algorithm with 6237 the SHA-1 algorithm. The algorithm identifier for RSA with SHA-1 is: 6239 Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 6240 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 6242 NOTE: RFC 3370 [10] recommends that MD5 is not used for new 6243 implementations. 6245 I.2.3 General 6247 The following is a selection of work that has been done in the area of 6248 digital signature mechanisms: 6250 - FIPS Publication 186 (1994): "Digital Signature Standard". 6251 NIST's Digital Signature Algorithm (DSA) is a variant of 6252 ElGamal's Discrete Logarithm based digital signature mechanism. 6253 The DSA requires a 160-bit hash-function and mandates SHA-1. 6255 - IEEE P1363 (2000) [P1363]: "Standard Specifications for 6256 Public-Key Cryptography". IEEE P1363 contains mechanisms for 6257 digital signatures, key establishment, and encipherment based on 6258 three families of public-key schemes: 6260 - "Conventional" Discrete Logarithm (DL) based techniques, i.e. 6261 Diffie-Hellman (DH) key agreement, Menezes-Qu-Vanstone (MQV) 6262 key agreement, the Digital Signature Algorithm (DSA), and 6263 Nyberg-Rueppel (NR) digital signatures; 6265 - Elliptic Curve (EC) based variants of the DL-mechanisms 6266 specified above, i.e. EC-DH, EC-MQV, EC-DSA, and EC-NR. For 6267 elliptic curves, implementation options include mod p and 6268 characteristic 2 with polynomial or normal basis 6269 representation; 6271 - Integer Factoring (IF) based techniques including RSA 6272 encryption, RSA digital signatures, and RSA-based key 6273 transport. 6275 - ISO/IEC 9796 (1991) [ISO9796]: "Information technology - Security 6276 techniques - Digital signature scheme giving message recovery". 6277 ISO/IEC 9796 specifies a digital signature mechanism based on the 6278 RSA public-key technique and a specifically designed redundancy 6279 function. 6281 - ISO/IEC 9796-2 (1997) [ISO9796-2]: "Information technology - 6282 Security techniques - Digital signature schemes giving message 6283 recovery - Part 2: Mechanisms using a hash-function". 6284 ISO/IEC 9796-2 specifies digital signature mechanisms with 6285 partial message recovery that are also based on the RSA technique 6286 but make use of a hash-function. 6288 - ISO/IEC 9796-4 (1998) [ISO9796-4]: "Digital signature schemes 6289 giving message recovery - Part 4: Discrete logarithm based 6290 mechanisms". ISO/IEC 9796-4 specifies digital signature 6291 mechanisms with partial message recovery that are based on 6292 Discrete Logarithm techniques. The document includes the 6293 Nyberg-Rueppel scheme. 6295 - ISO/IEC 14888-1 [ISO14888-1]: "Digital signatures with appendix - 6296 Part 1: General". ISO/IEC 14888-1 contains definitions and 6297 describes the basic concepts of digital signatures with appendix. 6299 - ISO/IEC 14888-2 [ISO14888-2]: "Digital signatures with appendix - 6300 Part 2: Identity-based mechanisms". ISO/IEC 14888-2 specifies 6301 digital signature schemes with appendix that make use of 6302 identity-based keying material. The document includes the 6303 zero-knowledge techniques of Fiat-Shamir and Guillou-Quisquater. 6305 - ISO/IEC 14888-3 [ISO14888-3]: "Digital signatures with appendix - 6306 Part 3: Certificate-based mechanisms". ISO/IEC 14888-3 specifies 6307 digital signature schemes with appendix that make use of 6308 certificate-based keying material. The document includes five 6309 schemes: 6311 - DSA; 6312 - EC-DSA, an elliptic curve based analog of NIST's Digital 6313 Signature Algorithm; 6314 - Pointcheval-Vaudeney signatures; 6315 - RSA signatures; 6316 - ESIGN. 6318 - ISO/IEC 15946-2 (2002) [ISO15946-2]: "Cryptographic techniques 6319 based on elliptic curves - Part 2: Digital signatures". 6321 - ISO/IEC 15946-3 (2002) [ISO 15946-3] specifies digital signature 6322 schemes with appendix using elliptic curves. 6324 - The document includes two schemes: 6326 - EC-DSA, an elliptic curve based analog of NIST's Digital 6327 Signature Algorithm; 6329 - EC-AMV, an elliptic curve based analog of the Agnew-Muller- 6330 Vanstone signature algorithm. 6332 - ANSI X9.31-1 (1997) [X9.31-1]: "Public Key Cryptography Using 6333 Reversible Algorithms for the Financial Services Industry � 6334 Part 1: The RSA Signature Algorithm". ANSI X9.31-1 specifies a 6335 digital signature mechanism with appendix using the RSA 6336 public-key technique. 6338 - ANSI X9.30-1 (1997) [X9.30-1]: "Public Key Cryptography Using 6339 Irreversible Algorithms for the Financial Services Industry � 6340 Part 1: The Digital Signature Algorithm (DSA)". ANSI X9.30-1 6341 specifies the DSA, NIST's Digital Signature Algorithm. 6343 - ANSI X9.62 (1998) [X9.62]: "Public Key Cryptography for the 6344 Financial Services Industry - The Elliptic Curve Digital 6345 Signature Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic 6346 Curve Digital Signature Algorithm, an analog of NIST's Digital 6347 Signature Algorithm (DSA) using elliptic curves. The appendices 6348 provide tutorial information on the underlying mathematics for 6349 elliptic curve cryptography and many examples. 6351 Annex J (informative): Changes from the previous version 6353 The title of the document has changed to be aligned with the title 6354 of XAdES (XML Advanced Electronic Signatures), the vocabulary used 6355 within the present document has been aligned with the vocabulary 6357 used in XAdES, 6359 If the hash of the signature policy is unknown, then, by 6360 convention, the sigPolicyHash shall be set to all zeros. 6362 The OIDs from the ASN.1 modules have changed for the following 6363 reasons: 6365 - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have been 6366 included. 6368 - since RFC 2459 and RFC 3852 has been obsoleted by RFC 3280 and 6369 RFC 3852 respectively, there was the need to refer to the OIDs 6370 of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the 6371 OIDs of the ASN.1 modules of RFC 2459 and RFC 3852. 6373 - other changes are related to the addition of the signing- 6374 certificate attribute, where the ESS signing-certificate 6375 attribute defined in RFC 2634, shall be used if the SHA-1 6376 hashing algorithm is used, while the ESS signing-certificate 6377 attribute v2, defined in �ESS Update: Adding CertID Algorithm 6378 Agility RFC 5035 shall be used when other hashing algorithms 6379 are to be used. 6381 - the definition of the Archive time-stamp attribute has been 6382 changed in section 6.4.1. to protect all signed and unsined 6383 attributes. A new object identifier has been assigned to this 6384 attribute. 6386 Full Copyright Statement 6388 Copyright (C) The IETF Trust (2007). 6390 This document is subject to the rights, licenses and restrictions 6391 contained in BCP 78, and except as set forth therein, the authors 6392 retain all their rights. 6394 This document and the information contained herein are provided on 6395 An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 6396 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 6397 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 6398 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 6399 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 6400 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 6401 FOR A PARTICULAR PURPOSE. 6403 Intellectual Property 6405 The IETF takes no position regarding the validity or scope of any 6406 Intellectual Property Rights or other rights that might be claimed 6407 to pertain to the implementation or use of the technology described 6408 in this document or the extent to which any license under such 6409 rights might or might not be available; nor does it represent that 6410 it has made any independent effort to identify any such rights. 6411 Information on the procedures with respect to rights in RFC 6412 documents can be found in BCP 78 and BCP 79. 6414 Copies of IPR disclosures made to the IETF Secretariat and any 6415 assurances of licenses to be made available, or the result of an 6416 attempt made to obtain a general license or permission for the use 6417 of such proprietary rights by implementers or users of this 6418 specification can be obtained from the IETF on-line IPR repository 6419 at http://www.ietf.org/ipr. 6421 The IETF invites any interested party to bring to its attention any 6422 copyrights, patents or patent applications, or other proprietary 6423 rights that may cover technology that may be required to implement 6424 this standard. Please address the information to the IETF at 6425 ietf-ipr@ietf.org. 6427 ETSI takes no position regarding the validity or scope of any 6428 Intellectual Property Rights or other rights that might be claimed 6429 to pertain to the implementation or use of the technology described 6430 in this document or the extent to which any license under such 6431 rights might or might not be available; nor does it represent that 6432 it has made any independent effort to identify any such rights. 6434 Information on the ETSI Intellectual Property Rights Policy may be 6435 obtained from . The document is 6436 an extract from Annex 6 of the ETSI Rules of Procedure that are 6437 available at : . 6439 The ETSI IPR database http://webapp.etsi.org/IPR/home.asp contains 6440 IPRs, particularly patents and patent applications, which have been 6441 notified to ETSI as being essential, or potentially essential, to 6442 ETSI standards. Unless otherwise specified, all IPRs contained 6443 herein have been notified to ETSI, with an undertaking from the 6444 owner to grant licenses according to the terms and conditions of 6445 Article 6.1 of Annex 6 of the ETSI Rules of the ETSI IPR Policy. 6447 The ETSI IPR database provides data that is based on the information 6448 received. ETSI has not checked the validity of the information, nor 6449 the relevance of the identified patents/patent applications to the 6450 ETSI Standards and cannot confirm, or deny, that the patents/patent 6451 applications are, in fact, essential, or potentially essential. No 6452 investigation, or IPR searches, have been carried out by ETSI and 6453 therefore no guarantee can be given concerning the existence of 6454 other IPRs which are, or may become, essential. 6456 Potential Licensees should use the information in this database at 6457 their discretion and should contact the patent holder. 6459 Acknowledgements 6461 Funding for the RFC Editor function is currently provided by the 6462 Internet Society. 6464 Funding for the publication of the previous RFC has been provided 6465 by ETSI and the European Commision.