idnits 2.17.1 draft-ietf-smime-esformats-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == It seems as if not all pages are separated by form feeds - found 0 form feeds but 80 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([ISONR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3764 has weird spacing: '...stamped is si...' == Line 3765 has weird spacing: '...stamped with ...' == 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 (November 2000) is 8562 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 3122 -- Looks like a reference, but probably isn't: '13' on line 260 -- Looks like a reference, but probably isn't: '9' on line 1355 -- Looks like a reference, but probably isn't: '8' on line 2183 -- Looks like a reference, but probably isn't: '25' on line 1371 -- Looks like a reference, but probably isn't: '0' on line 3121 -- Looks like a reference, but probably isn't: '2' on line 3123 -- Looks like a reference, but probably isn't: '16' on line 1548 == Missing Reference: 'X509' is mentioned on line 1927, but not defined -- Looks like a reference, but probably isn't: '7' on line 2179 == Unused Reference: 'PKCS9' is defined on line 2208, but no explicit reference was found in the text == Unused Reference: 'ES201733' is defined on line 2215, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Electronic Signature Formats 2 Internet Draft ETSI TC-SEC (ETSI) 3 S/MIME Working Group D. Pinkas (Bull) 4 expires in six months J. Ross (Security & Standards) 5 Target Category: Informational N. Pope (Security & Standards) 6 November 2000 8 Electronic Signature Formats 9 for long term electronic signatures 10 12 Status of this Memo 14 This document is an Internet-Draft and is NOT offered in 15 accordance with section of RFC 2026, and the author does not 16 provide the IETF with any rights other than to publish as an 17 Internet-Draft. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 Months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The informational RFC defines the format of an electronic signature 38 that can remain valid over long periods. This includes evidence as to 39 its validity even if the signer or verifying party later attempts to 40 deny (i.e. repudiates, see [ISONR]) the validity of the signature. 42 The format can be considered as an extension to RFC 2630 [CMS] and RFC 43 2634 [ESS], where, when appropriate additional signed and unsigned 44 attributes have been defined. 46 The contents of this Informational RFC is technically equivalent to 47 ETSI TS 101 733 V.1.2.2 Copyright (C). Individual copies of this 48 ETSI deliverable can be downloaded from http://www.etsi.org 50 1. Introduction 52 This document is intended to cover electronic signatures for various 53 types of transactions, including business transactions (e.g. purchase 54 requisition, contract, and invoice applications) where long term 55 validity of such signatures is important. 57 Internet Draft Electronic Signature Formats 59 Electronic signatures can be used for any transaction between an 60 individual and a company, between two companies, between an individual 61 and a governmental body, etc. This document is independent of any 62 environment. It can be applied to any environment e.g. smart cards, GSM 63 SIM cards, special programs for electronic signatures etc. 65 An electronic signature produced in accordance with this document 66 provides evidence that can be processed to get confidence that some 67 commitment has been explicitly endorsed under a signature policy, at a 68 given time, by a signer under an identifier, e.g. a name or a 69 pseudonym, and optionally a role. 71 The European Directive on a community framework for Electronic 72 Signatures defines an electronic signature as: "data in electronic form 73 which is attached to or logically associated with other electronic data 74 and which serves as a method of authentication". An electronic 75 signature as used in the current document is a form of advanced 76 electronic signature as defined in the Directive. 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 79 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 80 as shown) are to be interpreted as described in [RFC2119]. 82 TABLE OF CONTENTS 84 1. Introduction 1 85 2 Overview 4 86 2.1 Aim 4 87 2.2 Basis of Present Document 4 88 2.3 Major Parties 5 89 2.4 Electronic Signatures and Validation Data 6 90 2.5 Forms of Validation Data 7 91 2.6 Extended Forms of Validation Data 10 92 2.7 Archive Validation Data 12 93 2.8 Arbitration 13 94 2.9 Validation Process 13 95 2.10 Example Validation Sequence 14 96 2.11 Additional optional features 19 97 3. Data structure of an Electronic Signature 20 98 3.1 General Syntax 20 99 3.2 Data Content Type 20 100 3.3 Signed-data Content Type 20 101 3.4 SignedData Type 20 102 3.5 EncapsulatedContentInfo Type 21 103 3.6 SignerInfo Type 21 104 3.6.1 Message Digest Calculation Process 21 105 3.6.2 Message Signature Generation Process 21 106 3.6.3 Message Signature Verification Process 21 107 3.7 CMS Imported Mandatory Present Attributes 22 108 3.7.1 Content Type 22 109 3.7.2 Message Digest 22 110 3.7.3 Signing Time 22 112 Internet Draft Electronic Signature Formats 114 3.8 Alternative Signing Certificate Attributes 22 115 3.8.1 ESS Signing Certificate Attribute Definition 22 116 3.8.2 Other Signing Certificate Attribute Definition 23 117 3.9 Additional Mandatory Attributes 24 118 3.9.1 Signature policy Identifier 24 119 3.10 CMS Imported Optional Attributes 26 120 3.10.1 Countersignature 26 121 3.11 ESS Imported Optional Attributes 26 122 3.11.1 Content Reference Attribute 27 123 3.11.2 Content Identifier Attribute 27 124 3.11.3 Content Hints Attribute 27 125 3.12 Additional Optional Attributes 28 126 3.12.1 Commitment Type Indication Attribute 28 127 3.12.2 Signer Location attribute 30 128 3.12.3 Signer Attributes attribute 31 129 3.12.4 Content Timestamp attribute 31 130 3.13 Support for Multiple Signatures 32 131 3.13.1 Independent Signatures 32 132 3.13.2 Embedded Signatures 32 133 4. Validation Data 32 134 4.1 Electronic Signature Timestamp 33 135 4.1.1 Signature Timestamp Attribute Definition 33 136 4.2 Complete Validation Data 34 137 4.2.1 Complete Certificate Refs Attribute Definition 35 138 4.2.2 Complete Revocation Refs Attribute Definition 35 139 4.3 Extended Validation Data 37 140 4.3.1 Certificate Values Attribute Definition 37 141 4.3.2 Revocation Values Attribute Definition 38 142 4.3.3 ES-C Timestamp Attribute Definition 38 143 4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 39 144 4.4 Archive Validation Data 39 145 4.4.1 Archive Timestamp Attribute Definition 40 146 5. Security considerations 41 147 5.1 Protection of Private Key 41 148 5.2 Choice of Algorithms 41 149 6. Conformance Requirements 41 150 6.1 Signer 41 151 6.2 Verifier using timestamping 42 152 6.3 Verifier using secure records 42 153 7. References 43 154 8. Authors' Addresses 44 155 9. Full Copyright Statement 45 156 Annex A (normative): ASN.1 Definitions 46 157 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 46 158 A.2 Definitions Using X.680 1997 ASN.1 Syntax 54 159 Annex B (informative): General Description 64 160 B.1 The Signature Policy 64 161 B.2 Signed Information 65 162 B.3 Components of an Electronic Signature 65 163 B.3.1 Reference to the Signature Policy 65 164 B.3.2 Commitment Type Indication 66 165 B.3.3 Certificate Identifier from the Signer 67 167 Internet Draft Electronic Signature Formats 169 B.3.4. Role Attributes 68 170 B.3.4.1 Claimed Role 68 171 B.3.4.2 Certified Role 68 172 B.3.5 Signer Location 69 173 B.3.6 Signing Time 69 174 B.3.7 Content Format 70 175 B.4 Components of Validation Data 70 176 B.4.1 Revocation Status Information 70 177 B.4.2 CRL Information 71 178 B.4.3 OCSP Information 72 179 B.4.4 Certification Path 72 180 B.4.5 Timestamping for Long Life of Signature 73 181 B.4.6 Timestamping before CA Key Compromises 74 182 B.4.6.1 Timestamping the ES with Complete validation data 75 183 B.4.6.2 Timestamping Certificates and Revocation Information 75 184 B.4.7 Timestamping for Long Life of Signature 76 185 B.4.8 Reference to Additional Data 77 186 B.4.9 Timestamping for Mutual Recognition 77 187 B.4.10 TSA Key Compromise 78 188 B.5 Multiple Signatures 79 189 Annex C (informative): Identifiers and roles 79 190 C.1 Signer Name Forms 79 191 C.2 TSP Name Forms 79 192 C.3 Roles and Signer Attributes 80 194 2 Overview 196 2.1 Aim 198 The aim of this document is to define an Electronic Signature (ES) that 199 remains valid over long periods. This includes evidence as to its 200 validity even if the signer or verifying party later attempts to deny 201 (repudiates) the validity of the signature. 203 This document specifies the use of trusted service providers (e.g. 204 TimeStamping Authorities (TSA)), and the data that needs to be archived 205 (e.g. cross certificates and revocation lists) to meet the requirements 206 of long term electronic signatures. An electronic signature defined by 207 this document can be used for arbitration in case of a dispute between 208 the signer and verifier, which may occur at some later time, even years 209 later. This document uses a signature policy, referenced by the signer, 210 as the basis for establishing the validity of an electronic signature. 212 2.2 Basis of Present Document 214 This document is based on the use of public key cryptography to produce 215 digital signatures, supported by public key certificates. 217 A Public key certificate is a public keys of a user, together with some 218 other information, rendered unforgeable by encipherment with the 219 private key of the Certification Authority (CA) which issued it (ITU-T 220 Recommendation X.509 [1]). 222 Internet Draft Electronic Signature Formats 224 This document also specifies the uses of timestamping services to prove 225 the validity of a signature long after the normal lifetime of critical 226 elements of an electronic signature and to support non-repudiation. It 227 also, as an option, defines the use of additional timestamps to provide 228 very long-term protection against key compromise or weakened 229 algorithms. 231 This document builds on existing standards that are widely adopted. 232 This includes: 234 * RFC 2459 [RFC2459] Internet X.509 Public Key Infrastructure 235 Certificate and CRL Profile (PKIX); 236 * RFC 2630 [CMS] Crytographic Message Syntax (CMS); 237 * RFC 2634 [ESS] Enhanced Security Services (ESS); 238 * RFC 2439 [OCSP] One-line Certificate Status Protocol (OCSP); 239 * ITU-T Recommendation X.509 [1] Authentication framework; 240 * RFC (to be published) [TSP] PKIX Time Stamping protocol (TSP). 242 NOTE: See clause 8 for a full set of references. 244 2.3 Major Parties 246 The following are the major parties involved in a business transaction 247 supported by electronic signatures as defined in this document: 249 * the Signer; 250 * the Verifier; 251 * the Arbitrator; 252 * Trusted Service Providers (TSP). 254 A Signer is an entity that initially creates the electronic signature. 255 When the signer digitally signs over data using the prescribed format, 256 this represents a commitment on behalf of the signing entity to the 257 data being signed. 259 A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1 260 [13]). Within the context of this document this is an entity that 261 validates an electronic signature. 262 An arbitrator, is an entity which arbitrates disputes between a signer 263 and a verifier when there is a disagreement on the validity of a 264 digital signature. 266 Trusted Service Providers (TSPs) are one or more entities that help 267 to build trust relationships between the signer and verifier. Use of 268 some specific TSP services MAY be mandated by signature policy. TSP 269 supporting services may provide the following information: user 270 certificates, cross-certificates, timestamping tokens, CRLs, ARLs, 271 OCSP responses. 273 Internet Draft Electronic Signature Formats 275 The following TSPs are used to support the validation or 276 the verification of electronic signatures : 278 * Certification Authorities; 279 * Registration Authorities; 280 * Repository Authorities (e.g. a Directory); 281 * TimeStamping Authorities; 282 * One-line Certificate Status Protocol responders; 283 * Attribute Authorities; 284 * Signature Policy Issuers. 286 Certification Authorities provide users with public key certificates. 288 Registration Authorities allows the registration of entities before a 289 CA generates certificates. 291 Repository Authorities publish CRLs issued by CAs, cross-certificates 292 (i.e. CA certificates) issued by CAs, signature policies issued by 293 Signature Policy Issuers and optionally public key certificates (i.e. 294 leaf certificates) issued by CAs. 296 TimeStamping Authorities attest that some data was formed before a 297 given trusted time. 299 One-line Certificate Status Protocol responders (OSCP responders) 300 provide information about the status (i.e. revoked, not revoked, 301 unknown) of a particular certificate. 303 A Signature Policy Issuer issues signatures policies that define the 304 technical and procedural requirements for electronic signature 305 creation, validation and verification, in order to meet a particular 306 business need. 308 Attributes Authorities provide users with attributes linked to public 309 key certificates 311 2.4 Electronic Signatures and Validation Data 313 Validation of an electronic signature in accordance with this document 314 requires: 316 * The electronic signature; this includes: 318 - the signature policy; 319 - the signed user data; 320 - the digital signature; 321 - other signed attributes provided by the signer; 322 . - other unsigned attributes provided by the signer. 324 * Validation data which is the additional data needed to validate 325 the electronic signature; this includes: 327 - certificates references; 328 - certificates; 330 Internet Draft Electronic Signature Formats 332 - revocation status information references; 333 - revocation status information; 334 - time-stamps from Time Stamping Authorities (TSAs). 336 * The signature policy specifies the technical requirements on 337 signature creation and validation in order to meet a particular 338 business need. A given legal/contractual context may recognize a 339 particular signature policy as meeting its requirements. 341 For example: a specific signature policy may be recognized by court 342 of law as meeting the requirements of the European Directive for 343 electronic commerce. A signature policy may be written using a formal 344 notation like ASN.1 or in an informal free text form provided the 345 rules of the policy are clearly identified. However, for a given 346 signature policy there shall be one definitive form which has a unique 347 binary encoded value. 349 Signed user data is the user's data that is signed. 351 The Digital Signature is the digital signature applied over the 352 following attributes provided by the signer: 354 * hash of the user data (message digest); 355 * signature Policy Identifier; 356 * other signed attributes 358 The other signed attributes include any additional information which 359 must be signed to conform to the signature policy or this document 360 (e.g. signing time). 362 According to the requirements of a specific signature policy in use, 363 various Validation Data shall be collected and attached to or 364 associated with the signature structure by the signer and/or the 365 verifier. The validation data includes CA certificates as well as 366 revocation status information in the form of certificate revocation 367 lists (CRLs) or certificate status information provided by an on-line 368 service. Additional data also includes timestamps and other time 369 related data used to provide evidence of the timing of given events. It 370 is required, as a minimum, that either the signer or verifier obtains a 371 timestamp over the signer's signature or a secure time record of the 372 electronic signature must be maintained. Such secure records must not 373 be undetectably modified and must record the time close to when the 374 signature was first validated. 376 2.5 Forms of Validation Data 378 An electronic signature may exist in many forms including: 380 * the Electronic Signature (ES), which includes the digital 381 signature and other basic information provided by the signer; 383 Internet Draft Electronic Signature Formats 385 * the ES with Timestamp (ES-T), which adds a timestamp to the 386 Electronic Signature, to take initial steps towards providing 387 long term validity; 389 * the ES with Complete validation data (ES-C), which adds to the 390 ES-T references to the complete set of data supporting the 391 validity of the electronic signature (i.e. revocation status 392 information). 394 The signer must provide at least the ES form, but in some cases may 395 decide to provide the ES-T form and in the extreme case could provide 396 the ES-C form. If the signer does not provide ES-T, the verifier must 397 either create the ES-T on first receipt of an electronic signature or 398 shall keep a secure time record of the ES. Either of these two 399 approaches provide independent evidence of the existence of 400 the signature at the time it was first verified which should be near 401 the time it was created, and so protects against later repudiation of 402 the existence of the signature. If the signer does not provide ES-C the 403 verifier must create the ES-C when the complete set of revocation and 404 other validation data is available. 406 The ES satisfies the legal requirements for electronic signatures as 407 defined in the European Directive on electronic signatures, see Annex C 408 for further discussion on relationship of this document to the 409 Directive. It provides basic authentication and integrity protection 410 and can be created without accessing on-line (timestamping) services. 411 However, without the addition of a timestamp or a secure time record 412 the electronic signature does not protect against the threat that the 413 signer later denies having created the electronic signature (i.e. does 414 not provide non-repudiation of its existence). 416 The ES-T time-stamp or time record should be created close to the time 417 that ES was created to provide protection against repudiation. At this 418 time all the data needed to complete the validation may not be 419 available but what information is readily available may be used to 420 carry out some of the initial checks. For example, only part of the 421 revocation information may be available for verification at that point 422 in time. Generally, the ES-C form cannot be created at the same time as 423 the ES, as it is necessary to allow time for any revocation information 424 to be captured. Also, if a certificate is found to be temporarily 425 suspended, it will be necessary to wait until the end of the suspension 426 period. 428 The signer should only create the ES-C in situations where it was 429 prepared to wait for a sufficient length of time after creating the ES 430 form before dispatching the ES-C. This, however, has the advantage that 431 the verifier can be presented with the complete set of data supporting 432 the validity of the ES. 434 Support for ES-C by the verifier is mandated (see clause 6 for 435 specific conformance requirements). 437 Internet Draft Electronic Signature Formats 439 An Electronic Signature (ES), with the additional validation data 440 forming the ES-T and ES-C is illustrated in Figure 1: 442 +------------------------------------------------------------ES-C-----+ 443 |+--------------------------------------------ES-T-----+ | 444 ||+------Elect.Signature (ES)----------+ +------------+| +-----------+| 445 |||+---------+ +----------+ +---------+| |Timestamp || |Complete || 446 ||||Signature| | Other | | Digital || |over digital|| |certificate|| 447 ||||Policy ID| | Signed | |Signature|| |signature || |and || 448 |||| | |Attributes| | || +------------+| |revocation || 449 |||+---------+ +----------+ +---------+| | |references || 450 ||+------------------------------------+ | +-----------+| 451 |+-----------------------------------------------------+ | 452 +---------------------------------------------------------------------+ 454 Figure 1: Illustration of an ES, ES-T and ES-C 456 The verifiers conformance requirements of an ES with a timestamp of the 457 digital signature is defined in subclause 6.2. 459 The ES on its own satisfies the legal requirements for electronic 460 signatures as defined in the European Directive on electronic 461 signatures. The signers conformance requirements of an ES are defined 462 in subclause 6.1, and are met using a structure as indicated in figure 463 2: 465 +------Elect.Signature (ES)-----------| 466 |+---------+ +----------+ +---------+ | 467 ||Signature| | Other | | Digital | | 468 ||Policy ID| | Signed | |Signature| | 469 || | |Attributes| | | | 470 |+---------+ +----------+ +---------+ | 471 |+-----------------------------------+| 473 Figure 2: Illustration of an ES 475 Where there are requirements for long term signatures without 476 timestamping the digital signature, then a secure record is needed of 477 the time of verification in association with the electronic signature 478 (i.e. both must be securely recorded). In addition the certificates 479 and revocation information used at the time of verification should to 480 be recorded as indicated in figure 3 as an ES-C(bis). 482 Internet Draft Electronic Signature Formats 484 +-------------------------------------------------------ES-C-----+ 485 | | 486 | +------Elect.Signature (ES)----------+| +-----------+| 487 | |+---------+ +----------+ +---------+|| |Complete || 488 | ||Signature| | Other | | Digital ||| |certificate|| 489 | ||Policy ID| | Signed | |Signature||| |and || 490 | || | |Attributes| | ||| |revocation || 491 | |+---------+ +----------+ +---------+|| |references || 492 | +------------------------------------+| +-----------+| 493 | | 494 +----------------------------------------------------------------+ 496 Figure 3: Illustration of an ES-C(bis) 498 The verifiers conformance requirements of an ES-C(bis) is defined in 499 subclause 6.3. 501 Note: A timestamp attached to the electronic signature or a secure time 502 record helps to protect the validity of the signature even if some of 503 the verification data associated with the signature become compromised 504 AFTER the signature was generated. The timestamp or a secure time 505 record provides evidence that the signature was generated BEFORE the 506 event of compromise; hence the signature will maintain its validity 507 status. 509 2.6 Extended Forms of Validation Data 511 The complete validation data (ES-C) described above may be extended to 512 form an ES with eXtended validation data (ES-X) to meet following 513 additional requirements. 515 Firstly, when the verifier does not has access to, 517 * the signer's certificate, 518 * all the CA certificates that make up the full certification 519 path, 520 * all the associated revocation status information, as referenced 521 in the ES-C. 523 then the values of these certificates and revocation information may be 524 added to the ES-C. This form of extended validation data is called a 525 X-Long. 527 Secondly, if there is a risk that any CA keys used in the certificate 528 chain may be compromised, then it is necessary to additionally 529 timestamp the validation data by either: 531 * timestamping all the validation data as held with the ES(ES-C), 532 this eXtended validation data is called a Type 1 X-Timestamp; or 533 * timestamping individual reference data as used for complete 534 validation. 536 Internet Draft Electronic Signature Formats 538 This form of eXtended validation data is called a Type 2 X-Timestamp. 540 NOTE: The advantages/drawbacks for Type 1 and Type 2 X-Timestamp are 541 discussed in this document (see clause B.4.6.) 543 If all the above conditions occur then a combination of the two formats 544 above may be used. This form of eXtended validation data is called 545 a X-Long-Timestamped. 547 Support for the extended forms of validation data is optional. 549 An Electronic Signature (ES) , with the additional validation data 550 forming the ES-X long is illustrated in Figure 4: 552 +------------------------------------------------------- ES-X Long--+ 553 |+--------------------------------------- EC-C --------+ | 554 ||+---- Elect.Signature (ES)----+ +--------+| +--------+ | 555 |||+-------+-+-------+-+-------+| +---------+|Complete|| |Complete| | 556 ||||Signa- | |Other | |Digital|| |Timestamp||certi- || |certi- | | 557 ||||ture | |Signed | |Signa- || |over ||ficate || |ficate | | 558 ||||Policy | |Attri- | |ture || |digital ||and || |and | | 559 ||||ID | |butes | | || |signature||revoc. || |revoc. | | 560 |||+-------+ +-------+ +-------+| +---------+|refs || |data | | 561 ||+-----------------------------+ +--------+| +--------+ | 562 |+-----------------------------------------------------+ | 563 +-------------------------------------------------------------------+ 565 Figure 4: Illustration of an ES and ES-X long. 567 An Electronic Signature (ES) , with the additional validation data 568 forming the eXtended Validation Data - Type 1 is illustrated in 569 Figure 5: 571 +---------------------------------------------------------- ES-X 1 -+ 572 |+---------------------------------------- EC-C --------+ | 573 || +---- Elect.Signature (ES)----+ +--------+| +-------+ | 574 || |+-------+ +-------+ +-------+| +---------+|Complete|| | | | 575 || ||Signa- | |Other | |Digital|| |Timestamp||certifi-|| | Time- | | 576 || ||ture | |Signed | |Signa- || |over ||cate and|| | stamp | | 577 || ||Policy | |Attri- | |ture || |digital ||revoc. || | over | | 578 || ||ID | |butes | | || |signature||refs || | CES | | 579 || |+-------+ +-------+ +-------+| +---------+| || | | | 580 || +-----------------------------+ +--------+| +-------+ | 581 |+------------------------------------------------------+ | 582 +-------------------------------------------------------------------+ 584 Figure 5: Illustration of ES with ES-X Type 1 586 Internet Draft Electronic Signature Formats 588 An Electronic Signature (ES) , with the additional validation data 589 forming the eXtended Validation Data - Type 2 is illustrated in 590 Figure 6: 592 +-------------------------------------------------------- ES-X 2 ---+ 593 |+--------------------------------------- EC-C --------+ | 594 ||+---- Elect.Signature (ES)----+ +--------+| +--------+ | 595 |||+-------+ +-------+ +-------+| +---------+|Complete|| |Times | | 596 ||||Signa- | |Other | |Digital|| |Timestamp||certs || |Stamp | | 597 ||||ture | |Signed | |Signa- || |over ||and || |over | | 598 ||||Policy | |Attri- | |ture || |digital ||revoc. || |Complete| | 599 ||||ID | |butes | | || |signature||refs || |certs | | 600 |||+-------+ +-------+ +-------+| +---------+| || |and | | 601 ||+-----------------------------+ +--------+| |revoc. | | 602 || | |refs | | 603 |+-----------------------------------------------------+ +--------+ | 604 +-------------------------------------------------------------------+ 606 Figure 6: Illustration of ES with ES-X Type 2 608 2.7 Archive Validation Data 610 Before the algorithms, keys and other cryptographic data used at the 611 time the ES-C was built become weak and the cryptographic functions 612 become vulnerable, or the certificates supporting previous timestamps 613 expires, the signed data, the ES-C and any additional information 614 (ES-X) should be timestamped. If possible this should use stronger 615 algorithms (or longer key lengths) than in the original timestamp. 617 This additional data and timestamp is called Archive Validation Data 618 (ES-A). The Timestamping process may be repeated every time the 619 protection used to timestamp a previous ES-A become weak. An ES-A 620 may thus bear multiple embedded time stamps. 622 An example of an Electronic Signature (ES), with the additional 623 validation data for the ES-C and ES-X forming the ES-A is illustrated 624 in Figure 7. 626 +-------------------------------- ES-A --------- ----------+ 627 | +-------------------- ES-A -----------------+ | 628 | | +--------- ES-X -------------- + | | 629 | | |..............................| +-----+ | +-----+ | 630 | | |..............................| |Time | | |Time | | 631 | | |..............................| |Stamp| | |Stamp| | 632 | | | | +-----+ | +-----+ | 633 | | +----------------------------- + | | 634 | +-------------------------------------------+ | 635 +----------------------------------------------------------+ 637 Figure 7: Illustration of ES -A 639 Support for ES-A is optional. 641 Internet Draft Electronic Signature Formats 643 2.8 Arbitration 645 The ES-C may be used for arbitration should there be a dispute between 646 the signer and verifier, provided that: 648 * a copy of the signature policy referenced by the signer is 649 available; 651 * the arbitrator knows where to retrieve the signer's certificate 652 (if not already present), all the cross-certificates and the 653 required CRLs and/or OCSPs responses referenced in the ES-C; 655 * none of the issuing key from the certificate chain have ever 656 been compromised; 658 * the cryptography used at the time the ES-C was built has not 659 been broken at the time the arbitration is performed. 661 When the second condition is not met, then the plaintiff must provide 662 an ES-X Long. 664 When it is known by some external means that the third condition is 665 not met, then the plaintiff must provide an ES-X Timestamped. 667 When the two previous conditions are not met, the plaintiff must 668 provide the two above information (i.e. an ES-X Timestamped and Long). 670 When the last condition is not met, the plaintiff must provide an 671 ES-A. 673 It should be noticed that a verifier may need to get two time stamps 674 at two different instants of time: one soon after the generation of 675 the ES and one soon after some grace period allowing any entity from 676 the certification chain to declare a key compromise. 678 2.9 Validation Process 680 The Validation Process validates an electronic signature in accordance 681 with the requirements of the signature policy. The output status of 682 the validation process can be: 684 * valid; 685 * invalid; 686 * incomplete verification. 688 A Valid response indicates that the signature has passed verification 689 and it complies with the signature validation policy. 691 A signature validation policy is a part of the signature policy which 692 specifies the technical requirements on the signer in creating a 693 signature and verifier when validating a signature. 695 Internet Draft Electronic Signature Formats 697 An Invalid response indicates that either the signature format is 698 incorrect or that the digital signature value fails verification 699 (e.g. the integrity checks on the digital signature value fails or 700 any of the certificates on which the digital signature verification 701 depends is known to be invalid or revoked). 703 An Incomplete Validation response indicates that the format and 704 digital signature verifications have not failed but there is 705 insufficient information to determine if the electronic signature 706 is valid under the signature policy. This can include situations 707 where additional information, which does not effect the validity of 708 the digital signature value, may be available but is invalid. 710 In the case of Incomplete Validation, it may be possible to request 711 that the electronic signature be checked again at a later date when 712 additional validation information might become available. Also, in the 713 case of incomplete validation, additional information may be made 714 available to the application or user, thus allowing the application or 715 user to decide what to do with partially correct electronic signatures. 717 The validation process may also output validation data : 719 * a signature timestamp; 720 * the complete validation data; 721 * the archive validation data. 723 2.10 Example Validation Sequence 725 Figure 8, and subsequent description, describes how the validation 726 process may build up a complete electronic signature over time. 728 Soon after receiving the electronic signature (ES) from the signer (1), 729 the digital signature value may be checked, the validation process 730 must at least add a time-stamp (2), unless the signer has provided one 731 which is trusted by the verifier. The validation process may also 732 validate the electronic signature, as required under the identified 733 signature policy, using additional data (e.g. certificates, CRL, etc.) 734 provided by trusted service providers. If the validation process is not 735 complete then the output from this stage is the ES-T. 737 When all the additional data (e.g. the complete certificate and 738 revocation information) necessary to validate the electronic signature 739 first becomes available, then the validation process: 741 * obtains all the necessary additional certificate and revocation 742 status information; 744 * completes all the validation checks on the ES, using the 745 complete certificate and revocation information (if a timestamp 746 is not already present, this may be added at the same stage 747 combining ES-T and ES-C process); 749 Internet Draft Electronic Signature Formats 751 * records the complete certificate and revocation references (3); 753 * indicates the validity status to the user (4). 755 +---------------------------------------- ES-C ----------+ 756 |+----------------------------- ES-T -------+ | 757 ||+--- Elect.Signature (ES) ----+ | +--------+ | 758 |||+-------+ +-------+ +-------+|+---------+| |Complete| | 759 ||||Signa- | |Other | |Digital|||Timestamp|| |certifi-| | 760 ||||ture | |Signed | |Signa- |||over || |cate and| | 761 ||||Policy | |Attri- | |ture |||digital || |revoca- | | 762 ||||ID | |butes | | |||signature|| |tion | | 763 |||+-------+ +-------+ +-------+|+---------+| |referen-| | 764 ||+------------\----------------+ ^ | |ces | | 765 || \ | | +--------+ | 766 || \ 1 / | ^ | 767 |+----------------\----------------/--------+ | | 768 +------------------\--------------/-------------- /------+ 769 \ /2 ----3-----/ 770 +----------+ | / / 771 | Signed |\ v / | 772 |User data | \ +--------------------+ +------------+ 773 +----------+ \--->| Validation Process |---> |- Valid | 774 +---|--^-------|--^--+ 4 |- Invalid | 775 | | | | |- Validation| 776 v | v | | Incomplete| 777 +---------+ +--------+ +------------+ 778 |Signature| |Trusted | 779 | Policy | |Service | 780 | Issuer | |Provider| 781 +---------+ +--------+ 783 Figure 8: Illustration of an ES with Complete validation data (ES-C) 785 Internet Draft Electronic Signature Formats 787 At the same time as the validation process creates the ES-C, the 788 validation process may provide and/or record the values of certificates 789 and revocation status information used in ES-C, called the ES-X Long 790 (5). This is illustrated in figure 9: 792 +---------------------------------------------------- ES-X ---------+ 793 |+--------------------------------------- ES-C --------+ +--------+ | 794 ||+--- Elect.Signature (ES) ----+ +--------+ | |Complete| | 795 |||+-------+ +-------+ +-------+|+---------+|Complete| | |certifi-| | 796 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |cate | | 797 ||||ture | |Signed | |Signa- |||over ||cate and| | |and | | 798 ||||Policy | |Attri- | |ture |||digital ||revoca- | | |revoca- | | 799 ||||ID | |butes | | |||signature||tion | | |tion | | 800 |||+-------+ +---|---+ +-------+|+---------+|referen-| | |Data | | 801 ||+--------------\--------------+ ^ |ces | | +--------+ | 802 || \ | +--------+ | ^ | 803 || \ 1 2/ ^ | | | 804 |+------------------\--------------/-----------|-------+ / | 805 +--------------------\------------/-----------/-------------/-------+ 806 \ / ---3---/ / 807 +----------+ | / / -----------5-----/ 808 | Signed |\ v | | / 809 |User data | \ +--------------------+ +-----------+ 810 +----------+ \--->| Validation Process |---> | - Valid | 811 +---|--^-------|--^--+ 4 | - Invalid | 812 | | | | +-----------+ 813 v | v | 814 +---------+ +--------+ 815 |Signature| |Trusted | 816 | Policy | |Service | 817 | Issuer | |Provider| 818 +---------+ +--------+ 820 Figure 9: Illustration ES with eXtended validation data (Long) 822 Internet Draft Electronic Signature Formats 824 When the validation process creates the ES-C it may also create 825 extended forms of validation data. A first alternative is to timestamp 826 all data forming the Type 1 X-Timestamp (6). This is illustrated in 827 figure 10: 829 +---------------------------------------------------- ES-X -------+ 830 |+--------------------------------------- ES-C --------+ +------+ | 831 ||+--- Elect.Signature (ES) ----+ +--------+ | |Time- | | 832 |||+-------+ +-------+ +-------+|+---------+|Complete| | |stamp | | 833 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |over | | 834 ||||ture | |Signed | |Signa- |||over ||cate and| | |CES | | 835 ||||Policy | |Attri- | |ture |||digital ||revoca- | | +------+ | 836 ||||ID | |butes | | |||signature||tion | | ^ | 837 |||+-------+ +--|----+ +-------+|+---------+|referen-| | | | 838 ||+-------------|---------------+ ^ |ces | | | | 839 || | | +--------+ | | | 840 || \ 1 2/ ^ | | | 841 |+----------------\------------------/---------|-------+ | | 842 +------------------\----------------/----------/-------------/----+ 843 \ / ----3--/ / 844 +----------+ | / / --------------6---/ 845 | Signed |\ v | | / 846 |User data | \ +--------------------+ +-----------+ 847 +----------+ \--->| Validation Process |---> | - Valid | 848 +---|--^-------|--^--+ 4 | - Invalid | 849 | | | | +-----------+ 850 v | v | 851 +---------+ +--------+ 852 |Signature| |Trusted | 853 | Policy | |Service | 854 | Issuer | |Provider| 855 +---------+ +--------+ 857 Figure 10: Illustration of ES with eXtended validation data - Type 1 X- 858 Timestamp 860 Internet Draft Electronic Signature Formats 862 Another alternative is to timestamp the certificate and revocation 863 information references used to validate the electronic signature (but 864 not the signature) (6'); this is called Type 2 X-Timestamped. This is 865 illustrated in figure 11: 867 +---------------------------------------------------- ES-X ----------+ 868 |+--------------------------------------- ES-C --------+ +---------+ | 869 ||+--- Elect.Signature (ES) ----+ +--------+ | |Timestamp| | 870 |||+-------+ +-------+ +-------+|+---------+|Complete| | |over | | 871 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |Complete | | 872 ||||ture | |Signed | |Signa- |||over ||cate and| | |Certifi- | | 873 ||||Policy | |Attri- | |ture |||digital ||revoc. | | |cate and | | 874 ||||ID | |butes | | |||signature||refs | | |revoc. | | 875 |||+-------+ +---^---+ +-------+|+----^----++---^----+ | |refs | | 876 ||+--------------\--------------+ | | | +---------+ | 877 |+----------------\------------------/----------|------+ ^ | 878 +----------------1-\----------------/----------/--------------|------+ 879 \ / -----3--/ | 880 +----------+ | 2/ / --------------6'-----/ 881 | Signed |\ v | | / 882 |User data | \ +--------------------+ +-----------+ 883 +----------+ \--->| Validation Process |---> | - Valid | 884 +---|--^-------|--^--+ 4 | - Invalid | 885 | | | | +-----------+ 886 v | v | 887 +---------+ +--------+ 888 |Signature| |Trusted | 889 | Policy | |Service | 890 | Issuer | |Provider| 891 +---------+ +--------+ 893 Figure 11: Illustration of ES with eXtended validation data - Type 2 X- 894 Timestamp 896 Internet Draft Electronic Signature Formats 898 Before the algorithms used in any of electronic signatures become or 899 are likely, to be compromised or rendered vulnerable in the future, it 900 is necessary to timestamp the entire electronic signature, including 901 all the values of the validation and user data as an ES with Archive 902 validation data (ES-A) 904 An ES-A is illustrated in figure 12: 906 -------------------------------------------- ES-A --------------------+ 907 ----------------------------------------------------------------+ | 908 +------------------------------- EC-C --------++-----+ | | 909 | ||Time-| | | 910 |+-- Elect.Signature (ES) -+ +--------+||stamp| +-------+ | 911 ||+------++-------++-------|+------+|Complete|||over | Complete| | 912 |||Signa-||Other ||Digital||Time- ||certifi-|||CES | |certi- |+----| 913 |||ture ||Signed ||Signa- ||stamp ||cate and||+-----+ |ficate |Arch-| 914 |||Policy||Attri- ||ture ||over ||revoca- ||+------+ |and |ive | 915 |||ID ||butes || ||digit.||tion |||Time- | |revoca-|Time | 916 ||+------++---|---++-------||signa-||referen-|||stamp-| |tion |stamp| 917 |+------------|------------+|ture ||ces |||over | |data |+----| 918 | | +------++--------+|Complete\+-------+ ^ | 919 | | ^ ^ ||cert. | | | | 920 +-------------|----------------|---------|----+|and rev| | | | 921 \ | / |refs. | | | | 922 \ | / +-------+ | | | 923 -----------------\-------------|-------/------------------------+ | | 924 +----------+ \ | / / | 925 | Signed | \2 |3 / /--------------7-------/ | 926 |User data | \ | | / | 927 +-------\--+ \ | | / | 928 ---------\------------|--------|----|---/-----------------------------+ 929 \ v | | | 930 1\ +--------------------+ +-----------+ 931 \------>| Validation Process |---> | - Valid | 932 +---|--^-------|--^--+ 4 | - Invalid | 933 | | | | +-----------+ 934 v | v | 935 +---------+ +--------+ 936 |Signature| |Trusted | 937 | Policy | |Service | 938 | Issuer | |Provider| 939 +---------+ +--------+ 941 Figure 12: Illustration of an ES with Archive validation data (ES-A) 943 2.11 Additional optional features of an ES 945 This document also defines additional optional features of 946 an electronic signature to: 948 * indicate a commitment type being made by the signer; 949 * indicate the role under which a signature was created; 950 * support multiple signatures. 952 Internet Draft Electronic Signature Formats 954 3. Data structure of an Electronic Signature 956 This clause uses and builds upon the Cryptographic Message Syntax 957 (CMS), as defined in RFC 2630 [CMS], and Enhanced Security Services 958 (ESS), as defined in RFC 2634 [ESS]. The overall structure 959 of Electronic Signature is as defined in [CMS]. The Electronic 960 Signature (ES) uses attributes defined in [CMS], [ESS] and 961 this document. This document defines in full the ES attributes which it 962 uses and are not defined elsewhere. 964 The mandated set of attributes and the digital signature value is 965 defined as the minimum Electronic Signature (ES) required by this 966 document. A signature policy MAY mandate other signed attributes to be 967 present. 969 3.1 General Syntax 971 The general syntax of the ES is as defined in [CMS]. 973 3.2 Data Content Type 975 The data content type of the ES is as defined in [CMS]. 977 The data content type is intended to refer to arbitrary octet strings, 978 such as ASCII text files; the interpretation is left to the 979 application. Such strings need not have any internal structure 980 (although they could have their own ASN.1 definition or other 981 structure). 983 3.3 Signed-data Content Type 985 The Signed-data content type of the ES is as defined in [CMS]. 987 The signed-data content type consists of a content of any type and zero 988 or more signature values. Any number of signers in parallel can sign 989 any type of content. The typical application of the signed-data content 990 type represents one signer's digital signature on content of the data 991 content type. 993 To make sure that the verifier uses the right certificate, this 994 document mandates that the hash of the signers certificate is always 995 included in the Signing Certificate signed attribute. 997 3.4 SignedData Type 999 The syntax of the SignedData type of the ES is as defined in [CMS]. 1001 The fields of type SignedData have the meanings defined [CMS] except 1002 that: 1004 * version is the syntax version number. The value of version must 1005 be 3. 1007 Internet Draft Electronic Signature Formats 1009 * The identification of signer's certificate used to create the 1010 signature is always present as a signed attribute. 1012 * The degenerate case where there are no signers is not valid in 1013 this document. 1015 3.5 EncapsulatedContentInfo Type 1017 The syntax of the EncapsulatedContentInfo a type of the ES is as 1018 defined in [CMS]. 1020 For the purpose of long term validation as defined by this document, it 1021 is advisable that either the eContent is present, or the data which is 1022 signed is archived in such as way as to preserve the any data encoding. 1023 It is important that the OCTET STRING used to generate the signature 1024 remains the same every time either the verifier or an arbitrator 1025 validates the signature. 1027 The degenerate case where there are no signers is not valid in this 1028 document. 1030 3.6 SignerInfo Type 1032 The syntax of the SignerInfo a type of the ES is as defined in [CMS]. 1034 Per-signer information is represented in the type SignerInfo. In the 1035 case of multiple independent signatures, there is an instance 1036 of this field for each signer. 1038 The fields of type SignerInfo have the meanings defined in [CMS] 1039 except that signedAttributes must, as a minimum, contain the following 1040 attributes: 1042 * ContentType as defined in clause 3.7.1. 1043 * MessageDigest as defined in clause 3.7.2. 1044 * SigningTime as defined in clause 3.7.3. 1045 * SigningCertificate as defined in clause 3.8.1. 1046 * SignaturePolicyId as defined in clause 3.9.1. 1048 3.6.1 Message Digest Calculation Process 1050 The message digest calculation process is as defined in [CMS]. 1052 3.6.2 Message Signature Generation Process 1054 The input to the digital signature generation process is as defined in 1055 [CMS]. 1057 3.6.3 Message Signature Verification Process 1059 The procedures for CMS signed data validation are as defined in 1060 [CMS] and enhanced in this document. 1062 Internet Draft Electronic Signature Formats 1064 The input to the signature verification process includes the signer's 1065 public key verified as correct using either the ESS Signing 1066 Certificate attribute or the Other Signing Certificate attribute. 1068 3.7 CMS Imported Mandatory Present Attributes 1070 The following attributes MUST be present with the signed-data defined 1071 by this document. The attributes are defined in [CMS]. 1073 3.7.1 Content Type 1075 The syntax of the content-type attribute type of the ES is as defined 1076 in [CMS]. 1078 3.7.2 Message Digest 1080 The syntax of the message-digest attribute type of the ES is as defined 1081 in [CMS]. 1083 3.7.3 Signing Time 1085 The syntax of the message-digest attribute type of the ES is as defined 1086 in [CMS] and further qualified by this document. 1088 The signing-time attribute type specifies the time at which the signer 1089 claims to have performed the signing process. 1091 This present document recommends the use of GeneralizedTime. 1093 3.8 Alternative Signing Certificate Attributes 1095 One, and only one, of the following two alternative attributes MUST be 1096 present with the signed-data defined by this document to identify the 1097 signing certificate. Both attributes include an identifier and a hash 1098 of the signing certificate. The first, which is adopted in existing 1099 standards, may be only used with the SHA-1 hashing algorithm. The 1100 other shall be used when other hashing algorithms are to be supported. 1102 The signing certificate attribute is designed to prevent the simple 1103 substitution and re-issue attacks, and to allow for a restricted set of 1104 authorization certificates to be used in verifying a signature. 1106 3.8.1 ESS Signing Certificate Attribute Definition 1108 The syntax of the signing certificate attribute type of the ES is as 1109 defined in [ESS], and further qualified and profile in this document. 1111 The ESS signing certificate attribute must be a signed attribute. 1113 This document mandates the presence of this attribute as a signed CMS 1114 attribute, and the sequence must not be empty. The certificate used to 1115 verify the signature must be identified in the sequence, the Signature 1116 Validation Policy may mandate other certificate references to be 1117 present, that may include all the certificates up to the point of 1119 Internet Draft Electronic Signature Formats 1121 trust. The encoding of the ESSCertID for this certificate must include 1122 the issuerSerial field. 1124 The issuerAndSerialNumber present in the SignerInfo must be 1125 consistent with issuerSerial field. The certificate identified must be 1126 used during the signature verification process. If the hash of the 1127 certificate does not match the certificate used to verify the 1128 signature, the signature must be considered invalid. 1130 The sequence of policy information field is not used in this document. 1132 NOTE: Where an attribute certificate is used by the signer to associate 1133 a role, or other attributes of the signer, with the electronic 1134 signature this is placed in the Signer Attribute attribute as defined 1135 in clause 3.12.3. 1137 3.8.2 Other Signing Certificate Attribute Definition 1139 The following attribute is identical to the ESS SigningCertificate 1140 defined above except that this attribute can be used with hashing 1141 algorithms other than SHA-1. 1143 This attribute must be used in the same manner as defined above for 1144 the ESS SigningCertificate attribute. 1146 The following object identifier identifies the signing certificate 1147 attribute: 1149 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 1150 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1151 smime(16) id-aa(2) 19 } 1153 The signing certificate attribute value has the ASN.1 syntax 1154 OtherSigningCertificate 1156 OtherSigningCertificate ::= SEQUENCE { 1157 certs SEQUENCE OF OtherCertID, 1158 policies SEQUENCE OF PolicyInformation OPTIONAL 1159 -- NOT USED IN THIS DOCUMENT 1160 } 1162 OtherCertID ::= SEQUENCE { 1163 otherCertHash OtherHash, 1164 issuerSerial IssuerSerial OPTIONAL 1165 } 1167 OtherHash ::= CHOICE { 1168 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 1169 otherHash OtherHashAlgAndValue 1170 } 1172 OtherHashValue ::= OCTET STRING 1174 Internet Draft Electronic Signature Formats 1176 OtherHashAlgAndValue ::= SEQUENCE { 1177 hashAlgorithm AlgorithmIdentifier, 1178 hashValue OtherHashValue 1179 } 1181 3.9 Additional Mandatory Attributes 1183 3.9.1 Signature policy Identifier 1185 This document mandates that a reference to the signature policy, is 1186 included in the signedData, this reference is either explicitly 1187 identified or implied by the semantics of the signed content and other 1188 external data. A signature policy defines the rules for creation and 1189 validation of an electronic signature, is included as a signed 1190 attribute with every signature. The signature policy identifier must be 1191 a signed attribute. 1193 The following object identifier identifies the signature policy 1194 identifier attribute: 1196 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 1197 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1198 smime(16) id-aa(2) 15 } 1200 Signature-policy-identifier attribute values have ASN.1 type 1201 SignaturePolicyIdentifier. 1203 SignaturePolicyIdentifier ::= CHOICE{ 1204 SignaturePolicyId SignaturePolicyId, 1205 SignaturePolicyImplied SignaturePolicyImplied } 1207 SignaturePolicyId ::= SEQUENCE { 1208 sigPolicyIdentifier SigPolicyId, 1209 sigPolicyHash SigPolicyHash, 1210 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 1211 SigPolicyQualifierInfo OPTIONAL 1212 } 1214 SignaturePolicyImplied ::= NULL 1216 The presence of the NULL type indicates that the signature policy is 1217 implied by the semantics of the signed data and other external data. 1219 Internet Draft Electronic Signature Formats 1221 The sigPolicyId field contains an object-identifier which 1222 uniquely identifies a specific version of the signature policy. The 1223 syntax of this field is as follows: 1225 SigPolicyId ::= OBJECT IDENTIFIER 1227 The sigPolicyHash field contains the identifier of the hash algorithm 1228 and the hash of the value of the signature policy. 1230 If the signature policy is defined using a computer processable 1231 notation like ASN.1, then the hash is calculated on the value without 1232 the outer type and length fields and the hashing algorithm must be as 1233 specified in the field signPolicyHshAlg. 1235 If the signature policy is defined using another structure, the type of 1236 structure and the hashing algorithm must be either specified as part 1237 of the signature policy, or indicated using a signature policy 1238 qualifier. 1240 SigPolicyHash ::= ETSIHashAlgAndValue 1242 A signature policy identifier may be qualified with other information 1243 about the qualifier. The semantics and syntax of the qualifier is as 1244 associated with the object-identifier in the sigPolicyQualifierId 1245 field. The general syntax of this qualifier is as follows: 1247 SigPolicyQualifierInfo ::= SEQUENCE { 1248 sigPolicyQualifierId SigPolicyQualifierId, 1249 sigQualifier ANY DEFINED BY sigPolicyQualifierId 1250 } 1252 This document specifies the following qualifiers: 1254 * spuri: This contains the web URI or URL reference to the 1255 signature policy 1257 * spUserNotice: This contains a user notice which should be 1258 displayed whenever the signature is validated. 1260 Internet Draft Electronic Signature Formats 1262 -- sigpolicyQualifierIds defined in this document 1264 SigPolicyQualifierId ::= OBJECT IDENTIFIER 1266 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 1267 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1268 smime(16) id-spq(5) 1 } 1270 SPuri ::= IA5String 1272 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 1273 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1274 smime(16) id-spq(5) 2 } 1276 SPUserNotice ::= SEQUENCE { 1277 noticeRef NoticeReference OPTIONAL, 1278 explicitText DisplayText OPTIONAL 1279 } 1281 NoticeReference ::= SEQUENCE { 1282 organization DisplayText, 1283 noticeNumbers SEQUENCE OF INTEGER 1284 } 1286 DisplayText ::= CHOICE { 1287 visibleString VisibleString (SIZE (1..200)), 1288 bmpString BMPString (SIZE (1..200)), 1289 utf8String UTF8String (SIZE (1..200)) 1290 } 1292 3.10 CMS Imported Optional Attributes 1294 The following attributes MAY be present with the signed-data defined by 1295 this document. The attributes are defined in ref [CMS] and are imported 1297 into this specification and were appropriate qualified and profiling by 1298 this document. 1300 3.10.1 Countersignature 1302 The syntax of the countersignature attribute type of the ES is as 1303 defined in [CMS]. The countersignature attribute must be an unsigned 1304 attribute. 1306 3.11 ESS Imported Optional Attributes 1308 The following attributes MAY be present with the signed-data defined by 1309 this document. The attributes are defined in ref [ESS] and are imported 1310 into this specification and were appropriate qualified and profiling 1311 by this document. 1313 Internet Draft Electronic Signature Formats 1315 3.11.1 Content Reference Attribute 1317 The content reference attribute is a link from one SignedData to 1318 another. It may be used to link a reply to the original message to 1319 which it refers, or to incorporate by reference one SignedData into 1320 another. 1322 The content reference attribute MUST be used as defined in [ESS]. The 1323 content reference MUST be a signed attribute. 1325 The syntax of the content reference attribute type of the ES is as 1326 defined in [ESS]. 1328 3.11.2 Content Identifier Attribute 1330 The content identifier attribute provides an identifier for the signed 1331 content for use when reference may be later required to that content, 1332 for example in the content reference attribute in other signed data 1333 sent later. 1335 The content identifier must be a signed attribute. 1337 The syntax of the content identifier attribute type of the ES is as 1338 defined in [ESS]. 1340 The minimal signedContentIdentifier should contain a concatenation of 1341 user-specific identification information (such as a user name or public 1342 keying material identification information), a GeneralizedTime string, 1343 and a random number. 1345 3.11.3 Content Hints Attribute 1347 The content hints attribute provides information that describes the 1348 format of the signed content. It may be used by the signer to indicate 1349 to a verifier the precise format that MUST be used to present the data 1350 (e.g. text, voice, video) to a verifier. This attribute MUST be 1351 present when it is mandatory to present the signed data to human users 1352 on verification. 1354 The syntax of the content hints attribute type of the ES is as defined 1355 in ESS (RFC 2634, section 2.9 [9]). 1357 When used to indicate the precise format of the data to be presented to 1358 the user the following rules apply: 1360 The contentType (defined in RFC 2630 [8]) indicates the type of the 1361 associated content. It is an object identifier (i.e. a unique string of 1362 integers) assigned by an authority that defines the content type. 1364 Internet Draft Electronic Signature Formats 1366 The UTF8String shall define the presentation format. The format may be 1367 defined by MIME types as indicated below. 1369 Note 1: The contentType can be id-data defined in CMS (RFC 2630 [8]). 1370 The UTF8String can be used to indicate the encoding of the data, like 1371 MIME type. RFC 2045 [25] provides a common structure for encoding a 1372 range of electronic documents and other multi-media types, see annex B 1373 for further information, a system supporting verification of electronic 1374 signature may present information to users in the form identified by 1375 the MIME type. 1377 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1378 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1380 3.12 Additional Optional Attributes 1382 3.12.1 Commitment Type Indication Attribute 1384 There may be situation were a signer wants to explicitly indicate to a 1385 verifier that by signing the data, it illustrates a type of commitment 1386 on behalf of the signer. The commitmentTypeIndication attribute conveys 1387 such information. 1389 The commitmentTypeIndication attribute must be a signed attribute. 1391 The commitment type may be: 1393 * defined as part of the signature policy, in which case the 1394 commitment type has precise semantics that is defined as part of 1395 the signature policy. 1397 * be a registered type, in which case the commitment type has 1398 precise semantics defined by registration, under the rules of the 1399 registration authority. Such a registration authority may be a 1400 trading association or a legislative authority. 1402 The signature policy specifies a set of attributes that it 1403 "recognizes". This "recognized" set includes all those commitment types 1404 defined as part of the signature policy as well as any externally 1405 defined commitment types that the policy may choose to recognize. Only 1406 recognized commitment types are allowed in this field. 1408 Internet Draft Electronic Signature Formats 1410 The following object identifier identifies the commitment type 1411 indication attribute: 1413 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1414 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 1416 Commitment-Type-Indication attribute values have ASN.1 type 1417 CommitmentTypeIndication. 1419 CommitmentTypeIndication ::= SEQUENCE { 1420 commitmentTypeId CommitmentTypeIdentifier, 1421 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 1422 CommitmentTypeQualifier OPTIONAL 1423 } 1425 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 1427 CommitmentTypeQualifier ::= SEQUENCE { 1428 commitmentTypeIdentifier CommitmentTypeIdentifier, 1429 qualifier ANY DEFINED BY 1430 commitmentTypeIdentifier 1431 } 1433 The use of any qualifiers to the commitment type is outside the scope 1434 of this document. 1436 The following generic commitment types are defined in this document: 1438 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member- 1439 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1440 cti(6) 1} 1442 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member- 1443 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1444 cti(6) 2} 1446 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 1447 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1448 smime(16) cti(6) 3} 1450 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- 1451 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1452 cti(6) 4} 1454 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) 1455 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1456 smime(16) cti(6) 5} 1458 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) 1459 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1460 smime(16) cti(6) 6} 1462 Internet Draft Electronic Signature Formats 1464 These generic commitment types have the following meaning: 1466 Proof of origin indicates that the signer recognizes to have created, 1467 approved and sent the message. 1469 Proof of receipt indicates that signer recognizes to have received the 1470 content of the message. 1472 Proof of delivery indicates that the TSP providing that indication has 1473 delivered a message in a local store accessible to the recipient of the 1474 message. 1476 Proof of sender indicates that the entity providing that indication has 1477 sent the message (but not necessarily created it). 1479 Proof of approval indicates that the signer has approved the content of 1480 the message. 1482 Proof of creation indicates that the signer has created the message 1483 (but not necessarily approved, nor sent it). 1485 3.12.2 Signer Location attribute 1487 The signer-location attribute is an attribute which specifies a 1488 mnemonic for an address associated with the signer at a particular 1489 geographical (e.g. city) location. The mnemonic is registered in the 1490 country in which the signer is located and is used in the provision of 1491 the Public Telegram Service (according to ITU-T Recommendation F.1 1492 [PTS]). 1494 The signer-location attribute must be a signed attribute. 1496 The following object identifier identifies the signer-location 1497 attribute: 1499 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1500 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 1502 Signer-location attribute values have ASN.1 type SignerLocation. 1504 SignerLocation ::= SEQUENCE { 1505 -- at least one of the following must be present 1506 countryName [0] DirectoryString OPTIONAL, 1507 -- as used to name a Country in X.500 1508 localityName [1] DirectoryString OPTIONAL, 1509 -- as used to name a locality in X.500 1510 postalAdddress [2] PostalAddress OPTIONAL 1511 } 1513 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 1515 Internet Draft Electronic Signature Formats 1517 3.12.3 Signer Attributes attribute 1519 The signer-attributes attribute is an attribute which specifies 1520 additional attributes of the signer (e.g. role). 1522 It may be either: 1524 * claimed attributes of the signer; or 1525 * certified attributes of the signer; 1527 The signer-attributes attribute must be a signed attribute. 1529 The following object identifier identifies the signer-attribute 1530 attribute: 1532 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1533 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 1535 signer-attribute attribute values have ASN.1 type SignerAttribute. 1537 SignerAttribute ::= SEQUENCE OF CHOICE { 1538 claimedAttributes [0] ClaimedAttributes, 1539 certifiedAttributes [1] CertifiedAttributes 1540 } 1542 ClaimedAttributes ::= SEQUENCE OF Attribute 1544 CertifiedAttributes ::= AttributeCertificate 1545 -- as defined in X.509 : see section 10.3 1547 NOTE: The claimed and certified attribute are imported from ITU-T 1548 Recommendations X.501 [16] and ITU-T Recommendation X.509 : Draft 1549 Amendment on Certificate Extensions, October 1999. 1551 3.12.4 Content Timestamp attribute 1553 The content timestamp attribute is an attribute which is the timestamp 1554 of the signed data content before it is signed. 1556 The content timestamp attribute must be a signed attribute. 1558 The following object identifier identifies the signer-attribute 1559 attribute: 1561 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) 1562 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1563 smime(16) id-aa(2) 20} 1565 Content timestamp attribute values have ASN.1 type ContentTimestamp: 1566 ContentTimestamp::= TimeStampToken 1568 Internet Draft Electronic Signature Formats 1570 The value of messageImprint field within TimeStampToken must be a hash 1571 of the value of eContent field within encapContentInfo within the 1572 signedData. 1574 For further information and definition of TimeStampToken see [TSP]. 1576 3.13 Support for Multiple Signatures 1578 3.13.1 Independent Signatures 1580 Multiple independent signatures are supported by independent SignerInfo 1581 from each signer. 1583 Each SignerInfo must include all the attributes required under this 1584 document and must be processed independently by the verifier. 1586 3.13.2 Embedded Signatures 1588 Multiple embedded signatures are supported using the counter-signature 1589 unsigned attribute (see clause 3.10.1). Each counter signature is 1590 carried in Countersignature held as an unsigned attribute to the 1591 SignerInfo to which the counter-signature is applied. 1593 4. Validation Data 1595 This clause specifies the validation data structures which builds on 1596 the electronic signature specified in clause 3. This includes: 1598 * Timestamp applied to the electronic signature value. 1600 * Complete validation data which comprises the timestamp of the 1601 signature value, plus references to all the certificates and 1602 revocation information used for full validation of the electronic 1603 signature. 1605 The following optional eXtended forms of validation data are also 1606 defined: 1608 * X-timestamp: There are two types of timestamp used in extended 1609 validation data defined by this document. 1611 - Type 1 -Timestamp which comprises a timestamp over the ES 1612 with Complete validation data (ES-C). 1614 - Type 2 X-Timestamp which comprises of a timestamp over the 1615 certification path references and the revocation information 1616 references used to support the ES-C. 1618 Internet Draft Electronic Signature Formats 1620 * X-Long : This comprises a Complete validation data 1621 plus the actual values of all the certificates and 1622 revocation information used in the ES-C. 1624 * X-Long-Timestamp: This comprises a Type 1 or Type 2 1625 X-Timestamp plus the actual values of all the 1626 certificates and revocation information used in the 1627 ES-C. 1629 This clause also specifies the data structures used in Archive 1630 validation data: 1632 * Archive validation data comprises a Complete validation data, 1633 the certificate and revocation values (as in a X-Long 1634 validation data), any other existing X-timestamps, plus the 1635 Signed User data and an additional archive timestamp over all 1636 that data. An archive timestamp may be repeatedly applied 1637 after long periods to maintain validity when electronic 1638 signature and timestamping algorithms weaken. 1640 The additional data required to create the forms of electronic 1641 signature identified above is carried as unsigned attributes 1642 associated with an individual signature by being placed in the 1643 unsignedAttrs field of SignerInfo. Thus all the attributes defined 1644 in clause 4 are unsigned attributes. 1646 NOTE: Where multiple signatures are to be supported, as described in 1647 clause 3.13, each signature has a separate SignerInfo. Thus, each 1648 signature requires its own unsigned attribute values to create ES-T, 1649 ES-C etc. 1651 4.1 Electronic Signature Timestamp 1653 An Electronic Signature with Timestamp is an Electronic Signature for 1654 which part, but not all, of the additional data required for validation 1655 is available (e.g. some certificates and revocation information is 1656 available but not all). 1658 The minimum structure Timestamp validation data is the Signature 1659 Timestamp Attribute as defined in clause 4.1.1 over the ES signature 1660 value. 1662 4.1.1 Signature Timestamp Attribute Definition 1664 The Signature Timestamp attribute is timestamp of the signature value. 1665 It is an unsigned attribute. Several instances of this attribute from 1666 different TSAs may occur with an electronic signature. 1668 Internet Draft Electronic Signature Formats 1670 The Signature Validation Policy specifies, in the 1671 signatureTimestampDelay field of TimestampTrustConditions, a maximum 1672 acceptable time difference which is allowed between the time indicated 1673 in the signing time attribute and the time indicated by the Signature 1674 Timestamp attribute. If this delay is exceeded then the electronic 1675 signature must be considered as invalid. 1677 The following object identifier identifies the Signature Timestamp 1678 attribute: 1680 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 1681 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1682 id-aa(2) 14} 1684 The Signature timestamp attribute value has ASN.1 type 1685 SignatureTimeStampToken. 1687 SignatureTimeStampToken ::= TimeStampToken 1689 The value of messageImprint field within TimeStampToken must be a hash 1690 of the value of signature field within SignerInfo for the signedData 1691 being timestamped. 1693 For further information and definition of TimeStampToken see [TSP] 1695 4.2 Complete Validation Data 1697 An electronic signature with complete validation data is an Electronic 1698 Signature for which all the additional data required for validation 1699 (i.e. all certificates and revocation information) is available. 1700 Complete validation data (ES-C) build on the electronic signature 1701 Timestamp as defined above. 1703 The minimum structure of a Complete validation data is: 1705 * the Signature Timestamp Attribute, as defined in clause 4.1.1; 1706 * Complete Certificate Refs, as defined in clause 4.2.1; 1707 * Complete Revocation Refs, as defined in clause 4.2.2. 1709 The Complete validation data MAY also include the following additional 1710 information, forming a X-Long validation data, for use if later 1711 validation processes may not have access to this information: 1713 * Complete Certificate Values, as defined in clause 4.2.3; 1714 * Complete Revocation Values, as defined in clause 4.2.4. 1716 The Complete validation data MAY also include one of the following 1717 additional attributes, forming a X-Timestamp validation data, to 1718 provide additional protection against later CA compromise and provide 1719 integrity of the validation data used: 1721 * ES-C Timestamp, as defined in clause 4.2.5; or 1722 * Time-Stamped Certificates and CRLs references, as defined in 1723 clause 4.2.6. 1725 Internet Draft Electronic Signature Formats 1727 NOTE 1: As long as the CA's are trusted such that these keys cannot 1728 be compromised or the cryptography used broken, the ES-C provides long 1729 term proof of a valid electronic signature. 1731 A valid electronic signature is an electronic signature which passes 1732 validation according to a signature validation policy. 1734 NOTE 2: The ES-C provides the following important property for long 1735 standing signatures; that is having been found once to be valid, must 1736 continue to be so months or years later. Long after the validity period 1737 of the certificates have expired, or after the user key has been 1738 compromised. 1740 4.2.1 Complete Certificate Refs Attribute Definition 1742 The Complete Certificate Refs attribute is an unsigned attribute. It 1743 references the full set of CA certificates that have been used to 1744 validate a ES with Complete validation data (ES-C) up to (but not 1745 including) the signer's certificate. Only a single instance of this 1746 attribute must occur with an electronic signature. 1748 Note: The signer's certified is referenced in the signing certificate 1749 attribute (see clause 3.1). 1751 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1752 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 1754 The complete certificate refs attribute value has the ASN.1 syntax 1755 CompleteCertificateRefs. 1757 CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID 1759 OTHERCertID is defined in clause 3.8.2. 1761 The IssuerSerial that must be present in OTHERCertID. The certHash 1762 must match the hash of the certificate referenced. 1764 NOTE: Copies of the certificate values may be held using the 1765 Certificate Values attribute defined in clause 4.3.1. 1767 4.2.2 Complete Revocation Refs Attribute Definition 1769 The Complete Revocation Refs attribute is an unsigned attribute. Only a 1770 single instance of this attribute must occur with an electronic 1771 signature. It references the full set of the CRL or OCSP responses that 1772 have been used in the validation of the signer and CA certificates 1773 used in ES with Complete validation data. 1775 The following object identifier identifies the CompleteRevocationRefs 1776 attribute: 1778 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1779 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 1781 Internet Draft Electronic Signature Formats 1783 The complete revocation refs attribute value has the ASN.1 syntax 1784 CompleteRevocationRefs. 1786 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 1788 CrlOcspRef ::= SEQUENCE { 1789 crlids [0] CRLListID OPTIONAL, 1790 ocspids [1] OcspListID OPTIONAL, 1791 otherRev [2] OtherRevRefs OPTIONAL 1792 } 1794 CompleteRevocationRefs must contain one CrlOcspRef for the signing 1795 certificate, followed by one for each OTHERCertID in the 1796 CompleteCertificateRefs attribute. The second and subsequent CrlOcspRef 1797 fields must be in the same order as the OTHERCertID to which they 1798 relate. At least one of CRLListID or OcspListID or OtherRevRefs should 1799 be present for all but the "trusted" CA of the certificate path. 1801 CRLListID ::= SEQUENCE { 1802 crls SEQUENCE OF CrlValidatedID} 1804 CrlValidatedID ::= SEQUENCE { 1805 crlHash ETSIHash, 1806 crlIdentifier CrlIdentifier OPTIONAL} 1808 CrlIdentifier ::= SEQUENCE { 1809 crlissuer Name, 1810 crlIssuedTime UTCTime, 1811 crlNumber INTEGER OPTIONAL 1812 } 1814 OcspListID ::= SEQUENCE { 1815 ocspResponses SEQUENCE OF OcspResponsesID} 1817 OcspResponsesID ::= SEQUENCE { 1818 ocspIdentifier OcspIdentifier, 1819 ocspRepHash ETSIHash OPTIONAL 1820 } 1822 OcspIdentifier ::= SEQUENCE { 1823 ocspResponderID ResponderID, 1824 -- As in OCSP response data 1825 producedAt GeneralizedTime 1826 -- As in OCSP response data 1827 } 1829 When creating an crlValidatedID, the crlHash is computed over the 1830 entire DER encoded CRL including the signature. The crlIdentifier would 1831 normally be present unless the CRL can be inferred from other 1832 information. 1834 Internet Draft Electronic Signature Formats 1836 The crlIdentifier is to identify the CRL using the issuer name and the 1837 CRL issued time which must correspond to the time "thisUpdate" 1838 contained in the issued CRL. The crlListID attribute is an unsigned 1839 attribute. In the case that the identified CRL is a Delta CRL then 1840 references to the set of CRLs to provide a complete revocation list 1841 must be included. 1843 The OcspIdentifier is to identify the OSCP response using the issuer 1844 name and the time of issue of the OCSP response which must correspond 1845 to the time "producedAt" contained in the issued OCSP response. Since 1846 it may be needed to make the difference between two OCSP responses 1847 received within the same second, then the hash of the response 1848 contained in the OcspResponsesID may be needed to solve the ambiguity. 1850 NOTE: Copies of the CRL and OCSP responses values may be held using 1851 the Revocation Values attribute defined in clause 4.3.2. 1853 OtherRevRefs ::= SEQUENCE { 1854 otherRevRefType OtherRevRefType, 1855 otherRevRefs ANY DEFINED BY otherRevRefType 1856 } 1858 OtherRevRefType ::= OBJECT IDENTIFIER 1860 The syntax and semantics of other revocation references is outside the 1861 scope of this document. The definition of the syntax of the other form 1862 of revocation information is as identified by OtherRevRefType. 1864 4.3 Extended Validation Data 1866 4.3.1 Certificate Values Attribute Definition 1868 The Certificate Values attribute is an unsigned attribute. Only a 1869 single instance of this attribute must occur with an electronic 1870 signature. It holds the values of certificates referenced in the 1871 CompleteCertificateRefs attribute. 1873 Note: If an Attribute Certificate is used, it is not provided in this 1874 structure but must be provided by the signer as a signer-attributes 1875 attribute (see clause 12.3). 1877 The following object identifier identifies the CertificateValues 1878 attribute: 1880 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1881 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 1883 The certificate values attribute value has the ASN.1 syntax 1884 CertificateValues. 1886 CertificateValues ::= SEQUENCE OF Certificate 1888 Certificate is defined in RFC2459 and ITU-T Recommendation X.509 [1]) 1890 Internet Draft Electronic Signature Formats 1892 4.3.2 Revocation Values Attribute Definition 1894 The Revocation Values attribute is an unsigned attribute. Only a single 1895 instance of this attribute must occur with an electronic signature. It 1896 holds the values of CRLs and OCSP referenced in the 1897 CompleteRevocationRefs attribute. 1899 The following object identifier identifies the Revocation Values 1900 attribute: 1902 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- 1903 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1904 id-aa(2) 24} 1906 The revocation values attribute value has the ASN.1 syntax 1907 RevocationValues. 1909 RevocationValues ::= SEQUENCE { 1910 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 1911 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 1912 otherRevVals [2] OtherRevVals 1913 } 1915 OtherRevVals ::= SEQUENCE { 1916 otherRevValType OtherRevValType, 1917 otherRevVals ANY DEFINED BY otherRevValType 1918 } 1920 OtherRevValType ::= OBJECT IDENTIFIER 1922 The syntax and semantics of the other revocation values is outside the 1923 scope of this document. The definition of the syntax of the other form 1924 of revocation information is as identified by OtherRevRefType. 1926 CertificateList is defined in RFC 2459 [RFC2459] and in ITU-T 1927 Recommendation X.509 [X509]). 1929 BasicOCSPResponse is defined in RFC 2560 [OCSP]. 1931 4.3.3 ES-C Timestamp Attribute Definition 1933 This attribute is used for the Type 1 X-Timestamped validation data. 1934 The ES-C Timestamp attribute is an unsigned attribute. It is timestamp 1935 of a hash of the electronic signature and the complete validation data 1936 (ES-C). It is a special purpose TimeStampToken Attribute which 1937 timestamps the ES-C. Several instances instance of this attribute may 1938 occur with an electronic signature from different TSAs. 1940 The following object identifier identifies the ES-C Timestamp 1941 attribute: 1943 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member- 1944 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1945 id-aa(2) 25} 1947 Internet Draft Electronic Signature Formats 1949 The ES-C timestamp attribute value has the ASN.1 syntax 1950 ESCTimeStampToken. 1952 ESCTimeStampToken ::= TimeStampToken 1954 The value of messageImprint field within TimeStampToken must be a hash 1955 of the concatenated values (without the type or length encoding for 1956 that value) of the following data objects as present in the ES with 1957 Complete validation data (ES-C): 1959 * signature field within SignerInfo; 1961 * SignatureTimeStampToken attribute; 1963 * CompleteCertificateRefs attribute; 1965 * CompleteRevocationRefs attribute. 1967 For further information and definition of the Time Stamp Token see 1968 [TSP]. 1970 4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 1972 This attribute is used for the Type 2 X-Timestamp validation data. A 1973 TimestampedCertsCRLsRef attribute is an unsigned attribute. It is a 1974 list of referenced certificates and OCSP responses/CRLs which are been 1975 timestamped to protect against certain CA compromises. Its syntax is as 1976 follows: 1978 The following object identifier identifies the TimestampedCertsCRLsRef 1979 attribute: 1981 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 1982 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1983 id-aa(2) 26} 1985 The attribute value has the ASN.1 syntax TimestampedCertsCRLs. 1987 TimestampedCertsCRLs ::= TimeStampToken 1989 The value of messageImprint field within TimeStampToken must be a hash 1990 of the concatenated values (without the type or length encoding for 1991 that value) of the following data objects as present in the ES with 1992 Complete validation data (ES-C): 1994 * CompleteCertificateRefs attribute; 1995 * CompleteRevocationRefs attribute. 1997 4.4 Archive Validation Data 1999 Where an electronic signature is required to last for a very long time, 2000 and a the timestamp on an electronic signature is in danger of being 2001 invalidated due to algorithm weakness or limits in the validity period 2002 of the TSA certificate, then it may be required to timestamp the 2004 Internet Draft Electronic Signature Formats 2006 electronic signature several times. When this is required an archive 2007 timestamp attribute may be required. This timestamp may be repeatedly 2008 applied over a period of time. 2010 4.4.1 Archive Timestamp Attribute Definition 2012 The Archive Timestamp attribute is timestamp of the user data and the 2013 entire electronic signature. If the Certificate values and Revocation 2014 Values attributes are not present these attributes must be added to 2015 the electronic signature prior to the timestamp. The Archive Timestamp 2016 attribute is an unsigned attribute. Several instances of this attribute 2017 may occur with on electronic signature both over time and from 2018 different TSAs. 2020 The following object identifier identifies the Nested Archive Timestamp 2021 attribute: 2023 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2024 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2025 id-aa(2) 27} 2027 Archive timestamp attribute values have the ASN.1 syntax 2028 ArchiveTimeStampToken 2030 ArchiveTimeStampToken ::= TimeStampToken 2032 The value of messageImprint field within TimeStampToken must be a hash 2033 of the concatenated values (without the type or length encoding for 2034 that value) of the following data objects as present in the electronic 2035 signature: 2037 * encapContentInfo eContent OCTET STRING; 2038 * signedAttributes; 2039 * signature field within SignerInfo; 2040 * SignatureTimeStampToken attribute; 2041 * CompleteCertificateRefs attribute; 2042 * CompleteRevocationData attribute; 2043 * CertificateValues attribute 2044 (If not already present this information must be included in 2045 the ES-A); 2046 * RevocationValues attribute 2047 (If not already present this information must be included in 2048 the ES-A); 2049 * ESCTimeStampToken attribute if present; 2050 * TimestampedCertsCRLs attribute if present; 2051 * any previous ArchiveTimeStampToken attributes. 2053 For further information and definition of TimeStampToken see [TSP] 2055 The timestamp should be created using stronger algorithms (or longer 2056 key lengths) than in the original electronic signatures. 2058 Internet Draft Electronic Signature Formats 2060 5. Security considerations 2062 5.1 Protection of Private Key 2064 The security of the electronic signature mechanism defined in this 2065 document depends on the privacy of the signer's private key. 2066 Implementations must take steps to ensure that private keys cannot be 2067 compromised. 2069 5.2 Choice of Algorithms 2071 Implementers should be aware that cryptographic algorithms become 2072 weaker with time. As new cryptoanalysis techniques are developed and 2073 computing performance improves, the work factor to break a particular 2074 cryptographic algorithm will reduce. Therefore, cryptographic algorithm 2075 implementations should be modular allowing new algorithms to be readily 2076 inserted. That is, implementers should be prepared for the set of 2077 mandatory to implement algorithms to change over time. 2079 6. Conformance Requirements 2081 This document only defines conformance requirements up to a ES with 2082 Complete validation data (ES-C). This means that none of the extended 2083 and archive forms of Electronic Signature (ES-X, ES-A) need to be 2084 implemented to get conformance to this standard. 2086 This document mandates support for elements of the signature policy. 2088 6.1 Signer 2090 A system supporting signers according to this document must, at a 2091 minimum, support generation of an electronic signature consisting of 2092 the following components: 2094 * The general CMS syntax and content type as defined in RFC 2630 2095 (see clauses 4.1 and 4.2). 2097 * CMS SignedData as defined in RFC 2630 with version set to 3 2098 and at least one SignerInfo must be present 2099 (see clauses 4.3, 4.4, 4.5, 4.6). 2101 * The following CMS Attributes as defined in RFC 2630 : 2103 - ContentType; This must always be present 2104 (see clause 3.7.1); 2106 - MessageDigest; This must always be present 2107 (see clause 3.7.2); 2109 - SigningTime; This must always be present 2110 (see clause 3.7.3). 2112 Internet Draft Electronic Signature Formats 2114 * The following ESS Attributes as defined in RFC 2634 : 2116 - SigningCertificate: This must be set as defined 2117 in clauses 3.8.1 and 3.8.2. 2119 * The following Attributes as defined in clause 3.9: 2120 - SignaturePolicyIdentifier; This must always be present. 2122 * Public Key Certificates as defined in ITU-T Recommendation 2123 X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1). 2125 6.2 Verifier using timestamping 2127 A system supporting verifiers according to this document with 2128 timestamping facilities must, at a minimum, support: 2130 * Verification of the mandated components of an electronic 2131 signature, as defined in clause 5.1. 2133 * Signature Timestamp attribute, as defined in clause 4.1.1. 2135 * Complete Certificate Refs attribute, as defined in 2136 clause 4.2.1. 2138 * Complete Revocation Refs Attribute, as defined in 2139 clause 4.2.2. 2141 * Public Key Certificates, as defined in ITU-T 2142 Recommendation X.509 and profiled in RFC 2459. 2144 * Either of: 2146 - Certificate Revocation Lists. as defined in ITU-T 2147 Recommendation X.509 [1] and profiled in RFC 2459 [7]; 2148 or 2150 - On-line Certificate Status Protocol responses, as 2151 defined in RFC 2560. 2153 6.3 Verifier using secure records 2155 A system supporting verifiers according to the present document shall, 2156 at a minimum, support: 2158 * Verification of the mandated components of an electronic 2159 signature, as defined in subclause 5.1. 2161 * Complete Certificate Refs attribute, as defined in 2162 subclause 4.2.1. 2164 Internet Draft Electronic Signature Formats 2166 * Complete Revocation Refs Attribute, as defined in 2167 subclause 9.2.2. 2169 * A record shall be maintained, which cannot be undetectably 2170 modified, of the electronic signature and the time when the 2171 signature was first validated using the referenced 2172 certificates and revocation information. 2174 * Public Key Certificates, as defined in ITU-T Recommendation 2175 X.509 [1] and profiled in RFC 2459 [7] (see subclause 10.1). 2177 * Either of: 2178 - Certificate Revocation Lists. as defined in ITU-T 2179 Recommendation X.509 [1] and profiled in RFC 2459 [7] 2180 Or 2182 - On-line Certificate Status Protocol, as defined 2183 in RFC 2560 [8] (see subclause 10.3). 2185 7. References 2187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2188 Requirement Levels", BCP 14, RFC 2119, March 1997. 2190 [ESS] P. Hoffman, "Enhanced Security Services for S/MIME", 2191 RFC 2634, June 1999 2193 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, 2194 June 1999. 2196 [OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. 2197 On-line Status Certificate Protocol, RFC 2560. 2199 [TSP] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Time Stamp Protocol 2200 (TSP), (under progress). June 2000. 2202 [PTS] Public Telegram Service. ITU-T Recommendation F1. XXXX 2204 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 2205 Key Infrastructure, Certificate and CRL Profile," RFC 2459, January 2206 1999. 2208 [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards 2209 (PKCS)", RSA Data Security Inc., Redwood City, California, November 2210 1993 Release. 2212 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 2213 Non-Repudiation Framework. April 1997. 2215 [ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic 2216 Signature Formats. Note: copies of ETSI ES 210 733 can be freely 2217 downloaded from the ETSI web site www.etsi.org. 2219 Internet Draft Electronic Signature Formats 2221 8. Authors' Addresses 2223 This Informational RFC has been produced in ETSI TC-SEC. 2225 ETSI 2226 F-06921 Sophia Antipolis, Cedex - FRANCE 2227 650 Route des Lucioles - Sophia Antipolis 2228 Valbonne - France 2229 Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 2230 secretariat@etsi.fr 2231 http://www.etsi.org 2233 Contact Point 2235 Harri Rasilainen 2236 ETSI 2237 650 Route des Lucioles 2238 F-06921 Sophia Antipolis, Cedex 2239 FRANCE 2240 harri.rasilainen@etsi.fr 2242 Denis Pinkas 2243 Bull S.A. 2244 12, rue de Paris 2245 B.P. 59 2246 78231 Le Pecq 2247 FRANCE 2248 Denis.Pinkas @bull.net 2250 John Ross 2251 Security & Standards 2252 192 Moulsham Street 2253 Chelmsford, Essex 2254 CM2 0LG 2255 United Kingdom 2256 ross@secstan.com 2258 Nick Pope 2259 Security & Standards 2260 192 Moulsham Street 2261 Chelmsford, Essex 2262 CM2 0LG 2263 United Kingdom 2264 pope@secstan.com 2266 Internet Draft Electronic Signature Formats 2268 9. Full Copyright Statement 2270 Copyright (C) The Internet Society (2000). All Rights Reserved. 2271 This document and translations of it may be copied and furnished to 2272 others, and derivative works that comment on or otherwise explain it 2273 or assist in its implementation may be prepared, copied, published and 2274 distributed, in whole or in part, without restriction of any kind, 2275 provided that the above copyright notice and this paragraph are 2276 included on all such copies and derivative works. However, this 2277 document itself may not be modified in any way, such as by removing 2278 the copyright notice or references to the Internet Society or other 2279 Internet organizations, except as needed for the purpose of developing 2280 Internet standards in which case the procedures for copyrights defined 2281 in the Internet Standards process must be followed, or as required to 2282 translate it into languages other than English. 2284 The limited permissions granted above are perpetual and will not be 2285 revoked by the Internet Society or its successors or assigns. 2287 This document and the information contained herein is provided on an 2288 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2289 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2290 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2291 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2292 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2294 Internet Draft Electronic Signature Formats 2296 Annex A (normative): ASN.1 Definitions 2298 This annex provides a summary of all the ASN.1 syntax definitions for 2299 new syntax defined in this document. 2301 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 2303 NOTE: The ASN.1 module defined in clause A.1 has precedence over that 2304 defined in Annex A-2 in the case of any conflict. 2306 ETS-ElectronicSignatureFormats-88syntax { iso(1) member-body(2) 2307 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5} 2309 DEFINITIONS EXPLICIT TAGS ::= 2311 BEGIN 2313 -- EXPORTS All - 2315 IMPORTS 2317 -- Crypographic Message Syntax (CMS): RFC 2630 2319 ContentInfo, ContentType, id-data, id-signedData, SignedData, 2320 EncapsulatedContentInfo, SignerInfo, id-contentType, 2321 id-messageDigest, MessageDigest, id-signingTime, SigningTime, 2322 id-countersignature, Countersignature 2324 FROM CryptographicMessageSyntax 2325 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2326 smime(16) modules(0) cms(1) } 2328 -- ESS Defined attributes: RFC 2634 2329 -- (Enhanced Security Services for S/MIME) 2331 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 2332 id-aa-contentReference, ContentReference, 2333 id-aa-contentIdentifier, ContentIdentifier 2335 FROM ExtendedSecurityServices 2336 { iso(1) member-body(2) us(840) rsadsi(113549) 2337 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 2339 -- Internet X.509 Public Key Infrastructure 2340 -- Certificate and CRL Profile: RFC 2459 2342 Certificate, AlgorithmIdentifier, CertificateList, Name, 2343 GeneralNames, GeneralName, DirectoryString,Attribute, 2344 AttributeTypeAndValue, AttributeType, AttributeValue, 2345 PolicyInformation, BMPString, UTF8String 2347 Internet Draft Electronic Signature Formats 2349 FROM PKIX1Explicit88 2350 {iso(1) identified-organization(3) dod(6) internet(1) 2351 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit- 2352 88(1)} 2354 -- X.509 '97 Authentication Framework 2356 AttributeCertificate 2358 FROM AuthenticationFramework 2359 {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3} 2361 -- The imported AttributeCertificate is defined using the X.680 1997 2362 -- ASN.1 Syntax, 2363 -- an equivalent using the 88 ASN.1 syntax may be used. 2365 -- OCSP 2560 2367 BasicOCSPResponse, ResponderID 2369 FROM OCSP {-- OID not assigned -- } 2371 -- Time Stamp Protocol Internet Draft 2373 TimeStampToken 2375 FROM PKIXTSP 2376 {iso(1) identified-organization(3) dod(6) internet(1) 2377 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 2379 -- S/MIME Object Identifier arcs used in this document 2380 -- =================================================== 2382 -- S/MIME OID arc used in this document 2383 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2384 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 2386 -- S/MIME Arcs 2387 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 2388 -- modules 2389 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 2390 -- content types 2391 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 2392 -- attributes 2393 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 2394 -- signature policy qualifier 2395 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 2396 -- commitment type identifier 2398 Internet Draft Electronic Signature Formats 2400 -- Definitions of Object Identifier arcs used in this document 2401 -- =========================================================== 2403 -- The allocation of OIDs to specific objects are given below with the 2404 -- associated ASN.1 syntax definition 2406 -- OID used referencing electronic signature mechanisms based on this 2407 -- standard for use with the IDUP API (see annex D) 2409 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 2410 { itu-t(0) identified-organization(4) etsi(0) 2411 electronic-signature-standard (1733) part1 (1) 2412 idupMechanism (4)etsiESv1(1) } 2414 -- CMS Attributes Defined in this document 2415 -- ======================================= 2417 -- Mandatory Electronic Signature Attributes 2419 -- OtherSigningCertificate 2421 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 2422 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2423 smime(16) id-aa(2) 19 } 2425 OtherSigningCertificate ::= SEQUENCE { 2426 certs SEQUENCE OF OtherCertID, 2427 policies SEQUENCE OF PolicyInformation OPTIONAL 2428 -- NOT USED IN THIS DOCUMENT 2429 } 2431 OtherCertID ::= SEQUENCE { 2432 otherCertHash OtherHash, 2433 issuerSerial IssuerSerial OPTIONAL 2434 } 2436 OtherHash ::= CHOICE { 2437 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 2438 otherHash OtherHashAlgAndValue 2439 } 2441 OtherHashValue ::= OCTET STRING 2443 OtherHashAlgAndValue ::= SEQUENCE { 2444 hashAlgorithm AlgorithmIdentifier, 2445 hashValue OtherHashValue 2446 } 2448 Internet Draft Electronic Signature Formats 2450 -- Signature Policy Identifier 2452 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 2453 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2454 smime(16) id-aa(2) 15 } 2456 "SignaturePolicy CHOICE { 2457 SignaturePolicyId SignaturePolicyId, 2458 SignaturePolicyImplied SignaturePolicyImplied 2459 } 2461 SignaturePolicyId ::= SEQUENCE { 2462 sigPolicyIdentifier SigPolicyId, 2463 sigPolicyHash SigPolicyHash, 2464 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 2465 SigPolicyQualifierInfo OPTIONAL 2466 } 2468 SignaturePolicyImplied ::= NULL 2470 SigPolicyId ::= OBJECT IDENTIFIER 2472 SigPolicyHash ::= ETSIHashAlgAndValue 2474 SigPolicyQualifierInfo ::= SEQUENCE { 2475 sigPolicyQualifierId SigPolicyQualifierId, 2476 sigQualifier ANY DEFINED BY sigPolicyQualifierId 2477 } 2479 SigPolicyQualifierId ::= 2480 OBJECT IDENTIFIER 2482 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 2483 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2484 smime(16) id-spq(5) 1 } 2486 SPuri ::= IA5String 2488 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 2489 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2490 smime(16) id-spq(5) 2 } 2492 Internet Draft Electronic Signature Formats 2494 SPUserNotice ::= SEQUENCE { 2495 noticeRef NoticeReference OPTIONAL, 2496 explicitText DisplayText OPTIONAL 2497 } 2499 NoticeReference ::= SEQUENCE { 2500 organization DisplayText, 2501 noticeNumbers SEQUENCE OF INTEGER 2502 } 2504 DisplayText ::= CHOICE { 2505 visibleString VisibleString (SIZE (1..200)), 2506 bmpString BMPString (SIZE (1..200)), 2507 utf8String UTF8String (SIZE (1..200)) 2508 } 2510 -- Optional Electronic Signature Attributes 2512 -- Commitment Type 2514 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2515 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 2517 CommitmentTypeIndication ::= SEQUENCE { 2518 commitmentTypeId CommitmentTypeIdentifier, 2519 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 2520 CommitmentTypeQualifier OPTIONAL 2521 } 2523 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 2525 CommitmentTypeQualifier ::= SEQUENCE { 2526 commitmentTypeIdentifier CommitmentTypeIdentifier, 2527 qualifier ANY DEFINED BY commitmentTypeIdentifier 2528 } 2530 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member- 2531 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2532 cti(6) 1} 2534 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member- 2535 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2536 cti(6) 2} 2538 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 2539 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2540 cti(6) 3} 2542 Internet Draft Electronic Signature Formats 2544 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- 2545 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2546 cti(6) 4} 2548 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 2549 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2550 cti(6) 5} 2552 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 2553 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2554 cti(6) 6} 2556 -- Signer Location 2558 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member- 2559 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2560 id-aa(2) 17} 2562 SignerLocation ::= SEQUENCE { 2563 -- at least one of the following must be present 2564 countryName [0] DirectoryString OPTIONAL, 2565 -- as used to name a Country in X.500 2566 localityName [1] DirectoryString OPTIONAL, 2567 -- as used to name a locality in X.500 2568 postalAdddress [2] PostalAddress OPTIONAL 2569 } 2571 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 2573 -- Signer Attributes 2575 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2576 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 2578 SignerAttribute ::= SEQUENCE OF CHOICE { 2579 claimedAttributes [0] ClaimedAttributes, 2580 certifiedAttributes [1] CertifiedAttributes 2581 } 2583 ClaimedAttributes ::= SEQUENCE OF Attribute 2585 CertifiedAttributes ::= AttributeCertificate -- as defined in X.509 : 2586 see section 10.3 2588 Internet Draft Electronic Signature Formats 2590 -- Content Timestamp 2592 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2593 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2594 id-aa(2) 20} 2596 ContentTimestamp::= TimeStampToken 2598 -- Validation Data 2600 -- Signature Timestamp 2602 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 2603 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2604 id-aa(2) 14} 2606 SignatureTimeStampToken ::= TimeStampToken 2608 -- Complete Certificate Refs. 2610 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2611 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 2613 CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID 2615 -- Complete Revocation Refs 2617 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member- 2618 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2619 id-aa(2) 22} 2621 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 2623 CrlOcspRef ::= SEQUENCE { 2624 crlids [0] CRLListID OPTIONAL, 2625 ocspids [1] OcspListID OPTIONAL, 2626 otherRev [2] OtherRevRefs OPTIONAL 2627 } 2629 CRLListID ::= SEQUENCE { 2630 crls SEQUENCE OF CrlValidatedID} 2632 CrlValidatedID ::= SEQUENCE { 2633 crlHash ETSIHash, 2634 crlIdentifier CrlIdentifier OPTIONAL 2635 } 2637 Internet Draft Electronic Signature Formats 2639 CrlIdentifier ::= SEQUENCE { 2640 crlissuer Name, 2641 crlIssuedTime UTCTime, 2642 crlNumber INTEGER OPTIONAL 2643 } 2645 OcspListID ::= SEQUENCE { 2646 ocspResponses SEQUENCE OF OcspResponsesID} 2648 OcspResponsesID ::= SEQUENCE { 2649 ocspIdentifier OcspIdentifier, 2650 ocspRepHash ETSIHash OPTIONAL 2651 } 2653 OcspIdentifier ::= SEQUENCE { 2654 ocspResponderID ResponderID, 2655 -- as in OCSP response data 2656 producedAt GeneralizedTime 2657 -- as in OCSP response data 2658 } 2660 OtherRevRefs ::= SEQUENCE { 2661 otherRevRefType OtherRevRefType, 2662 otherRevRefs ANY DEFINED BY otherRevRefType 2663 } 2665 OtherRevRefType ::= OBJECT IDENTIFIER 2667 -- Certificate Values 2669 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2670 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 2672 CertificateValues ::= SEQUENCE OF Certificate 2674 -- Certificate Revocation Values 2676 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- 2677 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2678 id-aa(2) 24} 2680 RevocationValues ::= SEQUENCE { 2681 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 2682 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 2683 otherRevVals [2] OtherRevVals 2684 } 2686 Internet Draft Electronic Signature Formats 2688 OtherRevVals ::= SEQUENCE { 2689 otherRevValType OtherRevValType, 2690 otherRevVals ANY DEFINED BY otherRevValType 2691 } 2693 OtherRevValType ::= OBJECT IDENTIFIER 2695 -- ES-C Timestamp 2697 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2698 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 2700 ESCTimeStampToken ::= TimeStampToken 2702 -- Time-Stamped Certificates and CRLs 2704 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2705 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2706 id-aa(2) 26} 2708 TimestampedCertsCRLs ::= TimeStampToken 2710 -- Archive Timestamp 2712 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2713 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2714 id-aa(2) 27} 2716 ArchiveTimeStampToken ::= TimeStampToken 2718 END -- ETS-ElectronicSignatureFormats-88syntax -- 2720 Internet Draft Electronic Signature Formats 2722 A.2 Definitions Using X.680 1997 ASN.1 Syntax 2724 NOTE: The ASN.1 module defined in clause A.1 has precedence over that 2725 defined in clause A.2 in the case of any conflict. 2727 ETS-ElectronicSignatureFormats-97Syntax { iso(1) member-body(2) 2728 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6} 2730 DEFINITIONS EXPLICIT TAGS ::= 2732 BEGIN 2734 -- EXPORTS All - 2736 IMPORTS 2738 -- Cryptographic Message Syntax (CMS): RFC 2630 2740 ContentInfo, ContentType, id-data, id-signedData, SignedData, 2741 EncapsulatedContentInfo, SignerInfo, id-contentType, 2742 id-messageDigest, MessageDigest, id-signingTime, 2743 SigningTime, id-countersignature, Countersignature 2745 FROM CryptographicMessageSyntax 2746 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2747 smime(16) modules(0) cms(1) } 2749 -- ESS Defined attributes: RFC 2634 (Enhanced Security Services 2750 -- for S/MIME) 2752 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 2753 id-aa-contentReference, ContentReference, 2754 id-aa-contentIdentifier, ContentIdentifier 2756 FROM ExtendedSecurityServices 2757 { iso(1) member-body(2) us(840) rsadsi(113549) 2758 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 2760 -- Internet X.509 Public Key Infrastructure 2761 - - Certificate and CRL Profile:RFC 2459 2763 Certificate, AlgorithmIdentifier, CertificateList, Name, 2764 GeneralNames, GeneralName, DirectoryString, Attribute, 2765 AttributeTypeAndValue, AttributeType, AttributeValue, 2766 PolicyInformation. 2768 FROM PKIX1Explicit93 2769 {iso(1) identified-organization(3) dod(6) internet(1) 2770 security(5) mechanisms(5) pkix(7) id-mod(0) 2771 id-pkix1-explicit-88(1)} 2773 Internet Draft Electronic Signature Formats 2775 -- X.509 '97 Authentication Framework 2777 AttributeCertificate 2779 FROM AuthenticationFramework 2780 {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3} 2782 -- OCSP 2560 2784 BasicOCSPResponse, ResponderID 2786 FROM OCSP 2788 -- { OID not assigned } 2790 -- Time Stamp Protocol Internet Draft TimeStampToken 2792 FROM PKIXTSP 2793 {iso(1) identified-organization(3) dod(6) internet(1) 2794 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 2796 -- S/MIME Object Identifier arcs used in this document 2797 -- =================================================== 2799 -- S/MIME OID arc used in this document 2800 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2801 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 2803 -- S/MIME Arcs 2804 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 2805 -- modules 2806 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 2807 -- content types 2808 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 2809 -- attributes 2810 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 2811 -- signature policy qualifier 2812 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 2813 -- commitment type identifier 2815 -- Definitions of Object Identifier arcs used in this document 2816 -- =========================================================== 2818 -- The allocation of OIDs to specific objects are given below with the 2819 -- associated ASN.1 syntax definition 2821 -- OID used referencing electronic signature mechanisms based on this 2822 -- standard for use with the IDUP API (see annex D) 2824 Internet Draft Electronic Signature Formats 2826 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 2827 { itu-t(0) identified-organization(4) etsi(0) 2828 electronic-signature-standard (1733) part1 (1) 2829 idupMechanism (4)etsiESv1(1) } 2831 -- CMS Attributes Defined in this document 2832 -- ======================================= 2834 -- Mandatory Electronic Signature Attributes 2835 -- OtherSigningCertificate 2837 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 2838 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2839 smime(16) id-aa(2) 19 } 2841 OtherSigningCertificate ::= SEQUENCE { 2842 certs SEQUENCE OF OtherCertID, 2843 policies SEQUENCE OF PolicyInformation OPTIONAL 2844 -- NOT USED IN THIS DOCUMENT 2845 } 2847 OtherCertID ::= SEQUENCE { 2848 otherCertHash OtherHash, 2849 issuerSerial IssuerSerial OPTIONAL 2850 } 2852 OtherHash ::= CHOICE { 2853 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 2854 otherHash OtherHashAlgAndValue 2855 } 2857 OtherHashValue ::= OCTET STRING 2859 OtherHashAlgAndValue ::= SEQUENCE { 2860 hashAlgorithm AlgorithmIdentifier, 2861 hashValue OtherHashValue 2862 } 2864 -- Signature Policy Identifier 2866 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 2867 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2868 smime(16) id-aa(2) 15 } 2870 "SignaturePolicy CHOICE { 2871 SignaturePolicyId SignaturePolicyId, 2872 SignaturePolicyImplied SignaturePolicyImplied 2873 } 2875 Internet Draft Electronic Signature Formats 2877 SignaturePolicyId ::= SEQUENCE { 2878 sigPolicyIdentifier SigPolicyId, 2879 sigPolicyHash SigPolicyHash, 2880 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 2881 SigPolicyQualifierInfo OPTIONAL 2882 } 2884 SignaturePolicyImplied ::= NULL 2886 SigPolicyId ::= OBJECT IDENTIFIER 2888 SigPolicyHash ::= ETSIHashAlgAndValue 2890 SigPolicyQualifierInfo ::= SEQUENCE { 2891 sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id 2892 ({SupportedSigPolicyQualifiers}), 2893 qualifier SIG-POLICY-QUALIFIER.&Qualifier 2894 ({SupportedSigPolicyQualifiers} 2895 {@sigPolicyQualifierId})OPTIONAL } 2897 SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 2898 { noticeToUser | pointerToSigPolSpec } 2900 SIG-POLICY-QUALIFIER ::= CLASS { 2901 &id OBJECT IDENTIFIER UNIQUE, 2902 &Qualifier OPTIONAL } 2904 WITH SYNTAX { 2905 SIG-POLICY-QUALIFIER-ID &id 2906 [SIG-QUALIFIER-TYPE &Qualifier] } 2908 noticeToUser SIG-POLICY-QUALIFIER ::= { 2909 SIG-POLICY-QUALIFIER-ID id-sqt-unotice SIG-QUALIFIER-TYPE 2910 SPUserNotice 2911 } 2913 pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { 2914 SIG-POLICY-QUALIFIER-ID id-sqt-uri SIG-QUALIFIER-TYPE SPuri } 2916 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 2917 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2918 smime(16) id-spq(5) 1 } 2920 SPuri ::= IA5String 2922 Internet Draft Electronic Signature Formats 2924 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 2925 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2926 smime(16) id-spq(5) 2 } 2928 SPUserNotice ::= SEQUENCE { 2929 noticeRef NoticeReference OPTIONAL, 2930 explicitText DisplayText OPTIONAL 2931 } 2933 NoticeReference ::= SEQUENCE { 2934 organization DisplayText, 2935 noticeNumbers SEQUENCE OF INTEGER 2936 } 2938 DisplayText ::= CHOICE { 2939 visibleString VisibleString (SIZE (1..200)), 2940 bmpString BMPString (SIZE (1..200)), 2941 utf8String UTF8String (SIZE (1..200)) 2942 } 2944 -- Optional Electronic Signature Attributes 2946 -- Commitment Type 2948 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2949 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 2951 CommitmentTypeIndication ::= SEQUENCE { 2952 commitmentTypeId CommitmentTypeIdentifier, 2953 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 2954 CommitmentTypeQualifier 2955 OPTIONAL} 2957 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 2959 CommitmentTypeQualifier ::= SEQUENCE { 2960 commitmentQualifierId COMMITMENT-QUALIFIER.&id, 2961 qualifier COMMITMENT-QUALIFIER.&Qualifier 2962 OPTIONAL } 2964 COMMITMENT-QUALIFIER ::= CLASS { 2965 &id OBJECT IDENTIFIER UNIQUE, 2966 &Qualifier OPTIONAL } 2967 WITH SYNTAX { 2968 COMMITMENT-QUALIFIER-ID &id 2969 [COMMITMENT-TYPE &Qualifier] } 2971 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) 2972 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2973 smime(16) cti(6) 1} 2975 Internet Draft Electronic Signature Formats 2977 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) 2978 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2979 smime(16) cti(6) 2} 2981 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 2982 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2983 smime(16) cti(6) 3} 2985 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) 2986 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2987 smime(16) cti(6) 4} 2989 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) 2990 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2991 smime(16) cti(6) 5} 2993 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) 2994 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2995 smime(16) cti(6) 6} 2997 -- Signer Location 2999 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3000 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3002 SignerLocation ::= SEQUENCE { 3003 -- at least one of the following must be present 3004 countryName [0] DirectoryString OPTIONAL, 3005 -- As used to name a Country in X.500 3006 localityName [1] DirectoryString OPTIONAL, 3007 -- As used to name a locality in X.500 3008 postalAdddress [2] PostalAddress OPTIONAL } 3010 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 3012 -- Signer Attributes 3014 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3015 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3017 SignerAttribute ::= SEQUENCE OF CHOICE { 3018 claimedAttributes [0] ClaimedAttributes, 3019 certifiedAttributes [1] CertifiedAttributes } 3021 ClaimedAttributes ::= SEQUENCE OF Attribute 3023 CertifiedAttributes ::= AttributeCertificate 3024 -- As defined in X.509 : see section 10.3 3026 Internet Draft Electronic Signature Formats 3028 -- Content Timestamp 3030 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) 3031 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3032 smime(16) id-aa(2) 20} 3034 ContentTimestamp::= TimeStampToken 3036 -- Validation Data 3038 -- Signature Timestamp 3040 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 3041 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3042 smime(16) id-aa(2) 14} 3044 SignatureTimeStampToken ::= TimeStampToken 3046 -- Complete Certificate Refs. 3048 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3049 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3051 CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID 3053 -- Complete Revocation Refs 3055 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3056 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3058 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3060 CrlOcspRef ::= SEQUENCE { 3061 crlids [0] CRLListID OPTIONAL, 3062 ocspids [1] OcspListID OPTIONAL, 3063 otherRev [2] OtherRevRefs OPTIONAL 3064 } 3066 CRLListID ::= SEQUENCE { 3067 crls SEQUENCE OF CrlValidatedID} 3069 CrlValidatedID ::= SEQUENCE { 3070 crlHash ETSIHash, 3071 crlIdentifier CrlIdentifier OPTIONAL} 3073 CrlIdentifier ::= SEQUENCE { 3074 crlissuer Name, 3075 crlIssuedTime UTCTime, 3076 crlNumber INTEGER OPTIONAL 3077 } 3079 Internet Draft Electronic Signature Formats 3081 OcspListID ::= SEQUENCE { 3082 ocspResponses SEQUENCE OF OcspResponsesID} 3084 OcspResponsesID ::= SEQUENCE { 3085 ocspIdentifier OcspIdentifier, 3086 ocspRepHash ETSIHash OPTIONAL 3087 } 3089 OcspIdentifier ::= SEQUENCE { 3090 ocspResponderID ResponderID, 3091 -- As in OCSP response data 3092 producedAt GeneralizedTime 3093 -- As in OCSP response data 3094 } 3096 OtherRevRefs ::= SEQUENCE { 3097 otherRevRefType OTHER-REVOCATION-REF.&id, 3098 otherRevRefs OTHER-REVOCATION-REF.&Type 3099 } 3101 OTHER-REVOCATION-REF ::= CLASS { 3102 &Type, 3103 &id OBJECT IDENTIFIER UNIQUE } 3104 WITH SYNTAX { 3105 &Type ID &id } 3107 -- Certificate Values 3109 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3110 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3112 CertificateValues ::= SEQUENCE OF Certificate 3114 -- Certificate Revocation Values 3116 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 3117 member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3118 smime(16) id-aa(2) 24} 3120 RevocationValues ::= SEQUENCE { 3121 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3122 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3123 otherRevVals [2] OtherRevVals } 3125 OtherRevVals ::= SEQUENCE { 3126 otherRevValType OTHER-REVOCATION-VAL.&id, 3127 otherRevVals OTHER-REVOCATION-VAL.&Type 3128 } 3130 Internet Draft Electronic Signature Formats 3132 OTHER-REVOCATION-VAL ::= CLASS { 3133 &Type, 3134 &id OBJECT IDENTIFIER UNIQUE } 3135 WITH SYNTAX { 3136 &Type ID &id } 3138 -- ES-C Timestamp 3140 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) 3141 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3142 smime(16) id-aa(2) 25} 3144 ESCTimeStampToken ::= TimeStampToken 3146 -- Time-Stamped Certificates and CRLs 3148 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) 3149 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3150 smime(16) id-aa(2) 26} 3152 TimestampedCertsCRLs ::= TimeStampToken 3154 -- Archive Timestamp 3156 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) 3157 member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3158 smime(16) id-aa(2) 27} 3160 ArchiveTimeStampToken ::= TimeStampToken 3162 END -- ETS-ElectronicSignatureFormats-97Syntax 3164 Internet Draft Electronic Signature Formats 3166 Annex B (informative): General Description 3168 This annex captures the concepts that apply to this document and the 3169 rational for the elements of the specification defined using ASN.1 in 3170 the main text of this document. 3172 The specification below includes a description why the component is 3173 needed, with a brief description of the vulnerabilities and threats 3174 and the manner by which they are countered. 3176 B.1 The Signature Policy 3178 The signature policy is a set of rules for the creation and validation 3179 of an electronic signature, under which the signature can be 3180 determined to be valid. A given legal/contractual context may 3181 recognize a particular signature policy as meeting its requirements. 3182 A signature policy may be issued, for example, by a party relying on 3183 the electronic signatures and selected by the signer for use with that 3184 relying party. Alternatively, a signature policy may be established 3185 through an electronic trading association for use amongst its members. 3186 Both the signer and verifier use the same signature policy. 3188 The signature policy may be explicitly identified or may be implied by 3189 the semantics of the data being signed and other external data like a 3190 contract being referenced which itself refers to a signature policy. 3192 An explicit signature policy has a globally unique reference, which is 3193 bound to an electronic signature by the signer as part of the signature 3194 calculation. 3196 The signature policy needs to be available in human readable form so 3197 that it can be assessed to meet the requirements of the legal and 3198 contractual context in which it is being applied. To facilitate the 3199 automatic processing of an electronic signature the parts of the 3200 signature policy which specify the electronic rules for the creation 3201 and validation of the electronic signature also needs to be in a 3202 computer processable form. 3204 The signature policy thus includes the following: 3206 * Information about the signature policy that can be displayed 3207 to the signer or the verifiers. 3208 * Rules, which apply to functionality, covered by this document 3209 (referred to as the Signature Validation Policy). 3210 * Rules which may be implied through adoption of Certificate 3211 Policies that apply to the electronic signature (e.g. rules for 3212 ensuring the secrecy of the private signing key). 3213 * Rules, which relate to the environment used by the signer, 3214 e.g. the use of an agreed CAD (Card Accepting Device) used 3215 in conjunction with a smart card. 3217 Internet Draft Electronic Signature Formats 3219 An explicit Signature Validation Policy may be structured so that it 3220 can be computer processable. Any format of the signature validation 3221 policy is allowed by this document. However, for a given explicit 3222 signature policy there must be one definitive form that has a unique 3223 binary encoded value. 3225 The Signature Validation Policy includes rules regarding use of TSPs 3226 (CA, Attribute Authorities, Time Stamping Authorities) as well as 3227 rules defining the components of the electronic signature that must be 3228 provided by the signer with data required by the verifier to provide 3229 long term proof. 3231 B.2 Signed Information 3233 The information being signed may be defined as a MIME-encapsulated 3234 message which can be used to signal the format of the content in order 3235 to select the right display or application. It can be composed of 3236 formatted text (e.g. EDIFACT), free text or of fields from an 3237 electronic form (e-form). For example, the Adobe(tm) format "pdf" may 3238 be used or the eXtensible Mark up Language (XML). 3240 B.3 Components of an Electronic Signature 3242 B.3.1 Reference to the Signature Policy 3244 The definition of electronic signature includes: "a commitment has 3245 been explicitly endorsed under a "Signature policy", at a given time, 3246 by a signer under an identifier, e.g. a name or a pseudonym, and 3247 optionally a role". 3249 When two independent parties want to evaluate an electronic signature, 3250 it is fundamental that they get the same result. To meet this 3251 requirement same signature policy must be used by the signer and 3252 verifier. 3254 The signature policy may be explicitly identified or may be implied by 3255 the semantics of the data being signed and other external data which 3256 designate the signature policy to be used. 3258 By signing over the signature policy identifier the signer explicitly 3259 indicates that he or she has applied the signature policy in creating 3260 the signature. Thus, undertakes any explicit or implied commitments. 3262 In order to unambiguously identify an explicit signature policy that is 3263 to be used to verify the signature an identifier and hash of the 3264 "Signature policy" shall be part of the signed data. Additional 3265 information about the explicit policy (e.g. web reference to the 3266 document) may be carried as "qualifiers" to the signature policy 3267 identifier. 3269 Internet Draft Electronic Signature Formats 3271 When the signature policy not explicitly identified, but is implied by 3272 the semantics of the data being signed, then the signature will include 3273 a signature policy identifier that indicates that the signature policy 3274 is implied. In this case the verification rules must be determined by 3275 using other external data which will designate the signature policy to 3276 be used. If it may be determined from the context that all the 3277 documents to be verified refer to the same signature policy, then that 3278 policy may be predetermined or fixed within the application. 3280 In order to identify unambiguously the "Signature Validation Policy" 3281 to be used to verify the signature an identifier and hash of the 3282 "Signature policy" must be part of the signed data. Additional 3283 information about the policy (e.g. web reference to the document) may 3284 be carried as "qualifiers" to the signature policy identifier. 3286 B.3.2 Commitment Type Indication 3288 The definition of electronic signature includes: "a commitment has 3289 been explicitly endorsed under a signature policy, at a given time, 3290 by a signer under an identifier, e.g. a name or a pseudonym, and 3291 optionally a role". 3293 The commitment type can be indicated in the electronic signature 3294 either: 3296 * explicitly using a "commitment type indication" in the 3297 electronic signature; 3299 * implicitly or explicitly from the semantics of the signed data. 3301 If the indicated commitment type is explicit using a "commitment type 3302 indication" in the electronic signature, acceptance of a verified 3303 signature implies acceptance of the semantics of that commitment type. 3304 The semantics of explicit commitment types indications must be 3305 specified either as part of the signature policy or may be registered 3306 for generic use across multiple policies. 3308 If a signature includes a commitment type indication other than one of 3309 those recognized under the signature policy the signature must be 3310 treated as invalid. 3312 How commitment is indicated using the semantics of the data being 3313 signed is outside the scope of this document. 3315 NOTE: Examples of commitment indicated through the semantics of the 3316 data being signed, are: 3318 * An explicit commitment made by the signer indicated by the type 3319 of data being signed over. Thus, the data structure being 3320 signed can have an explicit commitment within the context of 3321 the application (e.g. EDIFACT purchase order). 3323 Internet Draft Electronic Signature Formats 3325 * An implicit commitment which is a commitment made by the signer 3326 because the data being signed over has specific semantics 3327 (meaning) which is only interpretable by humans, (i.e. free 3328 text). 3330 B.3.3 Certificate Identifier from the Signer 3332 The definition of the ETSI electronic signature includes: "a 3333 commitment has been explicitly endorsed under a signature policy, 3334 at a given time, by a signer under an identifier, e.g. a name or a 3335 pseudonym, and optionally a role." 3337 In many real life environments users will be able to get from 3338 different CAs or even from the same CA, different certificates 3339 containing the same public key for different names. The prime 3340 advantage is that a user can use the same private key for different 3341 purposes. Multiple use of the private key is an advantage when a smart 3342 card is used to protect the private key, since the storage of a smart 3343 card is always limited. When several CAs are involved, each different 3344 certificate may contain a different identity, e.g. as a national or as 3345 an employee from a company. Thus when a private key is used for 3346 various purposes, the certificate is needed to clarify the context in 3347 which the private key was used when generating the signature. Where 3348 there is the possibility of multiple use of private keys it is 3349 necessary for the signer to indicate to the verifier the precise 3350 certificate to be used. 3352 Many current schemes simply add the certificate after the signed data 3353 and thus are subject to various substitution attacks. An example of a 3354 substitution attack is a "bad" CA that would issue a certificate to 3355 someone with the public key of someone else. If the certificate from 3356 the signer was simply appended to the signature and thus not protected 3357 by the signature, any one could substitute one certificate by another 3358 and the message would appear to be signed by some one else. 3360 In order to counter this kind of attack, the identifier of the signer 3361 has to be protected by the digital signature from the signer. 3363 Although it does not provide the same advantages as the previous 3364 technique, another technique to counter that threat has been 3365 identified. It requires all CAs to perform a Proof Of Possession of 3366 the private key at the time of registration. The problem with that 3367 technique is that it does not provide any guarantee at the time of 3368 verification and only some proof "after the event" may be obtained, if 3369 and only if the CA keeps the Proof Of Possession in audit trail. 3371 In order to identify unambiguously the certificate to be used for the 3372 verification of the signature an identifier of the certificate from 3373 the signer must be part of the signed data. 3375 Internet Draft Electronic Signature Formats 3377 B.3.4 Role Attributes 3379 The definition of electronic signature includes: "a commitment has 3380 been explicitly endorsed under a non repudiation security policy, 3381 at a given time, by a signer under an identifier, e.g. a name or a 3382 pseudonym, and optionally a role. " 3384 While the name of the signer is important, the position of the signer 3385 within a company or an organization can be even more important. Some 3386 contracts may only be valid if signed by a user in a particular role, 3387 e.g. a Sales Director. In many cases whom the sales Director really 3388 is, is not that important but being sure that the signer is empowered 3389 by his company to be the Sales Director is fundamental. 3391 This document defines two different ways for providing this feature: 3393 * by placing a claimed role name in the CMS signed 3394 attributes field; 3396 * by placing a attribute certificate containing a certified 3397 role name in the CMS signed attributes field. 3399 NOTE: Another possible approach would have been to use additional 3400 attributes containing the roles name(s) in the signer's certificate. 3401 However, it was decided not to follow this approach as it breaks the 3402 basic philosophy of the certificate being issued for one primary 3403 purpose. Also, by using separate certificates for management of the 3404 signer's identity certificate and management of additional roles can 3405 simplify the management, as new identity keys need not be issued if a 3406 use of role is to be changed. 3408 B.3.5.1 Claimed Role 3410 The signer may be trusted to state his own role without any 3411 certificate to corroborate this claim. In which case the claimed role 3412 can be added to the signature as a signed attribute. 3414 B.3.5.2 Certified Role 3416 Unlike public key certificates that bind an identifier to a public 3417 key, Attribute Certificates bind the identifier of a certificate to 3418 some attributes, like a role. An Attribute Certificate is NOT issued 3419 by a CA but by an Attribute Authority (AA). The Attribute Authority 3420 will be most of the time under the control of an organization or a 3421 company that is best placed to know which attributes are relevant for 3422 which individual. 3424 Internet Draft Electronic Signature Formats 3426 The Attribute Authority may use or point to public key certificates 3427 issued by any CA, provided that the appropriate trust may be placed 3428 in that CA. Attribute Certificates may have various periods of 3429 validity. That period may be quite short, e.g. one day. While this 3430 requires that a new Attribute Certificate is obtained every day, valid 3431 for that day, this can be advantageous since revocation of such 3432 certificates may not be needed. When signing, the signer will have to 3433 specify which Attribute Certificate it selects. In order to do 3434 so, a reference to the Attribute Certificate will have to be included 3435 in the signed data in order to be protected by the digital signature 3436 from the signer. 3438 In order to identify unambiguously the attribute certificate(s) to be 3439 used for the verification of the signature an identifier of the 3440 attribute certificate(s) from the signer must be part of the signed 3441 data. 3443 B.3.5 Signer Location 3445 In some transactions the purported location of the signer at the time 3446 he or she applies his signature may need to be indicated. For this 3447 reason an optional location indicator must be able to be included. 3449 In order to provide indication of the location of the signer at the 3450 time he or she applied his signature a location attribute may be 3451 included in the signature. 3453 B.3.6 Signing Time 3455 The definition of electronic signature includes: "a commitment has 3456 been explicitly endorsed under a signature policy, at a given time, 3457 by a signer under an identifier, e.g. a name or a pseudonym, and 3458 optionally a 3459 role. " 3461 There are several ways to address this problem. The solution adopted 3462 in this document is to sign over a time which the signer claims is the 3463 signing time (i.e. claimed signing time) and to require a trusted 3464 time stamp to be obtained when building a ES with Timestamp. When a 3465 verifier accepts a signature, the two times must be within acceptable 3466 limits. 3468 The solution that is adopted in this document offers the major 3469 advantage that electronic signatures can be generated without any on- 3470 line connection to a trusted time source (i.e. they may be generated 3471 off-line). 3473 Thus two dates and two signatures are required: 3475 * a signing time indicated by the signer and which is part of 3476 the data signed by the signer (i.e. part of the basic 3477 electronic signature); 3479 Internet Draft Electronic Signature Formats 3481 * a time indicated by a TimeStamping Authority (TSA) which is 3482 signed over the digital signature value of the basic electronic 3483 signature. The signer, verifier or both may obtain the TSA 3484 timestamp. 3486 In order for an electronic signature to be valid under a signature 3487 policy, it must be timestamped by a TSA where the signing time as 3488 indicated by the signer and the time of time stamping as indicated by 3489 a TSA must be "close enough" to meet the requirements of the signature 3490 validation policy. 3492 "Close enough" means a few minutes, hours or even days according to 3493 the "Signature Validation Policy". 3495 NOTE: The need for Timestamping is further explained in clause B.4.5. 3496 A further optional attribute is defined in this document to timestamp 3497 the content, to provide proof of the existence of the content, at the 3498 time indicated by the timestamp. 3500 Using this optional attribute a trusted secure time may be obtained 3501 before the document is signed and included under the digital signature. 3502 This solution requires an on-line connection to a trusted timestamping 3503 service before generating the signature and may not represent the 3504 precise signing time, since it can be obtained in advance. However, 3505 this optional attribute may be used by the signer to prove that the 3506 signed object existed before the date included in the timestamp (see 3507 3.12.3, Content Timestamp). 3509 Also, the signing time should be between the time indicated by this 3510 timestamp and time indicated by the ES-T timestamp. 3512 B.3.7 Content Format 3514 When presenting signed data to a human user it may be important that 3515 there is no ambiguity as to the presentation of the signed information 3516 to the relying party. In order for the appropriate representation 3517 (text, sound or video) to be selected by the relying party a content 3518 hint may be indicated by the signer. If a relying party system does not 3519 use the format specified in the content hints to present the data to 3520 the relying party, the electronic signature may not be valid. 3522 B.4 Components of Validation Data 3524 B.4.1 Revocation Status Information 3526 A verifier will have to prove that the certificate of the signer was 3527 valid at the time of the signature. This can be done by either: 3529 * using Certificate Revocation Lists (CRLs); 3531 * using responses from an on-line certificate status server 3532 (for example; obtained through the OCSP protocol). 3534 Internet Draft Electronic Signature Formats 3536 B.4.2 CRL Information 3538 When using CRLs to get revocation information, a verifier will have to 3539 make sure that he or she gets at the time of the first verification the 3540 appropriate certificate revocation information from the signer's CA. 3541 This should be done as soon as possible to minimize the time delay 3542 between the generation and verification of the signature. This involves 3543 checking that the signer certificate serial number is not included in 3544 the CRL. The signer, the verifier or any other third party may obtain 3545 either this CRL. If obtained by the signer, then it must be conveyed 3546 to the verifier. It may be convenient to archive the CRL for ease of 3547 subsequent verification or arbitration. 3549 Alternatively, provided the CRL is archived elsewhere which is 3550 accessible for the purpose of arbitration, then the serial number of 3551 the CRL used may be archived together with the verified electronic 3552 signature. 3554 It may happen that the certificate serial number appears in the CRL 3555 but with the status "suspended" (i.e. on hold). In such a case, the 3556 electronic signature is not yet valid, since it is not possible to 3557 know whether the certificate will or will not be revoked at the end 3558 of the suspension period. If a decision has to be taken immediately 3559 then the signature has to be considered as invalid. If a decision can 3560 wait until the end of the suspension period, then two cases are 3561 possible: 3563 * the certificate serial number has disappeared from the list 3564 and thus the certificate can be considered as valid and that 3565 CRL must be captured and archived either by the verifier or 3566 elsewhere and be kept accessible for the purpose of arbitration. 3568 * the certificate serial number has been maintained on the list 3569 with the status definitively revoked and thus the electronic 3570 signature must be considered as invalid and discarded. 3572 At this point the verifier may be convinced that he or she got a valid 3573 signature, but is not yet in a position to prove at a later time that 3574 the signature was verified as valid. Before addressing this point, an 3575 alternative to CRL is to use OCSP responses. 3577 Internet Draft Electronic Signature Formats 3579 B.4.3 OCSP Information 3581 When using OCSP to get revocation information , a verifier will have 3582 to make sure that he or she gets at the time of the first verification 3583 an OCSP response that contains the status "valid". This should be done 3584 as soon as possible after the generation of the signature. The signer, 3585 the verifier or any other third party may fetch this OCSP response. 3586 Since OSCP responses are transient and thus are not archived by any 3587 TSP including CA, it is the responsibility of every verifier to make 3588 sure that it is stored in a safe place. The simplest way is to store 3589 them associated with the electronic signature. An alternative would be 3590 to store them in some storage so that they can then be easily 3591 retrieved. 3593 In the same way as for the case of the CRL, it may happen that the 3594 certificate is declared as invalid but with the secondary status 3595 "suspended". 3597 In such a case, the electronic signature is not yet valid, since it is 3598 not possible to know whether the certificate will or will not be 3599 revoked at the end of the suspension period. If a decision has to be 3600 taken immediately then the electronic signature has to be considered 3601 as invalid. If a decision can wait until the end of the suspension 3602 period, then two cases are possible: 3604 * An OCSP response with a valid status is obtained at a later 3605 date and thus the certificate can be considered as valid and 3606 that OCSP response must be captured. 3608 * An OCSP response with an invalid status is obtained with a 3609 secondary status indicating that the certificate is 3610 definitively revoked and thus the electronic signature must be 3611 considered as invalid and discarded. 3613 As in the CRL case, at this point, the verifier may be convinced that 3614 he or she got a valid signature, but is not yet in a position to prove 3615 at a later time that the signature was verified as valid. 3617 B.4.4 Certification Path 3619 A verifier will have to prove that the certification path was valid, 3620 at the time of the signature, up to a trust point according to the 3621 naming constraints and the certificate policy constraints from the 3622 "Signature Validation Policy". It will be necessary to capture all the 3623 certificates from the certification path, starting with those from the 3624 signer and ending up with those of the self-signed certificate from 3625 one trusted root of the "Signature Validation Policy". In addition, it 3626 will be necessary to capture the Authority Revocation Lists (ARLs) to 3627 prove than none of the CAs from the chain was revoked at the time of 3628 the signature. 3630 Internet Draft Electronic Signature Formats 3632 As in the OCSP case, at this point, the verifier may be convinced that 3633 he or she got a valid signature, but is not yet in a position to prove 3634 at a later time that the signature was verified as valid. 3636 B.4.5 Timestamping for Long Life of Signature 3638 An important property for long standing signatures is that a 3639 signature, having been found once to be valid, must continue to be so 3640 months or years later. 3642 A signer, verifier or both may be required to provide on request, 3643 proof that a digital signature was created or verified during the 3644 validity period of the all the certificates that make up the 3645 certificate path. In this case, the signer, verifier or both will 3646 also be required to provide proof that all the user and CA 3647 certificates used were not revoked when the signature was created 3648 or verified. 3650 It would be quite unacceptable, to consider a signature as invalid 3651 even if the keys or certificates were later compromised. Thus there 3652 is a need to be able to demonstrate that the signature keys was valid 3653 around the time that the signature was created to provide long term 3654 evidence of the validity of a signature. 3656 It could be the case that a certificate was valid at the time of the 3657 signature but revoked some time later. In this event, evidence must be 3658 provided that the document was signed before the signing key was 3659 revoked. 3661 Timestamping by a Time Stamping Authority (TSA) can provide such 3662 evidence. A time stamp is obtained by sending the hash value of the 3663 given data to the TSA. The returned "timestamp" is a signed document 3664 that contains the hash value, the identity of the TSA, and the time of 3665 stamping. This proves that the given data existed before the time of 3666 stamping. Timestamping a digital signature (by sending a hash of the 3667 signature to the TSA) before the revocation of the signer's private 3668 key, provides evidence that the signature has been created before the 3669 key was revoked. 3671 If a recipient wants to hold a valid electronic signature he will have 3672 to ensure that he has obtained a valid time stamp for it, before that 3673 key (and any key involved in the validation) is revoked. The sooner 3674 the timestamp is obtained after the signing time, the better. 3676 It is important to note that signatures may be generated "off-line" 3677 and time-stamped at a later time by anyone, for example by the signer 3678 or any recipient interested in the value of the signature. The time 3679 stamp can thus be provided by the signer together with the signed 3680 document, or obtained by the recipient following receipt of the signed 3681 document. 3683 Internet Draft Electronic Signature Formats 3685 The time stamp is NOT a component of the Electronic Signature, but the 3686 essential component of the ES with Timestamp. 3688 It is required in this document that signer's digital signature value 3689 is timestamped by a trusted source, known as a TimeStamping Authority. 3691 This document requires that the signer's digital signature value is 3692 timestamped by a trusted source before the electronic signature can 3693 become a ES with Complete validation data (ES-C). The acceptable TSAs 3694 are specified in the Signature Validation Policy. 3696 Should both the signer and verifier be required to timestamp the 3697 signature value to meet the requirements of the signature policy, the 3698 signature policy MAY specify a permitted time delay between the two 3699 time stamps. 3701 B.4.6 Timestamping before CA Key Compromises 3703 Timestamped extended electronic signatures are needed when there is a 3704 requirement to safeguard against the possibility of a CA key in the 3705 certificate chain ever being compromised. A verifier may be required 3706 to provide on request, proof that the certification path and the 3707 revocation information used a the time of the signature were valid, 3708 even in the case where one of the issuing keys or OCSP responder keys 3709 is later compromised. 3711 The current document defines two ways of using timestamps to protect 3712 against this compromise: 3714 * Timestamp the ES with Complete validation data, when an OCSP 3715 response is used to get the status of the certificate from the 3716 signer. 3718 * Timestamp only the certification path and revocation information 3719 references when a CRL is used to get the status of the 3720 certificate from the signer. 3722 NOTE: the signer, verifier or both may obtain the timestamp. 3724 Internet Draft Electronic Signature Formats 3726 B.4.6.1 Timestamping the ES with Complete validation data 3728 When an OCSP response is used, it is necessary to time stamp in 3729 particular that response in the case the key from the responder would 3730 be compromised. Since the information contained in the OCSP response 3731 is user specific and time specific, an individual time stamp is needed 3732 for every signature received. Instead of placing the time stamp only 3733 over the certification path references and the revocation information 3734 references, which include the OCSP response, the time stamp is placed 3735 on the ES-C. Since the certification path and revocation information 3736 references are included in the ES with Complete validation data they 3737 are also protected. For the same cryptographic price, this provides an 3738 integrity mechanism over the ES with Complete validation data. Any 3739 modification can be immediately detected. It should be noticed that 3740 other means of protecting/detecting the integrity of the ES with 3741 Complete Validation Data exist and could be used. 3743 Although the technique requires a time stamp for every signature, it 3744 is well suited for individual users wishing to have an integrity 3745 protected copy of all the validated signatures they have received. 3747 By timestamping the complete electronic signature, including the 3748 digital signature as well as the references to the certificates and 3749 revocation status information used to support validation of that 3750 signature, the timestamp ensures that there is no ambiguity in the 3751 means of validating that signature. 3753 This technique is referred to as ES with eXtended validation data 3754 (ES-X), type 1 Timestamped in this document. 3756 NOTE: Trust is achieved in the references by including a hash of the 3757 data being referenced. 3759 If it is desired for any reason to keep a copy of the additional data 3760 being referenced, the additional data may be attached to the 3761 electronic signature, in which case the electronic signature becomes 3762 a ES-X Long as defined by this document. 3764 A ES-X Long Timestamped is simply the concatenation of a ES-X 3765 Timestamped with a copy of the additional data being referenced. 3767 B.4.6.2 Timestamping Certificates and Revocation Information 3769 References Timestamping each ES with Complete validation data as 3770 defined above may not be efficient, particularly when the same set of 3771 CA certificates and CRL information is used to validate many 3772 signatures. 3774 Internet Draft Electronic Signature Formats 3776 Timestamping CA certificates will stop any attacker from issuing bogus 3777 CA certificates that could be claimed to existing before the CA key 3778 was compromised. Any bogus timestamped CA certificates will show that 3779 the certificate was created after the legitimate CA key was 3780 compromised. In the same way, timestamping CA CRLs, will stop any 3781 attacker from issuing bogus CA CRLs which could be claimed to existing 3782 before the CA key was compromised. 3784 Timestamping of commonly used certificates and CRLs can be done 3785 centrally, e.g. inside a company or by a service provider. This method 3786 reduces the amount of data the verifier has to timestamp, for example 3787 it could reduce to just one time stamp per day (i.e. in the case were 3788 all the signers use the same CA and the CRL applies for the whole day). 3789 The information that needs to be time stamped is not the actual 3790 certificates and CRLs but the unambiguous references to those 3791 certificates and CRLs. 3793 To comply with extended validation data, type 2 Timestamped, this 3794 document requires the following: 3796 * All the CA certificates references and revocation information 3797 references (i.e. CRLs) used in validating the ES-C are covered 3798 by one or more timestamp. 3800 Thus a ES-C with a timestamp signature value at time T1, can be proved 3801 valid if all the CA and CRL references are timestamped at time T1+. 3803 B.4.7 Timestamping for Long Life of Signature 3805 Advances in computing increase the probability of being able to break 3806 algorithms and compromise keys. There is therefore a requirement to be 3807 able to protect electronic signatures against this probability. 3809 Over a period of time weaknesses may occur in the cryptographic 3810 algorithms used to create an electronic signature (e.g. due to the 3811 time available for cryptoanalysis, or improvements in cryptoanalytical 3812 techniques). Before this such weaknesses become likely, a verifier 3813 should take extra measures to maintain the validity of the electronic 3814 signature. Several techniques could be used to achieve this goal 3815 depending on the nature of the weakened cryptography. In order to 3816 simplify, a single technique, called Archive validation data, covering 3817 all the cases is being used in this document. 3819 Archive validation data consists of the Complete validation data and 3820 the complete certificate and revocation data, time stamped together 3821 with the electronic signature. The Archive validation data is 3822 necessary if the hash function and the crypto algorithms that were 3823 used to create the signature are no longer secure. Also, if it cannot 3824 be assumed that the hash function used by the Time Stamping Authority 3825 is secure, then nested timestamps of Archived Electronic Signature are 3826 required. 3828 Internet Draft Electronic Signature Formats 3830 The potential for Trusted Service Provider (TSP) key compromise should 3831 be significantly lower than user keys, because TSP(s) are expected to 3832 use stronger cryptography and better key protection. It can be expected 3833 that new algorithms (or old ones with greater key lengths) will be 3834 used. In such a case, a sequence of timestamps will protect against 3835 forgery. Each timestamp needs to be affixed before either the 3836 compromise of the signing key or of the cracking of the algorithms used 3837 by the TSA. TSAs (TimeStamping Authorities) should have long keys (e.g. 3838 which at the time of drafting this document was 2048 bits for the 3839 signing RSA algorithm) and/or a "good" or different algorithm. 3841 Nested timestamps will also protect the verifier against key compromise 3842 or cracking the algorithm on the old electronic signatures. 3844 The process will need to be performed and iterated before the 3845 cryptographic algorithms used for generating the previous time stamp 3846 are no longer secure. Archive validation data may thus bear multiple 3847 embedded time stamps. 3849 B.4.8 Reference to Additional Data 3851 Using type 1 or 2 of Timestamped extended validation data verifiers 3852 still needs to keep track of all the components that were used to 3853 validate the signature, in order to be able to retrieve them again 3854 later on. These components may be archived by an external source like 3855 a trusted service provider, in which case referenced information that 3856 is provided as part of the ES with Complete validation data (ES-C) is 3857 adequate. The actual certificates and CRL information reference in the 3858 ES-C can be gathered when needed for arbitration. 3860 B.4.9 Timestamping for Mutual Recognition 3862 In some business scenarios both the signer and the verifier need to 3863 timestamp their own copy of the signature value. Ideally the two 3864 timestamps should be as close as possible to each other. 3866 Example: A contract is signed by two parties A and B representing 3867 their respective organizations, to timestamp the signer and verifier 3868 data two approaches are possible: 3870 * under the terms of the contract pre-defined common "trusted" 3871 TSA may be used; 3873 Internet Draft Electronic Signature Formats 3875 * if both organizations run their own timestamping services, A 3876 and B can have the transaction timestamped by these two 3877 timestamping services. In the latter case, the electronic 3878 signature will only be considered as valid, if both timestamps 3879 were obtained in due time (i.e. there should not be a long 3880 delay between obtaining the two timestamps). Thus, neither A 3881 nor B can repudiate the signing time indicated by their own 3882 timestamping service. 3884 Therefore, A and B do not need to agree on a common "trusted" TSA to 3885 get a valid transaction. 3887 It is important to note that signatures may be generated "off-line" 3888 and timestamped at a later time by anyone, e.g. by the signer or any 3889 recipient interested in validating the signature. The timestamp over 3890 the signature from the signer can thus be provided by the signer 3891 together with the signed document, and /or obtained by the verifier 3892 following receipt of the signed document. 3894 The business scenarios may thus dictate that one or more of the long- 3895 term signature timestamping methods describe above be used. This will 3896 need to be part of a mutually agreed the Signature Validation Policy 3897 with is part of the overall signature policy under which digital 3898 signature may be used to support the business relationship between the 3899 two parties. 3901 B.4.10 TSA Key Compromise 3903 TSA servers should be built in such a way that once the private 3904 signature key is installed, that there is minimal likelihood of 3905 compromise over as long as possible period. Thus the validity period 3906 for the TSA's keys should be as long as possible. 3908 Both the ES-T and the ES-C contain at least one time stamp over the 3909 signer's signature. In order to protect against the compromise of the 3910 private signature key used to produce that timestamp, the Archive 3911 validation data can be used when a different TimeStamping Authority key 3912 is involved to produce the additional timestamp. If it is believed that 3913 the TSA key used in providing an earlier timestamp may ever be 3914 compromised (e.g. outside its validity period), then the ES-A should be 3915 used. For extremely long periods this may be applied repeatedly using 3916 new TSA keys. 3918 Internet Draft Electronic Signature Formats 3920 B.5 Multiple Signatures 3922 Some electronic signatures may only be valid if they bear more than one 3923 signature. This is the case generally when a contract is signed between 3924 two parties. The ordering of the signatures may or may not be 3925 important, i.e. one may or may not need to be applied before the other. 3926 Several forms of multiple and counter signatures may need to be 3927 supported, which fall into two basic categories: 3929 * independent signatures; 3930 * embedded signatures. 3932 Independent signatures are parallel signatures where the ordering of 3933 the signatures is not important. The capability to have more than one 3934 independent signature over the same data must be provided. 3936 Embedded signatures are applied one after the other and are used where 3937 the order the signatures are applied is important. The capability to 3938 sign over signed data must be provided. 3940 These forms are described in clause 3.13. All other multiple signature 3941 schemes, e.g. a signed document with a countersignature, double 3942 countersignatures or multiple signatures, can be reduced to one or more 3943 occurrence of the above two cases. 3945 Annex C (informative): Identifiers and roles 3947 C.1 Signer Name Forms 3949 The name used by the signer, held as the subject in the signer's 3950 certificate, must uniquely identify the entity. The name must be 3951 allocated and verified on registration with the Certification 3952 Authority, either directly or indirectly through a Registration 3953 Authority, before being issued with a Certificate. 3955 This document places no restrictions on the form of the name. The 3956 subject's name may be a distinguished name, as defined in [RFC2459], 3957 held in the subject field of the certificate, or any other name form 3958 held in the X.509 subjectAltName certificate extension field. In the 3959 case that the subject has no distinguished name, the subject name can 3960 be an empty sequence and the subjectAltName extension must be critical. 3962 C.2 TSP Name Forms 3964 All TSP name forms (Certification Authorities, Attribute Authorities 3965 and TimeStamping Authorities) must be in the form of a distinguished 3966 name held in the subject field of the certificate. 3968 The TSP name form must include the legal jurisdiction (i.e. country) 3969 under which it operates and an identification for the organization 3970 providing the service. 3972 Internet Draft Electronic Signature Formats 3974 C.3 Roles and Signer Attributes 3976 Where a signer signs as an individual but wishes to also identify 3977 him/herself as acting on behalf of an organization, it may be necessary 3978 to provide two independent forms of identification. The first identity, 3979 with is directly associated with the signing key identifies him/her as 3980 an individual. The second, which is managed independently, identifies 3981 that person acting as part of the organization, possibly with a given 3982 role. 3984 In this case the first identity is carried in the 3985 subject/subjectAltName field of the signer's certificate as described 3986 above. 3988 This document supports the following means of providing a second form 3989 of identification: 3991 * by placing a secondary name field containing a claimed role in 3992 the CMS signed attributes field; 3994 * by placing an attribute certificate containing a certified role 3995 in the CMS signed attributes field.