idnits 2.17.1 draft-pinkas-smime-cades-01.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 6252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6265. ** 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 (August 2005) is 6828 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 3798, 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 (~~), 4 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 February 2006 D.Pinkas(Bull) 4 Obsoletes: RFC 3126 August 2005 5 Target Category: Informational 7 CMS Advanced Electronic Signatures (CAdES) 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 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 The present document recommends the use of GeneralizedTime. 1694 5.9.2 Countersignature 1696 The counterSignature attribute values for ES have ASN.1 type 1697 CounterSignature as defined in CMS (RFC 3852 [4]). 1699 A counterSignature attribute shall be an unsigned attribute. 1701 5.10 ESS imported optional attributes 1703 The following attributes MAY be present with the signed-data defined by 1704 the present document. The attributes are defined in ESS and are 1705 imported into the present document and were appropriate qualified and 1706 profiled by the present document. 1708 5.10.1 Content reference attribute 1710 The content-reference attribute is a link from one SignedData to 1711 another. It may be used to link a reply to the original message to 1712 which it refers, or to incorporate by reference one SignedData into 1713 another. The content-reference attribute shall be a signed attribute. 1715 Content-reference attribute values for ES have ASN.1 type 1716 ContentReference as defined in ESS (RFC 2634 [5]). 1718 The content-reference attribute shall be used as defined in ESS (RFC 1719 2634 [5]) and further qualified in the present document. 1721 5.10.2 Content identifier attribute 1723 The content-identifier attribute provides an identifier for the signed 1724 content for use when reference may be later required to that content, 1725 for example in the content reference attribute in other signed data 1726 sent later. The content-identifier shall be a signed attribute. 1728 content-identifier attribute type values for of the ES have ASN.1 type 1729 ContentIdentifier as defined in ESS (RFC 2634 [5]). 1731 The minimal content-identifier attribute should contain a concatenation 1732 of user-specific identification information (such as a user name or 1733 public keying material identification information), a GeneralizedTime 1734 string, and a random number. 1736 5.10.3 Content hints attribute 1738 The content-hints attribute provides information that describes the 1739 format of the signed content. It may be used by the signer to indicate 1740 to a verifier a precise presentation format of the signed data (e.g. 1741 text, voice, and video). This attribute SHOULD be present when the 1742 signed data is to be presented to human users on verification if the 1743 presentation format is not implicit within the data that has been 1744 signed. 1746 The syntax of the content-hints attribute type of the ES as defined in 1747 ESS (RFC 2634 [5]). 1749 When used to indicate the precise format of the data to be presented to 1750 the user the following rules apply: 1752 - the contentType indicates the type of the associated content. It 1753 is an object identifier (i.e. a unique string of integers) 1754 assigned by an authority that defines the content type; 1756 - when the contentType is id-data the contentDescription shall 1757 define the presentation format, the format may be defined by MIME 1758 types. 1760 When the format of the content is defined by MIME types the following 1761 rules apply: 1763 - the contentType shall be id-data as defined in CMS (RFC 3852 1764 [4]); 1766 - the contentDescription shall be used to indicate the encoding of 1767 the data in accordance with the rules defined RFC 2045 [6], see 1768 annex F for an example structured contents and MIME. 1770 NOTE 1: id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1771 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1773 NOTE 2: contentDescription is optional in ESS (RFC 2634 [5]). It may 1774 be used to complement contentTypes defined elsewhere , such 1775 definitions are outside the scope of the present document. 1777 5.11 Additional optional attributes defined in the present document 1779 This clause defines a number of attributes that may be used to meet 1780 specific requirements. 1782 5.11.1 Commitment type indication attribute 1784 There may be situations where a signer wants to explicitly indicate to 1785 a verifier that by signing the data, it illustrates a type of 1786 commitment on behalf of the signer. The commitment-type-indication 1787 attribute conveys such information. 1789 The commitment-type-indication attribute shall be a signed attribute. 1790 The commitment type may be: 1792 - defined as part of the signature policy, in which case the 1793 commitment type has precise semantics that is defined as part of 1794 the signature policy; 1796 - be a registered type, in which case the commitment type has 1797 precise semantics defined by registration, under the rules of the 1798 registration authority. Such a registration authority may be a 1799 trading association or a legislative authority. 1801 The signature policy specifies a set of attributes that it 1802 "recognizes". This "recognized" set includes all those commitment 1803 types defined as part of the signature policy as well as any externally 1804 defined commitment types that the policy may choose to recognize. Only 1805 recognized commitment types are allowed in this field. 1807 The following object identifier identifies the commitment-type- 1808 indication attribute: 1810 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1811 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 1813 commitment-type-indication attribute values have ASN.1 type 1814 CommitmentTypeIndication. 1816 CommitmentTypeIndication ::= SEQUENCE { 1817 commitmentTypeId CommitmentTypeIdentifier, 1818 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 1819 CommitmentTypeQualifier OPTIONAL} 1821 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 1823 CommitmentTypeQualifier ::= SEQUENCE { 1824 commitmentTypeIdentifier CommitmentTypeIdentifier, 1825 qualifier ANY DEFINED BY commitmentTypeIdentifier } 1827 The use of any qualifiers to the commitment type is outside the scope 1828 of the present document. 1830 The following generic commitment types are defined in the present 1831 document: 1833 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1834 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 1836 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1837 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 1839 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 1840 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} 1842 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1843 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 1845 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 1846 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} 1848 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 1849 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} 1850 These generic commitment types have the following meaning: 1852 Proof of origin indicates that the signer recognizes to have created, 1853 approved and sent the message. 1855 Proof of receipt indicates that signer recognizes to have received the 1856 content of the message. 1858 Proof of delivery indicates that the TSP providing that indication has 1859 delivered a message in a local store accessible to the recipient of the 1860 message. 1862 Proof of sender indicates that the entity providing that indication has 1863 sent the message (but not necessarily created it). 1865 Proof of approval indicates that the signer has approved the content of 1866 the message. 1868 Proof of creation indicates that the signer has created the message 1869 (but not necessarily approved, nor sent it). 1871 5.11.2 Signer location attribute 1873 The signer-location attribute specifies a mnemonic for an address 1874 associated with the signer at a particular geographical (e.g. city) 1875 location. The mnemonic is registered in the country in which the 1876 signer is located and is used in the provision of the Public Telegram 1877 Service (according to ITU-T Recommendation F.1 [11]). 1879 The signer-location attribute shall be a signed attribute. 1880 The following object identifier identifies the signer-location 1881 attribute: 1883 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1884 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 1886 Signer-location attribute values have ASN.1 type SignerLocation: 1887 SignerLocation ::= SEQUENCE { -- at least one of the following shall be 1888 present 1890 countryName [0] DirectoryString OPTIONAL, 1891 -- As used to name a Country in X.500 1892 localityName [1] DirectoryString OPTIONAL, 1893 -- As used to name a locality in X.500 1894 postalAdddress [2] PostalAddress OPTIONAL } 1896 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 1897 5.11.3 Signer attributes attribute 1899 The signer-attributes attribute specifies additional attributes of the 1900 signer (e.g. role). 1902 It may be either: 1904 - claimed attributes of the signer; 1906 - certified attributes of the signer. 1908 The signer-attributes attribute shall be a signed attribute. 1909 The following object identifier identifies the signer-attribute 1910 attribute: 1912 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1913 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 1915 signer-attributes values have ASN.1 type SignerAttribute: 1916 SignerAttribute ::= SEQUENCE OF CHOICE { 1917 ClaimedAttributes [0] ClaimedAttributes, 1918 certifiedAttributes [1] CertifiedAttributes } 1920 ClaimedAttributes ::= SEQUENCE OF Attribute 1922 CertifiedAttributes ::= AttributeCertificate 1923 -- as defined in RFC 3281 : see clause 4.1. 1925 NOTE 1: Only a single signer-attributes can be used 1927 NOTE 2: The claimedAttributes and certifiedAttributes fields are as 1928 defined in ITU-T Recommendations X.501 [9] and X.509 [1]. 1930 5.11.4 Content time-stamp 1932 The content-time-stamp attribute is an attribute which is the time- 1933 stamp token of the signed data content before it is signed. 1934 The content-time-stamp attribute shall be a signed attribute. 1936 The following object identifier identifies the content-time-stamp 1937 attribute: 1939 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 1940 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} 1942 Content-time-stamp attribute values have ASN.1 type ContentTimestamp: 1943 ContentTimestamp::= TimeStampToken 1944 The value of messageImprint of TimeStampToken (as described in RFC 3161 1945 [7]) shall be a hash of the value of eContent field within 1946 encapContentInfo in the signedData. 1948 For further information and definition of TimeStampToken see 1949 clause 7.4. 1951 NOTE: Content-time-stamp indicates that the signed information was 1952 formed before the date included in the Content-time-stamp. 1954 5.12 Support for multiple signatures 1956 5.12.1 Independent signatures 1958 Multiple independent signatures (see clause B.5) are supported by 1959 independent SignerInfo from each signer. 1961 Each SignerInfo shall include all the attributes required under the 1962 present document and shall be processed independently by the verifier. 1964 5.12.2 Embedded signatures 1966 Multiple embedded signatures (see clause C.5) are supported using the 1967 countersignature unsigned attribute (see clause 7.1). Each counter 1968 signature is carried in Countersignature held as an unsigned attribute 1969 to the SignerInfo to which the counter-signature is applied. 1971 6 Additional Electronic Signature validation attributes 1973 This clause specifies attributes that contain different types of 1974 validation data. These attributes build on the electronic signature 1975 specified in clause 5. This includes: 1977 - Signature-time-stamp applied to the electronic signature value or 1978 a Time-Mark in an audit trail. This is defined as the Electronic 1979 Signature with Time (CAdES-T); 1981 - complete validation data references which comprises the time- 1982 stamp of the signature value (CAdES-T), plus references to all 1983 the certificates (complete-certificate-references) and revocation 1984 (complete-revocation-references) information used for full 1985 validation of the electronic signature. This is defined as the 1986 Electronic Signature with Complete data references (CAdES-C). 1988 NOTE 1: Formats for CAdES-T are illustrated in clause 4.4 and the 1989 attribute are defined in clause 6.1.1. 1991 NOTE 2: Formats for CAdES-C are illustrated in clause 4.4. The 1992 required attributes for the CAdES-C signature format are 1993 defined in clause 6.2.1 to 6.2.2, optional attributes are 1994 defined in clauses 6.2.3 and 6.2.4. 1996 In addition the following optional eXtended forms of validation data 1997 are also defined, see annex B for an overview the eXtended forms of 1998 validation data: 2000 - CAdES-X with time stamp: there are two types of time-stamp used 2001 in extended validation data defined by the present document: 2003 - Type 1(CAdES-X Type 1): comprises a time-stamp over the ES 2004 with complete validation data (CAdES-C); 2006 - Type 2 (CAdES-X Type2): comprises a time-stamp over the 2007 certification path references and the revocation information 2008 references used to support the CAdES-C. 2010 NOTE 3: Formats for CAdES-X Type 1 and CAdES-X Type 2 are illustrated 2011 in clauses B.1.2 and B.1.3 respectively. 2013 - CAdES-X Long :comprises the complete validation data references 2014 (CAdES-C) plus the actual values of all the certificates and 2015 revocation information used in the CAdES-C. 2017 NOTE 4: Formats for CAdES-X Long are illustrated in clause B.1.1. 2019 - CAdES-X Long Type 1 or CAdES-X Long Type 2: comprises an X-Time- 2020 Stamp (Type 1 or Type 2) plus the actual values of all the 2021 certificates and revocation information used in the CAdES-C as 2022 per CAdES-X Long. 2024 This clause also specifies the data structures used in Archive 2025 validation data format (CAdES-A)of eXtended forms: 2027 - Archive form of electronic signature (CAdES-A) comprises the 2028 complete validation data references (CAdES-C), the certificate 2029 and revocation values (as in a CAdES-X Long ), if present any 2030 existing extended electronic signature timestamps (CAdES-X Type 1 2031 or CAdES-X Type 2), plus the signed user data and an additional 2032 archive time-stamp applied over all that data. An archive time- 2033 stamp may be repeatedly applied after long periods to maintain 2034 validity when electronic signature and time-stamping algorithms 2035 weaken. 2037 The additional data required to create the forms of electronic 2038 signature identified above is carried as unsigned attributes associated 2039 with an individual signature by being placed in the unsignedAttrs field 2040 of SignerInfo . Thus all the attributes defined in clause 6 are 2041 unsigned attributes. 2043 NOTE 5: Where multiple signatures are to be supported, as described 2044 in clause 5.12, each signature has a separate SignerInfo. 2045 Thus, each signature requires its own unsigned attribute 2046 values to create CAdES-T, CAdES-C, etc. 2048 NOTE 6: the optional attributes of the extended validation data are 2049 defined in clauses 6.3 and 6.4. 2051 6.1 Electronic Signature Time-stamped (CAdES-T) 2053 An Electronic Signature with time-stamp is an electronic signature for 2054 which part, but not all, of the additional data required for validation 2055 is available (i.e. some certificates and revocation information are 2056 available but not all). 2058 The minimum structure time-stamp validation data is: 2060 - the Signature Time-stamp Attribute as defined in clause 6.1.1 2061 over the ES signature value. 2063 6.1.1 Signature time- stamp attribute definition 2065 The signature-time-stamp attribute is a TimeStampToken computed on the 2066 signature value for a specific signer. It is an unsigned attribute. 2067 Several instances of this attribute may occur with an electronic 2068 signature, from different TSAs. 2070 The following object identifier identifies the signature-time-stamp 2071 attribute: 2073 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member- 2074 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} 2076 The signature-time-stamp attribute value has ASN.1 type 2077 SignatureTimeStampToken: 2078 SignatureTimeStampToken ::= TimeStampToken 2080 The value of messageImprint field within TimeStampToken shall be a hash 2081 of the value of the signature field within SignerInfo for the 2082 signedData being time-stamped. 2084 For further information and definition of TimeStampToken see 2085 clause 7.4. 2087 NOTE 1: In the case of multiple signatures it is possible to have a 2088 TimeStampToken computed for each and all signers, or 2089 TimeStampToken computed on one signer's signature and no 2090 TimeStampToken on another signer's signature. 2092 NOTE 2: In the case of multiple signatures, several TSTs , issued by 2093 different TSAs, may be present within the same signerInfo (see 2094 RFC 3852 [4]). 2096 6.2 Complete validation reference data (CAdES-C) 2098 An electronic signature with complete validation data references 2099 (CAdES-C) is an Electronic Signature for which all the additional data 2100 required for validation (i.e. all certificates and revocation 2101 information) is available. This form is built on the CAdES-T form 2102 defined above. 2104 As a minimum the complete validation data shall include the following: 2106 - a time, which shall either be a signature-timestamp attribute, as 2107 defined in clause 6.1.1, or a time mark operated by a Time- 2108 Marking Authority; 2110 - complete-certificate-references, as defined in clause 6.2.1; 2112 - complete-revocation-references , as defined in clause 6.2.2. 2114 6.2.1 Complete certificate references attribute definition 2116 The complete-certificate-references attribute is an unsigned attribute. 2117 It references the full set of CA certificates that have been used to 2118 validate an ES with Complete validation data up to (but not including) 2119 the signer's certificate. Only a single instance of this attribute 2120 shall occur with an electronic signature. 2122 NOTE 1: The signer's certificate is referenced in the signing 2123 certificate attribute (see clause 5.7.3). 2125 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2126 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 2128 The complete-certificate-references attribute value has the ASN.1 2129 syntax CompleteCertificateRefs. 2131 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 2133 OtherCertID is defined in clause 5.7.3.2. 2135 The IssuerSerial that shall be present in OtherCertID. The certHash 2136 shall match the hash of the certificate referenced. 2138 NOTE 2: Copies of the certificate values may be held using the 2139 certificate-values attribute defined in clause 6.3.3. 2141 This attribute MAY include references to the certification 2142 chain for any TSUs that provides time-stamp tokens. In this 2143 case the unsigned attribute shall be added to the signData of 2144 the relevant times tamp token as an unsignedAttrs in the 2145 signerInfos field. 2147 6.2.2 Complete Revocation References attribute definition 2149 The complete-revocation-references attribute is an unsigned attribute. 2150 Only a single instance of this attribute shall occur with an electronic 2151 signature. It references the full set of the CRL, ACRL or OCSP 2152 responses that have been used in the validation of the signer and CA 2153 certificates used in ES with Complete validation data. 2155 This attribute can be used to illustrate that the verifies has taken 2156 due diligence of the available revocation information and then to be 2157 able to retrieve that information when stored elsewhere. 2158 The following object identifier identifies the complete-revocation- 2159 references attribute: 2161 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2162 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 2164 The complete-revocation-references attribute value has the ASN.1 syntax 2165 CompleteRevocationRefs 2167 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 2169 CrlOcspRef ::= SEQUENCE { 2170 Crlids [0] CRLListID OPTIONAL, 2171 Ocspids [1] OcspListID OPTIONAL, 2172 OtherRev [2] OtherRevRefs OPTIONAL 2173 } 2175 CompleteRevocationRefs shall contain one CrlOcspRef for the signing- 2176 certificate, followed by one for each OtherCertID in the 2177 CompleteCertificateRefs attribute. The second and subsequent 2178 CrlOcspRef fields shall be in the same order as the OtherCertID to 2179 which they relate. At least one of CRLListID or OcspListID or 2180 OtherRevRefs should be present for all but the "trusted" CA of the 2181 certificate path. 2183 CRLListID ::= SEQUENCE { 2184 crls SEQUENCE OF CrlValidatedID} 2186 CrlValidatedID ::= SEQUENCE { 2187 crlHash OtherHash, 2188 crlIdentifier CrlIdentifier OPTIONAL} 2190 CrlIdentifier ::= SEQUENCE { 2191 crlissuer Name, 2192 crlIssuedTime UTCTime, 2193 crlNumber INTEGER OPTIONAL 2194 } 2196 OcspListID ::= SEQUENCE { 2197 ocspResponses SEQUENCE OF OcspResponsesID} 2199 OcspResponsesID ::= SEQUENCE { 2200 ocspIdentifier OcspIdentifier, 2201 ocspRepHash OtherHash OPTIONAL 2202 } 2204 OcspIdentifier ::= SEQUENCE { 2205 OcspResponderID ResponderID, -- As in OCSP response data 2206 ProducedAt GeneralizedTime -- As in OCSP response data 2207 } 2209 When creating a crlValidatedID, the crlHash is computed over the entire 2210 DER encoded CRL including the signature. The crlIdentifier would 2211 normally be present unless the CRL can be inferred from other 2212 information. 2214 The crlIdentifier is to identify the CRL using the issuer name and the 2215 CRL issued time, which shall correspond to the time thisUpdate 2216 contained in the issued CRL, and if present, the crlNumber. The 2217 crlListID attribute is an unsigned attribute. In the case that the 2218 identified CRL is a Delta CRL then references to the set of CRLs to 2219 provide a complete revocation list shall be included. 2221 The OcspIdentifier is to identify the OCSP response using the issuer 2222 name and the time of issue of the OCSP response which shall correspond 2223 to the time producedAt contained in the issued OCSP response. Since it 2224 may be needed to make the difference between two OCSP responses 2225 received within the same second, then the hash of the response 2226 contained in the OcspResponsesID may be needed to solve the ambiguity. 2228 NOTE: Copies of the CRL and OCSP responses values may be held using 2229 the revocation-values attribute defined in clause 6.3.4. 2231 OtherRevRefs ::= SEQUENCE { 2232 OtherRevRefType OtherRevRefType, 2233 OtherRevRefs ANY DEFINED BY otherRevRefType 2234 } 2236 OtherRevRefType ::= OBJECT IDENTIFIER 2237 The syntax and semantics of other revocation references is outside the 2238 scope of the present document. The definition of the syntax of the 2239 other form of revocation information is as identified by 2240 OtherRevRefType. 2241 This attribute MAY include the references to the full set of the CRL, 2242 ACRL or OCSP responses that have been used to verify the certification 2243 chain for any TSUs that provides time-stamp tokens. In this case the 2244 unsigned attribute shall be added to the signData of the relevant 2245 timestamp token as an unsignedAttrs in the signerInfos field. 2247 6.2.3 Attribute certificate references attribute definition 2249 This attribute is only used when an user attribute certificate is 2250 present in the electronic signature. 2252 The attribute-certificate-references attribute is an unsigned 2253 attribute. It references the full set of AA certificates that have 2254 been used to validate the attribute certificate. Only a single 2255 instance of this attribute shall occur with an electronic signature. 2257 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) member- 2258 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 44} 2260 The attribute-certificate-references attribute value has the ASN.1 2261 syntax AttributeCertificateRefs. 2263 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 2265 OtherCertID is defined in clause 5.8.2. 2267 NOTE: Copies of the certificate values may be held using the 2268 certificate-values attribute defined in clause 6.3.3. 2270 6.2.4 Attribute revocation references attribute definition 2272 This attribute is only used when a user attribute certificate is 2273 present in the electronic signature and when that attribute certificate 2274 can be revoked. 2276 The attribute-revocation-references attribute is an unsigned attribute. 2277 Only a single instance of this attribute shall occur with an electronic 2278 signature. It references the full set of the ACRL or OCSP responses 2279 that have been used in the validation of the attribute certificate. 2280 This attribute can be used to illustrate that the verifier has taken 2281 due diligence of the available revocation information. 2283 The following object identifier identifies the attribute-revocation- 2284 references attribute: 2286 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) member- 2287 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 45} 2289 The attribute-revocation-references attribute value has the ASN.1 2290 syntax AttributeRevocationRefs. 2291 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 2293 6.3 Extended validation data (CAdES-X) 2295 This clause specifies a number of optional attributes that are used by 2296 extended forms of electronic signatures (see annex B for an overview 2297 these forms of validation data). 2299 6.3.1 Time-stamped validation data (CAdES-X Type 1 or Type 2) 2301 The extended validation data MAY include one of the following 2302 additional attributes, forming a CAdES-X Time-Stamp validation data 2303 (CAdES-X Type 1 or CAdES-X Type 2), to provide additional protection 2304 against later CA compromise and provide integrity of the validation 2305 data used: 2307 - CAdES-C Time-stamp, as defined in clause 6.3.5 (CAdES-X Type 1); 2308 or 2310 - Time-Stamped Certificates and CRLs references, as defined in 2311 clause 6.3.6 (CAdES-X Type 2). 2313 6.3.2 Long validation data (CAdES-X Long, CAdES-X Long Type 1 or 2) 2315 The extended validation data MAY also include the following additional 2316 information, forming a CAdES-X Long, for use if later validation 2317 processes may not have access to this information: 2319 - certificate-values as defined in clause 6.3.3; 2320 - revocation-values as defined in clause 6.3.4. 2322 The extended validation data MAY in addition to certificate-values and 2323 revocation-values as defined in clauses 6.3.3 and 6.3.4 include one of 2324 the following additional attributes, forming an CAdES-X Long Type 1 or 2325 CAdES-X Long Type 2. 2327 - CAdES-C Time-stamp, as defined in clause 6.3.3 (CAdES-X long Type 2328 1); or 2330 - Time-Stamped Certificates and CRLs references, as defined in 2331 clause 6.3.4 (CAdES-X Long Type 2). 2333 The CAdES-X Long Type 1 or CAdES-X Long Type 2 provide additional 2334 protection against later CA compromise and provide integrity of the 2335 validation data used. 2337 NOTE 1: The CAdES-X Long provides long term proof of a valid 2338 electronic signature as long as the CAs are trusted such that 2339 these keys cannot be compromised or the cryptography used 2340 broken. 2341 NOTE 2: As long as the time stamp data remains valid, the CAdES-X 2342 Long Type 1 and the CAdES-X Long Type 2 provides the following 2343 important property for long standing signatures; that having 2344 been found once to be valid, it shall continue to be so months 2345 or years later, long after the validity period of the 2346 certificates have expired, or after the user key has been 2347 compromised. 2349 6.3.3 Certificate values attribute definition 2351 This attribute MAY be used to contain the certificate information 2352 required for the following forms of eXtended Electronic Signature: 2353 CAdES-X Long , ES X-Long Type 1 and CAdES-X Long Type 2, see clause 2354 B.1.1 for an illustration of this form of electronic signature. 2356 The certificate-values attribute is an unsigned attribute. Only a 2357 single instance of this attribute shall occur with an electronic 2358 signature. It holds the values of certificates referenced in the 2359 complete-certificate-references attribute. 2361 NOTE: If an attribute certificate is used, it is not provided in this 2362 structure but shall be provided by the signer as a signer- 2363 attributes attribute (see clause 5.11.3). 2365 The following object identifier identifies the certificate-values 2366 attribute: 2368 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2369 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 2371 The certificate-values attribute value has the ASN.1 syntax 2372 CertificateValues 2374 CertificateValues ::= SEQUENCE OF Certificate 2376 Certificate is defined in clause 7.1 (which is as defined in ITU-T 2377 Recommendation X.509 [1]). 2379 This attribute MAY include the certification information for any TSUs 2380 that have provided the time-stamp tokens if these certificates are not 2381 already included in the TSTs as part of the TSUs signatures. In this 2382 case the unsigned attribute shall be added to the signData of the 2383 relevant timestamp token. 2385 6.3.4 Revocation values attribute definition 2387 This attribute is used to contain the revocation information required 2388 for the following forms of eXtended Electronic Signature: CAdES-X Long, 2389 ES X-Long Type 1 and CAdES-X Long Type 2, see clause B.1.1 for an 2390 illustration of this form of electronic signature. 2392 The revocation-values attribute is an unsigned attribute. Only a 2393 single instance of this attribute shall occur with an electronic 2394 signature. It holds the values of CRLs and OCSP referenced in the 2395 complete-revocation-references attribute. 2397 The following object identifier identifies the revocation-values 2398 attribute: 2400 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 2401 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2402 smime(16) id-aa(2) 24} 2404 The revocation-values attribute value has the ASN.1 syntax 2405 RevocationValues 2407 RevocationValues ::= SEQUENCE { 2408 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 2409 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 2410 otherRevVals [2] OtherRevVals OPTIONAL} 2412 OtherRevVals ::= SEQUENCE { 2413 OtherRevValType OtherRevValType, 2414 OtherRevVals ANY DEFINED BY OtherRevValType 2415 } 2417 OtherRevValType ::= OBJECT IDENTIFIER 2419 The syntax and semantics of the other revocation values (OtherRevVals) 2420 is outside the scope of the present document. The definition of the 2421 syntax of the other form of revocation information is as identified by 2422 OtherRevRefType. 2424 CertificateList is defined in clause 7.2 (which as defined in ITU-T 2425 Recommendation X.509 [1]). 2427 BasicOCSPResponse is defined in clause 7.3 (which as defined in RFC 2428 2560 [3]). 2430 This attribute MAY include the values of revocation data including CRLs 2431 and OCSP for any TSUs that have provided the time-stamp tokens if these 2432 certificates are not already included in the TSTs as part of the TSUs 2433 signatures. In this case the unsigned attribute shall be added to the 2434 signData of the relevant timestamp token. 2436 6.3.5 CAdES-C time-stamp attribute definition 2438 This attribute is used to protect against CA key compromise. 2439 This attribute is used for the time stamping the complete electronic 2440 signature (CAdES-C). It is used in the following forms of eXtended 2441 Electronic Signature; CAdES-X Type 1 and CAdES-X Long Type 1, see 2442 clause B.1.2 for an illustration of this form of electronic signature. 2444 The CAdES-C-timestamp attribute is an unsigned attribute. It is a 2445 time-stamp token of the hash of the electronic signature and the 2446 complete validation data (CAdES-C). It is a special purpose 2447 TimeStampToken Attribute which time-stamps the CAdES-C. Several 2448 instances of this attribute may occur with an electronic signature from 2449 different TSAs. 2451 The following object identifier identifies the CAdES-C-Timestamp 2452 attribute: 2454 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2455 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 2457 The CAdES-C-timestamp attribute value has the ASN.1 syntax 2458 ESCTimeStampToken. 2460 ESCTimeStampToken ::= TimeStampToken 2462 The value of messageImprint field within TimeStampToken shall be a hash 2463 of the concatenated values (without the type or length encoding for 2464 that value) of the following data objects: 2466 - OCTETSTRING of the SignatureValue field within SignerInfo; 2468 - signature-time-stamp; or a time mark operated by a Time-Marking 2469 Authority; 2471 - complete-certificate-references s attribute; 2473 - complete-revocation-references attribute. 2475 For further information and definition of the TimeStampToken see 2476 clause 7.4. 2478 6.3.6 Time-stamped certificates and crls references attribute 2479 definition 2481 This attribute is used to protect against CA key compromise. 2483 This attribute is used for the time stamping certificate and revocation 2484 references. It is used in the following forms of eXtended Electronic 2485 Signature; CAdES-X Type 2 and CAdES-X Long Type 2, see clause B.1.3 for 2486 an illustration of this form of electronic signature. 2488 A time-stamped-certs-crls-references attribute is an unsigned 2489 attribute. It is a time-stamp token issued for a list of referenced 2490 certificates and OCSP responses/CRLs to protect against certain CA 2491 compromises. Its syntax is as follows: 2493 The following object identifier identifies the time-stamped-certs-crls- 2494 references attribute: 2496 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member 2497 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} 2498 The attribute value has the ASN.1 syntax TimestampedCertsCRLs. 2500 TimestampedCertsCRLs ::= TimeStampToken 2502 The value of messageImprint field within TimeStampToken shall be a hash 2503 of the concatenated values (without the type or length encoding for 2504 that value) of the following data objects as present in the ES with 2505 Complete validation data: 2507 - complete-certificate-references attribute; 2508 - complete-revocation-references attribute. 2510 6.4 Archive validation data 2512 Where an electronic signature is required to last for a very long time, 2513 and a the time-stamp token on an electronic signature is in danger of 2514 being invalidated due to algorithm weakness or limits in the validity 2515 period of the TSA certificate, then it may be required to time-stamp 2516 the electronic signature several times. When this is required an 2517 archive time-stamp attribute may be required for the archive form of 2518 electronic signature (CAdES-A). This archive time-stamp attribute may 2519 be repeatedly applied over a period of time. 2521 6.4.1 Archive time-stamp attribute definition 2523 The archive-time-stamp attribute is a time-stamp token of many of the 2524 elements of the signedData in the electronic signature. If the 2525 certificate-values and revocation-values attributes are not present in 2526 the CAdES-BES or CAdES-EPES, then they shall be added to the electronic 2527 signature prior to computing the archive time-stamp token. The 2528 archive-time-stamp attribute is an unsigned attribute. Several 2529 instances of this attribute may occur with an electronic signature both 2530 over time and from different TSUs. 2532 The following object identifier identifies the nested archive-time- 2533 stamp attribute: 2535 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2536 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27} 2537 Archive-time-stamp attribute values have the ASN.1 syntax 2538 ArchiveTimeStampToken 2540 ArchiveTimeStampToken ::= TimeStampToken 2542 The value of messageImprint field within TimeStampToken shall be a hash 2543 of the concatenation of: 2545 - The encapContentInfo element of the SignedData sequence; 2547 - When present, the Certificates and crls elements of the 2548 SignedData sequence; 2550 - Together with all data elements in the SignerInfo sequence 2551 including all signed and unsigned attributes. 2553 NOTE 1: The SignedData definition is the following: 2555 SignedData ::= SEQUENCE { 2556 version CMSVersion, 2557 digestAlgorithms DigestAlgorithmIdentifiers, 2558 encapContentInfo EncapsulatedContentInfo, 2559 certificates [0] IMPLICIT CertificateSet OPTIONAL, 2560 crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, 2561 signerInfos SignerInfos } 2563 NOTE 2: SignerInfo definition is as follows: 2565 SignerInfo ::= SEQUENCE { 2566 version CMSVersion, 2567 sid SignerIdentifier, 2568 digestAlgorithm DigestAlgorithmIdentifier, 2569 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 2570 signatureAlgorithm SignatureAlgorithmIdentifier, 2571 signature SignatureValue, 2572 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 2574 Further information and definition of TimeStampToken see clause 7.4. 2575 The timestamp should be created using stronger algorithms (or longer 2576 key lengths) than in the original electronic signatures and weak 2577 algorithm (key length) timestamps. 2579 NOTE 3: This form of ES also provides protection against a TSP key 2580 Compromise. 2582 The ArchiveTimeStamp will be added as an unsigned attribute in the 2583 SignerInfo sequence. For the validation of one ArchiveTimeStamp the 2584 data elements of the SignerInfo must be concatenated excluding all 2585 later ArchivTimeStampToken attributes. 2587 Certificates and revocation information required to validate the 2588 ArchiveTimeStampshall be provided by one of the following methods: 2590 - The TSU provides the information in the SignedData of the 2591 timestamp token; 2593 - Adding the complete-certificate-references attribute and the 2594 complete-revocation-references attribute of the TSP as an 2595 unsigned attribute within TimeStampToken, when the required 2596 information is store elsewhere; 2598 - Adding the certificate-values attribute and the revocation-values 2599 attribute of the TSP as an unsigned attribute within 2600 TimeStampToken, when the required information is store elsewhere. 2602 7 Other standard data structures 2604 7.1 Public-key certificate format 2606 The X.509 v3 certificate basis syntax is defined in ITU-T 2607 Recommendation X.509 [1]. A profile of the X.509 v3 certificate is 2608 defined in RFC 3280 [2], which is being revised. The reader should 2609 consult the latest version of this RFC or any RFC that makes it 2610 obsolete. 2612 7.2 Certificate revocation list format 2614 The X.509 v2 CRL syntax is defined in ITU-T Recommendation X.509 [1]. 2615 A profile of the X.509 v2 CRL is defined in RFC 3280 [2], which is 2616 being revised. 2618 7.3 OCSP response format 2620 The format of an OCSP token is defined in RFC 2560 [3]. 2622 7.4 Time-stamp token format 2624 The format of a TimeStampToken type is defined in RFC 3161 [7] and TS 2625 101 861 (see informative references). 2627 7.5 Name and attribute formats 2629 The syntax of the naming and other attributes is defined in ITU-T 2630 Recommendation X.509 [1]. 2632 The name used by the signer, held as the subject in the signer's 2633 certificate, shall be allocated and verified on registration with the 2634 Certification Authority, either directly or indirectly through a 2635 Registration Authority, before being issued with a Certificate. 2637 The present document places no restrictions on the form of the name. 2638 The subject's name may be a distinguished name, as defined in ITU-T 2639 Recommendation X.500 [12], held in the subject field of the 2640 certificate, or any other name form held in the subjectAltName 2641 certificate extension field as defined in ITU-T Recommendation X.509 2642 [1]. In the case that the subject has no distinguished name, the 2643 subject name can be an empty sequence and the subjectAltName extension 2644 shall be critical. 2646 All TSP name forms (Certification Authorities, Attribute Authorities 2647 and Time Stamping Authorities) shall be in the form of a distinguished 2648 name held in the subject field of the certificate. 2650 The TSP name form shall include identifiers for the organization 2651 providing the service and the legal jurisdiction (e.g. country) under 2652 which it operates. 2654 Where a signer signs as an individual but wishes to also identify 2655 him/herself as acting on behalf of an organization, it may be necessary 2656 to provide two independent forms of identification. The first 2657 identity, with is directly associated with the signing key identifies 2658 him/her as an individual. The second, which is managed independently, 2659 identifies that person acting as part of the organization, possibly 2660 with a given role. 2662 In this case one of the two identities is carried in the 2663 subject/subjectAltName field of the signer's certificate as described 2664 above. 2666 The present document does not specify the format of signer's attribute 2667 that may be included in public key certificates. 2669 NOTE : Signer's attribute may be supported by using a claimed role in 2670 the CMS signed attributes field or by placing an attribute 2671 certificate containing a certified role in the CMS signed 2672 attributes field, see clause 7.6. 2674 7.6 Attribute certificate 2676 The syntax of the AttributeCertificate type is defined in RFC 3281 [13]. 2678 8. Conformance requirements 2680 The present document defines conformance requirements for the 2681 generation of two forms of basic electronic signature, one of the two 2682 forms must be implemented. 2684 The present document defines conformance requirements for the 2685 verification of two forms of basic electronic signature, one of the two 2686 forms must be implemented. 2688 The present document only defines conformance requirements up to an ES 2689 with Complete validation data (CAdES-C). This means that none of the 2690 extended and archive forms of Electronic Signature (CAdES-X, CAdES-A) 2691 need to be implemented to get conformance to the present document. 2693 On verification the inclusion of optional signed and unsigned 2694 attributes must be supported only to the extended that the signature is 2695 verifiable. The semantics of optional attributes may be unsupported, 2696 unless specified otherwise by a signature policy. 2698 8.1 CAdES-Basic Electronic Signature (CAdES-BES) 2700 A system supporting CAdES-BES signers according to the present document 2701 shall, at a minimum, support generation of an electronic signature 2702 consisting of the following components: 2704 - The general CMS syntax and content type as defined in RFC 3852 2705 [4] (see clauses 5.1 and 5.2); 2707 - CMS SignedData as defined in RFC 3852 [4] with version set to 3 2708 and at least one SignerInfo shall be present (see clauses 5.3 to 2709 5.6); 2711 - The following CMS attributes as defined in RFC 3852 [4]: 2713 - content-type; this shall always be present (see clause 5.7.1); 2715 - message-digest; this shall always be present (see 2716 clause 5.7.2). 2718 - One of following attributes as defined in the present document: 2720 - signing-certificate: as defined in clause 5.7.3.1; 2721 - Other-Signing-Certificate as defined in clause 5.7.3.2. 2723 8.2 CAdES-Explicit Policy-based Electronic Signature 2725 A system supporting Policy-based signers according to the present 2726 document shall, at a minimum, support generation of an electronic 2727 signature consisting of the previous components defined for the basic 2728 signer, plus: 2730 - The following attributes as defined in clause 5.9: 2732 - signature-policy-identifier; this shall always be present (see 2733 clause 5.8.1). 2735 8.3 Verification using time-stamping 2737 A system supporting verifiers according to the present document with 2738 time-stamping facilities shall, at a minimum, support: 2740 - verification of the mandated components of an electronic 2741 signature, as defined in clause 8.1. 2743 - signature-time-stamp attribute, as defined in clause 6.1.1. 2745 - complete-certificate-references, attribute as defined in 2746 clause 6.2.1. 2748 - complete-revocation-references attribute, as defined in 2749 clause 6.2.2. 2751 - Public Key Certificates, as defined in ITU-T Recommendation X.509 2752 [1] (see clause 8.1). 2754 - either of: 2756 - Certificate Revocation Lists. as defined in ITU-T 2757 Recommendation X.509 [1] (see clause 8.2); or 2759 - on-line Certificate Status Protocol, as defined in RFC 2560 2760 [3] (see clause 8.3). 2762 8.4 Verification using secure records 2764 A system supporting verifiers according to the present document shall, 2765 at a minimum, support: 2767 - verification of the mandated components of an electronic 2768 signature, as defined in clause 8.1; 2770 - complete-certificate-references attribute, as defined in 2771 clause 6.2.1; 2773 - complete-revocation-references attribute, as defined in 2774 clause 6.2.2; 2776 - a record must be maintained and cannot be undetectable modified, 2777 of the electronic signature and the time when the signature was 2778 first validated using the referenced certificates and revocation 2779 information; 2781 - Public Key Certificates, as defined in ITU-T Recommendation X.509 2782 [1] (see clause 8.1); 2784 - either of: 2786 - Certificate Revocation Lists. as defined in ITU-T 2787 Recommendation X.509 [1] (see clause 8.2); or 2789 - on-line Certificate Status Protocol, as defined in RFC 2560 2790 [3] (see clause 8.3). 2792 9. Security considerations 2794 9.1 Protection of private key 2796 The security of the electronic signature mechanism defined in the 2797 present document depends on the privacy of the signer's private key. 2798 Implementations should take steps to ensure that private keys cannot be 2799 compromised. 2801 9.2 Choice of algorithms 2803 Implementers should be aware that cryptographic algorithms become 2804 weaker with time. As new cryptoanalysis techniques are developed and 2805 computing performance improves, the work factor to break a particular 2806 cryptographic algorithm will reduce. Therefore, cryptographic 2807 algorithm implementations should be modular allowing new algorithms to 2808 be readily inserted. That is, implementers should be prepared for the 2809 set of mandatory to implement algorithms to change over time. 2811 10. IANA Considerations 2813 Not applicable 2815 11. References 2817 11.1 Normative references 2819 [1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001): 2820 "Information technology - Open Systems Interconnection - 2821 The Directory: Authentication framework". 2823 [2] IETF RFC 3280 (2002): "Internet X.509 Public Key 2824 Infrastructure Certificate and Certificate Revocation List 2825 (CRL) Profile". 2827 [3] IETF RFC 2560 (1999): "X.509 Internet Public Key 2828 Infrastructure Online Certificate Status Protocol - OCSP". 2830 [4] IETF RFC 3852 (2004): "Cryptographic Message Syntax (CMS)". 2832 [5] IETF RFC 2634 (1999): "Enhanced Security Services for 2833 S/MIME". 2835 [6] IETF RFC 2045 (1996): "Multipurpose Internet Mail Extensions 2836 (MIME) Part One: Format of Internet Message Bodies". 2838 [7] IETF RFC 3161 (2001): "Internet X.509 Public Key 2839 Infrastructure Time-Stamp Protocol (TSP)". 2841 [8] ITU-T Recommendation X.680 (1997): "Information technology - 2842 Abstract Syntax Notation One (ASN.1): Specification of basic 2843 notation". 2845 [9] ITU-T Recommendation X.501 (2000)/ISO/IEC 9594-1 (2001): 2846 "Information technology - Open Systems Interconnection - 2847 Directory models ". 2849 [10] IETF RFC 3370 (2002): "Cryptographic Message Syntax (CMS) 2850 Algorithms". 2852 [11] ITU-T Recommendation F.1: "Operational provisions for the 2853 international public telegram service". 2855 [12] ITU-T Recommendation X.500: "Information technology - Open 2856 Systems Interconnection - The Directory: Overview of 2857 concepts, models and services". 2859 [13] IETF RFC 3281 (2002): "An Internet Attribute Certificate 2860 Profile for Authorization". 2862 [14] ITU-T Recommendation X.208 (1988): "Specification of Abstract 2863 Syntax Notation One (ASN.1)". 2865 Referenced documents hereabove which are not found to be publicly 2866 available in the expected location might be found at 2867 http://docbox.etsi.org/Reference. 2869 [STDWORDS] IETF RFC 2119 Bradner, S., "Key words for use in RFCs to 2870 Indicate Requirement Levels", BCP 14, RFC 2 2872 11.2 Informative references 2874 Directive 1999/93/EC of the European Parliament and of the Council 2875 of 13 December 1999 on a Community framework for electronic 2876 signatures. 2878 ETSI Standard TS 101 733 V.1.6.3 (2005-06) Electronic Signature 2879 Formats. Note: copies of ETSI TS 101 733 can be freely downloaded 2880 from the ETSI web site www.etsi.org. 2882 IETF RFC 2246 (1999): "The TLS Protocol Version 1.0". 2884 IETF RFC 2437 (1998): "PKCS #1: RSA Cryptography Specifications 2885 Version 2.0". 2887 IETF RFC 2479 (1998): "Independent Data Unit Protection Generic 2888 Security Service Application Program Interface (IDUP-GSS-API)". 2890 IETF RFC 2510 (1999): "Internet X.509 Public Key Infrastructure 2891 Certificate Management Protocols". 2893 IETF RFC 2587 (1999): "Internet X.509 Public Key Infrastructure 2894 LDAPv2 Schema". 2896 IETF RFC 3125 (2000): "Electronic Signature Policies". 2898 IETF RFC 2559 (2003): "Internet X.509 Public Key Infrastructure 2899 Operational Protocols - LDAPv2". 2901 ETSI TS 101 861: "Time stamping profile". 2903 ETSI TS 101 903: "XML Advanced Electronic Signatures (XAdES)". 2905 ETSI TS 102 023: "Electronic Signatures and Infrastructures (ESI); 2906 Policy requirements for time-stamping authorities". 2908 ETSI TS 102 038: "Electronic Signatures and Infrastructures (ESI); 2909 XML format for signature policies". 2911 ETSI TR 102 272. "Electronic Signatures and Infrastructures (ESI); 2912 ASN.1 format for signature policies". 2914 ISO 7498-2 (1989): "Information processing systems - Open Systems 2915 Interconnection - Basic Reference Model - Part 2: Security 2916 Architecture". 2918 ISO/IEC 13888-1 (2004): "IT security techniques - Non-repudiation - 2919 Part 1: General". 2921 ISO/IEC 9796-2 (2002): "Information technology - Security techniques 2922 - Digital signature schemes giving message recovery - Part 2: 2923 Integer factorization based mechanisms". 2925 ISO/IEC 9796-4 (1998): "Digital signature schemes giving message 2926 recovery - Part 4: Discrete logarithm based mechanisms". 2928 ISO/IEC 10118-1 (2000): "Information technology - Security 2929 techniques - Hash-functions - Part 1: General". 2931 ISO/IEC 10118-2 (2000): "Information technology - Security 2932 techniques - Hash-functions - Part 2: Hash-functions using an n-bit 2933 block cipher algorithm". 2935 ISO/IEC 10118-3 (2004): "Information technology - Security 2936 techniques - Hash-functions - Part 3: Dedicated hash-functions". 2938 ISO/IEC 10118-4 (1998): "Information technology - Security 2939 techniques - Hash-functions - Part 4: Hash-functions using modular 2940 arithmetic". 2942 ISO/IEC 14888-1 (1998): "Information technology - Security 2943 techniques - Digital signatures with appendix - Part 1: General". 2945 ISO/IEC 14888-2 (1999): "Information technology - Security 2946 techniques - Digital signatures with appendix - Part 2: Identity- 2947 based mechanisms". 2949 ISO/IEC 14888-3 (1998): "Information technology - Security 2950 techniques - Digital signatures with appendix - Part 3: Certificate- 2951 based mechanisms". 2953 ISO/IEC 15946-2 (2002): "Information technology - Security 2954 techniques - Cryptographic techniques based on elliptic curves - 2955 Part 2: Digital signatures". 2957 ISO/IEC 15946-3 (2002): "Information technology - Security 2958 techniques - Cryptographic techniques based on elliptic curves - 2959 Part 3: Key establishment". 2961 ISO/IEC 10181-5: Security Frameworks in Open Systems. 2962 Non-Repudiation Framework. April 1997. 2964 ITU-T Recommendation X.690 (2002): "Specification of basic encoding 2965 rules for Abstract Syntax Notation One (ASN.1)". 2967 CWA 14171 CEN Workshop Agreements: "General Guidelines for 2968 Electronic Signature Verification". 2970 XMLDSIG: W3C/IETF Recommendation (February 2002): "XML-Signature 2971 Syntax and Processing". 2973 ANSI X9.30-1 (1997): "Public Key Cryptography for the Financial 2974 Services Industry - Part 1: The Digital Signature Algorithm (DSA)". 2976 ANSI X9.30-2 (1997): "Public Key Cryptography for the Financial 2977 Services Industry - Part 2: The Secure Hash Algorithm (SHA-1)". 2979 ANSI X9.31-1 (1997): "Public Key Cryptography Using Reversible 2980 Algorithms for the Financial Services Industry - 2981 Part 1: The RSA Signature Algorithm". 2983 ANSI X9.31-2 (1996): "Public Key Cryptography Using Reversible 2984 Algorithms for the Financial Services Industry - 2985 Part 2: Hash Algorithms". 2987 ANSI X9.62 (1998): "Public Key Cryptography for the Financial 2988 Services Industry - The Elliptic Curve Digital Signature Algorithm 2989 (ECDSA)". 2991 IEEE P1363 (2000): "Standard Specifications for Public-Key 2992 Cryptography". 2994 12. Authors' addresses 2996 Denis Pinkas 2997 Bull S.A. 2998 Rue Jean-Jaures 2999 78340 Les Clayes sous Bois CEDEX 3000 FRANCE 3002 EMail: Denis.Pinkas@bull.net 3004 Nick Pope 3005 Security & Standards 3006 192 Moulsham Street 3007 Chelmsford, Essex 3008 CM2 0LG 3009 United Kingdom 3011 EMail: pope@secstan.com 3013 John Ross 3014 Security & Standards 3015 192 Moulsham Street 3016 Chelmsford, Essex 3017 CM2 0LG 3018 United Kingdom 3020 EMail: ross@secstan.com 3022 This Informational RFC has been produced in ETSI TC-ESI. 3024 ETSI 3025 F-06921 Sophia Antipolis, Cedex - FRANCE 3026 650 Route des Lucioles - Sophia Antipolis 3027 Valbonne - France 3028 Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 3029 secretariat@etsi.fr 3030 http://www.etsi.org 3032 Annex A (normative): ASN.1 definitions 3034 This annex provides a summary of all the ASN.1 syntax definitions for 3035 new syntax defined in the present document. 3037 A.1 Signature format definitions using X.208 ASN.1 syntax 3039 NOTE: The ASN.1 module defined in clause A.1 using syntax defined in 3040 ITU-T Recommendation X.208 [14] has precedence over that 3041 defined in clause A.2 in the case of any conflict. 3043 ETS-ElectronicSignatureFormats-ExplicitSyntax88 { iso(1) member-body(2) 3044 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 3045 eSignature-explicit88(28)} 3047 DEFINITIONS EXPLICIT TAGS ::= 3049 BEGIN 3051 -- EXPORTS All 3053 IMPORTS 3055 -- Cryptographic Message Syntax (CMS): RFC 3852 3057 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3058 EncapsulatedContentInfo, SignerInfo, id-contentType, 3059 id-messageDigest, MessageDigest, id-signingTime, SigningTime, 3060 id-countersignature, Countersignature 3061 FROM CryptographicMessageSyntax2004 3062 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3063 smime(16) modules(0) cms-2004(24) } 3065 -- ESS Defined attributes: RFC 2634 (Enhanced Security Services 3066 -- for S/MIME) 3068 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3069 id-aa-contentReference, ContentReference, id-aa-contentIdentifier, 3070 ContentIdentifier 3071 FROM ExtendedSecurityServices 3072 { iso(1) member-body(2) us(840) rsadsi(113549) 3073 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 3075 -- Internet X.509 Public Key Infrastructure - Certificate and CRL 3076 -- Profile: RFC 3280 3078 Certificate, AlgorithmIdentifier, CertificateList, Name, 3079 DirectoryString, Attribute, BMPString, UTF8String 3080 FROM PKIX1Explicit88 3081 {iso(1) identified-organization(3) dod(6) internet(1) 3082 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} 3084 GeneralNames, GeneralName, PolicyInformation 3085 FROM PKIX1Implicit88 3086 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 3087 mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit (19)} 3089 -- Internet Attribute Certificate Profile for Authorization - RFC 3281 3091 AttributeCertificate 3092 FROM PKIXAttributeCertificate {iso(1) identified-organization(3) 3093 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3094 id-mod(0) id-mod-attribute-cert(12)} 3096 -- OCSP - RFC 2560 3098 BasicOCSPResponse, ResponderID 3099 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 3100 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 3102 -- Time Stamp Protocol RFC 3161 3104 TimeStampToken 3105 FROM PKIXTSP 3106 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 3107 mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}; 3109 -- S/MIME Object Identifier arcs used in the present document 3110 -- ========================================================== 3112 -- S/MIME OID arc used in the present document 3113 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3114 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 3116 -- S/MIME Arcs 3117 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 3118 -- modules 3119 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 3120 -- content types 3121 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 3122 -- attributes 3123 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 3124 -- signature policy qualifier 3125 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 3126 -- commitment type identifier 3128 -- Definitions of Object Identifier arcs used in the present document 3129 -- ================================================================== 3131 -- The allocation of OIDs to specific objects are given below with 3132 -- the associated ASN.1 syntax definition 3134 -- OID used referencing electronic signature mechanisms based on 3135 -- the present document for use with the IDUP API (see annex D) 3136 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3137 { itu-t(0) identified-organization(4) etsi(0) 3138 electronic-signature-standard (1733) part1 (1) idupMechanism (4) 3139 etsiESv1(1) } 3141 -- Basic ES CMS Attributes Defined in the present document 3142 -- ======================================================= 3144 -- Mandatory RFC 3852 Electronic Signature Attributes 3146 -- OtherSigningCertificate 3148 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 3149 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3150 smime(16) id-aa(2) 19 } 3152 OtherSigningCertificate ::= SEQUENCE { 3153 certs SEQUENCE OF OtherCertID, 3154 policies SEQUENCE OF PolicyInformation OPTIONAL 3155 -- NOT USED IN THE PRESENT DOCUMENT 3156 } 3158 OtherCertID ::= SEQUENCE { 3159 otherCertHash OtherHash, 3160 issuerSerial IssuerSerial OPTIONAL } 3162 OtherHash ::= CHOICE { 3163 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3164 otherHash OtherHashAlgAndValue} 3166 OtherHashValue ::= OCTET STRING 3168 OtherHashAlgAndValue ::= SEQUENCE { 3169 hashAlgorithm AlgorithmIdentifier, 3170 hashValue OtherHashValue } 3172 -- Policy ES Attributes Defined in the present document 3173 -- ==================================================== 3175 -- Mandatory Basic Electronic Signature Attributes as above, 3176 -- plus in addition. 3178 -- Signature Policy Identifier 3180 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 3181 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3182 smime(16) id-aa(2) 15 } 3183 SignaturePolicy ::= CHOICE { 3184 signaturePolicyId SignaturePolicyId, 3185 signaturePolicyImplied SignaturePolicyImplied 3186 -- not used in this version 3187 } 3189 SignaturePolicyId ::= SEQUENCE { 3190 sigPolicyId SigPolicyId, 3191 sigPolicyHash SigPolicyHash OPTIONAL, 3192 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3193 SigPolicyQualifierInfo OPTIONAL 3194 } 3196 SignaturePolicyImplied ::= NULL 3198 SigPolicyId ::= OBJECT IDENTIFIER 3200 SigPolicyHash ::= OtherHashAlgAndValue 3202 SigPolicyQualifierInfo ::= SEQUENCE { 3203 sigPolicyQualifierId SigPolicyQualifierId, 3204 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 3206 SigPolicyQualifierId ::= OBJECT IDENTIFIER 3208 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 3209 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3210 smime(16) id-spq(5) 1 } 3212 SPuri ::= IA5String 3214 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 3215 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3216 smime(16) id-spq(5) 2 } 3218 SPUserNotice ::= SEQUENCE { 3219 noticeRef NoticeReference OPTIONAL, 3220 explicitText DisplayText OPTIONAL} 3222 NoticeReference ::= SEQUENCE { 3223 organization DisplayText, 3224 noticeNumbers SEQUENCE OF INTEGER } 3226 DisplayText ::= CHOICE { 3227 visibleString VisibleString (SIZE (1..200)), 3228 bmpString BMPString (SIZE (1..200)), 3229 utf8String UTF8String (SIZE (1..200)) } 3231 -- Optional Electronic Signature Attributes 3233 -- Commitment Type 3235 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3236 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3238 CommitmentTypeIndication ::= SEQUENCE { 3239 commitmentTypeId CommitmentTypeIdentifier, 3240 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3241 CommitmentTypeQualifier OPTIONAL} 3243 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3245 CommitmentTypeQualifier ::= SEQUENCE { 3246 commitmentTypeIdentifier CommitmentTypeIdentifier, 3247 qualifier ANY DEFINED BY commitmentTypeIdentifier } 3249 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3250 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 3252 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3253 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 3255 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 3256 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} 3258 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3259 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 3261 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 3262 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} 3264 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 3265 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} 3267 -- Signer Location 3269 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3270 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3271 SignerLocation ::= SEQUENCE { 3272 -- at least one of the following shall be present 3273 countryName [0] DirectoryString OPTIONAL, 3274 -- As used to name a Country in X.500 3275 localityName [1] DirectoryString OPTIONAL, 3276 -- As used to name a locality in X.500 3277 postalAdddress [2] PostalAddress OPTIONAL } 3279 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 3281 -- Signer Attributes 3283 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3284 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3286 SignerAttribute ::= SEQUENCE OF CHOICE { 3287 claimedAttributes [0] ClaimedAttributes, 3288 certifiedAttributes [1] CertifiedAttributes } 3290 ClaimedAttributes ::= SEQUENCE OF Attribute 3292 CertifiedAttributes ::= AttributeCertificate 3293 -- as defined in RFC 3281 : see clause 4.1 3295 -- Content Timestamp 3297 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3298 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} 3300 ContentTimestamp::= TimeStampToken 3302 -- Signature Timestamp 3304 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member- 3305 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} 3307 SignatureTimeStampToken ::= TimeStampToken 3309 -- Complete Certificate Refs. 3311 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3312 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3314 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 3315 -- Complete Revocation Refs 3317 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3318 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3320 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3322 CrlOcspRef ::= SEQUENCE { 3323 crlids [0] CRLListID OPTIONAL, 3324 ocspids [1] OcspListID OPTIONAL, 3325 otherRev [2] OtherRevRefs OPTIONAL 3326 } 3328 CRLListID ::= SEQUENCE { 3329 crls SEQUENCE OF CrlValidatedID} 3331 CrlValidatedID ::= SEQUENCE { 3332 crlHash OtherHash, 3333 crlIdentifier CrlIdentifier OPTIONAL} 3335 CrlIdentifier ::= SEQUENCE { 3336 crlissuer Name, 3337 crlIssuedTime UTCTime, 3338 crlNumber INTEGER OPTIONAL 3339 } 3341 OcspListID ::= SEQUENCE { 3342 ocspResponses SEQUENCE OF OcspResponsesID} 3344 OcspResponsesID ::= SEQUENCE { 3345 ocspIdentifier OcspIdentifier, 3346 ocspRepHash OtherHash OPTIONAL 3347 } 3349 OcspIdentifier ::= SEQUENCE { 3350 ocspResponderID ResponderID, -- As in OCSP response data 3351 producedAt GeneralizedTime -- As in OCSP response data 3352 } 3354 OtherRevRefs ::= SEQUENCE { 3355 otherRevRefType OtherRevRefType, 3356 otherRevRefs ANY DEFINED BY otherRevRefType 3357 } 3359 OtherRevRefType ::= OBJECT IDENTIFIER 3361 -- Certificate Values 3363 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3364 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3366 CertificateValues ::= SEQUENCE OF Certificate 3368 -- Certificate Revocation Values 3370 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 3371 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3372 smime(16) id-aa(2) 24} 3374 RevocationValues ::= SEQUENCE { 3375 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3376 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3377 otherRevVals [2] OtherRevVals OPTIONAL} 3379 OtherRevVals ::= SEQUENCE { 3380 otherRevValType OtherRevValType, 3381 otherRevVals ANY DEFINED BY otherRevValType 3382 } 3384 OtherRevValType ::= OBJECT IDENTIFIER 3386 -- CAdES-C Timestamp 3388 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3389 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 3391 ESCTimeStampToken ::= TimeStampToken 3393 -- Time-Stamped Certificates and CRLs 3395 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) 3396 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3397 smime(16) id-aa(2) 26} 3399 TimestampedCertsCRLs ::= TimeStampToken 3401 -- Archive Timestamp 3403 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) 3404 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3405 smime(16) id-aa(2) 27} 3406 ArchiveTimeStampToken ::= TimeStampToken 3408 -- Attribute certificate references 3410 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) 3411 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3412 smime(16) id-aa(2) 44} 3414 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 3416 -- Attribute revocation references 3418 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) 3419 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3420 smime(16) id-aa(2) 45} 3422 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 3424 END 3425 A.2 Signature format definitions using X.680 ASN.1 syntax 3427 NOTE: The ASN.1 module defined in clause A.2 has precedence over that 3428 defined in clause A.2 using syntax defined in ITU-T 3429 Recommendation X.680 (1997) [8] in the case of any conflict. 3431 ETS-ElectronicSignatureFormats-ExplicitSyntax97 { iso(1) member-body(2) 3432 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 3433 eSignature-explicit97(29)} 3435 DEFINITIONS EXPLICIT TAGS ::= 3437 BEGIN 3439 -- EXPORTS All - 3441 IMPORTS 3443 -- Cryptographic Message Syntax (CMS): RFC 3852 3445 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3446 EncapsulatedContentInfo, SignerInfo, 3447 id-contentType, id-messageDigest, MessageDigest, id-signingTime, 3448 SigningTime, id-countersignature, Countersignature 3449 FROM CryptographicMessageSyntax2004 3450 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3451 smime(16) modules(0) cms-2004(24) } 3453 -- ESS Defined attributes: RFC 2634 3454 -- (Enhanced Security Services for S/MIME) 3456 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3457 id-aa-contentReference, ContentReference, id-aa-contentIdentifier, 3458 ContentIdentifier 3459 FROM ExtendedSecurityServices 3460 { iso(1) member-body(2) us(840) rsadsi(113549) 3461 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 3463 -- Internet X.509 Public Key Infrastructure 3464 -- Certificate and CRL Profile: RFC 3280 3466 Certificate, AlgorithmIdentifier, CertificateList, Name, 3467 DirectoryString, Attribute, 3468 FROM PKIX1Explicit88 3469 {iso(1) identified-organization(3) dod(6) internet(1) 3470 security(5) mechanisms(5) pkix(7) id-mod(0) 3471 id-pkix1-explicit(18)} 3473 GeneralNames, GeneralName, PolicyInformation 3474 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 3475 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3476 id-pkix1-implicit(19)} 3478 -- Internet Attribute Certificate Profile for Authorization - RFC 3281 3480 AttributeCertificate 3481 FROM PKIXAttributeCertificate {iso(1) identified-organization(3) 3482 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 3483 id-mod-attribute-cert(12)} 3485 -- OCSP RFC 2560 3487 BasicOCSPResponse, ResponderID 3488 FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1) 3489 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)} 3491 -- RFC 3161 Internet X.509 Public Key Infrastructure 3492 -- Time-Stamp Protocol (TSP) 3494 TimeStampToken 3495 FROM PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1) 3496 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 3498 maxSize 3499 FROM ETS-ElectronicSignaturePolicies-97Syntax { iso(1) 3500 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3501 smime(16) id-mod(0) 8} 3503 ; 3505 -- S/MIME Object Identifier arcs used in the present document 3506 -- ========================================================== 3508 -- S/MIME OID arc used in the present document 3509 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3510 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 3512 -- S/MIME Arcs 3513 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 3514 -- modules 3515 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 3516 -- content types 3517 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 3518 -- attributes 3519 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 3520 -- signature policy qualifier 3521 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 3522 -- commitment type identifier 3524 -- Definitions of Object Identifier arcs used in the present document 3525 -- ================================================================== 3527 -- The allocation of OIDs to specific objects are given below 3528 -- with the associated ASN.1 syntax definition 3529 -- OID used referencing electronic signature mechanisms based 3530 -- on the present document for use with the IDUP API (see annex D) 3532 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3533 { itu-t(0) identified-organization(4) etsi(0) 3534 electronic-signature-standard (1733) part1 (1) idupMechanism (4) 3535 etsiESv1(1) } 3537 -- Basic ES Attributes Defined in the present document 3538 -- =================================================== 3540 -- CMS Attributes Defined in the present document 3542 -- Mandatory RFC 3852 Electronic Signature Attributes 3544 -- OtherSigningCertificate 3546 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 3547 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3548 smime(16) id-aa(2) 19 } 3550 OtherSigningCertificate ::= SEQUENCE { 3551 certs SEQUENCE OF OtherCertID, 3552 policies SEQUENCE OF PolicyInformation OPTIONAL 3553 -- NOT USED IN THE PRESENT DOCUMENT 3554 } 3556 OtherCertID ::= SEQUENCE { 3557 otherCertHash OtherHash, 3558 issuerSerial IssuerSerial OPTIONAL } 3560 OtherHash ::= CHOICE { 3561 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3562 otherHash OtherHashAlgAndValue} 3564 OtherHashValue ::= OCTET STRING 3566 OtherHashAlgAndValue ::= SEQUENCE { 3567 hashAlgorithm AlgorithmIdentifier, 3568 hashValue OtherHashValue } 3570 -- Policy ES Attributes Defined in the present document 3571 -- ==================================================== 3573 -- Mandatory Basic Electronic Signature Attributes, plus in addition. 3574 -- Signature Policy Identifier 3576 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 3577 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3578 smime(16) id-aa(2) 15 } 3579 SignaturePolicy ::= CHOICE { 3580 signaturePolicyId SignaturePolicyId, 3581 signaturePolicyImplied SignaturePolicyImplied 3582 -- not used in this version 3583 } 3585 SignaturePolicyId ::= SEQUENCE { 3586 sigPolicyId SigPolicyId, 3587 sigPolicyHash SigPolicyHash OPTIONAL, 3588 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3589 SigPolicyQualifierInfo OPTIONAL 3590 } 3592 SignaturePolicyImplied ::= NULL 3594 SigPolicyId ::= OBJECT IDENTIFIER 3596 SigPolicyHash ::= OtherHashAlgAndValue 3598 SigPolicyQualifierInfo ::= SEQUENCE { 3599 sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id 3600 ({SupportedSigPolicyQualifiers}), 3601 qualifier SIG-POLICY-QUALIFIER.&Qualifier 3602 ({SupportedSigPolicyQualifiers} 3603 {@sigPolicyQualifierId})OPTIONAL } 3605 SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 3606 { noticeToUser | pointerToSigPolSpec } 3608 SIG-POLICY-QUALIFIER ::= CLASS { 3609 &id OBJECT IDENTIFIER UNIQUE, 3610 &Qualifier OPTIONAL } 3611 WITH SYNTAX { 3612 SIG-POLICY-QUALIFIER-ID &id 3613 [SIG-QUALIFIER-TYPE &Qualifier] } 3615 noticeToUser SIG-POLICY-QUALIFIER ::= { 3616 SIG-POLICY-QUALIFIER-ID id-spq-ets-unotice SIG-QUALIFIER-TYPE 3617 SPUserNotice } 3619 pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { 3620 SIG-POLICY-QUALIFIER-ID id-spq-ets-uri SIG-QUALIFIER-TYPE SPuri } 3622 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 3623 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3624 smime(16) id-spq(5) 1 } 3626 SPuri ::= IA5String 3627 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 3628 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3629 smime(16) id-spq(5) 2 } 3631 SPUserNotice ::= SEQUENCE { 3632 noticeRef NoticeReference OPTIONAL, 3633 explicitText DisplayText OPTIONAL} 3635 NoticeReference ::= SEQUENCE { 3636 organization DisplayText, 3637 noticeNumbers SEQUENCE OF INTEGER } 3639 DisplayText ::= CHOICE { 3640 visibleString VisibleString (SIZE (1..200)), 3641 bmpString BMPString (SIZE (1..200)), 3642 utf8String UTF8String (SIZE (1..200)) } 3644 -- Optional Electronic Signature Attributes 3646 -- Commitment Type 3648 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3649 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3651 CommitmentTypeIndication ::= SEQUENCE { 3652 commitmentTypeId CommitmentTypeIdentifier, 3653 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3654 CommitmentTypeQualifier OPTIONAL} 3656 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3658 CommitmentTypeQualifier ::= SEQUENCE { 3659 commitmentQualifierId COMMITMENT-QUALIFIER.&id, 3660 qualifier COMMITMENT-QUALIFIER.&Qualifier OPTIONAL } 3662 COMMITMENT-QUALIFIER ::= CLASS { 3663 &id OBJECT IDENTIFIER UNIQUE, 3664 &Qualifier OPTIONAL } 3665 WITH SYNTAX { 3666 COMMITMENT-QUALIFIER-ID &id 3667 [COMMITMENT-TYPE &Qualifier] } 3669 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3670 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 1} 3672 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3673 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 2} 3675 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 3676 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 3} 3677 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3678 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 4} 3680 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 3681 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 5} 3683 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 3684 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) cti(6) 6} 3686 -- Signer Location 3688 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3689 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3691 SignerLocation ::= SEQUENCE { 3692 -- at least one of the following shall be present 3693 countryName [0] DirectoryString{maxSize} OPTIONAL, 3694 -- As used to name a Country in X.500 3695 localityName [1] DirectoryString{maxSize} OPTIONAL, 3696 -- As used to name a locality in X.500 3697 postalAdddress [2] PostalAddress OPTIONAL } 3699 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString{maxSize} 3701 -- Signer Attributes 3703 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3704 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3706 SignerAttribute ::= SEQUENCE OF CHOICE { 3707 claimedAttributes [0] ClaimedAttributes, 3708 certifiedAttributes [1] CertifiedAttributes } 3710 ClaimedAttributes ::= SEQUENCE OF Attribute 3712 CertifiedAttributes ::= AttributeCertificate 3713 -- as defined in RFC 3281 : see clause 4.1 3715 -- Content Timestamp 3717 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3718 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 20} 3720 ContentTimestamp::= TimeStampToken 3722 -- Signature Timestamp 3724 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member- 3725 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} 3727 SignatureTimeStampToken ::= TimeStampToken 3729 -- Complete Certificate Refs. 3731 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3732 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3734 CompleteCertificateRefs ::= SEQUENCE OF OtherCertID 3736 -- Complete Revocation Refs 3738 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3739 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3741 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3743 CrlOcspRef ::= SEQUENCE { 3744 crlids [0] CRLListID OPTIONAL, 3745 ocspids [1] OcspListID OPTIONAL, 3746 otherRev [2] OtherRevRefs OPTIONAL 3747 } 3749 CRLListID ::= SEQUENCE { 3750 crls SEQUENCE OF CrlValidatedID} 3752 CrlValidatedID ::= SEQUENCE { 3753 crlHash OtherHash, 3754 crlIdentifier CrlIdentifier OPTIONAL} 3756 CrlIdentifier ::= SEQUENCE { 3757 crlissuer Name, 3758 crlIssuedTime UTCTime, 3759 crlNumber INTEGER OPTIONAL 3760 } 3762 OcspListID ::= SEQUENCE { 3763 ocspResponses SEQUENCE OF OcspResponsesID} 3765 OcspResponsesID ::= SEQUENCE { 3766 ocspIdentifier OcspIdentifier, 3767 ocspRepHash OtherHash OPTIONAL 3768 } 3770 OcspIdentifier ::= SEQUENCE { 3771 ocspResponderID ResponderID, -- As in OCSP response data 3772 producedAt GeneralizedTime -- As in OCSP response data 3773 } 3775 OtherRevRefs ::= SEQUENCE { 3776 otherRevRefType OTHER-REVOCATION-REF.&id, 3777 otherRevRefs SEQUENCE OF OTHER-REVOCATION-REF.&Type 3778 } 3779 OTHER-REVOCATION-REF ::= CLASS { 3780 &Type, 3781 &id OBJECT IDENTIFIER UNIQUE } 3782 WITH SYNTAX { 3783 WITH SYNTAX &Type ID &id } 3785 -- Certificate Values 3787 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3788 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3790 CertificateValues ::= SEQUENCE OF Certificate 3792 -- Certificate Revocation Values 3794 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- 3795 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24} 3797 RevocationValues ::= SEQUENCE { 3798 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3799 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3800 otherRevVals [2] OtherRevVals OPTIONAL} 3802 OtherRevVals ::= SEQUENCE { 3803 otherRevValType OTHER-REVOCATION-VAL.&id, 3804 otherRevVals SEQUENCE OF OTHER-REVOCATION-REF.&Type 3805 } 3807 OTHER-REVOCATION-VAL ::= CLASS { 3808 &Type, 3809 &id OBJECT IDENTIFIER UNIQUE } 3810 WITH SYNTAX { 3811 WITH SYNTAX &Type ID &id } 3813 -- CAdES-C Timestamp 3815 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3816 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 3818 ESCTimeStampToken ::= TimeStampToken 3820 -- Time-Stamped Certificates and CRLs 3822 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3823 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} 3825 TimestampedCertsCRLs ::= TimeStampToken 3827 -- Archive Timestamp 3829 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3830 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27} 3832 ArchiveTimeStampToken ::= TimeStampToken 3834 -- Attribute certificate references 3836 id-aa-ets-attrCertificateRefs OBJECT IDENTIFIER ::= { iso(1) member- 3837 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 44} 3839 AttributeCertificateRefs ::= SEQUENCE OF OtherCertID 3841 -- Attribute revocation references 3843 id-aa-ets-attrRevocationRefs OBJECT IDENTIFIER ::= { iso(1) member- 3844 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 45} 3846 AttributeRevocationRefs ::= SEQUENCE OF CrlOcspRef 3848 END 3849 Annex B (informative): Extended forms of Electronic Signatures 3851 Clause 4 provides on overview of the various formats of electronic 3852 signatures included in the present document. This annex lists the 3853 attributes that need to be present in the various extended electronic 3854 signature formats and provide example validation sequences using the 3855 extended formats. 3857 B.1 Extended forms of validation data 3859 The complete validation data (CAdES-C) described in clause 4.3 and 3860 illustrated in figure 3 may be extended to create Electronic Signatures 3861 with extended validation data. Some Electronic Signatures forms that 3862 include extended validation are explained below. 3864 An X-Long electronic signature (CAdES-X Long) is when the values of the 3865 certificates and revocation information are added to the CAdES-C. 3867 This form of Electronic Signature can be useful when the verifier does 3868 not have direct access to the following information: 3870 - the signer's certificate; 3872 - all the CA certificates that make up the full certification path; 3874 - all the associated revocation status information, as referenced 3875 in the CAdES-C. 3877 In some situations additional time-stamps may be created and added to 3878 the Electronic Signatures as additional attributes. For example: 3880 - time-stamping all the validation data as held with the ES (CAdES- 3881 C), this eXtended validation data is called a CAdES-X Type 1; or 3883 - time-stamping individual reference data as used for complete 3884 validation. This form of eXtended validation data is called an 3885 CAdES-X Type 2. 3887 NOTE 1: The advantages/drawbacks for CAdES-X Type 1 and CAdES-X Type 2 3888 are discussed in clause C.4.4. 3890 The above time-stamp forms can be useful when it is required to counter 3891 the risk that any CA keys used in the certificate chain may be 3892 compromised. 3894 A combination of the two formats above may be used. This form of 3895 eXtended validation data is called an ES X-Long Type 1 or CAdES-X Long 3896 Type 2. This form of Electronic Signature can be useful when the 3897 verifier needs both the values and proof of when the validation data 3898 existed. 3900 NOTE 2: The advantages/drawbacks for CAdES-X long Type 1 and CAdES-X 3901 long Type 2 are discussed in clause C.4.6. 3903 B.1.1 CAdES-X Long 3905 An Electronic Signature with the additional validation data forming the 3906 CAdES-X Long form (CAdES-X-Long)) is illustrated in figure B.1 and 3907 comprises the following: 3909 - CAdES-BES or CAdES-EPES as defined in clauses 4.3 , 5.7 or 5.8; 3911 - complete-certificate-references attribute as defined in clause 3912 6.2.1; 3914 - complete-revocation-references attribute as defined in clause 3915 6.2.2. 3917 The following attributes are required if a TSP is not providing a time- 3918 mark of the ES: 3920 - signature-time-stamp attribute as defined in clause 6.1.1. 3922 The following attributes are required if the full certificate values 3923 and revocation values are not already included in the CAdES-BES or 3924 CAdES-EPES: 3926 - certificate-values attribute as defined in clause 6.3.3; 3927 - revocation-values attribute, as defined in clause 6.3.4. 3929 If attributes certificates are used then the following attributes may 3930 be present: 3932 - attribute-certificate-references attribute defined in clause 3933 6.2.3; 3935 - attribute-revocation-references attribute as defined in clause 3936 6.2.4. 3938 Other unsigned attributes may be present, but are not required. 3940 NOTE: Attribute certificate and revocation references are only 3941 present if a user attribute certificate is present in the 3942 electronic signature, see clauses 6.2.2 and 6.2.3. 3944 +---------------------- CAdES-X-Long --------------------------------+ 3945 |+-------------------------------------- CAdES-C ---+ | 3946 || +----------+ | +-------------+| 3947 ||+----- CAdES-BES or CAdES-EPES ----+ |Timestamp | | | || 3948 ||| | |over | | | Complete || 3949 |||+---------++----------++---------+| |digital | | | certificate || 3950 |||| || || || |signature | | | and || 3951 ||||Signer's || Signed ||Digital || | | | | revocation || 3952 ||||Document ||Attributes||signature|| |Optional | | | data || 3953 |||| || || || |when | | | || 3954 |||+---------++----------++---------+| |timemarked| | | || 3955 ||+----------------------------------+ +----------+ | | || 3956 || +-----------+| +-------------+| 3957 || |Complete || | 3958 || |certificate|| | 3959 || |and || | 3960 || |revocation || | 3961 || |references || | 3962 || +-----------+| | 3963 |+--------------------------------------------------+ | 3964 | | 3965 +--------------------------------------------------------------------+ 3967 Figure B.1 : Illustration of CAdES-X-Long 3969 B.1.2 CAdES-X Type 1 3971 An Electronic Signature with the additional validation data forming the 3972 eXtended Validation Data - Type 1 X is illustrated in figure B.2 and 3973 comprises the following: 3975 - the CAdES-BES or CAdES-EPES as defined in clauses 4.2, 5.7 or 3976 5.8; 3978 - complete-certificate-references attribute as defined in clause 3979 6.2.1; 3981 - complete-revocation-references attribute as defined in clause 3982 6.2.2; 3984 - CAdES-C-Timestamp attribute, as defined in clause 6.3.5. 3986 The following attributes are required if a TSP is not providing a time- 3987 mark of the ES: 3989 - signature-time-stamp attribute as defined in clause 6.1.1. 3991 If attributes certificates are used then the following attributes may 3992 be present: 3994 - attribute-certificate-references attribute defined in clause 3995 6.2.3; 3997 - attribute-revocation-references attribute as defined in clause 3998 6.2.4. 4000 Other unsigned attributes may be present, but are not required. 4002 +------------------------ CAdES-X-Type 1 ----------------------------+ 4003 |+---------------------------------- CAdES-C ------+ | 4004 || +----------+ | +-------------+ | 4005 ||+--- CAdES-BES or CAdES-EPES ------+|Timestamp | | | | | 4006 ||| ||over | | | | | 4007 |||+---------++----------++---------+||digital | | | | | 4008 ||||Signer's || Signed || Digital |||signature | | | Timestamp | | 4009 ||||Document ||Attributes||signature||| | | | over | | 4010 |||| || || |||Optional | | | CAdES-C | | 4011 |||+---------++----------++---------+||when | | | | | 4012 ||+----------------------------------+|timemarked| | | | | 4013 || +----------+ | | | | 4014 || +-----------+| +-------------+ | 4015 || |Complete || | 4016 || |certificate|| | 4017 || | and || | 4018 || |revocation || | 4019 || |references || | 4020 || +-----------+| | 4021 |+-------------------------------------------------+ | 4022 | | 4023 +--------------------------------------------------------------------+ 4025 Figure B.2 : Illustration of CAdES-X Type 1 4027 B.1.3 CAdES-X Type 2 4029 An Electronic Signature with the additional validation data forming the 4030 eXtended Validation Data - Type 2 X is illustrated in figure B.3. and 4031 comprises the following: 4033 - CAdES-BES or CAdES-EPES as defined in clauses 4.2, 5.7 or 5.8; 4035 - complete-certificate-references attribute as defined in clause 4036 6.2.1; 4038 - complete-revocation-references attribute as defined in clause 4039 6.2.2; 4041 - time-stamped-certs-crls-references attribute as defined in clause 4042 6.3.6. 4044 The following attributes are required if a TSP is not providing a time- 4045 mark of the ES: 4047 - signature-time-stamp attribute as defined in clause 6.1.1. 4049 If attributes certificates are used then the following attributes may 4050 be present: 4052 - attribute-certificate-references attribute defined in clause 4053 6.2.3; 4055 - attribute-revocation-references attribute as defined in clause 4056 6.2.4. 4058 Other unsigned attributes may be present, but are not required. 4060 +----------------------- CAdES-X-Type 2 -----------------------------+ 4061 |+-------------------------------------- CAdES-C --+ | 4062 || +----------+ | | 4063 ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | | | 4064 ||| ||over | | | 4065 |||+---------++----------++---------+||digital | | +-------------+ | 4066 |||| || || |||Signature | | | Timestamp | | 4067 ||||Signer's || Signed || Digital ||| | | | only over | | 4068 ||||Document ||Attributes||signature|||Optional | | | Complete | | 4069 |||| || || |||when | | | certificate | | 4070 |||+---------++----------++---------+||Timemarked| | | and | | 4071 ||+----------------------------------++----------+ | | revocation | | 4072 || +-----------+| | references | | 4073 || |Complete || +-------------+ | 4074 || |certificate|| | 4075 || |and || | 4076 || |revocation || | 4077 || |references || | 4078 || +-----------+| | 4079 |+-------------------------------------------------+ | 4080 | | 4081 +--------------------------------------------------------------------+ 4083 Figure B.3 : Illustration of CAdES-X Type 2 4085 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 4087 An Electronic Signature with the additional validation data forming the 4088 CAdES-X Long Type 1 and CAdES-X Long Type 2 is illustrated in 4089 figure B.4 and comprises the following: 4091 - CAdES-BES or CAdES-EPES as defined in clauses 4.3, 5.7 or 5.8; 4093 - complete-certificate-references attribute as defined in clause 4094 6.2.1; 4096 - complete-revocation-references attribute as defined in clause 4097 6.2.2; 4099 The following attributes are required if a TSP is not providing a time- 4100 mark of the ES: 4102 - signature-time-stamp attribute as defined in clause 6.1.1. 4104 The following attributes are required if the full certificate values 4105 and revocation values are not already included in the CAdES-BES or 4106 CAdES-EPES: 4107 - certificate-values attribute as defined in clause 6.3.3; 4108 - revocation-values attribute, as defined in clause 6.3.4. 4110 If attributes certificates are used then the following attributes may 4111 be present: 4113 - attribute-certificate-references attribute defined in clause 4114 6.2.3; 4116 - attribute-revocation-references attribute as defined in clause 4117 6.2.4. 4119 Plus one of the following attributes is required: 4121 - CAdES-C-Timestamp attribute, as defined in clause 6.3.5; 4122 - time-stamped-certs-crls-references attribute as defined in clause 4123 6.3.6. 4125 Other unsigned attributes may be present, but are not required. 4127 +---------------------- CAdES-X-Type 1 or 2 ------------------------+ 4128 | +--------------+| 4129 |+-------------------------------------- CAdES-C --+|+------------+|| 4130 || +----------+ ||| Timestamp ||| 4131 ||+-- CAdES-BES or CAdES-EPES -------+|Timestamp | ||| over ||| 4132 ||| ||over | ||| CAdES-C ||| 4133 |||+---------++----------++---------+||digital | | +------------+ | 4134 |||| || || |||signature | || or || 4135 ||||Signer's || Signed || Digital ||| | ||+------------+|| 4136 ||||Document ||Attributes||Signature|||Optional | ||| Timestamp ||| 4137 |||| || || |||when | ||| only over ||| 4138 |||+---------++----------++---------+||timemarked| ||| complete ||| 4139 ||+----------------------------------++----------+ ||| certificate||| 4140 || ||| and ||| 4141 || +-----------+||| revocation ||| 4142 || |Complete |||| references ||| 4143 || |certificate|||+------------+|| 4144 || |and ||+--------------+| 4145 || |revocation || +------------+ | 4146 || |references || |Complete | | 4147 || +-----------+| |certificate | | 4148 |+-------------------------------------------------+ | and | | 4149 | |revocation | | 4150 | | values | | 4151 | +------------+ | 4152 +-------------------------------------------------------------------+ 4154 Figure B.4 : Illustration of CAdES-X Long Type 1 4155 and CAdES-X Long Type 2 4157 B.2 Timestamp extensions 4159 Each instance of time-stamp attribute may include as unsigned 4160 attributes in the signedData of the timestamp the following attribute 4161 related to the TSU: 4163 - complete-certificate-references attribute of the TSU as defined 4164 in clause 6.2.1; 4166 - complete-revocation-references attribute of the TSU as defined in 4167 clause 6.2.2; 4169 - certificate-values attribute; of the TSU as defined in clause 4170 6.3.3; 4172 - revocation-values attribute, of the TSU as defined in clause 4173 6.3.4. 4175 Other unsigned attributes may be present, but are not required. 4177 B.3 Archive validation data (CAdES-A) 4179 Before the algorithms, keys and other cryptographic data used at the 4180 time the CAdES-C was built become weak and the cryptographic functions 4181 become vulnerable, or the certificates supporting previous time-stamps 4182 expires, the signed data, the CAdES-C and any additional information 4183 (i.e. any CAdES-X) should be time-stamped. If possible this should use 4184 stronger algorithms (or longer key lengths) than in the original time- 4185 stamp. This additional data and time-stamp is called Archive 4186 Validation Data required for the ES Archive format (CAdES-A). The 4187 Time-stamping process may be repeated every time the protection used to 4188 time-stamp a previous CAdES-A becomes weak. An CAdES-A may thus bear 4189 multiple embedded time stamps. 4191 An example of an Electronic Signature (ES), with the additional 4192 validation data for the CAdES-C and CAdES-X forming the CAdES-A is 4193 illustrated in figure B.5. 4195 +--------------------------- CAdES-A---------------------------------+ 4196 |+----------------------------------------------------+ | 4197 || +--------------+| +----------+ | 4198 ||+--------------------- CAdES-C ----+|+------------+|| | | | 4199 ||| +----------+ ||| Timestamp ||| | | | 4200 |||+-- CAdES-BES ------+|Timestamp | ||| over ||| | | | 4201 |||| or CAdES-EPES ||over | ||| CAdES-C ||| | Archive | | 4202 |||| ||digital | ||+------------+|| | | | 4203 |||| ||signature | || or || |Timestamp | | 4204 |||| || | ||+------------+|| | | | 4205 |||| ||optional | ||| Timestamp ||| | | | 4206 |||| ||when | ||| only over ||| | | | 4207 |||| ||timemarked| ||| complete ||| | | | 4208 |||+-------------------++----------+ ||| certificate||| +----------+ | 4209 ||| ||| and ||| | 4210 ||| +-------------+||| revocation ||| | 4211 ||| | Complete |||| references ||| | 4212 ||| | certificate |||+------------+|| | 4213 ||| | and ||+--------------+| | 4214 ||| | revocation || +------------+ | | 4215 ||| | references || |Complete | | | 4216 ||| +-------------+| |certificate | | | 4217 ||+----------------------------------+ | and | | | 4218 || |revocation | | | 4219 || | values | | | 4220 || +------------+ | | 4221 |+----------------------------------------------------+ | 4222 +--------------------------------------------------------------------+ 4224 Figure B.5 : Illustration of CAdES-A 4226 The CAdES-A comprises the following elements: 4228 - the CAdES-BES or CAdES-EPES including their signed and unsigned 4229 attributes; 4231 - complete-certificate-references attribute as defined in clause 4232 6.2.1; 4234 - complete-revocation-references attribute as defined in clause 4235 6.2.2. 4237 The following attributes are required if a TSP is not providing a time- 4238 mark of the ES: 4240 - signature-time-stamp attribute as defined in clause 6.1.1. 4242 If attributes certificates are used then the following attributes may 4243 be present: 4245 - attribute-certificate-references attribute defined in clause 4246 6.2.3; 4247 - attribute-revocation-references attribute as defined in clause 4248 6.2.4. 4250 The following attributes are required if the full certificate values 4251 and revocation values are not already included in the CAdES-BES or 4252 CAdES-EPES: 4254 - certificate-values attribute as defined in clause 6.3.3; 4255 - revocation-values attribute as defined in clause 6.3.4. 4257 At least one of the following two attributes is required: 4259 - CAdES-C-Timestamp attribute as defined in clause 6.3.5; 4261 - time-stamped-certs-crls-references attribute as defined in clause 4262 6.3.6. 4264 The following attribute is required: 4266 - archive-time-stamp attributes defined in clause 6.4.1. 4268 Several instances of archive-time-stamp attribute may occur with an 4269 electronic signature both over time and from different TSUs. The time- 4270 stamp should be created using stronger algorithms (or longer key 4271 lengths) than in the original electronic signatures or time-stamps. 4273 Other unsigned attributes of the ES may be present, but are not 4274 required. 4276 The archive timestamp will itself contain the certificate and 4277 revocation information required to validate the archive timestamp, this 4278 may include the following unsigned attributes: 4280 - complete-certificate-references attribute of the TSU as defined 4281 in clause 6.2.1; 4283 - complete-revocation-references attribute of the TSU as defined in 4284 clause 6.2.2; 4286 - certificate-values attribute of the TSU as defined in clause 4287 6.3.3; 4289 - revocation-values attribute of the TSU as defined in clause 4290 6.3.4. 4292 Other unsigned attributes may be present, but are not required. 4294 B.4 Example validation sequence 4296 As described earlier the signer or initial verifier may collect all the 4297 additional data that forms the electronic signature. Figure B.6, and 4298 subsequent description, describes how the validation process may build 4299 up a complete electronic signature over time. 4301 +------------------------------------------ CAdES-C -------------+ 4302 |+------------------------------- CAdES-T ------+ | 4303 ||+-------------- CAdES ------------+ | | 4304 |||+--------------------++---------+|+---------+| +-----------+ | 4305 |||| ________ || |||Timestamp|| |Complete | | 4306 |||||Sign.Pol| ||Digital |||over || |certificate| | 4307 ||||| Id. | Signed ||signature|||digital || | and | | 4308 ||||| option.|attributes|| |||signature|| |revocation | | 4309 |||||________| |+---------+|+---------+| |references | | 4310 |||+--------------------+ | ^ | +-----------+ | 4311 ||+---------------------------------+ | | ^ | 4312 || 1 | / | | | 4313 |+---------------------- | ------------/--------+ | | 4314 +----------------------- | ---------- / --------------- / -------+ 4315 | /2 ----3-------- 4316 +----------+ | / / 4317 | | v / | 4318 | Signer's | +---------------------+ +-------------+ 4319 | document |----->| Validation Process |---->|- Valid | 4320 | | +---------------------+ 4 |- Invalid | 4321 +----------+ | ^ | ^ |- Validation | 4322 v | v | | Incomplete | 4323 +---------+ +--------+ +-------------+ 4324 |Signature| |Trusted | 4325 | Policy | |Service | 4326 | Issuer | |Provider| 4327 +---------+ +--------+ 4329 Figure B.6 : Illustration of a CAdES validation sequence 4331 Soon after receiving the Electronic Signature (CAdES) from the signer 4332 (1), the digital signature value may be checked; the validation process 4333 shall at least add a time-stamp (2), unless the signer has provided one 4334 which is trusted by the verifier. The validation process may also 4335 validate the electronic signature, using additional data (e.g. 4336 certificates, CRL, etc.) provided by trusted service providers. When 4337 applicable, the validation process will also need to conform to the 4338 requirements specified in a signature policy. If the validation 4339 process is validation incomplete, then the output from this stage is 4340 the CAdES-T. 4342 To ascertain the validity status as Valid or Invalid and communicate 4343 that to the user (4) all the additional data required to validate the 4344 CAdES-C, must be available (e.g. the complete certificate and 4345 revocation information). 4347 Once the data needed to complete validation data references (CAdES-C) 4348 is available then the validation process should: 4350 - obtain all the necessary additional certificate and revocation 4351 status information; 4353 - complete all the validation checks on the ES, using the complete 4354 certificate and revocation information (if a time-stamp is not 4355 already present, this may be added at the same stage combining 4356 CAdES-T and CAdES-C process); 4358 - record the complete certificate and revocation references (3); 4360 - indicate the validity status to the user (4). 4362 At the same time as the validation process creates the CAdES-C, the 4363 validation process may provide and/or record the values of certificates 4364 and revocation status information used in CAdES-C, called the CAdES-X 4365 Long (5). 4367 This is illustrated in figure B.7. 4369 +----------------------------------------------------- CAdES-X Long -+ 4370 |+------------------------------- CAdES-C -------------+ | 4371 ||+-------------- CAdES ------------+ | | 4372 |||+--------------------++---------+|+---------+ |+-----------+| 4373 |||| ________ || |||Timestamp| ||Complete || 4374 |||||Sign.Pol| ||Digital |||over | ||certificate|| 4375 ||||| Id. | Signed ||signature|||digital | || and || 4376 ||||| option.|attributes|| |||signature| ||revocation || 4377 |||||________| || ||+---------+ || values || 4378 |||+--------------------++---------+| ^ +-----------+|+-----------+| 4379 ||+---------------------------------+ | |Complete || ^ | 4380 || | | |certificate|| | | 4381 || | 2 | | and || | | 4382 || | | |revocation || | | 4383 || | | |references || | | 4384 || 1 | / +-----------+| | | 4385 |+------------------------ | ------- / --------- ^-----+ / | 4386 +------------------------- | ------ / ---------- |--------- / -------+ 4387 | / ----- / ------- / 4388 +----------+ | / / 3 / 5 4389 | | v | | | 4390 | Signer's | +--------------------+ +-----------+ 4391 | document |----->| Validation Process |----->| - Valid | 4392 | | +--------------------+ 4 | - Invalid | 4393 +----------+ | ^ | ^ +-----------+ 4394 v | v | 4395 +---------+ +--------+ 4396 |Signature| |Trusted | 4397 | Policy | |Service | 4398 | Issuer | |Provider| 4399 +---------+ +--------+ 4401 Figure B.7 : Illustration of a CAdES validation sequence 4402 with CAdES-X Long 4404 When the validation process creates the CAdES-C it may also create 4405 extended forms of validation data. 4407 A first alternative is to time-stamp all data forming the CAdES-X Type 4408 1 (6). 4410 This is illustrated in figure B.8. 4412 +------------------------------------------------ CAdES-X Type 1 -----+ 4413 |+------------------------------- CAdES-C ------------------+ | 4414 ||+-------------- CAdES ------------+ | | 4415 |||+--------------------++---------+|+---------++----------+|+-------+| 4416 |||| ________ || |||Timestamp|| Complete ||| || 4417 |||||Sign.Pol| ||Digital |||over || cert. |||Time- || 4418 ||||| Id. | Signed ||signature|||digital || and |||stamp || 4419 ||||| option.|attributes|| |||signature|| revoc. ||| over || 4420 |||||________| |+---------+|+---------+|references|||CAdES-C|| 4421 |||+--------------------+ | ^ | ||| || 4422 ||+---------------------------------+ | +----------+|+-------+| 4423 || | | ^ | ^ | 4424 || 1 | / | | | | 4425 |+------------------------ | --------- / ----------- / -----+ | | 4426 +------------------------- | -------- / ----------- / --------- / ----+ 4427 | 2 / ---3---- / 4428 +----------+ | / / -----------5------ 4429 | | v | | / 4430 | Signer's | +--------------------+ +-----------+ 4431 | document |----->| Validation Process |-----> | - Valid | 4432 | | +--------------------+ 4 | - Invalid | 4433 +----------+ | ^ | ^ +-----------+ 4434 v | v | 4435 +---------+ +--------+ 4436 |Signature| |Trusted | 4437 | Policy | |Service | 4438 | Issuer | |Provider| 4439 +---------+ +--------+ 4441 Figure B.8 : Illustration of CAdES with eXtended Validation Data 4442 CAdES-X Type 1 4444 Another alternative is to time-stamp the certificate and revocation 4445 information references used to validate the electronic signature (but 4446 not the signature) (6'); this is called CAdES-X Type 2. 4448 This is illustrated in figure B.9. 4450 +-------------------------------------------- CAdES-X Type 2 --------+ 4451 |+------------------------------- CAdES-C -------------+ | 4452 ||+-------------- CAdES ------------+ | | 4453 |||+--------------------++---------+|+---------+ |+-----------+| 4454 |||| ________ || |||Timestamp| ||Timestamp || 4455 |||||Sign.Pol| || |||over | || over || 4456 ||||| Id. | Signed ||Digital |||digital | ||complete || 4457 ||||| option.|attributes||signature|||signature| ||certificate|| 4458 |||||________| || ||| | || || 4459 |||+--------------------++---------+|+---------+ || and || 4460 ||+---------------------------------+ ^ +-----------+||revocation || 4461 || | | |Complete |||references || 4462 || | | |certificate||+-----------+| 4463 || | | | and || ^ | 4464 || 1 | 2 | |revocation || | | 4465 || | | |references || | | 4466 || | | +-----------+| | | 4467 |+------------------------ | --------- | --- ^ --------+ | | 4468 | | | 3 | / | 4469 | | | / ---------- | 4470 | | / / / 5 | 4471 | | / / / | 4472 | | / / / | 4473 +------------------------- | ----- | -- | -- / ----------------------+ 4474 | | | | 4475 v | | | 4476 +--------------------+ +-----------+ 4477 | Validation Process |----->| - Valid | 4478 +--------------------+ 4 | - Invalid | 4479 | ^ | ^ +-----------+ 4480 v | v | 4481 +---------+ +--------+ 4482 |Signature| |Trusted | 4483 | Policy | |Service | 4484 | Issuer | |Provider| 4485 +---------+ +--------+ 4487 Figure B.9: Illustration of CAdES with eXtended Validation Data 4488 CAdES-X Type 2 4490 Before the algorithms used in any of electronic signatures become or 4491 are likely, to be compromised or rendered vulnerable in the future, it 4492 may be necessary to time-stamp the entire electronic signature, 4493 including all the values of the validation and user data as an ES with 4494 Archive Validation Data (CAdES-A) (7). 4496 An CAdES-A is illustrated in figure B.10. 4498 +----------------------------- CAdES-A ---------------------------+ 4499 | | 4500 | +-- CAdES-X Long Type 1 or 2 ----------+ | 4501 | | | +------------+ | 4502 | | | | | | 4503 | | | | Archive | | 4504 | | | | Time-stamp | | 4505 | | | | | | 4506 | | | +------------+ | 4507 | +---------------------------------------+ ^ | 4508 | +----------+ ^ ^ ^ ^ | | 4509 | | | | | | | / | 4510 | | Signers' | | | | | / | 4511 | | Document |\ | | | | / | 4512 | | | \ 1 2 | 3 | 5 | 6 | 7 / | 4513 | +----------+ \ | | | | / | 4514 | \ | | | | / | 4515 +----------------- \ --- | - | - | - | ------ / ------------------+ 4516 \ | | | | | 4517 | | | | | | 4518 | | | | | | 4519 v v | | | | 4520 +-----------------------------+ +-----------+ 4521 | Validation Process |----->| - Valid | 4522 +-----------------------------+ 4 | - Invalid | 4523 | ^ | ^ +-----------+ 4524 v | v | 4525 +---------+ +--------+ 4526 |Signature| |Trusted | 4527 | Policy | |Service | 4528 | Issuer | |Provider| 4529 +---------+ +--------+ 4531 Figure B.10: Illustration of CAdES-A 4533 B.5 Additional optional features 4535 The present document also defines additional optional features to: 4537 - indicate a commitment type being made by the signer; 4539 - indicate the claimed time when the signature was done; 4541 - indicate the claimed location of the signer; 4543 - indicate the claimed or certified role under which a signature 4544 was created; 4546 - support counter signatures; 4548 - support multiple signatures. 4550 Annex C (informative):General description 4552 This annex explains some of the concepts and provides the rational for 4553 normative parts of the present document. 4555 The specification below includes a description why and when the each 4556 component of an electronic signature is useful, with a brief 4557 description of the vulnerabilities and threats and the manner by which 4558 they are countered. 4560 C.1 The signature policy 4562 The signature policy is a set of rules for the creation and validation 4563 of an electronic signature, under which the signature can be determined 4564 to be valid. A given legal/contractual context may recognize a 4565 particular signature policy as meeting its requirements. A signature 4566 policy may be issued, for example, by a party relying on the electronic 4567 signatures and selected by the signer for use with that relying party. 4568 Alternatively, a signature policy may be established through an 4569 electronic trading association for use amongst its members. Both the 4570 signer and verifier use the same signature policy. 4572 The signature policy may be explicitly identified or may be implied by 4573 the semantics of the data being signed and other external data like a 4574 contract being referenced which itself refers to a signature policy. 4575 An explicit signature policy has a globally unique reference, which is 4576 bound to an electronic signature by the signer as part of the signature 4577 calculation. 4579 The signature policy needs to be available in human readable form so 4580 that it can be assessed to meet the requirements of the legal and 4581 contractual context in which it is being applied. To facilitate the 4582 automatic processing of an electronic signature the parts of the 4583 signature policy which specifies the electronic rules for the creation 4584 and validation of the electronic signature also needs to be 4585 comprehensively defined and in a computer processable form. 4587 The signature policy thus includes the following: 4589 - rules, which apply to technical validation of a particular 4590 signature; 4592 - rules which may be implied through adoption of Certificate 4593 Policies that apply to the electronic signature (e.g. rules for 4594 ensuring the secrecy of the private signing key); 4596 - rules, which relate to the environment used by the signer, e.g. 4597 the use of an agreed CAD (Card Accepting Device) used in 4598 conjunction with a smart card. 4600 For example, the major rules required for technical validation can 4601 include: recognized root keys or "top-level certification authorities", 4602 acceptable certificate policies (if any), necessary certificate 4603 extensions and values (if any), the need for the revocation status for 4604 each component of the certification tree, acceptable TSAs (if time- 4605 stamp tokens are being used), acceptable organizations for keeping the 4606 audit trails with time-marks (if time-marking is being used), 4607 acceptable AAs (if any are being used).as well as rules defining the 4608 components of the electronic signature that shall be provided by the 4609 signer with data required by the verifier when required to provide long 4610 term proof. 4612 C.2 Signed information 4614 The information being signed may be defined as a MIME-encapsulated 4615 message which can be used to signal the format of the content in order 4616 to select the right display or application. It can be composed of 4617 formatted data, free text or fields from an electronic form (e-form). 4618 For example, the Adobe(tm) format "pdf" may be used or the eXtensible Mark 4619 up Language (XML). Annex D defines how the content may be structured 4620 to indicate the type of signed data using MIME. 4622 C.3 Components of an electronic signature 4624 C.3.1 Reference to the signature policy 4626 When two independent parties want to evaluate an electronic signature, 4627 it is fundamental that they get the same result. This requirement can 4628 be met using comprehensive signature policies that ensure consistency 4629 of signature validation. Signature policies can be identified 4630 implicitly by the data being signed or they can be explicitly 4631 identified using the CAdES-EPES form of electronic signature, the 4632 CAdES-EPES mandates a consistent signature policy must be used by both 4633 the signer and verifier. 4635 By signing over the signature policy identifier in the CAdES-EPES the 4636 signer explicitly indicates that he or she has applied the signature 4637 policy in creating the signature. 4639 In order to unambiguously identify the details of an explicit signature 4640 policy that is to be used to verify a CAdES-EPES the signature an 4641 identifier and hash of the "Signature policy" shall be part of the 4642 signed data. Additional information about the explicit policy (e.g. 4643 web reference to the document) may be carried as "qualifiers" to the 4644 signature policy identifier. 4646 In order to unambiguously identify the authority responsible for 4647 defining an explicit signature policy the "Signature policy" can be 4648 signed. 4650 C.3.2 Commitment type indication 4652 The commitment type can be indicated in the electronic signature 4653 either: 4655 - explicitly using a "commitment type indication" in the electronic 4656 signature; 4658 - implicitly or explicitly from the semantics of the signed data. 4660 If the indicated commitment type is explicit using a "commitment type 4661 indication" in the electronic signature, acceptance of a verified 4662 signature implies acceptance of the semantics of that commitment type. 4663 The semantics of explicit commitment types indications may be subject 4664 to signer and verifier agreement, specified as part of the signature 4665 policy or registered for generic use across multiple policies. 4667 If a CAdES-EPES electronic signature format is used and the electronic 4668 signature includes a commitment type indication other than one of those 4669 recognized under the signature policy the signature shall be treated as 4670 invalid. 4672 How commitment is indicated using the semantics of the data being 4673 signed is outside the scope of the present document. 4675 NOTE: Examples of commitment indicated through the semantics of the 4676 data being signed, are: 4678 - an explicit commitment made by the signer indicated by the type 4679 of data being signed over. Thus, the data structure being signed 4680 can have an explicit commitment within the context of the 4681 application (e.g. EDIFACT purchase order); 4683 - an implicit commitment which is a commitment made by the signer 4684 because the data being signed over has specific semantics 4685 (meaning) which is only interpretable by humans, (i.e. free 4686 text). 4688 C.3.3 Certificate identifier from the signer 4690 In many real life environments users will be able to get from different 4691 CAs or even from the same CA, different certificates containing the 4692 same public key for different names. The prime advantage is that a 4693 user can use the same private key for different purposes. Multiple use 4694 of the private key is an advantage when a smart card is used to protect 4695 the private key, since the storage of a smart card is always limited. 4696 When several CAs are involved, each different certificate may contain a 4697 different identity, e.g. as a national or as an employee from a 4698 company. Thus when a private key is used for various purposes, the 4699 certificate is needed to clarify the context in which the private key 4700 was used when generating the signature. Where there is the possibility 4701 of multiple use of private keys it is necessary for the signer to 4702 indicate to the verifier the precise certificate to be used. 4704 Many current schemes simply add the certificate after the signed data 4705 and thus are vulnerable to substitution attacks. If the certificate 4706 from the signer was simply appended to the signature and thus not 4707 protected by the signature, any one could substitute one certificate by 4708 another and the message would appear to be signed by some one else. In 4709 order to counter this kind of attack, the identifier of the signer has 4710 to be protected by the digital signature from the signer. 4712 In order to identify unambiguously the certificate to be used for the 4713 verification of the signature an identifier of the certificate from the 4714 signer shall be part of the signed data. 4716 C.3.4 Role attributes 4718 While the name of the signer is important, the position of the signer 4719 within a company or an organization of paramount importance as well. 4720 Some information (i.e. a contract) may only be valid if signed by a 4721 user in a particular role, e.g. a Sales Director. In many cases who 4722 the sales Director really is, is not that important but being sure that 4723 the signer is empowered by his company to be the Sales Director is 4724 fundamental. 4726 The present document defines two different ways for providing this 4727 feature: 4729 - by placing a claimed role name in the CMS signed attributes 4730 field; 4732 - by placing an attribute certificate containing a certified role 4733 name in the CMS signed attributes field. 4735 NOTE: Another possible approach would have been to use additional 4736 attributes containing the roles name(s) in the signer's 4737 identity certificate However, it was decided not to follow 4738 this approach as it significantly complicates the management 4739 of certificates. For example by using separate certificates 4740 for signer's identity and roles means new identity keys need 4741 not be issued if a user's role changes. 4743 C.3.4.1 Claimed role 4745 The signer may be trusted to state his own role without any certificate 4746 to corroborate this claim. In which case the claimed role can be added 4747 to the signature as a signed attribute. 4749 C.3.4.2 Certified role 4751 Unlike public key certificates that bind an identifier to a public key, 4752 Attribute Certificates bind the identifier of a certificate to some 4753 attributes, like a role. An Attribute Certificate is NOT issued by a 4754 CA but by an Attribute Authority (AA). The Attribute Authority in most 4755 cases might be under the control of an organization or a company that 4756 is best placed to know which attributes are relevant for which 4757 individual. The Attribute Authority may use or point to public key 4758 certificates issued by any CA, provided that the appropriate trust may 4759 be placed in that CA. Attribute Certificates may have various periods 4760 of validity. That period may be quite short, e.g. one day. While this 4761 requires that a new Attribute Certificate be obtained every day, valid 4762 for that day, this can be advantageous since revocation of such 4763 certificates may not be needed. When signing, the signer will have to 4764 specify which Attribute Certificate it selects. In order to do so, the 4765 Attribute Certificate will have to be included in the signed data in 4766 order to be protected by the digital signature from the signer. 4768 In order to identify unambiguously the attribute certificate(s) to be 4769 used for the verification of the signature an identifier of the 4770 attribute certificate(s) from the signer shall be part of the signed 4771 data. 4773 C.3.5 Signer location 4775 In some transactions the purported location of the signer at the time 4776 he or she applies his signature may need to be indicated. For this 4777 reason an optional location indicator shall be able to be included. 4779 In order to provide indication of the location of the signer at the 4780 time he or she applied his signature a location attribute may be 4781 included in the signature. 4782 C.3.6 Signing time 4784 The present document provides the capability to include a claimed 4785 signing time as an attribute of an electronic signature. 4787 Using this attribute a signer may sign over a time which is the claimed 4788 signing time. When an ES with Time-stamp is created (CAdES-T) then 4789 either a trusted time stamp is obtained and added to the ES or a 4790 trusted time mark exists in an audit trail. When a verifier accepts a 4791 signature, the two times shall be within acceptable limits. In all 4792 cases, the claimed signing time cannot be after the time identified by 4793 the time-stamp or time-mark. 4795 A further optional attribute is defined in the present document to 4796 timestamp the content, to provide proof of the existence of the 4797 content, at the time indicated by the time-stamp token. 4799 Using this optional attribute a trusted secure time may be obtained 4800 before the document is signed and included under the digital signature. 4801 This solution requires an on-line connection to a trusted time-stamping 4802 service before generating the signature and may not represent the 4803 precise signing time, since it can be obtained in advance. However, 4804 this optional attribute may be used by the signer to prove that the 4805 signed object existed before the date included in the time-stamp (see 4806 clause 5.11.4). 4808 Also, the signing time, if present should be between the time indicated 4809 by this time-stamp and time indicated by the CAdES-T time-stamp. 4811 C.3.7 Content format 4813 When presenting signed data to a human user it may be important that 4814 there is no ambiguity as to the presentation of the signed information 4815 to the relying party. In order for the appropriate representation 4816 (text, sound or video) to be selected by the relying party a content 4817 hint may be indicated by the signer. If a relying party system does 4818 not use the format specified in the content hints attribute to present 4819 the data to the relying party, then a human relying party may 4820 misinterpret data with valid signatures. 4822 C.3.8 Content cross referencing 4824 When presenting a signed data is in related to another signed data, it 4825 may be important to identify the signed data to which it relates to. 4826 The Content-reference and Content-identifier attributes as defined in 4827 ESS (RFC 2634 [5]) provide the ability to link a request and reply 4828 messages in an exchange between two parties. 4830 C.4 Components of validation data 4832 C.4.1 Revocation status information 4834 A verifier will have to ascertain that the certificate of the signer 4835 was valid at the time of the signature. This can be done by either: 4837 - using Certificate Revocation Lists (CRLs); 4839 - using responses from an on-line certificate status server (for 4840 example; obtained through the OCSP protocol). 4842 NOTE 1: The time of the signature may not be know, so time-stamping 4843 or time-marking may be used to provide the time indication of 4844 when it was known the signature existed. 4846 NOTE 2: When validating an electronic signature and checking 4847 revocation status information a "grace period" is required 4848 which needs to be suitably long enough to allow the involved 4849 authority to process a "last minute" revocation request and 4850 for the request to propagate through the revocation system. 4851 This grace period is to be added to the time included with the 4852 timestamp token or the time mark and thus the revocation 4853 status information should be captured after the end of the 4854 grace period. 4856 C.4.1.1 CRL information 4858 When using CRLs to get revocation information, a verifier will have to 4859 make sure that he or she gets at the time of the first verification the 4860 appropriate certificate revocation information from the signer's CA. 4861 This should be done as soon as possible to minimize the time delay 4862 between the generation and verification of the signature. However, a 4863 "grace period" is required to allow CAs time to process revocation 4864 requests. 4866 For example, a revocation request may arrive at a CA just before 4867 issuing the next CRL and there may not enough time to include the 4868 revised revocation status information. This involves checking that the 4869 signer certificate serial number is not included in the CRL. The 4870 signer, the initial or subsequent verifier may obtain either this CRL. 4871 If obtained by the signer, then it shall be conveyed to the verifier. 4872 It may be convenient to archive the CRL for ease of subsequent 4873 verification or arbitration. Alternatively, provided the CRL is 4874 archived elsewhere which is accessible for the purpose of arbitration, 4875 then the serial number of the CRL used may be archived together with 4876 the verified electronic signature as an CAdES-C form. 4878 Even if the certificate serial number appears in the CRL with the 4879 status "suspended" (i.e. on hold), the signature is not to be deemed as 4880 valid since a suspended certificate is not supposed to be used even by 4881 its rightful owner. 4883 C.4.1.2 OCSP information 4885 When using OCSP to get revocation information, a verifier will have to 4886 make sure that he or she gets at the time of the first verification an 4887 OCSP response that contains the status "valid". This should be done as 4888 soon as possible after the generation of the signature, still providing 4889 a "grace period" suitable enough to allow the involved authority to 4890 process a "last minute" revocation request The signer, the verifier or 4891 any other third party may fetch this OCSP response. Since OCSP 4892 responses are transient and thus are not archived by any TSP including 4893 CA, it is the responsibility of every verifier to make sure that it is 4894 stored in a safe place. The simplest way is to store them associated 4895 with the electronic signature. An alternative would be to store them 4896 in some storage so that they can then be easily retrieved, and 4897 incorporate references to them in the electronic signature itself as an 4898 CAdES-C form. 4900 In the same way as for the case of the CRL, it may happen that the 4901 certificate is declared as invalid but with the secondary status 4902 "suspended". In such a case, same comment as for CRL applies. 4904 C.4.2 Certification path 4906 A verifier may have to ascertain that the certification path was valid, 4907 at the time of the signature, up to a trust point according to the: 4909 - naming constraints; 4910 - certificate policy constraints; 4911 - Signature Policy, when applicable. 4913 Since the time of the signature cannot be known with certainty, an 4914 upper limit of it should be used as indicated by either the time stamp 4915 or time mark. 4917 In this case it will be necessary to capture all the certificates from 4918 the certification path, starting with those from the signer and ending 4919 up with those of the self-signed certificate from one trusted root, 4920 when applicable this may be specified as part of the Signature Policy. 4921 In addition, it will be necessary to capture the Certificate Authority 4922 Revocation Lists (CARLs) to prove than none of the CAs from the chain 4923 was revoked at the time of the signature. Again, all this material may 4924 be incorporated in the electronic signature (ES X forms). An 4925 alternative would be to store it in some storage so that they can it be 4926 easily retrieved, and incorporate references to it in the electronic 4927 signature itself as an CAdES-C form. 4929 C.4.3 Time-stamping for long life of signatures 4931 An important property for long standing signatures is that a signature, 4932 having been found once to be valid, shall continue to be so months or 4933 years later. 4935 A signer, verifier or both may be required to provide on request, proof 4936 that a digital signature was created or verified during the validity 4937 period of the all the certificates that make up the certificate path. 4938 In this case, the signer, verifier or both will also be required to 4939 provide proof that the signer's certificate and all the CA certificates 4940 used to form a valid certification path were not revoked when the 4941 signature was created or verified. 4943 It would be quite unacceptable, to consider a signature as invalid even 4944 if the keys or certificates were later compromised. Thus there is a 4945 need to be able to demonstrate that the signature keys was valid at the 4946 time that the signature was created to provide long term evidence of 4947 the validity of a signature. 4949 It could be the case that a certificate was valid at the time of the 4950 signature but revoked some time later. In this event, evidence shall 4951 be provided that the document was signed before the signing key was 4952 revoked. Time-stamping by a Time-Stamping Authority (TSA) can provide 4953 such evidence. A time stamp is obtained by sending the hash value of 4954 the given data to the TSA. The returned "time-stamp" is a signed 4955 document that contains the hash value, the identity of the TSA, and the 4956 time of stamping. This proves that the given data existed before the 4957 time of stamping. Time-stamping a digital signature (by sending a hash 4958 of the signature to the TSA) before the revocation of the signer's 4959 private key, provides evidence that the signature has been created 4960 before the key was revoked. 4962 If a recipient wants to hold a valid electronic signature he will have 4963 to ensure that he has obtained a valid time stamp for it, before that 4964 key (and any key involved in the validation) is revoked. The sooner 4965 the time-stamp is obtained after the signing time, the better. Any 4966 time stamp or time mark that is taken after the expiration date of any 4967 certificate in the certification path has no value in proving the 4968 validity of a signature. 4970 It is important to note that signatures may be generated "off-line" and 4971 time-stamped at a later time by anyone, for example by the signer or 4972 any recipient interested in the value of the signature. The time stamp 4973 can thus be provided by the signer together with the signed document, 4974 or obtained by the recipient following receipt of the signed document. 4976 The time stamp is NOT a component of the Basic Electronic Signature, 4977 but the essential component of the ES with Time-stamp. 4979 It is required in the present document that if a signer's digital 4980 signature value is to be time-stamped, the Time-Stamp Token is issued 4981 by a trusted source, known as a Time-stamping Authority. 4983 The present document requires that the signer's digital signature value 4984 is time-stamped by a trusted source before the electronic signature can 4985 become an ES with Complete validation data. Acceptable TSAs may be 4986 specified in a Signature Validation Policy. 4988 This technique is referred to as CAdES-C in the present document. 4989 Should both the signer and verifier be required to time-stamp the 4990 signature value to meet the requirements of the signature policy, the 4991 signature policy MAY specify a permitted time delay between the two 4992 time stamps. 4994 C.4.4 Time-stamping for long life of signature before CA key 4995 compromises 4997 Time-stamped extended electronic signatures are needed when there is a 4998 requirement to safeguard against the possibility of a CA key in the 4999 certificate chain ever being compromised. A verifier may be required 5000 to provide on request, proof that the certification path and the 5001 revocation information used a the time of the signature were valid, 5002 even in the case where one of the issuing keys or OCSP responder keys 5003 is later compromised. 5005 The present document defines two ways of using time-stamps to protect 5006 against this compromise: 5008 - time-stamp the ES with Complete validation data, when an OCSP 5009 response is used to get the status of the certificate from the 5010 signer (CAdES-X Type 1). This format is suitable to be used with 5011 an OCSP response and offers the additional advantage to provide 5012 an integrity protection over the whole data; 5014 - time-stamp only the certification path and revocation information 5015 references when a CRL is used to get the status of the 5016 certificate from the signer (CAdES-X Type2). This format is 5017 suitable to be used with CRLs, since the time-stamped information 5018 may be used for more than one signature (when signers have their 5019 certificates issued by the same CA and when signatures can be 5020 checked using the same CRLs). 5022 NOTE: The signer, verifier or both may obtain the time-stamp. 5024 C.4.4.1 Time-stamping the ES with complete validation data 5025 (CAdES-X Type 1) 5027 When an OCSP response is used, it is necessary to time stamp in 5028 particular that response in the case the key from the responder would 5029 be compromised. Since the information contained in the OCSP response 5030 is user specific and time specific, an individual time stamp is needed 5031 for every signature received. Instead of placing the time stamp only 5032 over the certification path references and the revocation information 5033 references, which include the OCSP response, the time stamp is placed 5034 on the CAdES-C. Since the certification path and revocation 5035 information references are included in the ES with Complete validation 5036 data they are also protected. For the same cryptographic price, this 5037 provides an integrity mechanism over the ES with Complete validation 5038 data. Any modification can be immediately detected. It should be 5039 noticed that other means of protecting/detecting the integrity of the 5040 ES with Complete Validation Data exist and could be used. 5041 Although the technique requires a time stamp for every signature, it is 5042 well suited for individual users wishing to have an integrity protected 5043 copy of all the validated signatures they have received. 5045 By time-stamping the complete electronic signature, including the 5046 digital signature as well as the references to the certificates and 5047 revocation status information used to support validation of that 5048 signature, the time-stamp ensures that there is no ambiguity in the 5049 means of validating that signature. 5051 This technique is referred to as CAdES-X Type 1 in the present 5052 document. 5054 NOTE: Trust is achieved in the references by including a hash of the 5055 data being referenced. 5057 If it is desired for any reason to keep a copy of the additional data 5058 being referenced, the additional data may be attached to the electronic 5059 signature, in which case the electronic signature becomes an CAdES-X 5060 Long Type 1 as defined by the present document. 5062 An CAdES-X Long Type 1 is simply the concatenation of an CAdES-X Type 1 5063 with a copy of the additional data being referenced. 5065 C.4.4.2 Time-stamping certificates and revocation information 5066 references (CAdES-X Type 2) 5068 Time-stamping each ES with Complete Validation Data as defined above 5069 may not be efficient, particularly when the same set of CA certificates 5070 and CRL information is used to validate many signatures. 5072 Time-stamping CA certificates will stop any attacker from issuing bogus 5073 CA certificates that could be claimed to exist before the CA key was 5074 compromised. Any bogus time-stamped CA certificates will show that the 5075 certificate was created after the legitimate CA key was compromised. 5076 In the same way, time-stamping CA CRLs, will stop any attacker from 5077 issuing bogus CA CRLs which could be claimed to exist before the CA key 5078 was compromised. 5080 Time-stamping of commonly used certificates and CRLs can be done 5081 centrally, e.g. inside a company or by a service provider. This method 5082 reduces the amount of data the verifier has to time-stamp, for example 5083 it could reduce to just one time stamp per day (i.e. in the case were 5084 all the signers use the same CA and the CRL applies for the whole day). 5085 The information that needs to be time stamped is not the actual 5086 certificates and CRLs but the unambiguous references to those 5087 certificates and CRLs. 5089 This technique is referred to as CAdES-X Type 2 in the present document 5090 and requires the following: 5092 - all the CA certificates references and revocation information 5093 references (i.e. CRLs) used in validating the CAdES-C are covered 5094 by one or more time-stamp. 5096 Thus an CAdES-C with a time-stamp signature value at time T1, can be 5097 proved valid if all the CA and CRL references are time-stamped at time 5098 T1+. 5100 C.4.5 Time-stamping for archive of signature 5102 Advances in computing increase the probability of being able to break 5103 algorithms and compromise keys. There is therefore a requirement to be 5104 able to protect electronic signatures against this possibility. 5106 Over a period of time weaknesses may occur in the cryptographic 5107 algorithms used to create an electronic signature (e.g. due to the time 5108 available for crypto analysis, or improvements in crypto analytical 5109 techniques). Before such weaknesses become likely, a verifier should 5110 take extra measures to maintain the validity of the electronic 5111 signature. Several techniques could be used to achieve this goal 5112 depending on the nature of the weakened cryptography. In order to 5113 simplify matters, a single technique, called Archive validation data, 5114 covering all the cases is being used in the present document. 5116 Archive validation data consists of the validation data and the 5117 complete certificate and revocation data, time stamped together with 5118 the electronic signature. The Archive validation data is necessary if 5119 the hash function and the crypto algorithms that were used to create 5120 the signature are no longer secure. Also, if it cannot be assumed that 5121 the hash function used by the Time Stamping Authority is secure, then 5122 nested time-stamps of Archived Electronic Signature are required. 5124 The potential for Trusted Service Provider (TSP) key compromise should 5125 be significantly lower than user keys, because TSP(s) are expected to 5126 use stronger cryptography and better key protection. It can be 5127 expected that new algorithms (or old ones with greater key lengths) 5128 will be used. In such a case, a sequence of time-stamps will protect 5129 against forgery. Each time-stamp needs to be affixed before either the 5130 compromise of the signing key or of the cracking of the algorithms used 5131 by the TSA. TSAs (Time-stamping Authorities) should have long keys 5132 (e.g. which at the time of drafting the present document was at least 5133 2048 bits for the signing RSA algorithm) and/or a "good" or different 5134 algorithm. 5136 Nested time-stamps will also protect the verifier against key 5137 compromise or cracking the algorithm on the old electronic signatures. 5139 The process will need to be performed and iterated before the 5140 cryptographic algorithms used for generating the previous time stamp 5141 are no longer secure. Archive validation data may thus bear multiple 5142 embedded time stamps. 5144 This technique is referred to as CAdES-A in the present document. 5146 C.4.6 Reference to additional data 5148 Using CAdES-X Type 1 or CAdES-X Type 2 extended validation data 5149 verifiers still needs to keep track of all the components that were 5150 used to validate the signature, in order to be able to retrieve them 5151 again later on. These components may be archived by an external source 5152 like a trusted service provider, in which case referenced information 5153 that is provided as part of the ES with Complete validation data 5154 (CAdES-C) is adequate. The actual certificates and CRL information 5155 reference in the CAdES-C can be gathered when needed for arbitration. 5157 If references to additional data are not adequate, then the actual 5158 values of all the certificates and revocation information required may 5159 be part of the electronic signature. This technique is referred to as 5160 CAdES-X Long Type 1 or CAdES-X Long Type 2 in the present document. 5162 C.4.7 Time-stamping for mutual recognition 5164 In some business scenarios both the signer and the verifier need to 5165 time-stamp their own copy of the signature value. Ideally the two 5166 time-stamps should be as close as possible to each other. 5168 EXAMPLE: A contract is signed by two parties A and B representing 5169 their respective organizations, to time-stamp the signer 5170 and verifier data two approaches are possible: 5172 - under the terms of the contract pre-defined common 5173 "trusted" TSA may be used; 5175 - if both organizations run their own time-stamping 5176 services, A and B can have the transaction 5177 time-stamped by these two time-stamping services. 5179 In the latter case, the electronic signature will only be considered as 5180 valid, if both time-stamps were obtained in due time (i.e. there should 5181 not be a long delay between obtaining the two time-stamps). Thus, 5182 neither A nor B can repudiate the signing time indicated by their own 5183 time-stamping service. Therefore, A and B do not need to agree on a 5184 common "trusted" TSA to get a valid transaction. 5186 It is important to note that signatures may be generated "off-line" and 5187 time-stamped at a later time by anyone, e.g. by the signer or any 5188 recipient interested in validating the signature. The time-stamp over 5189 the signature from the signer can thus be provided by the signer 5190 together with the signed document, and/or obtained by the verifier 5191 following receipt of the signed document. 5193 The business scenarios may thus dictate that one or more of the long- 5194 term signature time-stamping methods describe above be used. This may 5195 be part of a mutually agreed Signature Validation Policy which is part 5196 of an agreed signature policy under which digital signature may be used 5197 to support the business relationship between the two parties. 5199 C.4.8 TSA key compromise 5201 TSA servers should be built in such a way that once the private 5202 signature key is installed, there is minimal likelihood of compromise 5203 over as long as possible period. Thus the validity period for the 5204 TSA's keys should be as long as possible. 5206 Both the CAdES-T and the CAdES-C contain at least one time stamp over 5207 the signer's signature. In order to protect against the compromise of 5208 the private signature key used to produce that time-stamp, the Archive 5209 validation data can be used when a different Time-Stamping Authority 5210 key is involved to produce the additional time-stamp. If it is 5211 believed that the TSA key used in providing an earlier time-stamp may 5212 ever be compromised (e.g. outside its validity period), then the CAdES- 5213 A should be used. For extremely long periods this may be applied 5214 repeatedly using new TSA keys. 5216 This technique is referred to as a nested CAdES-A in the present 5217 document. 5219 C.5 Multiple signatures 5221 Some electronic signatures may only be valid if they bear more than one 5222 signature. This is the case generally when a contract is signed 5223 between two parties. The ordering of the signatures may or may not be 5224 important, i.e. one may or may not need to be applied before the other. 5226 Several forms of multiple and counter signatures need to be supported, 5227 which fall into two basic categories: 5229 - independent signatures; 5230 - embedded signatures. 5232 Independent signatures are parallel signatures where the ordering of 5233 the signatures is not important. The capability to have more than one 5234 independent signature over the same data shall be provided. 5236 Embedded signatures are applied one after the other and are used where 5237 the order the signatures are applied is important. The capability to 5238 sign over signed data shall be provided. 5240 These forms are described in clause 5.13. All other multiple signature 5241 schemes, e.g. a signed document with a countersignature, double 5242 countersignatures or multiple signatures, can be reduced to one or more 5243 occurrence of the above two cases. 5245 Annex D (informative):Data protocols to interoperate with TSPs 5247 D.1 Operational protocols 5249 The following protocols can be used by signers and verifiers to 5250 interoperate with Trusted Service Providers during the electronic 5251 signature creation and validation. 5253 D.1.1 Certificate retrieval 5255 User certificates, CA certificate and cross-certificates can be 5256 retrieved from a repository using the Lightweight Directory Access 5257 Protocol as defined in as defined RFC 2559 (see informative 5258 references), with the schema defined in RFC 2587 (see informative 5259 references). 5261 D.1.2 CRL retrieval 5263 Certificate revocation lists, including authority revocation lists and 5264 partial CRL variants, can be retrieved from a repository using the 5265 Lightweight Directory Access Protocol as defined in RFC 2559 (see 5266 informative references), with the schema defined in RFC 2587 (see 5267 informative references). 5269 D.1.3 OnLine certificate status 5271 As an alternative to use of certificate revocation lists the status of 5272 certificate can be checked using the OnLine Certificate Status Protocol 5273 (OCSP) as defined in RFC 2560 [3]. 5275 D.1.4 Time-stamping 5277 The time-stamping service can be accessed using the Time-Stamping 5278 Protocol defined in RFC 3161 [7]. 5280 D.2 Management protocols 5282 Signers and verifiers can use the following management protocols to 5283 manage the use of certificates. 5285 D.2.1 Request for certificate revocation 5287 Request for a certificate to be revoked can be made using the 5288 revocation request and response messages defined in 5289 RFC 2510 (see informative references). 5291 Annex E (informative): Guidance on naming 5293 E.1 Allocation of names 5295 The subject name shall be allocated through a registration scheme 5296 administered through a Registration Authority (RA) to ensure 5297 uniqueness. This RA may be an independent body or a function carried 5298 out by the Certification Authority. 5300 In addition to ensuring uniqueness, the RA shall verify that the name 5301 allocated properly identifies the applicant and that authentication 5302 checks are carried out to protect against masquerade. 5304 The name allocated by an RA is based on registration information 5305 provided by, or relating to, the applicant (e.g. his personal name, 5306 date of birth, residence address) and information allocated by the RA. 5307 Three variations commonly exist: 5309 - the name is based entirely on registration information which 5310 uniquely identifies the applicant (e.g. "Pierre Durand (born on) 5311 July 6, 1956"); 5313 - the name is based on registration information with the addition 5314 of qualifiers added by the registration authority to ensure 5315 uniqueness (e.g. "Pierre Durand 12"); 5317 - the registration information is kept private by the registration 5318 authority and the registration authority allocates a "pseudonym". 5320 E.2 Providing access to registration information 5322 Under certain circumstances it may be necessary for information used 5323 during registration, but not published in the certificate, to be made 5324 available to third parties (e.g. to an arbitrator to resolve a dispute 5325 or for law enforcement). This registration information is likely to 5326 include personal and sensitive information. 5328 Thus the RA needs to establish a policy for: 5330 - whether the registration information should be disclosed; 5331 - to whom such information should be disclosed; 5332 - under what circumstances such information should be disclosed. 5334 This policy may be different whether the RA is being used only within a 5335 company or for public use. The policy will have to take into account 5336 national legislation and in particular any data protection and privacy 5337 legislation. 5339 Currently, the provision of access to registration is a local matter 5340 for the RA. However, if open access is required, standard protocols 5341 such as HTTP - RFC 2068 (Internet Web Access Protocol) may be employed 5342 with the addition of security mechanisms necessary to meet the data 5343 protection requirements (e.g. Transport Layer Security - RFC 2246 with 5344 client authentication). 5346 E.3 Naming schemes 5348 E.3.1 Naming schemes for individual citizens 5350 In some cases the subject name that is contained in a public key 5351 certificate may not be meaningful enough. This may happen because of 5352 the existence of homonyms or because of the use of pseudonyms. A 5353 distinction could be made if more attributes were present. However, 5354 adding more attributes to a public key certificate placed in a public 5355 repository would be going against the privacy protection requirements. 5357 In any case the Registration Authority will get information at the time 5358 of registration but not all that information will be placed in the 5359 certificate. In order to achieve a balance between these two opposite 5360 requirements the hash values of some additional attributes can be 5361 placed in a public key certificate. When the certificate owner 5362 provides these additional attributes, then they can be verified. Using 5363 biometrics attributes may unambiguously identify a person. Example of 5364 biometrics attributes that can be used include: a picture or a manual 5365 signature from the certificate owner. 5367 NOTE: Using hash values protects privacy only if the possible inputs 5368 are large enough. For example, using the hash of a person's 5369 social security number is generally not sufficient since it 5370 can easily be reversed. 5372 A picture can be used if the verifier once met the person and later on 5373 wants to verify that the certificate that he or she got relates to the 5374 person whom was met. In such a case, at the first exchange the picture 5375 is sent and the hash contained in the certificate may be used by the 5376 verifier to verify that it is the right person. At the next exchange 5377 the picture does not need to be sent again. 5379 A manual signature may be used if a signed document has been received 5380 beforehand. In such a case, at the first exchange the drawing of the 5381 manual signature is sent and the hash contained in the certificate may 5382 be used by the verifier to verify that it is the right manual 5383 signature. At the next exchange the manual signature does not need to 5384 be sent again. 5386 E.3.2 Naming schemes for employees of an organization 5388 The name of an employee within an organization is likely to be some 5389 combination of the name of the organization and the identifier of the 5390 employee within that organization. 5392 An organization name is usually a registered name, i.e. business or 5393 trading name used in day to day business. This name is registered by a 5394 Naming Authority, which guarantees that the organization's registered 5395 name is unambiguous and cannot be confused with another organization. 5396 In order to get more information about a given registered organization 5397 name, it is necessary to go back to a publicly available directory 5398 maintained by the Naming Authority. 5400 The identifier may be a name or a pseudonym (e.g. a nickname or a 5401 employee number). When it is a name, it is supposed to be descriptive 5402 enough to unambiguously identify the person. When it is a pseudonym, 5403 the certificate does not disclose the identity of the person. However 5404 it ensures that the person has been correctly authenticated at the time 5405 of registration and therefore may be eligible to some advantages 5406 implicitly or explicitly obtained through the possession of the 5407 certificate. In either case, however, this can be insufficient because 5408 of the existence of homonyms. 5410 Placing more attributes in the certificate may be one solution, for 5411 example by giving the organization unit of the person or the name of a 5412 city where the office is located. However the more information is 5413 placed in the certificate the more problems arise if there is a change 5414 in the organization structure or the place of work. So this may not be 5415 the best solution. An alternative is to provide more attributes (like 5416 the organization unit and the place of work) through access to a 5417 directory maintained by the company. It is likely that at the time of 5418 registration the Registration Authority got more information than what 5419 was placed in the certificate, if such additional information is placed 5420 in a repository accessible only to the organization. 5422 Annex F (informative): Example structured contents and MIME 5424 F.1 General description 5426 The signed content may be structured as using MIME (Multipurpose 5427 Internet Mail Extensions - RFC 2045 [6]. Whilst the MIME structure was 5428 initially developed for Internet e-mail, it has a number of features 5429 which make it useful to provide a common structure for encoding a range 5430 of electronic documents and other multi-media data (e.g. photographs, 5431 video). These features include: 5433 - it provides a means of signalling the type of "object" being 5434 carried (e.g. text, image, ZIP file, application data); 5436 - it provides a means of associating a file name with an object; 5438 - it can associate several independent "objects" (e.g. a document 5439 and image) to form a multi-part object; 5441 - it can handle data encoded in text or binary and, if necessary, 5442 re-encode the binary as text. 5444 When encoding a single object MIME consists of: 5446 - header information, followed by; 5447 - encoded content. 5449 This structure can be extended to support multi-part content. 5451 F.2 Header information 5453 A MIME header includes: 5455 MIME Version information: 5456 e.g.: MIME-Version: 1.0 5458 Content type information which includes information describing the 5459 content sufficient for it to presented to a user or application process 5460 as required. This includes information on the "media type" (e.g. text, 5461 image, audio) or whether the data is for passing to a particular type 5462 of application. In the case of text the content type includes 5463 information on the character set used. 5465 e.g. Content-Type: text/plain; charset="us-ascii" 5467 Content encoding information, which defines how the content is encoded. 5468 (See below about encoding supported by MIME). 5470 Other information about the content such as a description, or an 5471 associated file name. 5473 An example MIME header for text object is: 5475 Mime-Version: 1.0 5476 Content-Type: text/plain; charset=ISO-8859-1 5477 Content-Transfer-Encoding: quoted-printable 5479 An example MIME header for a binary file containing a word document is: 5481 Content-Type: application/octet-stream 5482 Content-Transfer-Encoding: base64 5483 Content-Description: JCFV201.doc (Microsoft Word Document) 5484 Content-Disposition: filename="JCFV201.doc" 5486 F.3 Content encoding 5488 MIME supports a range of mechanisms for encoding the both text and 5489 binary data. 5491 Text data can be carried transparently as lines of text data encoded in 5492 7 or 8 bit ASCII characters. MIME also includes a "quoted-printable" 5493 encoding which converts characters other than the basic ASCII into an 5494 ASCII sequence. 5496 Binary can either be carried: 5498 - transparently a 8 bit octets; or 5499 - converted to a basic set of characters using a system called 5500 Base64. 5502 NOTE: As there are some mail relays which can only handle 7 bit 5503 ASCII, Base64 encoding is usually used on the Internet. 5505 F.4 Multi-part content 5507 Several objects (e.g. text and a file attachment) can be associated 5508 together using a special "multi-part" content type. This is indicated 5509 by the content type "multipart" with an indication of the string to be 5510 used indicate a separation between each part. 5512 In addition to a header for the overall multipart content, each part 5513 includes its own header information indicating the inner content type 5514 and encoding. 5516 An example of a multipart content is: 5518 Mime-Version: 1.0 5519 Content-Type: multipart/mixed; boundary="---- 5520 =_NextPart_000_01BC4599.98004A80" 5521 Content-Transfer-Encoding: 7bit 5522 ------=_NextPart_000_01BC4599.98004A80 5523 Content-Type: text/plain; charset=ISO-8859-1 5524 Content-Transfer-Encoding: 7bit 5526 Per your request, I've attached our proposal for the Java Card Version 5527 2.0 API and the Java Card FAQ. 5529 ------=_NextPart_000_01BC4599.98004A80 5530 Content-Type: application/octet-stream; name="JCFV201.doc" 5531 Content-Transfer-Encoding: base64 5532 Content-Description: JCFV201.doc (Microsoft Word Document) 5533 Content-Disposition: attachment; filename="JCFV201.doc" 5535 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAgAAAAA 5536 AAAAAEAAAtAAAAAEAAAD+////AAAAAAMAAAAGAAAA////////////////////////////// 5537 //////////AANhAAQAYg== 5539 ------=_NextPart_000_01BC4599.98004A80-- 5541 Multipart content can be nested. So a set of associated objects (e.g. 5542 HTML text and images) can be handled as a single attachment to another 5543 object (e.g. text). 5545 F.5 S/MIME 5547 Previous clauses in this annex have described the use of MIME to encode 5548 data. MIME encoded data can be signed (i.e. carried in the eContent of 5549 the SignedData structure) thereby signalling the type of information 5550 that has been signed. 5552 MIME can also be used to encode the CMS structure containing data after 5553 it has been signed so that, for example, this can be carried within an 5554 e-mail message. The specific use of MIME to carry CMS (extended as 5555 defined in the present document) secured data is called S/MIME. The 5556 relationship between the general use of MIME for encoding content, CMS 5557 and S/MIME is illustrated in figure F.1. 5559 +------------++-------------++----------++------------++------------+ 5560 | || || || || | 5561 | E-mail || S/MIME || CAdES || MIME || Word file | 5562 | || || || || | 5563 |From: Smith ||Content Type=||SignedData||ContentType=||Dear MrSmith| 5564 |To:Jones ||application/ || Econtent ||application/||Received | 5565 |Subject: ||pkcs7 || ||octet-stream|| 100 tins | 5566 |Signed doc. || || || || | 5567 | /| || /| || /| || /| || Mr.Jones | 5568 | / -----+ / -----+ / -----+ / -----+ | 5569 | \ -----+ \ -----+ \ -----+ \ -----+ | 5570 | \| || \| || \| || \| || | 5571 | |+------------- | |+------------+| | 5572 +------------+ ++----------+ +------------+ 5574 Figure F.1 5576 S/MIME carries electronic signatures as either: 5578 - an "application/pkcs7-mime" object with the CMS carried as binary 5579 attachment (PKCS7 is the name of the early version of CMS). 5581 An example of signed data encoded using this approach is: 5582 Content-Type: application/pkcs7-mime; smime-type=signed-data; 5583 Content-Transfer-Encoding: base64 5584 Content-Disposition: attachment; filename=smime.p7m 5586 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 5587 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH 5588 HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 5589 6YT64V0GhIGfHfQbnj75 5591 This approach is similar to handling signed data as any other binary 5592 file attachment. Thus, this encoding can be used where signed data 5593 passes through gateways to other e-mail systems (e.g. those based on 5594 other e-mail systems). 5595 A "multipart/signed" object with the signed data and the signature 5596 encoded as separate MIME objects. 5598 An example of signed data encoded this approach is: 5599 Content-Type: multipart/signed; 5600 protocol="application/pkcs7-signature"; 5601 micalg=sha1; boundary=boundary42 5603 --boundary42 5604 Content-Type: text/plain 5606 This is a clear-signed message. 5608 --boundary42 5609 Content-Type: application/pkcs7-signature; name=smime.p7s 5610 Content-Transfer-Encoding: base64 5611 Content-Disposition: attachment; filename=smime.p7s 5613 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 5614 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj 5615 n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 5616 7GhIGfHfYT64VQbnj756 5618 --boundary42-- 5620 With this second approach MIME the signed data passes through the CMS 5621 process and is carried as part of the S/MIME structure as illustrated 5622 in figure F.2. The CMS structure just holds the electronic signature. 5624 +------------++-------------++----------++------------++------------+ 5625 | || || || || | 5626 | E-mail || | /MIME || CAdES || MIME || Word file | 5627 | || || || || | 5628 |From: Smith ||Content Type=||SignedData||ContentType=||Dear MrSmith| 5629 |To:Jones ||multipart/ || ||application/||Received | 5630 |Subject: ||signed || ||octet-stream|| 100 tins | 5631 |Signed doc. || /| || || || | 5632 | /| || / -----------------+ /| || Mr.Jones | 5633 | / -----+ \ -----------------+ / -----+ | 5634 | \ -----+ \| || || \ -----+ | 5635 | \| ||ContentType= || || \| || | 5636 +------------+|application/ || |+------------+| | 5637 |octet-stream || | +------------+ 5638 | || | 5639 |ContentType= || | 5640 |application/ || | 5641 |pkcs7- || | 5642 |signature || | 5643 | /| || | 5644 | / -----+ | 5645 | \ -----+ | 5646 | \| ||----------+ 5647 | | 5648 +-------------+ 5650 Figure F.2 5652 The second approach (multipart/signed) has the advantage that the 5653 signed data can be decoded by any MIME compatible e-mail system even if 5654 it does not recognize CMS encoded electronic signatures. However, this 5655 form cannot be used with other e-mail systems. 5657 Annex G (informative): Relationship to the European Directive and EESSI 5659 G.1 Introduction 5661 This annex provides an indication of the relationship between 5662 electronic signatures created under the present document and 5663 requirements under the European Parliament and Council Directive on a 5664 Community framework for electronic signatures. 5666 NOTE: Legal advice should be sought on the specific national 5667 legislation regarding use of electronic signatures. 5669 The present document is one of a set of standards being defined under 5670 the "European Electronic Signature Standardization Initiative" (EESSI) 5671 for electronic signature products and solutions compliant with the 5672 European Directive for electronic signatures. 5674 G.2 Electronic signatures and the directive 5676 This directive defines electronic signatures as: 5678 - "data in electronic form which are attached to or logically 5679 associated with other electronic data and which serve as a method 5680 of authentication". 5682 The directive states that an electronic signature should not be denied 5683 "legal effectiveness and admissibility as evidence in legal 5684 proceedings" solely on the grounds that it is in electronic form. 5686 The directive identifies an electronic signature as having equivalence 5687 to a hand-written signature if it meets specific criteria: 5689 - it is an "advanced electronic signature" with the following 5690 properties: 5692 a) it is uniquely linked to the signatory; 5694 b) it is capable of identifying the signatory; 5696 c) it is created using means that the signatory can maintain 5697 under his sole control; and 5699 d) it is linked to the data to which it relates in such a 5700 manner that any subsequent change of the data is detectable. 5702 - it is based on a certificate which meets detailed criteria given 5703 in annex I to the directive and is issued by a "certification- 5704 service-provider" which meets requirements given in annex II to 5705 the directive. Such a certificate is referred to as a "qualified 5706 certificate"; 5708 - it is created by a "device" which detailed criteria given in 5709 annex III to the directive. Such a device is referred to a 5710 "secure-signature-creation device"; 5712 This form of electronic signature is referred to as a "qualified 5713 electronic signature" in EESSI (see below). 5715 G.3 ETSI electronic signature formats and the directive 5716 An electronic signature created in accordance with the present document 5717 is: 5719 a) considered to be an "electronic signature" under the terms of 5720 the Directive; 5722 b) considered to be an "advanced electronic signature" under the 5723 terms of the Directive; 5725 c) considered to be a "Qualified Electronic Signature" provided the 5726 additional requirements in annex I, II and III of the Directive 5727 are met. The requirements in annex I, II and III of the 5728 Directive are outside the scope of the present document, and are 5729 subject to further standardization. 5731 G.4 EESSI standards and classes of electronic signature 5733 G.4.1 Structure of EESSI standardization 5735 EESSI looks at standards in several areas. See the ETSI ESI and CEN 5736 web sites for the latest list of standards and their versions 5738 - use of X.509 public key certificates as qualified certificates; 5740 - security Management and Certificate Policy for CSPs Issuing 5741 Qualified Certificates; 5743 - security requirements for trustworthy systems used by CSPs 5744 Issuing Qualified Certificates; 5746 - security requirements for Secure Signature Creation Devices; 5748 - security requirements for Signature Creation Systems; 5750 - procedures for Electronic Signature Verification; 5752 - electronic signature syntax and encoding formats; 5754 - protocol to interoperate with a Time Stamping Authority; 5756 - Policy requirements for Time-Stamping Authorities; 5758 - XML electronic signature formats. 5760 Each of these standards addresses a range of requirements including the 5761 requirements of Qualified Electronic Signatures as specified in article 5762 5.1 of the Directive. However, some of them also address general 5763 requirements of electronic signatures for business and electronic 5764 commerce which all fall into the category of article 5.2 of the 5765 Directive. Such variation in the requirements may be identified either 5766 as different levels or different options. 5768 G.4.2 Classes of electronic signatures 5770 Since some of these standards address a range of requirements, it may 5771 be useful to identify a set of standards to address a specific business 5772 need. Such a set of standards and their uses defines a class of 5773 electronic signature. The first class already identified is the 5774 qualified electronic signature, fulfilling the requirements of article 5775 5.1 of the Directive. 5777 A limited number of "classes of electronic signatures" and 5778 corresponding profiles could be defined by EESSI, in close co-operation 5779 with actors on the market (business, users, suppliers). Need for such 5780 standards is envisaged, in addition to those for qualified electronic 5781 signatures, in areas such as: 5783 - different classes of electronic signatures with long term 5784 validity; 5786 - electronic signatures for business transactions with limited 5787 value. 5789 G.4.3 EESSI classes and the ETSI electronic signature format 5790 The electronic signature format defined in the present document is 5791 applicable to the EESSI area "electronic signature and encoding 5792 formats". 5794 An electronic signature produced by a signer (see clause 5 and 5795 conformance clause 10.1) is applicable to the proposed class of 5796 electronic signature: "qualified electronic signatures fulfilling 5797 article 5.1". 5799 With the addition of validation data by the verifier (see clause 6 and 5800 conformance clause 10.2) this would become applicable electronic 5801 signatures adding long-term validity attributes to the qualified 5802 electronic signature. 5804 Annex H (informative):APIs for the generation and verification of 5805 electronic signatures tokens 5807 While the present document describes the data format of an electronic 5808 signature, the question is whether there exists APIs (Application 5809 Programming Interfaces) able to manipulate these structures. At least 5810 two such APIs have been defined. One set by the IETF and another set 5811 by the OMG (Object Management Group). 5813 H.1 Data framing 5815 In order to be able to use either of these APIs, it will be necessary 5816 to frame the previously defined electronic signature data structures 5817 using a mechanism-independent token format. Clause 3.1 of RFC 2743 5818 (see informative references) describes that framing incorporating an 5819 identifier of the mechanism type to be used and enabling tokens to be 5820 interpreted unambiguously. 5822 In order to be processable by these APIs, all electronic signature data 5823 formats that are defined in the present document shall be framed 5824 following that description. 5826 The encoding format for the token tag is derived from ASN.1 and DER, 5827 but its concrete representation is defined directly in terms of octets 5828 rather than at the ASN.1 level in order to facilitate interoperable 5829 implementation without use of general ASN.1 processing code. The token 5830 tag consists of the following elements, in order: 5832 1) 0x60 -- Tag for RFC 2743 SEQUENCE; indicates that constructed 5833 form, definite length encoding follows. 5835 2) Token length octets, specifying length of subsequent data (i.e. 5836 the summed lengths of elements 3 to 5 in this list, and of the 5837 mechanism-defined token object following the tag). This element 5838 comprises a variable number of octets: 5840 a) If the indicated value is less than 128, it shall be 5841 represented in a single octet with bit 8 (high order) set to 5842 "0" and the remaining bits representing the value. 5844 b) If the indicated value is 128 or more, it shall be represented 5845 in two or more octets, with bit 8 of the first octet set to 5846 "1" and the remaining bits of the first octet specifying the 5847 number of additional octets. The subsequent octets carry the 5848 value, 8 bits per octet, most significant digit first. The 5849 minimum number of octets shall be used to encode the length 5850 (i.e. no octets representing leading zeros shall be included 5851 within the length encoding). 5853 3) 0x06 -- Tag for OBJECT IDENTIFIER. 5855 4) Object identifier length -- length (number of octets) of the 5856 encoded object identifier contained in element 5, encoded per 5857 rules as described in 2a) and 2b) above. 5859 5) object identifier octets -- variable number of octets, encoded 5860 per ASN.1 BER rules: 5862 - The first octet contains the sum of two values: 5864 (1) the top-level object identifier component, multiplied by 5865 40 (decimal); and 5867 (2) the second-level object identifier component. 5869 This special case is the only point within an object 5870 identifier encoding where a single octet represents contents 5871 of more than one component. 5873 - Subsequent octets, if required, encode successively-lower 5874 components in the represented object identifier. A 5875 component's encoding may span multiple octets, encoding 7 bits 5876 per octet (most significant bits first) and with bit 8 set to 5877 "1" on all but the final octet in the component's encoding. 5878 The minimum number of octets shall be used to encode each 5879 component (i.e. no octets representing leading zeros shall be 5880 included within a component's encoding). 5882 NOTE: In many implementations, elements 3 to 5 may be stored and 5883 referenced as a contiguous string constant. 5885 The token tag is immediately followed by a mechanism-defined token 5886 object. Note that no independent size specifier intervenes following 5887 the object identifier value to indicate the size of the mechanism- 5888 defined token object. 5890 Tokens conforming to the present document shall have the following OID 5891 in order to be processable by IDUP-APIs: 5893 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 5894 { itu-t(0) identified-organization(4) etsi(0) 5895 electronic-signature-standard (1733) part1 (1) IDUPMechanism (4) 5896 etsiESv1(1) } 5898 H.2 IDUP-GSS-APIs defined by the IETF 5900 The IETF CAT WG has produced in December 1998 an RFC (RFC 2479 - see 5901 informative references) under the name of IDUP-GSS-API (Independent 5902 Data Unit Protection) able to handle the electronic signature data 5903 format defined in the present document. 5905 The IDUP-GSS-API includes support for non-repudiation services. 5907 It supports evidence generation, where "evidence" is information that 5908 either by itself, or when used in conjunction with other information, 5909 is used to establish proof about an event or action, as well a evidence 5910 verification. 5912 IDUP supports various types of evidences. All the types defined in 5913 IDUP are supported in the present document through the commitment type 5914 parameter. 5916 Clause 2.3.3 of IDUP describes the specific calls needed to handle 5917 evidences ("EV" calls). The "EV" group of calls provides a simple, 5918 high-level interface to underlying IDUP mechanisms when application 5919 developers need to deal only with evidences but not with encryption or 5920 integrity services. 5922 All generations and verification are performed according to the content 5923 of a NR policy that is referenced in the context. 5925 Get_token_details is used to return to an application the attributes 5926 that correspond to a given input token. Since IDUP-GSS- API tokens are 5927 meant to be opaque to the calling application, this function allows the 5928 application to determine information about the token without having to 5929 violate the opaqueness intention of IDUP. Of primary importance is the 5930 mechanism type, which the application can then use as input to the 5931 IDUP_Establish_Env() call in order to establish the correct environment 5932 in which to have the token processed. 5934 Generate_token generates a non-repudiation token using the current 5935 environment. 5937 Verify_evidence verifies the evidence token using the current 5938 environment. This operation returns a major_status code which can be 5939 used to determine whether the evidence contained in a token is complete 5940 (i.e. can be successfully verified (perhaps years) later). If a 5941 token's evidence is not complete, the token can be passed to another 5942 API: form_complete_pidu to complete it. This happens when a status 5943 "conditionally valid" is returned. That status corresponds to the 5944 status "validation incomplete" of the present document. 5946 Form_complete_PIDU is used primarily when the evidence token itself 5947 does not contain all the data required for its verification and it is 5948 anticipated that some of the data not stored in the token may become 5949 unavailable during the interval between generation of the evidence 5950 token and verification unless it is stored in the token. The 5951 Form_Complete_PIDU operation gathers the missing information and 5952 includes it in the token so that verification can be guaranteed to be 5953 possible at any future time. 5955 H.3 CORBA security interfaces defined by the OMG 5957 Non-repudiation interfaces have been defined in "CORBA Security", a 5958 document produced by the OMG (Object Management Group). These 5959 interfaces are described in IDL (Interface Definition Language) and are 5960 optional. 5962 The handling of "tokens" supporting non-repudiation is done through the 5963 following interfaces: 5965 - set_NR_features specifies the features to apply to future 5966 evidence generation and verification operations; 5968 - get_NR_features returns the features which will be applied to 5969 future evidence generation and verification operations; 5971 - generate_token generates a Non-repudiation token using the 5972 current Non-repudiation features; 5974 - verify_evidence verifies the evidence token using the current 5975 Non-repudiation features; 5976 - get_tokens_details returns information about an input Non- 5977 repudiation token. The information returned depends upon the 5978 type of token; 5980 - form_complete_evidence is used when the evidence token itself 5981 does not contain all the data required for its verification, and 5982 it is anticipated that some of the data not stored in the token 5983 may become unavailable during the interval between generation of 5984 the evidence token and verification unless it is stored in the 5985 token. The form_complete_evidence operation gathers the missing 5986 information and includes it in the token so that verification can 5987 be guaranteed to be possible at any future time. 5989 NOTE: The similarity between the two sets of APIs is noticeable. 5991 Annex I (informative):Cryptographic algorithms 5993 RFC 3370 [10] describes the conventions for using several cryptographic 5994 algorithms with the Crytographic Message Syntax (CMS). Only the 5995 hashing and signing algorithms are appropriate for use with the present 5996 document. 5998 Since the publication of RFC 3370 [10], MD5 has been broken. This 5999 algorithm is no more considered as appropriate and has been deleted 6000 from the list of algorithms. 6002 I.1 Digest algorithms 6004 I.1.1 SHA-1 6006 The SHA-1 digest algorithm is defined in FIPS Pub 180-1. The algorithm 6007 identifier for SHA-1 is: 6009 sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) 6010 secsig(3) algorithm(2) 26 } 6012 The AlgorithmIdentifier parameters field is optional. If present, the 6013 parameters field shall contain an ASN.1 NULL. Implementations should 6014 accept SHA-1 AlgorithmIdentifiers with absent parameters as well as 6015 NULL parameters. Implementations should generate SHA-1 6016 AlgorithmIdentifiers with NULL parameters. 6018 I.1.2 General 6020 The following is a selection of work that has been done in the area of 6021 digest algorithms or, as they are often called, hash functions: 6023 - ISO/IEC 10118-1 (1994): "Information technology - Security 6024 techniques - Hash-functions - Part 1: General". ISO/IEC 10118-1 6025 contains definitions and describes basic concepts. 6027 - ISO/IEC 10118-2 (1994): "Information technology - Security 6028 techniques - Hash-functions - Part 2: Hash-functions using an n- 6029 bit block cipher algorithm". ISO/IEC 10118-2 specifies two ways 6030 to construct a hash-function from a block cipher. 6032 - ISO/IEC 10118-3 (1997): "Information technology - Security 6033 techniques - Hash-functions - Part 3: Dedicated hash-functions". 6034 ISO/IEC 10118-3 specifies the following dedicated hash-functions: 6036 - SHA-1 (FIPS 180-1); 6037 - RIPEMD-128; 6038 - RIPEMD-160. 6040 - ISO/IEC 10118-4 (1998): "Information technology - Security 6041 techniques - Hash-functions - Part 4: Hash-functions using 6042 modular arithmetic". 6044 - RFC 1320 (PS 1992): "The MD4 Message-Digest Algorithm". RFC 1320 6045 specifies the hash-function MD4. Today, MD4 is considered out- 6046 dated. 6048 - RFC 1321 (I 1992): "The MD5 Message-Digest Algorithm". RFC 1321 6049 (informational) specifies the hash-unction MD5. 6051 - FIPS Publication 180-1 (1995): "Secure Hash Standard". FIPS 180-1 6052 specifies the Secure Hash Algorithm (SHA), dedicated hash- 6053 function developed for use with the DSA. The original SHA 6054 published in 1993 was slightly revised in 1995 and renamed SHA-1. 6056 - ANSI X9.30-2 (1997): "Public Key Cryptography for the Financial 6057 Services Industry - Part 2: The Secure Hash Algorithm (SHA-1)". 6058 X9.30-2 specifies the ANSI-Version of SHA-1. 6060 - ANSI X9.31-2 (1996): "Public Key Cryptography Using Reversible 6061 Algorithms for the Financial Services Industry - Part 2: Hash 6062 Algorithms". X9.31-2 specifies hash algorithms. 6064 I.2 Digital signature algorithms 6066 I.2.1 DSA 6068 The DSA signature algorithm is defined in FIPS Pub 186. DSA is always 6069 used with the SHA-1 message digest algorithm. The algorithm identifier 6070 for DSA is: 6072 id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 6073 x9-57 (10040) x9cm(4) 3 } 6075 The AlgorithmIdentifier parameters field shall not be present. 6077 I.2.2 RSA 6079 The RSA signature algorithm is defined in RFC 2437 (see informative 6080 references). RFC 3370 [10] specifies the use of the RSA signature 6081 algorithm with the SHA-1 algorithm. The algorithm identifier for RSA 6082 with SHA-1 is: 6084 Sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) 6085 us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } 6087 NOTE: RFC 3370 [10] recommends that MD5 is not used for new 6088 implementations. 6090 I.2.3 General 6092 The following is a selection of work that has been done in the area of 6093 digital signature mechanisms: 6095 - FIPS Publication 186 (1994): "Digital Signature Standard". 6096 NIST's Digital Signature Algorithm (DSA) is a variant of 6097 ElGamal's Discrete Logarithm based digital signature mechanism. 6098 The DSA requires a 160-bit hash-function and mandates SHA-1. 6100 - IEEE P1363 (2000): "Standard Specifications for Public-Key 6101 Cryptography". IEEE P1363 contains mechanisms for digital 6102 signatures, key establishment, and encipherment based on three 6103 families of public-key schemes: 6105 - "Conventional" Discrete Logarithm (DL) based techniques, i.e. 6106 Diffie-Hellman (DH) key agreement, Menezes-Qu-Vanstone (MQV) 6107 key agreement, the Digital Signature Algorithm (DSA), and 6108 Nyberg-Rueppel (NR) digital signatures; 6110 - Elliptic Curve (EC) based variants of the DL-mechanisms 6111 specified above, i.e. EC-DH, EC-MQV, EC-DSA, and EC-NR. For 6112 elliptic curves, implementation options include mod p and 6113 characteristic 2 with polynomial or normal basis 6114 representation; 6116 - Integer Factoring (IF) based techniques including RSA 6117 encryption, RSA digital signatures, and RSA-based key 6118 transport. 6120 - ISO/IEC 9796 (1991): "Information technology - Security 6121 techniques - Digital signature scheme giving message recovery". 6122 ISO/IEC 9796 specifies a digital signature mechanism based on the 6123 RSA public-key technique and a specifically designed redundancy 6124 function. 6126 - ISO/IEC 9796-2 (1997): "Information technology - Security 6127 techniques - Digital signature schemes giving message recovery - 6128 Part 2: Mechanisms using a hash-function". ISO/IEC 9796-2 6129 specifies digital signature mechanisms with partial message 6130 recovery that are also based on the RSA technique but make use of 6131 a hash-function. 6133 - ISO/IEC 9796-4 (1998): "Digital signature schemes giving message 6134 recovery - Part 4: Discrete logarithm based mechanisms". ISO/IEC 6135 9796-4 specifies digital signature mechanisms with partial 6136 message recovery that are based on Discrete Logarithm techniques. 6137 The document includes the Nyberg-Rueppel scheme. 6139 - ISO/IEC 14888-1: "Digital signatures with appendix - Part 1: 6140 General". ISO/IEC 14888-1 contains definitions and describes the 6141 basic concepts of digital signatures with appendix. 6143 - ISO/IEC 14888-2: "Digital signatures with appendix - Part 2: 6144 Identity-based mechanisms". ISO/IEC 14888-2 specifies digital 6145 signature schemes with appendix that make use of identity-based 6146 keying material. The document includes the zero-knowledge 6147 techniques of Fiat-Shamir and Guillou-Quisquater. 6149 - ISO/IEC 14888-3: "Digital signatures with appendix - Part 3: 6150 Certificate-based mechanisms". ISO/IEC 14888-3 specifies digital 6151 signature schemes with appendix that make use of certificate- 6152 based keying material. The document includes five schemes: 6154 - DSA; 6155 - EC-DSA, an elliptic curve based analog of NIST's Digital 6156 Signature Algorithm; 6157 - Pointcheval-Vaudeney signatures; 6158 - RSA signatures; 6159 - ESIGN. 6161 - ISO/IEC 15946-2 (2002) : "Cryptographic techniques based on 6162 elliptic curves - Part 2: Digital signatures". 6164 - ISO/IEC 15946-3 (2002) specifies digital signature schemes with 6165 appendix using elliptic curves. 6167 - The document includes two schemes: 6169 - EC-DSA, an elliptic curve based analog of NIST's Digital 6170 Signature Algorithm; 6172 - EC-AMV, an elliptic curve based analog of the Agnew-Muller- 6173 Vanstone signature algorithm. 6175 - ANSI X9.31-1 (1997): "Public Key Cryptography Using Reversible 6176 Algorithms for the Financial Services Industry - Part 1: The RSA 6177 Signature Algorithm". ANSI X9.31-1 specifies a digital signature 6178 mechanism with appendix using the RSA public-key technique. 6180 - ANSI X9.30-1 (1997): "Public Key Cryptography Using Irreversible 6181 Algorithms for the Financial Services Industry - Part 1: The 6182 Digital Signature Algorithm (DSA)". ANSI X9.30-1 specifies the 6183 DSA, NIST's Digital Signature Algorithm. 6185 - ANSI X9.62 (1998): "Public Key Cryptography for the Financial 6186 Services Industry - The Elliptic Curve Digital Signature 6187 Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic Curve 6188 Digital Signature Algorithm, an analog of NIST's Digital 6189 Signature Algorithm (DSA) using elliptic curves. The appendices 6190 provide tutorial information on the underlying mathematics for 6191 elliptic curve cryptography and many examples. 6193 Annex J (informative): Changes from the previous version 6195 The title of the document has changed to be aligned with the title 6196 of XAdES, the vocabulary used within the present document has been 6197 aligned with the vocabulary used in XAdES, 6199 In the previous version of TS 101 733 (i.e. version 1.5.1) 6200 sigPolicyHash was mandatory. Implementations requiring to be 6201 backward compatible with version 1.5.1 and previous versions 6202 of the current document MUST include SigPolicyHash. 6204 The OIDs from the ASN.1 modules have changed for the following 6205 reasons: 6207 - the OIDs of the ASN.1 modules of RFC 2560 and RFC 3161 have been 6208 included. 6210 - since RFC 2459 and RFC 3369 has been obsoleted by RFC 3280 and 6211 RFC 3852 respectively, there was the need to refer to the OIDs 6212 of the ASN.1 modules of RFC 3280 and RFC 3852, instead of the 6213 OIDs of the ASN.1 modules of RFC 2459 and RFC 3369. 6215 - the other change is related to the field sigPolicyHash from 6216 SignaturePolicyId (see clause 5.8.1). That field was mandatory 6217 and is now optional. 6219 Full Copyright Statement 6221 Copyright (C) The Internet Society (2005). 6223 The contents of this Informational RFC amounts to a transposition of 6224 the ETSI TS 101 733 V.1.6.3 and is technically equivalent to it. 6225 The ETSI TS is under the ETSI Copyright (C). Individual copies of 6226 this ETSI deliverable can be downloaded from http://www.etsi.org. 6228 This document is subject to the rights, licenses and restrictions 6229 contained in BCP 78, and except as set forth therein, the authors 6230 retain all their rights. 6232 Disclaimer 6234 This document and the information contained herein are provided on 6235 An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 6236 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 6237 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 6238 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 6239 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 6240 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 6241 PARTICULAR PURPOSE. 6243 Intellectual Property 6245 The IETF takes no position regarding the validity or scope of any 6246 Intellectual Property Rights or other rights that might be claimed 6247 to pertain to the implementation or use of the technology described 6248 in this document or the extent to which any license under such 6249 rights might or might not be available; nor does it represent that 6250 it has made any independent effort to identify any such rights. 6251 Information on the procedures with respect to rights in RFC 6252 documents can be found in BCP 78 and BCP 79. 6254 Copies of IPR disclosures made to the IETF Secretariat and any 6255 assurances of licenses to be made available, or the result of an 6256 attempt made to obtain a general license or permission for the use 6257 of such proprietary rights by implementers or users of this 6258 specification can be obtained from the IETF on-line IPR repository 6259 at http://www.ietf.org/ipr. 6261 The IETF invites any interested party to bring to its attention any 6262 copyrights, patents or patent applications, or other proprietary 6263 rights that may cover technology that may be required to implement 6264 this standard. Please address the information to the IETF at ietf- 6265 ipr@ietf.org. 6267 ETSI takes no position regarding the validity or scope of any 6268 Intellectual Property Rights or other rights that might be claimed 6269 to pertain to the implementation or use of the technology described 6270 in this document or the extent to which any license under such 6271 rights might or might not be available; nor does it represent that 6272 it has made any independent effort to identify any such rights. 6274 Information on the ETSI Intellectual Property Rights Policy may be 6275 obtained from . The document is 6276 an extract from Annex 6 of the ETSI Rules of Procedure that are 6277 available at : . 6279 The ETSI IPR database http://webapp.etsi.org/IPR/home.asp contains 6280 IPRs, particularly patents and patent applications, which have been 6281 notified to ETSI as being essential, or potentially essential, to 6282 ETSI standards. Unless otherwise specified, all IPRs contained 6283 herein have been notified to ETSI, with an undertaking from the 6284 owner to grant licenses according to the terms and conditions of 6285 Article 6.1 of Annex 6 of the ETSI Rules of the ETSI IPR Policy. 6287 The ETSI IPR database provides data that is based on the information 6288 received. ETSI has not checked the validity of the information, nor 6289 the relevance of the identified patents/patent applications to the 6290 ETSI Standards and cannot confirm, or deny, that the patents/patent 6291 applications are, in fact, essential, or potentially essential. No 6292 investigation, or IPR searches, have been carried out by ETSI and 6293 therefore no guarantee can be given concerning the existence of 6294 other IPRs which are, or may become, essential. 6296 Potential Licensees should use the information in this database at 6297 their discretion and should contact the patent holder.