idnits 2.17.1 draft-ietf-smime-esformats-02.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? == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 4) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 76 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. ** 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 3595 has weird spacing: '...stamped is si...' == Line 3596 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 (July 2000) is 8658 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2972 -- Looks like a reference, but probably isn't: '13' on line 255 -- Looks like a reference, but probably isn't: '12' on line 371 -- Looks like a reference, but probably isn't: '0' on line 2971 -- Looks like a reference, but probably isn't: '2' on line 2973 -- Looks like a reference, but probably isn't: '16' on line 1442 == Missing Reference: 'X509' is mentioned on line 1821, but not defined -- Looks like a reference, but probably isn't: '7' on line 2041 == Unused Reference: 'PKCS9' is defined on line 2072, but no explicit reference was found in the text == Unused Reference: 'ES201733' is defined on line 2079, 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: 9 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft ETSI TC-SEC (ETSI) 2 S/MIME Working Group D. Pinkas (Bull) 3 expires in six months J. Ross (Security & Standards) 4 Target Category: Informational N. Pope (Security & Standards) 5 July 2000 7 Electronic Signature Formats 8 for long term electronic signatures 9 11 Status of this Memo 13 This document is an Internet-Draft and is NOT offered in 14 accordance with section of RFC 2026, and the author does not 15 provide the IETF with any rights other than to publish as an 16 Internet-Draft. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 Months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The informational RFC defines the format of an electronic signature 37 that can remain valid over long periods. This includes evidence as to 38 its validity even if the signer or verifying party later attempts to 39 deny (i.e. repudiates, see [ISONR]) the validity of the signature. 41 The format can be considered as an extension to RFC 2630 [CMS] and RFC 42 2634 [ESS], where, when appropriate additional signed and unsigned 43 attributes have been defined. 45 The contents of this Informational RFC is technically equivalent to 46 ETSI ES 201 733 V.1.1.3 Copyright (C). Individual copies of this 47 ETSI deliverable can be downloaded from http://www.etsi.org 49 1. Introduction 51 This document is intended to cover electronic signatures for various 52 types of transactions, including business transactions (e.g. purchase 53 requisition, contract, and invoice applications) where long term 54 validity of such signatures is important. 56 Internet Draft Electronic Signature Formats 58 Electronic signatures can be used for any transaction between an 59 individual and a company, between two companies, between an individual 60 and a governmental body, etc. This document is independent of any 61 environment. It can be applied to any environment e.g. smart cards, GSM 62 SIM cards, special programs for electronic signatures etc. 64 An electronic signature produced in accordance with this document 65 provides evidence that can be processed to get confidence that some 66 commitment has been explicitly endorsed under a signature policy, at a 67 given time, by a signer under an identifier, e.g. a name or a 68 pseudonym, and optionally a role. 70 The European Directive on a community framework for Electronic 71 Signatures defines an electronic signature as: "data in electronic form 72 which is attached to or logically associated with other electronic data 73 and which serves as a method of authentication". An electronic 74 signature as used in the current document is a form of advanced 75 electronic signature as defined in the Directive. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 78 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 79 as shown) are to be interpreted as described in [RFC2119]. 81 TABLE OF CONTENTS 83 1. Introduction 1 84 2 Overview 4 85 2.1 Aim 4 86 2.2 Basis of Present Document 4 87 2.3 Major Parties 5 88 2.4 Electronic Signatures and Validation Data 6 89 2.5 Forms of Validation Data 7 90 2.6 Extended Forms of Validation Data 9 91 2.7 Archive Validation Data 11 92 2.8 Arbitration 12 93 2.9 Validation Process 12 94 2.10 Example Validation Sequence 13 95 2.11 Additional optional features 18 96 3. Data structure of an Electronic Signature 19 97 3.1 General Syntax 19 98 3.2 Data Content Type 19 99 3.3 Signed-data Content Type 19 100 3.4 SignedData Type 19 101 3.5 EncapsulatedContentInfo Type 20 102 3.6 SignerInfo Type 20 103 3.6.1 Message Digest Calculation Process 20 104 3.6.2 Message Signature Generation Process 20 105 3.6.3 Message Signature Verification Process 20 106 3.7 CMS Imported Mandatory Present Attributes 21 107 3.7.1 Content Type 21 108 3.7.2 Message Digest 21 109 3.7.3 Signing Time 21 111 Internet Draft Electronic Signature Formats 113 3.8 Alternative Signing Certificate Attributes 21 114 3.8.1 ESS Signing Certificate Attribute Definition 21 115 3.8.2 Other Signing Certificate Attribute Definition 22 116 3.9 Additional Mandatory Attributes 23 117 3.9.1 Signature policy Identifier 23 118 3.10 CMS Imported Optional Attributes 24 119 3.10.1 Countersignature 25 120 3.11 ESS Imported Optional Attributes 25 121 3.11.1 Content Reference Attribute 25 122 3.11.2 Content Identifier Attribute 25 123 3.12 Additional Optional Attributes 25 124 3.12.1 Commitment Type Indication Attribute 25 125 3.12.2 Signer Location attribute 27 126 3.12.3 Signer Attributes attribute 28 127 3.12.4 Content Timestamp attribute 28 128 3.13 Support for Multiple Signatures 29 129 3.13.1 Independent Signatures 29 130 3.13.2 Embedded Signatures 29 131 4. Validation Data 29 132 4.1 Electronic Signature Timestamp 30 133 4.1.1 Signature Timestamp Attribute Definition 30 134 4.2 Complete Validation Data 31 135 4.2.1 Complete Certificate Refs Attribute Definition 32 136 4.2.2 Complete Revocation Refs Attribute Definition 32 137 4.3 Extended Validation Data 34 138 4.3.1 Certificate Values Attribute Definition 34 139 4.3.2 Revocation Values Attribute Definition 35 140 4.3.3 ES-C Timestamp Attribute Definition 35 141 4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 36 142 4.4 Archive Validation Data 36 143 4.4.1 Archive Timestamp Attribute Definition 37 144 5. Security considerations 38 145 5.1 Protection of Private Key 38 146 5.2 Choice of Algorithms 38 147 6. Conformance Requirements 38 148 6.1 Signer 38 149 6.2 Verifier 39 150 7. References 40 151 8. Authors' Addresses 40 152 9. Full Copyright Statement 41 153 Annex A (normative): ASN.1 Definitions 43 154 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 43 155 A.2 Definitions Using X.680 1997 ASN.1 Syntax 52 156 Annex B (informative): General Description 61 157 B.1 The Signature Policy 61 158 B.2 Signed Information 62 159 B.3 Components of an Electronic Signature 62 160 B.3.1 Reference to the Signature Policy 62 161 B.3.2 Commitment Type Indication 63 162 B.3.3 Certificate Identifier from the Signer 64 164 Internet Draft Electronic Signature Formats 166 B.3.4. Role Attributes 64 167 B.3.4.1 Claimed Role 65 168 B.3.4.2 Certified Role 65 169 B.3.5 Signer Location 66 170 B.3.6 Signing Time 66 171 B.4 Components of Validation Data 67 172 B.4.1 Revocation Status Information 67 173 B.4.2 CRL Information 67 174 B.4.3 OCSP Information 68 175 B.4.4 Certification Path 69 176 B.4.5 Timestamping for Long Life of Signature 69 177 B.4.6 Timestamping before CA Key Compromises 70 178 B.4.6.1 Timestamping the ES with Complete validation data 71 179 B.4.6.2 Timestamping Certificates and Revocation Information 72 180 B.4.7 Timestamping for Long Life of Signature 72 181 B.4.8 Reference to Additional Data 73 182 B.4.9 Timestamping for Mutual Recognition 73 183 B.4.10 TSA Key Compromise 74 184 B.5 Multiple Signatures 74 185 Annex C (informative): Identifiers and roles 75 186 C.1 Signer Name Forms 75 187 C.2 TSP Name Forms 75 188 C.3 Roles and Signer Attributes 75 190 2 Overview 192 2.1 Aim 194 The aim of this document is to define an Electronic Signature (ES) that 195 remains valid over long periods. This includes evidence as to its 196 validity even if the signer or verifying party later attempts to deny 197 (repudiates) the validity of the signature. 199 This document specifies use of trusted service providers (e.g. 200 TimeStamping Authorities (TSA)), and the data that needs to be archived 201 (e.g. cross certificates and revocation lists) to meet the requirements 202 of long term electronic signatures. An electronic signature defined by 203 this document can be used for arbitration in case of a dispute between 204 the signer and verifier, which may occur at some later time, even years 205 later. This document uses a signature policy, referenced by the signer, 206 as the basis for establishing the validity of an electronic signature. 208 2.2 Basis of Present Document 210 This document is based on the use of public key cryptography to produce 211 digital signatures, supported by public key certificates. 213 A Public key certificate is a public keys of a user, together with some 214 other information, rendered unforgeable by encipherment with the 215 private key of the Certification Authority (CA) which issued it (ITU-T 216 Recommendation X.509 [1]). 218 Internet Draft Electronic Signature Formats 220 This document also uses timestamping services to prove the validity of 221 a signature long after the normal lifetime of critical elements of an 222 electronic signature and to support non-repudiation. It also, as an 223 option, uses additional timestamps to provide very long-term protection 224 against key compromise or weakened algorithms. 226 This document builds on existing standards that are widely adopted. 227 This includes: 229 * RFC 2459 [RFC2459] Internet X.509 Public Key Infrastructure 230 Certificate and CRL Profile (PKIX); 231 * RFC 2630 [CMS] Crytographic Message Syntax (CMS); 232 * RFC 2634 [ESS] Enhanced Security Services (ESS); 233 * RFC 2439 [OCSP] One-line Certificate Status Protocol (OCSP); 234 * ITU-T Recommendation X.509 [1] Authentication framework; 235 * RFC (to be published) [TSP] PKIX Time Stamping protocol (TSP). 237 NOTE: See clause 8 for a full set of references. 239 2.3 Major Parties 241 The following are the major parties involved in a business transaction 242 supported by electronic signatures as defined in this document: 244 * the Signer; 245 * the Verifier; 246 * the Arbitrator; 247 * Trusted Service Providers (TSP). 249 A Signer is an entity that creates the electronic signature. When 250 the signer digitally signs over data using the prescribed format, this 251 represents a commitment on behalf of the signing entity to the data 252 being signed. 254 A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1 255 [13]). Within the context of this document this is an entity that 256 validates an electronic signature. 257 An arbitrator, is an entity which arbitrates disputes between a signer 258 and a verifier when there is a disagreement on the validity of a 259 digital signature. 261 Trusted Service Providers (TSPs) are one or more entities that help 262 to build trust relationships between the signer and verifier. Use of 263 some specific TSP services MAY be mandated by signature policy. TSP 264 supporting services may provide the following information: user 265 certificates, cross-certificates, timestamping tokens, CRLs, ARLs, 266 OCSP responses. 268 Internet Draft Electronic Signature Formats 270 The following TSPs are used to support the validation or 271 the verification of electronic signatures : 273 * Certification Authorities; 274 * Registration Authorities; 275 * Repository Authorities (e.g. a Directory); 276 * TimeStamping Authorities; 277 * One-line Certificate Status Protocol responders; 278 * Attribute Authorities; 279 * Signature Policy Issuers. 281 Certification Authorities provide users with public key certificates. 283 Registration Authorities allows the registration of entities before a 284 CA generates certificates. 286 Repository Authorities publish CRLs issued by CAs, cross-certificates 287 (i.e. CA certificates) issued by CAs, signature policies issued by 288 Signature Policy Issuers and optionally public key certificates (i.e. 289 leaf certificates) issued by CAs. 291 TimeStamping Authorities attest that some data was formed before a 292 given trusted time. 294 One-line Certificate Status Protocol responders (OSCP responders) 295 provide information about the status (i.e. revoked, not revoked, 296 unknown) of a particular certificate. 298 A Signature Policy Issuer issues signatures policies that define the 299 technical and procedural requirements for electronic signature 300 creation, validation and verification, in order to meet a particular 301 business need. 303 Attributes Authorities provide users with attributes linked to public 304 key certificates 306 2.4 Electronic Signatures and Validation Data 308 Validation of an electronic signature in accordance with this document 309 requires: 311 * The electronic signature; this includes: 313 - the signature policy; 314 - the signed user data; 315 - the digital signature; 316 - other signed attributes provided by the signer; 317 . - other unsigned attributes provided by the signer. 319 * Validation data which is the additional data needed to validate 320 the electronic signature; this includes: 322 - certificates references; 323 - certificates; 325 Internet Draft Electronic Signature Formats 327 - revocation status information references; 328 - revocation status information; 329 - time-stamps from Time Stamping Authorities (TSAs). 331 * The signature policy specifies the technical requirements on 332 signature creation and validation in order to meet a particular 333 business need. A given legal/contractual context may recognize a 334 particular signature policy as meeting its requirements. 336 For example: a specific signature policy may be recognized by court 337 of law as meeting the requirements of the European Directive for 338 electronic commerce. A signature policy may be written using a formal 339 notation like ASN.1 or in an informal free text form provided the 340 rules of the policy are clearly identified. However, for a given 341 signature policy there shall be one definitive form which has a unique 342 binary encoded value. 344 Signed user data is the user's data that is signed. 346 The Digital Signature is the digital signature applied over the 347 following attributes provided by the signer: 349 * hash of the user data (message digest); 350 * signature Policy Identifier; 351 * other signed attributes 353 The other signed attributes include any additional information which 354 must be signed to conform to the signature policy or this document 355 (e.g. signing time). 357 The Validation Data may be collected by the signer and/or the verifier 358 and must meet the requirements of the signature policy. Additional 359 data includes CA certificates as well as revocation status information 360 in the form of Certificate Revocation Lists (CRLs) or certificate 361 status information provided by an on-line service. Additional data 362 also includes timestamps and other time related data used to provide 363 evidence of the timing of given events. It is required, as a minimum, 364 that either the signer or verifier obtains a timestamp over the 365 signer's signature. 367 A digital signature (not to be confused with an electronic signature) 368 is data appended to, or a cryptographic transformation of, a data unit 369 that allows a recipient of the data unit to prove the source and 370 integrity of the data unit and protect against forgery, e.g. by the 371 recipient (ISO 7498-2 [12]) 373 2.5 Forms of Validation Data 375 An electronic signature may exist in many forms including: 377 * the Electronic Signature (ES), which includes the digital 378 signature and other basic information provided by the signer; 380 Internet Draft Electronic Signature Formats 382 * the ES with Timestamp (ES-T), which adds a timestamp to the 383 Electronic Signature, to take initial steps towards providing 384 long term validity; 386 * the ES with Complete validation data (ES-C), which adds to the 387 ES-T references to the complete set of data supporting the 388 validity of the electronic signature (i.e. revocation status 389 information). 391 The signer must provide at least the ES form, but in some cases may 392 decide to provide the ES-T form and in the extreme case could provide 393 the ES-C form. If the signer does not provide ES-T, the verifier must 394 create the ES-T on first receipt of an electronic signature. The ES-T 395 provides independent evidence of the existence of the signature at the 396 time it was first verified which should be near the time it was 397 created, and so protects against later repudiation of the existence of 398 the signature. If the signer does not provide ES-C the verifier must 399 create the ES-C when the complete set of revocation and other 400 validation data is available. 402 The ES satisfies the legal requirements for electronic signatures as 403 defined in the European Directive on electronic signatures, see Annex C 404 for further discussion on relationship of this document to the 405 Directive. It provides basic authentication and integrity protection 406 and can be created without accessing on-line (timestamping) services. 407 However, without the addition of a timestamp the electronic signature 408 does not protect against the threat that the signer later denies having 409 created the electronic signature (i.e. does not provide non-repudiation 410 of its existence). 412 The ES-T time-stamp should be created close to the time that ES was 413 created to provide protection against repudiation. At this time all 414 the data needed to complete the validation may not be available but 415 what information is readily available may be used to carry out some of 416 the initial checks. For example, only part of the revocation 417 information may be available for verification at that point in time. 418 Generally, the ES-C form cannot be created at the same time as the ES, 419 as it is necessary to allow time for any revocation information to be 420 captured. Also, if a certificate is found to be temporarily suspended, 421 it will be necessary to wait until the end of the suspension period. 423 The signer should only create the ES-C in situations where it was 424 prepared to wait for a sufficient length of time after creating the ES 425 form before dispatching the ES-C. This, however, has the advantage that 426 the verifier can be presented with the complete set of data supporting 427 the validity of the ES. 429 Support for ES-C by the verifier is mandated (see clause 6 for 430 specific conformance requirements). 432 Internet Draft Electronic Signature Formats 434 An Electronic Signature (ES), with the additional validation data 435 forming the ES-T and ES-C is illustrated in Figure 1: 437 +------------------------------------------------------------ES-C-----+ 438 |+--------------------------------------------ES-T-----+ | 439 ||+------Elect.Signature (ES)----------+ +------------+| +-----------+| 440 |||+---------+ +----------+ +---------+| |Timestamp || |Complete || 441 ||||Signature| | Other | | Digital || |over digital|| |certificate|| 442 ||||Policy ID| | Signed | |Signature|| |signature || |and || 443 |||| | |Attributes| | || +------------+| |revocation || 444 |||+---------+ +----------+ +---------+| | |references || 445 ||+------------------------------------+ | +-----------+| 446 |+-----------------------------------------------------+ | 447 +---------------------------------------------------------------------+ 449 Figure 1: Illustration of an ES, ES-T and ES-C 451 2.6 Extended Forms of Validation Data 453 The complete validation data (ES-C) described above may be extended to 454 form an ES with eXtended validation data (ES-X) to meet following 455 additional requirements. 457 Firstly, when the verifier does not has access to, 459 * the signer's certificate, 460 * all the CA certificates that make up the full certification 461 path, 462 * all the associated revocation status information, as referenced 463 in the ES-C. 465 then the values of these certificates and revocation information may be 466 added to the ES-C. This form of extended validation data is called a 467 X-Long. 469 Secondly, if there is a risk that any CA keys used in the certificate 470 chain may be compromised, then it is necessary to additionally 471 timestamp the validation data by either: 473 * timestamping all the validation data as held with the ES(ES-C), 474 this eXtended validation data is called a Type 1 X-Timestamp; or 475 * timestamping individual reference data as used for complete 476 validation. 478 This form of eXtended validation data is called a Type 2 X-Timestamp. 480 NOTE: The advantages/drawbacks for Type 1 and Type 2 X-Timestamp are 481 discussed in this document (see clause B.4.6.) 483 Internet Draft Electronic Signature Formats 485 If all the above conditions occur then a combination of the two formats 486 above may be used. This form of eXtended validation data is called 487 a X-Long-Timestamped. 489 Support for the extended forms of validation data is optional. 491 An Electronic Signature (ES) , with the additional validation data 492 forming the ES-X long is illustrated in Figure 2: 494 +------------------------------------------------------- ES-X Long--+ 495 |+--------------------------------------- EC-C --------+ | 496 ||+---- Elect.Signature (ES)----+ +--------+| +--------+ | 497 |||+-------+-+-------+-+-------+| +---------+|Complete|| |Complete| | 498 ||||Signa- | |Other | |Digital|| |Timestamp||certi- || |certi- | | 499 ||||ture | |Signed | |Signa- || |over ||ficate || |ficate | | 500 ||||Policy | |Attri- | |ture || |digital ||and || |and | | 501 ||||ID | |butes | | || |signature||revoc. || |revoc. | | 502 |||+-------+ +-------+ +-------+| +---------+|refs || |data | | 503 ||+-----------------------------+ +--------+| +--------+ | 504 |+-----------------------------------------------------+ | 505 +-------------------------------------------------------------------+ 507 Figure 2: Illustration of an ES and ES-X long. 509 An Electronic Signature (ES) , with the additional validation data 510 forming the eXtended Validation Data - Type 1 is illustrated in 511 Figure 3: 513 +---------------------------------------------------------- ES-X 1 -+ 514 |+---------------------------------------- EC-C --------+ | 515 || +---- Elect.Signature (ES)----+ +--------+| +-------+ | 516 || |+-------+ +-------+ +-------+| +---------+|Complete|| | | | 517 || ||Signa- | |Other | |Digital|| |Timestamp||certifi-|| | Time- | | 518 || ||ture | |Signed | |Signa- || |over ||cate and|| | stamp | | 519 || ||Policy | |Attri- | |ture || |digital ||revoc. || | over | | 520 || ||ID | |butes | | || |signature||refs || | CES | | 521 || |+-------+ +-------+ +-------+| +---------+| || | | | 522 || +-----------------------------+ +--------+| +-------+ | 523 |+------------------------------------------------------+ | 524 +-------------------------------------------------------------------+ 526 Figure 3: Illustration of ES with ES-X Type 1 528 Internet Draft Electronic Signature Formats 530 An Electronic Signature (ES) , with the additional validation data 531 forming the eXtended Validation Data - Type 2 is illustrated in 532 Figure 4: 534 +-------------------------------------------------------- ES-X 2 ---+ 535 |+--------------------------------------- EC-C --------+ | 536 ||+---- Elect.Signature (ES)----+ +--------+| +--------+ | 537 |||+-------+ +-------+ +-------+| +---------+|Complete|| |Times | | 538 ||||Signa- | |Other | |Digital|| |Timestamp||certs || |Stamp | | 539 ||||ture | |Signed | |Signa- || |over ||and || |over | | 540 ||||Policy | |Attri- | |ture || |digital ||revoc. || |Complete| | 541 ||||ID | |butes | | || |signature||refs || |certs | | 542 |||+-------+ +-------+ +-------+| +---------+| || |and | | 543 ||+-----------------------------+ +--------+| |revoc. | | 544 || | |refs | | 545 |+-----------------------------------------------------+ +--------+ | 546 +-------------------------------------------------------------------+ 548 Figure 4: Illustration of ES with ES-X Type 2 550 2.7 Archive Validation Data 552 Before the algorithms, keys and other cryptographic data used at the 553 time the ES-C was built become weak and the cryptographic functions 554 become vulnerable, or the certificates supporting previous timestamps 555 expires, the signed data, the ES-C and any additional information 556 (ES-X) should be timestamped. If possible this should use stronger 557 algorithms (or longer key lengths) than in the original timestamp. 559 This additional data and timestamp is called Archive Validation Data 560 (ES-A). The Timestamping process may be repeated every time the 561 protection used to timestamp a previous ES-A become weak. An ES-A 562 may thus bear multiple embedded time stamps. 564 An example of an Electronic Signature (ES), with the additional 565 validation data for the ES-C and ES-X forming the ES-A is illustrated 566 in Figure 5. 568 +-------------------------------- ES-A --------- ----------+ 569 | +-------------------- ES-A -----------------+ | 570 | | +--------- ES-X -------------- + | | 571 | | |..............................| +-----+ | +-----+ | 572 | | |..............................| |Time | | |Time | | 573 | | |..............................| |Stamp| | |Stamp| | 574 | | | | +-----+ | +-----+ | 575 | | +----------------------------- + | | 576 | +-------------------------------------------+ | 577 +----------------------------------------------------------+ 579 Figure 5: Illustration of ES -A 581 Support for ES-A is optional. 583 Internet Draft Electronic Signature Formats 585 2.8 Arbitration 587 The ES-C may be used for arbitration should there be a dispute between 588 the signer and verifier, provided that: 590 * a copy of the signature policy referenced by the signer is 591 available; 593 * the arbitrator knows where to retrieve the signer's certificate 594 (if not already present), all the cross-certificates and the 595 required CRLs and/or OCSPs responses referenced in the ES-C; 597 * none of the issuing key from the certificate chain have ever 598 been compromised; 600 * the cryptography used at the time the ES-C was built has not 601 been broken at the time the arbitration is performed. 603 When the second condition is not met, then the plaintiff must provide 604 an ES-X Long. 606 When it is known by some external means that the third condition is 607 not met, then the plaintiff must provide an ES-X Timestamped. 609 When the two previous conditions are not met, the plaintiff must 610 provide the two above information (i.e. an ES-X Timestamped and Long). 612 When the last condition is not met, the plaintiff must provide an 613 ES-A. 615 It should be noticed that a verifier may need to get two time stamps 616 at two different instants of time: one soon after the generation of 617 the ES and one soon after some grace period allowing any entity from 618 the certification chain to declare a key compromise. 620 2.9 Validation Process 622 The Validation Process validates an electronic signature in accordance 623 with the requirements of the signature policy. The output status of 624 the validation process can be: 626 * valid; 627 * invalid; 628 * incomplete verification. 630 A Valid response indicates that the signature has passed verification 631 and it complies with the signature validation policy. 633 A signature validation policy is a part of the signature policy which 634 specifies the technical requirements on the signer in creating a 635 signature and verifier when validating a signature. 637 Internet Draft Electronic Signature Formats 639 An Invalid response indicates that either the signature format is 640 incorrect or that the digital signature value fails verification 641 (e.g. the integrity checks on the digital signature value fails or 642 any of the certificates on which the digital signature verification 643 depends is known to be invalid or revoked). 645 An Incomplete Validation response indicates that the format and 646 digital signature verifications have not failed but there is 647 insufficient information to determine if the electronic signature 648 is valid under the signature policy. This can include situations 649 where additional information, which does not effect the validity of 650 the digital signature value, may be available but is invalid. 652 In the case of Incomplete Validation, it may be possible to request 653 that the electronic signature be checked again at a later date when 654 additional validation information might become available. Also, in the 655 case of incomplete validation, additional information may be made 656 available to the application or user, thus allowing the application or 657 user to decide what to do with partially correct electronic signatures. 659 The validation process may also output validation data : 661 * a signature timestamp; 662 * the complete validation data; 663 * the archive validation data. 665 2.10 Example Validation Sequence 667 As described earlier the signer or verifier may collect all the 668 additional data that forms the Electronic Signature. Figure 6, and 669 subsequent description, describes how the validation process may build 670 up a complete electronic signature over time. 672 Soon after receiving the electronic signature (ES) from the signer (1), 673 the digital signature value may be checked, the validation process 674 must at least add a time-stamp (2), unless the signer has provided one 675 which is trusted by the verifier. The validation process may also 676 validate the electronic signature, as required under the identified 677 signature policy, using additional data (e.g. certificates, CRL, etc.) 678 provided by trusted service providers. If the validation process is not 679 complete then the output from this stage is the ES-T. 681 When all the additional data (e.g. the complete certificate and 682 revocation information) necessary to validate the electronic signature 683 first becomes available, then the validation process: 685 * obtains all the necessary additional certificate and revocation 686 status information; 688 * completes all the validation checks on the ES, using the 689 complete certificate and revocation information (if a timestamp 690 is not already present, this may be added at the same stage 691 combining ES-T and ES-C process); 693 Internet Draft Electronic Signature Formats 695 * records the complete certificate and revocation references (3); 697 * indicates the validity status to the user (4). 699 +---------------------------------------- ES-C ----------+ 700 |+----------------------------- ES-T -------+ | 701 ||+--- Elect.Signature (ES) ----+ | +--------+ | 702 |||+-------+ +-------+ +-------+|+---------+| |Complete| | 703 ||||Signa- | |Other | |Digital|||Timestamp|| |certifi-| | 704 ||||ture | |Signed | |Signa- |||over || |cate and| | 705 ||||Policy | |Attri- | |ture |||digital || |revoca- | | 706 ||||ID | |butes | | |||signature|| |tion | | 707 |||+-------+ +-------+ +-------+|+---------+| |referen-| | 708 ||+------------\----------------+ ^ | |ces | | 709 || \ | | +--------+ | 710 || \ 1 / | ^ | 711 |+----------------\----------------/--------+ | | 712 +------------------\--------------/-------------- /------+ 713 \ /2 ----3-----/ 714 +----------+ | / / 715 | Signed |\ v / | 716 |User data | \ +--------------------+ +------------+ 717 +----------+ \--->| Validation Process |---> |- Valid | 718 +---|--^-------|--^--+ 4 |- Invalid | 719 | | | | |- Validation| 720 v | v | | Incomplete| 721 +---------+ +--------+ +------------+ 722 |Signature| |Trusted | 723 | Policy | |Service | 724 | Issuer | |Provider| 725 +---------+ +--------+ 727 Figure 6: Illustration of an ES with Complete validation data (ES-C) 729 Internet Draft Electronic Signature Formats 731 At the same time as the validation process creates the ES-C, the 732 validation process may provide and/or record the values of certificates 733 and revocation status information used in ES-C, called the ES-X Long 734 (5). This is illustrated in figure 7: 736 +---------------------------------------------------- ES-X ---------+ 737 |+--------------------------------------- ES-C --------+ +--------+ | 738 ||+--- Elect.Signature (ES) ----+ +--------+ | |Complete| | 739 |||+-------+ +-------+ +-------+|+---------+|Complete| | |certifi-| | 740 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |cate | | 741 ||||ture | |Signed | |Signa- |||over ||cate and| | |and | | 742 ||||Policy | |Attri- | |ture |||digital ||revoca- | | |revoca- | | 743 ||||ID | |butes | | |||signature||tion | | |tion | | 744 |||+-------+ +---|---+ +-------+|+---------+|referen-| | |Data | | 745 ||+--------------\--------------+ ^ |ces | | +--------+ | 746 || \ | +--------+ | ^ | 747 || \ 1 2/ ^ | | | 748 |+------------------\--------------/-----------|-------+ / | 749 +--------------------\------------/-----------/-------------/-------+ 750 \ / ---3---/ / 751 +----------+ | / / -----------5-----/ 752 | Signed |\ v | | / 753 |User data | \ +--------------------+ +-----------+ 754 +----------+ \--->| Validation Process |---> | - Valid | 755 +---|--^-------|--^--+ 4 | - Invalid | 756 | | | | +-----------+ 757 v | v | 758 +---------+ +--------+ 759 |Signature| |Trusted | 760 | Policy | |Service | 761 | Issuer | |Provider| 762 +---------+ +--------+ 764 Figure 7: Illustration ES with eXtended validation data (Long) 766 Internet Draft Electronic Signature Formats 768 When the validation process creates the ES-C it may also create 769 extended forms of validation data. A first alternative is to timestamp 770 all data forming the Type 1 X-Timestamp (6). This is illustrated in 771 figure 8: 773 +---------------------------------------------------- ES-X -------+ 774 |+--------------------------------------- ES-C --------+ +------+ | 775 ||+--- Elect.Signature (ES) ----+ +--------+ | |Time- | | 776 |||+-------+ +-------+ +-------+|+---------+|Complete| | |stamp | | 777 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |over | | 778 ||||ture | |Signed | |Signa- |||over ||cate and| | |CES | | 779 ||||Policy | |Attri- | |ture |||digital ||revoca- | | +------+ | 780 ||||ID | |butes | | |||signature||tion | | ^ | 781 |||+-------+ +--|----+ +-------+|+---------+|referen-| | | | 782 ||+-------------|---------------+ ^ |ces | | | | 783 || | | +--------+ | | | 784 || \ 1 2/ ^ | | | 785 |+----------------\------------------/---------|-------+ | | 786 +------------------\----------------/----------/-------------/----+ 787 \ / ----3--/ / 788 +----------+ | / / --------------6---/ 789 | Signed |\ v | | / 790 |User data | \ +--------------------+ +-----------+ 791 +----------+ \--->| Validation Process |---> | - Valid | 792 +---|--^-------|--^--+ 4 | - Invalid | 793 | | | | +-----------+ 794 v | v | 795 +---------+ +--------+ 796 |Signature| |Trusted | 797 | Policy | |Service | 798 | Issuer | |Provider| 799 +---------+ +--------+ 801 Figure 8: Illustration of ES with eXtended validation data - Type 1 X- 802 Timestamp 804 Internet Draft Electronic Signature Formats 806 Another alternative is to timestamp the certificate and revocation 807 information references used to validate the electronic signature (but 808 not the signature) (6'); this is called Type 2 X-Timestamped. This is 809 illustrated in figure 9: 811 +---------------------------------------------------- ES-X ----------+ 812 |+--------------------------------------- ES-C --------+ +---------+ | 813 ||+--- Elect.Signature (ES) ----+ +--------+ | |Timestamp| | 814 |||+-------+ +-------+ +-------+|+---------+|Complete| | |over | | 815 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |Complete | | 816 ||||ture | |Signed | |Signa- |||over ||cate and| | |Certifi- | | 817 ||||Policy | |Attri- | |ture |||digital ||revoc. | | |cate and | | 818 ||||ID | |butes | | |||signature||refs | | |revoc. | | 819 |||+-------+ +---^---+ +-------+|+----^----++---^----+ | |refs | | 820 ||+--------------\--------------+ | | | +---------+ | 821 |+----------------\------------------/----------|------+ ^ | 822 +----------------1-\----------------/----------/--------------|------+ 823 \ / -----3--/ | 824 +----------+ | 2/ / --------------6'-----/ 825 | Signed |\ v | | / 826 |User data | \ +--------------------+ +-----------+ 827 +----------+ \--->| Validation Process |---> | - Valid | 828 +---|--^-------|--^--+ 4 | - Invalid | 829 | | | | +-----------+ 830 v | v | 831 +---------+ +--------+ 832 |Signature| |Trusted | 833 | Policy | |Service | 834 | Issuer | |Provider| 835 +---------+ +--------+ 837 Figure 9: Illustration of ES with eXtended validation data - Type 2 X- 838 Timestamp 840 Internet Draft Electronic Signature Formats 842 Before the algorithms used in any of electronic signatures become or 843 are likely, to be compromised or rendered vulnerable in the future, it 844 is necessary to timestamp the entire electronic signature, including 845 all the values of the validation and user data as an ES with Archive 846 validation data (ES-A) 848 An ES-A is illustrated in figure 10: 850 -------------------------------------------- ES-A --------------------+ 851 ----------------------------------------------------------------+ | 852 +------------------------------- EC-C --------++-----+ | | 853 | ||Time-| | | 854 |+-- Elect.Signature (ES) -+ +--------+||stamp| +-------+ | 855 ||+------++-------++-------|+------+|Complete|||over | Complete| | 856 |||Signa-||Other ||Digital||Time- ||certifi-|||CES | |certi- |+----| 857 |||ture ||Signed ||Signa- ||stamp ||cate and||+-----+ |ficate |Arch-| 858 |||Policy||Attri- ||ture ||over ||revoca- ||+------+ |and |ive | 859 |||ID ||butes || ||digit.||tion |||Time- | |revoca-|Time | 860 ||+------++---|---++-------||signa-||referen-|||stamp-| |tion |stamp| 861 |+------------|------------+|ture ||ces |||over | |data |+----| 862 | | +------++--------+|Complete\+-------+ ^ | 863 | | ^ ^ ||cert. | | | | 864 +-------------|----------------|---------|----+|and rev| | | | 865 \ | / |refs. | | | | 866 \ | / +-------+ | | | 867 -----------------\-------------|-------/------------------------+ | | 868 +----------+ \ | / / | 869 | Signed | \2 |3 / /--------------7-------/ | 870 |User data | \ | | / | 871 +-------\--+ \ | | / | 872 ---------\------------|--------|----|---/-----------------------------+ 873 \ v | | | 874 1\ +--------------------+ +-----------+ 875 \------>| Validation Process |---> | - Valid | 876 +---|--^-------|--^--+ 4 | - Invalid | 877 | | | | +-----------+ 878 v | v | 879 +---------+ +--------+ 880 |Signature| |Trusted | 881 | Policy | |Service | 882 | Issuer | |Provider| 883 +---------+ +--------+ 885 Figure 10: Illustration of an ES with Archive validation data (ES-A) 887 2.11 Additional optional features 889 This document also defines additional optional features to: 891 * indicate a commitment type being made by the signer; 892 * indicate the role under which a signature was created; 893 * support multiple signatures. 895 Internet Draft Electronic Signature Formats 897 3. Data structure of an Electronic Signature 899 This clause uses and builds upon the Cryptographic Message Syntax 900 (CMS), as defined in RFC 2630 [CMS], and Enhanced Security Services 901 (ESS), as defined in RFC 2634 [ESS]. The overall structure 902 of Electronic Signature is as defined in [CMS]. The Electronic 903 Signature (ES) uses attributes defined in [CMS], [ESS] and 904 this document. This document defines in full the ES attributes which it 905 uses and are not defined elsewhere. 907 The mandated set of attributes and the digital signature value is 908 defined as the minimum Electronic Signature (ES) required by this 909 document. A signature policy MAY mandate other signed attributes to be 910 present. 912 3.1 General Syntax 914 The general syntax of the ES is as defined in [CMS]. 916 3.2 Data Content Type 918 The data content type of the ES is as defined in [CMS]. 920 The data content type is intended to refer to arbitrary octet strings, 921 such as ASCII text files; the interpretation is left to the 922 application. Such strings need not have any internal structure 923 (although they could have their own ASN.1 definition or other 924 structure). 926 3.3 Signed-data Content Type 928 The Signed-data content type of the ES is as defined in [CMS]. 930 The signed-data content type consists of a content of any type and zero 931 or more signature values. Any number of signers in parallel can sign 932 any type of content. The typical application of the signed-data content 933 type represents one signer's digital signature on content of the data 934 content type. 936 To make sure that the verifier uses the right certificate, this 937 document mandates that the hash of the signers certificate is always 938 included in the Signing Certificate signed attribute. 940 3.4 SignedData Type 942 The syntax of the SignedData type of the ES is as defined in [CMS]. 944 The fields of type SignedData have the meanings defined [CMS] except 945 that: 947 * version is the syntax version number. The value of version must 948 be 3. 950 Internet Draft Electronic Signature Formats 952 * The identification of signer's certificate used to create the 953 signature is always present as a signed attribute. 955 * The degenerate case where there are no signers is not valid in 956 this document. 958 3.5 EncapsulatedContentInfo Type 960 The syntax of the EncapsulatedContentInfo a type of the ES is as 961 defined in [CMS]. 963 For the purpose of long term validation as defined by this document, it 964 is advisable that either the eContent is present, or the data which is 965 signed is archived in such as way as to preserve the any data encoding. 966 It is important that the OCTET STRING used to generate the signature 967 remains the same every time either the verifier or an arbitrator 968 validates the signature. 970 The degenerate case where there are no signers is not valid in this 971 document. 973 3.6 SignerInfo Type 975 The syntax of the SignerInfo a type of the ES is as defined in [CMS]. 977 Per-signer information is represented in the type SignerInfo. In the 978 case of multiple independent signatures, there is an instance 979 of this field for each signer. 981 The fields of type SignerInfo have the meanings defined in [CMS] 982 except that signedAttributes must, as a minimum, contain the following 983 attributes: 985 * ContentType as defined in clause 3.7.1. 986 * MessageDigest as defined in clause 3.7.2. 987 * SigningTime as defined in clause 3.7.3. 988 * SigningCertificate as defined in clause 3.8.1. 989 * SignaturePolicyId as defined in clause 3.9.1. 991 3.6.1 Message Digest Calculation Process 993 The message digest calculation process is as defined in [CMS]. 995 3.6.2 Message Signature Generation Process 997 The input to the digital signature generation process is as defined in 998 [CMS]. 1000 3.6.3 Message Signature Verification Process 1002 The procedures for CMS signed data validation are as defined in 1003 [CMS] and enhanced in this document. 1005 Internet Draft Electronic Signature Formats 1007 The input to the signature verification process includes the signer's 1008 public key verified as correct using either the ESS Signing 1009 Certificate attribute or the Other Signing Certificate attribute. 1011 3.7 CMS Imported Mandatory Present Attributes 1013 The following attributes MUST be present with the signed-data defined 1014 by this document. The attributes are defined in [CMS]. 1016 3.7.1 Content Type 1018 The syntax of the content-type attribute type of the ES is as defined 1019 in [CMS]. 1021 3.7.2 Message Digest 1023 The syntax of the message-digest attribute type of the ES is as defined 1024 in [CMS]. 1026 3.7.3 Signing Time 1028 The syntax of the message-digest attribute type of the ES is as defined 1029 in [CMS] and further qualified by this document. 1031 The signing-time attribute type specifies the time at which the signer 1032 claims to have performed the signing process. 1034 This present document recommends the use of GeneralizedTime. 1036 3.8 Alternative Signing Certificate Attributes 1038 One, and only one, of the following two alternative attributes MUST be 1039 present with the signed-data defined by this document to identify the 1040 signing certificate. Both attributes include an identifier and a hash 1041 of the signing certificate. The first, which is adopted in existing 1042 standards, may be only used with the SHA-1 hashing algorithm. The 1043 other shall be used when other hashing algorithms are to be supported. 1045 The signing certificate attribute is designed to prevent the simple 1046 substitution and re-issue attacks, and to allow for a restricted set of 1047 authorization certificates to be used in verifying a signature. 1049 3.8.1 ESS Signing Certificate Attribute Definition 1051 The syntax of the signing certificate attribute type of the ES is as 1052 defined in [ESS], and further qualified and profile in this document. 1054 The ESS signing certificate attribute must be a signed attribute. 1056 This document mandates the presence of this attribute as a signed CMS 1057 attribute, and the sequence must not be empty. The certificate used to 1058 verify the signature must be identified in the sequence, the Signature 1059 Validation Policy may mandate other certificate references to be 1060 present, that may include all the certificates up to the point of 1062 Internet Draft Electronic Signature Formats 1064 trust. The encoding of the ESSCertID for this certificate must include 1065 the issuerSerial field. 1067 The issuerAndSerialNumber present in the SignerInfo must be 1068 consistent with issuerSerial field. The certificate identified must be 1069 used during the signature verification process. If the hash of the 1070 certificate does not match the certificate used to verify the 1071 signature, the signature must be considered invalid. 1073 The sequence of policy information field is not used in this document. 1075 NOTE: Where an attribute certificate is used by the signer to associate 1076 a role, or other attributes of the signer, with the electronic 1077 signature this is placed in the Signer Attribute attribute as defined 1078 in clause 3.12.3. 1080 3.8.2 Other Signing Certificate Attribute Definition 1082 The following attribute is identical to the ESS SigningCertificate 1083 defined above except that this attribute can be used with hashing 1084 algorithms other than SHA-1. 1086 This attribute must be used in the same manner as defined above for 1087 the ESS SigningCertificate attribute. 1089 The following object identifier identifies the signing certificate 1090 attribute: 1092 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 1093 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1094 smime(16) id-aa(2) 19 } 1096 The signing certificate attribute value has the ASN.1 syntax 1097 OtherSigningCertificate 1099 OtherSigningCertificate ::= SEQUENCE { 1100 certs SEQUENCE OF OtherCertID, 1101 policies SEQUENCE OF PolicyInformation OPTIONAL 1102 -- NOT USED IN THIS DOCUMENT 1103 } 1105 OtherCertID ::= SEQUENCE { 1106 otherCertHash OtherHash, 1107 issuerSerial IssuerSerial OPTIONAL 1108 } 1110 OtherHash ::= CHOICE { 1111 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 1112 otherHash OtherHashAlgAndValue 1113 } 1115 OtherHashValue ::= OCTET STRING 1117 Internet Draft Electronic Signature Formats 1119 OtherHashAlgAndValue ::= SEQUENCE { 1120 hashAlgorithm AlgorithmIdentifier, 1121 hashValue OtherHashValue 1122 } 1124 3.9 Additional Mandatory Attributes 1126 3.9.1 Signature policy Identifier 1128 This document mandates that a reference to the signature policy, which 1129 defines the rules for creation and validation of an electronic 1130 signature, is included as a signed attribute with every signature. The 1131 signature policy identifier must be a signed attribute. 1133 The following object identifier identifies the signature policy 1134 identifier attribute: 1136 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 1137 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1138 smime(16) id-aa(2) 15 } 1140 Signature-policy-identifier attribute values have ASN.1 type 1141 SignaturePolicyIdentifier. 1143 SignaturePolicyIdentifier ::= SEQUENCE { 1144 sigPolicyIdentifier SigPolicyId, 1145 sigPolicyHash SigPolicyHash, 1146 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 1147 SigPolicyQualifierInfo OPTIONAL 1148 } 1150 The sigPolicyIdentifier field contains an object-identifier which 1151 uniquely identifies a specific version of the signature policy. The 1152 syntax of this field is as follows: 1154 SigPolicyId ::= OBJECT IDENTIFIER 1156 The sigPolicyHash field contains the identifier of the hash algorithm 1157 and the hash of the value of the signature policy. 1159 If the signature policy is defined using a computer processable 1160 notation like ASN.1, then the hash is calculated on the value without 1161 the outer type and length fields and the hashing algorithm must be as 1162 specified in the field signPolicyHshAlg. 1164 If the signature policy is defined using another structure, the type of 1165 structure and the hashing algorithm must be either specified as part 1166 of the signature policy, or indicated using a signature policy 1167 qualifier. 1169 SigPolicyHash ::= ETSIHashAlgAndValue 1171 Internet Draft Electronic Signature Formats 1173 A signature policy identifier may be qualified with other information 1174 about the qualifier. The semantics and syntax of the qualifier is as 1175 associated with the object-identifier in the sigPolicyQualifierId 1176 field. The general syntax of this qualifier is as follows: 1178 SigPolicyQualifierInfo ::= SEQUENCE { 1179 sigPolicyQualifierId SigPolicyQualifierId, 1180 sigQualifier ANY DEFINED BY sigPolicyQualifierId 1181 } 1183 This document specifies the following qualifiers: 1185 * spuri: This contains the web URI or URL reference to the 1186 signature policy 1188 * spUserNotice: This contains a user notice which should be 1189 displayed whenever the signature is validated. 1191 -- sigpolicyQualifierIds defined in this document 1193 SigPolicyQualifierId ::= OBJECT IDENTIFIER 1195 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 1196 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1197 smime(16) id-spq(5) 1 } 1199 SPuri ::= IA5String 1201 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 1202 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1203 smime(16) id-spq(5) 2 } 1205 SPUserNotice ::= SEQUENCE { 1206 noticeRef NoticeReference OPTIONAL, 1207 explicitText DisplayText OPTIONAL 1208 } 1210 NoticeReference ::= SEQUENCE { 1211 organization DisplayText, 1212 noticeNumbers SEQUENCE OF INTEGER 1213 } 1215 DisplayText ::= CHOICE { 1216 visibleString VisibleString (SIZE (1..200)), 1217 bmpString BMPString (SIZE (1..200)), 1218 utf8String UTF8String (SIZE (1..200)) 1219 } 1221 3.10 CMS Imported Optional Attributes 1223 The following attributes MAY be present with the signed-data defined by 1224 this document. The attributes are defined in ref [CMS] and are imported 1226 Internet Draft Electronic Signature Formats 1228 into this specification and were appropriate qualified and profiling by 1229 this document. 1231 3.10.1 Countersignature 1233 The syntax of the countersignature attribute type of the ES is as 1234 defined in [CMS]. The countersignature attribute must be an unsigned 1235 attribute. 1237 3.11 ESS Imported Optional Attributes 1239 The following attributes MAY be present with the signed-data defined by 1240 this document. The attributes are defined in ref [ESS] and are imported 1241 into this specification and were appropriate qualified and profiling 1242 by this document. 1244 3.11.1 Content Reference Attribute 1246 The content reference attribute is a link from one SignedData to 1247 another. It may be used to link a reply to the original message to 1248 which it refers, or to incorporate by reference one SignedData into 1249 another. 1251 The content reference attribute MUST be used as defined in [ESS]. The 1252 content reference MUST be a signed attribute. 1254 The syntax of the content reference attribute type of the ES is as 1255 defined in [ESS]. 1257 3.11.2 Content Identifier Attribute 1259 The content identifier attribute provides an identifier for the signed 1260 content for use when reference may be later required to that content, 1261 for example in the content reference attribute in other signed data 1262 sent later. 1264 The content identifier must be a signed attribute. 1266 The syntax of the content identifier attribute type of the ES is as 1267 defined in [ESS]. 1269 The minimal signedContentIdentifier should contain a concatenation of 1270 user-specific identification information (such as a user name or public 1271 keying material identification information), a GeneralizedTime string, 1272 and a random number. 1274 3.12 Additional Optional Attributes 1276 3.12.1 Commitment Type Indication Attribute 1278 There may be situation were a signer wants to explicitly indicate to a 1279 verifier that by signing the data, it illustrates a type of commitment 1280 on behalf of the signer. The commitmentTypeIndication attribute conveys 1281 such information. 1283 Internet Draft Electronic Signature Formats 1285 The commitmentTypeIndication attribute must be a signed attribute. 1287 The commitment type may be: 1289 * defined as part of the signature policy, in which case the 1290 commitment type has precise semantics that is defined as part of 1291 the signature policy. 1293 * be a registered type, in which case the commitment type has 1294 precise semantics defined by registration, under the rules of the 1295 registration authority. Such a registration authority may be a 1296 trading association or a legislative authority. 1298 The signature policy specifies a set of attributes that it 1299 "recognizes". This "recognized" set includes all those commitment types 1300 defined as part of the signature policy as well as any externally 1301 defined commitment types that the policy may choose to recognize. Only 1302 recognized commitment types are allowed in this field. 1304 The following object identifier identifies the commitment type 1305 indication attribute: 1307 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1308 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 1310 Commitment-Type-Indication attribute values have ASN.1 type 1311 CommitmentTypeIndication. 1313 CommitmentTypeIndication ::= SEQUENCE { 1314 commitmentTypeId CommitmentTypeIdentifier, 1315 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 1316 CommitmentTypeQualifier OPTIONAL 1317 } 1319 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 1321 CommitmentTypeQualifier ::= SEQUENCE { 1322 commitmentTypeIdentifier CommitmentTypeIdentifier, 1323 qualifier ANY DEFINED BY 1324 commitmentTypeIdentifier 1325 } 1327 The use of any qualifiers to the commitment type is outside the scope 1328 of this document. 1330 The following generic commitment types are defined in this document: 1332 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member- 1333 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1334 cti(6) 1} 1336 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member- 1337 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1338 cti(6) 2} 1340 Internet Draft Electronic Signature Formats 1342 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 1343 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1344 smime(16) cti(6) 3} 1346 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- 1347 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1348 cti(6) 4} 1350 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) 1351 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1352 smime(16) cti(6) 5} 1354 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) 1355 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1356 smime(16) cti(6) 6} 1358 These generic commitment types have the following meaning: 1360 Proof of origin indicates that the signer recognizes to have created, 1361 approved and sent the message. 1363 Proof of receipt indicates that signer recognizes to have received the 1364 content of the message. 1366 Proof of delivery indicates that the TSP providing that indication has 1367 delivered a message in a local store accessible to the recipient of the 1368 message. 1370 Proof of sender indicates that the entity providing that indication has 1371 sent the message (but not necessarily created it). 1373 Proof of approval indicates that the signer has approved the content of 1374 the message. 1376 Proof of creation indicates that the signer has created the message 1377 (but not necessarily approved, nor sent it). 1379 3.12.2 Signer Location attribute 1381 The signer-location attribute is an attribute which specifies a 1382 mnemonic for an address associated with the signer at a particular 1383 geographical (e.g. city) location. The mnemonic is registered in the 1384 country in which the signer is located and is used in the provision of 1385 the Public Telegram Service (according to ITU-T Recommendation F.1 1386 [PTS]). 1388 The signer-location attribute must be a signed attribute. 1390 The following object identifier identifies the signer-location 1391 attribute: 1393 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1394 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 1396 Internet Draft Electronic Signature Formats 1398 Signer-location attribute values have ASN.1 type SignerLocation. 1400 SignerLocation ::= SEQUENCE { 1401 -- at least one of the following must be present 1402 countryName [0] DirectoryString OPTIONAL, 1403 -- as used to name a Country in X.500 1404 localityName [1] DirectoryString OPTIONAL, 1405 -- as used to name a locality in X.500 1406 postalAdddress [2] PostalAddress OPTIONAL 1407 } 1409 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 1411 3.12.3 Signer Attributes attribute 1413 The signer-attributes attribute is an attribute which specifies 1414 additional attributes of the signer (e.g. role). 1416 It may be either: 1418 * claimed attributes of the signer; or 1419 * certified attributes of the signer; 1421 The signer-attributes attribute must be a signed attribute. 1423 The following object identifier identifies the signer-attribute 1424 attribute: 1426 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1427 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 1429 signer-attribute attribute values have ASN.1 type SignerAttribute. 1431 SignerAttribute ::= SEQUENCE OF CHOICE { 1432 claimedAttributes [0] ClaimedAttributes, 1433 certifiedAttributes [1] CertifiedAttributes 1434 } 1436 ClaimedAttributes ::= SEQUENCE OF Attribute 1438 CertifiedAttributes ::= AttributeCertificate 1439 -- as defined in X.509 : see section 10.3 1441 NOTE: The claimed and certified attribute are imported from ITU-T 1442 Recommendations X.501 [16] and ITU-T Recommendation X.509 : Draft 1443 Amendment on Certificate Extensions, October 1999. 1445 3.12.4 Content Timestamp attribute 1447 The content timestamp attribute is an attribute which is the timestamp 1448 of the signed data content before it is signed. 1450 The content timestamp attribute must be a signed attribute. 1452 Internet Draft Electronic Signature Formats 1454 The following object identifier identifies the signer-attribute 1455 attribute: 1457 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) 1458 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1459 smime(16) id-aa(2) 20} 1461 Content timestamp attribute values have ASN.1 type ContentTimestamp: 1462 ContentTimestamp::= TimeStampToken 1464 The value of messageImprint field within TimeStampToken must be a hash 1465 of the value of eContent field within encapContentInfo within the 1466 signedData. 1468 For further information and definition of TimeStampToken see [TSP]. 1470 3.13 Support for Multiple Signatures 1472 3.13.1 Independent Signatures 1474 Multiple independent signatures are supported by independent SignerInfo 1475 from each signer. 1477 Each SignerInfo must include all the attributes required under this 1478 document and must be processed independently by the verifier. 1480 3.13.2 Embedded Signatures 1482 Multiple embedded signatures are supported using the counter-signature 1483 unsigned attribute (see clause 3.10.1). Each counter signature is 1484 carried in Countersignature held as an unsigned attribute to the 1485 SignerInfo to which the counter-signature is applied. 1487 4. Validation Data 1489 This clause specifies the validation data structures which builds on 1490 the electronic signature specified in clause 3. This includes: 1492 * Timestamp applied to the electronic signature value. 1494 * Complete validation data which comprises the timestamp of the 1495 signature value, plus references to all the certificates and 1496 revocation information used for full validation of the electronic 1497 signature. 1499 The following optional eXtended forms of validation data are also 1500 defined: 1502 * X-timestamp: There are two types of timestamp used in extended 1503 validation data defined by this document. 1505 Internet Draft Electronic Signature Formats 1507 - Type 1 -Timestamp which comprises a timestamp over the ES 1508 with Complete validation data (ES-C). 1510 - Type 2 X-Timestamp which comprises of a timestamp over the 1511 certification path references and the revocation information 1512 references used to support the ES-C. 1514 * X-Long : This comprises a Complete validation data 1515 plus the actual values of all the certificates and 1516 revocation information used in the ES-C. 1518 * X-Long-Timestamp: This comprises a Type 1 or Type 2 1519 X-Timestamp plus the actual values of all the 1520 certificates and revocation information used in the 1521 ES-C. 1523 This clause also specifies the data structures used in Archive 1524 validation data: 1526 * Archive validation data comprises a Complete validation data, 1527 the certificate and revocation values (as in a X-Long 1528 validation data), any other existing X-timestamps, plus the 1529 Signed User data and an additional archive timestamp over all 1530 that data. An archive timestamp may be repeatedly applied 1531 after long periods to maintain validity when electronic 1532 signature and timestamping algorithms weaken. 1534 The additional data required to create the forms of electronic 1535 signature identified above is carried as unsigned attributes 1536 associated with an individual signature by being placed in the 1537 unsignedAttrs field of SignerInfo. Thus all the attributes defined 1538 in clause 4 are unsigned attributes. 1540 NOTE: Where multiple signatures are to be supported, as described in 1541 clause 3.13, each signature has a separate SignerInfo. Thus, each 1542 signature requires its own unsigned attribute values to create ES-T, 1543 ES-C etc. 1545 4.1 Electronic Signature Timestamp 1547 An Electronic Signature with Timestamp is an Electronic Signature for 1548 which part, but not all, of the additional data required for validation 1549 is available (e.g. some certificates and revocation information is 1550 available but not all). 1552 The minimum structure Timestamp validation data is the Signature 1553 Timestamp Attribute as defined in clause 4.1.1 over the ES signature 1554 value. 1556 4.1.1 Signature Timestamp Attribute Definition 1558 The Signature Timestamp attribute is timestamp of the signature value. 1559 It is an unsigned attribute. Several instances of this attribute from 1560 different TSAs may occur with an electronic signature. 1562 Internet Draft Electronic Signature Formats 1564 The Signature Validation Policy specifies, in the 1565 signatureTimestampDelay field of TimestampTrustConditions, a maximum 1566 acceptable time difference which is allowed between the time indicated 1567 in the signing time attribute and the time indicated by the Signature 1568 Timestamp attribute. If this delay is exceeded then the electronic 1569 signature must be considered as invalid. 1571 The following object identifier identifies the Signature Timestamp 1572 attribute: 1574 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 1575 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1576 id-aa(2) 14} 1578 The Signature timestamp attribute value has ASN.1 type 1579 SignatureTimeStampToken. 1581 SignatureTimeStampToken ::= TimeStampToken 1583 The value of messageImprint field within TimeStampToken must be a hash 1584 of the value of signature field within SignerInfo for the signedData 1585 being timestamped. 1587 For further information and definition of TimeStampToken see [TSP] 1589 4.2 Complete Validation Data 1591 An electronic signature with complete validation data is an Electronic 1592 Signature for which all the additional data required for validation 1593 (i.e. all certificates and revocation information) is available. 1594 Complete validation data (ES-C) build on the electronic signature 1595 Timestamp as defined above. 1597 The minimum structure of a Complete validation data is: 1599 * the Signature Timestamp Attribute, as defined in clause 4.1.1; 1600 * Complete Certificate Refs, as defined in clause 4.2.1; 1601 * Complete Revocation Refs, as defined in clause 4.2.2. 1603 The Complete validation data MAY also include the following additional 1604 information, forming a X-Long validation data, for use if later 1605 validation processes may not have access to this information: 1607 * Complete Certificate Values, as defined in clause 4.2.3; 1608 * Complete Revocation Values, as defined in clause 4.2.4. 1610 The Complete validation data MAY also include one of the following 1611 additional attributes, forming a X-Timestamp validation data, to 1612 provide additional protection against later CA compromise and provide 1613 integrity of the validation data used: 1615 * ES-C Timestamp, as defined in clause 4.2.5; or 1616 * Time-Stamped Certificates and CRLs references, as defined in 1617 clause 4.2.6. 1619 Internet Draft Electronic Signature Formats 1621 NOTE 1: As long as the CA's are trusted such that these keys cannot 1622 be compromised or the cryptography used broken, the ES-C provides long 1623 term proof of a valid electronic signature. 1625 A valid electronic signature is an electronic signature which passes 1626 validation according to a signature validation policy. 1628 NOTE 2: The ES-C provides the following important property for long 1629 standing signatures; that is having been found once to be valid, must 1630 continue to be so months or years later. Long after the validity period 1631 of the certificates have expired, or after the user key has been 1632 compromised. 1634 4.2.1 Complete Certificate Refs Attribute Definition 1636 The Complete Certificate Refs attribute is an unsigned attribute. It 1637 references the full set of CA certificates that have been used to 1638 validate a ES with Complete validation data (ES-C) up to (but not 1639 including) the signer's certificate. Only a single instance of this 1640 attribute must occur with an electronic signature. 1642 Note: The signer's certified is referenced in the signing certificate 1643 attribute (see clause 3.1). 1645 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1646 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 1648 The complete certificate refs attribute value has the ASN.1 syntax 1649 CompleteCertificateRefs. 1651 CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID 1653 OTHERCertID is defined in clause 3.8.2. 1655 The IssuerSerial that must be present in OTHERCertID. The certHash 1656 must match the hash of the certificate referenced. 1658 NOTE: Copies of the certificate values may be held using the 1659 Certificate Values attribute defined in clause 4.3.1. 1661 4.2.2 Complete Revocation Refs Attribute Definition 1663 The Complete Revocation Refs attribute is an unsigned attribute. Only a 1664 single instance of this attribute must occur with an electronic 1665 signature. It references the full set of the CRL or OCSP responses that 1666 have been used in the validation of the signer and CA certificates 1667 used in ES with Complete validation data. 1669 The following object identifier identifies the CompleteRevocationRefs 1670 attribute: 1672 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1673 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 1675 Internet Draft Electronic Signature Formats 1677 The complete revocation refs attribute value has the ASN.1 syntax 1678 CompleteRevocationRefs. 1680 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 1682 CrlOcspRef ::= SEQUENCE { 1683 crlids [0] CRLListID OPTIONAL, 1684 ocspids [1] OcspListID OPTIONAL, 1685 otherRev [2] OtherRevRefs OPTIONAL 1686 } 1688 CompleteRevocationRefs must contain one CrlOcspRef for the signing 1689 certificate, followed by one for each OTHERCertID in the 1690 CompleteCertificateRefs attribute. The second and subsequent CrlOcspRef 1691 fields must be in the same order as the OTHERCertID to which they 1692 relate. At least one of CRLListID or OcspListID or OtherRevRefs should 1693 be present for all but the "trusted" CA of the certificate path. 1695 CRLListID ::= SEQUENCE { 1696 crls SEQUENCE OF CrlValidatedID} 1698 CrlValidatedID ::= SEQUENCE { 1699 crlHash ETSIHash, 1700 crlIdentifier CrlIdentifier OPTIONAL} 1702 CrlIdentifier ::= SEQUENCE { 1703 crlissuer Name, 1704 crlIssuedTime UTCTime, 1705 crlNumber INTEGER OPTIONAL 1706 } 1708 OcspListID ::= SEQUENCE { 1709 ocspResponses SEQUENCE OF OcspResponsesID} 1711 OcspResponsesID ::= SEQUENCE { 1712 ocspIdentifier OcspIdentifier, 1713 ocspRepHash ETSIHash OPTIONAL 1714 } 1716 OcspIdentifier ::= SEQUENCE { 1717 ocspResponderID ResponderID, 1718 -- As in OCSP response data 1719 producedAt GeneralizedTime 1720 -- As in OCSP response data 1721 } 1723 When creating an crlValidatedID, the crlHash is computed over the 1724 entire DER encoded CRL including the signature. The crlIdentifier would 1725 normally be present unless the CRL can be inferred from other 1726 information. 1728 Internet Draft Electronic Signature Formats 1730 The crlIdentifier is to identify the CRL using the issuer name and the 1731 CRL issued time which must correspond to the time "thisUpdate" 1732 contained in the issued CRL. The crlListID attribute is an unsigned 1733 attribute. In the case that the identified CRL is a Delta CRL then 1734 references to the set of CRLs to provide a complete revocation list 1735 must be included. 1737 The OcspIdentifier is to identify the OSCP response using the issuer 1738 name and the time of issue of the OCSP response which must correspond 1739 to the time "producedAt" contained in the issued OCSP response. Since 1740 it may be needed to make the difference between two OCSP responses 1741 received within the same second, then the hash of the response 1742 contained in the OcspResponsesID may be needed to solve the ambiguity. 1744 NOTE: Copies of the CRL and OCSP responses values may be held using 1745 the Revocation Values attribute defined in clause 4.3.2. 1747 OtherRevRefs ::= SEQUENCE { 1748 otherRevRefType OtherRevRefType, 1749 otherRevRefs ANY DEFINED BY otherRevRefType 1750 } 1752 OtherRevRefType ::= OBJECT IDENTIFIER 1754 The syntax and semantics of other revocation references is outside the 1755 scope of this document. The definition of the syntax of the other form 1756 of revocation information is as identified by OtherRevRefType. 1758 4.3 Extended Validation Data 1760 4.3.1 Certificate Values Attribute Definition 1762 The Certificate Values attribute is an unsigned attribute. Only a 1763 single instance of this attribute must occur with an electronic 1764 signature. It holds the values of certificates referenced in the 1765 CompleteCertificateRefs attribute. 1767 Note: If an Attribute Certificate is used, it is not provided in this 1768 structure but must be provided by the signer as a signer-attributes 1769 attribute (see clause 12.3). 1771 The following object identifier identifies the CertificateValues 1772 attribute: 1774 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1775 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 1777 The certificate values attribute value has the ASN.1 syntax 1778 CertificateValues. 1780 CertificateValues ::= SEQUENCE OF Certificate 1782 Certificate is defined in RFC2459 and ITU-T Recommendation X.509 [1]) 1784 Internet Draft Electronic Signature Formats 1786 4.3.2 Revocation Values Attribute Definition 1788 The Revocation Values attribute is an unsigned attribute. Only a single 1789 instance of this attribute must occur with an electronic signature. It 1790 holds the values of CRLs and OCSP referenced in the 1791 CompleteRevocationRefs attribute. 1793 The following object identifier identifies the Revocation Values 1794 attribute: 1796 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- 1797 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1798 id-aa(2) 24} 1800 The revocation values attribute value has the ASN.1 syntax 1801 RevocationValues. 1803 RevocationValues ::= SEQUENCE { 1804 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 1805 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 1806 otherRevVals [2] OtherRevVals 1807 } 1809 OtherRevVals ::= SEQUENCE { 1810 otherRevValType OtherRevValType, 1811 otherRevVals ANY DEFINED BY otherRevValType 1812 } 1814 OtherRevValType ::= OBJECT IDENTIFIER 1816 The syntax and semantics of the other revocation values is outside the 1817 scope of this document. The definition of the syntax of the other form 1818 of revocation information is as identified by OtherRevRefType. 1820 CertificateList is defined in RFC 2459 [RFC2459] and in ITU-T 1821 Recommendation X.509 [X509]). 1823 BasicOCSPResponse is defined in RFC 2560 [OCSP]. 1825 4.3.3 ES-C Timestamp Attribute Definition 1827 This attribute is used for the Type 1 X-Timestamped validation data. 1828 The ES-C Timestamp attribute is an unsigned attribute. It is timestamp 1829 of a hash of the electronic signature and the complete validation data 1830 (ES-C). It is a special purpose TimeStampToken Attribute which 1831 timestamps the ES-C. Several instances instance of this attribute may 1832 occur with an electronic signature from different TSAs. 1834 The following object identifier identifies the ES-C Timestamp 1835 attribute: 1837 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member- 1838 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1839 id-aa(2) 25} 1841 Internet Draft Electronic Signature Formats 1843 The ES-C timestamp attribute value has the ASN.1 syntax 1844 ESCTimeStampToken. 1846 ESCTimeStampToken ::= TimeStampToken 1848 The value of messageImprint field within TimeStampToken must be a hash 1849 of the concatenated values (without the type or length encoding for 1850 that value) of the following data objects as present in the ES with 1851 Complete validation data (ES-C): 1853 * signature field within SignerInfo; 1855 * SignatureTimeStampToken attribute; 1857 * CompleteCertificateRefs attribute; 1859 * CompleteRevocationRefs attribute. 1861 For further information and definition of the Time Stamp Token see 1862 [TSP]. 1864 4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 1866 This attribute is used for the Type 2 X-Timestamp validation data. A 1867 TimestampedCertsCRLsRef attribute is an unsigned attribute. It is a 1868 list of referenced certificates and OCSP responses/CRLs which are been 1869 timestamped to protect against certain CA compromises. Its syntax is as 1870 follows: 1872 The following object identifier identifies the TimestampedCertsCRLsRef 1873 attribute: 1875 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 1876 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1877 id-aa(2) 26} 1879 The attribute value has the ASN.1 syntax TimestampedCertsCRLs. 1881 TimestampedCertsCRLs ::= TimeStampToken 1883 The value of messageImprint field within TimeStampToken must be a hash 1884 of the concatenated values (without the type or length encoding for 1885 that value) of the following data objects as present in the ES with 1886 Complete validation data (ES-C): 1888 * CompleteCertificateRefs attribute; 1889 * CompleteRevocationRefs attribute. 1891 4.4 Archive Validation Data 1893 Where an electronic signature is required to last for a very long time, 1894 and a the timestamp on an electronic signature is in danger of being 1895 invalidated due to algorithm weakness or limits in the validity period 1896 of the TSA certificate, then it may be required to timestamp the 1898 Internet Draft Electronic Signature Formats 1900 electronic signature several times. When this is required an archive 1901 timestamp attribute may be required. This timestamp may be repeatedly 1902 applied over a period of time. 1904 4.4.1 Archive Timestamp Attribute Definition 1906 The Archive Timestamp attribute is timestamp of the user data and the 1907 entire electronic signature. If the Certificate values and Revocation 1908 Values attributes are not present these attributes must be added to 1909 the electronic signature prior to the timestamp. The Archive Timestamp 1910 attribute is an unsigned attribute. Several instances of this attribute 1911 may occur with on electronic signature both over time and from 1912 different TSAs. 1914 The following object identifier identifies the Nested Archive Timestamp 1915 attribute: 1917 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 1918 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1919 id-aa(2) 27} 1921 Archive timestamp attribute values have the ASN.1 syntax 1922 ArchiveTimeStampToken 1924 ArchiveTimeStampToken ::= TimeStampToken 1926 The value of messageImprint field within TimeStampToken must be a hash 1927 of the concatenated values (without the type or length encoding for 1928 that value) of the following data objects as present in the electronic 1929 signature: 1931 * encapContentInfo eContent OCTET STRING; 1932 * signedAttributes; 1933 * signature field within SignerInfo; 1934 * SignatureTimeStampToken attribute; 1935 * CompleteCertificateRefs attribute; 1936 * CompleteRevocationData attribute; 1937 * CertificateValues attribute 1938 (If not already present this information must be included in 1939 the ES-A); 1940 * RevocationValues attribute 1941 (If not already present this information must be included in 1942 the ES-A); 1943 * ESCTimeStampToken attribute if present; 1944 * TimestampedCertsCRLs attribute if present; 1945 * any previous ArchiveTimeStampToken attributes. 1947 For further information and definition of TimeStampToken see [TSP] 1949 The timestamp should be created using stronger algorithms (or longer 1950 key lengths) than in the original electronic signatures. 1952 Internet Draft Electronic Signature Formats 1954 5. Security considerations 1956 5.1 Protection of Private Key 1958 The security of the electronic signature mechanism defined in this 1959 document depends on the privacy of the signer's private key. 1960 Implementations must take steps to ensure that private keys cannot be 1961 compromised. 1963 5.2 Choice of Algorithms 1965 Implementers should be aware that cryptographic algorithms become 1966 weaker with time. As new cryptoanalysis techniques are developed and 1967 computing performance improves, the work factor to break a particular 1968 cryptographic algorithm will reduce. Therefore, cryptographic algorithm 1969 implementations should be modular allowing new algorithms to be readily 1970 inserted. That is, implementers should be prepared for the set of 1971 mandatory to implement algorithms to change over time. 1973 6. Conformance Requirements 1975 This document only defines conformance requirements up to a ES with 1976 Complete validation data (ES-C). This means that none of the extended 1977 and archive forms of Electronic Signature (ES-X, ES-A) need to be 1978 implemented to get conformance to this standard. 1980 This document mandates support for elements of the signature policy. 1982 6.1 Signer 1984 A system supporting signers according to this document must, at a 1985 minimum, support generation of an electronic signature consisting of 1986 the following components: 1988 * The general CMS syntax and content type as defined in RFC 2630 1989 (see clauses 4.1 and 4.2). 1991 * CMS SignedData as defined in RFC 2630 with version set to 3 1992 and at least one SignerInfo must be present 1993 (see clauses 4.3, 4.4, 4.5, 4.6). 1995 * The following CMS Attributes as defined in RFC 2630 : 1997 - ContentType; This must always be present 1998 (see clause 3.7.1); 2000 - MessageDigest; This must always be present 2001 (see clause 3.7.2); 2003 - SigningTime; This must always be present 2004 (see clause 3.7.3). 2006 Internet Draft Electronic Signature Formats 2008 * The following ESS Attributes as defined in RFC 2634 : 2010 - SigningCertificate: This must be set as defined 2011 in clauses 3.8.1 and 3.8.2. 2013 * The following Attributes as defined in clause 3.9: 2014 - SignaturePolicyIdentifier; This must always be present. 2016 * Public Key Certificates as defined in ITU-T Recommendation 2017 X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1). 2019 6.2 Verifier 2021 A system supporting verifiers according to this document must, at a 2022 minimum, support: 2024 * Verification of the mandated components of an electronic 2025 signature, as defined in clause 14.1. 2027 * Signature Timestamp attribute, as defined in clause 4.1.1. 2029 * Complete Certificate Refs attribute, as defined in 2030 clause 4.2.1. 2032 * Complete Revocation Refs Attribute, as defined in 2033 clause 4.2.2. 2035 * Public Key Certificates, as defined in ITU-T 2036 Recommendation X.509 and profiled in RFC 2459. 2038 * Either of: 2040 - Certificate Revocation Lists. as defined in ITU-T 2041 Recommendation X.509 [1] and profiled in RFC 2459 [7]; 2042 or 2044 - On-line Certificate Status Protocol responses, as 2045 defined in RFC 2560. 2047 Internet Draft Electronic Signature Formats 2049 7. References 2051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2052 Requirement Levels", BCP 14, RFC 2119, March 1997. 2054 [ESS] P. Hoffman, "Enhanced Security Services for S/MIME", 2055 RFC 2634, June 1999 2057 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, 2058 June 1999. 2060 [OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. 2061 On-line Status Certificate Protocol, RFC 2560. 2063 [TSP] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Time Stamp Protocol 2064 (TSP), (under progress). June 2000. 2066 [PTS] Public Telegram Service. ITU-T Recommendation F1. XXXX 2068 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 2069 Key Infrastructure, Certificate and CRL Profile," RFC 2459, January 2070 1999. 2072 [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards 2073 (PKCS)", RSA Data Security Inc., Redwood City, California, November 2074 1993 Release. 2076 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 2077 Non-Repudiation Framework. April 1997. 2079 [ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic 2080 Signature Formats. Note: copies of ETSI ES 210 733 can be freely 2081 downloaded from the ETSI web site www.etsi.org. 2083 8. Authors' Addresses 2085 This Informational RFC has been produced in ETSI TC-SEC. 2087 ETSI 2088 F-06921 Sophia Antipolis, Cedex - FRANCE 2089 650 Route des Lucioles - Sophia Antipolis 2090 Valbonne - France 2091 Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 2092 secretariat@etsi.fr 2093 http://www.etsi.org 2095 Internet Draft Electronic Signature Formats 2097 Contact Point 2099 Harri Rasilainen 2100 ETSI 2101 650 Route des Lucioles 2102 F-06921 Sophia Antipolis, Cedex 2103 FRANCE 2104 harri.rasilainen@etsi.fr 2106 Denis Pinkas 2107 Bull S.A. 2108 12, rue de Paris 2109 B.P. 59 2110 78231 Le Pecq 2111 FRANCE 2112 Denis.Pinkas @bull.net 2114 John Ross 2115 Security & Standards 2116 192 Moulsham Street 2117 Chelmsford, Essex 2118 CM2 0LG 2119 United Kingdom 2120 ross@secstan.com 2122 Nick Pope 2123 Security & Standards 2124 192 Moulsham Street 2125 Chelmsford, Essex 2126 CM2 0LG 2127 United Kingdom 2128 pope@secstan.com 2130 9. Full Copyright Statement 2132 Copyright (C) The Internet Society (2000). All Rights Reserved. 2133 This document and translations of it may be copied and furnished to 2134 others, and derivative works that comment on or otherwise explain it 2135 or assist in its implementation may be prepared, copied, published and 2136 distributed, in whole or in part, without restriction of any kind, 2137 provided that the above copyright notice and this paragraph are 2138 included on all such copies and derivative works. However, this 2139 document itself may not be modified in any way, such as by removing 2140 the copyright notice or references to the Internet Society or other 2141 Internet organizations, except as needed for the purpose of developing 2142 Internet standards in which case the procedures for copyrights defined 2143 in the Internet Standards process must be followed, or as required to 2144 translate it into languages other than English. 2146 Internet Draft Electronic Signature Formats 2148 The limited permissions granted above are perpetual and will not be 2149 revoked by the Internet Society or its successors or assigns. 2151 This document and the information contained herein is provided on an 2152 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2153 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2154 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 2155 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2156 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2158 Internet Draft Electronic Signature Formats 2160 Annex A (normative): ASN.1 Definitions 2162 This annex provides a summary of all the ASN.1 syntax definitions for 2163 new syntax defined in this document. 2165 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 2167 NOTE: The ASN.1 module defined in clause A.1 has precedence over that 2168 defined in Annex A-2 in the case of any conflict. 2170 ETS-ElectronicSignatureFormats-88syntax { iso(1) member-body(2) 2171 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5} 2173 DEFINITIONS EXPLICIT TAGS ::= 2175 BEGIN 2177 -- EXPORTS All - 2179 IMPORTS 2181 -- Crypographic Message Syntax (CMS): RFC 2630 2183 ContentInfo, ContentType, id-data, id-signedData, SignedData, 2184 EncapsulatedContentInfo, SignerInfo, id-contentType, 2185 id-messageDigest, MessageDigest, id-signingTime, SigningTime, 2186 id-countersignature, Countersignature 2188 FROM CryptographicMessageSyntax 2189 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2190 smime(16) modules(0) cms(1) } 2192 -- ESS Defined attributes: RFC 2634 2193 -- (Enhanced Security Services for S/MIME) 2195 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 2196 id-aa-contentReference, ContentReference, 2197 id-aa-contentIdentifier, ContentIdentifier 2199 FROM ExtendedSecurityServices 2200 { iso(1) member-body(2) us(840) rsadsi(113549) 2201 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 2203 -- Internet X.509 Public Key Infrastructure 2204 -- Certificate and CRL Profile: RFC 2459 2206 Certificate, AlgorithmIdentifier, CertificateList, Name, 2207 GeneralNames, GeneralName, DirectoryString,Attribute, 2208 AttributeTypeAndValue, AttributeType, AttributeValue, 2209 PolicyInformation, BMPString, UTF8String 2211 Internet Draft Electronic Signature Formats 2213 FROM PKIX1Explicit88 2214 {iso(1) identified-organization(3) dod(6) internet(1) 2215 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit- 2216 88(1)} 2218 -- X.509 '97 Authentication Framework 2220 AttributeCertificate 2222 FROM AuthenticationFramework 2223 {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3} 2225 -- The imported AttributeCertificate is defined using the X.680 1997 2226 -- ASN.1 Syntax, 2227 -- an equivalent using the 88 ASN.1 syntax may be used. 2229 -- OCSP 2560 2231 BasicOCSPResponse, ResponderID 2233 FROM OCSP {-- OID not assigned -- } 2235 -- Time Stamp Protocol Internet Draft 2237 TimeStampToken 2239 FROM PKIXTSP 2240 {iso(1) identified-organization(3) dod(6) internet(1) 2241 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 2243 -- S/MIME Object Identifier arcs used in this document 2244 -- =================================================== 2246 -- S/MIME OID arc used in this document 2247 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2248 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 2250 -- S/MIME Arcs 2251 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 2252 -- modules 2253 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 2254 -- content types 2255 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 2256 -- attributes 2257 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 2258 -- signature policy qualifier 2259 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 2260 -- commitment type identifier 2262 Internet Draft Electronic Signature Formats 2264 -- Definitions of Object Identifier arcs used in this document 2265 -- =========================================================== 2267 -- The allocation of OIDs to specific objects are given below with the 2268 -- associated ASN.1 syntax definition 2270 -- OID used referencing electronic signature mechanisms based on this 2271 -- standard for use with the IDUP API (see annex D) 2273 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 2274 { itu-t(0) identified-organization(4) etsi(0) 2275 electronic-signature-standard (1733) part1 (1) 2276 idupMechanism (4)etsiESv1(1) } 2278 -- CMS Attributes Defined in this document 2279 -- ======================================= 2281 -- Mandatory Electronic Signature Attributes 2283 -- OtherSigningCertificate 2285 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 2286 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2287 smime(16) id-aa(2) 19 } 2289 OtherSigningCertificate ::= SEQUENCE { 2290 certs SEQUENCE OF OtherCertID, 2291 policies SEQUENCE OF PolicyInformation OPTIONAL 2292 -- NOT USED IN THIS DOCUMENT 2293 } 2295 OtherCertID ::= SEQUENCE { 2296 otherCertHash OtherHash, 2297 issuerSerial IssuerSerial OPTIONAL 2298 } 2300 OtherHash ::= CHOICE { 2301 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 2302 otherHash OtherHashAlgAndValue 2303 } 2305 OtherHashValue ::= OCTET STRING 2307 OtherHashAlgAndValue ::= SEQUENCE { 2308 hashAlgorithm AlgorithmIdentifier, 2309 hashValue OtherHashValue 2310 } 2312 -- Signature Policy Identifier 2314 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 2315 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2316 smime(16) id-aa(2) 15 } 2318 Internet Draft Electronic Signature Formats 2320 SignaturePolicyIdentifier ::= SEQUENCE { 2321 sigPolicyIdentifier SigPolicyId, 2322 sigPolicyHash SigPolicyHash, 2323 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 2324 SigPolicyQualifierInfo OPTIONAL 2325 } 2327 SigPolicyId ::= OBJECT IDENTIFIER 2329 SigPolicyHash ::= ETSIHashAlgAndValue 2331 SigPolicyQualifierInfo ::= SEQUENCE { 2332 sigPolicyQualifierId SigPolicyQualifierId, 2333 sigQualifier ANY DEFINED BY sigPolicyQualifierId 2334 } 2336 SigPolicyQualifierId ::= 2337 OBJECT IDENTIFIER 2339 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 2340 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2341 smime(16) id-spq(5) 1 } 2343 SPuri ::= IA5String 2345 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 2346 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2347 smime(16) id-spq(5) 2 } 2349 SPUserNotice ::= SEQUENCE { 2350 noticeRef NoticeReference OPTIONAL, 2351 explicitText DisplayText OPTIONAL 2352 } 2354 NoticeReference ::= SEQUENCE { 2355 organization DisplayText, 2356 noticeNumbers SEQUENCE OF INTEGER 2357 } 2359 DisplayText ::= CHOICE { 2360 visibleString VisibleString (SIZE (1..200)), 2361 bmpString BMPString (SIZE (1..200)), 2362 utf8String UTF8String (SIZE (1..200)) 2363 } 2365 Internet Draft Electronic Signature Formats 2367 -- Optional Electronic Signature Attributes 2369 -- Commitment Type 2371 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2372 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 2374 CommitmentTypeIndication ::= SEQUENCE { 2375 commitmentTypeId CommitmentTypeIdentifier, 2376 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 2377 CommitmentTypeQualifier OPTIONAL 2378 } 2380 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 2382 CommitmentTypeQualifier ::= SEQUENCE { 2383 commitmentTypeIdentifier CommitmentTypeIdentifier, 2384 qualifier ANY DEFINED BY commitmentTypeIdentifier 2385 } 2387 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member- 2388 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2389 cti(6) 1} 2391 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member- 2392 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2393 cti(6) 2} 2395 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 2396 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2397 cti(6) 3} 2399 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- 2400 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2401 cti(6) 4} 2403 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 2404 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2405 cti(6) 5} 2407 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 2408 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2409 cti(6) 6} 2411 Internet Draft Electronic Signature Formats 2413 -- Signer Location 2415 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member- 2416 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2417 id-aa(2) 17} 2419 SignerLocation ::= SEQUENCE { 2420 -- at least one of the following must be present 2421 countryName [0] DirectoryString OPTIONAL, 2422 -- as used to name a Country in X.500 2423 localityName [1] DirectoryString OPTIONAL, 2424 -- as used to name a locality in X.500 2425 postalAdddress [2] PostalAddress OPTIONAL 2426 } 2428 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 2430 -- Signer Attributes 2432 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2433 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 2435 SignerAttribute ::= SEQUENCE OF CHOICE { 2436 claimedAttributes [0] ClaimedAttributes, 2437 certifiedAttributes [1] CertifiedAttributes 2438 } 2440 ClaimedAttributes ::= SEQUENCE OF Attribute 2442 CertifiedAttributes ::= AttributeCertificate -- as defined in X.509 : 2443 see section 10.3 2445 -- Content Timestamp 2447 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2448 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2449 id-aa(2) 20} 2451 ContentTimestamp::= TimeStampToken 2453 -- Validation Data 2455 -- Signature Timestamp 2457 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 2458 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2459 id-aa(2) 14} 2461 SignatureTimeStampToken ::= TimeStampToken 2463 Internet Draft Electronic Signature Formats 2465 -- Complete Certificate Refs. 2467 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2468 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 2470 CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID 2472 -- Complete Revocation Refs 2474 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member- 2475 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2476 id-aa(2) 22} 2478 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 2480 CrlOcspRef ::= SEQUENCE { 2481 crlids [0] CRLListID OPTIONAL, 2482 ocspids [1] OcspListID OPTIONAL, 2483 otherRev [2] OtherRevRefs OPTIONAL 2484 } 2486 CRLListID ::= SEQUENCE { 2487 crls SEQUENCE OF CrlValidatedID} 2489 CrlValidatedID ::= SEQUENCE { 2490 crlHash ETSIHash, 2491 crlIdentifier CrlIdentifier OPTIONAL 2492 } 2494 CrlIdentifier ::= SEQUENCE { 2495 crlissuer Name, 2496 crlIssuedTime UTCTime, 2497 crlNumber INTEGER OPTIONAL 2498 } 2500 OcspListID ::= SEQUENCE { 2501 ocspResponses SEQUENCE OF OcspResponsesID} 2503 OcspResponsesID ::= SEQUENCE { 2504 ocspIdentifier OcspIdentifier, 2505 ocspRepHash ETSIHash OPTIONAL 2506 } 2508 OcspIdentifier ::= SEQUENCE { 2509 ocspResponderID ResponderID, 2510 -- as in OCSP response data 2511 producedAt GeneralizedTime 2512 -- as in OCSP response data 2513 } 2515 Internet Draft Electronic Signature Formats 2517 OtherRevRefs ::= SEQUENCE { 2518 otherRevRefType OtherRevRefType, 2519 otherRevRefs ANY DEFINED BY otherRevRefType 2520 } 2522 OtherRevRefType ::= OBJECT IDENTIFIER 2524 -- Certificate Values 2526 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2527 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 2529 CertificateValues ::= SEQUENCE OF Certificate 2531 -- Certificate Revocation Values 2533 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- 2534 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2535 id-aa(2) 24} 2537 RevocationValues ::= SEQUENCE { 2538 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 2539 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 2540 otherRevVals [2] OtherRevVals 2541 } 2543 OtherRevVals ::= SEQUENCE { 2544 otherRevValType OtherRevValType, 2545 otherRevVals ANY DEFINED BY otherRevValType 2546 } 2548 OtherRevValType ::= OBJECT IDENTIFIER 2550 -- ES-C Timestamp 2552 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2553 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 2555 ESCTimeStampToken ::= TimeStampToken 2557 -- Time-Stamped Certificates and CRLs 2559 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2560 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2561 id-aa(2) 26} 2563 TimestampedCertsCRLs ::= TimeStampToken 2565 Internet Draft Electronic Signature Formats 2567 -- Archive Timestamp 2569 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2570 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2571 id-aa(2) 27} 2573 ArchiveTimeStampToken ::= TimeStampToken 2575 END -- ETS-ElectronicSignatureFormats-88syntax -- 2577 Internet Draft Electronic Signature Formats 2579 A.2 Definitions Using X.680 1997 ASN.1 Syntax 2581 NOTE: The ASN.1 module defined in clause A.1 has precedence over that 2582 defined in clause A.2 in the case of any conflict. 2584 ETS-ElectronicSignatureFormats-97Syntax { iso(1) member-body(2) 2585 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6} 2587 DEFINITIONS EXPLICIT TAGS ::= 2589 BEGIN 2591 -- EXPORTS All - 2593 IMPORTS 2595 -- Cryptographic Message Syntax (CMS): RFC 2630 2597 ContentInfo, ContentType, id-data, id-signedData, SignedData, 2598 EncapsulatedContentInfo, SignerInfo, id-contentType, 2599 id-messageDigest, MessageDigest, id-signingTime, 2600 SigningTime, id-countersignature, Countersignature 2602 FROM CryptographicMessageSyntax 2603 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2604 smime(16) modules(0) cms(1) } 2606 -- ESS Defined attributes: RFC 2634 (Enhanced Security Services 2607 -- for S/MIME) 2609 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 2610 id-aa-contentReference, ContentReference, 2611 id-aa-contentIdentifier, ContentIdentifier 2613 FROM ExtendedSecurityServices 2614 { iso(1) member-body(2) us(840) rsadsi(113549) 2615 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 2617 -- Internet X.509 Public Key Infrastructure 2618 - - Certificate and CRL Profile:RFC 2459 2620 Certificate, AlgorithmIdentifier, CertificateList, Name, 2621 GeneralNames, GeneralName, DirectoryString, Attribute, 2622 AttributeTypeAndValue, AttributeType, AttributeValue, 2623 PolicyInformation. 2625 FROM PKIX1Explicit93 2626 {iso(1) identified-organization(3) dod(6) internet(1) 2627 security(5) mechanisms(5) pkix(7) id-mod(0) 2628 id-pkix1-explicit-88(1)} 2630 Internet Draft Electronic Signature Formats 2632 -- X.509 '97 Authentication Framework 2634 AttributeCertificate 2636 FROM AuthenticationFramework 2637 {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3} 2639 -- OCSP 2560 2641 BasicOCSPResponse, ResponderID 2643 FROM OCSP 2645 -- { OID not assigned } 2647 -- Time Stamp Protocol Internet Draft TimeStampToken 2649 FROM PKIXTSP 2650 {iso(1) identified-organization(3) dod(6) internet(1) 2651 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)} 2653 -- S/MIME Object Identifier arcs used in this document 2654 -- =================================================== 2656 -- S/MIME OID arc used in this document 2657 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2658 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 2660 -- S/MIME Arcs 2661 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 2662 -- modules 2663 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 2664 -- content types 2665 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 2666 -- attributes 2667 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 2668 -- signature policy qualifier 2669 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 2670 -- commitment type identifier 2672 -- Definitions of Object Identifier arcs used in this document 2673 -- =========================================================== 2675 -- The allocation of OIDs to specific objects are given below with the 2676 -- associated ASN.1 syntax definition 2678 -- OID used referencing electronic signature mechanisms based on this 2679 -- standard for use with the IDUP API (see annex D) 2681 Internet Draft Electronic Signature Formats 2683 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 2684 { itu-t(0) identified-organization(4) etsi(0) 2685 electronic-signature-standard (1733) part1 (1) 2686 idupMechanism (4)etsiESv1(1) } 2688 -- CMS Attributes Defined in this document 2689 -- ======================================= 2691 -- Mandatory Electronic Signature Attributes 2692 -- OtherSigningCertificate 2694 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 2695 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2696 smime(16) id-aa(2) 19 } 2698 OtherSigningCertificate ::= SEQUENCE { 2699 certs SEQUENCE OF OtherCertID, 2700 policies SEQUENCE OF PolicyInformation OPTIONAL 2701 -- NOT USED IN THIS DOCUMENT 2702 } 2704 OtherCertID ::= SEQUENCE { 2705 otherCertHash OtherHash, 2706 issuerSerial IssuerSerial OPTIONAL 2707 } 2709 OtherHash ::= CHOICE { 2710 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 2711 otherHash OtherHashAlgAndValue 2712 } 2714 OtherHashValue ::= OCTET STRING 2716 OtherHashAlgAndValue ::= SEQUENCE { 2717 hashAlgorithm AlgorithmIdentifier, 2718 hashValue OtherHashValue 2719 } 2721 -- Signature Policy Identifier 2723 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 2724 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2725 smime(16) id-aa(2) 15 } 2727 SignaturePolicyIdentifier ::= SEQUENCE { 2728 sigPolicyIdentifier SigPolicyId, 2729 sigPolicyHash SigPolicyHash, 2730 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 2731 SigPolicyQualifierInfo OPTIONAL 2732 } 2734 SigPolicyId ::= OBJECT IDENTIFIER 2736 Internet Draft Electronic Signature Formats 2738 SigPolicyHash ::= ETSIHashAlgAndValue 2740 SigPolicyQualifierInfo ::= SEQUENCE { 2741 sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id 2742 ({SupportedSigPolicyQualifiers}), 2743 qualifier SIG-POLICY-QUALIFIER.&Qualifier 2744 ({SupportedSigPolicyQualifiers} 2745 {@sigPolicyQualifierId})OPTIONAL } 2747 SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 2748 { noticeToUser | pointerToSigPolSpec } 2750 SIG-POLICY-QUALIFIER ::= CLASS { 2751 &id OBJECT IDENTIFIER UNIQUE, 2752 &Qualifier OPTIONAL } 2754 WITH SYNTAX { 2755 SIG-POLICY-QUALIFIER-ID &id 2756 [SIG-QUALIFIER-TYPE &Qualifier] } 2758 noticeToUser SIG-POLICY-QUALIFIER ::= { 2759 SIG-POLICY-QUALIFIER-ID id-sqt-unotice SIG-QUALIFIER-TYPE 2760 SPUserNotice 2761 } 2763 pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { 2764 SIG-POLICY-QUALIFIER-ID id-sqt-uri SIG-QUALIFIER-TYPE SPuri } 2766 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 2767 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2768 smime(16) id-spq(5) 1 } 2770 SPuri ::= IA5String 2772 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 2773 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2774 smime(16) id-spq(5) 2 } 2776 SPUserNotice ::= SEQUENCE { 2777 noticeRef NoticeReference OPTIONAL, 2778 explicitText DisplayText OPTIONAL 2779 } 2781 NoticeReference ::= SEQUENCE { 2782 organization DisplayText, 2783 noticeNumbers SEQUENCE OF INTEGER 2784 } 2786 DisplayText ::= CHOICE { 2787 visibleString VisibleString (SIZE (1..200)), 2788 bmpString BMPString (SIZE (1..200)), 2789 utf8String UTF8String (SIZE (1..200)) 2790 } 2792 Internet Draft Electronic Signature Formats 2794 -- Optional Electronic Signature Attributes 2796 -- Commitment Type 2798 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2799 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 2801 CommitmentTypeIndication ::= SEQUENCE { 2802 commitmentTypeId CommitmentTypeIdentifier, 2803 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 2804 CommitmentTypeQualifier 2805 OPTIONAL} 2807 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 2809 CommitmentTypeQualifier ::= SEQUENCE { 2810 commitmentQualifierId COMMITMENT-QUALIFIER.&id, 2811 qualifier COMMITMENT-QUALIFIER.&Qualifier 2812 OPTIONAL } 2814 COMMITMENT-QUALIFIER ::= CLASS { 2815 &id OBJECT IDENTIFIER UNIQUE, 2816 &Qualifier OPTIONAL } 2817 WITH SYNTAX { 2818 COMMITMENT-QUALIFIER-ID &id 2819 [COMMITMENT-TYPE &Qualifier] } 2821 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) 2822 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2823 smime(16) cti(6) 1} 2825 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) 2826 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2827 smime(16) cti(6) 2} 2829 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 2830 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2831 smime(16) cti(6) 3} 2833 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) 2834 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2835 smime(16) cti(6) 4} 2837 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) 2838 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2839 smime(16) cti(6) 5} 2841 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) 2842 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2843 smime(16) cti(6) 6} 2845 Internet Draft Electronic Signature Formats 2847 -- Signer Location 2849 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2850 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 2852 SignerLocation ::= SEQUENCE { 2853 -- at least one of the following must be present 2854 countryName [0] DirectoryString OPTIONAL, 2855 -- As used to name a Country in X.500 2856 localityName [1] DirectoryString OPTIONAL, 2857 -- As used to name a locality in X.500 2858 postalAdddress [2] PostalAddress OPTIONAL } 2860 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 2862 -- Signer Attributes 2864 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2865 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 2867 SignerAttribute ::= SEQUENCE OF CHOICE { 2868 claimedAttributes [0] ClaimedAttributes, 2869 certifiedAttributes [1] CertifiedAttributes } 2871 ClaimedAttributes ::= SEQUENCE OF Attribute 2873 CertifiedAttributes ::= AttributeCertificate 2874 -- As defined in X.509 : see section 10.3 2876 -- Content Timestamp 2878 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) 2879 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2880 smime(16) id-aa(2) 20} 2882 ContentTimestamp::= TimeStampToken 2884 -- Validation Data 2886 -- Signature Timestamp 2888 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 2889 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2890 smime(16) id-aa(2) 14} 2892 SignatureTimeStampToken ::= TimeStampToken 2894 Internet Draft Electronic Signature Formats 2896 -- Complete Certificate Refs. 2898 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2899 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 2901 CompleteCertificateRefs ::= SEQUENCE OF OTHERCertID 2903 -- Complete Revocation Refs 2905 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2906 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 2908 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 2910 CrlOcspRef ::= SEQUENCE { 2911 crlids [0] CRLListID OPTIONAL, 2912 ocspids [1] OcspListID OPTIONAL, 2913 otherRev [2] OtherRevRefs OPTIONAL 2914 } 2916 CRLListID ::= SEQUENCE { 2917 crls SEQUENCE OF CrlValidatedID} 2919 CrlValidatedID ::= SEQUENCE { 2920 crlHash ETSIHash, 2921 crlIdentifier CrlIdentifier OPTIONAL} 2923 CrlIdentifier ::= SEQUENCE { 2924 crlissuer Name, 2925 crlIssuedTime UTCTime, 2926 crlNumber INTEGER OPTIONAL 2927 } 2929 OcspListID ::= SEQUENCE { 2930 ocspResponses SEQUENCE OF OcspResponsesID} 2932 OcspResponsesID ::= SEQUENCE { 2933 ocspIdentifier OcspIdentifier, 2934 ocspRepHash ETSIHash OPTIONAL 2935 } 2937 OcspIdentifier ::= SEQUENCE { 2938 ocspResponderID ResponderID, 2939 -- As in OCSP response data 2940 producedAt GeneralizedTime 2941 -- As in OCSP response data 2942 } 2944 Internet Draft Electronic Signature Formats 2946 OtherRevRefs ::= SEQUENCE { 2947 otherRevRefType OTHER-REVOCATION-REF.&id, 2948 otherRevRefs OTHER-REVOCATION-REF.&Type 2949 } 2951 OTHER-REVOCATION-REF ::= CLASS { 2952 &Type, 2953 &id OBJECT IDENTIFIER UNIQUE } 2954 WITH SYNTAX { 2955 &Type ID &id } 2957 -- Certificate Values 2959 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2960 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 2962 CertificateValues ::= SEQUENCE OF Certificate 2964 -- Certificate Revocation Values 2966 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 2967 member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2968 smime(16) id-aa(2) 24} 2970 RevocationValues ::= SEQUENCE { 2971 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 2972 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 2973 otherRevVals [2] OtherRevVals } 2975 OtherRevVals ::= SEQUENCE { 2976 otherRevValType OTHER-REVOCATION-VAL.&id, 2977 otherRevVals OTHER-REVOCATION-VAL.&Type 2978 } 2980 OTHER-REVOCATION-VAL ::= CLASS { 2981 &Type, 2982 &id OBJECT IDENTIFIER UNIQUE } 2983 WITH SYNTAX { 2984 &Type ID &id } 2986 -- ES-C Timestamp 2988 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) 2989 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2990 smime(16) id-aa(2) 25} 2992 ESCTimeStampToken ::= TimeStampToken 2994 Internet Draft Electronic Signature Formats 2996 -- Time-Stamped Certificates and CRLs 2998 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) 2999 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3000 smime(16) id-aa(2) 26} 3002 TimestampedCertsCRLs ::= TimeStampToken 3004 -- Archive Timestamp 3006 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) 3007 member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3008 smime(16) id-aa(2) 27} 3010 ArchiveTimeStampToken ::= TimeStampToken 3012 END -- ETS-ElectronicSignatureFormats-97Syntax 3014 Internet Draft Electronic Signature Formats 3016 Annex B (informative): General Description 3018 This annex captures the concepts that apply to this document and the 3019 rational for the elements of the specification defined using ASN.1 in 3020 the main text of this document. 3022 The specification below includes a description why the component is 3023 needed, with a brief description of the vulnerabilities and threats 3024 and the manner by which they are countered. 3026 B.1 The Signature Policy 3028 The signature policy is a set of rules for the creation and validation 3029 of an electronic signature, under which the signature can be 3030 determined to be valid. A given legal/contractual context may 3031 recognize a particular signature policy as meeting its requirements. 3032 A signature policy may be issued, for example, by a party relying on 3033 the electronic signatures and selected by the signer for use with that 3034 relying party. Alternatively, a signature policy may be established 3035 through an electronic trading association for use amongst its members. 3036 Both the signer and verifier use the same signature policy. 3038 A signature policy has a globally unique reference, which is bound to 3039 an electronic signature by the signer as part of the signature 3040 calculation. 3042 The signature policy needs to be available in human readable form so 3043 that it can be assessed to meet the requirements of the legal and 3044 contractual context in which it is being applied. To facilitate the 3045 automatic processing of an electronic signature the parts of the 3046 signature policy which specify the electronic rules for the creation 3047 and validation of the electronic signature also needs to be in a 3048 computer processable form. 3050 The signature policy thus includes the following: 3052 * Information about the signature policy that can be displayed 3053 to the signer or the verifiers. 3054 * Rules, which apply to functionality, covered by this document 3055 (referred to as the Signature Validation Policy). 3056 * Rules which may be implied through adoption of Certificate 3057 Policies that apply to the electronic signature (e.g. rules for 3058 ensuring the secrecy of the private signing key). 3059 * Rules, which relate to the environment used by the signer, 3060 e.g. the use of an agreed CAD (Card Accepting Device) used 3061 in conjunction with a smart card. 3063 The Signature Validation Policy may be structured so that it can be 3064 computer processable. Any format of the signature validation policy 3065 is allowed by this document. However, for a given signature policy 3066 there must be one definitive form that has a unique binary encoded 3067 value. 3069 Internet Draft Electronic Signature Formats 3071 The Signature Validation Policy includes rules regarding use of TSPs 3072 (CA, Attribute Authorities, Time Stamping Authorities) as well as 3073 rules defining the components of the electronic signature that must be 3074 provided by the signer with data required by the verifier to provide 3075 long term proof. 3077 B.2 Signed Information 3079 The information being signed may be defined as a MIME-encapsulated 3080 message which can be used to signal the format of the content in order 3081 to select the right display or application. It can be composed of 3082 formatted text (e.g. EDIFACT), free text or of fields from an 3083 electronic form (e-form). For example, the Adobe(tm) format "pdf" may 3084 be used or the eXtensible Mark up Language (XML). 3086 B.3 Components of an Electronic Signature 3088 B.3.1 Reference to the Signature Policy 3090 The definition of electronic signature includes: "a commitment has 3091 been explicitly endorsed under a "Signature policy", at a given time, 3092 by a signer under an identifier, e.g. a name or a pseudonym, and 3093 optionally a role". 3095 When two independent parties want to evaluate an electronic signature, 3096 it is fundamental that they get the same result. To meet this 3097 requirement the technical components and technical aspects used in 3098 creating the signature must be referenced, this is provided by a 3099 reference to the "Signature Validation Policy". The "Signature 3100 Validation Policy" defines: 3102 * the components of an electronic signature to be provided by the 3103 signer; 3105 * any additional components (i.e. verifier components) used to 3106 validate an electronic signature at the time of receipt by a 3107 verifier and later by an arbitrator, auditor or other 3108 independent parties. 3110 By signing over the signature policy identifier, the algorithm 3111 identifier and the hash of the signature policy, the signer explicitly 3112 indicates that he or she has applied the signature policy in creating 3113 the signature. Thus, undertakes any commitments implied by the 3114 signature policy, any indication of commitment type included in the 3115 electronic signature, and the user data that is signed. 3117 The hash algorithm identifier and value is included to ensure that 3118 both the signer and verifier use exactly the same signature policy. 3119 This unambiguously binds the signer and verifier to same definitive 3120 form of the signature policy has a unique binary encoding. 3122 Internet Draft Electronic Signature Formats 3124 In order to identify unambiguously the "Signature Validation Policy" 3125 to be used to verify the signature an identifier and hash of the 3126 "Signature policy" must be part of the signed data. Additional 3127 information about the policy (e.g. web reference to the document) may 3128 be carried as "qualifiers" to the signature policy identifier. 3130 B.3.2 Commitment Type Indication 3132 The definition of electronic signature includes: "a commitment has 3133 been explicitly endorsed under a signature policy, at a given time, 3134 by a signer under an identifier, e.g. a name or a pseudonym, and 3135 optionally a role". 3137 The commitment type can be indicated in the electronic signature 3138 either: 3140 * explicitly using a "commitment type indication" in the 3141 electronic signature; 3143 * implicitly or explicitly from the semantics of the signed data. 3145 If the indicated commitment type is explicit using a "commitment type 3146 indication" in the electronic signature, acceptance of a verified 3147 signature implies acceptance of the semantics of that commitment type. 3148 The semantics of explicit commitment types indications must be 3149 specified either as part of the signature policy or may be registered 3150 for generic use across multiple policies. 3152 If a signature includes a commitment type indication other than one of 3153 those recognized under the signature policy the signature must be 3154 treated as invalid. 3156 How commitment is indicated using the semantics of the data being 3157 signed is outside the scope of this document. 3159 NOTE: Examples of commitment indicated through the semantics of the 3160 data being signed, are: 3162 * An explicit commitment made by the signer indicated by the type 3163 of data being signed over. Thus, the data structure being 3164 signed can have an explicit commitment within the context of 3165 the application (e.g. EDIFACT purchase order). 3167 * An implicit commitment which is a commitment made by the signer 3168 because the data being signed over has specific semantics 3169 (meaning) which is only interpretable by humans, (i.e. free 3170 text). 3172 Internet Draft Electronic Signature Formats 3174 B.3.3 Certificate Identifier from the Signer 3176 The definition of the ETSI electronic signature includes: "a 3177 commitment has been explicitly endorsed under a signature policy, 3178 at a given time, by a signer under an identifier, e.g. a name or a 3179 pseudonym, and optionally a role." 3181 In many real life environments users will be able to get from 3182 different CAs or even from the same CA, different certificates 3183 containing the same public key for different names. The prime 3184 advantage is that a user can use the same private key for different 3185 purposes. Multiple use of the private key is an advantage when a smart 3186 card is used to protect the private key, since the storage of a smart 3187 card is always limited. When several CAs are involved, each different 3188 certificate may contain a different identity, e.g. as a national or as 3189 an employee from a company. Thus when a private key is used for 3190 various purposes, the certificate is needed to clarify the context in 3191 which the private key was used when generating the signature. Where 3192 there is the possibility of multiple use of private keys it is 3193 necessary for the signer to indicate to the verifier the precise 3194 certificate to be used. 3196 Many current schemes simply add the certificate after the signed data 3197 and thus are subject to various substitution attacks. An example of a 3198 substitution attack is a "bad" CA that would issue a certificate to 3199 someone with the public key of someone else. If the certificate from 3200 the signer was simply appended to the signature and thus not protected 3201 by the signature, any one could substitute one certificate by another 3202 and the message would appear to be signed by some one else. 3204 In order to counter this kind of attack, the identifier of the signer 3205 has to be protected by the digital signature from the signer. 3207 Although it does not provide the same advantages as the previous 3208 technique, another technique to counter that threat has been 3209 identified. It requires all CAs to perform a Proof Of Possession of 3210 the private key at the time of registration. The problem with that 3211 technique is that it does not provide any guarantee at the time of 3212 verification and only some proof "after the event" may be obtained, if 3213 and only if the CA keeps the Proof Of Possession in audit trail. 3215 In order to identify unambiguously the certificate to be used for the 3216 verification of the signature an identifier of the certificate from 3217 the signer must be part of the signed data. 3219 B.3.4 Role Attributes 3221 The definition of electronic signature includes: "a commitment has 3222 been explicitly endorsed under a non repudiation security policy, 3223 at a given time, by a signer under an identifier, e.g. a name or a 3224 pseudonym, and optionally a role. " 3226 Internet Draft Electronic Signature Formats 3228 While the name of the signer is important, the position of the signer 3229 within a company or an organization can be even more important. Some 3230 contracts may only be valid if signed by a user in a particular role, 3231 e.g. a Sales Director. In many cases whom the sales Director really 3232 is, is not that important but being sure that the signer is empowered 3233 by his company to be the Sales Director is fundamental. 3235 This document defines two different ways for providing this feature: 3237 * by placing a claimed role name in the CMS signed 3238 attributes field; 3240 * by placing a attribute certificate containing a certified 3241 role name in the CMS signed attributes field. 3243 NOTE: Another possible approach would have been to use additional 3244 attributes containing the roles name(s) in the signer's certificate. 3245 However, it was decided not to follow this approach as it breaks the 3246 basic philosophy of the certificate being issued for one primary 3247 purpose. Also, by using separate certificates for management of the 3248 signer's identity certificate and management of additional roles can 3249 simplify the management, as new identity keys need not be issued if a 3250 use of role is to be changed. 3252 B.3.5.1 Claimed Role 3254 The signer may be trusted to state his own role without any 3255 certificate to corroborate this claim. In which case the claimed role 3256 can be added to the signature as a signed attribute. 3258 B.3.5.2 Certified Role 3260 Unlike public key certificates that bind an identifier to a public 3261 key, Attribute Certificates bind the identifier of a certificate to 3262 some attributes, like a role. An Attribute Certificate is NOT issued 3263 by a CA but by an Attribute Authority (AA). The Attribute Authority 3264 will be most of the time under the control of an organization or a 3265 company that is best placed to know which attributes are relevant for 3266 which individual. 3268 The Attribute Authority may use or point to public key certificates 3269 issued by any CA, provided that the appropriate trust may be placed 3270 in that CA. Attribute Certificates may have various periods of 3271 validity. That period may be quite short, e.g. one day. While this 3272 requires that a new Attribute Certificate is obtained every day, valid 3273 for that day, this can be advantageous since revocation of such 3274 certificates may not be needed. When signing, the signer will have to 3275 specify which Attribute Certificate it selects. In order to do 3276 so, the Attribute Certificate will have to be included in the signed 3277 data in order to be protected by the digital signature from the signer. 3279 Internet Draft Electronic Signature Formats 3281 In order to identify unambiguously the attribute certificate(s) to be 3282 used for the verification of the signature an identifier of the 3283 attribute certificate(s) from the signer must be part of the signed 3284 data. 3286 B.3.5 Signer Location 3288 In some transactions the purported location of the signer at the time 3289 he or she applies his signature may need to be indicated. For this 3290 reason an optional location indicator must be able to be included. 3292 In order to provide indication of the location of the signer at the 3293 time he or she applied his signature a location attribute may be 3294 included in the signature. 3296 B.3.6 Signing Time 3298 The definition of electronic signature includes: "a commitment has 3299 been explicitly endorsed under a signature policy, at a given time, 3300 by a signer under an identifier, e.g. a name or a pseudonym, and 3301 optionally a 3302 role. " 3304 There are several ways to address this problem. The solution adopted 3305 in this document is to sign over a time which the signer claims is the 3306 signing time (i.e. claimed signing time) and to require a trusted 3307 time stamp to be obtained when building a ES with Timestamp. When a 3308 verifier accepts a signature, the two times must be within acceptable 3309 limits. 3311 The solution that is adopted in this document offers the major 3312 advantage that electronic signatures can be generated without any on- 3313 line connection to a trusted time source (i.e. they may be generated 3314 off-line). 3316 Thus two dates and two signatures are required: 3318 * a signing time indicated by the signer and which is part of 3319 the data signed by the signer (i.e. part of the basic 3320 electronic signature); 3322 * a time indicated by a TimeStamping Authority (TSA) which is 3323 signed over the digital signature value of the basic electronic 3324 signature. The signer, verifier or both may obtain the TSA 3325 timestamp. 3327 In order for an electronic signature to be valid under a signature 3328 policy, it must be timestamped by a TSA where the signing time as 3329 indicated by the signer and the time of time stamping as indicated by 3330 a TSA must be "close enough" to meet the requirements of the signature 3331 validation policy. 3333 Internet Draft Electronic Signature Formats 3335 "Close enough" means a few minutes, hours or even days according to 3336 the "Signature Validation Policy". 3338 NOTE: The need for Timestamping is further explained in clause B.4.5. 3339 A further optional attribute is defined in this document to timestamp 3340 the content, to provide proof of the existence of the content, at the 3341 time indicated by the timestamp. 3343 Using this optional attribute a trusted secure time may be obtained 3344 before the document is signed and included under the digital signature. 3345 This solution requires an on-line connection to a trusted timestamping 3346 service before generating the signature and may not represent the 3347 precise signing time, since it can be obtained in advance. However, 3348 this optional attribute may be used by the signer to prove that the 3349 signed object existed before the date included in the timestamp (see 3350 3.12.3, Content Timestamp). 3352 Also, the signing time should be between the time indicated by this 3353 timestamp and time indicated by the ES-T timestamp. 3355 B.4 Components of Validation Data 3357 B.4.1 Revocation Status Information 3359 A verifier will have to prove that the certificate of the signer was 3360 valid at the time of the signature. This can be done by either: 3362 * using Certificate Revocation Lists (CRLs); 3364 * using responses from an on-line certificate status server 3365 (for example; obtained through the OCSP protocol). 3367 B.4.2 CRL Information 3369 When using CRLs to get revocation information, a verifier will have to 3370 make sure that he or she gets at the time of the first verification the 3371 appropriate certificate revocation information from the signer's CA. 3372 This should be done as soon as possible to minimize the time delay 3373 between the generation and verification of the signature. This involves 3374 checking that the signer certificate serial number is not included in 3375 the CRL. The signer, the verifier or any other third party may obtain 3376 either this CRL. If obtained by the signer, then it must be conveyed 3377 to the verifier. It may be convenient to archive the CRL for ease of 3378 subsequent verification or arbitration. 3380 Alternatively, provided the CRL is archived elsewhere which is 3381 accessible for the purpose of arbitration, then the serial number of 3382 the CRL used may be archived together with the verified electronic 3383 signature. 3385 Internet Draft Electronic Signature Formats 3387 It may happen that the certificate serial number appears in the CRL 3388 but with the status "suspended" (i.e. on hold). In such a case, the 3389 electronic signature is not yet valid, since it is not possible to 3390 know whether the certificate will or will not be revoked at the end 3391 of the suspension period. If a decision has to be taken immediately 3392 then the signature has to be considered as invalid. If a decision can 3393 wait until the end of the suspension period, then two cases are 3394 possible: 3396 * the certificate serial number has disappeared from the list 3397 and thus the certificate can be considered as valid and that 3398 CRL must be captured and archived either by the verifier or 3399 elsewhere and be kept accessible for the purpose of arbitration. 3401 * the certificate serial number has been maintained on the list 3402 with the status definitively revoked and thus the electronic 3403 signature must be considered as invalid and discarded. 3405 At this point the verifier may be convinced that he or she got a valid 3406 signature, but is not yet in a position to prove at a later time that 3407 the signature was verified as valid. Before addressing this point, an 3408 alternative to CRL is to use OCSP responses. 3410 B.4.3 OCSP Information 3412 When using OCSP to get revocation information , a verifier will have 3413 to make sure that he or she gets at the time of the first verification 3414 an OCSP response that contains the status "valid". This should be done 3415 as soon as possible after the generation of the signature. The signer, 3416 the verifier or any other third party may fetch this OCSP response. 3417 Since OSCP responses are transient and thus are not archived by any 3418 TSP including CA, it is the responsibility of every verifier to make 3419 sure that it is stored in a safe place. The simplest way is to store 3420 them associated with the electronic signature. An alternative would be 3421 to store them in some storage so that they can then be easily 3422 retrieved. 3424 In the same way as for the case of the CRL, it may happen that the 3425 certificate is declared as invalid but with the secondary status 3426 "suspended". 3428 In such a case, the electronic signature is not yet valid, since it is 3429 not possible to know whether the certificate will or will not be 3430 revoked at the end of the suspension period. If a decision has to be 3431 taken immediately then the electronic signature has to be considered 3432 as invalid. If a decision can wait until the end of the suspension 3433 period, then two cases are possible: 3435 * An OCSP response with a valid status is obtained at a later 3436 date and thus the certificate can be considered as valid and 3437 that OCSP response must be captured. 3439 Internet Draft Electronic Signature Formats 3441 * An OCSP response with an invalid status is obtained with a 3442 secondary status indicating that the certificate is 3443 definitively revoked and thus the electronic signature must be 3444 considered as invalid and discarded. 3446 As in the CRL case, at this point, the verifier may be convinced that 3447 he or she got a valid signature, but is not yet in a position to prove 3448 at a later time that the signature was verified as valid. 3450 B.4.4 Certification Path 3452 A verifier will have to prove that the certification path was valid, 3453 at the time of the signature, up to a trust point according to the 3454 naming constraints and the certificate policy constraints from the 3455 "Signature Validation Policy". It will be necessary to capture all the 3456 certificates from the certification path, starting with those from the 3457 signer and ending up with those of the self-signed certificate from 3458 one trusted root of the "Signature Validation Policy". In addition, it 3459 will be necessary to capture the Authority Revocation Lists (ARLs) to 3460 prove than none of the CAs from the chain was revoked at the time of 3461 the signature. 3463 As in the OCSP case, at this point, the verifier may be convinced that 3464 he or she got a valid signature, but is not yet in a position to prove 3465 at a later time that the signature was verified as valid. 3467 B.4.5 Timestamping for Long Life of Signature 3469 An important property for long standing signatures is that a 3470 signature, having been found once to be valid, must continue to be so 3471 months or years later. 3473 A signer, verifier or both may be required to provide on request, 3474 proof that a digital signature was created or verified during the 3475 validity period of the all the certificates that make up the 3476 certificate path. In this case, the signer, verifier or both will 3477 also be required to provide proof that all the user and CA 3478 certificates used were not revoked when the signature was created 3479 or verified. 3481 It would be quite unacceptable, to consider a signature as invalid 3482 even if the keys or certificates were later compromised. Thus there 3483 is a need to be able to demonstrate that the signature keys was valid 3484 around the time that the signature was created to provide long term 3485 evidence of the validity of a signature. 3487 It could be the case that a certificate was valid at the time of the 3488 signature but revoked some time later. In this event, evidence must be 3489 provided that the document was signed before the signing key was 3490 revoked. 3492 Internet Draft Electronic Signature Formats 3494 Timestamping by a Time Stamping Authority (TSA) can provide such 3495 evidence. A time stamp is obtained by sending the hash value of the 3496 given data to the TSA. The returned "timestamp" is a signed document 3497 that contains the hash value, the identity of the TSA, and the time of 3498 stamping. This proves that the given data existed before the time of 3499 stamping. Timestamping a digital signature (by sending a hash of the 3500 signature to the TSA) before the revocation of the signer's private 3501 key, provides evidence that the signature has been created before the 3502 key was revoked. 3504 If a recipient wants to hold a valid electronic signature he will have 3505 to ensure that he has obtained a valid time stamp for it, before that 3506 key (and any key involved in the validation) is revoked. The sooner 3507 the timestamp is obtained after the signing time, the better. 3509 It is important to note that signatures may be generated "off-line" 3510 and time-stamped at a later time by anyone, for example by the signer 3511 or any recipient interested in the value of the signature. The time 3512 stamp can thus be provided by the signer together with the signed 3513 document, or obtained by the recipient following receipt of the signed 3514 document. 3516 The time stamp is NOT a component of the Electronic Signature, but the 3517 essential component of the ES with Timestamp. 3519 It is required in this document that signer's digital signature value 3520 is timestamped by a trusted source, known as a TimeStamping Authority. 3522 This document requires that the signer's digital signature value is 3523 timestamped by a trusted source before the electronic signature can 3524 become a ES with Complete validation data (ES-C). The acceptable TSAs 3525 are specified in the Signature Validation Policy. 3527 Should both the signer and verifier be required to timestamp the 3528 signature value to meet the requirements of the signature policy, the 3529 signature policy MAY specify a permitted time delay between the two 3530 time stamps. 3532 B.4.6 Timestamping before CA Key Compromises 3534 Timestamped extended electronic signatures are needed when there is a 3535 requirement to safeguard against the possibility of a CA key in the 3536 certificate chain ever being compromised. A verifier may be required 3537 to provide on request, proof that the certification path and the 3538 revocation information used a the time of the signature were valid, 3539 even in the case where one of the issuing keys or OCSP responder keys 3540 is later compromised. 3542 Internet Draft Electronic Signature Formats 3544 The current document defines two ways of using timestamps to protect 3545 against this compromise: 3547 * Timestamp the ES with Complete validation data, when an OCSP 3548 response is used to get the status of the certificate from the 3549 signer. 3551 * Timestamp only the certification path and revocation information 3552 references when a CRL is used to get the status of the 3553 certificate from the signer. 3555 NOTE: the signer, verifier or both may obtain the timestamp. 3557 B.4.6.1 Timestamping the ES with Complete validation data 3559 When an OCSP response is used, it is necessary to time stamp in 3560 particular that response in the case the key from the responder would 3561 be compromised. Since the information contained in the OCSP response 3562 is user specific and time specific, an individual time stamp is needed 3563 for every signature received. Instead of placing the time stamp only 3564 over the certification path references and the revocation information 3565 references, which include the OCSP response, the time stamp is placed 3566 on the ES-C. Since the certification path and revocation information 3567 references are included in the ES with Complete validation data they 3568 are also protected. For the same cryptographic price, this provides an 3569 integrity mechanism over the ES with Complete validation data. Any 3570 modification can be immediately detected. It should be noticed that 3571 other means of protecting/detecting the integrity of the ES with 3572 Complete Validation Data exist and could be used. 3574 Although the technique requires a time stamp for every signature, it 3575 is well suited for individual users wishing to have an integrity 3576 protected copy of all the validated signatures they have received. 3578 By timestamping the complete electronic signature, including the 3579 digital signature as well as the references to the certificates and 3580 revocation status information used to support validation of that 3581 signature, the timestamp ensures that there is no ambiguity in the 3582 means of validating that signature. 3584 This technique is referred to as ES with eXtended validation data 3585 (ES-X), type 1 Timestamped in this document. 3587 NOTE: Trust is achieved in the references by including a hash of the 3588 data being referenced. 3590 If it is desired for any reason to keep a copy of the additional data 3591 being referenced, the additional data may be attached to the 3592 electronic signature, in which case the electronic signature becomes 3593 a ES-X Long as defined by this document. 3595 A ES-X Long Timestamped is simply the concatenation of a ES-X 3596 Timestamped with a copy of the additional data being referenced. 3598 Internet Draft Electronic Signature Formats 3600 B.4.6.2 Timestamping Certificates and Revocation Information 3602 References Timestamping each ES with Complete validation data as 3603 defined above may not be efficient, particularly when the same set of 3604 CA certificates and CRL information is used to validate many 3605 signatures. 3607 Timestamping CA certificates will stop any attacker from issuing bogus 3608 CA certificates that could be claimed to existing before the CA key 3609 was compromised. Any bogus timestamped CA certificates will show that 3610 the certificate was created after the legitimate CA key was 3611 compromised. In the same way, timestamping CA CRLs, will stop any 3612 attacker from issuing bogus CA CRLs which could be claimed to existing 3613 before the CA key was compromised. 3615 Timestamping of commonly used certificates and CRLs can be done 3616 centrally, e.g. inside a company or by a service provider. This method 3617 reduces the amount of data the verifier has to timestamp, for example 3618 it could reduce to just one time stamp per day (i.e. in the case were 3619 all the signers use the same CA and the CRL applies for the whole day). 3620 The information that needs to be time stamped is not the actual 3621 certificates and CRLs but the unambiguous references to those 3622 certificates and CRLs. 3624 To comply with extended validation data, type 2 Timestamped, this 3625 document requires the following: 3627 * All the CA certificates references and revocation information 3628 references (i.e. CRLs) used in validating the ES-C are covered 3629 by one or more timestamp. 3631 Thus a ES-C with a timestamp signature value at time T1, can be proved 3632 valid if all the CA and CRL references are timestamped at time T1+. 3634 B.4.7 Timestamping for Long Life of Signature 3636 Advances in computing increase the probability of being able to break 3637 algorithms and compromise keys. There is therefore a requirement to be 3638 able to protect electronic signatures against this probability. 3640 Over a period of time weaknesses may occur in the cryptographic 3641 algorithms used to create an electronic signature (e.g. due to the 3642 time available for cryptoanalysis, or improvements in cryptoanalytical 3643 techniques). Before this such weaknesses become likely, a verifier 3644 should take extra measures to maintain the validity of the electronic 3645 signature. Several techniques could be used to achieve this goal 3646 depending on the nature of the weakened cryptography. In order to 3647 simplify, a single technique, called Archive validation data, covering 3648 all the cases is being used in this document. 3650 Internet Draft Electronic Signature Formats 3652 Archive validation data consists of the Complete validation data and 3653 the complete certificate and revocation data, time stamped together 3654 with the electronic signature. The Archive validation data is 3655 necessary if the hash function and the crypto algorithms that were 3656 used to create the signature are no longer secure. Also, if it cannot 3657 be assumed that the hash function used by the Time Stamping Authority 3658 is secure, then nested timestamps of Archived Electronic Signature are 3659 required. 3661 The potential for Trusted Service Provider (TSP) key compromise should 3662 be significantly lower than user keys, because TSP(s) are expected to 3663 use stronger cryptography and better key protection. It can be expected 3664 that new algorithms (or old ones with greater key lengths) will be 3665 used. In such a case, a sequence of timestamps will protect against 3666 forgery. Each timestamp needs to be affixed before either the 3667 compromise of the signing key or of the cracking of the algorithms used 3668 by the TSA. TSAs (TimeStamping Authorities) should have long keys (e.g. 3669 which at the time of drafting this document was 2048 bits for the 3670 signing RSA algorithm) and/or a "good" or different algorithm. 3672 Nested timestamps will also protect the verifier against key compromise 3673 or cracking the algorithm on the old electronic signatures. 3675 The process will need to be performed and iterated before the 3676 cryptographic algorithms used for generating the previous time stamp 3677 are no longer secure. Archive validation data may thus bear multiple 3678 embedded time stamps. 3680 B.4.8 Reference to Additional Data 3682 Using type 1 or 2 of Timestamped extended validation data verifiers 3683 still needs to keep track of all the components that were used to 3684 validate the signature, in order to be able to retrieve them again 3685 later on. These components may be archived by an external source like 3686 a trusted service provider, in which case referenced information that 3687 is provided as part of the ES with Complete validation data (ES-C) is 3688 adequate. The actual certificates and CRL information reference in the 3689 ES-C can be gathered when needed for arbitration. 3691 B.4.9 Timestamping for Mutual Recognition 3693 In some business scenarios both the signer and the verifier need to 3694 timestamp their own copy of the signature value. Ideally the two 3695 timestamps should be as close as possible to each other. 3697 Example: A contract is signed by two parties A and B representing 3698 their respective organizations, to timestamp the signer and verifier 3699 data two approaches are possible: 3701 * under the terms of the contract pre-defined common "trusted" 3702 TSA may be used; 3704 Internet Draft Electronic Signature Formats 3706 * if both organizations run their own timestamping services, A 3707 and B can have the transaction timestamped by these two 3708 timestamping services. In the latter case, the electronic 3709 signature will only be considered as valid, if both timestamps 3710 were obtained in due time (i.e. there should not be a long 3711 delay between obtaining the two timestamps). Thus, neither A 3712 nor B can repudiate the signing time indicated by their own 3713 timestamping service. 3715 Therefore, A and B do not need to agree on a common "trusted" TSA to 3716 get a valid transaction. 3718 It is important to note that signatures may be generated "off-line" 3719 and timestamped at a later time by anyone, e.g. by the signer or any 3720 recipient interested in validating the signature. The timestamp over 3721 the signature from the signer can thus be provided by the signer 3722 together with the signed document, and /or obtained by the verifier 3723 following receipt of the signed document. 3725 The business scenarios may thus dictate that one or more of the long- 3726 term signature timestamping methods describe above be used. This will 3727 need to be part of a mutually agreed the Signature Validation Policy 3728 with is part of the overall signature policy under which digital 3729 signature may be used to support the business relationship between the 3730 two parties. 3732 B.4.10 TSA Key Compromise 3734 TSA servers should be built in such a way that once the private 3735 signature key is installed, that there is minimal likelihood of 3736 compromise over as long as possible period. Thus the validity period 3737 for the TSA's keys should be as long as possible. 3739 Both the ES-T and the ES-C contain at least one time stamp over the 3740 signer's signature. In order to protect against the compromise of the 3741 private signature key used to produce that timestamp, the Archive 3742 validation data can be used when a different TimeStamping Authority key 3743 is involved to produce the additional timestamp. If it is believed that 3744 the TSA key used in providing an earlier timestamp may ever be 3745 compromised (e.g. outside its validity period), then the ES-A should be 3746 used. For extremely long periods this may be applied repeatedly using 3747 new TSA keys. 3749 B.5 Multiple Signatures 3751 Some electronic signatures may only be valid if they bear more than one 3752 signature. This is the case generally when a contract is signed between 3753 two parties. The ordering of the signatures may or may not be 3754 important, i.e. one may or may not need to be applied before the other. 3756 Internet Draft Electronic Signature Formats 3758 Several forms of multiple and counter signatures may need to be 3759 supported, which fall into two basic categories: 3761 * independent signatures; 3762 * embedded signatures. 3764 Independent signatures are parallel signatures where the ordering of 3765 the signatures is not important. The capability to have more than one 3766 independent signature over the same data must be provided. 3768 Embedded signatures are applied one after the other and are used where 3769 the order the signatures are applied is important. The capability to 3770 sign over signed data must be provided. 3772 These forms are described in clause 3.13. All other multiple signature 3773 schemes, e.g. a signed document with a countersignature, double 3774 countersignatures or multiple signatures, can be reduced to one or more 3775 occurrence of the above two cases. 3777 Internet Draft Electronic Signature Formats 3779 Annex C (informative): Identifiers and roles 3781 C.1 Signer Name Forms 3783 The name used by the signer, held as the subject in the signer's 3784 certificate, must uniquely identify the entity. The name must be 3785 allocated and verified on registration with the Certification 3786 Authority, either directly or indirectly through a Registration 3787 Authority, before being issued with a Certificate. 3789 This document places no restrictions on the form of the name. The 3790 subject's name may be a distinguished name, as defined in [RFC2459], 3791 held in the subject field of the certificate, or any other name form 3792 held in the X.509 subjectAltName certificate extension field. In the 3793 case that the subject has no distinguished name, the subject name can 3794 be an empty sequence and the subjectAltName extension must be critical. 3796 C.2 TSP Name Forms 3798 All TSP name forms (Certification Authorities, Attribute Authorities 3799 and TimeStamping Authorities) must be in the form of a distinguished 3800 name held in the subject field of the certificate. 3802 The TSP name form must include the legal jurisdiction (i.e. country) 3803 under which it operates and an identification for the organization 3804 providing the service. 3806 C.3 Roles and Signer Attributes 3808 Where a signer signs as an individual but wishes to also identify 3809 him/herself as acting on behalf of an organization, it may be necessary 3810 to provide two independent forms of identification. The first identity, 3811 with is directly associated with the signing key identifies him/her as 3812 an individual. The second, which is managed independently, identifies 3813 that person acting as part of the organization, possibly with a given 3814 role. 3816 In this case the first identity is carried in the 3817 subject/subjectAltName field of the signer's certificate as described 3818 above. 3820 This document supports the following means of providing a second form 3821 of identification: 3823 * by placing a secondary name field containing a claimed role in 3824 the CMS signed attributes field; 3826 * by placing an attribute certificate containing a certified role 3827 in the CMS signed attributes field.