idnits 2.17.1 draft-ietf-smime-cades-00.txt: 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 6254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6267. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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 is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 2005) is 6679 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 3800, but not defined ** 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) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group J.Ross(Security and Standards) 2 INTERNET-DRAFT N.Pope(Security and Standards) 3 Expires June 2006 D.Pinkas(Bull) 4 Obsoletes: RFC 3126 December 2005 5 Target Category: Informational 7 CMS Advanced Electronic Signatures (CAdES) 8 < draft-ietf-smime-cades-00.txt> 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document may not be modified, and derivative works of it may 34 not be created, except to publish it as an RFC and to translate it 35 into languages other than English. 37 Abstract 39 This document defines the format of an electronic signature that can 40 remain valid over long periods. This includes evidence as to its 41 validity even if the signer or verifying party later attempts to deny 42 (i.e., repudiates the validity of the signature). The format can be 43 considered as an extension to RFC 3369 and RFC 2634, where, when 44 appropriate additional signed and unsigned attributes have been 45 defined. The contents of this Informational RFC amounts to a 46 transposition of the ETSI TS 101 733 V.1.6.3 (CMS Advanced 47 Electronic Signatures - CAdES) and is technically equivalent to it. 49 Table of Contents 51 1. Introduction 6 53 2. Scope 6 55 3. Definitions and abbreviations 8 56 3.1 Definitions 8 57 3.2 Abbreviations 11 59 4. Overview 12 60 4.1 Major parties 12 61 4.2 Signatures policies 14 62 4.3 Electronic signature formats 14 63 4.3.1 CAdES Basic Electronic Signature (CAdES-BES) 14 64 4.3.2 CAdES Explicit Policy Electronic Signatures (CAdES-EPES) 17 65 4.4 Electronic signature formats with validation data 18 66 4.4.1 Electronic Signature with Time (CAdES-T) 19 67 4.4.2 ES with Complete validation data references (CAdES-C) 20 68 4.4.3 Extended electronic signature formats 22 69 4.4.4 Archival Electronic Signature (CAdES-A) 26 70 4.5 Arbitration 27 71 4.6 Validation process 28 73 5. Electronic signature attributes 29 74 5.1 General syntax 29 75 5.2 Data content type 29 76 5.3 Signed-data content type 29 77 5.4 SignedData type 30 78 5.5 EncapsulatedContentInfo type 30 79 5.6 SignerInfo type 30 80 5.6.1 Message digest calculation process 31 81 5.6.2 Message signature generation process 31 82 5.6.3 Message signature verification process 31 83 5.7 Basic ES mandatory present attributes 31 84 5.7.1 Content type 31 85 5.7.2 Message digest 31 86 5.7.3 Signing certificate reference attribute 31 87 5.8 Additional mandatory attributes for Explicit Policy-based 88 Electronic Signatures 33 89 5.8.1 Signature policy identifier 33 90 5.9 CMS imported optional attributes 35 91 5.9.1 Signing time 35 92 5.9.2 Countersignature 35 93 5.10 ESS imported optional attributes 36 94 5.10.1 Content reference attribute 36 95 5.10.2 Content identifier attribute 36 96 5.10.3 Content hints attribute 36 97 5.11 Additional optional attributes defined in the present document 37 98 5.11.1 Commitment type indication attribute 37 99 5.11.2 Signer location attribute 39 100 5.11.3 Signer attributes attribute 40 101 5.11.4 Content time-stamp 40 102 5.12 Support for multiple signatures 41 103 5.12.1 Independent signatures 41 104 5.12.2 Embedded signatures 41 106 6. Additional Electronic Signature validation attributes 41 107 6.1 Electronic Signature Time-stamped (CAdES-T) 43 108 6.1.1 Signature time- stamp attribute definition 43 109 6.2 Complete validation reference data (CAdES-C) 44 110 6.2.1 Complete certificate references attribute definition 44 111 6.2.2 Complete Revocation References attribute definition 45 112 6.2.3 Attribute certificate references attribute definition 47 113 6.2.4 Attribute revocation references attribute definition 47 114 6.3 Extended validation data (CAdES-X) 48 115 6.3.1 Time-stamped validation data (CAdES-X Type 1 or Type 2) 48 116 6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2) 48 117 6.3.3 Certificate values attribute definition 49 118 6.3.4 Revocation values attribute definition 50 119 6.3.5 CAdES-C time-stamp attribute definition 51 120 6.3.6 Time-stamped certificates and crls references attribute 121 definition 51 122 6.4 Archive validation data 52 123 6.4.1 Archive time-stamp attribute definition 52 125 7. Other standard data structures 54 126 7.1 Public-key certificate format 54 127 7.2 Certificate revocation list format 54 128 7.3 OCSP response format 54 129 7.4 Time-stamp token format 54 130 7.5 Name and attribute formats 54 131 7.6 Attribute certificate 55 133 8. Conformance requirements 55 134 8.1 CAdES-Basic Electronic Signature (CAdES-BES) 56 135 8.2 CAdES-Explicit Policy-based Electronic Signature 56 136 8.3 Verification using time-stamping 56 137 8.4 Verification using secure records 57 139 9. Security considerations 58 140 9.1 Protection of private key 58 141 9.2 Choice of algorithms 58 143 10. IANA Considerations 58 145 11. References 58 146 11.1 Normative references 58 147 11.2 Informative references 59 149 12. Authors' addresses 62 150 Annex A (normative): ASN.1 definitions 63 151 A.1 Signature format definitions using X.208 ASN.1 syntax 63 152 A.2 Signature format definitions using X.680 ASN.1 syntax 72 154 Annex B (informative): Extended forms of Electronic Signatures 81 155 B.1 Extended forms of validation data 81 156 B.1.1 CAdES-X Long 82 157 B.1.2 CAdES-X Type 1 83 158 B.1.3 CAdES-X Type 2 84 159 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 85 160 B.2 Timestamp extensions 87 161 B.3 Archive validation data (CAdES-A) 88 162 B.4 Example validation sequence 90 163 B.5 Additional optional features 95 165 Annex C (informative):General description 96 166 C.1 The signature policy 96 167 C.2 Signed information 97 168 C.3 Components of an electronic signature 97 169 C.3.1 Reference to the signature policy 97 170 C.3.2 Commitment type indication 98 171 C.3.3 Certificate identifier from the signer 98 172 C.3.4 Role attributes 99 173 C.3.4.1 Claimed role 99 174 C.3.4.2 Certified role 100 175 C.3.5 Signer location 100 176 C.3.6 Signing time 100 177 C.3.7 Content format 101 178 C.3.8 Content cross referencing 101 179 C.4 Components of validation data 101 180 C.4.1 Revocation status information 101 181 C.4.1.1 CRL information 102 182 C.4.1.2 OCSP information 102 183 C.4.2 Certification path 103 184 C.4.3 Time-stamping for long life of signatures 103 185 C.4.4 Time-stamping for long life of signature before CA key 186 compromises 104 187 C.4.4.1 Time-stamping the ES with complete validation data 105 188 C.4.4.2 Time-stamping certificates and revocation information 189 references 106 190 C.4.5 Time-stamping for archive of signature 107 191 C.4.6 Reference to additional data 108 192 C.4.7 Time-stamping for mutual recognition 108 193 C.4.8 TSA key compromise 109 194 C.5 Multiple signatures 109 196 Annex D (informative):Data protocols to interoperate with TSPs 110 197 D.1 Operational protocols 110 198 D.1.1 Certificate retrieval 110 199 D.1.2 CRL retrieval 110 200 D.1.3 OnLine certificate status 110 201 D.1.4 Time-stamping 110 202 D.2 Management protocols 110 203 D.2.1 Request for certificate revocation 110 204 Annex E (informative): Guidance on naming 111 205 E.1 Allocation of names 111 206 E.2 Providing access to registration information 111 207 E.3 Naming schemes 112 208 E.3.1 Naming schemes for individual citizens 112 209 E.3.2 Naming schemes for employees of an organization 113 211 Annex F (informative): Example structured contents and MIME 114 212 F.1 General description 114 213 F.2 Header information 114 214 F.3 Content encoding 115 215 F.4 Multi-part content 115 216 F.5 S/MIME 116 218 Annex G (informative): Relationship to the European Directive 219 And EESSI 119 220 G.1 Introduction 119 221 G.2 Electronic signatures and the directive 119 222 G.3 ETSI electronic signature formats and the directive 120 223 G.4 EESSI standards and classes of electronic signature 120 224 G.4.1 Structure of EESSI standardization 120 225 G.4.2 Classes of electronic signatures 121 226 G.4.3 EESSI classes and the ETSI electronic signature format 121 228 Annex H (informative): APIs for the generation and verification 229 of electronic signatures tokens 122 230 H.1 Data framing 122 231 H.2 IDUP-GSS-APIs defined by the IETF 123 232 H.3 CORBA security interfaces defined by the OMG 124 234 Annex I (informative):Cryptographic algorithms 126 235 I.1 Digest algorithms 126 236 I.1.1 SHA-1 126 237 I.1.2 General 126 238 I.2 Digital signature algorithms 127 239 I.2.1 DSA 127 240 I.2.2 RSA 127 241 I.2.3 General 128 243 Annex J (informative): Changes from the previous version 130 245 Full Copyright Statement 131 247 Disclaimer 131 249 Intellectual Property 131 250 1. Introduction 252 This document is intended to cover electronic signatures for various 253 types of transactions, including business transactions (e.g. purchase 254 requisition, contract, and invoice applications) where long term 255 validity of such signatures is important. This includes evidence as 256 to its validity even if the signer or verifying party later attempts 257 to deny (i.e., repudiates, see ISO/IEC 10181-5) the validity of the 258 signature). 260 Thus the present document can be used for any transaction between an 261 individual and a company, between two companies, between an individual 262 and a governmental body, etc. The present document is independent of 263 any environment. It can be applied to any environment e.g. smart cards, 264 GSM SIM cards, special programs for electronic signatures, etc. 266 The European Directive on a community framework for Electronic 267 Signatures defines an electronic signature as: "Data in electronic form 268 which is attached to or logically associated with other electronic data 269 and which serves as a method of authentication". 271 An electronic signature as used in the present document is a form 272 of advanced electronic signature as defined in the Directive. 274 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 275 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 276 as shown) are to be interpreted as described in RFC 2119 [STDWORDS] 278 2. Scope 280 The scope the present document covers Electronic Signature Formats 281 only. The aspects of Electronic Signature Policies are defined in RFC 282 3125 and in TR 102 272 (see informative references). 284 The present document defines a number of Electronic Signature Formats, 285 including electronic signature that can remain valid over long periods. 286 This includes evidence as to its validity even if the signer or 287 verifying party later attempts to deny (repudiates) the validity of the 288 electronic signature. 290 The present document specifies use of trusted service providers (e.g. 291 Time-Stamping Authorities), and the data that needs to be archived 292 (e.g. cross certificates and revocation lists) to meet the requirements 293 of long term electronic signatures. 295 An electronic signature defined by the present document can be used for 296 arbitration in case of a dispute between the signer and verifier, which 297 may occur at some later time, even years later. 299 The present document includes the concept of signature policies that 300 can be used to establish technical consistency when validating 301 electronic signatures but does not mandate their use. 303 The present document is based on the use of public key cryptography to 304 produce digital signatures, supported by public key certificates. 305 The present document also specifies the use of time-stamping and time- 306 marking services to prove the validity of a signature long after the 307 normal lifetime of critical elements of an electronic signature. It 308 also, as an option, defines ways to provide very long-term protection 309 against key compromise or weakened algorithms. 311 The present document builds on existing standards that are widely 312 adopted. This includes: 314 - RFC 3852 [4] "Cryptographic Message Syntax (CMS)"; 316 - ISO/IEC 9594-8/ITU-T Recommendation X.509 [1]: "Information 317 technology - Open Systems Interconnection - The Directory: 318 Authentication framework"; 320 - RFC 3280 [2] "Internet X.509 Public Key Infrastructure (PKIX) 321 Certificate and CRL Profile"; 323 - RFC 3161 [7] "Internet X.509 Public Key Infrastructure Time-Stamp 324 Protocol (TSP)". 326 NOTE: See section 11 for a full set of references. 328 The present document describes formats for advanced electronic 329 signatures using ASN.1 (Abstract Syntax Notation 1). These formats are 330 based on CMS (Cryptographic Message Syntax) defined in RFC 3852 [4]. 331 These electronic signatures are thus called CAdES, for "CMS Advanced 332 Electronic Signatures". 334 Another document, TS 101 903 (see informative references), describes 335 formats for XML advanced electronic signatures (XAdES) built on 336 XMLDSIG. 338 In addition, the present document identifies other documents that 339 define formats for Public Key Certificates, Attribute Certificates, 340 Certificate Revocation Lists and supporting protocols, including, 341 protocols for use of trusted third parties to support the operation of 342 electronic signature creation and validation. 344 Informative annexes include: 346 - illustrations of extended forms of extended Electronic Signatures 347 formats that protect against various vulnerabilities and examples 348 of validation processes; 350 - descriptions and explanations of some of the concepts used in the 351 present document. giving a rational for normative parts of the 352 present document; 354 - information on protocols to interoperate with Trusted Service 355 Providers; 357 - information on security considerations; 359 - an example structured content and MIME; 361 - the relationship between the present document and the directive 362 on electronic signature and associated standardization 363 initiatives; 365 - APIs to support the generation and the verification of electronic 366 signatures; 368 - cryptographic algorithms that may be used; 370 - guidance on naming. 372 - changes from the previous version. 374 3 Definitions and abbreviations 376 3.1 Definitions 378 For the purposes of the present document, the following terms and 379 definitions apply: 381 Arbitrator: arbitrator entity may be used to arbitrate a dispute 382 between a signer and verifier when there is a disagreement on the 383 validity of a digital signature. 385 Attribute Authority (AA): authority which assigns privileges by issuing 386 attribute certificates. 388 Authority certificate: certificate issued to an authority (e.g. either 389 to a certification authority or to an attribute authority). 391 Attribute Authority Revocation List (AARL): revocation list containing 392 a list of references to certificates issued to AAs, that are no longer 393 considered valid by the issuing authority. 395 Attribute Certificate Revocation List (ACRL): revocation list 396 containing a list of references to attribute certificates that are no 397 longer considered valid by the issuing authority. 399 Certification Authority Revocation List (CARL): revocation list 400 containing a list of public-key certificates issued to certification 401 authorities, that are no longer considered valid by the certificate 402 issuer. 404 Certification Authority (CA): authority trusted by one or more users to 405 create and assign public key certificates, optionally the certification 406 authority may create the users' keys. 408 NOTE: See ITU-T Recommendation X.509 [1]. 410 Certificate Revocation List (CRL): signed list indicating a set of 411 public key certificates that are no longer considered valid by the 412 certificate issuer. 414 Digital signature: data appended to, or a cryptographic transformation 415 of, a data unit that allows a recipient of the data unit to prove the 416 source and integrity of the data unit and protect against forgery, e.g. 417 by the recipient. 419 NOTE: See ISO 7498-2 (see informative references). 421 Electronic signature: data in electronic form which are attached to or 422 logically associated with other electronic data and which serve as a 423 method of authentication. 425 NOTE: See Directive 1999/93/EC of the European Parliament and of the 426 Council of 13 December 1999 on a Community framework for 427 electronic signatures. 429 Enhanced electronic signatures: electronic signatures enhanced by 430 complementing the baseline requirements with additional data, such as 431 time tamp tokens and certificate revocation data, to address commonly 432 recognized threats. 434 Explicit Policy-based Electronic Signature (EPES): an electronic 435 signature where the signature policy is explicitly specified that shall 436 be used to validate it. 438 grace period: time period which permits the certificate revocation 439 information to propagate through the revocation process to relying 440 parties. 442 Initial verification: a process performed by a verifier done after an 443 electronic signature is generated in order to capture additional 444 information that could make it valid for long term verification. 446 Public Key Certificate (PKC): public keys of a user, together with some 447 other information, rendered unforgeable by encipherment with the 448 private key of the certification authority which issued it. 450 NOTE: See ITU-T Recommendation X.509 [1]. 452 Rivest-Shamir-Adleman (RSA): asymmetric cryptography algorithm based on 453 the difficulty to factorize very large numbers, using a key pair: a 454 private key and a public key. 456 Signature policy: set of rules for the creation and validation of an 457 electronic signature, that defines the technical and procedural 458 requirements for electronic signature creation and validation, in order 459 to meet a particular business need, and under which the signature can 460 be determined to be valid. 462 Signature policy issuer: entity that defines and issues a signature 463 policy. 465 Signature validation policy: part of the signature policy which 466 specifies the technical requirements on the signer in creating a 467 signature and verifier when validating a signature. 469 Signer: entity that creates an electronic signature. 471 Subsequent Verification: a process performed by a verifier to assess 472 the signature validity. 474 NOTE: It may be done even years after the electronic signature was 475 produced by the signer and completed by the Initial 476 Verification and it might not need to capture more data than 477 those captured at the time of initial verification. 479 Time-Stamp token: data object that binds a representation of a datum to 480 a particular time, thus establishing evidence that the datum existed 481 before that time. 483 Time-Mark: information in an audit trail from a Trusted Service 484 Provider that binds a representation of a datum to a particular time, 485 thus establishing evidence that the datum existed before that time. 487 Time-Marking Authority: trusted third party that creates records in an 488 audit trail in order to indicate that a datum existed before a 489 particular point in time. 491 Time-Stamping Authority (TSA): trusted third party that creates time- 492 stamp tokens in order to indicate that a datum existed at a particular 493 point in time. 495 Time-Stamping Unit (TSU): set of hardware and software which is managed 496 as a unit and has a single time-stamp token signing key active at a 497 time. 499 Trusted Service Provider (TSP): entity that helps to build trust 500 relationships by making available or providing some information upon 501 request. 503 Validation data: additional data that may be used by a verifier of 504 electronic signatures to determine the signature is valid. 506 Valid electronic signature: electronic signature which passes 507 validation. 509 Verifier: entity that verifies evidence. 511 NOTE 1: See ISO/IEC 13888-1 (see informative references). 513 NOTE 2: Within the context of the present document this is an entity 514 that validates an electronic signature. 516 3.2 Abbreviations 518 For the purposes of the present document, the following abbreviations 519 apply: 521 AA Attribute Authority 522 AARL Attribute Authority Revocation List 523 ACRL Attribute Certificate Revocation List 524 API Application Program Interface 525 ASCII American Standard Code for Information Interchange 526 ASN.1 Abstract Syntax Notation 1 527 CA Certification Authority 528 CAD Card Accepting Device 529 CAdES CMS Advanced Electronic Signature 530 CAdES-A CAdES with Archive validation data 531 CAdES-BES CAdES Basic Electronic Signature 532 CAdES-C CAdES with Complete validation data 533 CAdES-EPES CAdES Explicit Policy Electronic Signature 534 CAdES-T CAdES with Time-stamp 535 CAdES-X CAdES with eXtended validation data 536 CARL Certification Authority Revocation List 537 CMS Cryptographic Message Syntax 538 CRL Certificate Revocation List 539 CWA CEN Workshop Agreement 540 DER Distinguished Encoding Rules (for ASN.1) 541 DSA Digital Signature Algorithm 542 EDIFACT Electronic Data Interchange For Administration, Commerce 543 and Transport 545 EESSI European Electronic Signature Standardization Initiative 546 EPES Explicit Policy-based Electronic Signature 547 ES Electronic Signature 548 ESS Enhanced Security Services (enhances CMS) 549 IDL Interface Definition Language 550 MIME Multipurpose Internet Mail Extensions 551 OCSP Online Certificate Status Provider 552 OID Object IDentifier 553 PKC Public Key Certificate 554 PKIX internet X.509 Public Key Infrastructure 555 RSA Rivest-Shamir-Adleman 556 SHA-1 Secure Hash Algorithm 1 557 TSA Time-Stamping Authority 558 TSP Trusted Service Provider 559 TST Time-Stamp Token 560 TSU Time-Stamping Unit 561 URI Uniform Resource Identifier 562 URL Uniform Resource Locator 563 XML eXtended Mark up Language 564 XMLDSIG XML-Signature Syntax and Processing 566 4 Overview 568 The present document defines a number of Electronic Signature (ES) 569 formats that build on CMS (RFC 3852 [4] by adding signed and unsigned 570 attributes. 572 This clause provides an introduction to the major parties involved 573 (clause 4.1), the concept of Signature Policies (clause 4.2), provides 574 an overview of the various ES formats (clause 4.3), introduces the 575 concept of validation data and provides an overview of formats that 576 incorporate validation data (clause 4.4), presents relevant 577 considerations on arbitration (clause 4.5) and for the validation 578 process (clause 4.6). 580 The formal specifications of the attributes are specified in clauses 5 581 and 6, annexes C and D provide rationale for the definitions of the 582 different ES forms. 584 4.1 Major parties 586 The major parties involved in a business transaction supported by 587 electronic signatures as defined in the present document are: 589 - the Signer; 590 - the Verifier; 591 - Trusted Service Providers (TSP); 592 - the Arbitrator. 594 The signer is the entity that creates the electronic signature. When 595 the signer digitally signs over data using the prescribed format, this 596 represents a commitment on behalf of the signing entity to the data 597 being signed. 599 The verifier is the entity that validates the electronic signature, it 600 may be a single entity or multiple entities. 602 The Trusted Service Providers (TSPs) are one or more entities that help 603 to build trust relationships between the signer and verifier. They 604 support the signer and verifier by means of supporting services 605 including: user certificates, cross-certificates, time-stamp tokens, 606 CRLs, ARLs, OCSP responses. The following TSPs are used to support the 607 functions defined in the present document: 609 - Certification Authorities; 610 - Registration Authorities; 611 - Repository Authorities (e.g. a Directory); 612 - Time-Stamping Authorities; 613 - Time-Marking Authorities; 614 - Signature Policy Issuers. 616 Certification Authorities provide users with public key certificates 617 and with a revocation service. 619 Registration Authorities allow the identification and registration of 620 entities before a CA generates certificates. 622 Repository Authorities publish CRLs issued by CAs, signature policies 623 issued by Signature Policy Issuers and optionally public key 624 certificates. 626 Time-Stamping Authorities attest that some data was formed before a 627 given trusted time. 629 Time-Marking Authorities record that some data was formed before a 630 given trusted time. 632 Signature Policy Issuers define the signature policies to be used by 633 signers and verifiers. 635 In some cases the following additional TSPs are needed: 637 - Attribute Authorities. 639 Attributes Authorities provide users with attributes linked to public 640 key certificates. 642 An Arbitrator is an entity that arbitrates in disputes between a signer 643 and a verifier. 645 4.2 Signatures policies 647 The present document includes the concept of signature policies that 648 can be used to establish technical consistency when validating 649 electronic signatures. 651 When a comprehensive signature policy used by the verifier is either 652 explicitly indicated by the signer or implied by the data being signed, 653 then a consistent result can be obtained when validating an electronic 654 signature. 656 When the signature policy being used by the verifier is neither 657 indicated by the signer nor can be derived from other data, or the 658 signature policy is incomplete then verifiers, including arbitrators, 659 may obtain different results when validating an electronic signature. 660 Therefore, comprehensive signature policies that ensure consistency of 661 signature validation are recommended from both the signers and 662 verifiers point of view. 664 Further information on signature policies is provided in: 666 - TR 102 038 (see informative references); 667 - Clauses 5.8.1, C.1 and C.3.1 of the present document; 668 - RFC 3125 (see informative references); 669 - TR 102 272 (see informative references). 671 4.3 Electronic signature formats 673 The current clause provides an overview for two forms of CMS advanced 674 electronic signature specified in the present document, namely, the 675 CAdES Basic Electronic Signature (CAdES-BES) and the CAdES Explicit 676 Policy-based Electronic Signature (CAdES-EPES). Conformance to the 677 present document mandates the signer creates one of these formats. 679 4.3.1 CAdES Basic Electronic Signature (CAdES-BES) 681 A CAdES Basic Electronic Signature (CAdES-BES) in accordance with the 682 present contains: 684 - The signed user data (e.g. the signer's document) as defined in 685 CMS (RFC 3852 [4]); 687 - A collection of mandatory signed attributes as defined in CMS 688 (RFC 3852 [4]).and in ESS (RFC 2634 [5]); 690 - Additional mandatory signed attributes defined in the present 691 document; 693 - The digital signature value computed on the user data and, when 694 present, on the signed attributes, as defined in CMS (RFC 3852 695 [4]). 697 A CAdES Basic Electronic Signature (CAdES-BES) in accordance with the 698 present may contain: 700 - A collection of additional signed attributes; 701 - A collection of optional unsigned attributes. 703 The mandatory signed attributes are: 705 - Content-type. It is defined in RFC 3852 [4] and specifies that 706 the content type of the ContentInfo is "signed-data". Details 707 are provided in clause 5.7.1; 709 - Message-digest. It is defined in RFC 3852 [4] and specifies the 710 message digest of the eContent OCTET STRING within 711 encapContentInfo being signed. Details are provided in clause 712 5.7.2; 714 - ESS signing-certificate OR other-signing-certificate. The ESS 715 signing-certificate attribute is defined in Enhanced Security 716 Services (ESS), RFC 2634 [5] and only allows for the use of SHA-1 717 as digest algorithm. The other-signing-certificate attribute one 718 is defined in the present document and allows for the use of any 719 digest algorithm. A CAdES-BES claiming compliance with the 720 present document must include one of them. Clause 5.7.3 provides 721 the details of these attributes. Clause 5.7.3.2 shows the formal 722 specification of other-signing-certificate. Rationale for its 723 inclusion is provided in clause C.3.3. 725 Optional signed attributes may be added to the CAdES-BES, including 726 optional signed attributes defined in CMS (RFC 3852 [4]), (RFC 2634 727 [5]) and the present document. Listed below are optional attributes 728 that are defined in clause 5 and have a rational provided in annex C: 730 - Signing-time: as defined in CMS (RFC 3852 [4]) indicates the time 731 of the signature as claimed by the signer. Details and short 732 rationale are provided in clause 5.9.1. Clause C.3.6 in provides 733 the rationale. 735 - Content-hints as defined in ESS (RFC 2634 [5]) provides 736 information that describes the format of the signed content. 737 Clause 5.10.1 provides the specification details. Clause C.3.7 738 in provides the rationale. 740 - Content-reference. as defined in ESS (RFC 2634 [5]) can be 741 incorporated as a way to link request and reply messages in an 742 exchange between two parties. Clause 5.10.1 provides the 743 specification details. Clause C.3.8 in provides the rationale. 745 - Content-identifier. as defined in ESS (RFC 2634 [5]) contains an 746 identifier that may be used later on in the previous content- 747 reference attribute. Clause 5.10.2 provides the specification 748 details. Clause C.3.8 in provides the rationale. 750 - Commitment-type-indication. This attribute is defined by the 751 present document as a way to indicate the commitment endorsed by 752 the signer when producing the signature. Clause 5.11.1 provides 753 the specification details. Clause C.3.2 in provides the 754 rationale. 756 - Signer-location. This attribute is defined by the present 757 document. It allows the signer to indicate the place where he 758 has purportedly produced the signature. Clause 5.11.2 provides 759 the specification details. Clause C.3.5 provides the rationale. 761 - Signer-attributes. This attribute is defined by the present 762 document. It allows a claimed or certified role to be 763 incorporated into the signed information. Clause 5.11.3 provides 764 the specification details. Clause C.3.4 provides the rationale. 766 - Content-time-stamp. This attribute is defined by the present 767 document. It allows a time-stamp token of the data to be signed 768 to be incorporated into the signed information. It provides 769 proof of the existence of the data before the signature was 770 created. Clause 5.11.4 provides the specification details. 771 Clause C.3.6 provides the rationale. 773 A CAdES-BES form can also incorporate instances of unsigned attributes 774 as defined in CMS (RFC 3852 [4]) and (RFC 2634 [5]). 776 - CounterSignature. as defined in CMS (RFC 3852 [4]). It can be 777 incorporated wherever allowing embedded signatures is a 778 requirement. Clause 5.9.2 provides the specification details. 779 Clause C.5 in annex C provides the rationale. 781 The structure of the CAdES-BES is illustrated in figure 1. 783 +------Elect.Signature (CAdES-BES)------+ 784 |+----------------------------------- + | 785 ||+---------+ +----------+ | | 786 |||Signer's | | Signed | Digital | | 787 |||Document | |Attributes| Signature | | 788 ||| | | | | | 789 ||+---------+ +----------+ | | 790 |+------------------------------------+ | 791 +---------------------------------------+ 793 Figure 1: Illustration of a CAdES-BES 795 The signer's conformance requirements of a CAdES-BES are defined in 796 clause 8.1. 797 NOTE: The CAdES-BES is the minimum format for an electronic signature 798 to be generated by the signer. On its own, it does not 799 provide enough information for it to be verified in the longer 800 term. For example, revocation information issued by the 801 relevant certificate status information issuer needs to be 802 available for long term validation (see clause 4.4.2). 804 The CAdES-BES satisfies the legal requirements for electronic 805 signatures as defined in the European Directive on electronic 806 signatures, (see annex C for further discussion on relationship of the 807 present document to the Directive). It provides basic authentication 808 and integrity protection. 810 The semantics of the signed data of a CAdES-BES or its context may 811 implicitly indicate a signature policy to the verifier. Specification 812 of the contents of signature policies is outside the scope of the 813 present document. 815 Further information on signature policies is provided in TR 102 038 816 (see informative references), RFC 3125 (see informative references) and 817 clauses 5.8.1, C.1 and C.3.1 of the present document. 819 4.3.2 CAdES Explicit Policy Electronic Signatures (CAdES-EPES) 821 A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES) in 822 accordance with the present document, extends the definition of an 823 electronic signature to conform to the identified signature policy. 824 A CAdES Explicit Policy-based Electronic Signature (CAdES-EPES) 825 incorporates a signed attribute (signature-policy-identifier) 826 indicating that a signature policy that is mandatory to use to validate 827 the signature and specifies explicitly the signature policy that shall 828 be used. This signed attribute is protected by the signature. The 829 signature may also have other signed attributes required to conform to 830 the mandated signature policy. 832 Clause 5.7.3 provides the details on the specification of signature- 833 policy-identifier attribute. Clause C.1 provides a short rationale. 834 Specification of the contents of signature policies is outside the 835 scope of the present document. 837 Further information on signature policies is provided in TR 102 038 838 (see informative references) and clauses 5.8.1, C.1 and C.3.1 of the 839 present document. 841 The structure of the CAdES-EPES is illustrated in figure 2. 843 +------------- Elect.Signature (CAdES-EPES) ---------------+ 844 ||+----------------------------------------------------- + | 845 || +---------------------------+ | | 846 || +---------+ | +----------+ | | | 847 || | | | | | | | | 848 || |Signer's | | |Signature | Signed | Digital | | 849 || |Document | | |Policy ID | Attributes |Signature| | 850 || | | | | | | | | 851 || +---------+ | +----------+ | | | 852 || +---------------------------+ | | 853 |+-------------------------------------------------------+ | 854 | | 855 +----------------------------------------------------------+ 857 Figure 2: Illustration of a CAdES-EPES 859 The signer's conformance requirements of CAdES-EPES are defined in 860 clause 8.2. 862 4.4 Electronic signature formats with validation data 864 Validation of an electronic signature in accordance with the present 865 document requires additional data needed to validate the electronic 866 signature. This additional data is called validation data; and 867 includes: 869 - Public Key Certificates (PKCs); 871 - revocation status information for each PKC; 873 - trusted time-stamps applied to the digital signature or a time- 874 mark shall be available in an audit log; 876 - when appropriate, the details of a signature policy to be used to 877 verify the electronic signature. 879 The validation data may be collected by the signer and/or the verifier. 880 When the signature policy id is present, it shall meet the requirements 881 of the signature policy. Validation data includes CA certificates as 882 well as revocation status information in the form of Certificate 883 Revocation Lists (CRLs) or certificate status information (OCSP) 884 provided by an on-line service. Validation data also includes evidence 885 that the signature was created before a particular point in time this 886 may be either a time-stamp token or time-mark. 888 The present document defines unsigned attributes able to contain 889 validation data that can be added to CAdES-BES and CAdES-EPES leading 890 to electronic signature formats that include validation data. Clauses 891 below summarize these formats and their most relevant characteristics. 893 4.4.1 Electronic Signature with Time (CAdES-T) 895 Electronic Signature with Time (CAdES-T) in accordance with the present 896 document is when there exits trusted time associated with the ES. 898 The trusted time may be provided by: 900 - the signature-time-stamp as an unsigned attribute added to the 901 ES; 903 - A time mark of the ES provided by a trusted service provider. 905 The signature-time-stamp attribute contains a time-stamp token of the 906 electronic signature value. Clause 6.1.1 provides the specification 907 details. Clause C.4.3 in provides the rationale. 909 A time-mark provided by a Trusted Service would have similar effect to 910 the signature-time-stamp attribute but in this case no attribute is 911 added to the ES as it is the responsibility of the TSP to provide 912 evidence of a time mark when required to do so. The management of time 913 marks is outside the scope of the present document. 915 Trusted time provides the initial steps towards providing long term 916 validity. Electronic signatures with the time stamp attribute forming 917 the CAdES-T is illustrated in figure 3. 919 +-------------------------------------------------CAdES-T ---------+ 920 |+------ CAdES-BES or CAdES-EPES -------+ | 921 ||+-----------------------------------+ | +----------------------+ | 922 |||+---------+ +----------+ | | | | | 923 ||||Signer's | | Signed | Digital | | | Signature-time-stamp | | 924 ||||Document | |Attributes| Signature | | | attribute required | | 925 |||| | | | | | | when using time | | 926 |||+---------+ +----------+ | | | stamps. | | 927 ||+-----------------------------------+ | | | | 928 |+--------------------------------------+ | or the BES/EPES | | 929 | | shall be tme marked | | 930 | | | | 931 | | Management and | | 932 | | provision of time | | 933 | | mark is the | | 934 | | responsibility of | | 935 | | the TSP. | | 936 | +----------------------+ | 937 +------------------------------------------------------------------+ 939 Figure 3: Illustration of CAdES-T formats 941 NOTE A time stamp token is added to the CAdES-BES or CAdES-EPES as 942 an unsigned attribute. 944 4.4.2 ES with Complete validation data references (CAdES-C) 946 Electronic Signature with Complete validation data references (CAdES-C) 947 in accordance with the present document adds to the CAdES-T the 948 complete-certificate-references and complete-revocation-references 949 attributes as defined by the present document. The complete- 950 certificate-references attribute contain references to all the 951 certificates present in the certification path used for verifying the 952 signature. The complete-revocation-references attribute contains 953 references to the CRLs and/or OCSP responses used for verifying the 954 signature. Clause 6.2 provides the specification details. Storing the 955 references allows the values of the certification path and the CRLs or 956 OCSPs responses to be stored elsewhere, reducing the size of a stored 957 electronic signature format. 959 Clauses C.4.1 to C.4.2 provide rationale on the usage of validation 960 data and when it is suitable to generate the CAdES-C form. 961 Electronic signatures with the additional validation data forming the 962 CAdES-C are illustrated in figure 4. 964 +------------------------- CAdES-C --------------------------------+ 965 |+----------------------------- CAdES-T ---------+ | 966 || +----------+ | +-------------+ | 967 || |Timestamp | | | | | 968 || |attribute | | | | | 969 ||+- CAdES-BES or CAdES-EPES ------+|over | | | | | 970 ||| ||digital | | | Complete | | 971 |||+---------++----------+ ||signature | | | certificate | | 972 ||||Signer's || Signed | Digital ||is | | | and | | 973 ||||Document ||Attributes|Signature||mandatory | | | revocation | | 974 |||| || | ||if is | | | references | | 975 |||+---------++----------+ ||NOT | | | | | 976 ||+--------------------------------+|timemarked| | | | | 977 || +----------+ | | | | 978 || | +-------------+ | 979 |+-----------------------------------------------+ | 980 | | 981 +------------------------------------------------------------------+ 983 Figure 4: Illustration of CAdES-C format 985 NOTE 1: The complete certificate and revocation references are added 986 to the CAdES-T as an unsigned attribute. 988 NOTE 2: As a minimum, the signer will provide the CAdES-BES or when 989 indicating that the signature conforms to an explicit signing 990 policy the CAdES-EPES. 992 NOTE 3: To reduce the risk of repudiating signature creation, the 993 trusted time indication needs to be as close as possible to 994 the time the signature was created. The signer or a TSP could 995 provide the CAdES-T, if not the verifier should create the 996 CAdES-T on first receipt of an electronic signature because 997 the CAdES-T provides independent evidence of the existence of 998 the signature prior to the trusted time indication. 1000 NOTE 4: An CAdES-T trusted time indications must be created before a 1001 certificate has been revoked or expired. 1003 NOTE 5: The signer and TSP could provide the CAdES-C, to minimize 1004 this risk and when the signer does not provide the CAdES-C, 1005 the verifier should create the CAdES-C when the required 1006 component of revocation and validation data become available, 1007 this may require a grace period. 1009 NOTE 6: A grace period permits certificate revocation information to 1010 propagate through the revocation processes. This period could 1011 extend from the time an authorized entity requests certificate 1012 revocation, to when the information is available for the 1013 relying to use. In order to make sure that the certificate 1014 was not revoked at the time the signature was time-marked or 1015 time-stamped, verifiers should wait until the end of the grace 1016 period. A signature policy may define specific values for 1017 grace periods. An illustration of a grace period is provided 1018 in figure 5. 1020 +<--------------Grace Period --------->+ 1021 ----+-------+-------+--------+---------------------+----------+ 1022 ^ ^ ^ ^ ^ ^ 1023 | | | | | | 1024 | | | | | | 1025 Signature | First | Second | 1026 creation | revocation | revocation | 1027 time | status | status | 1028 | checking | checking | 1029 | | | 1030 Time-stamp Certification Build 1031 or path CAdES-C 1032 time-mark construction 1033 over & verification 1034 signature 1036 Figure 5: Illustration of a grace period 1037 Figure 5: Illustration of a grace period 1039 NOTE 7: CWA 14171 (see informative references) specifies a signature 1040 validation process using CAdES-T, CAdES-C and a grace period. 1041 Annex B provides example validation processes. Clause C.4 1042 provides additional information about applying grace periods 1043 during the validation process. 1045 The verifier's conformance requirements are defined in clause 8.3 for 1046 time stamped CAdES-C and clause 8.4 for time marked CAdES-C. The 1047 present document only defines conformance requirements for the verifier 1048 up to an ES with complete validation data (CAdES-C). This means that 1049 none of the extended and archive forms of Electronic Signature as 1050 defined in clauses 4.4.3 to 4.4.4) need to be implemented to achieve 1051 conformance to the present document. 1053 4.4.3 Extended electronic signature formats 1055 CAdES-C can be extended by adding unsigned attributes to the electronic 1056 signature. The present document defines various unsigned attributes 1057 that are applicable for very long term verification, and for preventing 1058 some disaster situations which are discussed in annex C. Annex B 1059 provides the details of the various extended formats, all the required 1060 unsigned attributes for each type and how they can be used within the 1061 electronic signature validation process. The clauses below give an 1062 overview of the various forms of extended signature formats in the 1063 present document. 1065 4.4.3.1 EXtended Long Electronic Signature (CAdES-X Long) 1067 Extended Long format (CAdES-X Long) in accordance with the present 1068 document adds to the CAdES-C format the certificate-values and 1069 revocation-values attributes. The first one contains the whole 1070 certificate path required for verifying the signature; the second one 1071 the CRLs and/OCSP responses required for the validation of the 1072 signature. This provides a know repository of certificate and 1073 revocation information required to validate an CAdES-C and prevents 1074 such information getting lost. Clauses 6.3.3 and 6.3.4 give 1075 specification details. Clause B.1.1 gives details on the production of 1076 the format. Clauses C4.1 to C.4.2 provide the rationale. 1078 The structure of the CAdES-X Long format is illustrated in figure 6. 1080 +----------------------- CAdES-X-Long -----------------------------+ 1081 |+------------------------------------ CadES-C --+ | 1082 || +----------+ | +-------------+ | 1083 ||+------ CAdES -------------------+|Timestamp | | | | | 1084 ||| || over | | | Complete | | 1085 |||+---------++----------+ ||digital | | | certificate | | 1086 ||||Signer's || Signed | Digital ||signature | | | and | | 1087 ||||Document ||Attributes|Signature|| | | | revocation | | 1088 |||| || | ||Optional | | | data | | 1089 |||+---------++----------+ ||when | | | | | 1090 ||+--------------------------------+|timemarked| | | | | 1091 || +----------+ | | | | 1092 || +-------------+ | +-------------+ | 1093 || | Complete | | | 1094 || | certificate | | | 1095 || | and | | | 1096 || | revocation | | | 1097 || | references | | | 1098 || +-------------+ | | 1099 |+-----------------------------------------------+ | 1100 | | 1101 +------------------------------------------------------------------+ 1103 Figure 6: Illustration of CAdES-X-Long 1105 4.4.3.2 EXtended Electronic Signature with Time Type 1 1106 (CAdES-X Type 1) 1108 Extended format with time type 1 (CAdES-X Type 1) in accordance with 1109 the present document adds to the CAdES-C format the CAdES-C-time-stamp 1110 attribute, whose content is a time-stamp token on the CAdES-C itself. 1112 This provides an integrity and trusted time protection over all the 1113 elements and references. It may protect the certificates, CRLs and 1114 OCSP responses in case of a later compromise of a CA key, CRL key or 1115 OCSP issuer key. Clause 6.3.5 provides the specification details. 1117 Clause B.1.2 gives details on the production of the time-stamping 1118 process. Clauses C.4.4.1 provides the rationale. 1120 The structure of the CAdES-X Type 1 format is illustrated in figure 7. 1122 +----------------------- CAdES-X-Type 1 -----------------------------+ 1123 |+-------------------------------------- CAdES-C --+ | 1124 || +----------+ | +-------------+ | 1125 ||+--------- CAdES ------------------+|Timestamp | | | | | 1126 ||| ||over | | | | | 1127 |||+---------++----------++---------+||digital | | | | | 1128 ||||Signer's || Signed || Digital |||signature | | | Timestamp | | 1129 ||||Document ||Attributes||Signature||| | | | over | | 1130 |||| || || |||Optional | | | CAdES-C | | 1131 |||+---------++----------++---------+||when | | | | | 1132 ||+----------------------------------+|timemarked| | | | | 1133 || +----------+ | | | | 1134 || +-------------+ | +-------------+ | 1135 || | Complete | | | 1136 || | certificate | | | 1137 || | and | | | 1138 || | revocation | | | 1139 || | references | | | 1140 || +-------------+ | | 1141 |+-------------------------------------------------+ | 1142 | | 1143 +--------------------------------------------------------------------+ 1145 Figure 7: Illustration of CAdES-X Type 1 1147 4.4.3.3 EXtended Electronic Signature with Time Type 2 1148 (CAdES-X Type 2) 1150 Extended format with time type 2 (CAdES-X Type 2) in accordance with 1151 the present document adds to the CAdES-C format the CAdES-C-time- 1152 stamped-certs-crls-references attribute, whose content is a time-stamp 1153 token on the certification path and revocation information references. 1154 This provides an integrity and trusted time protection over all the 1155 references. 1157 It may protect the certificates, CRLs and OCSP responses in case of a 1158 later compromise of a CA key, CRL key or OCSP issuer key. 1160 Both CAdES-X Type 1 and CAdES-X Type 2 counter the same threats and the 1161 usage of one or the other depends on the environment. Clause 6.3.5 1162 provides the specification details. Clause B.1.3 gives details on the 1163 production of the time-stamping process. Clause C.4.4.2 provides the 1164 rationale. 1166 The structure of the CAdES-X Type 2 format is illustrated in figure 8. 1168 +------------------------- CAdES-X-Type 2 ---------------------------+ 1169 |+-----------------------------------------CAdES-C --+ | 1170 || +-----------+| | 1171 ||+----- CAdES ------------------------+| Timmestamp|| | 1172 ||| || over || | 1173 |||+---------+ +----------+ +---------+|| digital ||+-------------+| 1174 ||||Signer's | | Signed | | Digital ||| signature ||| Time-stamp || 1175 ||||Document | |Attributes| |signature||| ||| only over || 1176 |||| | | | | ||| optional ||| complete || 1177 |||+---------+ +----------+ +---------+|| when ||| certificate || 1178 ||+------------------------------------+| timemarked||| and || 1179 || +-----------+|| revocation || 1180 || +-------------+|| references || 1181 || | Complete ||+-------------+| 1182 || | certificate || | 1183 || | and || | 1184 || | revocation || | 1185 || | references || | 1186 || +-------------+| | 1187 |+---------------------------------------------------+ | 1188 | | 1189 +--------------------------------------------------------------------+ 1191 Figure 8: Illustration of CAdES-X Type 2 1193 4.4.3.4 EXtended Long Electronic Signature with Time (CAdES-X Long Type 1194 1 or 2) 1196 Extended Long with Time (CAdES-X Long Type 1 or 2) in accordance with 1197 the present document is a combination of CAdES-X Long and one of the 1198 two former types (CAdES-X Type 1 and CAdES-X Type 2). Clause B.1.4 1199 gives details on the production of the time-stamping process. Clause 1200 C4.8 in annex C provides the rationale. 1202 The structure of the CAdES-X Long Type 1 and CAdES-X Long Type 2. 1203 format is illustrated in figure 9. 1205 +------------------ CAdES-X Long Type 1 or 2 -----------------------+ 1206 | +--------------+| 1207 |+-------------------------------------- CAdES-C --+|+------------+|| 1208 || ||| Timestamp ||| 1209 ||+------- CAdES --------------------++----------+ ||| over ||| 1210 ||| ||Timestamp | ||| CAdES-C ||| 1211 ||| ||over | ||+------------+|| 1212 |||+---------++----------++---------+||digital | || OR || 1213 ||||Signer's || Signed || Digital |||signature | ||+------------+|| 1214 ||||Document ||Attributes||signature||| | ||| Timestamp ||| 1215 |||| || || |||Optional | ||| only over ||| 1216 |||+---------++----------++---------+||when | ||| complete ||| 1217 ||+----------------------------------+|timemarked| ||| certificate||| 1218 || +----------+ ||| and ||| 1219 || ||| Revocation ||| 1220 || +-------------+ ||| References ||| 1221 || | Complete | ||+------------+|| 1222 || | certificate | |+--------------+| 1223 || | and | | +------------+ | 1224 || | revocation | | | Complete | | 1225 || | references | | |certificate | | 1226 || +-------------+ | | and | | 1227 |+-------------------------------------------------+ |revocation | | 1228 | | value | | 1229 | +------------+ | 1230 +-------------------------------------------------------------------+ 1232 Figure 9: Illustration of CAdES-X Long Type 1 and CAdES Long Type 2 1234 4.4.4 Archival Electronic Signature (CAdES-A) 1236 Archival Form (CAdES-A) in accordance with the present document builds 1237 on a CAdES-X Long or a CAdES-X Long Type 1 or 2 by adding one or more 1238 archive-time-stamp attributes. This form is used for archival of long- 1239 term signatures. Successive time-stamps protect the whole material 1240 against vulnerable hashing algorithms or the breaking of the 1241 cryptographic material or algorithms. Clause 6.4 contains the 1242 specification details. Clauses C.4.5 and C.4.8 provide the rationale. 1244 The structure of the CAdES-A form is illustrated in figure 10. 1246 +---------------------------CAdES-A ---------------------------------+ 1247 |+----------------------------------------------------+ | 1248 || +--------------+| +----------+ | 1249 ||+----------------------CAdES-C ----+|+------------+|| | | | 1250 ||| +----------+ ||| Timestamp ||| | | | 1251 |||+---- CAdES-BES ----+|Timestamp | ||| over ||| | | | 1252 |||| or CAdeS-EPES || over | ||| CAdES-C ||| | Archive | | 1253 |||| ||digital | ||+------------+|| | | | 1254 |||| ||signature | || or || |Timestamp | | 1255 |||| || | ||+------------+|| | | | 1256 |||| ||Optional | ||| Timestamp ||| | | | 1257 |||| ||when | ||| only over ||| | | | 1258 |||| ||Timemarked| ||| complete ||| | | | 1259 |||+-------------------+| | ||| certificate||| +----------+ | 1260 ||| +----------+ ||| and ||| | 1261 ||| +-------------+ ||| revocation ||| | 1262 ||| | Complete | ||| references ||| | 1263 ||| | certificate | ||+------------+|| | 1264 ||| | and | |+--------------+| | 1265 ||| | revocation | | +------------+ | | 1266 ||| | references | | | Complete | | | 1267 ||| +-------------+ | |certificate | | | 1268 ||| | | and | | | 1269 ||+----------------------------------+ |revocation | | | 1270 || | values | | | 1271 || +------------+ | | 1272 |+----------------------------------------------------+ | 1273 +--------------------------------------------------------------------+ 1275 Figure 10: Illustration of CAdES-A 1277 TABLE NOTE : Timestamps are timestamp token that may themselves 1278 include unsigned attributes required to validate the timestamp 1279 token, such as the complete-certificate-references and 1280 complete-revocation-references attributes as defined by the 1281 present document. 1283 4.5 Arbitration 1285 The CAdES-C may be used for arbitration should there be a dispute 1286 between the signer and verifier, provided that: 1288 - the arbitrator knows where to retrieve the signer's certificate 1289 (if not already present), all the cross-certificates and the 1290 required CRLs, ACRLs or OCSP responses referenced in the CAdES-C; 1292 - when time-stamping in the CAdES-T is being used, the certificate 1293 from the TSU that has issued the time-stamp token in the CAdES-T 1294 format is still within its validity period; 1296 - when time-stamping in the CAdES-T is being used, the certificate 1297 from the TSU that has issued the time-stamp token in the CAdES-T 1298 format is not revoked at the time of arbitration; 1300 - when time-marking in the CAdES-T is being used, a reliable audit 1301 trail from the Time-Marking Authority is available for 1302 examination regarding the time; 1304 - none of the private keys corresponding to the certificates used 1305 to verify the signature chain have ever been compromised; 1307 - the cryptography used at the time the CAdES-C was built has not 1308 been broken at the time the arbitration is performed; 1310 - If the signature policy can be explicit or implicitly identified 1311 then an arbitrator is able to determine the rules required to 1312 validate the electronic signature. 1314 4.6 Validation process 1316 The Validation Process validates an electronic signature, the output 1317 status of the validation process can be: 1319 - invalid; 1321 - incomplete validation; 1323 - valid. 1325 An Invalid response indicates that either the signature format is 1326 incorrect or that the digital signature value fails verification (e.g. 1327 the integrity check on the digital signature value fails or any of the 1328 certificates on which the digital signature verification depends is 1329 known to be invalid or revoked). 1331 An Incomplete Validation response indicates that the signature 1332 validation status is currently unknown. In the case of incomplete 1333 validation, additional information may be made available to the 1334 application or user, thus allowing them to decide what to do with the 1335 electronic signature. In the case of incomplete validation, the 1336 electronic signature may be checked again at some later time when 1337 additional information becomes available. 1339 NOTE: For example; an incomplete validation may be because all the 1340 required certificates are not available or the grace period is 1341 not completed. 1343 A Valid response indicates that the signature has passed verification 1344 and it complies with the signature validation policy. 1346 Example validation sequences are illustrated in annex B. 1348 5 Electronic signature attributes 1350 This clause builds upon the existing Cryptographic Message Syntax 1351 (CMS), as defined in RFC 3852 [4], and Enhanced Security Services 1352 (ESS), as defined in RFC 2634 [5]. The overall structure of Electronic 1353 Signature is as defined in CMS. The Electronic Signature (ES) uses 1354 attributes defined in CMS, ESS and the present document. The present 1355 document defines ES attributes which it uses and are not defined 1356 elsewhere. 1358 The mandated set of attributes and the digital signature value is 1359 defined as the minimum Electronic Signature (ES) required by the 1360 present document. A signature policy MAY mandate that other signed 1361 attributes are present. 1363 5.1 General syntax 1365 The general syntax of the ES is as defined in CMS (RFC 3852 [4]). 1367 NOTE: CMS defines content types for id-data, id-signedData, id- 1368 envelopedData, id-digestedData, id-encryptedData, and id- 1369 authenticatedData. Although CMS permits other documents to 1370 define other content types, the ASN.1 type defined should not 1371 be a CHOICE type. The present document does not define other 1372 content types. 1374 5.2 Data content type 1376 The data content type of the ES is as defined in CMS (RFC 3852 [4]). 1378 NOTE: Requirements to identify encoding types within the content when 1379 the ContentType set to id-data are outside the scope of the 1380 present document, see annex F for an example of using MIME to 1381 identify encoding type. 1383 5.3 Signed-data content type 1385 The signed-data content type of the ES is as defined in CMS (RFC 3852 1386 [4]). 1388 To make sure that the verifier uses the right signer's key, the present 1389 document mandates that an unambiguous reference of the signer's 1390 certificate is always included in the Signing Certificate signed 1391 attribute (see clause 5.7.3). 1393 5.4 SignedData type 1395 The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 1396 [4]). 1398 The fields of type SignedData have the meanings as defined in CMS (RFC 1399 3852 [4]) except that: 1401 - the syntax version number value shall be 3. 1403 The identification of signer's certificate used to create the signature 1404 is always signed (see clause 5.7.3). The validation policy may specify 1405 requirements for the presence of certain certificates. 1406 The degenerate case where there are no signers is not valid in the 1407 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, this allows the signed data 1422 to be encapsulated in the SignData (i.e. Signature + data) 1423 alternatively the signed data may be absent form the SignData 1424 (i.e. Signature only). It is in the case of signature only 1425 that the data which is signed needs to be archived in such as 1426 way as to preserve any data encoding. 1427 The degenerate case where there are no signers is not valid in the 1428 present document. 1430 5.6 SignerInfo type 1432 The syntax of the SignerInfo type ES is as defined in CMS (RFC 3852 1433 [4]). 1435 Per-signer information is represented in the type SignerInfo. In the 1436 case of multiple independent signatures (see clause B.5), there is an 1437 instance of this field for each signer. 1439 The fields of type SignerInfo have the meanings defined in CMS (RFC 1440 3852 [4]) except that the signedAttrs field shall contain the following 1441 attributes: 1443 - content-type as defined in clause 5.7.1; 1444 - message-digest as defined in clause 5.7.2; 1445 - signing-certificate as defined in clause 5.7.3. 1447 5.6.1 Message digest calculation process 1449 The message digest calculation process is as defined in CMS (RFC 3852 1450 [4]). 1452 5.6.2 Message signature generation process 1454 The input to the message signature generation process is as defined in 1455 CMS (RFC 3852 [4]). 1457 5.6.3 Message signature verification process 1459 The procedures for message signature verification are defined in CMS 1460 (RFC 3852 [4]) and enhanced in the present document. 1461 The input to the signature verification process includes the signer's 1462 public key which SHALL be verified as correct using the signing 1463 certificate reference attribute containing a reference to the signing 1464 certificate. 1466 5.7 Basic ES mandatory present attributes 1468 The following attributes SHALL be present with the signed-data defined 1469 by the present document. The attributes are defined in CMS (RFC 3852 1470 [4]). 1472 5.7.1 Content type 1474 The syntax of the content-type attribute type of the ES is as defined 1475 in CMS (RFC 3852 [4]). 1477 5.7.2 Message digest 1479 The syntax of the message-digest attribute type of the ES is as defined 1480 in CMS (RFC 3852 [4]). 1482 5.7.3 Signing certificate reference attributes 1484 The Signing certificate reference attributes are supported by using 1485 either the ESS signing-certificate attribute or the other-signing- 1486 certificate attribute. 1488 These attributes shall contain a reference to the signer's certificate, 1489 they are designed to prevent the simple substitution and re-issue 1490 attacks and to allow for a restricted set of certificates to be used in 1491 verifying a signature. They have a compact form (much shorter than the 1492 full certificate) that allows to a certificate to be unambiguously 1493 identified. 1495 One, and only one, of the following alternative attributes SHALL be 1496 present with the signedData defined by the present document. 1498 - The ESS signing-certificate attribute, which is adopted in 1499 existing standards, may be used if the SHA-1 hashing algorithm is 1500 used. 1502 - The other-signing-certificate attribute shall be used when other 1503 hashing algorithms are to be utilized. 1505 The certificate to be used to verify the signature shall be identified 1506 in the sequence (i.e. the certificate from the signer) and the sequence 1507 shall not be empty. The signature validation policy may mandate other 1508 certificates be present that may include all the certificates up to the 1509 point of trust. 1511 5.7.3.1 ESS signing certificate attribute definition 1513 The syntax of the signing-certificate attribute type of the ES is as 1514 defined in Enhanced Security Services (ESS), RFC 2634 [5] and further 1515 qualified in the present document. 1517 The sequence of policy information field is not used in the present 1518 document. 1520 The ESS signing-certificate attribute shall be a signed attribute. 1521 The encoding of the ESSCertID for this certificate shall include the 1522 issuerSerial field. 1524 The issuerAndSerialNumber present in the SignerInfo shall be consistent 1525 with issuerSerial field. The certificate identified shall be used 1526 during the signature verification process. If the hash of the 1527 certificate does not match the certificate used to verify the 1528 signature, the signature shall be considered invalid. 1530 NOTE: Where an attribute certificate is used by the signer to 1531 associate a role, or other attributes of the signer, with the 1532 electronic signature this is placed in the signer-attributes 1533 attribute as defined in clause 5.8.3. 1535 5.7.3.2 Other signing certificate attribute definition 1537 The following attribute is identical to the ESS signing-certificate 1538 defined above except that this attribute can be used with hashing 1539 algorithms other than SHA-1. 1541 This attribute shall be used in the same manner as defined above for 1542 the ESS signing-certificate attribute. 1543 The following object identifier identifies the other-signing- 1544 certificate attribute: 1546 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 1547 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1548 smime(16) id-aa(2) 19 } 1550 The other-signing-certificate attribute value has the ASN.1 syntax 1551 OtherSigningCertificate: 1553 OtherSigningCertificate ::= SEQUENCE { 1554 certs SEQUENCE OF OtherCertID, 1555 policies SEQUENCE OF PolicyInformation OPTIONAL 1556 -- NOT USED IN THE PRESENT DOCUMENT } 1558 OtherCertID ::= SEQUENCE { 1559 otherCertHash OtherHash, 1560 issuerSerial IssuerSerial OPTIONAL } 1562 OtherHash ::= CHOICE { 1563 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 1564 otherHash OtherHashAlgAndValue} 1566 OtherHashValue ::= OCTET STRING 1568 OtherHashAlgAndValue ::= SEQUENCE { 1569 HashAlgorithm AlgorithmIdentifier, 1570 HashValue OtherHashValue } 1572 5.8 Additional mandatory attributes for Explicit Policy-based 1573 Electronic Signatures 1575 5.8.1 Signature policy identifier 1577 he present document mandates that for CAdES-EPES a reference to the 1578 signature policy is included in the signedData. This reference is 1579 explicitly identified. A signature policy defines the rules for 1580 creation and validation of an electronic signature, is included as a 1581 signed attribute with every Explicit Policy-based Electronic Signature. 1582 The signature-policy-identifier shall be a signed attribute. 1584 The following object identifier identifies signature-policy-identifier 1585 attribute: 1587 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 1588 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1589 smime(16) id-aa(2) 15 } 1591 signature-policy-identifier attribute values have ASN.1 type 1592 SignaturePolicyIdentifier: 1593 SignaturePolicyIdentifier ::=CHOICE{ 1594 signaturePolicyId SignaturePolicyId, 1595 signaturePolicyImplied SignaturePolicyImplied 1596 -- not used in this version} 1598 SignaturePolicyId ::= SEQUENCE { 1599 sigPolicyId SigPolicyId, 1600 sigPolicyHash SigPolicyHash OPTIONAL, 1601 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 1602 SigPolicyQualifierInfo OPTIONAL} 1604 SignaturePolicyImplied ::= NULL 1606 The sigPolicyId field contains an object-identifier which uniquely 1607 identifies a specific version of the signature policy. The syntax of 1608 this field is as follows: 1610 SigPolicyId ::= OBJECT IDENTIFIER 1612 The sigPolicyHash field optionally contains the identifier of the hash 1613 algorithm and the hash of the value of the signature policy. 1615 If the signature policy is defined using ASN.1, then the hash is 1616 calculated on the value without the outer type and length fields and 1617 the hashing algorithm shall be as specified in the field sigPolicyHash. 1619 If the signature policy is defined using another structure, the type of 1620 structure and the hashing algorithm shall be either specified as part 1621 of the signature policy, or indicated using a signature policy 1622 qualifier. 1624 SigPolicyHash ::= OtherHashAlgAndValue 1626 NOTE: In the previous version of TS 101 733 (i.e. version 1.5.1) 1627 sigPolicyHash was mandatory. Implementations requiring to be 1628 backward compatible with version 1.5.1 and previous versions 1629 of the current document MUST include SigPolicyHash. 1631 A signature policy identifier may be qualified with other information 1632 about the qualifier. The semantics and syntax of the qualifier is as 1633 associated with the object-identifier in the sigPolicyQualifierId 1634 field. The general syntax of this qualifier is as follows: 1636 SigPolicyQualifierInfo ::= SEQUENCE { 1637 sigPolicyQualifierId SigPolicyQualifierId, 1638 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 1640 The present document specifies the following qualifiers: 1642 - spuri: this contains the web URI or URL reference to the 1643 signature policy; 1645 - sp-user-notice: this contains a user notice which should be 1646 displayed whenever the signature is validated. 1648 sigpolicyQualifierIds defined in the present document 1650 SigPolicyQualifierId ::= 1651 OBJECT IDENTIFIER 1653 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 1654 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1655 smime(16) id-spq(5) 1 } 1657 SPuri ::= IA5String 1659 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 1660 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1661 smime(16) id-spq(5) 2 } 1663 SPUserNotice ::= SEQUENCE { 1664 noticeRef NoticeReference OPTIONAL, 1665 explicitText DisplayText OPTIONAL} 1667 NoticeReference ::= SEQUENCE { 1668 organization DisplayText, 1669 noticeNumbers SEQUENCE OF INTEGER } 1671 DisplayText ::= CHOICE { 1672 visibleString VisibleString (SIZE (1..200)), 1673 bmpString BMPString (SIZE (1..200)), 1674 utf8String UTF8String (SIZE (1..200)) } 1676 5.9 CMS imported optional attributes 1678 The following attributes MAY be present with the signed-data, the 1679 attributes are defined in CMS (RFC 3852 [4]) and are imported into the 1680 present document. Were appropriated the attributes are qualified and 1681 profiled by the present document. 1683 5.9.1 Signing time 1685 The signing-time attribute specifies the time at which the signer 1686 claims to have performed the signing process. 1688 Signing-time attribute values for ES have the ASN.1 type SigningTime as 1689 defined in CMS (RFC 3852 [4]). This type is further qualified in the 1690 present document. 1692 Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be 1693 encoded as UTCTime. Any dates with year values before 1950 or after 1694 2049 MUST be encoded as GeneralizedTime. 1696 5.9.2 Countersignature 1698 The counterSignature attribute values for ES have ASN.1 type 1699 CounterSignature as defined in CMS (RFC 3852 [4]). 1701 A counterSignature attribute shall be an unsigned attribute. 1703 5.10 ESS imported optional attributes 1705 The following attributes MAY be present with the signed-data defined by 1706 the present document. The attributes are defined in ESS and are 1707 imported into the present document and were appropriate qualified and 1708 profiled by the present document. 1710 5.10.1 Content reference attribute 1712 The content-reference attribute is a link from one SignedData to 1713 another. It may be used to link a reply to the original message to 1714 which it refers, or to incorporate by reference one SignedData into 1715 another. The content-reference attribute shall be a signed attribute. 1717 Content-reference attribute values for ES have ASN.1 type 1718 ContentReference as defined in ESS (RFC 2634 [5]). 1720 The content-reference attribute shall be used as defined in ESS (RFC 1721 2634 [5]) and further qualified in the present document. 1723 5.10.2 Content identifier attribute 1725 The content-identifier attribute provides an identifier for the signed 1726 content for use when reference may be later required to that content, 1727 for example in the content reference attribute in other signed data 1728 sent later. The content-identifier shall be a signed attribute. 1730 content-identifier attribute type values for of the ES have ASN.1 type 1731 ContentIdentifier as defined in ESS (RFC 2634 [5]). 1733 The minimal content-identifier attribute should contain a concatenation 1734 of user-specific identification information (such as a user name or 1735 public keying material identification information), a GeneralizedTime 1736 string, and a random number. 1738 5.10.3 Content hints attribute 1740 The content-hints attribute provides information that describes the 1741 format of the signed content. It may be used by the signer to indicate 1742 to a verifier a precise presentation format of the signed data (e.g. 1743 text, voice, and video). This attribute SHOULD be present when the 1744 signed data is to be presented to human users on verification if the 1745 presentation format is not implicit within the data that has been 1746 signed. 1748 The syntax of the content-hints attribute type of the ES as defined in 1749 ESS (RFC 2634 [5]). 1751 When used to indicate the precise format of the data to be presented to 1752 the user the following rules apply: 1754 - the contentType indicates the type of the associated content. It 1755 is an object identifier (i.e. a unique string of integers) 1756 assigned by an authority that defines the content type; 1758 - when the contentType is id-data the contentDescription shall 1759 define the presentation format, the format may be defined by MIME 1760 types. 1762 When the format of the content is defined by MIME types the following 1763 rules apply: 1765 - the contentType shall be id-data as defined in CMS (RFC 3852 1766 [4]); 1768 - the contentDescription shall be used to indicate the encoding of 1769 the data in accordance with the rules defined RFC 2045 [6], see 1770 annex F for an example structured contents and MIME. 1772 NOTE 1: id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1773 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1775 NOTE 2: contentDescription is optional in ESS (RFC 2634 [5]). It may 1776 be used to complement contentTypes defined elsewhere , such 1777 definitions are outside the scope of the present document. 1779 5.11 Additional optional attributes defined in the present document 1781 This clause defines a number of attributes that may be used to meet 1782 specific requirements. 1784 5.11.1 Commitment type indication attribute 1786 There may be situations where a signer wants to explicitly indicate to 1787 a verifier that by signing the data, it illustrates a type of 1788 commitment on behalf of the signer. The commitment-type-indication 1789 attribute conveys such information. 1791 The commitment-type-indication attribute shall be a signed attribute. 1792 The commitment type may be: 1794 - defined as part of the signature policy, in which case the 1795 commitment type has precise semantics that is defined as part of 1796 the signature policy; 1798 - be a registered type, in which case the commitment type has 1799 precise semantics defined by registration, under the rules of the 1800 registration authority. Such a registration authority may be a 1801 trading association or a legislative authority. 1803 The signature policy specifies a set of attributes that it 1804 "recognizes". This "recognized" set includes all those commitment 1805 types defined as part of the signature policy as well as any externally 1806 defined commitment types that the policy may choose to recognize. Only 1807 recognized commitment types are allowed in this field. 1809 The following object identifier identifies the commitment-type- 1810 indication attribute: 1812 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1813 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 1815 commitment-type-indication attribute values have ASN.1 type 1816 CommitmentTypeIndication. 1818 CommitmentTypeIndication ::= SEQUENCE { 1819 commitmentTypeId CommitmentTypeIdentifier, 1820 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 1821 CommitmentTypeQualifier OPTIONAL} 1823 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 1825 CommitmentTypeQualifier ::= SEQUENCE { 1826 commitmentTypeIdentifier CommitmentTypeIdentifier, 1827 qualifier ANY DEFINED BY commitmentTypeIdentifier } 1829 The use of any qualifiers to the commitment type is outside the scope 1830 of the present document. 1832 The following generic commitment types are defined in the present 1833 document: 1835 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1836 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 1838 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1839 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 1841 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 1842 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} 1844 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1845 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 1847 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 1848 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} 1850 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 1851 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} 1852 These generic commitment types have the following meaning: 1854 Proof of origin indicates that the signer recognizes to have created, 1855 approved and sent the message. 1857 Proof of receipt indicates that signer recognizes to have received the 1858 content of the message. 1860 Proof of delivery indicates that the TSP providing that indication has 1861 delivered a message in a local store accessible to the recipient of the 1862 message. 1864 Proof of sender indicates that the entity providing that indication has 1865 sent the message (but not necessarily created it). 1867 Proof of approval indicates that the signer has approved the content of 1868 the message. 1870 Proof of creation indicates that the signer has created the message 1871 (but not necessarily approved, nor sent it). 1873 5.11.2 Signer location attribute 1875 The signer-location attribute specifies a mnemonic for an address 1876 associated with the signer at a particular geographical (e.g. city) 1877 location. The mnemonic is registered in the country in which the 1878 signer is located and is used in the provision of the Public Telegram 1879 Service (according to ITU-T Recommendation F.1 [11]). 1881 The signer-location attribute shall be a signed attribute. 1882 The following object identifier identifies the signer-location 1883 attribute: 1885 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1886 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 1888 Signer-location attribute values have ASN.1 type SignerLocation: 1889 SignerLocation ::= SEQUENCE { -- at least one of the following shall be 1890 present 1892 countryName [0] DirectoryString OPTIONAL, 1893 -- As used to name a Country in X.500 1894 localityName [1] DirectoryString OPTIONAL, 1895 -- As used to name a locality in X.500 1896 postalAdddress [2] PostalAddress OPTIONAL } 1898 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 1899 5.11.3 Signer attributes attribute 1901 The signer-attributes attribute specifies additional attributes of the 1902 signer (e.g. role). 1904 It may be either: 1906 - claimed attributes of the signer; 1908 - certified attributes of the signer. 1910 The signer-attributes attribute shall be a signed attribute. 1911 The following object identifier identifies the signer-attribute 1912 attribute: 1914 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1915 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 1917 signer-attributes values have ASN.1 type SignerAttribute: 1918 SignerAttribute ::= SEQUENCE OF CHOICE { 1919 ClaimedAttributes [0] ClaimedAttributes, 1920 certifiedAttributes [1] CertifiedAttributes } 1922 ClaimedAttributes ::= SEQUENCE OF Attribute 1924 CertifiedAttributes ::= AttributeCertificate 1925 -- as defined in RFC 3281 : see clause 4.1. 1927 NOTE 1: Only a single signer-attributes can be used 1929 NOTE 2: The claimedAttributes and certifiedAttributes fields are as 1930 defined in ITU-T Recommendations X.501 [9] and X.509 [1]. 1932 5.11.4 Content time-stamp 1934 The content-time-stamp attribute is an attribute which is the time- 1935 stamp token of the signed data content before it is signed. 1936 The content-time-stamp attribute shall be a signed attribute. 1938 The following object identifier identifies the content-time-stamp 1939 attribute: 1941 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 1942 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} 1944 Content-time-stamp attribute values have ASN.1 type ContentTimestamp: 1945 ContentTimestamp::= TimeStampToken 1946 The value of messageImprint of TimeStampToken (as described in RFC 3161 1947 [7]) shall be a hash of the value of eContent field within 1948 encapContentInfo in the signedData. 1950 For further information and definition of TimeStampToken see 1951 clause 7.4. 1953 NOTE: Content-time-stamp indicates that the signed information was 1954 formed before the date included in the Content-time-stamp. 1956 5.12 Support for multiple signatures 1958 5.12.1 Independent signatures 1960 Multiple independent signatures (see clause B.5) are supported by 1961 independent SignerInfo from each signer. 1963 Each SignerInfo shall include all the attributes required under the 1964 present document and shall be processed independently by the verifier. 1966 5.12.2 Embedded signatures 1968 Multiple embedded signatures (see clause C.5) are supported using the 1969 countersignature unsigned attribute (see clause 7.1). Each counter 1970 signature is carried in Countersignature held as an unsigned attribute 1971 to the SignerInfo to which the counter-signature is applied. 1973 6 Additional Electronic Signature validation attributes 1975 This clause specifies attributes that contain different types of 1976 validation data. These attributes build on the electronic signature 1977 specified in clause 5. This includes: 1979 - Signature-time-stamp applied to the electronic signature value or 1980 a Time-Mark in an audit trail. This is defined as the Electronic 1981 Signature with Time (CAdES-T); 1983 - complete validation data references which comprises the time- 1984 stamp of the signature value (CAdES-T), plus references to all 1985 the certificates (complete-certificate-references) and revocation 1986 (complete-revocation-references) information used for full 1987 validation of the electronic signature. This is defined as the 1988 Electronic Signature with Complete data references (CAdES-C). 1990 NOTE 1: Formats for CAdES-T are illustrated in clause 4.4 and the 1991 attribute are defined in clause 6.1.1. 1993 NOTE 2: Formats for CAdES-C are illustrated in clause 4.4. The 1994 required attributes for the CAdES-C signature format are 1995 defined in clause 6.2.1 to 6.2.2, optional attributes are 1996 defined in clauses 6.2.3 and 6.2.4. 1998 In addition the following optional eXtended forms of validation data 1999 are also defined, see annex B for an overview the eXtended forms of 2000 validation data: 2002 - CAdES-X with time stamp: there are two types of time-stamp used 2003 in extended validation data defined by the present document: 2005 - Type 1(CAdES-X Type 1): comprises a time-stamp over the ES 2006 with complete validation data (CAdES-C); 2008 - Type 2 (CAdES-X Type2): comprises a time-stamp over the 2009 certification path references and the revocation information 2010 references used to support the CAdES-C. 2012 NOTE 3: Formats for CAdES-X Type 1 and CAdES-X Type 2 are illustrated 2013 in clauses B.1.2 and B.1.3 respectively. 2015 - CAdES-X Long :comprises the complete validation data references 2016 (CAdES-C) plus the actual values of all the certificates and 2017 revocation information used in the CAdES-C. 2019 NOTE 4: Formats for CAdES-X Long are illustrated in clause B.1.1. 2021 - CAdES-X Long Type 1 or CAdES-X Long Type 2: comprises an X-Time- 2022 Stamp (Type 1 or Type 2) plus the actual values of all the 2023 certificates and revocation information used in the CAdES-C as 2024 per CAdES-X Long. 2026 This clause also specifies the data structures used in Archive 2027 validation data format (CAdES-A)of eXtended forms: 2029 - Archive form of electronic signature (CAdES-A) comprises the 2030 complete validation data references (CAdES-C), the certificate 2031 and revocation values (as in a CAdES-X Long ), if present any 2032 existing extended electronic signature timestamps (CAdES-X Type 1 2033 or CAdES-X Type 2), plus the signed user data and an additional 2034 archive time-stamp applied over all that data. An archive time- 2035 stamp may be repeatedly applied after long periods to maintain 2036 validity when electronic signature and time-stamping algorithms 2037 weaken. 2039 The additional data required to create the forms of electronic 2040 signature identified above is carried as unsigned attributes associated 2041 with an individual signature by being placed in the unsignedAttrs field 2042 of SignerInfo . Thus all the attributes defined in clause 6 are 2043 unsigned attributes. 2045 NOTE 5: Where multiple signatures are to be supported, as described 2046 in clause 5.12, each signature has a separate SignerInfo. 2047 Thus, each signature requires its own unsigned attribute 2048 values to create CAdES-T, CAdES-C, etc. 2050 NOTE 6: the optional attributes of the extended validation data are 2051 defined in clauses 6.3 and 6.4. 2053 6.1 Electronic Signature Time-stamped (CAdES-T) 2055 An Electronic Signature with time-stamp is an electronic signature for 2056 which part, but not all, of the additional data required for validation 2057 is available (i.e. some certificates and revocation information are 2058 available but not all). 2060 The minimum structure time-stamp validation data is: 2062 - the Signature Time-stamp Attribute as defined in clause 6.1.1 2063 over the ES signature value. 2065 6.1.1 Signature time- stamp attribute definition 2067 The signature-time-stamp attribute is a TimeStampToken computed on the 2068 signature value for a specific signer. It is an unsigned attribute. 2069 Several instances of this attribute may occur with an electronic 2070 signature, from different TSAs. 2072 The following object identifier identifies the signature-time-stamp 2073 attribute: 2075 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member- 2076 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} 2078 The signature-time-stamp attribute value has ASN.1 type 2079 SignatureTimeStampToken: 2080 SignatureTimeStampToken ::= TimeStampToken 2082 The value of messageImprint field within TimeStampToken shall be a hash 2083 of the value of the signature field within SignerInfo for the 2084 signedData being time-stamped. 2086 For further information and definition of TimeStampToken see 2087 clause 7.4. 2089 NOTE 1: In the case of multiple signatures it is possible to have a 2090 TimeStampToken computed for each and all signers, or 2091 TimeStampToken computed on one signer's signature and no 2092 TimeStampToken on another signer's signature. 2094 NOTE 2: In the case of multiple signatures, several TSTs , issued by 2095 different TSAs, may be present within the same signerInfo (see 2096 RFC 3852 [4]). 2098 6.2 Complete validation reference data (CAdES-C) 2100 An electronic signature with complete validation data references 2101 (CAdES-C) is an Electronic Signature for which all the additional data 2102 required for validation (i.e. all certificates and revocation 2103 information) is available. This form is built on the CAdES-T form 2104 defined above. 2106 As a minimum the complete validation data shall include the following: 2108 - a time, which shall either be a signature-timestamp attribute, as 2109 defined in clause 6.1.1, or a time mark operated by a Time- 2110 Marking Authority; 2112 - complete-certificate-references, as defined in clause 6.2.1; 2114 - complete-revocation-references , as defined in clause 6.2.2. 2116 6.2.1 Complete certificate references attribute definition 2118 The complete-certificate-references attribute is an unsigned attribute. 2119 It references the full set of CA certificates that have been used to 2120 validate an ES with Complete validation data up to (but not including) 2121 the signer's certificate. Only a single instance of this attribute 2122 shall occur with an electronic signature. 2124 NOTE 1: The signer's certificate is referenced in the signing 2125 certificate attribute (see clause 5.7.3). 2127 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2128 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 2130 The complete-certificate-references attribute value has the ASN.1 2131 syntax CompleteCertificateRefs. 2133 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 2135 OtherCertID is defined in clause 5.7.3.2. 2137 The IssuerSerial that shall be present in OtherCertID. The certHash 2138 shall match the hash of the certificate referenced. 2140 NOTE 2: Copies of the certificate values may be held using the 2141 certificate-values attribute defined in clause 6.3.3. 2143 This attribute MAY include references to the certification 2144 chain for any TSUs that provides time-stamp tokens. In this 2145 case the unsigned attribute shall be added to the signData of 2146 the relevant times tamp token as an unsignedAttrs in the 2147 signerInfos field. 2149 6.2.2 Complete Revocation References attribute definition 2151 The complete-revocation-references attribute is an unsigned attribute. 2152 Only a single instance of this attribute shall occur with an electronic 2153 signature. It references the full set of the CRL, ACRL or OCSP 2154 responses that have been used in the validation of the signer and CA 2155 certificates used in ES with Complete validation data. 2157 This attribute can be used to illustrate that the verifies has taken 2158 due diligence of the available revocation information and then to be 2159 able to retrieve that information when stored elsewhere. 2160 The following object identifier identifies the complete-revocation- 2161 references attribute: 2163 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2164 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 2166 The complete-revocation-references attribute value has the ASN.1 syntax 2167 CompleteRevocationRefs 2169 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 2171 CrlOcspRef ::= SEQUENCE { 2172 Crlids [0] CRLListID OPTIONAL, 2173 Ocspids [1] OcspListID OPTIONAL, 2174 OtherRev [2] OtherRevRefs OPTIONAL 2175 } 2177 CompleteRevocationRefs shall contain one CrlOcspRef for the signing- 2178 certificate, followed by one for each OtherCertID in the 2179 CompleteCertificateRefs attribute. The second and subsequent 2180 CrlOcspRef fields shall be in the same order as the OtherCertID to 2181 which they relate. At least one of CRLListID or OcspListID or 2182 OtherRevRefs should be present for all but the "trusted" CA of the 2183 certificate path. 2185 CRLListID ::= SEQUENCE { 2186 crls SEQUENCE OF CrlValidatedID} 2188 CrlValidatedID ::= SEQUENCE { 2189 crlHash OtherHash, 2190 crlIdentifier CrlIdentifier OPTIONAL} 2192 CrlIdentifier ::= SEQUENCE { 2193 crlissuer Name, 2194 crlIssuedTime UTCTime, 2195 crlNumber INTEGER OPTIONAL 2196 } 2198 OcspListID ::= SEQUENCE { 2199 ocspResponses SEQUENCE OF OcspResponsesID} 2201 OcspResponsesID ::= SEQUENCE { 2202 ocspIdentifier OcspIdentifier, 2203 ocspRepHash OtherHash OPTIONAL 2204 } 2206 OcspIdentifier ::= SEQUENCE { 2207 OcspResponderID ResponderID, -- As in OCSP response data 2208 ProducedAt GeneralizedTime -- As in OCSP response data 2209 } 2211 When creating a crlValidatedID, the crlHash is computed over the entire 2212 DER encoded CRL including the signature. The crlIdentifier would 2213 normally be present unless the CRL can be inferred from other 2214 information. 2216 The crlIdentifier is to identify the CRL using the issuer name and the 2217 CRL issued time, which shall correspond to the time thisUpdate 2218 contained in the issued CRL, and if present, the crlNumber. The 2219 crlListID attribute is an unsigned attribute. In the case that the 2220 identified CRL is a Delta CRL then references to the set of CRLs to 2221 provide a complete revocation list shall be included. 2223 The OcspIdentifier is to identify the OCSP response using the issuer 2224 name and the time of issue of the OCSP response which shall correspond 2225 to the time producedAt contained in the issued OCSP response. Since it 2226 may be needed to make the difference between two OCSP responses 2227 received within the same second, then the hash of the response 2228 contained in the OcspResponsesID may be needed to solve the ambiguity. 2230 NOTE: Copies of the CRL and OCSP responses values may be held using 2231 the revocation-values attribute defined in clause 6.3.4. 2233 OtherRevRefs ::= SEQUENCE { 2234 OtherRevRefType OtherRevRefType, 2235 OtherRevRefs ANY DEFINED BY otherRevRefType 2236 } 2238 OtherRevRefType ::= OBJECT IDENTIFIER 2239 The syntax and semantics of other revocation references is outside the 2240 scope of the present document. The definition of the syntax of the 2241 other form of revocation information is as identified by 2242 OtherRevRefType. 2243 This attribute MAY include the references to the full set of the CRL, 2244 ACRL or OCSP responses that have been used to verify the certification 2245 chain for any TSUs that provides time-stamp tokens. In this case the 2246 unsigned attribute shall be added to the signData of the relevant 2247 timestamp token as an unsignedAttrs in the signerInfos field. 2249 6.2.3 Attribute certificate references attribute definition 2251 This attribute is only used when an user attribute certificate is 2252 present in the electronic signature. 2254 The attribute-certificate-references attribute is an unsigned 2255 attribute. It references the full set of AA certificates that have 2256 been used to validate the attribute certificate. Only a single 2257 instance of this attribute shall occur with an electronic signature. 2259 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) member- 2260 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 44} 2262 The attribute-certificate-references attribute value has the ASN.1 2263 syntax AttributeCertificateRefs. 2265 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 2267 OtherCertID is defined in clause 5.8.2. 2269 NOTE: Copies of the certificate values may be held using the 2270 certificate-values attribute defined in clause 6.3.3. 2272 6.2.4 Attribute revocation references attribute definition 2274 This attribute is only used when a user attribute certificate is 2275 present in the electronic signature and when that attribute certificate 2276 can be revoked. 2278 The attribute-revocation-references attribute is an unsigned attribute. 2279 Only a single instance of this attribute shall occur with an electronic 2280 signature. It references the full set of the ACRL or OCSP responses 2281 that have been used in the validation of the attribute certificate. 2282 This attribute can be used to illustrate that the verifier has taken 2283 due diligence of the available revocation information. 2285 The following object identifier identifies the attribute-revocation- 2286 references attribute: 2288 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) member- 2289 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 45} 2291 The attribute-revocation-references attribute value has the ASN.1 2292 syntax AttributeRevocationRefs. 2293 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 2295 6.3 Extended validation data (CAdES-X) 2297 This clause specifies a number of optional attributes that are used by 2298 extended forms of electronic signatures (see annex B for an overview 2299 these forms of validation data). 2301 6.3.1 Time-stamped validation data (CAdES-X Type 1 or Type 2) 2303 The extended validation data MAY include one of the following 2304 additional attributes, forming a CAdES-X Time-Stamp validation data 2305 (CAdES-X Type 1 or CAdES-X Type 2), to provide additional protection 2306 against later CA compromise and provide integrity of the validation 2307 data used: 2309 - CAdES-C Time-stamp, as defined in clause 6.3.5 (CAdES-X Type 1); 2310 or 2312 - Time-Stamped Certificates and CRLs references, as defined in 2313 clause 6.3.6 (CAdES-X Type 2). 2315 6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2) 2317 The extended validation data MAY also include the following additional 2318 information, forming a CAdES-X Long, for use if later validation 2319 processes may not have access to this information: 2321 - certificate-values as defined in clause 6.3.3; 2322 - revocation-values as defined in clause 6.3.4. 2324 The extended validation data MAY in addition to certificate-values and 2325 revocation-values as defined in clauses 6.3.3 and 6.3.4 include one of 2326 the following additional attributes, forming an CAdES-X Long Type 1 or 2327 CAdES-X Long Type 2. 2329 - CAdES-C Time-stamp, as defined in clause 6.3.3 (CAdES-X long Type 2330 1); or 2332 - Time-Stamped Certificates and CRLs references, as defined in 2333 clause 6.3.4 (CAdES-X Long Type 2). 2335 The CAdES-X Long Type 1 or CAdES-X Long Type 2 provide additional 2336 protection against later CA compromise and provide integrity of the 2337 validation data used. 2339 NOTE 1: The CAdES-X Long provides long term proof of a valid 2340 electronic signature as long as the CAs are trusted such that 2341 these keys cannot be compromised or the cryptography used 2342 broken. 2343 NOTE 2: As long as the time stamp data remains valid, the CAdES-X 2344 Long Type 1 and the CAdES-X Long Type 2 provides the following 2345 important property for long standing signatures; that having 2346 been found once to be valid, it shall continue to be so months 2347 or years later, long after the validity period of the 2348 certificates have expired, or after the user key has been 2349 compromised. 2351 6.3.3 Certificate values attribute definition 2353 This attribute MAY be used to contain the certificate information 2354 required for the following forms of eXtended Electronic Signature: 2355 CAdES-X Long , ES X-Long Type 1 and CAdES-X Long Type 2, see clause 2356 B.1.1 for an illustration of this form of electronic signature. 2358 The certificate-values attribute is an unsigned attribute. Only a 2359 single instance of this attribute shall occur with an electronic 2360 signature. It holds the values of certificates referenced in the 2361 complete-certificate-references attribute. 2363 NOTE: If an attribute certificate is used, it is not provided in this 2364 structure but shall be provided by the signer as a signer- 2365 attributes attribute (see clause 5.11.3). 2367 The following object identifier identifies the certificate-values 2368 attribute: 2370 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2371 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 2373 The certificate-values attribute value has the ASN.1 syntax 2374 CertificateValues 2376 CertificateValues ::= SEQUENCE OF Certificate 2378 Certificate is defined in clause 7.1 (which is as defined in ITU-T 2379 Recommendation X.509 [1]). 2381 This attribute MAY include the certification information for any TSUs 2382 that have provided the time-stamp tokens if these certificates are not 2383 already included in the TSTs as part of the TSUs signatures. In this 2384 case the unsigned attribute shall be added to the signData of the 2385 relevant timestamp token. 2387 6.3.4 Revocation values attribute definition 2389 This attribute is used to contain the revocation information required 2390 for the following forms of eXtended Electronic Signature: CAdES-X Long, 2391 ES X-Long Type 1 and CAdES-X Long Type 2, see clause B.1.1 for an 2392 illustration of this form of electronic signature. 2394 The revocation-values attribute is an unsigned attribute. Only a 2395 single instance of this attribute shall occur with an electronic 2396 signature. It holds the values of CRLs and OCSP referenced in the 2397 complete-revocation-references attribute. 2399 The following object identifier identifies the revocation-values 2400 attribute: 2402 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 2403 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2404 smime(16) id-aa(2) 24} 2406 The revocation-values attribute value has the ASN.1 syntax 2407 RevocationValues 2409 RevocationValues ::= SEQUENCE { 2410 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 2411 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 2412 otherRevVals [2] OtherRevVals OPTIONAL} 2414 OtherRevVals ::= SEQUENCE { 2415 OtherRevValType OtherRevValType, 2416 OtherRevVals ANY DEFINED BY OtherRevValType 2417 } 2419 OtherRevValType ::= OBJECT IDENTIFIER 2421 The syntax and semantics of the other revocation values (OtherRevVals) 2422 is outside the scope of the present document. The definition of the 2423 syntax of the other form of revocation information is as identified by 2424 OtherRevRefType. 2426 CertificateList is defined in clause 7.2 (which as defined in ITU-T 2427 Recommendation X.509 [1]). 2429 BasicOCSPResponse is defined in clause 7.3 (which as defined in RFC 2430 2560 [3]). 2432 This attribute MAY include the values of revocation data including CRLs 2433 and OCSP for any TSUs that have provided the time-stamp tokens if these 2434 certificates are not already included in the TSTs as part of the TSUs 2435 signatures. In this case the unsigned attribute shall be added to the 2436 signData of the relevant timestamp token. 2438 6.3.5 CAdES-C time-stamp attribute definition 2440 This attribute is used to protect against CA key compromise. 2441 This attribute is used for the time stamping the complete electronic 2442 signature (CAdES-C). It is used in the following forms of eXtended 2443 Electronic Signature; CAdES-X Type 1 and CAdES-X Long Type 1, see 2444 clause B.1.2 for an illustration of this form of electronic signature. 2446 The CAdES-C-timestamp attribute is an unsigned attribute. It is a 2447 time-stamp token of the hash of the electronic signature and the 2448 complete validation data (CAdES-C). It is a special purpose 2449 TimeStampToken Attribute which time-stamps the CAdES-C. Several 2450 instances of this attribute may occur with an electronic signature from 2451 different TSAs. 2453 The following object identifier identifies the CAdES-C-Timestamp 2454 attribute: 2456 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2457 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 2459 The CAdES-C-timestamp attribute value has the ASN.1 syntax 2460 ESCTimeStampToken. 2462 ESCTimeStampToken ::= TimeStampToken 2464 The value of messageImprint field within TimeStampToken shall be a hash 2465 of the concatenated values (without the type or length encoding for 2466 that value) of the following data objects: 2468 - OCTETSTRING of the SignatureValue field within SignerInfo; 2470 - signature-time-stamp; or a time mark operated by a Time-Marking 2471 Authority; 2473 - complete-certificate-references s attribute; 2475 - complete-revocation-references attribute. 2477 For further information and definition of the TimeStampToken see 2478 clause 7.4. 2480 6.3.6 Time-stamped certificates and crls references attribute 2481 definition 2483 This attribute is used to protect against CA key compromise. 2485 This attribute is used for the time stamping certificate and revocation 2486 references. It is used in the following forms of eXtended Electronic 2487 Signature; CAdES-X Type 2 and CAdES-X Long Type 2, see clause B.1.3 for 2488 an illustration of this form of electronic signature. 2490 A time-stamped-certs-crls-references attribute is an unsigned 2491 attribute. It is a time-stamp token issued for a list of referenced 2492 certificates and OCSP responses/CRLs to protect against certain CA 2493 compromises. Its syntax is as follows: 2495 The following object identifier identifies the time-stamped-certs-crls- 2496 references attribute: 2498 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member 2499 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} 2500 The attribute value has the ASN.1 syntax TimestampedCertsCRLs. 2502 TimestampedCertsCRLs ::= TimeStampToken 2504 The value of messageImprint field within TimeStampToken shall be a hash 2505 of the concatenated values (without the type or length encoding for 2506 that value) of the following data objects as present in the ES with 2507 Complete validation data: 2509 - complete-certificate-references attribute; 2510 - complete-revocation-references attribute. 2512 6.4 Archive validation data 2514 Where an electronic signature is required to last for a very long time, 2515 and a the time-stamp token on an electronic signature is in danger of 2516 being invalidated due to algorithm weakness or limits in the validity 2517 period of the TSA certificate, then it may be required to time-stamp 2518 the electronic signature several times. When this is required an 2519 archive time-stamp attribute may be required for the archive form of 2520 electronic signature (CAdES-A). This archive time-stamp attribute may 2521 be repeatedly applied over a period of time. 2523 6.4.1 Archive time-stamp attribute definition 2525 The archive-time-stamp attribute is a time-stamp token of many of the 2526 elements of the signedData in the electronic signature. If the 2527 certificate-values and revocation-values attributes are not present in 2528 the CAdES-BES or CAdES-EPES, then they shall be added to the electronic 2529 signature prior to computing the archive time-stamp token. The 2530 archive-time-stamp attribute is an unsigned attribute. Several 2531 instances of this attribute may occur with an electronic signature both 2532 over time and from different TSUs. 2534 The following object identifier identifies the nested archive-time- 2535 stamp attribute: 2537 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2538 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27} 2539 Archive-time-stamp attribute values have the ASN.1 syntax 2540 ArchiveTimeStampToken 2542 ArchiveTimeStampToken ::= TimeStampToken 2544 The value of messageImprint field within TimeStampToken shall be a hash 2545 of the concatenation of: 2547 - The encapContentInfo element of the SignedData sequence; 2549 - When present, the Certificates and crls elements of the 2550 SignedData sequence; 2552 - Together with all data elements in the SignerInfo sequence 2553 including all signed and unsigned attributes. 2555 NOTE 1: The SignedData definition is the following: 2557 SignedData ::= SEQUENCE { 2558 version CMSVersion, 2559 digestAlgorithms DigestAlgorithmIdentifiers, 2560 encapContentInfo EncapsulatedContentInfo, 2561 certificates [0] IMPLICIT CertificateSet OPTIONAL, 2562 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 2563 signerInfos SignerInfos } 2565 NOTE 2: SignerInfo definition is as follows: 2567 SignerInfo ::= SEQUENCE { 2568 version CMSVersion, 2569 sid SignerIdentifier, 2570 digestAlgorithm DigestAlgorithmIdentifier, 2571 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 2572 signatureAlgorithm SignatureAlgorithmIdentifier, 2573 signature SignatureValue, 2574 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2576 Further information and definition of TimeStampToken see clause 7.4. 2577 The timestamp should be created using stronger algorithms (or longer 2578 key lengths) than in the original electronic signatures and weak 2579 algorithm (key length) timestamps. 2581 NOTE 3: This form of ES also provides protection against a TSP key 2582 Compromise. 2584 The ArchiveTimeStamp will be added as an unsigned attribute in the 2585 SignerInfo sequence. For the validation of one ArchiveTimeStamp the 2586 data elements of the SignerInfo must be concatenated excluding all 2587 later ArchivTimeStampToken attributes. 2589 Certificates and revocation information required to validate the 2590 ArchiveTimeStampshall be provided by one of the following methods: 2592 - The TSU provides the information in the SignedData of the 2593 timestamp token; 2595 - Adding the complete-certificate-references attribute and the 2596 complete-revocation-references attribute of the TSP as an 2597 unsigned attribute within TimeStampToken, when the required 2598 information is store elsewhere; 2600 - Adding the certificate-values attribute and the revocation-values 2601 attribute of the TSP as an unsigned attribute within 2602 TimeStampToken, when the required information is store elsewhere. 2604 7 Other standard data structures 2606 7.1 Public-key certificate format 2608 The X.509 v3 certificate basis syntax is defined in ITU-T 2609 Recommendation X.509 [1]. A profile of the X.509 v3 certificate is 2610 defined in RFC 3280 [2], which is being revised. The reader should 2611 consult the latest version of this RFC or any RFC that makes it 2612 obsolete. 2614 7.2 Certificate revocation list format 2616 The X.509 v2 CRL syntax is defined in ITU-T Recommendation X.509 [1]. 2617 A profile of the X.509 v2 CRL is defined in RFC 3280 [2], which is 2618 being revised. 2620 7.3 OCSP response format 2622 The format of an OCSP token is defined in RFC 2560 [3]. 2624 7.4 Time-stamp token format 2626 The format of a TimeStampToken type is defined in RFC 3161 [7] and TS 2627 101 861 (see informative references). 2629 7.5 Name and attribute formats 2631 The syntax of the naming and other attributes is defined in ITU-T 2632 Recommendation X.509 [1]. 2634 The name used by the signer, held as the subject in the signer's 2635 certificate, shall be allocated and verified on registration with the 2636 Certification Authority, either directly or indirectly through a 2637 Registration Authority, before being issued with a Certificate. 2639 The present document places no restrictions on the form of the name. 2640 The subject's name may be a distinguished name, as defined in ITU-T 2641 Recommendation X.500 [12], held in the subject field of the 2642 certificate, or any other name form held in the subjectAltName 2643 certificate extension field as defined in ITU-T Recommendation X.509 2644 [1]. In the case that the subject has no distinguished name, the 2645 subject name can be an empty sequence and the subjectAltName extension 2646 shall be critical. 2648 All TSP name forms (Certification Authorities, Attribute Authorities 2649 and Time Stamping Authorities) shall be in the form of a distinguished 2650 name held in the subject field of the certificate. 2652 The TSP name form shall include identifiers for the organization 2653 providing the service and the legal jurisdiction (e.g. country) under 2654 which it operates. 2656 Where a signer signs as an individual but wishes to also identify 2657 him/herself as acting on behalf of an organization, it may be necessary 2658 to provide two independent forms of identification. The first 2659 identity, with is directly associated with the signing key identifies 2660 him/her as an individual. The second, which is managed independently, 2661 identifies that person acting as part of the organization, possibly 2662 with a given role. 2664 In this case one of the two identities is carried in the 2665 subject/subjectAltName field of the signer's certificate as described 2666 above. 2668 The present document does not specify the format of signer's attribute 2669 that may be included in public key certificates. 2671 NOTE : Signer's attribute may be supported by using a claimed role in 2672 the CMS signed attributes field or by placing an attribute 2673 certificate containing a certified role in the CMS signed 2674 attributes field, see clause 7.6. 2676 7.6 Attribute certificate 2678 The syntax of the AttributeCertificate type is defined in RFC 3281 [13]. 2680 8. Conformance requirements 2682 The present document defines conformance requirements for the 2683 generation of two forms of basic electronic signature, one of the two 2684 forms must be implemented. 2686 The present document defines conformance requirements for the 2687 verification of two forms of basic electronic signature, one of the two 2688 forms must be implemented. 2690 The present document only defines conformance requirements up to an ES 2691 with Complete validation data (CAdES-C). This means that none of the 2692 extended and archive forms of Electronic Signature (CAdES-X, CAdES-A) 2693 need to be implemented to get conformance to the present document. 2695 On verification the inclusion of optional signed and unsigned 2696 attributes must be supported only to the extended that the signature is 2697 verifiable. The semantics of optional attributes may be unsupported, 2698 unless specified otherwise by a signature policy. 2700 8.1 CAdES-Basic Electronic Signature (CAdES-BES) 2702 A system supporting CAdES-BES signers according to the present document 2703 shall, at a minimum, support generation of an electronic signature 2704 consisting of the following components: 2706 - The general CMS syntax and content type as defined in RFC 3852 2707 [4] (see clauses 5.1 and 5.2); 2709 - CMS SignedData as defined in RFC 3852 [4] with version set to 3 2710 and at least one SignerInfo shall be present (see clauses 5.3 to 2711 5.6); 2713 - The following CMS attributes as defined in RFC 3852 [4]: 2715 - content-type; this shall always be present (see clause 5.7.1); 2717 - message-digest; this shall always be present (see 2718 clause 5.7.2). 2720 - One of following attributes as defined in the present document: 2722 - signing-certificate: as defined in clause 5.7.3.1; 2723 - Other-Signing-Certificate as defined in clause 5.7.3.2. 2725 8.2 CAdES-Explicit Policy-based Electronic Signature 2727 A system supporting Policy-based signers according to the present 2728 document shall, at a minimum, support generation of an electronic 2729 signature consisting of the previous components defined for the basic 2730 signer, plus: 2732 - The following attributes as defined in clause 5.9: 2734 - signature-policy-identifier; this shall always be present (see 2735 clause 5.8.1). 2737 8.3 Verification using time-stamping 2739 A system supporting verifiers according to the present document with 2740 time-stamping facilities shall, at a minimum, support: 2742 - verification of the mandated components of an electronic 2743 signature, as defined in clause 8.1. 2745 - signature-time-stamp attribute, as defined in clause 6.1.1. 2747 - complete-certificate-references, attribute as defined in 2748 clause 6.2.1. 2750 - complete-revocation-references attribute, as defined in 2751 clause 6.2.2. 2753 - Public Key Certificates, as defined in ITU-T Recommendation X.509 2754 [1] (see clause 8.1). 2756 - either of: 2758 - Certificate Revocation Lists. as defined in ITU-T 2759 Recommendation X.509 [1] (see clause 8.2); or 2761 - on-line Certificate Status Protocol, as defined in RFC 2560 2762 [3] (see clause 8.3). 2764 8.4 Verification using secure records 2766 A system supporting verifiers according to the present document shall, 2767 at a minimum, support: 2769 - verification of the mandated components of an electronic 2770 signature, as defined in clause 8.1; 2772 - complete-certificate-references attribute, as defined in 2773 clause 6.2.1; 2775 - complete-revocation-references attribute, as defined in 2776 clause 6.2.2; 2778 - a record must be maintained and cannot be undetectable modified, 2779 of the electronic signature and the time when the signature was 2780 first validated using the referenced certificates and revocation 2781 information; 2783 - Public Key Certificates, as defined in ITU-T Recommendation X.509 2784 [1] (see clause 8.1); 2786 - either of: 2788 - Certificate Revocation Lists. as defined in ITU-T 2789 Recommendation X.509 [1] (see clause 8.2); or 2791 - on-line Certificate Status Protocol, as defined in RFC 2560 2792 [3] (see clause 8.3). 2794 9. Security considerations 2796 9.1 Protection of private key 2798 The security of the electronic signature mechanism defined in the 2799 present document depends on the privacy of the signer's private key. 2800 Implementations should take steps to ensure that private keys cannot be 2801 compromised. 2803 9.2 Choice of algorithms 2805 Implementers should be aware that cryptographic algorithms become 2806 weaker with time. As new cryptoanalysis techniques are developed and 2807 computing performance improves, the work factor to break a particular 2808 cryptographic algorithm will reduce. Therefore, cryptographic 2809 algorithm implementations should be modular allowing new algorithms to 2810 be readily inserted. That is, implementers should be prepared for the 2811 set of mandatory to implement algorithms to change over time. 2813 10. IANA Considerations 2815 Not applicable 2817 11. References 2819 11.1 Normative references 2821 [1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001): 2822 "Information technology - Open Systems Interconnection - 2823 The Directory: Authentication framework". 2825 [2] IETF RFC 3280 (2002): "Internet X.509 Public Key 2826 Infrastructure Certificate and Certificate Revocation List 2827 (CRL) Profile". 2829 [3] IETF RFC 2560 (1999): "X.509 Internet Public Key 2830 Infrastructure Online Certificate Status Protocol - OCSP". 2832 [4] IETF RFC 3852 (2004): "Cryptographic Message Syntax (CMS)". 2834 [5] IETF RFC 2634 (1999): "Enhanced Security Services for 2835 S/MIME". 2837 [6] IETF RFC 2045 (1996): "Multipurpose Internet Mail Extensions 2838 (MIME) Part One: Format of Internet Message Bodies". 2840 [7] IETF RFC 3161 (2001): "Internet X.509 Public Key 2841 Infrastructure Time-Stamp Protocol (TSP)". 2843 [8] ITU-T Recommendation X.680 (1997): "Information technology - 2844 Abstract Syntax Notation One (ASN.1): Specification of basic 2845 notation". 2847 [9] ITU-T Recommendation X.501 (2000)/ISO/IEC 9594-1 (2001): 2848 "Information technology - Open Systems Interconnection - 2849 Directory models ". 2851 [10] IETF RFC 3370 (2002): "Cryptographic Message Syntax (CMS) 2852 Algorithms". 2854 [11] ITU-T Recommendation F.1: "Operational provisions for the 2855 international public telegram service". 2857 [12] ITU-T Recommendation X.500: "Information technology - Open 2858 Systems Interconnection - The Directory: Overview of 2859 concepts, models and services". 2861 [13] IETF RFC 3281 (2002): "An Internet Attribute Certificate 2862 Profile for Authorization". 2864 [14] ITU-T Recommendation X.208 (1988): "Specification of Abstract 2865 Syntax Notation One (ASN.1)". 2867 Referenced documents hereabove which are not found to be publicly 2868 available in the expected location might be found at 2869 http://docbox.etsi.org/Reference. 2871 [STDWORDS] IETF RFC 2119 Bradner, S., "Key words for use in RFCs to 2872 Indicate Requirement Levels", BCP 14, RFC 2 2874 11.2 Informative references 2876 Directive 1999/93/EC of the European Parliament and of the Council 2877 of 13 December 1999 on a Community framework for electronic 2878 signatures. 2880 ETSI Standard TS 101 733 V.1.6.3 (2005-06) Electronic Signature 2881 Formats. Note: copies of ETSI TS 101 733 can be freely downloaded 2882 from the ETSI web site www.etsi.org. 2884 IETF RFC 2246 (1999): "The TLS Protocol Version 1.0". 2886 IETF RFC 2437 (1998): "PKCS #1: RSA Cryptography Specifications 2887 Version 2.0". 2889 IETF RFC 2479 (1998): "Independent Data Unit Protection Generic 2890 Security Service Application Program Interface (IDUP-GSS-API)". 2892 IETF RFC 2510 (1999): "Internet X.509 Public Key Infrastructure 2893 Certificate Management Protocols". 2895 IETF RFC 2587 (1999): "Internet X.509 Public Key Infrastructure 2896 LDAPv2 Schema". 2898 IETF RFC 3125 (2000): "Electronic Signature Policies". 2900 IETF RFC 2559 (2003): "Internet X.509 Public Key Infrastructure 2901 Operational Protocols - LDAPv2". 2903 ETSI TS 101 861: "Time stamping profile". 2905 ETSI TS 101 903: "XML Advanced Electronic Signatures (XAdES)". 2907 ETSI TS 102 023: "Electronic Signatures and Infrastructures (ESI); 2908 Policy requirements for time-stamping authorities". 2910 ETSI TS 102 038: "Electronic Signatures and Infrastructures (ESI); 2911 XML format for signature policies". 2913 ETSI TR 102 272. "Electronic Signatures and Infrastructures (ESI); 2914 ASN.1 format for signature policies". 2916 ISO 7498-2 (1989): "Information processing systems - Open Systems 2917 Interconnection - Basic Reference Model - Part 2: Security 2918 Architecture". 2920 ISO/IEC 13888-1 (2004): "IT security techniques - Non-repudiation - 2921 Part 1: General". 2923 ISO/IEC 9796-2 (2002): "Information technology - Security techniques 2924 - Digital signature schemes giving message recovery - Part 2: 2925 Integer factorization based mechanisms". 2927 ISO/IEC 9796-4 (1998): "Digital signature schemes giving message 2928 recovery - Part 4: Discrete logarithm based mechanisms". 2930 ISO/IEC 10118-1 (2000): "Information technology - Security 2931 techniques - Hash-functions - Part 1: General". 2933 ISO/IEC 10118-2 (2000): "Information technology - Security 2934 techniques - Hash-functions - Part 2: Hash-functions using an n-bit 2935 block cipher algorithm". 2937 ISO/IEC 10118-3 (2004): "Information technology - Security 2938 techniques - Hash-functions - Part 3: Dedicated hash-functions". 2940 ISO/IEC 10118-4 (1998): "Information technology - Security 2941 techniques - Hash-functions - Part 4: Hash-functions using modular 2942 arithmetic". 2944 ISO/IEC 14888-1 (1998): "Information technology - Security 2945 techniques - Digital signatures with appendix - Part 1: General". 2947 ISO/IEC 14888-2 (1999): "Information technology - Security 2948 techniques - Digital signatures with appendix - Part 2: Identity- 2949 based mechanisms". 2951 ISO/IEC 14888-3 (1998): "Information technology - Security 2952 techniques - Digital signatures with appendix - Part 3: Certificate- 2953 based mechanisms". 2955 ISO/IEC 15946-2 (2002): "Information technology - Security 2956 techniques - Cryptographic techniques based on elliptic curves - 2957 Part 2: Digital signatures". 2959 ISO/IEC 15946-3 (2002): "Information technology - Security 2960 techniques - Cryptographic techniques based on elliptic curves - 2961 Part 3: Key establishment". 2963 ISO/IEC 10181-5: Security Frameworks in Open Systems. 2964 Non-Repudiation Framework. April 1997. 2966 ITU-T Recommendation X.690 (2002): "Specification of basic encoding 2967 rules for Abstract Syntax Notation One (ASN.1)". 2969 CWA 14171 CEN Workshop Agreements: "General Guidelines for 2970 Electronic Signature Verification". 2972 XMLDSIG: W3C/IETF Recommendation (February 2002): "XML-Signature 2973 Syntax and Processing". 2975 ANSI X9.30-1 (1997): "Public Key Cryptography for the Financial 2976 Services Industry - Part 1: The Digital Signature Algorithm (DSA)". 2978 ANSI X9.30-2 (1997): "Public Key Cryptography for the Financial 2979 Services Industry - Part 2: The Secure Hash Algorithm (SHA-1)". 2981 ANSI X9.31-1 (1997): "Public Key Cryptography Using Reversible 2982 Algorithms for the Financial Services Industry - 2983 Part 1: The RSA Signature Algorithm". 2985 ANSI X9.31-2 (1996): "Public Key Cryptography Using Reversible 2986 Algorithms for the Financial Services Industry - 2987 Part 2: Hash Algorithms". 2989 ANSI X9.62 (1998): "Public Key Cryptography for the Financial 2990 Services Industry - The Elliptic Curve Digital Signature Algorithm 2991 (ECDSA)". 2993 IEEE P1363 (2000): "Standard Specifications for Public-Key 2994 Cryptography". 2996 12. Authors' addresses 2998 Denis Pinkas 2999 Bull S.A. 3000 Rue Jean-Jaures 3001 78340 Les Clayes sous Bois CEDEX 3002 FRANCE 3004 EMail: Denis.Pinkas@bull.net 3006 Nick Pope 3007 Security & Standards 3008 192 Moulsham Street 3009 Chelmsford, Essex 3010 CM2 0LG 3011 United Kingdom 3013 EMail: pope@secstan.com 3015 John Ross 3016 Security & Standards 3017 192 Moulsham Street 3018 Chelmsford, Essex 3019 CM2 0LG 3020 United Kingdom 3022 EMail: ross@secstan.com 3024 This Informational RFC has been produced in ETSI TC-ESI. 3026 ETSI 3027 F-06921 Sophia Antipolis, Cedex - FRANCE 3028 650 Route des Lucioles - Sophia Antipolis 3029 Valbonne - France 3030 Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 3031 secretariat@etsi.fr 3032 http://www.etsi.org 3034 Annex A (normative): ASN.1 definitions 3036 This annex provides a summary of all the ASN.1 syntax definitions for 3037 new syntax defined in the present document. 3039 A.1 Signature format definitions using X.208 ASN.1 syntax 3041 NOTE: The ASN.1 module defined in clause A.1 using syntax defined in 3042 ITU-T Recommendation X.208 [14] has precedence over that 3043 defined in clause A.2 in the case of any conflict. 3045 ETS-ElectronicSignatureFormats-ExplicitSyntax88 { iso(1) member-body(2) 3046 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 3047 eSignature-explicit88(28)} 3049 DEFINITIONS EXPLICIT TAGS ::= 3051 BEGIN 3053 -- EXPORTS All 3055 IMPORTS 3057 -- Cryptographic Message Syntax (CMS): RFC 3852 3059 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3060 EncapsulatedContentInfo, SignerInfo, id-contentType, 3061 id-messageDigest, MessageDigest, id-signingTime, SigningTime, 3062 id-countersignature, Countersignature 3063 FROM CryptographicMessageSyntax2004 3064 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3065 smime(16) modules(0) cms-2004(24) } 3067 -- ESS Defined attributes: RFC 2634 (Enhanced Security Services 3068 -- for S/MIME) 3070 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3071 id-aa-contentReference, ContentReference, id-aa-contentIdentifier, 3072 ContentIdentifier 3073 FROM ExtendedSecurityServices 3074 { iso(1) member-body(2) us(840) rsadsi(113549) 3075 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 3077 -- Internet X.509 Public Key Infrastructure - Certificate and CRL 3078 -- Profile: RFC 3280 3080 Certificate, AlgorithmIdentifier, CertificateList, Name, 3081 DirectoryString, Attribute, BMPString, UTF8String 3082 FROM PKIX1Explicit88 3083 {iso(1) identified-organization(3) dod(6) internet(1) 3084 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} 3086 GeneralNames, GeneralName, PolicyInformation 3087 FROM PKIX1Implicit88 3088 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 3089 mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit (19)} 3091 -- Internet Attribute Certificate Profile for Authorization - RFC 3281 3093 AttributeCertificate 3094 FROM PKIXAttributeCertificate {iso(1) identified-organization(3) 3095 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3096 id-mod(0) id-mod-attribute-cert(12)} 3098 -- OCSP - RFC 2560 3100 BasicOCSPResponse, ResponderID 3101 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 3102 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 3104 -- Time Stamp Protocol RFC 3161 3106 TimeStampToken 3107 FROM PKIXTSP 3108 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 3109 mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}; 3111 -- S/MIME Object Identifier arcs used in the present document 3112 -- ========================================================== 3114 -- S/MIME OID arc used in the present document 3115 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3116 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 3118 -- S/MIME Arcs 3119 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 3120 -- modules 3121 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 3122 -- content types 3123 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 3124 -- attributes 3125 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 3126 -- signature policy qualifier 3127 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 3128 -- commitment type identifier 3130 -- Definitions of Object Identifier arcs used in the present document 3131 -- ================================================================== 3133 -- The allocation of OIDs to specific objects are given below with 3134 -- the associated ASN.1 syntax definition 3136 -- OID used referencing electronic signature mechanisms based on 3137 -- the present document for use with the IDUP API (see annex D) 3138 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3139 { itu-t(0) identified-organization(4) etsi(0) 3140 electronic-signature-standard (1733) part1 (1) idupMechanism (4) 3141 etsiESv1(1) } 3143 -- Basic ES CMS Attributes Defined in the present document 3144 -- ======================================================= 3146 -- Mandatory RFC 3852 Electronic Signature Attributes 3148 -- OtherSigningCertificate 3150 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 3151 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3152 smime(16) id-aa(2) 19 } 3154 OtherSigningCertificate ::= SEQUENCE { 3155 certs SEQUENCE OF OtherCertID, 3156 policies SEQUENCE OF PolicyInformation OPTIONAL 3157 -- NOT USED IN THE PRESENT DOCUMENT 3158 } 3160 OtherCertID ::= SEQUENCE { 3161 otherCertHash OtherHash, 3162 issuerSerial IssuerSerial OPTIONAL } 3164 OtherHash ::= CHOICE { 3165 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3166 otherHash OtherHashAlgAndValue} 3168 OtherHashValue ::= OCTET STRING 3170 OtherHashAlgAndValue ::= SEQUENCE { 3171 hashAlgorithm AlgorithmIdentifier, 3172 hashValue OtherHashValue } 3174 -- Policy ES Attributes Defined in the present document 3175 -- ==================================================== 3177 -- Mandatory Basic Electronic Signature Attributes as above, 3178 -- plus in addition. 3180 -- Signature Policy Identifier 3182 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 3183 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3184 smime(16) id-aa(2) 15 } 3185 SignaturePolicy ::= CHOICE { 3186 signaturePolicyId SignaturePolicyId, 3187 signaturePolicyImplied SignaturePolicyImplied 3188 -- not used in this version 3189 } 3191 SignaturePolicyId ::= SEQUENCE { 3192 sigPolicyId SigPolicyId, 3193 sigPolicyHash SigPolicyHash OPTIONAL, 3194 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3195 SigPolicyQualifierInfo OPTIONAL 3196 } 3198 SignaturePolicyImplied ::= NULL 3200 SigPolicyId ::= OBJECT IDENTIFIER 3202 SigPolicyHash ::= OtherHashAlgAndValue 3204 SigPolicyQualifierInfo ::= SEQUENCE { 3205 sigPolicyQualifierId SigPolicyQualifierId, 3206 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 3208 SigPolicyQualifierId ::= OBJECT IDENTIFIER 3210 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 3211 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3212 smime(16) id-spq(5) 1 } 3214 SPuri ::= IA5String 3216 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 3217 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3218 smime(16) id-spq(5) 2 } 3220 SPUserNotice ::= SEQUENCE { 3221 noticeRef NoticeReference OPTIONAL, 3222 explicitText DisplayText OPTIONAL} 3224 NoticeReference ::= SEQUENCE { 3225 organization DisplayText, 3226 noticeNumbers SEQUENCE OF INTEGER } 3228 DisplayText ::= CHOICE { 3229 visibleString VisibleString (SIZE (1..200)), 3230 bmpString BMPString (SIZE (1..200)), 3231 utf8String UTF8String (SIZE (1..200)) } 3233 -- Optional Electronic Signature Attributes 3235 -- Commitment Type 3237 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3238 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3240 CommitmentTypeIndication ::= SEQUENCE { 3241 commitmentTypeId CommitmentTypeIdentifier, 3242 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3243 CommitmentTypeQualifier OPTIONAL} 3245 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3247 CommitmentTypeQualifier ::= SEQUENCE { 3248 commitmentTypeIdentifier CommitmentTypeIdentifier, 3249 qualifier ANY DEFINED BY commitmentTypeIdentifier } 3251 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3252 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 3254 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3255 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 3257 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 3258 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} 3260 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3261 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 3263 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 3264 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} 3266 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 3267 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} 3269 -- Signer Location 3271 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3272 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3273 SignerLocation ::= SEQUENCE { 3274 -- at least one of the following shall be present 3275 countryName [0] DirectoryString OPTIONAL, 3276 -- As used to name a Country in X.500 3277 localityName [1] DirectoryString OPTIONAL, 3278 -- As used to name a locality in X.500 3279 postalAdddress [2] PostalAddress OPTIONAL } 3281 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 3283 -- Signer Attributes 3285 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3286 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3288 SignerAttribute ::= SEQUENCE OF CHOICE { 3289 claimedAttributes [0] ClaimedAttributes, 3290 certifiedAttributes [1] CertifiedAttributes } 3292 ClaimedAttributes ::= SEQUENCE OF Attribute 3294 CertifiedAttributes ::= AttributeCertificate 3295 -- as defined in RFC 3281 : see clause 4.1 3297 -- Content Timestamp 3299 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3300 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} 3302 ContentTimestamp::= TimeStampToken 3304 -- Signature Timestamp 3306 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member- 3307 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} 3309 SignatureTimeStampToken ::= TimeStampToken 3311 -- Complete Certificate Refs. 3313 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3314 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3316 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 3317 -- Complete Revocation Refs 3319 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3320 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3322 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3324 CrlOcspRef ::= SEQUENCE { 3325 crlids [0] CRLListID OPTIONAL, 3326 ocspids [1] OcspListID OPTIONAL, 3327 otherRev [2] OtherRevRefs OPTIONAL 3328 } 3330 CRLListID ::= SEQUENCE { 3331 crls SEQUENCE OF CrlValidatedID} 3333 CrlValidatedID ::= SEQUENCE { 3334 crlHash OtherHash, 3335 crlIdentifier CrlIdentifier OPTIONAL} 3337 CrlIdentifier ::= SEQUENCE { 3338 crlissuer Name, 3339 crlIssuedTime UTCTime, 3340 crlNumber INTEGER OPTIONAL 3341 } 3343 OcspListID ::= SEQUENCE { 3344 ocspResponses SEQUENCE OF OcspResponsesID} 3346 OcspResponsesID ::= SEQUENCE { 3347 ocspIdentifier OcspIdentifier, 3348 ocspRepHash OtherHash OPTIONAL 3349 } 3351 OcspIdentifier ::= SEQUENCE { 3352 ocspResponderID ResponderID, -- As in OCSP response data 3353 producedAt GeneralizedTime -- As in OCSP response data 3354 } 3356 OtherRevRefs ::= SEQUENCE { 3357 otherRevRefType OtherRevRefType, 3358 otherRevRefs ANY DEFINED BY otherRevRefType 3359 } 3361 OtherRevRefType ::= OBJECT IDENTIFIER 3363 -- Certificate Values 3365 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3366 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3368 CertificateValues ::= SEQUENCE OF Certificate 3370 -- Certificate Revocation Values 3372 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 3373 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3374 smime(16) id-aa(2) 24} 3376 RevocationValues ::= SEQUENCE { 3377 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3378 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3379 otherRevVals [2] OtherRevVals OPTIONAL} 3381 OtherRevVals ::= SEQUENCE { 3382 otherRevValType OtherRevValType, 3383 otherRevVals ANY DEFINED BY otherRevValType 3384 } 3386 OtherRevValType ::= OBJECT IDENTIFIER 3388 -- CAdES-C Timestamp 3390 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3391 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 3393 ESCTimeStampToken ::= TimeStampToken 3395 -- Time-Stamped Certificates and CRLs 3397 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) 3398 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3399 smime(16) id-aa(2) 26} 3401 TimestampedCertsCRLs ::= TimeStampToken 3403 -- Archive Timestamp 3405 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) 3406 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3407 smime(16) id-aa(2) 27} 3408 ArchiveTimeStampToken ::= TimeStampToken 3410 -- Attribute certificate references 3412 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) 3413 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3414 smime(16) id-aa(2) 44} 3416 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 3418 -- Attribute revocation references 3420 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) 3421 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3422 smime(16) id-aa(2) 45} 3424 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 3426 END 3427 A.2 Signature format definitions using X.680 ASN.1 syntax 3429 NOTE: The ASN.1 module defined in clause A.2 has precedence over that 3430 defined in clause A.2 using syntax defined in ITU-T 3431 Recommendation X.680 (1997) [8] in the case of any conflict. 3433 ETS-ElectronicSignatureFormats-ExplicitSyntax97 { iso(1) member-body(2) 3434 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 3435 eSignature-explicit97(29)} 3437 DEFINITIONS EXPLICIT TAGS ::= 3439 BEGIN 3441 -- EXPORTS All - 3443 IMPORTS 3445 -- Cryptographic Message Syntax (CMS): RFC 3852 3447 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3448 EncapsulatedContentInfo, SignerInfo, 3449 id-contentType, id-messageDigest, MessageDigest, id-signingTime, 3450 SigningTime, id-countersignature, Countersignature 3451 FROM CryptographicMessageSyntax2004 3452 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3453 smime(16) modules(0) cms-2004(24) } 3455 -- ESS Defined attributes: RFC 2634 3456 -- (Enhanced Security Services for S/MIME) 3458 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3459 id-aa-contentReference, ContentReference, id-aa-contentIdentifier, 3460 ContentIdentifier 3461 FROM ExtendedSecurityServices 3462 { iso(1) member-body(2) us(840) rsadsi(113549) 3463 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 3465 -- Internet X.509 Public Key Infrastructure 3466 -- Certificate and CRL Profile: RFC 3280 3468 Certificate, AlgorithmIdentifier, CertificateList, Name, 3469 DirectoryString, Attribute, 3470 FROM PKIX1Explicit88 3471 {iso(1) identified-organization(3) dod(6) internet(1) 3472 security(5) mechanisms(5) pkix(7) id-mod(0) 3473 id-pkix1-explicit(18)} 3475 GeneralNames, GeneralName, PolicyInformation 3476 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3477 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3478 id-pkix1-implicit(19)} 3480 -- Internet Attribute Certificate Profile for Authorization - RFC 3281 3482 AttributeCertificate 3483 FROM PKIXAttributeCertificate {iso(1) identified-organization(3) 3484 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3485 id-mod-attribute-cert(12)} 3487 -- OCSP RFC 2560 3489 BasicOCSPResponse, ResponderID 3490 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 3491 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 3493 -- RFC 3161 Internet X.509 Public Key Infrastructure 3494 -- Time-Stamp Protocol (TSP) 3496 TimeStampToken 3497 FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) 3498 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 3500 maxSize 3501 FROM ETS-ElectronicSignaturePolicies-97Syntax { iso(1) 3502 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3503 smime(16) id-mod(0) 8} 3505 ; 3507 -- S/MIME Object Identifier arcs used in the present document 3508 -- ========================================================== 3510 -- S/MIME OID arc used in the present document 3511 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3512 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 3514 -- S/MIME Arcs 3515 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 3516 -- modules 3517 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 3518 -- content types 3519 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 3520 -- attributes 3521 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 3522 -- signature policy qualifier 3523 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 3524 -- commitment type identifier 3526 -- Definitions of Object Identifier arcs used in the present document 3527 -- ================================================================== 3529 -- The allocation of OIDs to specific objects are given below 3530 -- with the associated ASN.1 syntax definition 3531 -- OID used referencing electronic signature mechanisms based 3532 -- on the present document for use with the IDUP API (see annex D) 3534 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3535 { itu-t(0) identified-organization(4) etsi(0) 3536 electronic-signature-standard (1733) part1 (1) idupMechanism (4) 3537 etsiESv1(1) } 3539 -- Basic ES Attributes Defined in the present document 3540 -- =================================================== 3542 -- CMS Attributes Defined in the present document 3544 -- Mandatory RFC 3852 Electronic Signature Attributes 3546 -- OtherSigningCertificate 3548 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 3549 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3550 smime(16) id-aa(2) 19 } 3552 OtherSigningCertificate ::= SEQUENCE { 3553 certs SEQUENCE OF OtherCertID, 3554 policies SEQUENCE OF PolicyInformation OPTIONAL 3555 -- NOT USED IN THE PRESENT DOCUMENT 3556 } 3558 OtherCertID ::= SEQUENCE { 3559 otherCertHash OtherHash, 3560 issuerSerial IssuerSerial OPTIONAL } 3562 OtherHash ::= CHOICE { 3563 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3564 otherHash OtherHashAlgAndValue} 3566 OtherHashValue ::= OCTET STRING 3568 OtherHashAlgAndValue ::= SEQUENCE { 3569 hashAlgorithm AlgorithmIdentifier, 3570 hashValue OtherHashValue } 3572 -- Policy ES Attributes Defined in the present document 3573 -- ==================================================== 3575 -- Mandatory Basic Electronic Signature Attributes, plus in addition. 3576 -- Signature Policy Identifier 3578 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 3579 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3580 smime(16) id-aa(2) 15 } 3581 SignaturePolicy ::= CHOICE { 3582 signaturePolicyId SignaturePolicyId, 3583 signaturePolicyImplied SignaturePolicyImplied 3584 -- not used in this version 3585 } 3587 SignaturePolicyId ::= SEQUENCE { 3588 sigPolicyId SigPolicyId, 3589 sigPolicyHash SigPolicyHash OPTIONAL, 3590 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3591 SigPolicyQualifierInfo OPTIONAL 3592 } 3594 SignaturePolicyImplied ::= NULL 3596 SigPolicyId ::= OBJECT IDENTIFIER 3598 SigPolicyHash ::= OtherHashAlgAndValue 3600 SigPolicyQualifierInfo ::= SEQUENCE { 3601 sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id 3602 ({SupportedSigPolicyQualifiers}), 3603 qualifier SIG-POLICY-QUALIFIER.&Qualifier 3604 ({SupportedSigPolicyQualifiers} 3605 {@sigPolicyQualifierId})OPTIONAL } 3607 SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 3608 { noticeToUser | pointerToSigPolSpec } 3610 SIG-POLICY-QUALIFIER ::= CLASS { 3611 &id OBJECT IDENTIFIER UNIQUE, 3612 &Qualifier OPTIONAL } 3613 WITH SYNTAX { 3614 SIG-POLICY-QUALIFIER-ID &id 3615 [SIG-QUALIFIER-TYPE &Qualifier] } 3617 noticeToUser SIG-POLICY-QUALIFIER ::= { 3618 SIG-POLICY-QUALIFIER-ID id-spq-ets-unotice SIG-QUALIFIER-TYPE 3619 SPUserNotice } 3621 pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { 3622 SIG-POLICY-QUALIFIER-ID id-spq-ets-uri SIG-QUALIFIER-TYPE SPuri } 3624 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 3625 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3626 smime(16) id-spq(5) 1 } 3628 SPuri ::= IA5String 3629 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 3630 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3631 smime(16) id-spq(5) 2 } 3633 SPUserNotice ::= SEQUENCE { 3634 noticeRef NoticeReference OPTIONAL, 3635 explicitText DisplayText OPTIONAL} 3637 NoticeReference ::= SEQUENCE { 3638 organization DisplayText, 3639 noticeNumbers SEQUENCE OF INTEGER } 3641 DisplayText ::= CHOICE { 3642 visibleString VisibleString (SIZE (1..200)), 3643 bmpString BMPString (SIZE (1..200)), 3644 utf8String UTF8String (SIZE (1..200)) } 3646 -- Optional Electronic Signature Attributes 3648 -- Commitment Type 3650 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3651 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3653 CommitmentTypeIndication ::= SEQUENCE { 3654 commitmentTypeId CommitmentTypeIdentifier, 3655 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3656 CommitmentTypeQualifier OPTIONAL} 3658 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3660 CommitmentTypeQualifier ::= SEQUENCE { 3661 commitmentQualifierId COMMITMENT-QUALIFIER.&id, 3662 qualifier COMMITMENT-QUALIFIER.&Qualifier OPTIONAL } 3664 COMMITMENT-QUALIFIER ::= CLASS { 3665 &id OBJECT IDENTIFIER UNIQUE, 3666 &Qualifier OPTIONAL } 3667 WITH SYNTAX { 3668 COMMITMENT-QUALIFIER-ID &id 3669 [COMMITMENT-TYPE &Qualifier] } 3671 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3672 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 3674 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3675 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 3677 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 3678 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} 3679 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3680 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 3682 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 3683 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} 3685 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 3686 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} 3688 -- Signer Location 3690 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3691 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3693 SignerLocation ::= SEQUENCE { 3694 -- at least one of the following shall be present 3695 countryName [0] DirectoryString{maxSize} OPTIONAL, 3696 -- As used to name a Country in X.500 3697 localityName [1] DirectoryString{maxSize} OPTIONAL, 3698 -- As used to name a locality in X.500 3699 postalAdddress [2] PostalAddress OPTIONAL } 3701 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize} 3703 -- Signer Attributes 3705 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3706 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3708 SignerAttribute ::= SEQUENCE OF CHOICE { 3709 claimedAttributes [0] ClaimedAttributes, 3710 certifiedAttributes [1] CertifiedAttributes } 3712 ClaimedAttributes ::= SEQUENCE OF Attribute 3714 CertifiedAttributes ::= AttributeCertificate 3715 -- as defined in RFC 3281 : see clause 4.1 3717 -- Content Timestamp 3719 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3720 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} 3722 ContentTimestamp::= TimeStampToken 3724 -- Signature Timestamp 3726 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member- 3727 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} 3729 SignatureTimeStampToken ::= TimeStampToken 3731 -- Complete Certificate Refs. 3733 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3734 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3736 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 3738 -- Complete Revocation Refs 3740 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3741 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3743 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3745 CrlOcspRef ::= SEQUENCE { 3746 crlids [0] CRLListID OPTIONAL, 3747 ocspids [1] OcspListID OPTIONAL, 3748 otherRev [2] OtherRevRefs OPTIONAL 3749 } 3751 CRLListID ::= SEQUENCE { 3752 crls SEQUENCE OF CrlValidatedID} 3754 CrlValidatedID ::= SEQUENCE { 3755 crlHash OtherHash, 3756 crlIdentifier CrlIdentifier OPTIONAL} 3758 CrlIdentifier ::= SEQUENCE { 3759 crlissuer Name, 3760 crlIssuedTime UTCTime, 3761 crlNumber INTEGER OPTIONAL 3762 } 3764 OcspListID ::= SEQUENCE { 3765 ocspResponses SEQUENCE OF OcspResponsesID} 3767 OcspResponsesID ::= SEQUENCE { 3768 ocspIdentifier OcspIdentifier, 3769 ocspRepHash OtherHash OPTIONAL 3770 } 3772 OcspIdentifier ::= SEQUENCE { 3773 ocspResponderID ResponderID, -- As in OCSP response data 3774 producedAt GeneralizedTime -- As in OCSP response data 3775 } 3777 OtherRevRefs ::= SEQUENCE { 3778 otherRevRefType OTHER-REVOCATION-REF.&id, 3779 otherRevRefs SEQUENCE OF OTHER-REVOCATION-REF.&Type 3780 } 3781 OTHER-REVOCATION-REF ::= CLASS { 3782 &Type, 3783 &id OBJECT IDENTIFIER UNIQUE } 3784 WITH SYNTAX { 3785 WITH SYNTAX &Type ID &id } 3787 -- Certificate Values 3789 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3790 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3792 CertificateValues ::= SEQUENCE OF Certificate 3794 -- Certificate Revocation Values 3796 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- 3797 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24} 3799 RevocationValues ::= SEQUENCE { 3800 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3801 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3802 otherRevVals [2] OtherRevVals OPTIONAL} 3804 OtherRevVals ::= SEQUENCE { 3805 otherRevValType OTHER-REVOCATION-VAL.&id, 3806 otherRevVals SEQUENCE OF OTHER-REVOCATION-REF.&Type 3807 } 3809 OTHER-REVOCATION-VAL ::= CLASS { 3810 &Type, 3811 &id OBJECT IDENTIFIER UNIQUE } 3812 WITH SYNTAX { 3813 WITH SYNTAX &Type ID &id } 3815 -- CAdES-C Timestamp 3817 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3818 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 3820 ESCTimeStampToken ::= TimeStampToken 3822 -- Time-Stamped Certificates and CRLs 3824 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3825 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} 3827 TimestampedCertsCRLs ::= TimeStampToken 3829 -- Archive Timestamp 3831 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3832 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27} 3834 ArchiveTimeStampToken ::= TimeStampToken 3836 -- Attribute certificate references 3838 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) member- 3839 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 44} 3841 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 3843 -- Attribute revocation references 3845 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) member- 3846 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 45} 3848 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 3850 END 3851 Annex B (informative): Extended forms of Electronic Signatures 3853 Clause 4 provides on overview of the various formats of electronic 3854 signatures included in the present document. This annex lists the 3855 attributes that need to be present in the various extended electronic 3856 signature formats and provide example validation sequences using the 3857 extended formats. 3859 B.1 Extended forms of validation data 3861 The complete validation data (CAdES-C) described in clause 4.3 and 3862 illustrated in figure 3 may be extended to create Electronic Signatures 3863 with extended validation data. Some Electronic Signatures forms that 3864 include extended validation are explained below. 3866 An X-Long electronic signature (CAdES-X Long) is when the values of the 3867 certificates and revocation information are added to the CAdES-C. 3869 This form of Electronic Signature can be useful when the verifier does 3870 not have direct access to the following information: 3872 - the signer's certificate; 3874 - all the CA certificates that make up the full certification path; 3876 - all the associated revocation status information, as referenced 3877 in the CAdES-C. 3879 In some situations additional time-stamps may be created and added to 3880 the Electronic Signatures as additional attributes. For example: 3882 - time-stamping all the validation data as held with the ES (CAdES- 3883 C), this eXtended validation data is called a CAdES-X Type 1; or 3885 - time-stamping individual reference data as used for complete 3886 validation. This form of eXtended validation data is called an 3887 CAdES-X Type 2. 3889 NOTE 1: The advantages/drawbacks for CAdES-X Type 1 and CAdES-X Type 2 3890 are discussed in clause C.4.4. 3892 The above time-stamp forms can be useful when it is required to counter 3893 the risk that any CA keys used in the certificate chain may be 3894 compromised. 3896 A combination of the two formats above may be used. This form of 3897 eXtended validation data is called an ES X-Long Type 1 or CAdES-X Long 3898 Type 2. This form of Electronic Signature can be useful when the 3899 verifier needs both the values and proof of when the validation data 3900 existed. 3902 NOTE 2: The advantages/drawbacks for CAdES-X long Type 1 and CAdES-X 3903 long Type 2 are discussed in clause C.4.6. 3905 B.1.1 CAdES-X Long 3907 An Electronic Signature with the additional validation data forming the 3908 CAdES-X Long form (CAdES-X-Long)) is illustrated in figure B.1 and 3909 comprises the following: 3911 - CAdES-BES or CAdES-EPES as defined in clauses 4.3 , 5.7 or 5.8; 3913 - complete-certificate-references attribute as defined in clause 3914 6.2.1; 3916 - complete-revocation-references attribute as defined in clause 3917 6.2.2. 3919 The following attributes are required if a TSP is not providing a time- 3920 mark of the ES: 3922 - signature-time-stamp attribute as defined in clause 6.1.1. 3924 The following attributes are required if the full certificate values 3925 and revocation values are not already included in the CAdES-BES or 3926 CAdES-EPES: 3928 - certificate-values attribute as defined in clause 6.3.3; 3929 - revocation-values attribute, as defined in clause 6.3.4. 3931 If attributes certificates are used then the following attributes may 3932 be present: 3934 - attribute-certificate-references attribute defined in clause 3935 6.2.3; 3937 - attribute-revocation-references attribute as defined in clause 3938 6.2.4. 3940 Other unsigned attributes may be present, but are not required. 3942 NOTE: Attribute certificate and revocation references are only 3943 present if a user attribute certificate is present in the 3944 electronic signature, see clauses 6.2.2 and 6.2.3. 3946 +---------------------- CAdES-X-Long --------------------------------+ 3947 |+-------------------------------------- CAdES-C ---+ | 3948 || +----------+ | +-------------+| 3949 ||+----- CAdES-BES or CAdES-EPES ----+ |Timestamp | | | || 3950 ||| | |over | | | Complete || 3951 |||+---------++----------++---------+| |digital | | | certificate || 3952 |||| || || || |signature | | | and || 3953 ||||Signer's || Signed ||Digital || | | | | revocation || 3954 ||||Document ||Attributes||signature|| |Optional | | | data || 3955 |||| || || || |when | | | || 3956 |||+---------++----------++---------+| |timemarked| | | || 3957 ||+----------------------------------+ +----------+ | | || 3958 || +-----------+| +-------------+| 3959 || |Complete || | 3960 || |certificate|| | 3961 || |and || | 3962 || |revocation || | 3963 || |references || | 3964 || +-----------+| | 3965 |+--------------------------------------------------+ | 3966 | | 3967 +--------------------------------------------------------------------+ 3969 Figure B.1 : Illustration of CAdES-X-Long 3971 B.1.2 CAdES-X Type 1 3973 An Electronic Signature with the additional validation data forming the 3974 eXtended Validation Data - Type 1 X is illustrated in figure B.2 and 3975 comprises the following: 3977 - the CAdES-BES or CAdES-EPES as defined in clauses 4.2, 5.7 or 3978 5.8; 3980 - complete-certificate-references attribute as defined in clause 3981 6.2.1; 3983 - complete-revocation-references attribute as defined in clause 3984 6.2.2; 3986 - CAdES-C-Timestamp attribute, as defined in clause 6.3.5. 3988 The following attributes are required if a TSP is not providing a time- 3989 mark of the ES: 3991 - signature-time-stamp attribute as defined in clause 6.1.1. 3993 If attributes certificates are used then the following attributes may 3994 be present: 3996 - attribute-certificate-references attribute defined in clause 3997 6.2.3; 3999 - attribute-revocation-references attribute as defined in clause 4000 6.2.4. 4002 Other unsigned attributes may be present, but are not required. 4004 +------------------------ CAdES-X-Type 1 ----------------------------+ 4005 |+---------------------------------- CAdES-C ------+ | 4006 || +----------+ | +-------------+ | 4007 ||+--- CAdES-BES or CAdES-EPES ------+|Timestamp | | | | | 4008 ||| ||over | | | | | 4009 |||+---------++----------++---------+||digital | | | | | 4010 ||||Signer's || Signed || Digital |||signature | | | Timestamp | | 4011 ||||Document ||Attributes||signature||| | | | over | | 4012 |||| || || |||Optional | | | CAdES-C | | 4013 |||+---------++----------++---------+||when | | | | | 4014 ||+----------------------------------+|timemarked| | | | | 4015 || +----------+ | | | | 4016 || +-----------+| +-------------+ | 4017 || |Complete || | 4018 || |certificate|| | 4019 || | and || | 4020 || |revocation || | 4021 || |references || | 4022 || +-----------+| | 4023 |+-------------------------------------------------+ | 4024 | | 4025 +--------------------------------------------------------------------+ 4027 Figure B.2 : Illustration of CAdES-X Type 1 4029 B.1.3 CAdES-X Type 2 4031 An Electronic Signature with the additional validation data forming the 4032 eXtended Validation Data - Type 2 X is illustrated in figure B.3. and 4033 comprises the following: 4035 - CAdES-BES or CAdES-EPES as defined in clauses 4.2, 5.7 or 5.8; 4037 - complete-certificate-references attribute as defined in clause 4038 6.2.1; 4040 - complete-revocation-references attribute as defined in clause 4041 6.2.2; 4043 - time-stamped-certs-crls-references attribute as defined in clause 4044 6.3.6. 4046 The following attributes are required if a TSP is not providing a time- 4047 mark of the ES: 4049 - signature-time-stamp attribute as defined in clause 6.1.1. 4051 If attributes certificates are used then the following attributes may 4052 be present: 4054 - attribute-certificate-references attribute defined in clause 4055 6.2.3; 4057 - attribute-revocation-references attribute as defined in clause 4058 6.2.4. 4060 Other unsigned attributes may be present, but are not required. 4062 +----------------------- CAdES-X-Type 2 -----------------------------+ 4063 |+-------------------------------------- CAdES-C --+ | 4064 || +----------+ | | 4065 ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | | | 4066 ||| ||over | | | 4067 |||+---------++----------++---------+||digital | | +-------------+ | 4068 |||| || || |||Signature | | | Timestamp | | 4069 ||||Signer's || Signed || Digital ||| | | | only over | | 4070 ||||Document ||Attributes||signature|||Optional | | | Complete | | 4071 |||| || || |||when | | | certificate | | 4072 |||+---------++----------++---------+||Timemarked| | | and | | 4073 ||+----------------------------------++----------+ | | revocation | | 4074 || +-----------+| | references | | 4075 || |Complete || +-------------+ | 4076 || |certificate|| | 4077 || |and || | 4078 || |revocation || | 4079 || |references || | 4080 || +-----------+| | 4081 |+-------------------------------------------------+ | 4082 | | 4083 +--------------------------------------------------------------------+ 4085 Figure B.3 : Illustration of CAdES-X Type 2 4087 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 4089 An Electronic Signature with the additional validation data forming the 4090 CAdES-X Long Type 1 and CAdES-X Long Type 2 is illustrated in 4091 figure B.4 and comprises the following: 4093 - CAdES-BES or CAdES-EPES as defined in clauses 4.3, 5.7 or 5.8; 4095 - complete-certificate-references attribute as defined in clause 4096 6.2.1; 4098 - complete-revocation-references attribute as defined in clause 4099 6.2.2; 4101 The following attributes are required if a TSP is not providing a time- 4102 mark of the ES: 4104 - signature-time-stamp attribute as defined in clause 6.1.1. 4106 The following attributes are required if the full certificate values 4107 and revocation values are not already included in the CAdES-BES or 4108 CAdES-EPES: 4109 - certificate-values attribute as defined in clause 6.3.3; 4110 - revocation-values attribute, as defined in clause 6.3.4. 4112 If attributes certificates are used then the following attributes may 4113 be present: 4115 - attribute-certificate-references attribute defined in clause 4116 6.2.3; 4118 - attribute-revocation-references attribute as defined in clause 4119 6.2.4. 4121 Plus one of the following attributes is required: 4123 - CAdES-C-Timestamp attribute, as defined in clause 6.3.5; 4124 - time-stamped-certs-crls-references attribute as defined in clause 4125 6.3.6. 4127 Other unsigned attributes may be present, but are not required. 4129 +---------------------- CAdES-X-Type 1 or 2 ------------------------+ 4130 | +--------------+| 4131 |+-------------------------------------- CAdES-C --+|+------------+|| 4132 || +----------+ ||| Timestamp ||| 4133 ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | ||| over ||| 4134 ||| ||over | ||| CAdES-C ||| 4135 |||+---------++----------++---------+||digital | | +------------+ | 4136 |||| || || |||signature | || or || 4137 ||||Signer's || Signed || Digital ||| | ||+------------+|| 4138 ||||Document ||Attributes||Signature|||Optional | ||| Timestamp ||| 4139 |||| || || |||when | ||| only over ||| 4140 |||+---------++----------++---------+||timemarked| ||| complete ||| 4141 ||+----------------------------------++----------+ ||| certificate||| 4142 || ||| and ||| 4143 || +-----------+||| revocation ||| 4144 || |Complete |||| references ||| 4145 || |certificate|||+------------+|| 4146 || |and ||+--------------+| 4147 || |revocation || +------------+ | 4148 || |references || |Complete | | 4149 || +-----------+| |certificate | | 4150 |+-------------------------------------------------+ | and | | 4151 | |revocation | | 4152 | | values | | 4153 | +------------+ | 4154 +-------------------------------------------------------------------+ 4156 Figure B.4 : Illustration of CAdES-X Long Type 1 4157 and CAdES-X Long Type 2 4159 B.2 Timestamp extensions 4161 Each instance of time-stamp attribute may include as unsigned 4162 attributes in the signedData of the timestamp the following attribute 4163 related to the TSU: 4165 - complete-certificate-references attribute of the TSU as defined 4166 in clause 6.2.1; 4168 - complete-revocation-references attribute of the TSU as defined in 4169 clause 6.2.2; 4171 - certificate-values attribute; of the TSU as defined in clause 4172 6.3.3; 4174 - revocation-values attribute, of the TSU as defined in clause 4175 6.3.4. 4177 Other unsigned attributes may be present, but are not required. 4179 B.3 Archive validation data (CAdES-A) 4181 Before the algorithms, keys and other cryptographic data used at the 4182 time the CAdES-C was built become weak and the cryptographic functions 4183 become vulnerable, or the certificates supporting previous time-stamps 4184 expires, the signed data, the CAdES-C and any additional information 4185 (i.e. any CAdES-X) should be time-stamped. If possible this should use 4186 stronger algorithms (or longer key lengths) than in the original time- 4187 stamp. This additional data and time-stamp is called Archive 4188 Validation Data required for the ES Archive format (CAdES-A). The 4189 Time-stamping process may be repeated every time the protection used to 4190 time-stamp a previous CAdES-A becomes weak. An CAdES-A may thus bear 4191 multiple embedded time stamps. 4193 An example of an Electronic Signature (ES), with the additional 4194 validation data for the CAdES-C and CAdES-X forming the CAdES-A is 4195 illustrated in figure B.5. 4197 +--------------------------- CAdES-A---------------------------------+ 4198 |+----------------------------------------------------+ | 4199 || +--------------+| +----------+ | 4200 ||+--------------------- CAdES-C ----+|+------------+|| | | | 4201 ||| +----------+ ||| Timestamp ||| | | | 4202 |||+-- CAdES-BES ------+|Timestamp | ||| over ||| | | | 4203 |||| or CAdES-EPES ||over | ||| CAdES-C ||| | Archive | | 4204 |||| ||digital | ||+------------+|| | | | 4205 |||| ||signature | || or || |Timestamp | | 4206 |||| || | ||+------------+|| | | | 4207 |||| ||optional | ||| Timestamp ||| | | | 4208 |||| ||when | ||| only over ||| | | | 4209 |||| ||timemarked| ||| complete ||| | | | 4210 |||+-------------------++----------+ ||| certificate||| +----------+ | 4211 ||| ||| and ||| | 4212 ||| +-------------+||| revocation ||| | 4213 ||| | Complete |||| references ||| | 4214 ||| | certificate |||+------------+|| | 4215 ||| | and ||+--------------+| | 4216 ||| | revocation || +------------+ | | 4217 ||| | references || |Complete | | | 4218 ||| +-------------+| |certificate | | | 4219 ||+----------------------------------+ | and | | | 4220 || |revocation | | | 4221 || | values | | | 4222 || +------------+ | | 4223 |+----------------------------------------------------+ | 4224 +--------------------------------------------------------------------+ 4226 Figure B.5 : Illustration of CAdES-A 4228 The CAdES-A comprises the following elements: 4230 - the CAdES-BES or CAdES-EPES including their signed and unsigned 4231 attributes; 4233 - complete-certificate-references attribute as defined in clause 4234 6.2.1; 4236 - complete-revocation-references attribute as defined in clause 4237 6.2.2. 4239 The following attributes are required if a TSP is not providing a time- 4240 mark of the ES: 4242 - signature-time-stamp attribute as defined in clause 6.1.1. 4244 If attributes certificates are used then the following attributes may 4245 be present: 4247 - attribute-certificate-references attribute defined in clause 4248 6.2.3; 4249 - attribute-revocation-references attribute as defined in clause 4250 6.2.4. 4252 The following attributes are required if the full certificate values 4253 and revocation values are not already included in the CAdES-BES or 4254 CAdES-EPES: 4256 - certificate-values attribute as defined in clause 6.3.3; 4257 - revocation-values attribute as defined in clause 6.3.4. 4259 At least one of the following two attributes is required: 4261 - CAdES-C-Timestamp attribute as defined in clause 6.3.5; 4263 - time-stamped-certs-crls-references attribute as defined in clause 4264 6.3.6. 4266 The following attribute is required: 4268 - archive-time-stamp attributes defined in clause 6.4.1. 4270 Several instances of archive-time-stamp attribute may occur with an 4271 electronic signature both over time and from different TSUs. The time- 4272 stamp should be created using stronger algorithms (or longer key 4273 lengths) than in the original electronic signatures or time-stamps. 4275 Other unsigned attributes of the ES may be present, but are not 4276 required. 4278 The archive timestamp will itself contain the certificate and 4279 revocation information required to validate the archive timestamp, this 4280 may include the following unsigned attributes: 4282 - complete-certificate-references attribute of the TSU as defined 4283 in clause 6.2.1; 4285 - complete-revocation-references attribute of the TSU as defined in 4286 clause 6.2.2; 4288 - certificate-values attribute of the TSU as defined in clause 4289 6.3.3; 4291 - revocation-values attribute of the TSU as defined in clause 4292 6.3.4. 4294 Other unsigned attributes may be present, but are not required. 4296 B.4 Example validation sequence 4298 As described earlier the signer or initial verifier may collect all the 4299 additional data that forms the electronic signature. Figure B.6, and 4300 subsequent description, describes how the validation process may build 4301 up a complete electronic signature over time. 4303 +------------------------------------------ CAdES-C -------------+ 4304 |+------------------------------- CAdES-T ------+ | 4305 ||+-------------- CAdES ------------+ | | 4306 |||+--------------------++---------+|+---------+| +-----------+ | 4307 |||| ________ || |||Timestamp|| |Complete | | 4308 |||||Sign.Pol| ||Digital |||over || |certificate| | 4309 ||||| Id. | Signed ||signature|||digital || | and | | 4310 ||||| option.|attributes|| |||signature|| |revocation | | 4311 |||||________| |+---------+|+---------+| |references | | 4312 |||+--------------------+ | ^ | +-----------+ | 4313 ||+---------------------------------+ | | ^ | 4314 || 1 | / | | | 4315 |+---------------------- | ------------/--------+ | | 4316 +----------------------- | ---------- / --------------- / -------+ 4317 | /2 ----3-------- 4318 +----------+ | / / 4319 | | v / | 4320 | Signer's | +---------------------+ +-------------+ 4321 | document |----->| Validation Process |---->|- Valid | 4322 | | +---------------------+ 4 |- Invalid | 4323 +----------+ | ^ | ^ |- Validation | 4324 v | v | | Incomplete | 4325 +---------+ +--------+ +-------------+ 4326 |Signature| |Trusted | 4327 | Policy | |Service | 4328 | Issuer | |Provider| 4329 +---------+ +--------+ 4331 Figure B.6 : Illustration of a CAdES validation sequence 4333 Soon after receiving the Electronic Signature (CAdES) from the signer 4334 (1), the digital signature value may be checked; the validation process 4335 shall at least add a time-stamp (2), unless the signer has provided one 4336 which is trusted by the verifier. The validation process may also 4337 validate the electronic signature, using additional data (e.g. 4338 certificates, CRL, etc.) provided by trusted service providers. When 4339 applicable, the validation process will also need to conform to the 4340 requirements specified in a signature policy. If the validation 4341 process is validation incomplete, then the output from this stage is 4342 the CAdES-T. 4344 To ascertain the validity status as Valid or Invalid and communicate 4345 that to the user (4) all the additional data required to validate the 4346 CAdES-C, must be available (e.g. the complete certificate and 4347 revocation information). 4349 Once the data needed to complete validation data references (CAdES-C) 4350 is available then the validation process should: 4352 - obtain all the necessary additional certificate and revocation 4353 status information; 4355 - complete all the validation checks on the ES, using the complete 4356 certificate and revocation information (if a time-stamp is not 4357 already present, this may be added at the same stage combining 4358 CAdES-T and CAdES-C process); 4360 - record the complete certificate and revocation references (3); 4362 - indicate the validity status to the user (4). 4364 At the same time as the validation process creates the CAdES-C, the 4365 validation process may provide and/or record the values of certificates 4366 and revocation status information used in CAdES-C, called the CAdES-X 4367 Long (5). 4369 This is illustrated in figure B.7. 4371 +----------------------------------------------------- CAdES-X Long -+ 4372 |+------------------------------- CAdES-C -------------+ | 4373 ||+-------------- CAdES ------------+ | | 4374 |||+--------------------++---------+|+---------+ |+-----------+| 4375 |||| ________ || |||Timestamp| ||Complete || 4376 |||||Sign.Pol| ||Digital |||over | ||certificate|| 4377 ||||| Id. | Signed ||signature|||digital | || and || 4378 ||||| option.|attributes|| |||signature| ||revocation || 4379 |||||________| || ||+---------+ || values || 4380 |||+--------------------++---------+| ^ +-----------+|+-----------+| 4381 ||+---------------------------------+ | |Complete || ^ | 4382 || | | |certificate|| | | 4383 || | 2 | | and || | | 4384 || | | |revocation || | | 4385 || | | |references || | | 4386 || 1 | / +-----------+| | | 4387 |+------------------------ | ------- / --------- ^-----+ / | 4388 +------------------------- | ------ / ---------- |--------- / -------+ 4389 | / ----- / ------- / 4390 +----------+ | / / 3 / 5 4391 | | v | | | 4392 | Signer's | +--------------------+ +-----------+ 4393 | document |----->| Validation Process |----->| - Valid | 4394 | | +--------------------+ 4 | - Invalid | 4395 +----------+ | ^ | ^ +-----------+ 4396 v | v | 4397 +---------+ +--------+ 4398 |Signature| |Trusted | 4399 | Policy | |Service | 4400 | Issuer | |Provider| 4401 +---------+ +--------+ 4403 Figure B.7 : Illustration of a CAdES validation sequence 4404 with CAdES-X Long 4406 When the validation process creates the CAdES-C it may also create 4407 extended forms of validation data. 4409 A first alternative is to time-stamp all data forming the CAdES-X Type 4410 1 (6). 4412 This is illustrated in figure B.8. 4414 +------------------------------------------------ CAdES-X Type 1 -----+ 4415 |+------------------------------- CAdES-C ------------------+ | 4416 ||+-------------- CAdES ------------+ | | 4417 |||+--------------------++---------+|+---------++----------+|+-------+| 4418 |||| ________ || |||Timestamp|| Complete ||| || 4419 |||||Sign.Pol| ||Digital |||over || cert. |||Time- || 4420 ||||| Id. | Signed ||signature|||digital || and |||stamp || 4421 ||||| option.|attributes|| |||signature|| revoc. ||| over || 4422 |||||________| |+---------+|+---------+|references|||CAdES-C|| 4423 |||+--------------------+ | ^ | ||| || 4424 ||+---------------------------------+ | +----------+|+-------+| 4425 || | | ^ | ^ | 4426 || 1 | / | | | | 4427 |+------------------------ | --------- / ----------- / -----+ | | 4428 +------------------------- | -------- / ----------- / --------- / ----+ 4429 | 2 / ---3---- / 4430 +----------+ | / / -----------5------ 4431 | | v | | / 4432 | Signer's | +--------------------+ +-----------+ 4433 | document |----->| Validation Process |-----> | - Valid | 4434 | | +--------------------+ 4 | - Invalid | 4435 +----------+ | ^ | ^ +-----------+ 4436 v | v | 4437 +---------+ +--------+ 4438 |Signature| |Trusted | 4439 | Policy | |Service | 4440 | Issuer | |Provider| 4441 +---------+ +--------+ 4443 Figure B.8 : Illustration of CAdES with eXtended Validation Data 4444 CAdES-X Type 1 4446 Another alternative is to time-stamp the certificate and revocation 4447 information references used to validate the electronic signature (but 4448 not the signature) (6'); this is called CAdES-X Type 2. 4450 This is illustrated in figure B.9. 4452 +-------------------------------------------- CAdES-X Type 2 --------+ 4453 |+------------------------------- CAdES-C -------------+ | 4454 ||+-------------- CAdES ------------+ | | 4455 |||+--------------------++---------+|+---------+ |+-----------+| 4456 |||| ________ || |||Timestamp| ||Timestamp || 4457 |||||Sign.Pol| || |||over | || over || 4458 ||||| Id. | Signed ||Digital |||digital | ||complete || 4459 ||||| option.|attributes||signature|||signature| ||certificate|| 4460 |||||________| || ||| | || || 4461 |||+--------------------++---------+|+---------+ || and || 4462 ||+---------------------------------+ ^ +-----------+||revocation || 4463 || | | |Complete |||references || 4464 || | | |certificate||+-----------+| 4465 || | | | and || ^ | 4466 || 1 | 2 | |revocation || | | 4467 || | | |references || | | 4468 || | | +-----------+| | | 4469 |+------------------------ | --------- | --- ^ --------+ | | 4470 | | | 3 | / | 4471 | | | / ---------- | 4472 | | / / / 5 | 4473 | | / / / | 4474 | | / / / | 4475 +------------------------- | ----- | -- | -- / ----------------------+ 4476 | | | | 4477 v | | | 4478 +--------------------+ +-----------+ 4479 | Validation Process |----->| - Valid | 4480 +--------------------+ 4 | - Invalid | 4481 | ^ | ^ +-----------+ 4482 v | v | 4483 +---------+ +--------+ 4484 |Signature| |Trusted | 4485 | Policy | |Service | 4486 | Issuer | |Provider| 4487 +---------+ +--------+ 4489 Figure B.9: Illustration of CAdES with eXtended Validation Data 4490 CAdES-X Type 2 4492 Before the algorithms used in any of electronic signatures become or 4493 are likely, to be compromised or rendered vulnerable in the future, it 4494 may be necessary to time-stamp the entire electronic signature, 4495 including all the values of the validation and user data as an ES with 4496 Archive Validation Data (CAdES-A) (7). 4498 An CAdES-A is illustrated in figure B.10. 4500 +----------------------------- CAdES-A ---------------------------+ 4501 | | 4502 | +-- CAdES-X Long Type 1 or 2 ----------+ | 4503 | | | +------------+ | 4504 | | | | | | 4505 | | | | Archive | | 4506 | | | | Time-stamp | | 4507 | | | | | | 4508 | | | +------------+ | 4509 | +---------------------------------------+ ^ | 4510 | +----------+ ^ ^ ^ ^ | | 4511 | | | | | | | / | 4512 | | Signers' | | | | | / | 4513 | | Document |\ | | | | / | 4514 | | | \ 1 2 | 3 | 5 | 6 | 7 / | 4515 | +----------+ \ | | | | / | 4516 | \ | | | | / | 4517 +----------------- \ --- | - | - | - | ------ / ------------------+ 4518 \ | | | | | 4519 | | | | | | 4520 | | | | | | 4521 v v | | | | 4522 +-----------------------------+ +-----------+ 4523 | Validation Process |----->| - Valid | 4524 +-----------------------------+ 4 | - Invalid | 4525 | ^ | ^ +-----------+ 4526 v | v | 4527 +---------+ +--------+ 4528 |Signature| |Trusted | 4529 | Policy | |Service | 4530 | Issuer | |Provider| 4531 +---------+ +--------+ 4533 Figure B.10: Illustration of CAdES-A 4535 B.5 Additional optional features 4537 The present document also defines additional optional features to: 4539 - indicate a commitment type being made by the signer; 4541 - indicate the claimed time when the signature was done; 4543 - indicate the claimed location of the signer; 4545 - indicate the claimed or certified role under which a signature 4546 was created; 4548 - support counter signatures; 4550 - support multiple signatures. 4552 Annex C (informative):General description 4554 This annex explains some of the concepts and provides the rational for 4555 normative parts of the present document. 4557 The specification below includes a description why and when the each 4558 component of an electronic signature is useful, with a brief 4559 description of the vulnerabilities and threats and the manner by which 4560 they are countered. 4562 C.1 The signature policy 4564 The signature policy is a set of rules for the creation and validation 4565 of an electronic signature, under which the signature can be determined 4566 to be valid. A given legal/contractual context may recognize a 4567 particular signature policy as meeting its requirements. A signature 4568 policy may be issued, for example, by a party relying on the electronic 4569 signatures and selected by the signer for use with that relying party. 4570 Alternatively, a signature policy may be established through an 4571 electronic trading association for use amongst its members. Both the 4572 signer and verifier use the same signature policy. 4574 The signature policy may be explicitly identified or may be implied by 4575 the semantics of the data being signed and other external data like a 4576 contract being referenced which itself refers to a signature policy. 4577 An explicit signature policy has a globally unique reference, which is 4578 bound to an electronic signature by the signer as part of the signature 4579 calculation. 4581 The signature policy needs to be available in human readable form so 4582 that it can be assessed to meet the requirements of the legal and 4583 contractual context in which it is being applied. To facilitate the 4584 automatic processing of an electronic signature the parts of the 4585 signature policy which specifies the electronic rules for the creation 4586 and validation of the electronic signature also needs to be 4587 comprehensively defined and in a computer processable form. 4589 The signature policy thus includes the following: 4591 - rules, which apply to technical validation of a particular 4592 signature; 4594 - rules which may be implied through adoption of Certificate 4595 Policies that apply to the electronic signature (e.g. rules for 4596 ensuring the secrecy of the private signing key); 4598 - rules, which relate to the environment used by the signer, e.g. 4599 the use of an agreed CAD (Card Accepting Device) used in 4600 conjunction with a smart card. 4602 For example, the major rules required for technical validation can 4603 include: recognized root keys or "top-level certification authorities", 4604 acceptable certificate policies (if any), necessary certificate 4605 extensions and values (if any), the need for the revocation status for 4606 each component of the certification tree, acceptable TSAs (if time- 4607 stamp tokens are being used), acceptable organizations for keeping the 4608 audit trails with time-marks (if time-marking is being used), 4609 acceptable AAs (if any are being used).as well as rules defining the 4610 components of the electronic signature that shall be provided by the 4611 signer with data required by the verifier when required to provide long 4612 term proof. 4614 C.2 Signed information 4616 The information being signed may be defined as a MIME-encapsulated 4617 message which can be used to signal the format of the content in order 4618 to select the right display or application. It can be composed of 4619 formatted data, free text or fields from an electronic form (e-form). 4620 For example, the Adobe(tm) format "pdf" may be used or the eXtensible Mark 4621 up Language (XML). Annex D defines how the content may be structured 4622 to indicate the type of signed data using MIME. 4624 C.3 Components of an electronic signature 4626 C.3.1 Reference to the signature policy 4628 When two independent parties want to evaluate an electronic signature, 4629 it is fundamental that they get the same result. This requirement can 4630 be met using comprehensive signature policies that ensure consistency 4631 of signature validation. Signature policies can be identified 4632 implicitly by the data being signed or they can be explicitly 4633 identified using the CAdES-EPES form of electronic signature, the 4634 CAdES-EPES mandates a consistent signature policy must be used by both 4635 the signer and verifier. 4637 By signing over the signature policy identifier in the CAdES-EPES the 4638 signer explicitly indicates that he or she has applied the signature 4639 policy in creating the signature. 4641 In order to unambiguously identify the details of an explicit signature 4642 policy that is to be used to verify a CAdES-EPES the signature an 4643 identifier and hash of the "Signature policy" shall be part of the 4644 signed data. Additional information about the explicit policy (e.g. 4645 web reference to the document) may be carried as "qualifiers" to the 4646 signature policy identifier. 4648 In order to unambiguously identify the authority responsible for 4649 defining an explicit signature policy the "Signature policy" can be 4650 signed. 4652 C.3.2 Commitment type indication 4654 The commitment type can be indicated in the electronic signature 4655 either: 4657 - explicitly using a "commitment type indication" in the electronic 4658 signature; 4660 - implicitly or explicitly from the semantics of the signed data. 4662 If the indicated commitment type is explicit using a "commitment type 4663 indication" in the electronic signature, acceptance of a verified 4664 signature implies acceptance of the semantics of that commitment type. 4665 The semantics of explicit commitment types indications may be subject 4666 to signer and verifier agreement, specified as part of the signature 4667 policy or registered for generic use across multiple policies. 4669 If a CAdES-EPES electronic signature format is used and the electronic 4670 signature includes a commitment type indication other than one of those 4671 recognized under the signature policy the signature shall be treated as 4672 invalid. 4674 How commitment is indicated using the semantics of the data being 4675 signed is outside the scope of the present document. 4677 NOTE: Examples of commitment indicated through the semantics of the 4678 data being signed, are: 4680 - an explicit commitment made by the signer indicated by the type 4681 of data being signed over. Thus, the data structure being signed 4682 can have an explicit commitment within the context of the 4683 application (e.g. EDIFACT purchase order); 4685 - an implicit commitment which is a commitment made by the signer 4686 because the data being signed over has specific semantics 4687 (meaning) which is only interpretable by humans, (i.e. free 4688 text). 4690 C.3.3 Certificate identifier from the signer 4692 In many real life environments users will be able to get from different 4693 CAs or even from the same CA, different certificates containing the 4694 same public key for different names. The prime advantage is that a 4695 user can use the same private key for different purposes. Multiple use 4696 of the private key is an advantage when a smart card is used to protect 4697 the private key, since the storage of a smart card is always limited. 4698 When several CAs are involved, each different certificate may contain a 4699 different identity, e.g. as a national or as an employee from a 4700 company. Thus when a private key is used for various purposes, the 4701 certificate is needed to clarify the context in which the private key 4702 was used when generating the signature. Where there is the possibility 4703 of multiple use of private keys it is necessary for the signer to 4704 indicate to the verifier the precise certificate to be used. 4706 Many current schemes simply add the certificate after the signed data 4707 and thus are vulnerable to substitution attacks. If the certificate 4708 from the signer was simply appended to the signature and thus not 4709 protected by the signature, any one could substitute one certificate by 4710 another and the message would appear to be signed by some one else. In 4711 order to counter this kind of attack, the identifier of the signer has 4712 to be protected by the digital signature from the signer. 4714 In order to identify unambiguously the certificate to be used for the 4715 verification of the signature an identifier of the certificate from the 4716 signer shall be part of the signed data. 4718 C.3.4 Role attributes 4720 While the name of the signer is important, the position of the signer 4721 within a company or an organization of paramount importance as well. 4722 Some information (i.e. a contract) may only be valid if signed by a 4723 user in a particular role, e.g. a Sales Director. In many cases who 4724 the sales Director really is, is not that important but being sure that 4725 the signer is empowered by his company to be the Sales Director is 4726 fundamental. 4728 The present document defines two different ways for providing this 4729 feature: 4731 - by placing a claimed role name in the CMS signed attributes 4732 field; 4734 - by placing an attribute certificate containing a certified role 4735 name in the CMS signed attributes field. 4737 NOTE: Another possible approach would have been to use additional 4738 attributes containing the roles name(s) in the signer's 4739 identity certificate However, it was decided not to follow 4740 this approach as it significantly complicates the management 4741 of certificates. For example by using separate certificates 4742 for signer's identity and roles means new identity keys need 4743 not be issued if a user's role changes. 4745 C.3.4.1 Claimed role 4747 The signer may be trusted to state his own role without any certificate 4748 to corroborate this claim. In which case the claimed role can be added 4749 to the signature as a signed attribute. 4751 C.3.4.2 Certified role 4753 Unlike public key certificates that bind an identifier to a public key, 4754 Attribute Certificates bind the identifier of a certificate to some 4755 attributes, like a role. An Attribute Certificate is NOT issued by a 4756 CA but by an Attribute Authority (AA). The Attribute Authority in most 4757 cases might be under the control of an organization or a company that 4758 is best placed to know which attributes are relevant for which 4759 individual. The Attribute Authority may use or point to public key 4760 certificates issued by any CA, provided that the appropriate trust may 4761 be placed in that CA. Attribute Certificates may have various periods 4762 of validity. That period may be quite short, e.g. one day. While this 4763 requires that a new Attribute Certificate be obtained every day, valid 4764 for that day, this can be advantageous since revocation of such 4765 certificates may not be needed. When signing, the signer will have to 4766 specify which Attribute Certificate it selects. In order to do so, the 4767 Attribute Certificate will have to be included in the signed data in 4768 order to be protected by the digital signature from the signer. 4770 In order to identify unambiguously the attribute certificate(s) to be 4771 used for the verification of the signature an identifier of the 4772 attribute certificate(s) from the signer shall be part of the signed 4773 data. 4775 C.3.5 Signer location 4777 In some transactions the purported location of the signer at the time 4778 he or she applies his signature may need to be indicated. For this 4779 reason an optional location indicator shall be able to be included. 4781 In order to provide indication of the location of the signer at the 4782 time he or she applied his signature a location attribute may be 4783 included in the signature. 4784 C.3.6 Signing time 4786 The present document provides the capability to include a claimed 4787 signing time as an attribute of an electronic signature. 4789 Using this attribute a signer may sign over a time which is the claimed 4790 signing time. When an ES with Time-stamp is created (CAdES-T) then 4791 either a trusted time stamp is obtained and added to the ES or a 4792 trusted time mark exists in an audit trail. When a verifier accepts a 4793 signature, the two times shall be within acceptable limits. In all 4794 cases, the claimed signing time cannot be after the time identified by 4795 the time-stamp or time-mark. 4797 A further optional attribute is defined in the present document to 4798 timestamp the content, to provide proof of the existence of the 4799 content, at the time indicated by the time-stamp token. 4801 Using this optional attribute a trusted secure time may be obtained 4802 before the document is signed and included under the digital signature. 4803 This solution requires an on-line connection to a trusted time-stamping 4804 service before generating the signature and may not represent the 4805 precise signing time, since it can be obtained in advance. However, 4806 this optional attribute may be used by the signer to prove that the 4807 signed object existed before the date included in the time-stamp (see 4808 clause 5.11.4). 4810 Also, the signing time, if present should be between the time indicated 4811 by this time-stamp and time indicated by the CAdES-T time-stamp. 4813 C.3.7 Content format 4815 When presenting signed data to a human user it may be important that 4816 there is no ambiguity as to the presentation of the signed information 4817 to the relying party. In order for the appropriate representation 4818 (text, sound or video) to be selected by the relying party a content 4819 hint may be indicated by the signer. If a relying party system does 4820 not use the format specified in the content hints attribute to present 4821 the data to the relying party, then a human relying party may 4822 misinterpret data with valid signatures. 4824 C.3.8 Content cross referencing 4826 When presenting a signed data is in related to another signed data, it 4827 may be important to identify the signed data to which it relates to. 4828 The Content-reference and Content-identifier attributes as defined in 4829 ESS (RFC 2634 [5]) provide the ability to link a request and reply 4830 messages in an exchange between two parties. 4832 C.4 Components of validation data 4834 C.4.1 Revocation status information 4836 A verifier will have to ascertain that the certificate of the signer 4837 was valid at the time of the signature. This can be done by either: 4839 - using Certificate Revocation Lists (CRLs); 4841 - using responses from an on-line certificate status server (for 4842 example; obtained through the OCSP protocol). 4844 NOTE 1: The time of the signature may not be know, so time-stamping 4845 or time-marking may be used to provide the time indication of 4846 when it was known the signature existed. 4848 NOTE 2: When validating an electronic signature and checking 4849 revocation status information a "grace period" is required 4850 which needs to be suitably long enough to allow the involved 4851 authority to process a "last minute" revocation request and 4852 for the request to propagate through the revocation system. 4853 This grace period is to be added to the time included with the 4854 timestamp token or the time mark and thus the revocation 4855 status information should be captured after the end of the 4856 grace period. 4858 C.4.1.1 CRL information 4860 When using CRLs to get revocation information, a verifier will have to 4861 make sure that he or she gets at the time of the first verification the 4862 appropriate certificate revocation information from the signer's CA. 4863 This should be done as soon as possible to minimize the time delay 4864 between the generation and verification of the signature. However, a 4865 "grace period" is required to allow CAs time to process revocation 4866 requests. 4868 For example, a revocation request may arrive at a CA just before 4869 issuing the next CRL and there may not enough time to include the 4870 revised revocation status information. This involves checking that the 4871 signer certificate serial number is not included in the CRL. The 4872 signer, the initial or subsequent verifier may obtain either this CRL. 4873 If obtained by the signer, then it shall be conveyed to the verifier. 4874 It may be convenient to archive the CRL for ease of subsequent 4875 verification or arbitration. Alternatively, provided the CRL is 4876 archived elsewhere which is accessible for the purpose of arbitration, 4877 then the serial number of the CRL used may be archived together with 4878 the verified electronic signature as an CAdES-C form. 4880 Even if the certificate serial number appears in the CRL with the 4881 status "suspended" (i.e. on hold), the signature is not to be deemed as 4882 valid since a suspended certificate is not supposed to be used even by 4883 its rightful owner. 4885 C.4.1.2 OCSP information 4887 When using OCSP to get revocation information, a verifier will have to 4888 make sure that he or she gets at the time of the first verification an 4889 OCSP response that contains the status "valid". This should be done as 4890 soon as possible after the generation of the signature, still providing 4891 a "grace period" suitable enough to allow the involved authority to 4892 process a "last minute" revocation request The signer, the verifier or 4893 any other third party may fetch this OCSP response. Since OCSP 4894 responses are transient and thus are not archived by any TSP including 4895 CA, it is the responsibility of every verifier to make sure that it is 4896 stored in a safe place. The simplest way is to store them associated 4897 with the electronic signature. An alternative would be to store them 4898 in some storage so that they can then be easily retrieved, and 4899 incorporate references to them in the electronic signature itself as an 4900 CAdES-C form. 4902 In the same way as for the case of the CRL, it may happen that the 4903 certificate is declared as invalid but with the secondary status 4904 "suspended". In such a case, same comment as for CRL applies. 4906 C.4.2 Certification path 4908 A verifier may have to ascertain that the certification path was valid, 4909 at the time of the signature, up to a trust point according to the: 4911 - naming constraints; 4912 - certificate policy constraints; 4913 - Signature Policy, when applicable. 4915 Since the time of the signature cannot be known with certainty, an 4916 upper limit of it should be used as indicated by either the time stamp 4917 or time mark. 4919 In this case it will be necessary to capture all the certificates from 4920 the certification path, starting with those from the signer and ending 4921 up with those of the self-signed certificate from one trusted root, 4922 when applicable this may be specified as part of the Signature Policy. 4923 In addition, it will be necessary to capture the Certificate Authority 4924 Revocation Lists (CARLs) to prove than none of the CAs from the chain 4925 was revoked at the time of the signature. Again, all this material may 4926 be incorporated in the electronic signature (ES X forms). An 4927 alternative would be to store it in some storage so that they can it be 4928 easily retrieved, and incorporate references to it in the electronic 4929 signature itself as an CAdES-C form. 4931 C.4.3 Time-stamping for long life of signatures 4933 An important property for long standing signatures is that a signature, 4934 having been found once to be valid, shall continue to be so months or 4935 years later. 4937 A signer, verifier or both may be required to provide on request, proof 4938 that a digital signature was created or verified during the validity 4939 period of the all the certificates that make up the certificate path. 4940 In this case, the signer, verifier or both will also be required to 4941 provide proof that the signer's certificate and all the CA certificates 4942 used to form a valid certification path were not revoked when the 4943 signature was created or verified. 4945 It would be quite unacceptable, to consider a signature as invalid even 4946 if the keys or certificates were later compromised. Thus there is a 4947 need to be able to demonstrate that the signature keys was valid at the 4948 time that the signature was created to provide long term evidence of 4949 the validity of a signature. 4951 It could be the case that a certificate was valid at the time of the 4952 signature but revoked some time later. In this event, evidence shall 4953 be provided that the document was signed before the signing key was 4954 revoked. Time-stamping by a Time-Stamping Authority (TSA) can provide 4955 such evidence. A time stamp is obtained by sending the hash value of 4956 the given data to the TSA. The returned "time-stamp" is a signed 4957 document that contains the hash value, the identity of the TSA, and the 4958 time of stamping. This proves that the given data existed before the 4959 time of stamping. Time-stamping a digital signature (by sending a hash 4960 of the signature to the TSA) before the revocation of the signer's 4961 private key, provides evidence that the signature has been created 4962 before the key was revoked. 4964 If a recipient wants to hold a valid electronic signature he will have 4965 to ensure that he has obtained a valid time stamp for it, before that 4966 key (and any key involved in the validation) is revoked. The sooner 4967 the time-stamp is obtained after the signing time, the better. Any 4968 time stamp or time mark that is taken after the expiration date of any 4969 certificate in the certification path has no value in proving the 4970 validity of a signature. 4972 It is important to note that signatures may be generated "off-line" and 4973 time-stamped at a later time by anyone, for example by the signer or 4974 any recipient interested in the value of the signature. The time stamp 4975 can thus be provided by the signer together with the signed document, 4976 or obtained by the recipient following receipt of the signed document. 4978 The time stamp is NOT a component of the Basic Electronic Signature, 4979 but the essential component of the ES with Time-stamp. 4981 It is required in the present document that if a signer's digital 4982 signature value is to be time-stamped, the Time-Stamp Token is issued 4983 by a trusted source, known as a Time-stamping Authority. 4985 The present document requires that the signer's digital signature value 4986 is time-stamped by a trusted source before the electronic signature can 4987 become an ES with Complete validation data. Acceptable TSAs may be 4988 specified in a Signature Validation Policy. 4990 This technique is referred to as CAdES-C in the present document. 4991 Should both the signer and verifier be required to time-stamp the 4992 signature value to meet the requirements of the signature policy, the 4993 signature policy MAY specify a permitted time delay between the two 4994 time stamps. 4996 C.4.4 Time-stamping for long life of signature before CA key 4997 compromises 4999 Time-stamped extended electronic signatures are needed when there is a 5000 requirement to safeguard against the possibility of a CA key in the 5001 certificate chain ever being compromised. A verifier may be required 5002 to provide on request, proof that the certification path and the 5003 revocation information used a the time of the signature were valid, 5004 even in the case where one of the issuing keys or OCSP responder keys 5005 is later compromised. 5007 The present document defines two ways of using time-stamps to protect 5008 against this compromise: 5010 - time-stamp the ES with Complete validation data, when an OCSP 5011 response is used to get the status of the certificate from the 5012 signer (CAdES-X Type 1). This format is suitable to be used with 5013 an OCSP response and offers the additional advantage to provide 5014 an integrity protection over the whole data; 5016 - time-stamp only the certification path and revocation information 5017 references when a CRL is used to get the status of the 5018 certificate from the signer (CAdES-X Type2). This format is 5019 suitable to be used with CRLs, since the time-stamped information 5020 may be used for more than one signature (when signers have their 5021 certificates issued by the same CA and when signatures can be 5022 checked using the same CRLs). 5024 NOTE: The signer, verifier or both may obtain the time-stamp. 5026 C.4.4.1 Time-stamping the ES with complete validation data 5027 (CAdES-X Type 1) 5029 When an OCSP response is used, it is necessary to time stamp in 5030 particular that response in the case the key from the responder would 5031 be compromised. Since the information contained in the OCSP response 5032 is user specific and time specific, an individual time stamp is needed 5033 for every signature received. Instead of placing the time stamp only 5034 over the certification path references and the revocation information 5035 references, which include the OCSP response, the time stamp is placed 5036 on the CAdES-C. Since the certification path and revocation 5037 information references are included in the ES with Complete validation 5038 data they are also protected. For the same cryptographic price, this 5039 provides an integrity mechanism over the ES with Complete validation 5040 data. Any modification can be immediately detected. It should be 5041 noticed that other means of protecting/detecting the integrity of the 5042 ES with Complete Validation Data exist and could be used. 5043 Although the technique requires a time stamp for every signature, it is 5044 well suited for individual users wishing to have an integrity protected 5045 copy of all the validated signatures they have received. 5047 By time-stamping the complete electronic signature, including the 5048 digital signature as well as the references to the certificates and 5049 revocation status information used to support validation of that 5050 signature, the time-stamp ensures that there is no ambiguity in the 5051 means of validating that signature. 5053 This technique is referred to as CAdES-X Type 1 in the present 5054 document. 5056 NOTE: Trust is achieved in the references by including a hash of the 5057 data being referenced. 5059 If it is desired for any reason to keep a copy of the additional data 5060 being referenced, the additional data may be attached to the electronic 5061 signature, in which case the electronic signature becomes an CAdES-X 5062 Long Type 1 as defined by the present document. 5064 An CAdES-X Long Type 1 is simply the concatenation of an CAdES-X Type 1 5065 with a copy of the additional data being referenced. 5067 C.4.4.2 Time-stamping certificates and revocation information 5068 references (CAdES-X Type 2) 5070 Time-stamping each ES with Complete Validation Data as defined above 5071 may not be efficient, particularly when the same set of CA certificates 5072 and CRL information is used to validate many signatures. 5074 Time-stamping CA certificates will stop any attacker from issuing bogus 5075 CA certificates that could be claimed to exist before the CA key was 5076 compromised. Any bogus time-stamped CA certificates will show that the 5077 certificate was created after the legitimate CA key was compromised. 5078 In the same way, time-stamping CA CRLs, will stop any attacker from 5079 issuing bogus CA CRLs which could be claimed to exist before the CA key 5080 was compromised. 5082 Time-stamping of commonly used certificates and CRLs can be done 5083 centrally, e.g. inside a company or by a service provider. This method 5084 reduces the amount of data the verifier has to time-stamp, for example 5085 it could reduce to just one time stamp per day (i.e. in the case were 5086 all the signers use the same CA and the CRL applies for the whole day). 5087 The information that needs to be time stamped is not the actual 5088 certificates and CRLs but the unambiguous references to those 5089 certificates and CRLs. 5091 This technique is referred to as CAdES-X Type 2 in the present document 5092 and requires the following: 5094 - all the CA certificates references and revocation information 5095 references (i.e. CRLs) used in validating the CAdES-C are covered 5096 by one or more time-stamp. 5098 Thus an CAdES-C with a time-stamp signature value at time T1, can be 5099 proved valid if all the CA and CRL references are time-stamped at time 5100 T1+. 5102 C.4.5 Time-stamping for archive of signature 5104 Advances in computing increase the probability of being able to break 5105 algorithms and compromise keys. There is therefore a requirement to be 5106 able to protect electronic signatures against this possibility. 5108 Over a period of time weaknesses may occur in the cryptographic 5109 algorithms used to create an electronic signature (e.g. due to the time 5110 available for crypto analysis, or improvements in crypto analytical 5111 techniques). Before such weaknesses become likely, a verifier should 5112 take extra measures to maintain the validity of the electronic 5113 signature. Several techniques could be used to achieve this goal 5114 depending on the nature of the weakened cryptography. In order to 5115 simplify matters, a single technique, called Archive validation data, 5116 covering all the cases is being used in the present document. 5118 Archive validation data consists of the validation data and the 5119 complete certificate and revocation data, time stamped together with 5120 the electronic signature. The Archive validation data is necessary if 5121 the hash function and the crypto algorithms that were used to create 5122 the signature are no longer secure. Also, if it cannot be assumed that 5123 the hash function used by the Time Stamping Authority is secure, then 5124 nested time-stamps of Archived Electronic Signature are required. 5126 The potential for Trusted Service Provider (TSP) key compromise should 5127 be significantly lower than user keys, because TSP(s) are expected to 5128 use stronger cryptography and better key protection. It can be 5129 expected that new algorithms (or old ones with greater key lengths) 5130 will be used. In such a case, a sequence of time-stamps will protect 5131 against forgery. Each time-stamp needs to be affixed before either the 5132 compromise of the signing key or of the cracking of the algorithms used 5133 by the TSA. TSAs (Time-stamping Authorities) should have long keys 5134 (e.g. which at the time of drafting the present document was at least 5135 2048 bits for the signing RSA algorithm) and/or a "good" or different 5136 algorithm. 5138 Nested time-stamps will also protect the verifier against key 5139 compromise or cracking the algorithm on the old electronic signatures. 5141 The process will need to be performed and iterated before the 5142 cryptographic algorithms used for generating the previous time stamp 5143 are no longer secure. Archive validation data may thus bear multiple 5144 embedded time stamps. 5146 This technique is referred to as CAdES-A in the present document. 5148 C.4.6 Reference to additional data 5150 Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data 5151 verifiers still needs to keep track of all the components that were 5152 used to validate the signature, in order to be able to retrieve them 5153 again later on. These components may be archived by an external source 5154 like a trusted service provider, in which case referenced information 5155 that is provided as part of the ES with Complete validation data 5156 (CAdES-C) is adequate. The actual certificates and CRL information 5157 reference in the CAdES-C can be gathered when needed for arbitration. 5159 If references to additional data are not adequate, then the actual 5160 values of all the certificates and revocation information required may 5161 be part of the electronic signature. This technique is referred to as 5162 CAdES-X Long Type 1 or CAdES-X Long Type 2 in the present document. 5164 C.4.7 Time-stamping for mutual recognition 5166 In some business scenarios both the signer and the verifier need to 5167 time-stamp their own copy of the signature value. Ideally the two 5168 time-stamps should be as close as possible to each other. 5170 EXAMPLE: A contract is signed by two parties A and B representing 5171 their respective organizations, to time-stamp the signer 5172 and verifier data two approaches are possible: 5174 - under the terms of the contract pre-defined common 5175 "trusted" TSA may be used; 5177 - if both organizations run their own time-stamping 5178 services, A and B can have the transaction 5179 time-stamped by these two time-stamping services. 5181 In the latter case, the electronic signature will only be considered as 5182 valid, if both time-stamps were obtained in due time (i.e. there should 5183 not be a long delay between obtaining the two time-stamps). Thus, 5184 neither A nor B can repudiate the signing time indicated by their own 5185 time-stamping service. Therefore, A and B do not need to agree on a 5186 common "trusted" TSA to get a valid transaction. 5188 It is important to note that signatures may be generated "off-line" and 5189 time-stamped at a later time by anyone, e.g. by the signer or any 5190 recipient interested in validating the signature. The time-stamp over 5191 the signature from the signer can thus be provided by the signer 5192 together with the signed document, and/or obtained by the verifier 5193 following receipt of the signed document. 5195 The business scenarios may thus dictate that one or more of the long- 5196 term signature time-stamping methods describe above be used. This may 5197 be part of a mutually agreed Signature Validation Policy which is part 5198 of an agreed signature policy under which digital signature may be used 5199 to support the business relationship between the two parties. 5201 C.4.8 TSA key compromise 5203 TSA servers should be built in such a way that once the private 5204 signature key is installed, there is minimal likelihood of compromise 5205 over as long as possible period. Thus the validity period for the 5206 TSA's keys should be as long as possible. 5208 Both the CAdES-T and the CAdES-C contain at least one time stamp over 5209 the signer's signature. In order to protect against the compromise of 5210 the private signature key used to produce that time-stamp, the Archive 5211 validation data can be used when a different Time-Stamping Authority 5212 key is involved to produce the additional time-stamp. If it is 5213 believed that the TSA key used in providing an earlier time-stamp may 5214 ever be compromised (e.g. outside its validity period), then the CAdES- 5215 A should be used. For extremely long periods this may be applied 5216 repeatedly using new TSA keys. 5218 This technique is referred to as a nested CAdES-A in the present 5219 document. 5221 C.5 Multiple signatures 5223 Some electronic signatures may only be valid if they bear more than one 5224 signature. This is the case generally when a contract is signed 5225 between two parties. The ordering of the signatures may or may not be 5226 important, i.e. one may or may not need to be applied before the other. 5228 Several forms of multiple and counter signatures need to be supported, 5229 which fall into two basic categories: 5231 - independent signatures; 5232 - embedded signatures. 5234 Independent signatures are parallel signatures where the ordering of 5235 the signatures is not important. The capability to have more than one 5236 independent signature over the same data shall be provided. 5238 Embedded signatures are applied one after the other and are used where 5239 the order the signatures are applied is important. The capability to 5240 sign over signed data shall be provided. 5242 These forms are described in clause 5.13. All other multiple signature 5243 schemes, e.g. a signed document with a countersignature, double 5244 countersignatures or multiple signatures, can be reduced to one or more 5245 occurrence of the above two cases. 5247 Annex D (informative):Data protocols to interoperate with TSPs 5249 D.1 Operational protocols 5251 The following protocols can be used by signers and verifiers to 5252 interoperate with Trusted Service Providers during the electronic 5253 signature creation and validation. 5255 D.1.1 Certificate retrieval 5257 User certificates, CA certificate and cross-certificates can be 5258 retrieved from a repository using the Lightweight Directory Access 5259 Protocol as defined in as defined RFC 2559 (see informative 5260 references), with the schema defined in RFC 2587 (see informative 5261 references). 5263 D.1.2 CRL retrieval 5265 Certificate revocation lists, including authority revocation lists and 5266 partial CRL variants, can be retrieved from a repository using the 5267 Lightweight Directory Access Protocol as defined in RFC 2559 (see 5268 informative references), with the schema defined in RFC 2587 (see 5269 informative references). 5271 D.1.3 OnLine certificate status 5273 As an alternative to use of certificate revocation lists the status of 5274 certificate can be checked using the OnLine Certificate Status Protocol 5275 (OCSP) as defined in RFC 2560 [3]. 5277 D.1.4 Time-stamping 5279 The time-stamping service can be accessed using the Time-Stamping 5280 Protocol defined in RFC 3161 [7]. 5282 D.2 Management protocols 5284 Signers and verifiers can use the following management protocols to 5285 manage the use of certificates. 5287 D.2.1 Request for certificate revocation 5289 Request for a certificate to be revoked can be made using the 5290 revocation request and response messages defined in 5291 RFC 2510 (see informative references). 5293 Annex E (informative): Guidance on naming 5295 E.1 Allocation of names 5297 The subject name shall be allocated through a registration scheme 5298 administered through a Registration Authority (RA) to ensure 5299 uniqueness. This RA may be an independent body or a function carried 5300 out by the Certification Authority. 5302 In addition to ensuring uniqueness, the RA shall verify that the name 5303 allocated properly identifies the applicant and that authentication 5304 checks are carried out to protect against masquerade. 5306 The name allocated by an RA is based on registration information 5307 provided by, or relating to, the applicant (e.g. his personal name, 5308 date of birth, residence address) and information allocated by the RA. 5309 Three variations commonly exist: 5311 - the name is based entirely on registration information which 5312 uniquely identifies the applicant (e.g. "Pierre Durand (born on) 5313 July 6, 1956"); 5315 - the name is based on registration information with the addition 5316 of qualifiers added by the registration authority to ensure 5317 uniqueness (e.g. "Pierre Durand 12"); 5319 - the registration information is kept private by the registration 5320 authority and the registration authority allocates a "pseudonym". 5322 E.2 Providing access to registration information 5324 Under certain circumstances it may be necessary for information used 5325 during registration, but not published in the certificate, to be made 5326 available to third parties (e.g. to an arbitrator to resolve a dispute 5327 or for law enforcement). This registration information is likely to 5328 include personal and sensitive information. 5330 Thus the RA needs to establish a policy for: 5332 - whether the registration information should be disclosed; 5333 - to whom such information should be disclosed; 5334 - under what circumstances such information should be disclosed. 5336 This policy may be different whether the RA is being used only within a 5337 company or for public use. The policy will have to take into account 5338 national legislation and in particular any data protection and privacy 5339 legislation. 5341 Currently, the provision of access to registration is a local matter 5342 for the RA. However, if open access is required, standard protocols 5343 such as HTTP - RFC 2068 (Internet Web Access Protocol) may be employed 5344 with the addition of security mechanisms necessary to meet the data 5345 protection requirements (e.g. Transport Layer Security - RFC 2246 with 5346 client authentication). 5348 E.3 Naming schemes 5350 E.3.1 Naming schemes for individual citizens 5352 In some cases the subject name that is contained in a public key 5353 certificate may not be meaningful enough. This may happen because of 5354 the existence of homonyms or because of the use of pseudonyms. A 5355 distinction could be made if more attributes were present. However, 5356 adding more attributes to a public key certificate placed in a public 5357 repository would be going against the privacy protection requirements. 5359 In any case the Registration Authority will get information at the time 5360 of registration but not all that information will be placed in the 5361 certificate. In order to achieve a balance between these two opposite 5362 requirements the hash values of some additional attributes can be 5363 placed in a public key certificate. When the certificate owner 5364 provides these additional attributes, then they can be verified. Using 5365 biometrics attributes may unambiguously identify a person. Example of 5366 biometrics attributes that can be used include: a picture or a manual 5367 signature from the certificate owner. 5369 NOTE: Using hash values protects privacy only if the possible inputs 5370 are large enough. For example, using the hash of a person's 5371 social security number is generally not sufficient since it 5372 can easily be reversed. 5374 A picture can be used if the verifier once met the person and later on 5375 wants to verify that the certificate that he or she got relates to the 5376 person whom was met. In such a case, at the first exchange the picture 5377 is sent and the hash contained in the certificate may be used by the 5378 verifier to verify that it is the right person. At the next exchange 5379 the picture does not need to be sent again. 5381 A manual signature may be used if a signed document has been received 5382 beforehand. In such a case, at the first exchange the drawing of the 5383 manual signature is sent and the hash contained in the certificate may 5384 be used by the verifier to verify that it is the right manual 5385 signature. At the next exchange the manual signature does not need to 5386 be sent again. 5388 E.3.2 Naming schemes for employees of an organization 5390 The name of an employee within an organization is likely to be some 5391 combination of the name of the organization and the identifier of the 5392 employee within that organization. 5394 An organization name is usually a registered name, i.e. business or 5395 trading name used in day to day business. This name is registered by a 5396 Naming Authority, which guarantees that the organization's registered 5397 name is unambiguous and cannot be confused with another organization. 5398 In order to get more information about a given registered organization 5399 name, it is necessary to go back to a publicly available directory 5400 maintained by the Naming Authority. 5402 The identifier may be a name or a pseudonym (e.g. a nickname or a 5403 employee number). When it is a name, it is supposed to be descriptive 5404 enough to unambiguously identify the person. When it is a pseudonym, 5405 the certificate does not disclose the identity of the person. However 5406 it ensures that the person has been correctly authenticated at the time 5407 of registration and therefore may be eligible to some advantages 5408 implicitly or explicitly obtained through the possession of the 5409 certificate. In either case, however, this can be insufficient because 5410 of the existence of homonyms. 5412 Placing more attributes in the certificate may be one solution, for 5413 example by giving the organization unit of the person or the name of a 5414 city where the office is located. However the more information is 5415 placed in the certificate the more problems arise if there is a change 5416 in the organization structure or the place of work. So this may not be 5417 the best solution. An alternative is to provide more attributes (like 5418 the organization unit and the place of work) through access to a 5419 directory maintained by the company. It is likely that at the time of 5420 registration the Registration Authority got more information than what 5421 was placed in the certificate, if such additional information is placed 5422 in a repository accessible only to the organization. 5424 Annex F (informative): Example structured contents and MIME 5426 F.1 General description 5428 The signed content may be structured as using MIME (Multipurpose 5429 Internet Mail Extensions - RFC 2045 [6]. Whilst the MIME structure was 5430 initially developed for Internet e-mail, it has a number of features 5431 which make it useful to provide a common structure for encoding a range 5432 of electronic documents and other multi-media data (e.g. photographs, 5433 video). These features include: 5435 - it provides a means of signalling the type of "object" being 5436 carried (e.g. text, image, ZIP file, application data); 5438 - it provides a means of associating a file name with an object; 5440 - it can associate several independent "objects" (e.g. a document 5441 and image) to form a multi-part object; 5443 - it can handle data encoded in text or binary and, if necessary, 5444 re-encode the binary as text. 5446 When encoding a single object MIME consists of: 5448 - header information, followed by; 5449 - encoded content. 5451 This structure can be extended to support multi-part content. 5453 F.2 Header information 5455 A MIME header includes: 5457 MIME Version information: 5458 e.g.: MIME-Version: 1.0 5460 Content type information which includes information describing the 5461 content sufficient for it to presented to a user or application process 5462 as required. This includes information on the "media type" (e.g. text, 5463 image, audio) or whether the data is for passing to a particular type 5464 of application. In the case of text the content type includes 5465 information on the character set used. 5467 e.g. Content-Type: text/plain; charset="us-ascii" 5469 Content encoding information, which defines how the content is encoded. 5470 (See below about encoding supported by MIME). 5472 Other information about the content such as a description, or an 5473 associated file name. 5475 An example MIME header for text object is: 5477 Mime-Version: 1.0 5478 Content-Type: text/plain; charset=ISO-8859-1 5479 Content-Transfer-Encoding: quoted-printable 5481 An example MIME header for a binary file containing a word document is: 5483 Content-Type: application/octet-stream 5484 Content-Transfer-Encoding: base64 5485 Content-Description: JCFV201.doc (Microsoft Word Document) 5486 Content-Disposition: filename="JCFV201.doc" 5488 F.3 Content encoding 5490 MIME supports a range of mechanisms for encoding the both text and 5491 binary data. 5493 Text data can be carried transparently as lines of text data encoded in 5494 7 or 8 bit ASCII characters. MIME also includes a "quoted-printable" 5495 encoding which converts characters other than the basic ASCII into an 5496 ASCII sequence. 5498 Binary can either be carried: 5500 - transparently a 8 bit octets; or 5501 - converted to a basic set of characters using a system called 5502 Base64. 5504 NOTE: As there are some mail relays which can only handle 7 bit 5505 ASCII, Base64 encoding is usually used on the Internet. 5507 F.4 Multi-part content 5509 Several objects (e.g. text and a file attachment) can be associated 5510 together using a special "multi-part" content type. This is indicated 5511 by the content type "multipart" with an indication of the string to be 5512 used indicate a separation between each part. 5514 In addition to a header for the overall multipart content, each part 5515 includes its own header information indicating the inner content type 5516 and encoding. 5518 An example of a multipart content is: 5520 Mime-Version: 1.0 5521 Content-Type: multipart/mixed; boundary="---- 5522 =_NextPart_000_01BC4599.98004A80" 5523 Content-Transfer-Encoding: 7bit 5524 ------=_NextPart_000_01BC4599.98004A80 5525 Content-Type: text/plain; charset=ISO-8859-1 5526 Content-Transfer-Encoding: 7bit 5528 Per your request, I've attached our proposal for the Java Card Version 5529 2.0 API and the Java Card FAQ. 5531 ------=_NextPart_000_01BC4599.98004A80 5532 Content-Type: application/octet-stream; name="JCFV201.doc" 5533 Content-Transfer-Encoding: base64 5534 Content-Description: JCFV201.doc (Microsoft Word Document) 5535 Content-Disposition: attachment; filename="JCFV201.doc" 5537 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA 5538 AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// 5539 //////////AANhAAQAYg== 5541 ------=_NextPart_000_01BC4599.98004A80-- 5543 Multipart content can be nested. So a set of associated objects (e.g. 5544 HTML text and images) can be handled as a single attachment to another 5545 object (e.g. text). 5547 F.5 S/MIME 5549 Previous clauses in this annex have described the use of MIME to encode 5550 data. MIME encoded data can be signed (i.e. carried in the eContent of 5551 the SignedData structure) thereby signalling the type of information 5552 that has been signed. 5554 MIME can also be used to encode the CMS structure containing data after 5555 it has been signed so that, for example, this can be carried within an 5556 e-mail message. The specific use of MIME to carry CMS (extended as 5557 defined in the present document) secured data is called S/MIME. The 5558 relationship between the general use of MIME for encoding content, CMS 5559 and S/MIME is illustrated in figure F.1. 5561 +------------++-------------++----------++------------++------------+ 5562 | || || || || | 5563 | E-mail || S/MIME || CAdES || MIME || Word file | 5564 | || || || || | 5565 |From: Smith ||Content Type=||SignedData||ContentType=||Dear MrSmith| 5566 |To:Jones ||application/ || Econtent ||application/||Received | 5567 |Subject: ||pkcs7 || ||octet-stream|| 100 tins | 5568 |Signed doc. || || || || | 5569 | /| || /| || /| || /| || Mr.Jones | 5570 | / -----+ / -----+ / -----+ / -----+ | 5571 | \ -----+ \ -----+ \ -----+ \ -----+ | 5572 | \| || \| || \| || \| || | 5573 | |+------------- | |+------------+| | 5574 +------------+ ++----------+ +------------+ 5576 Figure F.1 5578 S/MIME carries electronic signatures as either: 5580 - an "application/pkcs7-mime" object with the CMS carried as binary 5581 attachment (PKCS7 is the name of the early version of CMS). 5583 An example of signed data encoded using this approach is: 5584 Content-Type: application/pkcs7-mime; smime-type=signed-data; 5585 Content-Transfer-Encoding: base64 5586 Content-Disposition: attachment; filename=smime.p7m 5588 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 5589 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 5590 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 5591 6YT64V0GhIGfHfQbnj75 5593 This approach is similar to handling signed data as any other binary 5594 file attachment. Thus, this encoding can be used where signed data 5595 passes through gateways to other e-mail systems (e.g. those based on 5596 other e-mail systems). 5597 A "multipart/signed" object with the signed data and the signature 5598 encoded as separate MIME objects. 5600 An example of signed data encoded this approach is: 5601 Content-Type: multipart/signed; 5602 protocol="application/pkcs7-signature"; 5603 micalg=sha1; boundary=boundary42 5605 --boundary42 5606 Content-Type: text/plain 5608 This is a clear-signed message. 5610 --boundary42 5611 Content-Type: application/pkcs7-signature; name=smime.p7s 5612 Content-Transfer-Encoding: base64 5613 Content-Disposition: attachment; filename=smime.p7s 5615 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 5616 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 5617 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 5618 7GhIGfHfYT64VQbnj756 5620 --boundary42-- 5622 With this second approach MIME the signed data passes through the CMS 5623 process and is carried as part of the S/MIME structure as illustrated 5624 in figure F.2. The CMS structure just holds the electronic signature. 5626 +------------++-------------++----------++------------++------------+ 5627 | || || || || | 5628 | E-mail || | /MIME || CAdES || MIME || Word file | 5629 | || || || || | 5630 |From: Smith ||Content Type=||SignedData||ContentType=||Dear MrSmith| 5631 |To:Jones ||multipart/ || ||application/||Received | 5632 |Subject: ||signed || ||octet-stream|| 100 tins | 5633 |Signed doc. || /| || || || | 5634 | /| || / -----------------+ /| || Mr.Jones | 5635 | / -----+ \ -----------------+ / -----+ | 5636 | \ -----+ \| || || \ -----+ | 5637 | \| ||ContentType= || || \| || | 5638 +------------+|application/ || |+------------+| | 5639 |octet-stream || | +------------+ 5640 | || | 5641 |ContentType= || | 5642 |application/ || | 5643 |pkcs7- || | 5644 |signature || | 5645 | /| || | 5646 | / -----+ | 5647 | \ -----+ | 5648 | \| ||----------+ 5649 | | 5650 +-------------+ 5652 Figure F.2 5654 The second approach (multipart/signed) has the advantage that the 5655 signed data can be decoded by any MIME compatible e-mail system even if 5656 it does not recognize CMS encoded electronic signatures. However, this 5657 form cannot be used with other e-mail systems. 5659 Annex G (informative): Relationship to the European Directive and EESSI 5661 G.1 Introduction 5663 This annex provides an indication of the relationship between 5664 electronic signatures created under the present document and 5665 requirements under the European Parliament and Council Directive on a 5666 Community framework for electronic signatures. 5668 NOTE: Legal advice should be sought on the specific national 5669 legislation regarding use of electronic signatures. 5671 The present document is one of a set of standards being defined under 5672 the "European Electronic Signature Standardization Initiative" (EESSI) 5673 for electronic signature products and solutions compliant with the 5674 European Directive for electronic signatures. 5676 G.2 Electronic signatures and the directive 5678 This directive defines electronic signatures as: 5680 - "data in electronic form which are attached to or logically 5681 associated with other electronic data and which serve as a method 5682 of authentication". 5684 The directive states that an electronic signature should not be denied 5685 "legal effectiveness and admissibility as evidence in legal 5686 proceedings" solely on the grounds that it is in electronic form. 5688 The directive identifies an electronic signature as having equivalence 5689 to a hand-written signature if it meets specific criteria: 5691 - it is an "advanced electronic signature" with the following 5692 properties: 5694 a) it is uniquely linked to the signatory; 5696 b) it is capable of identifying the signatory; 5698 c) it is created using means that the signatory can maintain 5699 under his sole control; and 5701 d) it is linked to the data to which it relates in such a 5702 manner that any subsequent change of the data is detectable. 5704 - it is based on a certificate which meets detailed criteria given 5705 in annex I to the directive and is issued by a "certification- 5706 service-provider" which meets requirements given in annex II to 5707 the directive. Such a certificate is referred to as a "qualified 5708 certificate"; 5710 - it is created by a "device" which detailed criteria given in 5711 annex III to the directive. Such a device is referred to a 5712 "secure-signature-creation device"; 5714 This form of electronic signature is referred to as a "qualified 5715 electronic signature" in EESSI (see below). 5717 G.3 ETSI electronic signature formats and the directive 5718 An electronic signature created in accordance with the present document 5719 is: 5721 a) considered to be an "electronic signature" under the terms of 5722 the Directive; 5724 b) considered to be an "advanced electronic signature" under the 5725 terms of the Directive; 5727 c) considered to be a "Qualified Electronic Signature" provided the 5728 additional requirements in annex I, II and III of the Directive 5729 are met. The requirements in annex I, II and III of the 5730 Directive are outside the scope of the present document, and are 5731 subject to further standardization. 5733 G.4 EESSI standards and classes of electronic signature 5735 G.4.1 Structure of EESSI standardization 5737 EESSI looks at standards in several areas. See the ETSI ESI and CEN 5738 web sites for the latest list of standards and their versions 5740 - use of X.509 public key certificates as qualified certificates; 5742 - security Management and Certificate Policy for CSPs Issuing 5743 Qualified Certificates; 5745 - security requirements for trustworthy systems used by CSPs 5746 Issuing Qualified Certificates; 5748 - security requirements for Secure Signature Creation Devices; 5750 - security requirements for Signature Creation Systems; 5752 - procedures for Electronic Signature Verification; 5754 - electronic signature syntax and encoding formats; 5756 - protocol to interoperate with a Time Stamping Authority; 5758 - Policy requirements for Time-Stamping Authorities; 5760 - XML electronic signature formats. 5762 Each of these standards addresses a range of requirements including the 5763 requirements of Qualified Electronic Signatures as specified in article 5764 5.1 of the Directive. However, some of them also address general 5765 requirements of electronic signatures for business and electronic 5766 commerce which all fall into the category of article 5.2 of the 5767 Directive. Such variation in the requirements may be identified either 5768 as different levels or different options. 5770 G.4.2 Classes of electronic signatures 5772 Since some of these standards address a range of requirements, it may 5773 be useful to identify a set of standards to address a specific business 5774 need. Such a set of standards and their uses defines a class of 5775 electronic signature. The first class already identified is the 5776 qualified electronic signature, fulfilling the requirements of article 5777 5.1 of the Directive. 5779 A limited number of "classes of electronic signatures" and 5780 corresponding profiles could be defined by EESSI, in close co-operation 5781 with actors on the market (business, users, suppliers). Need for such 5782 standards is envisaged, in addition to those for qualified electronic 5783 signatures, in areas such as: 5785 - different classes of electronic signatures with long term 5786 validity; 5788 - electronic signatures for business transactions with limited 5789 value. 5791 G.4.3 EESSI classes and the ETSI electronic signature format 5792 The electronic signature format defined in the present document is 5793 applicable to the EESSI area "electronic signature and encoding 5794 formats". 5796 An electronic signature produced by a signer (see clause 5 and 5797 conformance clause 10.1) is applicable to the proposed class of 5798 electronic signature: "qualified electronic signatures fulfilling 5799 article 5.1". 5801 With the addition of validation data by the verifier (see clause 6 and 5802 conformance clause 10.2) this would become applicable electronic 5803 signatures adding long-term validity attributes to the qualified 5804 electronic signature. 5806 Annex H (informative):APIs for the generation and verification of 5807 electronic signatures tokens 5809 While the present document describes the data format of an electronic 5810 signature, the question is whether there exists APIs (Application 5811 Programming Interfaces) able to manipulate these structures. At least 5812 two such APIs have been defined. One set by the IETF and another set 5813 by the OMG (Object Management Group). 5815 H.1 Data framing 5817 In order to be able to use either of these APIs, it will be necessary 5818 to frame the previously defined electronic signature data structures 5819 using a mechanism-independent token format. Clause 3.1 of RFC 2743 5820 (see informative references) describes that framing incorporating an 5821 identifier of the mechanism type to be used and enabling tokens to be 5822 interpreted unambiguously. 5824 In order to be processable by these APIs, all electronic signature data 5825 formats that are defined in the present document shall be framed 5826 following that description. 5828 The encoding format for the token tag is derived from ASN.1 and DER, 5829 but its concrete representation is defined directly in terms of octets 5830 rather than at the ASN.1 level in order to facilitate interoperable 5831 implementation without use of general ASN.1 processing code. The token 5832 tag consists of the following elements, in order: 5834 1) 0x60 -- Tag for RFC 2743 SEQUENCE; indicates that constructed 5835 form, definite length encoding follows. 5837 2) Token length octets, specifying length of subsequent data (i.e. 5838 the summed lengths of elements 3 to 5 in this list, and of the 5839 mechanism-defined token object following the tag). This element 5840 comprises a variable number of octets: 5842 a) If the indicated value is less than 128, it shall be 5843 represented in a single octet with bit 8 (high order) set to 5844 "0" and the remaining bits representing the value. 5846 b) If the indicated value is 128 or more, it shall be represented 5847 in two or more octets, with bit 8 of the first octet set to 5848 "1" and the remaining bits of the first octet specifying the 5849 number of additional octets. The subsequent octets carry the 5850 value, 8 bits per octet, most significant digit first. The 5851 minimum number of octets shall be used to encode the length 5852 (i.e. no octets representing leading zeros shall be included 5853 within the length encoding). 5855 3) 0x06 -- Tag for OBJECT IDENTIFIER. 5857 4) Object identifier length -- length (number of octets) of the 5858 encoded object identifier contained in element 5, encoded per 5859 rules as described in 2a) and 2b) above. 5861 5) object identifier octets -- variable number of octets, encoded 5862 per ASN.1 BER rules: 5864 - The first octet contains the sum of two values: 5866 (1) the top-level object identifier component, multiplied by 5867 40 (decimal); and 5869 (2) the second-level object identifier component. 5871 This special case is the only point within an object 5872 identifier encoding where a single octet represents contents 5873 of more than one component. 5875 - Subsequent octets, if required, encode successively-lower 5876 components in the represented object identifier. A 5877 component's encoding may span multiple octets, encoding 7 bits 5878 per octet (most significant bits first) and with bit 8 set to 5879 "1" on all but the final octet in the component's encoding. 5880 The minimum number of octets shall be used to encode each 5881 component (i.e. no octets representing leading zeros shall be 5882 included within a component's encoding). 5884 NOTE: In many implementations, elements 3 to 5 may be stored and 5885 referenced as a contiguous string constant. 5887 The token tag is immediately followed by a mechanism-defined token 5888 object. Note that no independent size specifier intervenes following 5889 the object identifier value to indicate the size of the mechanism- 5890 defined token object. 5892 Tokens conforming to the present document shall have the following OID 5893 in order to be processable by IDUP-APIs: 5895 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 5896 { itu-t(0) identified-organization(4) etsi(0) 5897 electronic-signature-standard (1733) part1 (1) IDUPMechanism (4) 5898 etsiESv1(1) } 5900 H.2 IDUP-GSS-APIs defined by the IETF 5902 The IETF CAT WG has produced in December 1998 an RFC (RFC 2479 - see 5903 informative references) under the name of IDUP-GSS-API (Independent 5904 Data Unit Protection) able to handle the electronic signature data 5905 format defined in the present document. 5907 The IDUP-GSS-API includes support for non-repudiation services. 5909 It supports evidence generation, where "evidence" is information that 5910 either by itself, or when used in conjunction with other information, 5911 is used to establish proof about an event or action, as well a evidence 5912 verification. 5914 IDUP supports various types of evidences. All the types defined in 5915 IDUP are supported in the present document through the commitment type 5916 parameter. 5918 Clause 2.3.3 of IDUP describes the specific calls needed to handle 5919 evidences ("EV" calls). The "EV" group of calls provides a simple, 5920 high-level interface to underlying IDUP mechanisms when application 5921 developers need to deal only with evidences but not with encryption or 5922 integrity services. 5924 All generations and verification are performed according to the content 5925 of a NR policy that is referenced in the context. 5927 Get_token_details is used to return to an application the attributes 5928 that correspond to a given input token. Since IDUP-GSS- API tokens are 5929 meant to be opaque to the calling application, this function allows the 5930 application to determine information about the token without having to 5931 violate the opaqueness intention of IDUP. Of primary importance is the 5932 mechanism type, which the application can then use as input to the 5933 IDUP_Establish_Env() call in order to establish the correct environment 5934 in which to have the token processed. 5936 Generate_token generates a non-repudiation token using the current 5937 environment. 5939 Verify_evidence verifies the evidence token using the current 5940 environment. This operation returns a major_status code which can be 5941 used to determine whether the evidence contained in a token is complete 5942 (i.e. can be successfully verified (perhaps years) later). If a 5943 token's evidence is not complete, the token can be passed to another 5944 API: form_complete_pidu to complete it. This happens when a status 5945 "conditionally valid" is returned. That status corresponds to the 5946 status "validation incomplete" of the present document. 5948 Form_complete_PIDU is used primarily when the evidence token itself 5949 does not contain all the data required for its verification and it is 5950 anticipated that some of the data not stored in the token may become 5951 unavailable during the interval between generation of the evidence 5952 token and verification unless it is stored in the token. The 5953 Form_Complete_PIDU operation gathers the missing information and 5954 includes it in the token so that verification can be guaranteed to be 5955 possible at any future time. 5957 H.3 CORBA security interfaces defined by the OMG 5959 Non-repudiation interfaces have been defined in "CORBA Security", a 5960 document produced by the OMG (Object Management Group). These 5961 interfaces are described in IDL (Interface Definition Language) and are 5962 optional. 5964 The handling of "tokens" supporting non-repudiation is done through the 5965 following interfaces: 5967 - set_NR_features specifies the features to apply to future 5968 evidence generation and verification operations; 5970 - get_NR_features returns the features which will be applied to 5971 future evidence generation and verification operations; 5973 - generate_token generates a Non-repudiation token using the 5974 current Non-repudiation features; 5976 - verify_evidence verifies the evidence token using the current 5977 Non-repudiation features; 5978 - get_tokens_details returns information about an input Non- 5979 repudiation token. The information returned depends upon the 5980 type of token; 5982 - form_complete_evidence is used when the evidence token itself 5983 does not contain all the data required for its verification, and 5984 it is anticipated that some of the data not stored in the token 5985 may become unavailable during the interval between generation of 5986 the evidence token and verification unless it is stored in the 5987 token. The form_complete_evidence operation gathers the missing 5988 information and includes it in the token so that verification can 5989 be guaranteed to be possible at any future time. 5991 NOTE: The similarity between the two sets of APIs is noticeable. 5993 Annex I (informative):Cryptographic algorithms 5995 RFC 3370 [10] describes the conventions for using several cryptographic 5996 algorithms with the Crytographic Message Syntax (CMS). Only the 5997 hashing and signing algorithms are appropriate for use with the present 5998 document. 6000 Since the publication of RFC 3370 [10], MD5 has been broken. This 6001 algorithm is no more considered as appropriate and has been deleted 6002 from the list of algorithms. 6004 I.1 Digest algorithms 6006 I.1.1 SHA-1 6008 The SHA-1 digest algorithm is defined in FIPS Pub 180-1. The algorithm 6009 identifier for SHA-1 is: 6011 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) 6012 secsig(3) algorithm(2) 26 } 6014 The AlgorithmIdentifier parameters field is optional. If present, the 6015 parameters field shall contain an ASN.1 NULL. Implementations should 6016 accept SHA-1 AlgorithmIdentifiers with absent parameters as well as 6017 NULL parameters. Implementations should generate SHA-1 6018 AlgorithmIdentifiers with NULL parameters. 6020 I.1.2 General 6022 The following is a selection of work that has been done in the area of 6023 digest algorithms or, as they are often called, hash functions: 6025 - ISO/IEC 10118-1 (1994): "Information technology - Security 6026 techniques - Hash-functions - Part 1: General". ISO/IEC 10118-1 6027 contains definitions and describes basic concepts. 6029 - ISO/IEC 10118-2 (1994): "Information technology - Security 6030 techniques - Hash-functions - Part 2: Hash-functions using an n- 6031 bit block cipher algorithm". ISO/IEC 10118-2 specifies two ways 6032 to construct a hash-function from a block cipher. 6034 - ISO/IEC 10118-3 (1997): "Information technology - Security 6035 techniques - Hash-functions - Part 3: Dedicated hash-functions". 6036 ISO/IEC 10118-3 specifies the following dedicated hash-functions: 6038 - SHA-1 (FIPS 180-1); 6039 - RIPEMD-128; 6040 - RIPEMD-160. 6042 - ISO/IEC 10118-4 (1998): "Information technology - Security 6043 techniques - Hash-functions - Part 4: Hash-functions using 6044 modular arithmetic". 6046 - RFC 1320 (PS 1992): "The MD4 Message-Digest Algorithm". RFC 1320 6047 specifies the hash-function MD4. Today, MD4 is considered out- 6048 dated. 6050 - RFC 1321 (I 1992): "The MD5 Message-Digest Algorithm". RFC 1321 6051 (informational) specifies the hash-unction MD5. 6053 - FIPS Publication 180-1 (1995): "Secure Hash Standard". FIPS 180-1 6054 specifies the Secure Hash Algorithm (SHA), dedicated hash- 6055 function developed for use with the DSA. The original SHA 6056 published in 1993 was slightly revised in 1995 and renamed SHA-1. 6058 - ANSI X9.30-2 (1997): "Public Key Cryptography for the Financial 6059 Services Industry - Part 2: The Secure Hash Algorithm (SHA-1)". 6060 X9.30-2 specifies the ANSI-Version of SHA-1. 6062 - ANSI X9.31-2 (1996): "Public Key Cryptography Using Reversible 6063 Algorithms for the Financial Services Industry - Part 2: Hash 6064 Algorithms". X9.31-2 specifies hash algorithms. 6066 I.2 Digital signature algorithms 6068 I.2.1 DSA 6070 The DSA signature algorithm is defined in FIPS Pub 186. DSA is always 6071 used with the SHA-1 message digest algorithm. The algorithm identifier 6072 for DSA is: 6074 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 6075 x9-57 (10040) x9cm(4) 3 } 6077 The AlgorithmIdentifier parameters field shall not be present. 6079 I.2.2 RSA 6081 The RSA signature algorithm is defined in RFC 2437 (see informative 6082 references). RFC 3370 [10] specifies the use of the RSA signature 6083 algorithm with the SHA-1 algorithm. The algorithm identifier for RSA 6084 with SHA-1 is: 6086 Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 6087 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 6089 NOTE: RFC 3370 [10] recommends that MD5 is not used for new 6090 implementations. 6092 I.2.3 General 6094 The following is a selection of work that has been done in the area of 6095 digital signature mechanisms: 6097 - FIPS Publication 186 (1994): "Digital Signature Standard". 6098 NIST's Digital Signature Algorithm (DSA) is a variant of 6099 ElGamal's Discrete Logarithm based digital signature mechanism. 6100 The DSA requires a 160-bit hash-function and mandates SHA-1. 6102 - IEEE P1363 (2000): "Standard Specifications for Public-Key 6103 Cryptography". IEEE P1363 contains mechanisms for digital 6104 signatures, key establishment, and encipherment based on three 6105 families of public-key schemes: 6107 - "Conventional" Discrete Logarithm (DL) based techniques, i.e. 6108 Diffie-Hellman (DH) key agreement, Menezes-Qu-Vanstone (MQV) 6109 key agreement, the Digital Signature Algorithm (DSA), and 6110 Nyberg-Rueppel (NR) digital signatures; 6112 - Elliptic Curve (EC) based variants of the DL-mechanisms 6113 specified above, i.e. EC-DH, EC-MQV, EC-DSA, and EC-NR. For 6114 elliptic curves, implementation options include mod p and 6115 characteristic 2 with polynomial or normal basis 6116 representation; 6118 - Integer Factoring (IF) based techniques including RSA 6119 encryption, RSA digital signatures, and RSA-based key 6120 transport. 6122 - ISO/IEC 9796 (1991): "Information technology - Security 6123 techniques - Digital signature scheme giving message recovery". 6124 ISO/IEC 9796 specifies a digital signature mechanism based on the 6125 RSA public-key technique and a specifically designed redundancy 6126 function. 6128 - ISO/IEC 9796-2 (1997): "Information technology - Security 6129 techniques - Digital signature schemes giving message recovery - 6130 Part 2: Mechanisms using a hash-function". ISO/IEC 9796-2 6131 specifies digital signature mechanisms with partial message 6132 recovery that are also based on the RSA technique but make use of 6133 a hash-function. 6135 - ISO/IEC 9796-4 (1998): "Digital signature schemes giving message 6136 recovery - Part 4: Discrete logarithm based mechanisms". ISO/IEC 6137 9796-4 specifies digital signature mechanisms with partial 6138 message recovery that are based on Discrete Logarithm techniques. 6139 The document includes the Nyberg-Rueppel scheme. 6141 - ISO/IEC 14888-1: "Digital signatures with appendix - Part 1: 6142 General". ISO/IEC 14888-1 contains definitions and describes the 6143 basic concepts of digital signatures with appendix. 6145 - ISO/IEC 14888-2: "Digital signatures with appendix - Part 2: 6146 Identity-based mechanisms". ISO/IEC 14888-2 specifies digital 6147 signature schemes with appendix that make use of identity-based 6148 keying material. The document includes the zero-knowledge 6149 techniques of Fiat-Shamir and Guillou-Quisquater. 6151 - ISO/IEC 14888-3: "Digital signatures with appendix - Part 3: 6152 Certificate-based mechanisms". ISO/IEC 14888-3 specifies digital 6153 signature schemes with appendix that make use of certificate- 6154 based keying material. The document includes five schemes: 6156 - DSA; 6157 - EC-DSA, an elliptic curve based analog of NIST's Digital 6158 Signature Algorithm; 6159 - Pointcheval-Vaudeney signatures; 6160 - RSA signatures; 6161 - ESIGN. 6163 - ISO/IEC 15946-2 (2002) : "Cryptographic techniques based on 6164 elliptic curves - Part 2: Digital signatures". 6166 - ISO/IEC 15946-3 (2002) specifies digital signature schemes with 6167 appendix using elliptic curves. 6169 - The document includes two schemes: 6171 - EC-DSA, an elliptic curve based analog of NIST's Digital 6172 Signature Algorithm; 6174 - EC-AMV, an elliptic curve based analog of the Agnew-Muller- 6175 Vanstone signature algorithm. 6177 - ANSI X9.31-1 (1997): "Public Key Cryptography Using Reversible 6178 Algorithms for the Financial Services Industry - Part 1: The RSA 6179 Signature Algorithm". ANSI X9.31-1 specifies a digital signature 6180 mechanism with appendix using the RSA public-key technique. 6182 - ANSI X9.30-1 (1997): "Public Key Cryptography Using Irreversible 6183 Algorithms for the Financial Services Industry - Part 1: The 6184 Digital Signature Algorithm (DSA)". ANSI X9.30-1 specifies the 6185 DSA, NIST's Digital Signature Algorithm. 6187 - ANSI X9.62 (1998): "Public Key Cryptography for the Financial 6188 Services Industry - The Elliptic Curve Digital Signature 6189 Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic Curve 6190 Digital Signature Algorithm, an analog of NIST's Digital 6191 Signature Algorithm (DSA) using elliptic curves. The appendices 6192 provide tutorial information on the underlying mathematics for 6193 elliptic curve cryptography and many examples. 6195 Annex J (informative): Changes from the previous version 6197 The title of the document has changed to be aligned with the title 6198 of XAdES, the vocabulary used within the present document has been 6199 aligned with the vocabulary used in XAdES, 6201 In the previous version of TS 101 733 (i.e. version 1.5.1) 6202 sigPolicyHash was mandatory. Implementations requiring to be 6203 backward compatible with version 1.5.1 and previous versions 6204 of the current document MUST include SigPolicyHash. 6206 The OIDs from the ASN.1 modules have changed for the following 6207 reasons: 6209 - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have been 6210 included. 6212 - since RFC 2459 and RFC 3369 has been obsoleted by RFC 3280 and 6213 RFC 3852 respectively, there was the need to refer to the OIDs 6214 of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the 6215 OIDs of the ASN.1 modules of RFC 2459 and RFC 3369. 6217 - the other change is related to the field sigPolicyHash from 6218 SignaturePolicyId (see clause 5.8.1). That field was mandatory 6219 and is now optional. 6221 Full Copyright Statement 6223 Copyright (C) The Internet Society (2005). 6225 The contents of this Informational RFC amounts to a transposition of 6226 the ETSI TS 101 733 V.1.6.3 and is technically equivalent to it. 6227 The ETSI TS is under the ETSI Copyright (C). Individual copies of 6228 this ETSI deliverable can be downloaded from http://www.etsi.org. 6230 This document is subject to the rights, licenses and restrictions 6231 contained in BCP 78, and except as set forth therein, the authors 6232 retain all their rights. 6234 Disclaimer 6236 This document and the information contained herein are provided on 6237 An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 6238 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 6239 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 6240 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 6241 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 6242 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 6243 PARTICULAR PURPOSE. 6245 Intellectual Property 6247 The IETF takes no position regarding the validity or scope of any 6248 Intellectual Property Rights or other rights that might be claimed 6249 to pertain to the implementation or use of the technology described 6250 in this document or the extent to which any license under such 6251 rights might or might not be available; nor does it represent that 6252 it has made any independent effort to identify any such rights. 6253 Information on the procedures with respect to rights in RFC 6254 documents can be found in BCP 78 and BCP 79. 6256 Copies of IPR disclosures made to the IETF Secretariat and any 6257 assurances of licenses to be made available, or the result of an 6258 attempt made to obtain a general license or permission for the use 6259 of such proprietary rights by implementers or users of this 6260 specification can be obtained from the IETF on-line IPR repository 6261 at http://www.ietf.org/ipr. 6263 The IETF invites any interested party to bring to its attention any 6264 copyrights, patents or patent applications, or other proprietary 6265 rights that may cover technology that may be required to implement 6266 this standard. Please address the information to the IETF at ietf- 6267 ipr@ietf.org. 6269 ETSI takes no position regarding the validity or scope of any 6270 Intellectual Property Rights or other rights that might be claimed 6271 to pertain to the implementation or use of the technology described 6272 in this document or the extent to which any license under such 6273 rights might or might not be available; nor does it represent that 6274 it has made any independent effort to identify any such rights. 6276 Information on the ETSI Intellectual Property Rights Policy may be 6277 obtained from . The document is 6278 an extract from Annex 6 of the ETSI Rules of Procedure that are 6279 available at : . 6281 The ETSI IPR database http://webapp.etsi.org/IPR/home.asp contains 6282 IPRs, particularly patents and patent applications, which have been 6283 notified to ETSI as being essential, or potentially essential, to 6284 ETSI standards. Unless otherwise specified, all IPRs contained 6285 herein have been notified to ETSI, with an undertaking from the 6286 owner to grant licenses according to the terms and conditions of 6287 Article 6.1 of Annex 6 of the ETSI Rules of the ETSI IPR Policy. 6289 The ETSI IPR database provides data that is based on the information 6290 received. ETSI has not checked the validity of the information, nor 6291 the relevance of the identified patents/patent applications to the 6292 ETSI Standards and cannot confirm, or deny, that the patents/patent 6293 applications are, in fact, essential, or potentially essential. No 6294 investigation, or IPR searches, have been carried out by ETSI and 6295 therefore no guarantee can be given concerning the existence of 6296 other IPRs which are, or may become, essential. 6298 Potential Licensees should use the information in this database at 6299 their discretion and should contact the patent holder.