idnits 2.17.1 draft-ietf-smime-esformats-00.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 document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 88 longer pages, the longest (page 9) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 106 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 120 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 571 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1096 has weird spacing: '...ofiling by...' == Line 1110 has weird spacing: '...ofiling by...' == Line 1357 has weird spacing: '...the electroni...' == Line 1534 has weird spacing: '...tion of the s...' == Line 1681 has weird spacing: '... values is ou...' == (6 more instances...) == 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 (March 2000) is 8808 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '13' on line 100 -- Looks like a reference, but probably isn't: '1' on line 4012 -- Looks like a reference, but probably isn't: '9' on line 128 -- Looks like a reference, but probably isn't: '7' on line 2560 -- Looks like a reference, but probably isn't: '12' on line 267 == Missing Reference: 'CMS' is mentioned on line 1102, but not defined -- Looks like a reference, but probably isn't: '10' on line 792 == Missing Reference: 'ESS' is mentioned on line 1137, but not defined -- Looks like a reference, but probably isn't: '0' on line 4010 -- Looks like a reference, but probably isn't: '2' on line 4014 -- Looks like a reference, but probably isn't: '16' on line 1309 == Missing Reference: 'TSP' is mentioned on line 1814, but not defined -- Looks like a reference, but probably isn't: '8' on line 1689 -- Looks like a reference, but probably isn't: '3' on line 4016 -- Looks like a reference, but probably isn't: '4' on line 4018 -- Looks like a reference, but probably isn't: '5' on line 3830 -- Looks like a reference, but probably isn't: '15' on line 5233 == Unused Reference: 'RFC2510' is defined on line 2574, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 2580, but no explicit reference was found in the text == Unused Reference: 'RFC 2634' is defined on line 2583, but no explicit reference was found in the text == Unused Reference: 'RFC 2630' is defined on line 2585, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 2590, but no explicit reference was found in the text == Unused Reference: 'PKCS9' is defined on line 2594, but no explicit reference was found in the text == Unused Reference: 'ISONR' is defined on line 2598, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2630 (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) Summary: 13 errors (**), 0 flaws (~~), 20 warnings (==), 16 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 J Ross (Security & Standards) 3 expires in six months D Pinkas (Bull) 4 Target Category: Informational N Pope (Security & Standards) 5 March 2000 7 Electronic Signature Formats 8 for long term electronic signature 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 other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 Months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The informational RFC defines the format of an electronic signature 36 that can remain valid over long periods. This includes evidence as to 37 its validity even if the signer or verifying party later attempts to 38 deny (repudiates) the validity of the signature. 40 The contents of this Informational RFC is technically equivalent to 41 ETSI ES 201 733 V.1.1.1 Copyright (C). Individual copies of this 42 ETSI deliverable can be downloaded from http://www.etsi.org 44 1. Introduction 46 This document is intended to cover electronic signatures for various 47 types of transactions, including business transactions (e.g. purchase 48 requisition, contract, and invoice applications) where long term 49 validity of such signatures is important. Electronic signatures can 50 be used for any transaction between an individual and a company, 51 between two companies, between an individual and a governmental body, 52 etc. This document is independent of any environment. It can be applied 53 to any environment e.g. smart cards, GSM SIM cards, special programs 54 for electronic signatures etc. 56 Internet Draft Electronic Signature Formats 58 An electronic signature produced in accordance with this document 59 provides evidence that can be processed to get confidence that some 60 commitment has been explicitly endorsed under a Signature policy, at a 61 given time, by a signer under an identifier, e.g. a name or a 62 pseudonym, and optionally a role. 64 The European Directive on a community framework for Electronic 65 Signatures defines an electronic signature as: "data in electronic form 66 which is attached to or logically associated with other electronic data 67 and which serves as a method of authentication". An electronic 68 signature as used in the current document is a form of advanced 69 electronic signature as defined in the Directive. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 72 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 73 as shown) are to be interpreted as described in [RFC2119]. 75 2 Overview 77 2.1 Aim 79 The aim of this document is to define an Electronic Signature (ES) that 80 remains valid over long periods. This includes evidence as to its 81 validity even if the signer or verifying party later attempts to deny 82 (repudiates) the validity of the signature. 84 A signer is the entity that creates an electronic signature. 86 This document specifies use of trusted service providers (e.g. 87 TimeStamping Authorities (TSA)), and the data that needs to be archived 88 (e.g. cross certificates and revocation lists) to meet the requirements 89 of long term electronic signatures. An electronic signature defined by 90 this document can be used for arbitration in case of a dispute between 91 the signer and verifier, which may occur at some later time, even years 92 later. This document uses a signature policy, referenced by the signer, 93 as the basis for establishing the validity of an electronic signature. 95 A Trusted Service Provider (TSP) is an entity that helps to build trust 96 relationships by making available or providing some information upon 97 request. 99 A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1 100 [13]). Within the context of this document this is an entity that 101 validates an electronic signature. 103 A signature policy is a set of rules for the creation and validation of 104 an electronic signature, under which the signature can be determined to 105 be valid 107 2.2 Basis of Present Document 109 This document is based on the use of public key cryptography to produce 110 digital signatures, supported by public key certificates. 112 Internet Draft Electronic Signature Formats 114 A Public key certificate is a public keys of a user, together with some 115 other information, rendered unforgeable by encipherment with the 116 private key of the Certification Authority (CA) which issued it (ITU-T 117 Recommendation X.509 [1]). 119 This document also uses timestamping services to prove the validity of 120 a signature long after the normal lifetime of critical elements of an 121 electronic signature and to support non-repudiation. It also, as an 122 option, uses additional timestamps to provide very long-term protection 123 against key compromise or weakened algorithms. 125 This document builds on existing standards that are widely adopted. 126 This includes: 128 * RFC 2630 [9] Crytographic Message Syntax (CMS); 129 * ITU-T Recommendation X.509 [1] Authentication framework; 130 * RFC 2459 [7] Internet X.509 Public Key Infrastructure (PKIX) 132 Certificate and CRL Profile; 133 * RFC (to be published) PKIX Timestamping protocol. 135 NOTE: See clause 2 for a full set of references. 137 2.3 Major Parties 139 The following are the major parties involved in a business transaction 140 supported by electronic signatures as defined in this document: 142 * the Signer; 143 * the Verifier; 144 * Trusted Service Providers (TSP); 145 * the Arbitrator. 147 The arbitrator is an entity that may be used to arbitrate a dispute 148 between a signer and verifier when there is a disagreement on the 149 validity of a digital signature. 151 The Signer is the entity that creates the electronic signature. When 152 the signer digitally signs over data using the prescribed format, this 153 represents a commitment on behalf of the signing entity to the data 154 being signed. 156 The Verifier is the entity that validates the electronic signature, it 157 may be a single entity or multiple entities. 159 The Trusted Service Providers (TSPs) are one or more entities that help 160 to build trust relationships between the signer and verifier. They 161 support the signer and verifier by means of supporting services 162 including: user certificates, cross-certificates, timestamping tokens, 163 CRLs, ARLs, OCSP responses. 165 Internet Draft Electronic Signature Formats 167 The following TSPs are used to support the 168 functions defined in this document: 170 * Certification Authorities; 171 * Registration Authorities; 172 * Repository Authorities (e.g. a Directory); 173 * TimeStamping Authorities; 174 * Signature Policy Issuers. 176 Certification Authorities provide users with public key certificates. 178 Registration Authorities allows the registration of entities before a 179 CA generates certificates. 181 Repository Authorities publish CRLs issued by CAs, signature policies 182 issued by Signature Policy Issuers and optionally public key 183 certificates. 185 TimeStamping Authorities attest that some data was formed before a 186 given trusted time. 188 Signature Policy Issuers define the technical and procedural 189 requirements for electronic signature creation and validation, in order 190 to meet a particular business need. 192 In some cases the following additional TSPs are needed: 194 * Attribute Authorities. 196 Attributes Authorities provide users with attributes linked to public 197 key certificates 199 An Arbitrator is an entity that arbitrates disputes between a signer 200 and a verifier. 202 A signature policy issuer is an entity that defines the technical and 203 procedural requirements for electronic signature creation and 204 validation, in order to meet a particular business need 206 2.4 Electronic Signatures and Validation Data 208 Validation of an electronic signature in accordance with this document 209 requires: 211 * The electronic signature; this includes: 212 - the signature policy; 213 - the signed user data; 214 - the digital signature; 215 - other signed attributes provided by the signer. 217 Internet Draft Electronic Signature Formats 219 * Validation data which is the additional data needed to validate 220 the electronic signature; this includes: 222 - certificates; 223 - revocation status information, 224 - trusted time-stamps from Trusted Service Providers (TSPs). 226 * The signature policy specifies the technical requirements on 227 signature creation and validation in order to meet a particular 228 business need. A given legal/contractual context may recognize a 229 particular signature policy as meeting its requirements. 231 For example: a specific signature policy may be recognized by court of 232 law as meeting the requirements of the European Directive for electronic 233 commerce. A signature policy may be written using a formal notation like 234 ASN.1 (see 6.1) or in an informal free text form provided the rules of 235 the policy are clearly identified. However, for a given signature policy 236 there shall be one definitive form which has a unique binary encoded 237 value. 239 Signed user data is the user's data that is signed. 241 The Digital Signature is the digital signature applied over the 242 following attributes provided by the signer: 244 * hash of the user data; 245 * signature Policy Identifier; 246 * other signed attributes 248 The other signed attributes include any additional information which 249 must be signed to conform to the signature policy or this document 250 (e.g. signing time). 252 The Validation Data may be collected by the signer and/or the verifier 253 and must meet the requirements of the signature policy. Additional 254 data includes CA certificates as well as revocation status information 255 in the form of Certificate Revocation Lists (CRLs) or certificate 256 status information provided by an on-line service. Additional data 257 also includes timestamps and other time related data used to provide 258 evidence of the timing of given events. It is required, as a minimum, 259 that either the signer or verifier obtains a timestamp over the 260 signer's signature. 262 A Certificate Revocation List (CRL) is signed list indicating a set of 263 certificates that are no longer considered valid by the certificate 264 issuer [X.509 FPAM]digital signature: data appended to, or a 265 cryptographic transformation of, a data unit that allows a recipient of 266 the data unit to prove the source and integrity of the data unit and 267 protect against forgery, e.g. by the recipient (ISO 7498-2 [12]) 269 Internet Draft Electronic Signature Formats 271 2.5 Forms of Validation Data 273 An electronic signature may exist in many forms including: 275 * the Electronic Signature (ES), which includes the digital 276 signature and other basic information provided by the signer; 278 * the ES with Timestamp (ES-T), which adds a timestamp to the 279 Electronic Signature, to take initial steps towards providing 280 long term validity; 282 * the ES with Complete validation data (ES-C), which adds to the 283 ES-T references to the complete set of data supporting the 284 validity of the electronic signature (i.e. revocation status 285 information). 287 The signer must provide at least the ES form, but in some cases may 288 decide to provide the ES-T form and in the extreme case could provide 289 the ES-C form. If the signer does not provide ES-T, the verifier must 290 create the ES-T on first receipt of an electronic signature. The ES-T 291 provides independent evidence of the existence of the signature at the 292 time it was first verified which should be near the time it was 293 created, and so protects against later repudiation of the existence of 294 the signature. If the signer does not provide ES-C the verifier must 295 create the ES-C when the complete set of revocation and other validation 296 data is available. 298 The ES satisfies the legal requirements for electronic signatures as 299 defined in the European Directive on electronic signatures, see Annex C 300 for further discussion on relationship of this document to the 301 Directive. It provides basic authentication and integrity protection 302 and can be created without accessing on-line (timestamping) services. 303 However, without the addition of a timestamp the electronic signature 304 does not protect against the threat that the signer later denies having 305 created the electronic signature (i.e. does not provide non-repudiation 306 of its existence). 308 The ES-T time-stamp should be created close to the time that ES was 309 created to provide maximum protection against repudiation. At this time 310 ll the data needed to complete the validation may not be available but 311 what information is readily available may be used to carry out some of 312 the initial checks. For example, only part of the revocation 313 information may be available for verification at that point in time. 315 Generally, the ES-C form cannot be created at the same time as the ES, 316 as it is necessary to allow time for any revocation information to be 317 captured. Also, if a certificate is found to be temporarily suspended, 318 it will be necessary to wait until the end of the suspension period. 320 The signer should only create the ES-C in situations where it was 321 prepared to wait for a sufficient length of time after creating the ES 322 form before dispatching the ES-C. This, however, has the advantage that 323 the verifier can be presented with the complete set of data supporting 324 the validity of the ES. 326 Internet Draft Electronic Signature Formats 328 Support for ES-C by the verifier is mandated (see clause 14 for 329 specific conformance requirements). 331 An Electronic Signature (ES), with the additional validation data forming the 332 ES-T and ES-C is illustrated in Figure 1: 334 +------------------------------------------------------------ES-C-----+ 335 |+--------------------------------------------ES-T-----+ | 336 ||+------Elect.Signature (ES)----------+ +------------+| +-----------+| 337 |||+---------+ +----------+ +---------+| |Timestamp || |Complete || 338 ||||Signature| | Other | | Digital || |over digital|| |certificate|| 339 ||||Policy ID| | Signed | |Signature|| |signature || |and || 340 |||| | |Attributes| | || +------------+| |revocation || 341 |||+---------+ +----------+ +---------+| | |references || 342 ||+------------------------------------+ | +-----------+| 343 |+-----------------------------------------------------+ | 344 +---------------------------------------------------------------------+ 346 Figure 1: Illustration of an ES, ES-T and ES-C 348 2.6 Extended Forms of Validation Data 350 The complete validation data (ES-C) described above may be extended to 351 form an ES with eXtended validation data (ES-X) to meet following 352 additional requirements. 354 Firstly, when the verifier does not has access to, 356 * the signer's certificate, 357 * all the CA certificates that make up the full certification 358 path, 359 * all the associated revocation status information, as referenced 360 in the ES-C. 362 then the values of these certificates and revocation information may be 363 added to the ES-C. This form of extended validation data is called a 364 X-Long. 366 Secondly, if there is a risk that any CA keys used in the certificate 367 chain may be compromised, then it is necessary to additionally 368 timestamp the validation data by either: 370 * timestamping all the validation data as held with the ES(ES-C), 371 this eXtended validation data is called a Type 1 X-Timestamp; or 372 * timestamping individual reference data as used for complete 373 validation. 375 This form of eXtended validation data is called a Type 2 X-Timestamp. 377 Internet Draft Electronic Signature Formats 379 NOTE: The advantages/drawbacks for Type 1 and Type 2 X-Timestamp are 380 discussed in this document (see clause 4.4.6.) 382 If all the above conditions occur then a combination of the two formats 383 above may be used. This form of eXtended validation data is called 384 a X-Long-Timestamped. 386 Support for the extended forms of validation data is optional. 388 An Electronic Signature (ES) , with the additional validation data 389 forming the ES-X long is illustrated in Figure 2: 391 +------------------------------------------------------- ES-X Long--+ 392 |+--------------------------------------- EC-C --------+ | 393 ||+---- Elect.Signature (ES)----+ +--------+| +--------+ | 394 |||+-------+-+-------+-+-------+| +---------+|Complete|| |Complete| | 395 ||||Signa- | |Other | |Digital|| |Timestamp||certi- || |certi- | | 396 ||||ture | |Signed | |Signa- || |over ||ficate || |ficate | | 397 ||||Policy | |Attri- | |ture || |digital ||and || |and | | 398 ||||ID | |butes | | || |signature||revoc. || |revoc. | | 399 |||+-------+ +-------+ +-------+| +---------+|refs || |data | | 400 ||+-----------------------------+ +--------+| +--------+ | 401 |+-----------------------------------------------------+ | 402 +-------------------------------------------------------------------+ 404 Figure 2: Illustration of an ES and ES-X long. 406 An Electronic Signature (ES) , with the additional validation data 407 forming the eXtended Validation Data - Type 1 is illustrated in 408 Figure 3: 410 +---------------------------------------------------------- ES-X 1 -+ 411 |+---------------------------------------- EC-C --------+ | 412 || +---- Elect.Signature (ES)----+ +--------+| +-------+ | 413 || |+-------+ +-------+ +-------+| +---------+|Complete|| | | | 414 || ||Signa- | |Other | |Digital|| |Timestamp||certifi-|| | Time- | | 415 || ||ture | |Signed | |Signa- || |over ||cate and|| | stamp | | 416 || ||Policy | |Attri- | |ture || |digital ||revoc. || | over | | 417 || ||ID | |butes | | || |signature||refs || | CES | | 418 || |+-------+ +-------+ +-------+| +---------+| || | | | 419 || +-----------------------------+ +--------+| +-------+ | 420 |+------------------------------------------------------+ | 421 +-------------------------------------------------------------------+ 423 Figure 3: Illustration of ES with ES-X Type 1 425 Internet Draft Electronic Signature Formats 427 An Electronic Signature (ES) , with the additional validation data 428 forming the eXtended Validation Data - Type 2 is illustrated in 429 Figure 4: 431 +-------------------------------------------------------- ES-X 2 ---+ 432 |+--------------------------------------- EC-C --------+ | 433 ||+---- Elect.Signature (ES)----+ +--------+| +--------+ | 434 |||+-------+ +-------+ +-------+| +---------+|Complete|| |Times | | 435 ||||Signa- | |Other | |Digital|| |Timestamp||certs || |Stamp | | 436 ||||ture | |Signed | |Signa- || |over ||and || |over | | 437 ||||Policy | |Attri- | |ture || |digital ||revoc. || |Complete| | 438 ||||ID | |butes | | || |signature||refs || |certs | | 439 |||+-------+ +-------+ +-------+| +---------+| || |and | | 440 ||+-----------------------------+ +--------+| |revoc. | | 441 || | |refs | | 442 |+-----------------------------------------------------+ +--------+ | 443 +-------------------------------------------------------------------+ 445 Figure 4: Illustration of ES with ES-X Type 2 447 2.7 Archive Validation Data 449 Before the algorithms, keys and other cryptographic data used at the 450 time the ES-C was built become weak and the cryptographic functions 451 become vulnerable, or the certificates supporting previous timestamps 452 expires, the signed data, the ES-C and any additional information 453 (ES-X) should be timestamped. If possible this should use stronger 454 algorithms (or longer key lengths) than in the original timestamp. 456 This additional data and timestamp is called Archive Validation Data 457 (ES-A). The Timestamping process may be repeated every time the 458 protection used to timestamp a previous ES-A become weak. An ES-A 459 may thus bear multiple embedded time stamps. 461 Support for ES-A is optional. 463 Internet Draft Electronic Signature Formats 465 An example of an Electronic Signature (ES), with the additional 466 validation data for the ES-C and ES-X forming the ES-A is illustrated 467 in Figure 5. 469 +-------------------------------- ES-A --------- ----------+ 470 | +-------------------- ES-A -----------------+ | 471 | | +--------- ES-X -------------- + | | 472 | | |..............................| +-----+ | +-----+ | 473 | | |..............................| |Time | | |Time | | 474 | | |..............................| |Stamp| | |Stamp| | 475 | | | | +-----+ | +-----+ | 476 | | +----------------------------- + | | 477 | +-------------------------------------------+ | 478 +----------------------------------------------------------+ 480 Figure 5: Illustration of ES -A 482 2.8 Arbitration 484 The ES-C may be used for arbitration should there be a dispute between 485 the signer and verifier, provided that: 487 * the arbitrator knows where to retrieve the signer's certificate 488 (if not already present), all the cross-certificates and the 489 required CRLs and/or OCSPs responses referenced in the ES-C; 491 * none of the issuing key from the certificate chain have ever 492 been compromised; 494 * the cryptography used at the time the ES-C was built has not 495 been broken at the time the arbitration is performed. 497 When the first condition is not met, then the plaintiff must provide 498 an ES-X Long. 500 When it is known by some external means that the second condition is 501 not met, then the plaintiff must provide an ES-X Timestamped. 503 When the two previous conditions are not met, the plaintiff must 504 provide the two above information (i.e. an ES-X Timestamped and Long). 506 When the last condition is not met, the plaintiff must provide an ES- 507 A. 509 It should be noticed that a verifier may need to get two time stamps at 510 two different instants of time: one soon after the generation of the ES 511 and one soon after some grace period allowing any entity from the 512 certification chain to declare a key compromise. 514 Internet Draft Electronic Signature Formats 516 2.9 Validation Process 518 The Validation Process validates an electronic signature in accordance 519 with the requirements of the signature policy. The output status of the 520 validation process can be: 522 * valid; 523 * invalid; 524 ... * incomplete verification. 526 A Valid response indicates that the signature has passed verification 527 and it complies with the signature validation policy. 529 A signature validation policy is a part of the signature policy which 530 specifies the technical requirements on the signer in creating a 531 signature and verifier when validating a signature 533 An Invalid response indicates that either the signature format is 534 incorrect or that the digital signature value fails verification 535 (e.g. the integrity checks on the digital signature value fails or any 536 of the certificates on which the digital signature verification depends 537 is known to be invalid or revoked). 539 An Incomplete Validation response indicates that the format and digital 540 signature verifications have not failed but there is insufficient 541 information to determine if the electronic signature is valid under the 542 signature policy. 544 This can include situations where additional information, which does 545 not effect the validity of the digital signature value, may be 546 available but is invalid. In the case of Incomplete Validation, it may 547 be possible to request that the electronic signature be checked again 548 at a later date when additional validation information might become 549 available. Also, in the case of incomplete validation, additional 550 information may be made available to the application or user, thus 551 allowing the application or user to decide what to do with partially 552 correct electronic signatures. 554 The validation process may also output validation data : 555 * a signature timestamp; 556 * the complete validation data; 557 * the archive validation data. 559 Internet Draft Electronic Signature Formats 561 2.10 Example Validation Sequence 563 As described earlier the signer or verifier may collect all the 564 additional data that forms the Electronic Signature. Figure 6, and 565 subsequent description, describes how the validation process may build 566 up a complete electronic signature over time. 568 +---------------------------------------- ES-C ----------+ 569 |+----------------------------- ES-T -------+ | 570 ||+--- Elect.Signature (ES) ----+ | +--------+ | 571 |||+-------+ +-------+ +-------+|+---------+| |Complete| | 572 ||||Signa- | |Other | |Digital|||Timestamp|| |certifi-| | 573 ||||ture | |Signed | |Signa- |||over || |cate and| | 574 ||||Policy | |Attri- | |ture |||digital || |revoca- | | 575 ||||ID | |butes | | |||signature|| |tion | | 576 |||+-------+ +-------+ +-------+|+---------+| |referen-| | 577 ||+------------\----------------+ ^ | |ces | | 578 || \ | | +--------+ | 579 || \ 1 / | ^ | 580 |+----------------\----------------/--------+ | | 581 +------------------\--------------/-------------- /------+ 582 \ /2 ----3-----/ 583 +----------+ | / / 584 | Signed |\ v / | 585 |User data | \ +--------------------+ +------------+ 586 +----------+ \--->| Validation Process |---> |- Valid | 587 +---|--^-------|--^--+ 4 |- Invalid | 588 | | | | |- Validation| 589 v | v | | Incomplete| 590 +---------+ +--------+ +------------+ 591 |Signature| |Trusted | 592 | Policy | |Service | 593 | Issuer | |Provider| 594 +---------+ +--------+ 596 Figure 6: Illustration of an ES with Complete validation data (ES-C) 598 Soon after receiving the electronic signature (ES) from the signer (1), 599 the digital signature value may be checked, the validation process 600 must at least add a time-stamp (2), unless the signer has provided one 601 which is trusted by the verifier. The validation process may also 602 validate the electronic signature, as required under the identified 603 signature policy, using additional data (e.g. certificates, CRL, etc.) 604 provided by trusted service providers. If the validation process is not 605 complete then the output from this stage is the ES-T. 607 Internet Draft Electronic Signature Formats 609 When all the additional data (e.g. the complete certificate and 610 revocation information) necessary to validate the electronic signature 611 first becomes available, then the validation process: 613 * obtains all the necessary additional certificate and revocation 614 status information; 616 * completes all the validation checks on the ES, using the 617 complete certificate and revocation information (if a timestamp 618 is not already present, this may be added at the same stage 619 combining ES-T and ES-C process); 620 * records the complete certificate and revocation references (3); 621 * indicates the validity status to the user (4). 623 At the same time as the validation process creates the ES-C, the 624 validation process may provide and/or record the values of certificates 625 and revocation status information used in ES-C, called the ES-X Long 626 (5). This is illustrated in figure 7: 628 +---------------------------------------------------- ES-X ---------+ 629 |+--------------------------------------- ES-C --------+ +--------+ | 630 ||+--- Elect.Signature (ES) ----+ +--------+ | |Complete| | 631 |||+-------+ +-------+ +-------+|+---------+|Complete| | |certifi-| | 632 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |cate | | 633 ||||ture | |Signed | |Signa- |||over ||cate and| | |and | | 634 ||||Policy | |Attri- | |ture |||digital ||revoca- | | |revoca- | | 635 ||||ID | |butes | | |||signature||tion | | |tion | | 636 |||+-------+ +---|---+ +-------+|+---------+|referen-| | |Data | | 637 ||+--------------\--------------+ ^ |ces | | +--------+ | 638 || \ | +--------+ | ^ | 639 || \ 1 2/ ^ | | | 640 |+------------------\--------------/-----------|-------+ / | 641 +--------------------\------------/-----------/-------------/-------+ 642 \ / ---3---/ / 643 +----------+ | / / -----------5-----/ 644 | Signed |\ v | | / 645 |User data | \ +--------------------+ +-----------+ 646 +----------+ \--->| Validation Process |---> | - Valid | 647 +---|--^-------|--^--+ 4 | - Invalid | 648 | | | | +-----------+ 649 v | v | 650 +---------+ +--------+ 651 |Signature| |Trusted | 652 | Policy | |Service | 653 | Issuer | |Provider| 654 +---------+ +--------+ 656 Figure 7: Illustration ES with eXtended validation data (Long) 658 Internet Draft Electronic Signature Formats 660 When the validation process creates the ES-C it may also create 661 extended forms of validation data. A first alternative is to timestamp 662 all data forming the Type 1 X-Timestamp (6). This is illustrated in 663 figure 8: 665 +---------------------------------------------------- ES-X -------+ 666 |+--------------------------------------- ES-C --------+ +------+ | 667 ||+--- Elect.Signature (ES) ----+ +--------+ | |Time- | | 668 |||+-------+ +-------+ +-------+|+---------+|Complete| | |stamp | | 669 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |over | | 670 ||||ture | |Signed | |Signa- |||over ||cate and| | |CES | | 671 ||||Policy | |Attri- | |ture |||digital ||revoca- | | +------+ | 672 ||||ID | |butes | | |||signature||tion | | ^ | 673 |||+-------+ +--|----+ +-------+|+---------+|referen-| | | | 674 ||+-------------|---------------+ ^ |ces | | | | 675 || | | +--------+ | | | 676 || \ 1 2/ ^ | | | 677 |+----------------\------------------/---------|-------+ | | 678 +------------------\----------------/----------/-------------/----+ 679 \ / ----3--/ / 680 +----------+ | / / --------------6---/ 681 | Signed |\ v | | / 682 |User data | \ +--------------------+ +-----------+ 683 +----------+ \--->| Validation Process |---> | - Valid | 684 +---|--^-------|--^--+ 4 | - Invalid | 685 | | | | +-----------+ 686 v | v | 687 +---------+ +--------+ 688 |Signature| |Trusted | 689 | Policy | |Service | 690 | Issuer | |Provider| 691 +---------+ +--------+ 693 Figure 8: Illustration of ES with eXtended validation data - Type 1 X- 694 Timestamp 696 Internet Draft Electronic Signature Formats 698 Another alternative is to timestamp the certificate and revocation 699 information references used to validate the electronic signature (but 700 not the signature) (6'); this is called Type 2 X-Timestamped. This is 701 illustrated in figure 9: 703 +---------------------------------------------------- ES-X ----------+ 704 |+--------------------------------------- ES-C --------+ +---------+ | 705 ||+--- Elect.Signature (ES) ----+ +--------+ | |Timestamp| | 706 |||+-------+ +-------+ +-------+|+---------+|Complete| | |over | | 707 ||||Signa- | |Other | |Digital|||Timestamp||certifi-| | |Complete | | 708 ||||ture | |Signed | |Signa- |||over ||cate and| | |Certifi- | | 709 ||||Policy | |Attri- | |ture |||digital ||revoc. | | |cate and | | 710 ||||ID | |butes | | |||signature||refs | | |revoc. | | 711 |||+-------+ +---^---+ +-------+|+----^----++---^----+ | |refs | | 712 ||+--------------\--------------+ | | | +---------+ | 713 |+----------------\------------------/----------|------+ ^ | 714 +----------------1-\----------------/----------/--------------|------+ 715 \ / -----3--/ | 716 +----------+ | 2/ / --------------6'-----/ 717 | Signed |\ v | | / 718 |User data | \ +--------------------+ +-----------+ 719 +----------+ \--->| Validation Process |---> | - Valid | 720 +---|--^-------|--^--+ 4 | - Invalid | 721 | | | | +-----------+ 722 v | v | 723 +---------+ +--------+ 724 |Signature| |Trusted | 725 | Policy | |Service | 726 | Issuer | |Provider| 727 +---------+ +--------+ 729 Figure 9: Illustration of ES with eXtended validation data - Type 2 X- 730 Timestamp 732 Internet Draft Electronic Signature Formats 734 Before the algorithms used in any of electronic signatures become or 735 are likely, to be compromised or rendered vulnerable in the future, it 736 is necessary to timestamp the entire electronic signature, including 737 all the values of the validation and user data as an ES with Archive 738 validation data (ES-A) 740 An ES-A is illustrated in figure 10: 742 -------------------------------------------- ES-A --------------------+ 743 ----------------------------------------------------------------+ | 744 +------------------------------- EC-C --------++-----+ | | 745 | ||Time-| | | 746 |+-- Elect.Signature (ES) -+ +--------+||stamp| +-------+ | 747 ||+------++-------++-------|+------+|Complete|||over | Complete| | 748 |||Signa-||Other ||Digital||Time- ||certifi-|||CES | |certi- |+----| 749 |||ture ||Signed ||Signa- ||stamp ||cate and||+-----+ |ficate |Arch-| 750 |||Policy||Attri- ||ture ||over ||revoca- ||+------+ |and |ive | 751 |||ID ||butes || ||digit.||tion |||Time- | |revoca-|Time | 752 ||+------++---|---++-------||signa-||referen-|||stamp-| |tion |stamp| 753 |+------------|------------+|ture ||ces |||over | |data |+----| 754 | | +------++--------+|Complete\+-------+ ^ | 755 | | ^ ^ ||cert. | | | | 756 +-------------|----------------|---------|----+|and rev| | | | 757 \ | / |refs. | | | | 758 \ | / +-------+ | | | 759 -----------------\-------------|-------/------------------------+ | | 760 +----------+ \ | / / | 761 | Signed | \2 |3 / /--------------7-------/ | 762 |User data | \ | | / | 763 +-------\--+ \ | | / | 764 ---------\------------|--------|----|---/-----------------------------+ 765 \ v | | | 766 1\ +--------------------+ +-----------+ 767 \------>| Validation Process |---> | - Valid | 768 +---|--^-------|--^--+ 4 | - Invalid | 769 | | | | +-----------+ 770 v | v | 771 +---------+ +--------+ 772 |Signature| |Trusted | 773 | Policy | |Service | 774 | Issuer | |Provider| 775 +---------+ +--------+ 777 Figure 10: Illustration of an ES with Archive validation data (ES-A) 779 2.11 Additional optional features 781 This document also defines additional optional features to: 782 * indicate a commitment type being made by the signer; 783 * indicate the role under which a signature was created; 784 * support multiple signatures. 786 Internet Draft Electronic Signature Formats 788 3. Data structure of an Electronic Signature 790 This clause uses and builds upon the Crypographic Message Syntax (CMS), 791 as defined in RFC 2630, REF [CMS] , and Enhanced Security Services 792 (ESS), as defined in RFC 2634 [10], REF [ESS] . The overall structure 793 of Electronic Signature is as defined in [CMS]. The Electronic 794 Signature (ES) uses attributes defined in [CMS], [ESS] and 795 this document. This document defines in full the ES attributes which it 796 uses and are not defined elsewhere. 798 The mandated set of attributes and the digital signature value is 799 defined as the minimum Electronic Signature (ES) required by this 800 document. A signature policy MAY mandate other signed attributes are 801 present. 803 3.1 General Syntax 805 The general syntax of the ES is as defined in [CMS]. 807 3.2 Data Content Type 809 The data content type of the ES is as defined in [CMS]. 811 3.3 Signed-data Content Type 813 The Signed-data content type of the ES is as defined in [CMS]. 815 To make sure that the verifier uses the right signers key, this 816 document mandates that the hash of the signers certificate is always 817 included in the Signing Certificate signed attribute. 819 3.4 SignedData Type 821 The syntax of the SignedData type of the ES is as defined in [CMS]. 823 The fields of type SignedData have the meanings defined [CMS] except 824 that: 826 * version is the syntax version number. The value of version must 827 be 3. 829 * The identification of signer's certificate used to create the 830 signature is always signed. The validation policy may specify 831 requirements for the presence of certain certificates. 833 * The degenerate case where there are no signers is not valid in 834 this document. 836 Internet Draft Electronic Signature Formats 838 3.5 EncapsulatedContentInfo Type 840 The syntax of the EncapsulatedContentInfo a type of the ES is as defined 841 in [CMS]. 843 For the purpose of long term validation as defined by this document, it 844 is advisable that either the eContent is present, or the data which is 845 signed is archived in such as way as to preserve the any data encoding. 846 It is important that the OCTET STRING used to generate the signature 847 remains the same every time either the verifier or an arbitrator 848 validates the signature. 850 The degenerate case where there are no signers is not valid in this 851 document. 853 3.6 SignerInfo Type 855 The syntax of the SignerInfo a type of the ES is as defined in [CMS]. 857 Per-signer information is represented in the type SignerInfo. In the 858 case of multiple independent signatures, there is an instance 859 of this field for each signer. 861 The fields of type SignerInfo have the meanings defined in [CMS} except 862 that: 864 signedAttributes must, as a minimum, 865 contain the following attributes: 866 * ContentType as defined in clause 3.7.1. 867 * MessageDigest as defined in clause 3.7.2. 868 * SigningTime as defined in clause 3.7.3. 869 * SigningCertificate as defined in clause 3.8.1. 870 * SignaturePolicyId as defined in clause 3.9.1. 872 3.6.1 Message Digest Calculation Process 874 The message digest calculation process is as defined in [CMS]. 876 3.6.2 Message Signature Generation Process 878 The input to the digital signature generation process is as defined in 879 [CMS]. 881 3.6.3 Message Signature Verification Process 883 The procedures for CMS signed data validation are as defined in 884 [CMS] and enhanced in this document. 886 The input to the signature verification process includes the signer's 887 public key verified as correct using the ESS Signing Certificate or 888 Other Signing Certificate attribute. 890 Internet Draft Electronic Signature Formats 892 3.7 CMS Imported Mandatory Present Attributes 894 The following attributes MUST be present with the signed-data defined 895 by this document. The attributes are defined in [CMS]. 897 3.7.1 Content Type 898 The syntax of the content-type attribute type of the ES is as defined 899 in [CMS]. 901 3.7.2 Message Digest 902 The syntax of the message-digest attribute type of the ES is as defined 903 in [CMS]. 905 3.7.3 Signing Time 907 The syntax of the message-digest attribute type of the ES is as defined 908 in [CMS]and further qualified by this document. 910 The signing-time attribute type specifies the time at which the signer 911 claims to have performed the signing process. 913 This present document recommends the use of GeneralizedTime. 915 3.8 Alternative Signing Certificate Attributes 917 One, and only one, of the following two alternative attributes MUST be 918 present with the signed-data defined by this document to identify the 919 signing certificate. Both attributes include an identifier and a hash 920 of the signing certificate. The first, which is adopted in existing 921 standards, may be used if with the SHA-1 hashing algorithm. The other 922 hall be used for other hashing algorithms are to be supported. 924 The signing certificate attribute is designed to prevent the simple 925 substitution and re-issue attacks, and to allow for a restricted set of 926 authorization certificates to be used in verifying a signature. 928 3.8.1 ESS Signing Certificate Attribute Definition 930 The syntax of the signing certificate attribute type of the ES is as 931 defined in [ESS], and further qualified and profile in this document. 933 The ESS signing certificate attribute must be a signed attribute. 935 This document mandates the presence of this attribute as a signed CMS 936 attribute, and the sequence must not be empty. The certificate used to 937 verify the signature must be identified in the sequence, the Signature 938 Validation Policy may mandate other certificates be present, that may 939 include all the certificates up to the point of trust. The encoding of 940 the ESSCertID for this certificate must include the issuerSerial 941 field. 943 Internet Draft Electronic Signature Formats 945 The issuerAndSerialNumber present in the SignerInfo must be 946 consistent with issuerSerial field. The certificate identified must be 947 used during the signature verification process. If the hash of the 948 certificate does not match the certificate used to verify the 949 signature, the signature must be considered invalid. 951 The sequence of policy information field is not used in this document. 953 NOTE: Where an attribute certificate is used by the signer to associate 954 a role, or other attributes of the signer, with the electronic 955 signature this is placed in the Signer Attribute attribute as defined 956 in clause 3.12.3. 958 3.8.2 Other Signing Certificate Attribute Definition 960 The following attribute is identical to the ESS SigningCertificate 961 defined above except that this attribute can be used with hashing 962 algorithms other than SHA-1. 964 This attribute must be used in the same manner as defined above for 965 the ESS SigningCertificate attribute. 967 The following object identifier identifies the signing certificate 968 attribute: 970 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 971 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 972 smime(16) id-aa(2) 19 } 974 The signing certificate attribute value has the ASN.1 syntax 975 OtherSigningCertificate 977 OtherSigningCertificate ::= SEQUENCE { 978 certs SEQUENCE OF OtherCertID, 979 policies SEQUENCE OF PolicyInformation OPTIONAL 980 -- NOT USED IN THIS DOCUMENT 981 } 983 OtherCertID ::= SEQUENCE { 984 otherCertHash OtherHash, 985 issuerSerial IssuerSerial OPTIONAL } 987 OtherHash ::= CHOICE { 988 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 989 otherHash OtherHashAlgAndValue} 991 OtherHashValue ::= OCTET STRING 993 OtherHashAlgAndValue ::= SEQUENCE { 994 hashAlgorithm AlgorithmIdentifier, 995 hashValue OtherHashValue } 997 Internet Draft Electronic Signature Formats 999 3.9 Additional Mandatory Attributes 1001 3.9.1 Signature policy Identifier 1003 This document mandates that a reference to the signature policy, which 1004 defines the rules for creation and validation of an electronic 1005 signature, is included as a signed attribute with every signature. The 1006 signature policy identifier must be a signed attribute. 1008 The following object identifier identifies the signature policy 1009 identifier attribute: 1011 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 1012 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1013 smime(16) id-aa(2) 15 } 1015 Signature-policy-identifier attribute values have ASN.1 type 1016 SignaturePolicyIdentifier. 1017 SignaturePolicyIdentifier ::= SEQUENCE { 1018 sigPolicyIdentifier SigPolicyId, 1019 sigPolicyHash SigPolicyHash, 1020 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 1021 SigPolicyQualifierInfo OPTIONAL} 1023 The sigPolicyIdentifier field contains an object-identifier which 1024 uniquely identifies a specific version of the signature policy. The 1025 syntax of this field is as follows: 1027 SigPolicyId ::= OBJECT IDENTIFIER 1029 The sigPolicyHash field contains the identifier of the hash algorithm 1030 and the hash of the value of the signature policy. 1032 If the signature policy is defined using ASN.1 (see 6.1) the hash is 1033 calculated on the value without the outer type and length fields and 1034 the hashing algorithm must be as specified in the field 1035 signPolicyHshAlg. 1037 If the signature policy is defined using another structure, the type of 1038 structure and the hashing algorithm must be either specified as part 1039 of the signature policy, or indicated using a signature policy 1040 qualifier. 1042 SigPolicyHash ::= ETSIHashAlgAndValue 1044 Internet Draft Electronic Signature Formats 1046 A signature policy identifier may be qualified with other information 1047 about the qualifier. The semantics and syntax of the qualifier is as 1048 associated with the object-identifier in the sigPolicyQualifierId 1049 field. The general syntax of this qualifier is as follows: 1051 SigPolicyQualifierInfo ::= SEQUENCE { 1052 sigPolicyQualifierId SigPolicyQualifierId, 1053 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 1055 This document specifies the following qualifiers: 1056 * spuri: This contains the web URI or URL reference to the 1057 signature policy 1059 * spUserNotice: This contains a user notice which should be 1060 displayed whenever the signature is validated. 1062 -- sigpolicyQualifierIds defined in this document 1064 SigPolicyQualifierId ::= 1065 OBJECT IDENTIFIER 1067 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 1068 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1069 smime(16) id-spq(5) 1 } 1071 SPuri ::= IA5String 1073 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 1074 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1075 smime(16) id-spq(5) 2 } 1077 SPUserNotice ::= SEQUENCE { 1078 noticeRef NoticeReference OPTIONAL, 1079 explicitText DisplayText OPTIONAL} 1081 NoticeReference ::= SEQUENCE { 1082 organization DisplayText, 1083 noticeNumbers SEQUENCE OF INTEGER } 1085 DisplayText ::= CHOICE { 1086 visibleString VisibleString (SIZE (1..200)), 1087 bmpString BMPString (SIZE (1..200)), 1088 utf8String UTF8String (SIZE (1..200)) } 1090 Internet Draft Electronic Signature Formats 1092 3.10 CMS Imported Optional Attributes 1094 The following attributes MAY be present with the signed-data defined by 1095 this document. The attributes are defined in ref [CMS] and are imported 1096 into this specification and were appropriate qualified and profiling by 1097 this document. 1099 3.10.1 Countersignature 1101 The syntax of the countersignature attribute type of the ES is as 1102 defined in [CMS]. 1104 The countersignature attribute must be an unsigned attribute 1106 3.11 ESS Imported Optional Attributes 1108 The following attributes MAY be present with the signed-data defined by 1109 this document. The attributes are defined in ref [ESS] and are imported 1110 into this specification and were appropriate qualified and profiling by 1111 this document. 1113 3.11.1 Signed Content Reference Attribute 1115 The content reference attribute is a link from one SignedData to 1116 another. It may be used to link a reply to the original message to 1117 which it refers, or to incorporate by reference one SignedData into 1118 another. 1120 The content reference attribute MUST be used as defined in [ESS]. 1122 The content reference MUST be a signed attribute. 1124 The syntax of the content reference attribute type of the ES is as 1125 defined in [ESS]. 1127 3.11.2 Content Identifier Attribute 1129 The content identifier attribute provides an identifier for the signed 1130 content for use when reference may be later required to that content, 1131 for example in the content reference attribute in other signed data sent 1132 later. 1134 The content identifier must be a signed attribute. 1136 The syntax of the content identifier attribute type of the ES is as 1137 defined in [ESS]. 1139 The minimal signedContentIdentifier should contain a concatenation of 1140 user-specific identification information (such as a user name or public 1141 keying material identification information), a GeneralizedTime string, 1142 and a random number. 1144 Internet Draft Electronic Signature Formats 1146 3.12 Additional Optional Attributes 1148 3.12.1 Commitment Type Indication Attribute 1150 There may be situation were a signer wants to explicitly indicate to a 1151 verifier that by signing the data, it illustrates a type of commitment 1152 on behalf of the signer. The commitmentTypeIndication attribute conveys 1153 such information. 1155 The commitmentTypeIndication attribute must be a signed attribute 1157 The commitment type may be: 1159 * defined as part of the signature policy, in which case the 1160 commitment type has precise semantics that is defined as part of 1161 the signature policy. 1163 * be a registered type, in which case the commitment type has 1164 precise semantics defined by registration, under the rules of the 1165 registration authority. Such a registration authority may be a 1166 trading association or a legislative authority. 1168 The signature policy specifies a set of attributes that it 1169 "recognizes". This "recognized" set includes all those commitment types 1170 defined as part of the signature policy as well as any externally 1171 defined commitment types that the policy may choose to recognize. Only 1172 recognized commitment types are allowed in this field. 1174 The following object identifier identifies the commitment type 1175 indication attribute: 1177 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1178 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 1180 Commitment-Type-Indication attribute values have ASN.1 type 1181 CommitmentTypeIndication. 1182 CommitmentTypeIndication ::= SEQUENCE { 1183 commitmentTypeId CommitmentTypeIdentifier, 1184 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 1185 CommitmentTypeQualifier 1186 OPTIONAL} 1188 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 1190 CommitmentTypeQualifier ::= SEQUENCE { 1191 commitmentTypeIdentifier CommitmentTypeIdentifier, 1192 qualifier ANY DEFINED BY commitmentTypeIdentifier } 1194 The use of any qualifiers to the commitment type is outside the scope 1195 of this document. 1197 Internet Draft Electronic Signature Formats 1199 The following generic commitment types are defined in this document: 1200 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member- 1201 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1202 cti(6) 1} 1204 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member- 1205 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1206 cti(6) 2} 1208 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 1209 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1210 smime(16) cti(6) 3} 1212 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- 1213 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1214 cti(6) 4} 1216 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) 1217 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1218 smime(16) cti(6) 5} 1220 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) 1221 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1222 smime(16) cti(6) 6} 1224 These generic commitment types have the following meaning: 1226 Proof of origin indicates that the signer recognizes to have created, 1227 approved and sent the message. 1229 Proof of receipt indicates that signer recognizes to have received the 1230 content of the message. 1232 Proof of delivery indicates that the TSP providing that indication has 1233 delivered a message in a local store accessible to the recipient of the 1234 message. 1236 Proof of sender indicates that the entity providing that indication has 1237 sent the message (but not necessarily created it). 1239 Proof of approval indicates that the signer has approved the content of 1240 the message. 1242 Proof of creation indicates that the signer has created the message 1243 (but not necessarily approved, nor sent it). 1245 NOTE: See clause A.3 for a full description of the commitment types 1246 defined above. 1248 Internet Draft Electronic Signature Formats 1250 3.12.2 Signer Location 1252 The signer-location attribute is an attribute which specifies a 1253 mnemonic for an address associated with the signer at a particular 1254 geographical (e.g. city) location. The mnemonic is registered in the 1255 country in which the signer is located and is used in the provision of 1256 the Public Telegram Service (according to ITU-T Recommendation F.1 1257 [5?????]). 1259 The signer-location attribute must be a signed attribute. 1261 The following object identifier identifies the signer-location 1262 attribute: 1264 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1265 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 1267 Signer-location attribute values have ASN.1 type SignerLocation: 1268 SignerLocation ::= SEQUENCE { 1269 -- at least one of the following must be present 1270 countryName [0] DirectoryString OPTIONAL, 1271 -- As used to name a Country in X.500 1272 localityName [1] DirectoryString OPTIONAL, 1273 -- As used to name a locality in X.500 1274 postalAdddress [2] PostalAddress OPTIONAL } 1276 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 1278 3.12.3 Signer Attributes 1280 The signer-attributes attribute is an attribute which specifies 1281 additional attributes of the signer (e.g. role). 1283 It may be either: 1284 * claimed attributes of the signer; 1285 * certified attributes of the signer; 1286 * the signer-attribute attribute must be a signed attribute 1287 attributes. 1289 The signer-attributes attribute must be a signed attribute. 1290 The following object identifier identifies the signer-attribute 1291 attribute: 1293 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1294 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 1296 signer-attribute attribute values have ASN.1 type SignerAttribute. 1297 SignerAttribute ::= SEQUENCE OF CHOICE { 1298 claimedAttributes [0] ClaimedAttributes, 1299 certifiedAttributes [1] CertifiedAttributes } 1301 Internet Draft Electronic Signature Formats 1303 ClaimedAttributes ::= SEQUENCE OF Attribute 1305 CertifiedAttributes ::= AttributeCertificate 1306 -- As defined in X.509 : see section 10.3 1308 NOTE: The claimed and certified attribute are imported from ITU-T 1309 Recommendations X.501 [16] and ITU-T Recommendation X.509 : Draft 1310 Amendment on Certificate Extensions, October 1999. 1312 3.12.3 Content Timestamp 1314 The content timestamp attribute is an attribute which is the timestamp 1315 of the signed data content before it is signed. 1317 The content timestamp attribute must be a signed attribute. 1318 The following object identifier identifies the signer-attribute 1319 attribute: 1321 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) 1322 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1323 smime(16) id-aa(2) 20} 1325 Content timestamp attribute values have ASN.1 type ContentTimestamp: 1326 ContentTimestamp::= TimeStampToken 1328 The value of messageImprint field within TimeStampToken must be a hash 1329 of the value of eContent field within encapContentInfo within the 1330 signedData. 1332 For further information and definition of TimeStampToken see ref .. temp 1333 note; need to add the reference to the timestamping RFC. 1335 3.13 Support for Multiple Signatures 1337 3.13.1 Independent Signatures 1339 Multiple independent signatures (see clause 55) are supported by 1340 independent SignerInfo from each signer. 1342 Each SignerInfo must include all the attributes required under this 1343 document and must be processed independently by the verifier. 1345 3.13.2 Embedded Signatures 1347 Multiple embedded signatures (see clause B.6) are supported using the 1348 counter-signature unsigned attribute (see clause 10.1). Each counter 1349 signature is carried in Countersignature held as an unsigned attribute 1350 to the SignerInfo to which the counter-signature is applied. 1352 Internet Draft Electronic Signature Formats 1354 4. Validation Data 1356 This clause specifies the validation data structures which builds on 1357 the electronic signature specified in clause 3. This includes: 1359 * Timestamp applied to the electronic signature value. 1361 * Complete validation data which comprises the timestamp of the 1362 signature value, plus references to all the certificates and 1363 revocation information used for full validation of the electronic 1364 signature. 1366 The following optional eXtended forms of validation data are also 1367 defined: 1369 * X-timestamp: There are two types of timestamp used in extended 1370 validation data defined by this document. 1372 - Type 1 -Timestamp which comprises a timestamp over the ES 1373 with Complete validation data (ES-C). 1375 - Type 2 X-Timestamp which comprises of a timestamp over the 1376 certification path references and the revocation information 1377 references used to support the ES-C. 1379 * X-Long : This comprises a Complete validation data 1380 plus the actual values of all the certificates and 1381 revocation information used in the ES-C. 1383 * X-Long-Timestamp: This comprises a Type 1 or Type 2 1384 X-Timestamp plus the actual values of all the 1385 certificates and revocation information used in the 1386 ES-C. 1388 This clause also specifies the data structures used in Archive 1389 validation data: 1391 * Archive validation data comprises a Complete validation data, 1392 the certificate and revocation values (as in a X-Long 1393 validation data), any other existing X-timestamps, plus the 1394 Signed User data and an additional archive timestamp over all 1395 that data. An archive timestamp may be repeatedly applied 1396 after long periods to maintain validity when electronic 1397 signature and timestamping algorithms weaken. 1399 The additional data required to create the forms of electronic 1400 signature identified above is carried as unsigned attributes associated 1401 with an individual signature by being placed in the unsignedAttrs field 1402 of SignerInfo (see clause 6????). Thus all the attributes defined in 1403 clause 9?? are unsigned attributes. 1405 Internet Draft Electronic Signature Formats 1407 NOTE: Where multiple signatures are to be supported, as described in 1408 clause 3.13, each signature has a separate SignerInfo. Thus, each 1409 signature requires its own unsigned attribute values to create ES-T, 1410 ES-C etc. 1412 4.1 Electronic Signature Timestamp 1414 An Electronic Signature with Timestamp is an Electronic Signature for 1415 which part, but not all, of the additional data required for validation 1416 is available (i.e. some certificates and revocation information is 1417 available but not all). The minimum structure Timestamp validation data 1418 is: 1419 * The Signature Timestamp Attribute as defined in clause 4.1.1 1420 over the ES signature value. 1422 4.1.1 Signature Timestamp Attribute Definition 1424 The Signature Timestamp attribute is timestamp of the signature value. 1425 It is an unsigned attribute. Several instances of this attribute may 1426 occur with an electronic signature, from different TSAs. 1428 The Signature Validation Policy specifies, in the 1429 signatureTimestampDelay field of TimestampTrustConditions, an maximum 1430 acceptable time difference which is allowed between the time indicated 1431 in the signing time attribute and the time indicated by the Signature 1432 Timestamp attribute. If this delay is exceeded then the electronic 1433 signature must be considered as invalid. 1435 The following object identifier identifies the Signature Timestamp 1436 attribute: 1438 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 1439 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 1440 id-aa(2) 14} 1442 The Signature timestamp attribute value has ASN.1 type 1443 SignatureTimeStampToken: 1445 SignatureTimeStampToken ::= TimeStampToken 1447 The value of messageImprint field within TimeStampToken must be a hash 1448 of the value of signature field within SignerInfo for the signedData 1449 being timestamped. 1451 For further information and definition of TimeStampToken see [TSP] 1452 Temp note ;ref to timestamping doc required 1454 Internet Draft Electronic Signature Formats 1456 4.2 Complete Validation Data 1458 An electronic signature with complete validation data is an Electronic 1459 Signature for which all the additional data required for validation 1460 (i.e. all certificates and revocation information) is available. 1461 Complete validation data (ES-C) build on the electronic signature 1462 Timestamp as defined above. 1464 The minimum structure of a Complete validation data is: 1465 * the Signature Timestamp Attribute, as defined in clause 4.1.1; 1466 * Complete Certificate Refs, as defined in clause 4.2.1; 1467 * Complete Revocation Refs, as defined in clause 4.2.2. 1469 The Complete validation data MAY also include the following additional 1470 information, forming a X-Long validation data, for use if later 1471 validation processes may not have access to this information: 1473 * Complete Certificate Values, as defined in clause 4.2.3; 1475 * Complete Revocation Values, as defined in clause 4.2.4. 1477 The Complete validation data MAY also include one of the following 1478 additional attributes, forming a X-Timestamp validation data, to 1479 provide additional protection against later CA compromise and provide 1480 integrity of the validation data used: 1482 * ES-C Timestamp, as defined in clause 4.2.5; or 1484 * Time-Stamped Certificates and CRLs references, as defined in 1485 clause 4.2.6. 1487 NOTE 1: As long as the CA's are trusted such that these keys cannot 1488 be compromised or the cryptography used broken, the ES-C provides long 1489 term proof of a valid electronic signature. 1491 A valid electronic signature is an electronic signature which passes 1492 validation according to a signature validation policy. 1494 NOTE 2: The ES-C provides the following important property for long 1495 standing signatures; that is having been found once to be valid, must 1496 continue to be so months or years later. Long after the validity period 1497 of the certificates have expired, or after the user key has been 1498 compromised. 1500 4.2.1 Complete Certificate Refs Attribute Definition 1502 The Complete Certificate Refs attribute is an unsigned attribute. It 1503 references the full set of CA certificates that have been used to 1504 validate a ES with Complete validation data (ES-C) up to (but not 1505 including) the signer's certificate. Only a single instance of this 1506 attribute must occur with an electronic signature. 1508 Internet Draft Electronic Signature Formats 1510 Note: The signer's certified is referenced in the signing certificate 1511 attribute (see clause 3.1). 1513 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1514 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 1516 The complete certificate refs attribute value has the ASN.1 syntax 1517 CompleteCertificateRefs. 1519 CompleteCertificateRefs ::= SEQUENCE OF ETSICertID 1521 ETSICertID is defined in clause 3.8.2. 1523 The IssuerSerial that must be present in ETSICertID. The certHash 1524 must match the hash of the certificate referenced. 1526 NOTE: Copies of the certificate values may be held using the 1527 Certificate Values attribute defined in clause 4.3.1. 1529 4.2.2 Complete Revocation Refs Attribute Definition 1531 The Complete Revocation Refs attribute is an unsigned attribute. Only a 1532 single instance of this attribute must occur with an electronic 1533 signature. It references the full set of the CRL or OCSP responses that 1534 have been used in the validation of the signer and CA certificates 1535 used in ES with Complete validation data. 1537 The following object identifier identifies the CompleteRevocationRefs 1538 attribute: 1540 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1541 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 1543 The complete revocation refs attribute value has the ASN.1 syntax 1544 CompleteRevocationRefs 1545 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 1547 CrlOcspRef ::= SEQUENCE { 1548 crlids [0] CRLListID OPTIONAL, 1549 ocspids [1] OcspListID OPTIONAL, 1550 otherRev [2] OtherRevRefs OPTIONAL 1551 } 1553 Internet Draft Electronic Signature Formats 1555 CompleteRevocationRefs must contain one CrlOcspRef for the signing 1556 certificate, followed by one for each ETSICertID in the 1557 CompleteCertificateRefs attribute. the second and subsequent CrlOcspRef 1558 fields must be in the same order as the ETSICertID to which they 1559 relate. At least one of CRLListID or OcspListID or OtherRevRefs should 1560 be present for all but the "trusted" CA of the certificate path. 1562 CRLListID ::= SEQUENCE { 1563 crls SEQUENCE OF CrlValidatedID} 1565 CrlValidatedID ::= SEQUENCE { 1566 crlHash ETSIHash, 1567 crlIdentifier CrlIdentifier OPTIONAL} 1569 CrlIdentifier ::= SEQUENCE { 1570 crlissuer Name, 1571 crlIssuedTime UTCTime, 1572 crlNumber INTEGER OPTIONAL 1573 } 1575 OcspListID ::= SEQUENCE { 1576 ocspResponses SEQUENCE OF OcspResponsesID} 1578 OcspResponsesID ::= SEQUENCE { 1579 ocspIdentifier OcspIdentifier, 1580 ocspRepHash ETSIHash OPTIONAL 1581 } 1583 OcspIdentifier ::= SEQUENCE { 1584 ocspResponderID ResponderID, 1585 -- As in OCSP response data 1586 producedAt GeneralizedTime 1587 -- As in OCSP response data 1588 } 1590 When creating an crlValidatedID, the crlHash is computed over the 1591 entire DER encoded CRL including the signature. The crlIdentifier would 1592 normally be present unless the CRL can be inferred from other 1593 information. 1595 The crlIdentifier is to identify the CRL using the issuer name and the 1596 CRL issued time which must correspond to the time "thisUpdate" 1597 contained in the issued CRL. The crlListID attribute is an unsigned 1598 attribute. In the case that the identified CRL is a Delta CRL then 1599 references to the set of CRLs to provide a complete revocation list 1600 must be included. 1602 The OcspIdentifier is to identify the OSCP response using the issuer 1603 name and the time of issue of the OCSP response which must correspond 1604 to the time "producedAt" contained in the issued OCSP response. Since 1605 it may be needed to make the difference between two OCSP responses 1606 received within the same second, then the hash of the response contained 1607 in the OcspResponsesID may be needed to solve the ambiguity. 1609 Internet Draft Electronic Signature Formats 1611 NOTE: Copies of the CRL and OCSP responses values may be held using the 1612 Revocation Values attribute defined in clause 4.3.2. 1614 OtherRevRefs ::= SEQUENCE { 1615 otherRevRefType OtherRevRefType, 1616 otherRevRefs ANY DEFINED BY otherRevRefType 1617 } 1619 OtherRevRefType ::= OBJECT IDENTIFIER 1621 The syntax and semantics of other revocation references is outside the 1622 scope of this document. The definition of the syntax of the other form 1623 of revocation information is as identified by OtherRevRefType. 1625 4.3 Extended Validation Data 1627 4.3.1 Certificate Values Attribute Definition 1629 The Certificate Values attribute is an unsigned attribute. Only a 1630 single instance of this attribute must occur with an electronic 1631 signature. It holds the values of certificates referenced in the 1632 CompleteCertificateRefs attribute. 1634 Note: If an Attribute Certificate is used, it is not provided in this 1635 structure but must be provided by the signer as a signer-attributes 1636 attribute (see clause 12.3). 1638 The following object identifier identifies the CertificateValues 1639 attribute: 1641 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1642 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 1644 The certificate values attribute value has the ASN.1 syntax 1645 CertificateValues 1646 CertificateValues ::= SEQUENCE OF Certificate 1648 Certificate is defined in clause 10.1 (which is as defined in ITU-T 1649 Recommendation X.509 [1]) 1651 Internet Draft Electronic Signature Formats 1653 4.3.2 Revocation Values Attribute Definition 1655 The Revocation Values attribute is an unsigned attribute. Only a single 1656 instance of this attribute must occur with an electronic signature. 1657 It holds the values of CRLs and OCSP referenced in the 1658 CompleteRevocationRefs attribute. 1660 The following object identifier identifies the CertificateValues 1661 attribute: 1663 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- 1664 body(2) 1665 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24} 1667 The revocation values attribute value has the ASN.1 syntax 1668 RevocationValues 1669 RevocationValues ::= SEQUENCE { 1670 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 1671 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 1672 otherRevVals [2] OtherRevVals } 1674 OtherRevVals ::= SEQUENCE { 1675 otherRevValType OtherRevValType, 1676 otherRevVals ANY DEFINED BY otherRevValType 1677 } 1679 OtherRevValType ::= OBJECT IDENTIFIER 1681 The syntax and semantics of the other revocation values is outside the 1682 scope of this document. The definition of the syntax of the other form 1683 of revocation information is as identified by OtherRevRefType. 1685 CertificateList is defined in clause 10.2 (which as defined in ITU-T 1686 Recommendation X.509 [1]). 1688 BasicOCSPResponse is defined in clause 10.3 (which as defined in ??? RFC 1689 2560 [8] ???). 1691 4.3.3 ES-C Timestamp Attribute Definition 1693 This attribute is used for the Type 1 X-Timestamped validation data. 1694 The ES-C Timestamp attribute is an unsigned attribute. It is timestamp 1695 of a hash of the electronic signature and the complete validation data 1696 (ES-C). It is a special purpose TimeStampToken Attribute which 1697 timestamps the ES-C. Several instances instance of this attribute may 1698 occur with an electronic signature from different TSAs. 1700 The following object identifier identifies the ES-C Timestamp 1701 attribute: 1703 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1704 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 1706 Internet Draft Electronic Signature Formats 1708 The ES-C timestamp attribute value has the ASN.1 syntax 1709 ESCTimeStampToken. 1711 ESCTimeStampToken ::= TimeStampToken 1713 The value of messageImprint field within TimeStampToken must be a hash 1714 of the concatenated values (without the type or length encoding for 1715 that value) of the following data objects as present in the ES with 1716 Complete validation data (ES-C): 1718 * signature field within SignerInfo; 1720 * SignatureTimeStampToken attribute; 1722 * CompleteCertificateRefs attribute; 1724 * CompleteRevocationRefs attribute. 1726 For further information and definition of the Time Stamp Token see 1727 clause [TSP]. 1728 Temp note ;ref to timestamping doc required. 1730 4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 1732 This attribute is used for the Type 2 X-Timestamp validation data. A 1733 TimestampedCertsCRLsRef attribute is an unsigned attribute. It is a 1734 list of referenced certificates and OCSP responses/CRLs which are been 1735 timestamped to protect against certain CA compromises. Its syntax is as 1736 follows: 1738 The following object identifier identifies the TimestampedCertsCRLsRef 1739 attribute: 1741 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 1742 body(2) 1743 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} 1745 The attribute value has the ASN.1 syntax TimestampedCertsCRLs. 1747 TimestampedCertsCRLs ::= TimeStampToken 1749 The value of messageImprint field within TimeStampToken must be a hash 1750 of the concatenated values (without the type or length encoding for 1751 that value) of the following data objects as present in the ES with 1752 Complete validation data (ES-C): 1754 * CompleteCertificateRefs attribute; 1755 * CompleteRevocationRefs attribute. 1757 Internet Draft Electronic Signature Formats 1759 4.4 Archive Validation Data 1761 Where an electronic signature is required to last for a very long time, 1762 and a the timestamp on an electronic signature is in danger of being 1763 invalidated due to algorithm weakness or limits in the validity period 1764 of the TSA certificate, then it may be required to timestamp the 1765 electronic signature several times. When this is required an archive 1766 timestamp attribute may be required. This timestamp may be repeatedly 1767 applied over a period of time. 1769 4.4.1 Archive Timestamp Attribute Definition 1771 The Archive Timestamp attribute is timestamp of the user data and the 1772 entire electronic signature. If the Certificate values and Revocation 1773 Values attributes are not present these attributes must be added to 1774 the electronic signature prior to the timestamp. The Archive Timestamp 1775 attribute is an unsigned attribute. Several instances of this attribute 1776 may occur with on electronic signature both over time and from 1777 different TSAs. 1779 The following object identifier identifies the Nested Archive Timestamp 1780 attribute: 1782 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 1783 body(2) 1784 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27} 1786 Archive timestamp attribute values have the ASN.1 syntax 1787 ArchiveTimeStampToken 1789 ArchiveTimeStampToken ::= TimeStampToken 1791 The value of messageImprint field within TimeStampToken must be a hash 1792 of the concatenated values (without the type or length encoding for 1793 that value) of the following data objects as present in the electronic 1794 signature: 1796 * encapContentInfo eContent OCTET STRING; 1797 * signedAttributes; 1798 * signature field within SignerInfo; 1799 * SignatureTimeStampToken attribute; 1800 * CompleteCertificateRefs attribute; 1801 * CompleteRevocationData attribute; 1802 * CertificateValues attribute 1803 (If not already present this information must be included in the 1804 ES-A); 1805 * RevocationValues attribute 1806 (If not already present this information must be included in the 1807 ES-A); 1808 * ESCTimeStampToken attribute if present; 1809 * TimestampedCertsCRLs attribute if present; 1810 * any previous ArchiveTimeStampToken attributes. 1812 Internet Draft Electronic Signature Formats 1814 For further information and definition of TimeStampToken see see [TSP] 1815 Temp note ;ref to timestamping doc required 1817 The timestamp should be created using stronger algorithms (or longer 1818 key lengths) than in the original electronic signatures and weak 1819 algorithm (key length) timestamps . 1821 5. Signature Policy Specification 1823 This document mandates that: 1824 * an electronic signature must be processed by the signer and 1825 verifier in accordance with the signature policy as identified 1826 by the signature policy attribute (see clause 4.1); 1827 * the signature policy must be identifiable by an Object 1828 Identifier; 1829 * there must exist a specification of the signature policy; 1830 * for a given signature policy there must be one definitive form 1831 of the specification which has a unique binary encoding; 1832 * a hash of the definitive specification, using an agreed 1833 algorithm, must be provided by the signer and checked by the 1834 verifier (see clause 4.1). 1836 A signature policy specification includes general information about the 1837 policy, the validation policy rules and other signature policy 1838 information. 1840 Clause 6 describes the kind of information to be included in a 1841 signature policy. 1843 The current document does not mandate the form of the signature policy 1844 specification. The signature policy may be specified either: 1846 * in a free form document for human interpretation; or 1847 * in a structured form using an agreed syntax and encoding. 1849 This document defines an ASN.1 based syntax that may be used to define 1850 a structured signature policy. 1852 5.1 Overall ASN.1 Structure 1854 The overall structure of a signature policy defined using ASN.1 is 1855 given in this clause. Use of this ASN.1 structure is optional. 1857 This ASN.1 syntax is encoded using the Distinguished Encoding Rules 1858 (DER). 1860 Internet Draft Electronic Signature Formats 1862 In this structure the policy information is preceded by an identifier 1863 for the hashing algorithm used to protect the signature policy and 1864 followed by the hash value which must be re-calculated and checked 1865 whenever the policy is passed between the issuer and signer/verifier. 1866 The hash is calculated without the outer type and length fields. 1868 SignaturePolicy ::= SEQUENCE { 1869 signPolicyHashAlg AlgorithmIdentifier, 1870 signPolicyInfo SignPolicyInfo, 1871 signPolicyHash SignPolicyHash OPTIONAL } 1873 SignPolicyHash ::= OCTET STRING 1875 SignPolicyInfo ::= SEQUENCE { 1876 signPolicyIdentifier SignPolicyId, 1877 dateOfIssue GeneralizedTime, 1878 policyIssuerName PolicyIssuerName, 1879 fieldOfApplication FieldOfApplication, 1880 signatureValidationPolicy SignatureValidationPolicy, 1881 signPolExtensions SignPolExtensions 1882 OPTIONAL 1883 } 1885 SignPolicyId ::= OBJECT IDENTIFIER 1887 The policyIssuerName field identifies the policy issuer in one or more 1888 of the general name forms. 1890 PolicyIssuerName ::= GeneralNames 1892 The fieldofApplication is a description of the expected application of 1893 this policy. 1895 FieldOfApplication ::= DirectoryString 1897 The signature validation policy rules are fully processable to allow 1898 the validation of electronic signatures issued under that signature 1899 policy. They are described in the rest of this clause. 1901 5.2 Signature Validation Policy 1903 The signature validation policy defines for the signer which data 1904 elements must be present in the electronic signature he provides and 1905 for the verifier which data elements must be present under that 1906 signature policy for an electronic signature to be potentially valid. 1908 Internet Draft Electronic Signature Formats 1910 The signature validation policy is described as follows: 1912 SignatureValidationPolicy ::= SEQUENCE { 1913 signingPeriod SigningPeriod, 1914 commonRules CommonRules, 1915 commitmentRules CommitmentRules, 1916 signPolExtensions SignPolExtensions OPTIONAL 1917 } 1919 The signingPeriod identifies the date and time before which the 1920 signature policy should not be used for creating signatures, and an 1921 optional date after which it should not be used for creating 1922 signatures. 1924 SigningPeriod ::= SEQUENCE { 1925 notBefore GeneralizedTime, 1926 notAfter GeneralizedTime OPTIONAL } 1928 5.3 Common Rules 1930 The CommonRules define rules that are common to all commitment types. 1931 These rules are defined in terms of trust conditions for certificates, 1932 timestamps and attributes, along with any constraints on attributes 1933 that may be included in the electronic signature. 1935 CommonRules ::= SEQUENCE { 1936 signerAndVeriferRules [0] SignerAndVerifierRules 1937 OPTIONAL, 1938 signingCertTrustCondition [1] SigningCertTrustCondition 1939 OPTIONAL, 1940 timeStampTrustCondition [2] TimestampTrustCondition 1941 OPTIONAL, 1942 attributeTrustCondition [3] AttributeTrustCondition 1943 OPTIONAL, 1944 algorithmConstraintSet [4] AlgorithmConstraintSet 1945 OPTIONAL, 1946 signPolExtensions [5] SignPolExtensions 1947 OPTIONAL 1948 } 1950 If a field is present in CommonRules then the equivalent field must 1951 not be present in any of the CommitmentRules (see below). If any of the 1952 following fields are not present in CommonRules then it must be 1953 present in each CommitmentRule: 1955 * signerAndVeriferRules; 1956 * signingCertTrustCondition; 1957 * timeStampTrustCondition. 1959 Internet Draft Electronic Signature Formats 1961 5.4 Commitment Rules 1963 The CommitmentRules consists of the validation rules which apply to 1964 given commitment types: 1966 CommitmentRules ::= SEQUENCE OF CommitmentRule 1968 The CommitmentRule for given commitment types are defined in terms of 1969 trust conditions for certificates, timestamps and attributes, along 1970 with any constraints on attributes that may be included in the 1971 electronic signature. 1973 CommitmentRule ::= SEQUENCE { 1974 selCommitmentTypes SelectedCommitmentTypes, 1975 signerAndVeriferRules [0] SignerAndVerifierRules 1976 OPTIONAL, 1977 signingCertTrustCondition [1] SigningCertTrustCondition 1978 OPTIONAL, 1979 timeStampTrustCondition [2] TimestampTrustCondition 1980 OPTIONAL, 1981 attributeTrustCondition [3] AttributeTrustCondition 1982 OPTIONAL, 1983 algorithmConstraintSet [4] AlgorithmConstraintSet 1984 OPTIONAL, 1985 signPolExtensions [5] SignPolExtensions 1986 OPTIONAL 1987 } 1989 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 1990 empty NULL, 1991 recognizedCommitmentType CommitmentType } 1993 If the SelectedCommitmentTypes indicates "empty" then this rule applied 1994 when a commitment type is not present (i.e.the type of commitment is 1995 indicated in the semantics of the message). Otherwise, the electronic 1996 signature must contain a commitment type indication that must fit one 1997 of the commitments types that are mentioned in CommitmentType. 1999 A specific commitment type identifier must not appear in more than one 2000 commitment rule. 2002 CommitmentType ::= SEQUENCE { 2003 identifier CommitmentTypeIdentifier, 2004 fieldOfApplication [0] FieldOfApplication OPTIONAL, 2005 semantics [1] DirectoryString OPTIONAL } 2007 The fieldOfApplication and semantics fields define the specific use and 2008 meaning of the commitment within the overall field of application 2009 defined for the policy. 2011 Internet Draft Electronic Signature Formats 2013 5.5 Signer and Verifier Rules 2015 The SignerAndVerifierRules consists of signer rule and verification 2016 rules as defined below: 2017 SignerAndVerifierRules ::= SEQUENCE { 2018 signerRules SignerRules, 2019 verifierRules VerifierRules } 2021 5.5.1 Signer Rules 2023 The signer rules identify: 2025 * if the eContent is empty and the signature is calculated using 2026 a hash of signed data external to CMS structure. 2028 * the CMS signed attributes that must be provided by the signer 2029 under this policy; 2031 * the CMS unsigned attribute that must be provided by the signer 2032 under this policy; 2034 * whether the certificate identifiers from the full certification 2035 path up to the trust point must be provided by the signer in 2036 the SigningCertificate attribute; 2038 * whether a signer's certificate, or all certificates in the 2039 certification path to the trust point must be provided by the 2040 signer in the certificates field of SignedData. 2042 SignerRules ::= SEQUENCE { 2043 externalSignedData BOOLEAN OPTIONAL, 2044 -- True if signed data is external to CMS structure 2045 -- False if signed data part of CMS structure 2046 -- not present if either allowed 2047 mandatedSignedAttr CMSAttrs, 2048 -- Mandated CMS signed attributes 2049 mandatedUnsignedAttr CMSAttrs, 2050 -- Mandated CMS unsigned attributed 2051 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 2052 -- Mandated Certificate Reference 2053 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 2054 -- Mandated Certificate Info 2055 signPolExtensions [2] SignPolExtensions OPTIONAL 2056 } 2058 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 2060 The mandatedSignedAttr field must include the object identifier for 2061 all those signed attributes required by this document as well as 2062 additional attributes required by this policy. 2064 Internet Draft Electronic Signature Formats 2066 The mandatedUnsignedAttr field must include the object identifier for 2067 all those unsigned attributes required by this document as well as 2068 additional attributes required this policy. For example, if a signature 2069 timestamp (see clause 1.1) is required by the signer the object 2070 identifier for this attribute must be included. 2072 The mandatedCertificateRef identifies whether just the signer's 2073 certificate, or all the full certificate path must be provided by the 2074 signer. 2076 CertRefReq ::= ENUMERATED { 2077 signerOnly (1), 2078 -- Only reference to signer cert mandated 2079 fullPath (2) 2081 -- References for full cert path up to a trust point required 2082 } 2084 The mandatedCertificateInfo field identifies whether a signer's 2085 certificate, or all certificates in the certification path to the trust 2086 point must be provided by the signer in the certificates field of 2087 SignedData. 2089 CertInfoReq ::= ENUMERATED { 2090 none (0) , 2091 -- No mandatory requirements 2092 signerOnly (1) , 2093 -- Only reference to signer cert mandated 2094 fullPath (2) 2095 -- References for full cert path up to a 2096 -- trust point mandated 2097 } 2099 5.5.2 Verifier Rules 2101 The verifier rules identify: 2102 * The CMS unsigned attributes that must be present under this policy 2103 and must be added by the verifier if not added by the signer. 2105 VerifierRules ::= SEQUENCE { 2106 mandatedUnsignedAttr MandatedUnsignedAttr, 2107 signPolExtensions SignPolExtensions OPTIONAL 2108 } 2110 MandatedUnsignedAttr ::= CMSAttrs 2111 -- Mandated CMS unsigned attributed 2113 Internet Draft Electronic Signature Formats 2115 5.6 Certificate and Revocation Requirement 2117 The SigningCertTrustCondition, TimestampTrustCondition and 2118 AttributeTrustCondition (defined in subsequent sub-clauses) make use of 2119 two ASN1 structures which are defined below: CertificateTrustTrees and 2120 CertRevReq. 2122 5.6.1 Certificate Requirements 2124 The certificateTrustTrees identifies a set of self signed certificates 2125 for the trust points used to start (or end) certificate path processing 2126 and the initial conditions for certificate path validation as defined 2127 RFC 2459 [7] section 5. This ASN1 structure is used to define policy 2128 for validating the signing certificate, the TSA's certificate and 2129 attribute certificates. 2131 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 2133 CertificateTrustPoint ::= SEQUENCE { 2134 trustpoint Certificate, 2135 -- self-signed certificate 2136 pathLenConstraint [0] PathLenConstraint OPTIONAL, 2137 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 2138 -- If not present "any policy" 2139 nameConstraints [2] NameConstraints OPTIONAL, 2140 policyConstraints [3] PolicyConstraints OPTIONAL } 2142 The trustPoint field gives the self signed certificate for the CA that 2143 is used as the trust point for the start of certificate path 2144 processing. 2146 The pathLenConstraint field gives the maximum number of CA certificates 2147 that may be in a certification path following the trustpoint. A value 2148 of zero indicates that only the given trustpoint certificate and an 2149 end-entity certificate may be used. If present, the pathLenConstraint 2150 field must be greater than or equal to zero. Where pathLenConstraint 2151 is not present, there is no limit to the allowed length of the 2152 certification path. 2154 PathLenConstraint ::= INTEGER (0..MAX) 2156 The acceptablePolicySet field identifies the initial set of certificate 2157 policies, any of which are acceptable under the signature policy. 2158 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 2160 CertPolicyId ::= OBJECT IDENTIFIER 2162 Internet Draft Electronic Signature Formats 2164 The nameConstraints field indicates a name space within which all 2165 subject names in subsequent certificates in a certification path must 2166 be located. Restrictions may apply to the subject distinguished name or 2167 subject alternative names. Restrictions apply only when the specified 2168 name form is present. If no name of the type is in the certificate, the 2169 certificate is acceptable. 2171 Restrictions are defined in terms of permitted or excluded name 2172 subtrees. Any name matching a restriction in the excludedSubtrees field 2173 is invalid regardless of information appearing in the ermittedSubtrees. 2175 NameConstraints ::= SEQUENCE { 2176 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 2177 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 2179 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 2181 GeneralSubtree ::= SEQUENCE { 2182 base GeneralName, 2183 minimum [0] BaseDistance DEFAULT 0, 2184 maximum [1] BaseDistance OPTIONAL } 2186 BaseDistance ::= INTEGER (0..MAX) 2188 The policyConstraints extension constrains path processing in two ways. 2189 It can be used to prohibit policy mapping or require that each 2190 certificate in a path contain an acceptable policy identifier. 2192 The policyConstraints field, if present specifies requirement for 2193 explicit indication of the certificate policy and/or the constraints on 2194 policy mapping. 2196 PolicyConstraints ::= SEQUENCE { 2197 requireExplicitPolicy [0] SkipCerts OPTIONAL, 2198 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 2200 SkipCerts ::= INTEGER (0..MAX) 2202 If the inhibitPolicyMapping field is present, the value indicates the 2203 number of additional certificates that may appear in the path 2204 (including the trustpoint's self certificate) before policy mapping is 2205 no longer permitted. For example, a value of one indicates that policy 2206 mapping may be processed in certificates issued by the subject of this 2207 certificate, but not in additional certificates in the path. 2209 If the requireExplicitPolicy field is present, subsequent certificates 2210 must include an acceptable policy identifier. The value of 2211 requireExplicitPolicy indicates the number of additional certificates 2212 that may appear in the path (including the trustpoint's self 2213 certificate) before an explicit policy is required. An acceptable 2214 policy identifier is the identifier of a policy required by the user of 2215 the certification path or the identifier of a policy which has been 2216 declared equivalent through policy mapping. 2218 Internet Draft Electronic Signature Formats 2220 5.6.2 Revocation Requirements 2222 The RevocRequirements field specifies minimum requirements for 2223 revocation information, obtained through CRLs and/or OCSP responses, to 2224 be used in checking the revocation status of certificates. This ASN1 2225 structure is used to define policy for validating the signing 2226 certificate, the TSA's certificate and attribute certificates. 2228 CertRevReq ::= SEQUENCE { 2229 endCertRevReq RevReq, 2230 caCerts [0] RevReq 2231 } 2233 Certificate revocation requirements are specified in terms of checks 2234 required on: 2235 * endCertRevReq: end certificates (i.e. the signers certificate, 2236 the attribute certificate or the timestamping authority 2237 certificate). 2239 * caCerts: CA certificates. 2241 RevReq ::= SEQUENCE { 2242 enuRevReq EnuRevReq, 2243 exRevReq SignPolExtensions OPTIONAL} 2245 An authority certificate is certificate issued to an authority (e.g. 2246 either to a certification authority or to an attribute authority (AA)). 2248 A TimeStamping Authority (TSA) is a trusted third party that creates 2249 time stamp tokens in order to indicate that a datum existed at a 2250 particular point in time (RFC??: "Internet X.509 Public Key 2251 Infrastructure - Time Stamp Protocol"). 2253 EnuRevReq ::= ENUMERATED { 2254 clrCheck (0), 2255 --Checks must be made against current CRLs 2256 -- (or authority revocation lists (ARL)) 2257 ocspCheck (1), -- The revocation status must be checked 2258 -- using the Online Certificate Status Protocol 2259 -- (OCSP),RFC 2450. 2260 bothCheck (2), 2261 -- Both CRL and OCSP checks must be carried out 2262 eitherCheck (3), 2263 -- At least one of CRL or OCSP checks must be 2264 -- carried out 2265 noCheck (4), 2266 -- no check is mandated 2267 other (5) 2268 -- Other mechanism as defined by signature poilicy 2269 -- extension 2270 } 2272 Internet Draft Electronic Signature Formats 2274 Revocation requirements are specified in terms of: 2275 * clrCheck: Checks must be made against current CRLs (or 2276 authority revocation lists); 2277 * ocspCheck: The revocation status must be checked using the 2278 Online Certificate Status Protocol (RFC 2450); 2279 * bothCheck: Both OCSP and CRL checks must be carried out; 2280 * eitherCheck: Either OCSP or CRL checks must be carried out; 2281 * noCheck: No check is mandated. 2283 5.7 Signing Certificate Trust Conditions 2285 The SigningCertTrustCondition field identifies trust conditions for 2286 certificate path processing used to validate the signing certificate. 2288 SigningCertTrustCondition ::= SEQUENCE { 2289 signerTrustTrees CertificateTrustTrees, 2290 signerRevReq CertRevReq 2291 } 2293 5.8 TimeStamp Trust Conditions 2295 The TimeStampTrustCondition field identifies trust conditions for 2296 certificate path processing used to authenticate the timstamping 2297 authority and constraints on the name of the timestamping authority. 2298 This applies to the timestamp that must be present in every ES-T. 2300 TimestampTrustCondition ::= SEQUENCE { 2301 ttsCertificateTrustTrees [0] CertificateTrustTrees 2302 OPTIONAL, 2303 ttsRevReq [1] CertRevReq 2304 OPTIONAL, 2305 ttsNameConstraints [2] NameConstraints 2306 OPTIONAL, 2307 cautionPeriod [3] DeltaTime 2308 OPTIONAL, 2309 signatureTimestampDelay [4] DeltaTime 2310 OPTIONAL } 2312 DeltaTime ::= SEQUENCE { 2313 deltaSeconds INTEGER, 2314 deltaMinutes INTEGER, 2315 deltaHours INTEGER, 2316 deltaDays INTEGER } 2318 If ttsCertificateTrustTrees is not present then the same rule as 2319 defined in certificateTrustCondition applies to certification of the 2320 timestamping authorities public key. 2322 Internet Draft Electronic Signature Formats 2324 The tstrRevReq specifies minimum requirements for revocation 2325 information, obtained through CRLs and/or OCSP responses, to be used in 2326 checking the revocation status of the time stamp that must be present 2327 in the ES-T. 2329 If ttsNameConstraints is not present then there are no additional 2330 naming constraints on the trusted timestamping authority other than 2331 those implied by the ttsCertificateTrustTrees. 2333 The cautionPeriod field specifies a caution period after the signing 2334 time that it is mandated the verifier must wait to get high assurance 2335 of the validity of the signer's key and that any relevant revocation 2336 has been notified. The revocation status information forming the ES 2337 with Complete validation data must not be collected and used to 2338 validate the electronic signature until after this caution period. 2340 The signatureTimestampDelay field specifies a maximum acceptable time 2341 between the signing time and the time at which the signature timestamp, 2342 as used to form the ES Timestamped, is created for the verifier. If the 2343 signature timestamp is later that the time in the signing-time 2344 attribute by more than the value given in signatureTimestampDelay, the 2345 signature must be considered invalid. 2347 5.9 Attribute Trust Conditions 2349 If the attributeTrustCondition field is not present then any certified 2350 attributes may not considered to be valid under this validation policy. 2351 The AttributeTrustCondition field is defined as follows: 2353 AttributeTrustCondition ::= SEQUENCE { 2354 attributeMandated BOOLEAN, 2355 -- Attribute must be present 2356 howCertAttribute HowCertAttribute, 2357 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 2358 attrRevReq [1] CertRevReq OPTIONAL, 2359 attributeConstraints [2] AttributeConstraints OPTIONAL } 2361 If attributeMandated is true then an attribute, certified within the 2362 following constraints, must be present. If false, then the signature 2363 is still valid if no attribute is specified. 2365 The howCertAttribute field specifies whether attributes uncertified 2366 attributes "claimed" by the signer, or certified in an attribute 2367 certificate or either using the signer attributes attribute defined 2368 in 4.12.3. 2370 HowCertAttribute ::= ENUMERATED { 2371 claimedAttribute (0), 2372 certifiedAttribtes (1), 2373 either (2) } 2375 Internet Draft Electronic Signature Formats 2377 The attrCertificateTrustTrees specifies certificate path conditions for 2378 any attribute certificate. If not present the same rules apply as in 2379 certificateTrustCondition. 2381 The attrRevReq specifies minimum requirements for revocation 2382 information, obtained through CRLs and/or OCSP responses, to be used in 2383 checking the revocation status of Attribute Certificates, if any are 2384 present. 2386 If the attributeConstraints field is not present then there are no 2387 constraints on the attributes that may be validated under this policy. 2388 The attributeConstraints field is defined as follows: 2390 AttributeConstraints ::= SEQUENCE { 2391 attributeTypeConstarints [0] AttributeTypeConstraints 2392 OPTIONAL, 2393 attributeValueConstarints [1] AttributeValueConstraints 2394 OPTIONAL } 2396 If present, the attributeTypeConstarints field specifies the attribute 2397 types which are considered valid under the signature policy. Any value 2398 for that attribute is considered valid. 2400 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 2402 If present, the attributeTypeConstraints field specifies the specific 2403 attribute values which are considered valid under the signature policy. 2405 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 2407 5.10 Algorithm Constraints 2409 The algorithmConstrains fields, if present, identifies the signing 2410 algorithms (hash, public key cryptography, combined hash and public key 2411 cryptography) that may be used for specific purposes and any minimum 2412 length. If this field is not present then the policy applies no 2413 constraints. 2415 AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on: 2416 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 2417 -- signer 2418 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 2419 -- issuer of end entity certs. 2420 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 2421 -- issuer of CA certificates 2422 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 2423 -- Attribute Authority 2424 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 2425 -- TimeStamping Authority 2426 } 2428 Internet Draft Electronic Signature Formats 2430 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 2432 AlgAndLength ::= SEQUENCE { 2433 algID OBJECT IDENTIFIER, 2434 minKeyLength INTEGER OPTIONAL, 2435 -- Minimum key length in bits 2436 other SignPolExtensions OPTIONAL 2437 } 2439 An Attribute Authority (AA)is authority which assigns privileges by 2440 issuing attribute certificates 2442 5.11 Signature Policy Extensions 2444 Additional signature policy rules may be added to: 2446 * the overall signature policy structure, as defined in 2447 clause 5.1; 2448 * the signature validation policy structure, as defined in 2449 clause 5.2; 2450 * the common rules, as defined in clause 5.3; 2451 * the commitment rules, as defined in clause 5.4; 2452 * the signer rules, as defined in clause 5.5.1; 2453 * the verifier rules, as defined in clause 5.5.2; 2454 * the revocation requirements in clause 5.6.2; 2455 * the algorithm constraints in clause 5.10. 2457 These extensions to the signature policy rules must be defined using 2458 an ASN.1 syntax with an associated object identifier carried in the 2459 SignPolExtn as defined below: 2461 SignPolExtensions ::= SEQUENCE OF SignPolExtn 2463 SignPolExtn ::= SEQUENCE { 2464 extnID OBJECT IDENTIFIER, 2465 extnValue OCTET STRING } 2467 The extnID field must contain the object identifier for the extension. 2468 The extnValue field must contain the DER (see ITU-T Recommendation 2469 X.690 [4]) encoded value of the extension. The definition of an 2470 extension, as identified by extnID must include a definition of the 2471 syntax and semantics of the extension. 2473 6. Security considerations 2475 6.1 Protection of Private Key 2477 The security of the electronic signature mechanism defined in this 2478 document depends on the privacy of the signer's private key. 2479 Implementations must take steps to ensure that private keys cannot be 2480 compromised. 2482 Internet Draft Electronic Signature Formats 2484 6.2 Choice of Algorithms 2486 Implementers should be aware that cryptographic algorithms become 2487 weaker with time. As new cryptoanalysis techniques are developed and 2488 computing performance improves, the work factor to break a particular 2489 cryptographic algorithm will reduce. Therefore, cryptographic algorithm 2490 implementations should be modular allowing new algorithms to be readily 2491 inserted. That is, implementers should be prepared for the set of 2492 mandatory to implement algorithms to change over time. 2494 7. Conformance Requirements 2496 This document only defines conformance requirements up to a ES with 2497 Complete validation data (ES-C). This means that none of the extended 2498 and archive forms of Electronic Signature (ES-X, ES-A) need to be 2499 implemented to get conformance to this standard. 2501 This document mandates support for elements of the signature policy. 2503 7.1 Signer 2505 A system supporting signers according to this document must, at a 2506 minimum, support generation of an electronic signature consisting of 2507 the following components: 2509 * The general CMS syntax and content type as defined in RFC 2630 2510 (see clauses 4.1 and 4.2). 2512 * CMS SignedData as defined in RFC 2630 with version set to 3 2513 and at least one SignerInfo must be present 2514 (see clauses 4.3, 4.4, 4.5, 4.6). 2516 * The following CMS Attributes as defined in RFC 2630 : 2517 - ContentType; This must always be present 2518 (see clause 3.7.1); 2520 - MessageDigest; This must always be present 2521 (see clause 3.7.2); 2523 - SigningTime; This must always be present 2524 (see clause 3.7.3). 2526 * The following ESS Attributes as defined in RFC 2634 : 2527 - SigningCertificate: This must be set as defined 2528 in clauses 3.8.1 and 3.8.2. 2530 * The following Attributes as defined in clause 3.9: 2531 - SignaturePolicyIdentifier; This must always be present. 2533 * Public Key Certificates as defined in ITU-T Recommendation 2534 X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1). 2536 Internet Draft Electronic Signature Formats 2538 7.2 Verifier 2540 A system supporting verifiers according to this document must, at a 2541 minimum, support: 2543 * Verification of the mandated components of an electronic 2544 signature, as defined in clause 14.1. 2546 * Signature Timestamp attribute, as defined in clause 5.1.1. 2548 * Complete Certificate Refs attribute, as defined in 2549 clause 5.2.1. 2551 * Complete Revocation Refs Attribute, as defined in 2552 clause 5.2.2. 2554 * Public Key Certificates, as defined in ITU-T 2555 Recommendation X.509 and profiled in RFC 2459 2556 (see clause 10.1) 2558 * Either of: 2559 - Certificate Revocation Lists. as defined in ITU-T 2560 Recommendation X.509 [1] and profiled in RFC 2459 [7] 2561 (see clause 10.2); Or 2562 - On-line Certificate Status Protocol, as defined in 2563 RFC 2560 (see clause 10.3). 2565 7.3 Signature Policy 2567 Both signer and verifier systems must be able to process an electronic 2568 signature in accordance with the specification of at least one 2569 signature policy, as identified by the signature policy attribute 2570 (see clause 4.9.1). 2572 8. References 2574 [RFC2510] C. Adams, S. Farrell, "Internet X.509 Public Key 2575 Infrastructure, Certificate Management Protocols," RFC 2510, March 1999. 2577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2578 Requirement Levels", BCP 14, RFC 2119, March 1997. 2580 [RFC2246] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC 2581 2246, January 1999. 2583 [RFC 2634] P. Hoffman, "Enhanced Security Services for S/MIME", 2585 [RFC 2630] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 2586 1999. 2588 Internet Draft Electronic Signature Formats 2590 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 2591 Key Infrastructure, Certificate and CRL Profile," RFC 2459, January 2592 1999. 2594 [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards 2595 (PKCS)", RSA Data Security Inc., Redwood City, California, November 2596 1993 Release. 2598 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 2599 Non-Repudiation Framework. April 1997. 2601 9. Authors' Addresses 2603 This Informational RFC has been produced in ETSI TC-SEC. 2605 ETSI 2606 F-06921 Sophia Antipolis, Cedex - FRANCE 2607 650 Route des Lucioles - Sophia Antipolis 2608 Valbonne - France 2609 Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 2610 secretariat@etsi.fr 2611 http://www.etsi.org 2613 ETSI Contact Point 2615 Harri Rasilainen 2616 ETSI 2617 F-06921 Sophie Antipolis 2618 650 Route des Lucioles 2619 Sophia Antipolis, Valbonne 2620 FRANCE 2621 harri.rasilainen@etsi.fr 2623 Additional Contact Points 2625 John Ross 2626 Security & Standards 2627 192 Moulsham Street 2628 Chelmsford, Essex 2629 CM2 0LG 2630 United Kingdom 2631 ross@secstan.com 2633 Denis Pinkas Nick Pope 2634 Bull S.A. Security & Standards 2635 12, rue de Paris 192 Moulsham Street 2636 B.P. 59 Chelmsford, Essex 2637 78231 Le Pecq CM2 0LG 2638 FRANCE United Kingdom 2639 pinkas.denis@bull.net pope@secstan.com 2641 Internet Draft Electronic Signature Formats 2643 10. Full Copyright Statement 2645 Copyright (C) The Internet Society (2000). All Rights Reserved. 2646 This document and translations of it may be copied and furnished to others, 2647 and derivative works that comment on or otherwise explain it or assist in 2648 its implementation may be prepared, copied, published and distributed, in 2649 whole or in part, without restriction of any kind, provided that the above 2650 copyright notice and this paragraph are included on all such copies and 2651 derivative works. However, this document itself may not be modified in any 2652 way, such as by removing the copyright notice or references to the Internet 2653 Society or other Internet organizations, except as needed for the purpose of 2654 developing Internet standards in which case the procedures for copyrights 2655 defined in the Internet Standards process must be followed, or as required to 2656 translate it into languages other than English. 2658 The limited permissions granted above are perpetual and will not be revoked 2659 by the Internet Society or its successors or assigns. 2661 This document and the information contained herein is provided on an 2662 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2663 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 2664 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 2665 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2666 FITNESS FOR A PARTICULAR PURPOSE. 2668 11.Temportary Issues 2669 It might be interesting to split this document into two RFCs, one RFC 2670 dealing only with ES formats, the other one only with Signature 2671 Policies. In such a case, the basis of this split will be, sections 6 2672 and annex C will be removed from this document and placed in the another 2673 RFC dealing with Signature policies. The signature policy ASN.1 will be 2674 removed the current ASN.1 modules in annex A and placed in a new ASN.1 2675 module in the other RFC dealing with Signature Policies. Opinions are 2676 requested on this issue. 2678 Internet Draft Electronic Signature Formats 2680 Note: If there is a request to split this document into two RFCs, one 2681 RFC dealing with ES formats, the other with Signature policies, then the 2682 signature policy ASN.1 will be removed the current ASN.1 modules in 2683 annex A and placed in a new ASN.1 module in the other RFC dealing with 2684 Signature policies. 2686 Annex A (normative): 2688 ASN.1 Definitions 2690 This annex provides a summary of all the ASN.1 syntax definitions for 2691 new syntax defined in this document. 2693 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 2695 NOTE: The ASN.1 module defined in clause A.1 has precedence over that 2696 defined in Annex A-2 in the case of any conflict. 2698 ETS-ElectronicSignature-88syntax { iso(1) member-body(2) 2699 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5} 2701 DEFINITIONS EXPLICIT TAGS ::= 2702 BEGIN 2703 -- EXPORTS All - 2705 IMPORTS 2707 -- Crypographic Message Syntax (CMS): RFC 2630 2708 ContentInfo, ContentType, id-data, id-signedData, SignedData, 2709 EncapsulatedContentInfo, 2710 SignerInfo, id-contentType, id-messageDigest, MessageDigest, 2711 id-signingTime, SigningTime, 2712 id-countersignature, Countersignature 2713 FROM CryptographicMessageSyntax 2714 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2715 smime(16) modules(0) cms(1) } 2717 -- ESS Defined attributes: RFC 2634 2718 -- (Enhanced Security Services for S/MIME) 2719 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 2720 id-aa-contentReference, ContentReference, 2721 id-aa-contentIdentifier, ContentIdentifier 2722 FROM ExtendedSecurityServices 2723 { iso(1) member-body(2) us(840) rsadsi(113549) 2724 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 2726 Internet Draft Electronic Signature Formats 2728 -- Internet X.509 Public Key Infrastructure 2729 - - Certificate and CRL Profile: RFC 2459 2731 Certificate, AlgorithmIdentifier, CertificateList, Name, 2732 GeneralNames, GeneralName, 2733 DirectoryString,Attribute, AttributeTypeAndValue, AttributeType, 2734 AttributeValue, 2735 PolicyInformation, BMPString, UTF8String 2736 FROM PKIX1Explicit88 2737 {iso(1) identified-organization(3) dod(6) internet(1) 2738 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit- 2739 88(1)} 2741 -- X.509 '97 Authentication Framework 2742 AttributeCertificate 2743 FROM AuthenticationFramework 2744 {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3} 2745 -- The imported AttributeCertificate is defined using the X.680 1997 2746 -- ASN.1 Syntax, 2747 -- an equivalent using the 88 ASN.1 syntax may be used. 2749 -- OCSP 2560 2750 BasicOCSPResponse, ResponderID 2751 FROM OCSP {-- OID not assigned -- } 2753 -- Time Stamp Protocol Internet Draft 2754 -- TimeStampToken 2755 FROM TSP {-- OID not assigned -- }; 2757 -- S/MIME Object Identifier arcs used in this document 2758 -- ================================================================== 2760 -- S/MIME OID arc used in this document 2761 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2762 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 2764 -- S/MIME Arcs 2765 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 2766 -- modules 2767 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 2768 -- content types 2769 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 2770 -- attributes 2771 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 2772 -- signature policy qualifier 2773 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 2774 -- commitment type identifier 2776 Internet Draft Electronic Signature Formats 2778 -- Definitions of Object Identifier arcs used in this document 2779 -- ================================================================== 2781 -- The allocation of OIDs to specific objects are given below with the 2782 -- associated ASN.1 syntax definition 2784 -- OID used referencing electronic signature mechanisms based on this 2785 -- standard for use with the IDUP API (see annex D) 2787 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 2788 { itu-t(0) identified-organization(4) etsi(0) 2789 electronic-signature-standard (1733) part1 (1) 2790 idupMechanism (4)etsiESv1(1) } 2792 -- CMS Attributes Defined in this document 2793 -- ============================================== 2795 -- Mandatory Electronic Signature Attributes 2797 -- OtherSigningCertificate 2799 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 2800 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2801 smime(16) id-aa(2) 19 } 2803 OtherSigningCertificate ::= SEQUENCE { 2804 certs SEQUENCE OF OtherCertID, 2805 policies SEQUENCE OF PolicyInformation OPTIONAL 2806 -- NOT USED IN THIS DOCUMENT 2807 } 2809 OtherCertID ::= SEQUENCE { 2810 otherCertHash OtherHash, 2811 issuerSerial IssuerSerial OPTIONAL } 2813 OtherHash ::= CHOICE { 2814 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 2815 otherHash OtherHashAlgAndValue} 2817 OtherHashValue ::= OCTET STRING 2819 OtherHashAlgAndValue ::= SEQUENCE { 2820 hashAlgorithm AlgorithmIdentifier, 2821 hashValue OtherHashValue } 2823 -- Signature Policy Identifier 2825 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 2826 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2827 smime(16) id-aa(2) 15 } 2829 Internet Draft Electronic Signature Formats 2831 SignaturePolicyIdentifier ::= SEQUENCE { 2832 sigPolicyIdentifier SigPolicyId, 2833 sigPolicyHash SigPolicyHash, 2834 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 2835 SigPolicyQualifierInfo OPTIONAL} 2837 SigPolicyId ::= OBJECT IDENTIFIER 2839 SigPolicyHash ::= ETSIHashAlgAndValue 2841 SigPolicyQualifierInfo ::= SEQUENCE { 2842 sigPolicyQualifierId SigPolicyQualifierId, 2843 sigQualifier ANY DEFINED BY sigPolicyQualifierId } 2845 SigPolicyQualifierId ::= 2846 OBJECT IDENTIFIER 2848 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 2849 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2850 smime(16) id-spq(5) 1 } 2852 SPuri ::= IA5String 2854 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 2855 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2856 smime(16) id-spq(5) 2 } 2858 SPUserNotice ::= SEQUENCE { 2859 noticeRef NoticeReference OPTIONAL, 2860 explicitText DisplayText OPTIONAL} 2862 NoticeReference ::= SEQUENCE { 2863 organization DisplayText, 2864 noticeNumbers SEQUENCE OF INTEGER } 2866 DisplayText ::= CHOICE { 2867 visibleString VisibleString (SIZE (1..200)), 2868 bmpString BMPString (SIZE (1..200)), 2869 utf8String UTF8String (SIZE (1..200)) } 2871 Internet Draft Electronic Signature Formats 2873 -- Optional Electronic Signature Attributes 2875 -- Commitment Type 2877 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2878 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 2880 CommitmentTypeIndication ::= SEQUENCE { 2881 commitmentTypeId CommitmentTypeIdentifier, 2882 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 2883 CommitmentTypeQualifier 2884 OPTIONAL} 2886 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 2888 CommitmentTypeQualifier ::= SEQUENCE { 2889 commitmentTypeIdentifier CommitmentTypeIdentifier, 2890 qualifier ANY DEFINED BY commitmentTypeIdentifier } 2892 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member- 2893 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2894 cti(6) 1} 2896 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member- 2897 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2898 cti(6) 2} 2900 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member- 2901 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2902 cti(6) 3} 2904 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member- 2905 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2906 cti(6) 4} 2908 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member- 2909 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2910 cti(6) 5} 2912 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member- 2913 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2914 cti(6) 6} 2916 Internet Draft Electronic Signature Formats 2918 -- Signer Location 2920 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2921 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 2923 SignerLocation ::= SEQUENCE { 2924 -- At least one of the following must be present 2925 countryName [0] DirectoryString OPTIONAL, 2926 -- As used to name a Country in X.500 2927 localityName [1] DirectoryString OPTIONAL, 2928 -- As used to name a locality in X.500 2929 postalAdddress [2] PostalAddress OPTIONAL } 2931 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 2933 -- Signer Attributes 2935 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2936 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 2938 SignerAttribute ::= SEQUENCE OF CHOICE { 2939 claimedAttributes [0] ClaimedAttributes, 2940 certifiedAttributes [1] CertifiedAttributes } 2942 ClaimedAttributes ::= SEQUENCE OF Attribute 2944 CertifiedAttributes ::= AttributeCertificate -- As defined in X.509 : 2945 see section 10.3 2947 -- Content Timestamp 2949 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 2950 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2951 id-aa(2) 20} 2953 ContentTimestamp::= TimeStampToken 2955 -- Validation Data 2957 -- Signature Timestamp 2959 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member- 2960 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2961 id-aa(2) 14} 2963 SignatureTimeStampToken ::= TimeStampToken 2965 Internet Draft Electronic Signature Formats 2967 -- Complete Certificate Refs. 2969 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2970 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 2972 CompleteCertificateRefs ::= SEQUENCE OF ETSICertID 2974 -- Complete Revocation Refs 2976 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2977 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 2979 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 2981 CrlOcspRef ::= SEQUENCE { 2982 crlids [0] CRLListID OPTIONAL, 2983 ocspids [1] OcspListID OPTIONAL, 2984 otherRev [2] OtherRevRefs OPTIONAL 2985 } 2987 CRLListID ::= SEQUENCE { 2988 crls SEQUENCE OF CrlValidatedID} 2990 CrlValidatedID ::= SEQUENCE { 2991 crlHash ETSIHash, 2992 crlIdentifier CrlIdentifier OPTIONAL} 2994 CrlIdentifier ::= SEQUENCE { 2995 crlissuer Name, 2996 crlIssuedTime UTCTime, 2997 crlNumber INTEGER OPTIONAL 2998 } 3000 OcspListID ::= SEQUENCE { 3001 ocspResponses SEQUENCE OF OcspResponsesID} 3003 OcspResponsesID ::= SEQUENCE { 3004 ocspIdentifier OcspIdentifier, 3005 ocspRepHash ETSIHash OPTIONAL 3006 } 3008 OcspIdentifier ::= SEQUENCE { 3009 ocspResponderID ResponderID, 3010 -- As in OCSP response data 3011 producedAt GeneralizedTime 3012 -- As in OCSP response data 3013 } 3015 Internet Draft Electronic Signature Formats 3017 OtherRevRefs ::= SEQUENCE { 3018 otherRevRefType OtherRevRefType, 3019 otherRevRefs ANY DEFINED BY otherRevRefType 3020 } 3022 OtherRevRefType ::= OBJECT IDENTIFIER 3024 -- Certificate Values 3026 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3027 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3029 CertificateValues ::= SEQUENCE OF Certificate 3031 -- Certificate Revocation Values 3033 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member- 3034 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3035 id-aa(2) 24} 3037 RevocationValues ::= SEQUENCE { 3038 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3039 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3040 otherRevVals [2] OtherRevVals } 3042 OtherRevVals ::= SEQUENCE { 3043 otherRevValType OtherRevValType, 3044 otherRevVals ANY DEFINED BY otherRevValType 3045 } 3047 OtherRevValType ::= OBJECT IDENTIFIER 3049 -- ES-C Timestamp 3051 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3052 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} 3054 ESCTimeStampToken ::= TimeStampToken 3056 -- Time-Stamped Certificates and CRLs 3058 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3059 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3060 id-aa(2) 26} 3062 TimestampedCertsCRLs ::= TimeStampToken 3064 Internet Draft Electronic Signature Formats 3066 -- Archive Timestamp 3068 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member- 3069 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3070 id-aa(2) 27} 3072 ArchiveTimeStampToken ::= TimeStampToken 3074 -- Signature Policy Specification 3075 -- ============================== 3077 SignaturePolicy ::= SEQUENCE { 3078 signPolicyHashAlg AlgorithmIdentifier, 3079 signPolicyInfo SignPolicyInfo, 3080 signPolicyHash SignPolicyHash OPTIONAL } 3082 SignPolicyHash ::= OCTET STRING 3084 SignPolicyInfo ::= SEQUENCE { 3085 signPolicyIdentifier SignPolicyId, 3086 dateOfIssue GeneralizedTime, 3087 policyIssuerName PolicyIssuerName, 3088 fieldOfApplication FieldOfApplication, 3089 signatureValidationPolicy SignatureValidationPolicy, 3090 signPolExtensions SignPolExtensions 3091 OPTIONAL 3092 } 3094 SignPolicyId ::= OBJECT IDENTIFIER 3096 PolicyIssuerName ::= GeneralNames 3098 FieldOfApplication ::= DirectoryString 3100 SignatureValidationPolicy ::= SEQUENCE { 3101 signingPeriod SigningPeriod, 3102 commonRules CommonRules, 3103 commitmentRules CommitmentRules, 3104 signPolExtensions SignPolExtensions 3105 OPTIONAL 3106 } 3108 SigningPeriod ::= SEQUENCE { 3109 notBefore GeneralizedTime, 3110 notAfter GeneralizedTime OPTIONAL } 3112 Internet Draft Electronic Signature Formats 3114 CommonRules ::= SEQUENCE { 3115 signerAndVeriferRules [0] SignerAndVerifierRules 3116 OPTIONAL, 3117 signingCertTrustCondition [1] SigningCertTrustCondition 3118 OPTIONAL, 3119 timeStampTrustCondition [2] TimestampTrustCondition 3120 OPTIONAL, 3121 attributeTrustCondition [3] AttributeTrustCondition 3122 OPTIONAL, 3123 algorithmConstraintSet [4] AlgorithmConstraintSet 3124 OPTIONAL, 3125 signPolExtensions [5] SignPolExtensions 3126 OPTIONAL 3127 } 3129 CommitmentRules ::= SEQUENCE OF CommitmentRule 3131 CommitmentRule ::= SEQUENCE { 3132 selCommitmentTypes SelectedCommitmentTypes, 3133 signerAndVeriferRules [0] SignerAndVerifierRules 3134 OPTIONAL, 3135 signingCertTrustCondition [1] SigningCertTrustCondition 3136 OPTIONAL, 3137 timeStampTrustCondition [2] TimestampTrustCondition 3138 OPTIONAL, 3139 attributeTrustCondition [3] AttributeTrustCondition 3140 OPTIONAL, 3141 algorithmConstraintSet [4] AlgorithmConstraintSet 3142 OPTIONAL, 3143 signPolExtensions [5] SignPolExtensions 3144 OPTIONAL 3145 } 3147 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 3148 empty NULL, 3149 recognizedCommitmentType CommitmentType } 3151 CommitmentType ::= SEQUENCE { 3152 identifier CommitmentTypeIdentifier, 3153 fieldOfApplication [0] FieldOfApplication OPTIONAL, 3154 semantics [1] DirectoryString OPTIONAL } 3156 SignerAndVerifierRules ::= SEQUENCE { 3157 signerRules SignerRules, 3158 verifierRules VerifierRules } 3160 Internet Draft Electronic Signature Formats 3162 SignerRules ::= SEQUENCE { 3163 externalSignedData BOOLEAN OPTIONAL, 3164 -- True if signed data is external to CMS structure 3165 -- False if signed data part of CMS structure 3166 -- not present if either allowed 3167 mandatedSignedAttr CMSAttrs, 3168 -- Mandated CMS signed attributes 3169 mandatedUnsignedAttr CMSAttrs, 3170 -- Mandated CMS unsigned attributed 3171 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 3172 -- Mandated Certificate Reference 3173 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 3174 -- Mandated Certificate Info 3175 signPolExtensions [2] SignPolExtensions 3176 OPTIONAL} 3178 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 3180 CertRefReq ::= ENUMERATED { 3181 signerOnly (1), 3182 -- Only reference to signer cert mandated 3183 fullPath (2) 3184 -- References for full cert path up to a trust point required 3186 } 3188 CertInfoReq ::= ENUMERATED { 3189 none (0), 3190 -- No mandatory requirements 3191 signerOnly (1), 3192 -- Only reference to signer cert mandated 3193 fullPath (2) 3194 -- References for full cert path up to a trust point mandated 3195 } 3197 VerifierRules ::= SEQUENCE { 3198 mandatedUnsignedAttr MandatedUnsignedAttr, 3199 signPolExtensions SignPolExtensions OPTIONAL 3200 } 3202 MandatedUnsignedAttr ::= CMSAttrs 3203 -- Mandated CMS unsigned attributed 3205 Internet Draft Electronic Signature Formats 3207 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 3209 CertificateTrustPoint ::= SEQUENCE { 3210 trustpoint Certificate, 3211 -- self-signed certificate 3212 pathLenConstraint [0] PathLenConstraint OPTIONAL, 3213 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 3214 -- If not present "any policy" 3215 nameConstraints [2] NameConstraints OPTIONAL, 3216 policyConstraints [3] PolicyConstraints OPTIONAL } 3218 PathLenConstraint ::= INTEGER (0..MAX) 3220 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 3222 CertPolicyId ::= OBJECT IDENTIFIER 3224 NameConstraints ::= SEQUENCE { 3225 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 3226 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 3228 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 3230 GeneralSubtree ::= SEQUENCE { 3231 base GeneralName, 3232 minimum [0] BaseDistance DEFAULT 0, 3233 maximum [1] BaseDistance OPTIONAL } 3235 BaseDistance ::= INTEGER (0..MAX) 3237 PolicyConstraints ::= SEQUENCE { 3238 requireExplicitPolicy [0] SkipCerts OPTIONAL, 3239 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 3241 SkipCerts ::= INTEGER (0..MAX) 3243 CertRevReq ::= SEQUENCE { 3244 endCertRevReq RevReq, 3245 caCerts [0] RevReq 3246 } 3248 RevReq ::= SEQUENCE { 3249 enuRevReq EnuRevReq, 3250 exRevReq SignPolExtensions OPTIONAL} 3252 Internet Draft Electronic Signature Formats 3254 EnuRevReq ::= ENUMERATED { 3255 clrCheck (0), --Checks must be made against current CRLs 3256 -- (or authority revocation lists) 3257 ocspCheck (1), -- The revocation status must be checked 3258 -- using the Online Certificate Status Protocol (RFC 2450) 3259 bothCheck (2), 3260 -- Both CRL and OCSP checks must be carried out 3261 eitherCheck (3), 3262 -- At least one of CRL or OCSP checks must be carried out 3263 noCheck (4), 3264 -- no check is mandated 3265 other (5) 3266 -- Other mechanism as defined by signature policy extension 3267 } 3269 SigningCertTrustCondition ::= SEQUENCE { 3270 signerTrustTrees CertificateTrustTrees, 3271 signerRevReq CertRevReq 3272 } 3274 TimestampTrustCondition ::= SEQUENCE { 3275 ttsCertificateTrustTrees [0] CertificateTrustTrees 3276 OPTIONAL, 3277 ttsRevReq [1] CertRevReq 3278 OPTIONAL, 3279 ttsNameConstraints [2] NameConstraints 3280 OPTIONAL, 3281 cautionPeriod [3] DeltaTime 3282 OPTIONAL, 3283 signatureTimestampDelay [4] DeltaTime 3284 OPTIONAL } 3286 DeltaTime ::= SEQUENCE { 3287 deltaSeconds INTEGER, 3288 deltaMinutes INTEGER, 3289 deltaHours INTEGER, 3290 deltaDays INTEGER } 3292 AttributeTrustCondition ::= SEQUENCE { 3293 attributeMandated BOOLEAN, 3294 -- Attribute must be present 3295 howCertAttribute HowCertAttribute, 3296 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 3297 attrRevReq [1] CertRevReq OPTIONAL, 3298 attributeConstraints [2] AttributeConstraints OPTIONAL } 3300 HowCertAttribute ::= ENUMERATED { 3301 claimedAttribute (0), 3302 certifiedAttribtes (1), 3303 either (2) } 3305 Internet Draft Electronic Signature Formats 3307 AttributeConstraints ::= SEQUENCE { 3308 attributeTypeConstarints [0] AttributeTypeConstraints 3309 OPTIONAL, 3310 attributeValueConstarints [1] AttributeValueConstraints 3311 OPTIONAL } 3313 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 3315 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 3317 AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on: 3318 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 3319 -- signer 3320 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 3321 -- issuer of end entity certs. 3322 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 3323 -- issuer of CA certificates 3324 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 3325 -- Attribute Authority 3326 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 3327 -- TimeStamping Authority 3328 } 3330 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 3332 AlgAndLength ::= SEQUENCE { 3333 algID OBJECT IDENTIFIER, 3334 minKeyLength INTEGER OPTIONAL, 3335 -- Minimum key length in bits other 3336 SignPolExtensions OPTIONAL 3337 } 3339 SignPolExtensions ::= SEQUENCE OF SignPolExtn 3341 SignPolExtn ::= SEQUENCE { 3342 extnID OBJECT IDENTIFIER, 3343 extnValue OCTET STRING } 3345 END -- ETS-ElectronicSignature-88syntax -- 3347 Internet Draft Electronic Signature Formats 3349 A.2 Definitions Using X.680 1997 ASN.1 Syntax 3351 NOTE: The ASN.1 module defined in clause A.1 has precedence over that 3352 defined in clause A.2 in the case of any conflict. 3354 ETS-ElectronicSignature-97Syntax { iso(1) member-body(2) 3355 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6} 3357 DEFINITIONS EXPLICIT TAGS ::= 3358 BEGIN 3359 -- EXPORTS All - 3361 IMPORTS 3363 -- Crypographic Message Syntax (CMS): RFC 2630 3364 ContentInfo, ContentType, id-data, id-signedData, SignedData, 3365 EncapsulatedContentInfo, SignerInfo, 3366 id-contentType, id-messageDigest, MessageDigest, id-signingTime, 3367 SigningTime, id-countersignature, Countersignature 3369 FROM CryptographicMessageSyntax 3370 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3371 smime(16) modules(0) cms(1) } 3373 -- ESS Defined attributes: RFC 2634 (Enhanced Security Services 3374 -- for S/MIME) 3375 id-aa-signingCertificate, SigningCertificate, IssuerSerial, 3376 id-aa-contentReference, ContentReference, 3377 id-aa-contentIdentifier, ContentIdentifier 3378 FROM ExtendedSecurityServices 3379 { iso(1) member-body(2) us(840) rsadsi(113549) 3380 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 3382 -- Internet X.509 Public Key Infrastructure 3383 - - Certificate and CRL Profile:RFC 2459 3384 Certificate, AlgorithmIdentifier, CertificateList, Name, 3385 GeneralNames, GeneralName, DirectoryString, Attribute, 3386 AttributeTypeAndValue, AttributeType, AttributeValue, 3387 PolicyInformation. 3389 FROM PKIX1Explicit93 3390 {iso(1) identified-organization(3) dod(6) internet(1) 3391 security(5) mechanisms(5) pkix(7) id-mod(0) 3392 id-pkix1-explicit-88(1)} 3394 -- X.509 '97 Authentication Framework 3395 AttributeCertificate 3396 FROM AuthenticationFramework 3397 {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3} 3399 Internet Draft Electronic Signature Formats 3401 -- OCSP 2560 3402 BasicOCSPResponse, ResponderID 3403 FROM OCSP 3404 -- { OID not assigned } 3406 -- Time Stamp Protocol Internet Draft TimeStampToken 3407 FROM TSP 3408 -- { OID not assigned }; 3410 -- S/MIME Object Identifier arcs used in this document 3411 -- ================================================================== 3413 -- S/MIME OID arc used in this document 3414 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3415 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 3417 -- S/MIME Arcs 3418 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 3419 -- modules 3420 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 3421 -- content types 3422 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 3423 -- attributes 3424 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 3425 -- signature policy qualifier 3426 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 3427 -- commitment type identifier 3429 -- Definitions of Object Identifier arcs used in this document 3430 -- ================================================================== 3432 -- The allocation of OIDs to specific objects are given below with the 3433 -- associated ASN.1 syntax definition 3435 -- OID used referencing electronic signature mechanisms based on this 3436 -- standard for use with the IDUP API (see annex D) 3438 id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::= 3439 { itu-t(0) identified-organization(4) etsi(0) 3440 electronic-signature-standard (1733) part1 (1) 3441 idupMechanism (4)etsiESv1(1) } 3443 Internet Draft Electronic Signature Formats 3445 -- CMS Attributes Defined in this document 3446 -- ============================================== 3448 -- Mandatory Electronic Signature Attributes 3449 -- OtherSigningCertificate 3451 id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1) 3452 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3453 smime(16) id-aa(2) 19 } 3455 OtherSigningCertificate ::= SEQUENCE { 3456 certs SEQUENCE OF OtherCertID, 3457 policies SEQUENCE OF PolicyInformation OPTIONAL 3458 -- NOT USED IN THIS DOCUMENT 3459 } 3461 OtherCertID ::= SEQUENCE { 3462 otherCertHash OtherHash, 3463 issuerSerial IssuerSerial OPTIONAL } 3465 OtherHash ::= CHOICE { 3466 sha1Hash OtherHashValue, -- This contains a SHA-1 hash 3467 otherHash OtherHashAlgAndValue} 3469 OtherHashValue ::= OCTET STRING 3471 OtherHashAlgAndValue ::= SEQUENCE { 3472 hashAlgorithm AlgorithmIdentifier, 3473 hashValue OtherHashValue } 3475 -- Signature Policy Identifier 3477 id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) 3478 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3479 smime(16) id-aa(2) 15 } 3481 SignaturePolicyIdentifier ::= SEQUENCE { 3482 sigPolicyIdentifier SigPolicyId, 3483 sigPolicyHash SigPolicyHash, 3484 sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 3485 SigPolicyQualifierInfo OPTIONAL} 3487 Internet Draft Electronic Signature Formats 3489 SigPolicyId ::= OBJECT IDENTIFIER 3491 SigPolicyHash ::= ETSIHashAlgAndValue 3493 SigPolicyQualifierInfo ::= SEQUENCE { 3494 sigPolicyQualifierId SIG-POLICY-QUALIFIER.&id 3495 ({SupportedSigPolicyQualifiers}), 3496 qualifier SIG-POLICY-QUALIFIER.&Qualifier 3497 ({SupportedSigPolicyQualifiers} 3498 {@sigPolicyQualifierId})OPTIONAL } 3500 SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 3501 { noticeToUser | pointerToSigPolSpec } 3503 SIG-POLICY-QUALIFIER ::= CLASS { 3504 &id OBJECT IDENTIFIER UNIQUE, 3505 &Qualifier OPTIONAL } 3507 WITH SYNTAX { 3508 SIG-POLICY-QUALIFIER-ID &id 3509 [SIG-QUALIFIER-TYPE &Qualifier] } 3511 noticeToUser SIG-POLICY-QUALIFIER ::= { 3512 SIG-POLICY-QUALIFIER-ID id-sqt-unotice SIG-QUALIFIER-TYPE 3513 SPUserNotice 3514 } 3516 pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= { 3517 SIG-POLICY-QUALIFIER-ID id-sqt-uri SIG-QUALIFIER-TYPE SPuri } 3519 id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1) 3520 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3521 smime(16) id-spq(5) 1 } 3523 SPuri ::= IA5String 3525 id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1) 3526 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3527 smime(16) id-spq(5) 2 } 3529 SPUserNotice ::= SEQUENCE { 3530 noticeRef NoticeReference OPTIONAL, 3531 explicitText DisplayText OPTIONAL} 3533 NoticeReference ::= SEQUENCE { 3534 organization DisplayText, 3535 noticeNumbers SEQUENCE OF INTEGER } 3537 DisplayText ::= CHOICE { 3538 visibleString VisibleString (SIZE (1..200)), 3539 bmpString BMPString (SIZE (1..200)), 3540 utf8String UTF8String (SIZE (1..200)) } 3542 Internet Draft Electronic Signature Formats 3544 -- Optional Electronic Signature Attributes 3546 -- Commitment Type 3548 id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3549 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16} 3551 CommitmentTypeIndication ::= SEQUENCE { 3552 commitmentTypeId CommitmentTypeIdentifier, 3553 commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 3554 CommitmentTypeQualifier 3555 OPTIONAL} 3557 CommitmentTypeIdentifier ::= OBJECT IDENTIFIER 3559 CommitmentTypeQualifier ::= SEQUENCE { 3560 commitmentQualifierId COMMITMENT-QUALIFIER.&id, 3561 qualifier COMMITMENT-QUALIFIER.&Qualifier 3562 OPTIONAL } 3564 COMMITMENT-QUALIFIER ::= CLASS { 3565 &id OBJECT IDENTIFIER UNIQUE, 3566 &Qualifier OPTIONAL } 3567 WITH SYNTAX { 3568 COMMITMENT-QUALIFIER-ID &id 3569 [COMMITMENT-TYPE &Qualifier] } 3571 id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) 3572 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3573 smime(16) cti(6) 1} 3575 id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) 3576 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3577 smime(16) cti(6) 2} 3579 id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) 3580 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3581 smime(16) cti(6) 3} 3583 id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) 3584 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3585 smime(16) cti(6) 4} 3587 id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) 3588 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3589 smime(16) cti(6) 5} 3591 id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) 3592 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3593 smime(16) cti(6) 6} 3595 Internet Draft Electronic Signature Formats 3597 -- Signer Location 3599 id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3600 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17} 3602 SignerLocation ::= SEQUENCE { 3603 -- at least one of the following must be present 3604 countryName [0] DirectoryString OPTIONAL, 3605 -- As used to name a Country in X.500 3606 localityName [1] DirectoryString OPTIONAL, 3607 -- As used to name a locality in X.500 3608 postalAdddress [2] PostalAddress OPTIONAL } 3610 PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString 3612 -- Signer Attributes 3614 id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3615 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18} 3617 SignerAttribute ::= SEQUENCE OF CHOICE { 3618 claimedAttributes [0] ClaimedAttributes, 3619 certifiedAttributes [1] CertifiedAttributes } 3621 ClaimedAttributes ::= SEQUENCE OF Attribute 3623 CertifiedAttributes ::= AttributeCertificate 3624 -- As defined in X.509 : see section 10.3 3626 -- Content Timestamp 3628 id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) 3629 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3630 smime(16) id-aa(2) 20} 3632 ContentTimestamp::= TimeStampToken 3634 -- Validation Data 3636 -- Signature Timestamp 3638 id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 3639 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3640 smime(16) id-aa(2) 14} 3642 SignatureTimeStampToken ::= TimeStampToken 3644 Internet Draft Electronic Signature Formats 3646 -- Complete Certificate Refs. 3648 id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3649 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21} 3651 CompleteCertificateRefs ::= SEQUENCE OF ETSICertID 3653 -- Complete Revocation Refs 3655 id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3656 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22} 3658 CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef 3660 CrlOcspRef ::= SEQUENCE { 3661 crlids [0] CRLListID OPTIONAL, 3662 ocspids [1] OcspListID OPTIONAL, 3663 otherRev [2] OtherRevRefs OPTIONAL 3664 } 3666 CRLListID ::= SEQUENCE { 3667 crls SEQUENCE OF CrlValidatedID} 3669 CrlValidatedID ::= SEQUENCE { 3670 crlHash ETSIHash, 3671 crlIdentifier CrlIdentifier OPTIONAL} 3673 CrlIdentifier ::= SEQUENCE { 3674 crlissuer Name, 3675 crlIssuedTime UTCTime, 3676 crlNumber INTEGER OPTIONAL 3677 } 3679 OcspListID ::= SEQUENCE { 3680 ocspResponses SEQUENCE OF OcspResponsesID} 3682 OcspResponsesID ::= SEQUENCE { 3683 ocspIdentifier OcspIdentifier, 3684 ocspRepHash ETSIHash OPTIONAL 3685 } 3687 OcspIdentifier ::= SEQUENCE { 3688 ocspResponderID ResponderID, 3689 -- As in OCSP response data 3690 producedAt GeneralizedTime 3691 -- As in OCSP response data 3692 } 3694 Internet Draft Electronic Signature Formats 3696 OtherRevRefs ::= SEQUENCE { 3697 otherRevRefType OTHER-REVOCATION-REF.&id, 3698 otherRevRefs OTHER-REVOCATION-REF.&Type 3699 } 3701 OTHER-REVOCATION-REF ::= CLASS { 3702 &Type, 3703 &id OBJECT IDENTIFIER UNIQUE } 3704 WITH SYNTAX { 3705 &Type ID &id } 3707 -- Certificate Values 3709 id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2) 3710 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23} 3712 CertificateValues ::= SEQUENCE OF Certificate 3714 -- Certificate Revocation Values 3716 id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) 3717 member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3718 smime(16) id-aa(2) 24} 3720 RevocationValues ::= SEQUENCE { 3721 crlVals [0] SEQUENCE OF CertificateList OPTIONAL, 3722 ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, 3723 otherRevVals [2] OtherRevVals } 3725 OtherRevVals ::= SEQUENCE { 3726 otherRevValType OTHER-REVOCATION-VAL.&id, 3727 otherRevVals OTHER-REVOCATION-VAL.&Type 3728 } 3730 OTHER-REVOCATION-VAL ::= CLASS { 3731 &Type, 3732 &id OBJECT IDENTIFIER UNIQUE } 3733 WITH SYNTAX { 3734 &Type ID &id } 3736 -- ES-C Timestamp 3738 id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) 3739 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3740 smime(16) id-aa(2) 25} 3742 ESCTimeStampToken ::= TimeStampToken 3744 Internet Draft Electronic Signature Formats 3746 -- Time-Stamped Certificates and CRLs 3748 id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) 3749 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3750 smime(16) id-aa(2) 26} 3752 TimestampedCertsCRLs ::= TimeStampToken 3754 -- Archive Timestamp 3756 id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) 3757 member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 3758 smime(16) id-aa(2) 27} 3760 ArchiveTimeStampToken ::= TimeStampToken 3762 -- Signature Policy Specification 3763 -- ============================== 3765 SignaturePolicy ::= SEQUENCE { 3766 signPolicyHashAlg AlgorithmIdentifier, 3767 signPolicyInfo SignPolicyInfo, 3768 signPolicyHash SignPolicyHash OPTIONAL } 3770 SignPolicyHash ::= OCTET STRING 3772 SignPolicyInfo ::= SEQUENCE { 3773 signPolicyIdentifier SignPolicyId, 3774 dateOfIssue GeneralizedTime, 3775 policyIssuerName PolicyIssuerName, 3776 fieldOfApplication FieldOfApplication, 3777 signatureValidationPolicy SignatureValidationPolicy, 3778 signPolExtensions SignPolExtensions 3779 OPTIONAL 3780 } 3782 SignPolicyId ::= OBJECT IDENTIFIER 3784 PolicyIssuerName ::= GeneralNames 3786 FieldOfApplication ::= DirectoryString 3788 SignatureValidationPolicy ::= SEQUENCE { 3789 signingPeriod SigningPeriod, 3790 commonRules CommonRules, 3791 commitmentRules CommitmentRules, 3792 signPolExtensions SignPolExtensions OPTIONAL 3793 } 3795 Internet Draft Electronic Signature Formats 3797 SigningPeriod ::= SEQUENCE { 3798 notBefore GeneralizedTime, 3799 notAfter GeneralizedTime OPTIONAL } 3801 CommonRules ::= SEQUENCE { 3802 signerAndVeriferRules [0] SignerAndVerifierRules 3803 OPTIONAL, 3804 signingCertTrustCondition [1] SigningCertTrustCondition 3805 OPTIONAL, 3806 timeStampTrustCondition [2] TimestampTrustCondition 3807 OPTIONAL, 3808 attributeTrustCondition [3] AttributeTrustCondition 3809 OPTIONAL, 3810 algorithmConstraintSet [4] AlgorithmConstraintSet 3811 OPTIONAL, 3812 signPolExtensions [5] SignPolExtensions 3813 OPTIONAL 3814 } 3816 CommitmentRules ::= SEQUENCE OF CommitmentRule 3818 CommitmentRule ::= SEQUENCE { 3819 selCommitmentTypes SelectedCommitmentTypes, 3820 signerAndVeriferRules [0] SignerAndVerifierRules 3821 OPTIONAL, 3822 signingCertTrustCondition [1] SigningCertTrustCondition 3823 OPTIONAL, 3824 timeStampTrustCondition [2] TimestampTrustCondition 3825 OPTIONAL, 3826 attributeTrustCondition [3] AttributeTrustCondition 3827 OPTIONAL, 3828 algorithmConstraintSet [4] AlgorithmConstraintSet 3829 OPTIONAL, 3830 signPolExtensions [5] SignPolExtensions 3831 OPTIONAL 3832 } 3834 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 3835 empty NULL, 3836 recognizedCommitmentType CommitmentType } 3838 CommitmentType ::= SEQUENCE { 3839 identifier CommitmentTypeIdentifier, 3840 fieldOfApplication [0] FieldOfApplication OPTIONAL, 3841 semantics [1] DirectoryString OPTIONAL } 3843 SignerAndVerifierRules ::= SEQUENCE { 3844 signerRules SignerRules, 3845 verifierRules VerifierRules } 3847 Internet Draft Electronic Signature Formats 3849 SignerRules ::= SEQUENCE { 3850 externalSignedData BOOLEAN OPTIONAL, 3851 -- True if signed data is external to CMS structure 3852 -- False if signed data part of CMS structure 3853 -- not present if either allowed 3854 mandatedSignedAttr CMSAttrs, 3855 -- Mandated CMS signed attributes 3856 mandatedUnsignedAttr CMSAttrs, 3857 -- Mandated CMS unsigned attributed 3858 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 3859 -- Mandated Certificate Reference 3860 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 3861 -- Mandated Certificate Info 3862 signPolExtensions [2] SignPolExtensions OPTIONAL 3863 } 3865 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 3867 CertRefReq ::= ENUMERATED { 3868 signerOnly (1), 3869 -- Only reference to signer cert mandated 3870 fullPath (2) 3871 -- References for full cert path up to a trust 3872 -- point required 3873 } 3875 CertInfoReq ::= ENUMERATED { 3876 none (0) , 3877 -- No mandatory requirements 3878 signerOnly (1) , 3879 -- Only reference to signer cert mandated 3880 fullPath (2) 3881 -- References for full cert path up to a 3882 -- trust point mandated 3883 } 3885 VerifierRules ::= SEQUENCE { 3886 mandatedUnsignedAttr MandatedUnsignedAttr, 3887 signPolExtensions SignPolExtensions OPTIONAL 3888 } 3890 MandatedUnsignedAttr ::= CMSAttrs 3891 -- Mandated CMS unsigned attributed 3893 Internet Draft Electronic Signature Formats 3895 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 3897 CertificateTrustPoint ::= SEQUENCE { 3898 trustpoint Certificate, 3899 -- self-signed certificate 3900 pathLenConstraint [0] PathLenConstraint OPTIONAL, 3901 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 3902 -- If not present "any policy" 3903 nameConstraints [2] NameConstraints OPTIONAL, 3904 policyConstraints [3] PolicyConstraints OPTIONAL } 3906 PathLenConstraint ::= INTEGER (0..MAX) 3908 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 3910 CertPolicyId ::= OBJECT IDENTIFIER 3912 NameConstraints ::= SEQUENCE { 3913 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 3914 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 3916 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 3918 GeneralSubtree ::= SEQUENCE { 3919 base GeneralName, 3920 minimum [0] BaseDistance DEFAULT 0, 3921 maximum [1] BaseDistance OPTIONAL } 3923 BaseDistance ::= INTEGER (0..MAX) 3925 PolicyConstraints ::= SEQUENCE { 3926 requireExplicitPolicy [0] SkipCerts OPTIONAL, 3927 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 3929 SkipCerts ::= INTEGER (0..MAX) 3931 CertRevReq ::= SEQUENCE { 3932 endCertRevReq RevReq, 3933 caCerts [0] RevReq 3934 } 3936 RevReq ::= SEQUENCE { 3937 enuRevReq EnuRevReq, 3938 exRevReq SignPolExtensions OPTIONAL} 3940 Internet Draft Electronic Signature Formats 3942 EnuRevReq ::= ENUMERATED { 3943 clrCheck (0), 3944 -- Checks must be made against current CRLs 3945 -- (or authority revocation lists) 3946 ocspCheck (1), 3947 -- The revocation status must be checked using 3948 -- the Online Certificate Status Protocol (RFC 2450) 3949 bothCheck (2), 3950 -- Both CRL and OCSP checks must be carried out 3951 eitherCheck (3), 3952 -- At least one of CRL or OCSP checks must be carried out 3953 noCheck (4), 3954 -- no check is mandated 3955 other (5) 3956 -- Other mechanism as defined by signature poilicy 3957 -- extension 3958 } 3960 SigningCertTrustCondition ::= SEQUENCE { 3961 signerTrustTrees CertificateTrustTrees, 3962 signerRevReq CertRevReq 3963 } 3965 TimestampTrustCondition ::= SEQUENCE { 3966 ttsCertificateTrustTrees [0] CertificateTrustTrees 3967 OPTIONAL, 3968 ttsRevReq [1] CertRevReq 3969 OPTIONAL, 3970 ttsNameConstraints [2] NameConstraints 3971 OPTIONAL, 3972 cautionPeriod [3] DeltaTime 3973 OPTIONAL, 3974 signatureTimestampDelay [4] DeltaTime 3975 OPTIONAL } 3977 DeltaTime ::= SEQUENCE { 3978 deltaSeconds INTEGER, 3979 deltaMinutes INTEGER, 3980 deltaHours INTEGER, 3981 deltaDays INTEGER } 3983 AttributeTrustCondition ::= SEQUENCE { 3984 attributeMandated BOOLEAN, 3985 -- Attribute must be present 3986 howCertAttribute HowCertAttribute, 3987 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 3988 attrRevReq [1] CertRevReq OPTIONAL, 3989 attributeConstraints [2] AttributeConstraints OPTIONAL } 3991 Internet Draft Electronic Signature Formats 3993 HowCertAttribute ::= ENUMERATED { 3994 claimedAttribute (0), 3995 certifiedAttribtes (1), 3996 either (2) } 3998 AttributeConstraints ::= SEQUENCE { 3999 attributeTypeConstarints [0] AttributeTypeConstraints 4000 OPTIONAL, 4001 attributeValueConstarints [1] AttributeValueConstraints 4002 OPTIONAL } 4004 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 4006 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 4008 AlgorithmConstraintSet ::= SEQUENCE { 4009 -- Algorithm constrains on: 4010 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 4011 -- signer 4012 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 4013 -- issuer of end entity certs. 4014 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 4015 -- issuer of CA certificates 4016 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 4017 -- Attribute Authority 4018 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 4019 -- TimeStamping Authority 4020 } 4022 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 4024 AlgAndLength ::= SEQUENCE { 4025 algID OBJECT IDENTIFIER, 4026 minKeyLength INTEGER OPTIONAL, 4027 -- Minimum key length in bits 4028 other SignPolExtensions OPTIONAL 4029 } 4031 SignPolExtensions ::= SEQUENCE OF SignPolExtn 4033 SignPolExtn ::= SEQUENCE { 4034 extnID OBJECT IDENTIFIER, 4035 extnValue OCTET STRING } 4037 END -- ETS-ElectronicSignature-97Syntax 4039 Internet Draft Electronic Signature Formats 4041 Annex B (informative): 4043 General Description 4045 This annex captures the concepts that apply to this document and the 4046 rational for the elements of the specification defined using ASN.1 in 4047 the main text of this document. 4049 The specification below includes a description why the component is 4050 needed, with a brief description of the vulnerabilities and threats and 4051 the manner by which they are countered. 4053 B.1 The Signature Policy 4055 The signature policy is a set of rules for the creation and validation 4056 of an electronic signature, under which the signature can be determined 4057 to be valid. A given legal/contractual context may recognize a 4058 particular signature policy as meeting its requirements. A signature 4059 policy may be issued, for example, by a party relying on the electronic 4060 signatures and selected by the signer for use with that relying party. 4061 Alternatively, a signature policy may be established through an 4062 electronic trading association for use amongst its members. Both the 4063 signer and verifier use the same signature policy. 4065 A signature policy has a globally unique reference, which is bound to 4066 an electronic signature by the signer as part of the signature 4067 calculation. 4069 The signature policy needs to be available in human readable form so 4070 that it can be assessed to meet the requirements of the legal and 4071 contractual context in which it is being applied. To facilitate the 4072 automatic processing of an electronic signature the parts of the 4073 signature policy which specify the electronic rules for the creation 4074 and validation of the electronic signature also needs to be in a 4075 computer processable form. 4077 The signature policy thus includes the following: 4079 * Rules, which apply to functionality, covered by this document 4080 (referred to as the Signature Validation Policy). 4081 * Rules which may be implied through adoption of Certificate 4082 Policies that apply to the electronic signature (e.g. rules for 4083 ensuring the secrecy of the private signing key). 4084 * Rules, which relate to the environment used by the signer, 4085 e.g. the use of an agreed CAD (Card Accepting Device) used 4086 in conjunction with a smart card. 4088 The Signature Validation Policy may be structured so that it can be 4089 computer processable. The current document includes, as an option, a 4090 formal structure for the signature validation policy based on the used 4091 of Abstract Syntax Notation 1 (ASN.1). Other formats of the signature 4092 validation policy are allowed by this document. However, for a given 4093 signature policy there must be one definitive form that has a unique 4094 binary encoded value. 4096 Internet Draft Electronic Signature Formats 4098 The Signature Validation Policy includes rules regarding use of TSPs 4099 (CA, Attribute Authorities, Time Stamping Authorities) as well as rules 4100 defining the components of the electronic signature that must be 4101 provided by the signer with data required by the verifier to provide 4102 long term proof. 4104 B.2 Signed Information 4106 The information being signed may be defined as a MIME-encapsulated 4107 message which can be used to signal the format of the content in order 4108 to select the right display or application. It can be composed of 4109 formatted text (e.g. EDIFACT), free text or of fields from an 4110 electronic form (e-form). For example, the Adobe(tm) format "pdf" may 4111 be used or the eXtensible Mark up Language (XML). 4113 B.3 Components of an Electronic Signature 4115 B.3.1 Reference to the Signature Policy 4117 The definition of electronic signature includes: "a commitment has been 4118 explicitly endorsed under a "Signature policy", at a given time, by a 4119 signer under an identifier, e.g. a name or a pseudonym, and optionally 4120 a role". 4122 When two independent parties want to evaluate an electronic signature, 4123 it is fundamental that they get the same result. To meet this 4124 requirement the technical components and technical aspects used in 4125 creating the signature must be referenced, this is provided by a 4126 reference to the "Signature Validation Policy". The "Signature 4127 Validation Policy" defines: 4129 * the components of an electronic signature to be provided by the 4130 signer; 4131 * any additional components (i.e. verifier components) used to 4132 validate an electronic signature at the time of receipt by a 4133 verifier and later by an arbitrator, auditor or other 4134 independent parties. 4136 By signing over the signature policy identifier, the algorithm 4137 identifier and the hash of the signature policy, the signer explicitly 4138 indicates that he or she has applied the signature policy in creating 4139 the signature. Thus, undertakes any commitments implied by the 4140 signature policy, any indication of commitment type included in the 4141 electronic signature, and the user data that is signed. 4143 The hash algorithm identifier and value is included to ensure that both 4144 the signer and verifier use exactly the same signature policy. This 4145 unambiguously binds the signer and verifier to same definitive form of 4146 the signature policy has a unique binary encoding. 4148 Internet Draft Electronic Signature Formats 4150 In order to identify unambiguously the "Signature Validation Policy" to 4151 be used to verify the signature an identifier and hash of the 4152 "Signature policy" must be part of the signed data. Additional 4153 information about the policy (e.g. web reference to the document) may 4154 be carried as "qualifiers" to the signature policy identifier 4156 B.3.2 Commitment Type Indication 4158 The definition of electronic signature includes: "a commitment has been 4159 explicitly endorsed under a signature policy, at a given time, by a 4160 signer under an identifier, e.g. a name or a pseudonym, and optionally a 4161 role". 4163 The commitment type can be indicated in the electronic signature 4164 either: 4166 * explicitly using a "commitment type indication" in the 4167 electronic signature; 4169 * implicitly or explicitly from the semantics of the signed data. 4171 If the indicated commitment type is explicit using a "commitment type 4172 indication" in the electronic signature , acceptance of a verified 4173 signature implies acceptance of the semantics of that commitment type. 4174 The semantics of explicit commitment types indications must be 4175 specified either as part of the signature policy or may be registered 4176 for generic use across multiple policies. 4178 If a signature includes a commitment type indication other than one of 4179 those recognized under the signature policy the signature must be 4180 treated as invalid. 4182 How commitment is indicated using the semantics of the data being 4183 signed is outside the scope of this document. 4185 NOTE: Examples of commitment indicated through the semantics of the 4186 data being signed, are: 4188 * An explicit commitment made by the signer indicated by the type 4189 of data being signed over. Thus, the data structure being 4190 signed can have an explicit commitment within the context of the 4191 application (e.g. EDIFACT purchase order). 4193 * An implicit commitment which is a commitment made by the signer 4194 because the data being signed over has specific semantics 4195 (meaning) which is only interpretable by humans, 4196 (i.e. free text). 4198 Internet Draft Electronic Signature Formats 4200 B.3.4 Certificate Identifier from the Signer 4202 The definition of the ETSI electronic signature includes: "a commitment 4203 has been explicitly endorsed under a signature policy, at a given time, 4204 by a signer under an identifier, e.g. a name or a pseudonym, and 4205 optionally a role." 4207 In many real life environments users will be able to get from different 4208 CAs or even from the same CA, different certificates containing the 4209 same public key for different names. The prime advantage is that a user 4210 can use the same private key for different purposes. Multiple use of 4211 the private key is an advantage when a smart card is used to protect 4212 the private key, since the storage of a smart card is always limited. 4213 When several CAs are involved, each different certificate may contain a 4214 different identity, e.g. as a national or as an employee from a 4215 company. Thus when a private key is used for various purposes, the 4216 certificate is needed to clarify the context in which the private key 4217 was used when generating the signature. Where there is the possibility 4218 of multiple use of private keys it is necessary for the 4219 signer to indicate to the verifier the precise certificate to be used. 4221 Many current schemes simply add the certificate after the signed data 4222 and thus are subject to various substitution attacks. An example of a 4223 substitution attack is a "bad" CA that would issue a certificate to 4224 someone with the public key of someone else. If the certificate from 4225 the signer was simply appended to the signature and thus not protected 4226 by the signature, any one could substitute one certificate by another 4227 and the message would appear to be signed by some one else. 4229 In order to counter this kind of attack, the identifier of the signer 4230 has to be protected by the digital signature from the signer. 4232 Although it does not provide the same advantages as the previous 4233 technique, another technique to counter that threat has been 4234 identified. It requires all CAs to perform a Proof Of Possession of the 4235 private key at the time of registration. The problem with that 4236 technique is that it does not provide any guarantee at the time of 4237 verification and only some proof "after the event" may be obtained, if 4238 and only if the CA keeps the Proof Of Possession in audit trail. 4240 In order to identify unambiguously the certificate to be used for the 4241 verification of the signature an identifier of the certificate from the 4242 signer must be part of the signed data. 4244 B.3.5 Role Attributes 4246 The definition of electronic signature includes: "a commitment has been 4247 explicitly endorsed under a non repudiation security policy, at a given 4248 time, by a signer under an identifier, e.g. a name or a pseudonym, and 4249 optionally a role. " 4251 Internet Draft Electronic Signature Formats 4253 While the name of the signer is important, the position of the signer 4254 within a company or an organization can be even more important. Some 4255 contracts may only be valid if signed by a user in a particular role, 4256 e.g. a Sales Director. In many cases whom the sales Director really is, 4257 is not that important but being sure that the signer is empowered by 4258 his company to be the Sales Director is fundamental. 4260 This document defines two different ways for providing this feature: 4262 * by placing a claimed role name in the CMS signed 4263 attributes field; 4264 * by placing a attribute certificate containing a certified 4265 role name in the CMS signed attributes field. 4267 NOTE: Another possible approach would have been to use additional 4268 attributes containing the roles name(s) in the signer's certificate. 4269 However, it was decided not to follow this approach as it breaks the 4270 basic philosophy of the certificate being issued for one primary 4271 purpose. Also, by using separate certificates for management of the 4272 signer's identity certificate and management of additional roles can 4273 simplify the management, as new identity keys need not be issued if a 4274 use of role is to be changed. 4276 B.3.5.1 Claimed Role 4278 The signer may be trusted to state his own role without any certificate 4279 to corroborate this claim. In which case the claimed role can be added 4280 to the signature as a signed attribute. 4282 B.3.5.2 Certified Role 4284 Unlike public key certificates that bind an identifier to a public key, 4285 Attribute Certificates bind the identifier of a certificate to some 4286 attributes, like a role. An Attribute Certificate is NOT issued by a CA 4287 but by an Attribute Authority (AA). The Attribute Authority will be 4288 most of the time under the control of an organization or a company that 4289 is best placed to know which attributes are relevant for which 4290 individual. The Attribute Authority may use or point to public key 4291 certificates issued by any CA, provided that the appropriate trust may 4292 be placed in that CA. Attribute Certificates may have various periods 4293 of validity. That period may be quite short, e.g. one day. While this 4294 requires that a new Attribute Certificate is obtained every day, valid 4295 for that day, this can be advantageous since revocation of such 4296 certificates may not be needed. When signing, the signer will have to 4297 specify which Attribute Certificate it selects. In order to do 4298 so, the Attribute Certificate will have to be included in the signed 4299 data in order to be protected by the digital signature from the signer. 4301 Internet Draft Electronic Signature Formats 4303 In order to identify unambiguously the attribute certificate(s) to be 4304 used for the verification of the signature an identifier of the 4305 attribute certificate(s) from the signer must be part of the signed 4306 data. 4308 B.3.6 Signer Location 4310 In some transactions the purported location of the signer at the time 4311 he or she applies his signature may need to be indicated. For this 4312 reason an optional location indicator must be able to be included. 4314 In order to provide indication of the location of the signer at the 4315 time he or she applied his signature a location attribute may be 4316 included in the signature. 4318 B.3.7 Signing Time 4320 The definition of electronic signature includes: "a commitment has been 4321 explicitly endorsed under a signature policy, at a given time, by a 4322 signer under an identifier, e.g. a name or a pseudonym, and optionally a 4323 role. " 4325 There are several ways to address this problem. The solution adopted in 4326 this document is to sign over a time which the signer claims is the 4327 signing time (i.e. claimed signing time) and to require a trusted time 4328 stamp to be obtained when building a ES with Timestamp. When a verifier 4329 accepts a signature, the two times must be within acceptable limits. 4331 The solution that is adopted in this document offers the major 4332 advantage that electronic signatures can be generated without any on- 4333 line connection to a trusted time source (i.e. they may be generated 4334 off-line). 4336 Thus two dates and two signatures are required: 4337 * a signing time indicated by the signer and which is part of 4338 the data signed by the signer (i.e. part of the basic electronic 4339 signature); 4340 * a time indicated by a TimeStamping Authority (TSA) which is 4341 signed over the digital signature value of the basic electronic 4342 signature. The signer, verifier or both may obtain the TSA 4343 timestamp. 4345 In order for an electronic signature to be valid under a signature 4346 policy, it must be timestamped by a TSA where the signing time as 4347 indicated by the signer and the time of time stamping as indicated by a 4348 TSA must be "close enough" to meet the requirements of the signature 4349 validation policy. 4351 "Close enough" means a few minutes, hours or even days according to the 4352 "Signature Validation Policy". 4354 Internet Draft Electronic Signature Formats 4356 NOTE: The need for Timestamping is further explained in clause B.4.5. 4357 A further optional attribute is defined in this document to timestamp 4358 the content, to provide proof of the existence of the content, at the 4359 time indicated by the timestamp. 4361 Using this optional attribute a trusted secure time may be obtained 4362 before the document is signed and included under the digital signature. 4363 This solution requires an on-line connection to a trusted timestamping 4364 service before generating the signature and may not represent the 4365 precise signing time, since it can be obtained in advance. However, 4366 this optional attribute may be used by the signer to prove that the 4367 signed object existed before the date included in the timestamp (see 4368 4.12.3, Content Timestamp). 4370 Also, the signing time should be between the time indicated by this 4371 timestamp and time indicated by the ES-T timestamp. 4373 B.4 Components of Validation Data 4375 B.4.1 Revocation Status Information 4377 A verifier will have to prove that the certificate of the signer was 4378 valid at the time of the signature. This can be done by either: 4379 * using Certificate Revocation Lists (CRLs); 4380 * using responses from an on-line certificate status server 4381 (for example; obtained through the OCSP protocol). 4383 B.4.2 CRL Information 4385 When using CRLs to get revocation information, a verifier will have to 4386 make sure that he or she gets at the time of the first verification the 4387 appropriate certificate revocation information from the signer's CA. 4388 This should be done as soon as possible to minimize the time delay 4389 between the generation and verification of the signature. This involves 4390 checking that the signer certificate serial number is not included in 4391 the CRL. The signer, the verifier or any other third party may obtain 4392 either this CRL. If obtained by the signer, then it must be conveyed 4393 to the verifier. It may be convenient to archive the CRL for ease of 4394 subsequent verification or arbitration. 4396 Alternatively, provided the CRL is archived elsewhere which is 4397 accessible for the purpose of arbitration, then the serial number of 4398 the CRL used may be archived together with the verified electronic 4399 signature. 4401 Internet Draft Electronic Signature Formats 4403 It may happen that the certificate serial number appears in the CRL but 4404 with the status "suspended" (i.e. on hold). In such a case, the 4405 electronic signature is not yet valid, since it is not possible to know 4406 whether the certificate will or will not be revoked at the end of the 4407 suspension period. If a decision has to be taken immediately then the 4408 signature has to be considered as invalid. If a decision can wait until 4409 the end of the suspension period, then two cases are possible: 4411 * the certificate serial number has disappeared from the list 4412 and thus the certificate can be considered as valid and that CRL 4413 must be captured and archived either by the verifier or 4414 elsewhere and be kept accessible for the purpose of arbitration. 4416 * the certificate serial number has been maintained on the list 4417 with the status definitively revoked and thus the electronic 4418 signature must be considered as invalid and discarded. 4420 At this point the verifier may be convinced that he or she got a valid 4421 signature, but is not yet in a position to prove at a later time that 4422 the signature was verified as valid. Before addressing this point, an 4423 alternative to CRL is to use OCSP responses. 4425 B.4.3 OCSP Information 4427 When using OCSP to get revocation information , a verifier will have to 4428 make sure that he or she gets at the time of the first verification an 4429 OCSP response that contains the status "valid". This should be done as 4430 soon as possible after the generation of the signature. The signer, the 4431 verifier or any other third party may fetch this OCSP response. Since 4432 OSCP responses are transient and thus are not archived by any TSP 4433 including CA, it is the responsibility of every verifier to make sure 4434 that it is stored in a safe place. The simplest way is to store them 4435 associated with the electronic signature. An alternative would be to 4436 store them in some storage so that they can then be easily retrieved. 4438 In the same way as for the case of the CRL, it may happen that the 4439 certificate is declared as invalid but with the secondary status 4440 "suspended". 4442 In such a case, the electronic signature is not yet valid, since it is 4443 not possible to know whether the certificate will or will not be 4444 revoked at the end of the suspension period. If a decision has to be 4445 taken immediately then the electronic signature has to be considered as 4446 invalid. If a decision can wait until the end of the suspension period, 4447 then two cases are possible: 4449 * An OCSP response with a valid status is obtained at a later date 4450 and thus the certificate can be considered as valid and that 4451 OCSP response must be captured. 4453 * An OCSP response with an invalid status is obtained with a 4454 secondary status indicating that the certificate is definitively 4455 revoked and thus the electronic signature must be considered as 4456 invalid and discarded. 4458 Internet Draft Electronic Signature Formats 4460 As in the CRL case, at this point, the verifier may be convinced that 4461 he or she got a valid signature, but is not yet in a position to prove 4462 at a later time that the signature was verified as valid. 4464 B.4.4 Certification Path 4466 A verifier will have to prove that the certification path was valid, at 4467 the time of the signature, up to a trust point according to the naming 4468 constraints and the certificate policy constraints from the "Signature 4469 Validation Policy". It will be necessary to capture all the 4470 certificates from the certification path, starting with those from the 4471 signer and ending up with those of the self-signed certificate from one 4472 trusted root of the "Signature Validation Policy". In addition, it will 4473 be necessary to capture the Authority Revocation Lists (ARLs) to prove 4474 than none of the CAs from the chain was revoked at the time of the 4475 signature. 4477 As in the OCSP case, at this point, the verifier may be convinced that 4478 he or she got a valid signature, but is not yet in a position to prove 4479 at a later time that the signature was verified as valid. 4481 B.4.5 Timestamping for Long Life of Signature 4483 An important property for long standing signatures is that a signature, 4484 having been found once to be valid, must continue to be so months or 4485 years later. 4487 A signer, verifier or both may be required to provide on request, proof 4488 that a digital signature was created or verified during the validity 4489 period of the all the certificates that make up the certificate path. 4490 In this case, the signer, verifier or both will also be required to 4491 provide proof that all the user and CA certificates used were not 4492 revoked when the signature was created or verified. 4494 It would be quite unacceptable, to consider a signature as invalid even 4495 if the keys or certificates were later compromised. Thus there is a 4496 need to be able to demonstrate that the signature keys was valid around 4497 the time that the signature was created to provide long term evidence 4498 of the validity of a signature. 4500 It could be the case that a certificate was valid at the time of the 4501 signature but revoked some time later. In this event, evidence must be 4502 provided that the document was signed before the signing key was 4503 revoked. 4505 Timestamping by a Time Stamping Authority (TSA) can provide such 4506 evidence. A time stamp is obtained by sending the hash value of the 4507 given data to the TSA. The returned "timestamp" is a signed document 4508 that contains the hash value, the identity of the TSA, and the time of 4509 stamping. This proves that the given data existed before the time of 4510 stamping. Timestamping a digital signature (by sending a hash of the 4511 signature to the TSA) before the revocation of the signer's private 4512 key, provides evidence that the signature has been created before the 4513 key was revoked. 4515 Internet Draft Electronic Signature Formats 4517 If a recipient wants to hold a valid electronic signature he will have 4518 to ensure that he has obtained a valid time stamp for it, before that 4519 key (and any key involved in the validation) is revoked. The sooner the 4520 timestamp is obtained after the signing time, the better. 4522 It is important to note that signatures may be generated "off-line" and 4523 time-stamped at a later time by anyone, for example by the signer or 4524 any recipient interested in the value of the signature. The time stamp 4525 can thus be provided by the signer together with the signed document, 4526 or obtained by the recipient following receipt of the signed document. 4528 The time stamp is NOT a component of the Electronic Signature, but the 4529 essential component of the ES with Timestamp. 4531 It is required in this document that signer's digital signature value 4532 is timestamped by a trusted source, known as a TimeStamping Authority. 4534 This document requires that the signer's digital signature value is 4535 timestamped by a trusted source before the electronic signature can 4536 become a ES with Complete validation data (ES-C). The acceptable TSAs 4537 are specified in the Signature Validation Policy. 4539 Should both the signer and verifier be required to timestamp the 4540 signature value to meet the requirements of the signature policy, the 4541 signature policy MAY specify a permitted time delay between the two 4542 time stamps. 4544 B.4.6 Timestamping for Long Life of Signature before CA Key Compromises 4546 Timestamped extended electronic signatures are needed when there is a 4547 requirement to safeguard against the possibility of a CA key in the 4548 certificate chain ever being compromised. A verifier may be required to 4549 provide on request, proof that the certification path and the 4550 revocation information used a the time of the signature were valid, 4551 even in the case where one of the issuing keys or OCSP responder keys 4552 is later compromised. 4554 The current document defines two ways of using timestamps to protect 4555 against this compromise: 4557 * Timestamp the ES with Complete validation data, when an OCSP 4558 response is used to get the status of the certificate from the 4559 signer. 4560 * Timestamp only the certification path and revocation information 4561 references when a CRL is used to get the status of the 4562 certificate from the signer. 4564 NOTE: the signer, verifier or both may obtain the timestamp. 4566 Internet Draft Electronic Signature Formats 4568 B.4.6.1 Timestamping the ES with Complete validation data 4570 When an OCSP response is used, it is necessary to time stamp in 4571 particular that response in the case the key from the responder would 4572 be compromised. Since the information contained in the OCSP response is 4573 user specific and time specific, an individual time stamp is needed for 4574 every signature received. Instead of placing the time stamp only over 4575 the certification path references and the revocation information 4576 references, which include the OCSP response, the time stamp is placed 4577 on the ES-C. Since the certification path and revocation information 4578 references are included in the ES with Complete validation data they 4579 are also protected. For the same cryptographic price, this provides an 4580 integrity mechanism over the ES with Complete validation data. Any 4581 modification can be immediately detected. It should be noticed that 4582 other means of protecting/detecting the integrity of the ES with 4583 Complete Validation Data exist and could be used. 4585 Although the technique requires a time stamp for every signature, it is 4586 well suited for individual users wishing to have an integrity protected 4587 copy of all the validated signatures they have received. 4589 By timestamping the complete electronic signature, including the 4590 digital signature as well as the references to the certificates and 4591 revocation status information used to support validation of that 4592 signature, the timestamp ensures that there is no ambiguity in the 4593 means of validating that signature. 4595 This technique is referred to as ES with eXtended validation data (ES- 4596 X), type 1 Timestamped in this document. 4598 NOTE: Trust is achieved in the references by including a hash of the 4599 data being referenced. 4601 If it is desired for any reason to keep a copy of the additional data 4602 being referenced, the additional data may be attached to the electronic 4603 signature, in which case the electronic signature becomes a ES-X Long 4604 as defined by this document. 4606 A ES-X Long Timestamped is simply the concatenation of a ES-X 4607 Timestamped with a copy of the additional data being referenced. 4609 B.4.6.2 Timestamping Certificates and Revocation Information 4611 References Timestamping each ES with Complete validation data as 4612 defined above may not be efficient, particularly when the same set of 4613 CA certificates and CRL information is used to validate many 4614 signatures. 4616 Internet Draft Electronic Signature Formats 4618 Timestamping CA certificates will stop any attacker from issuing bogus 4619 CA certificates that could be claimed to existing before the CA key was 4620 compromised. Any bogus timestamped CA certificates will show that the 4621 certificate was created after the legitimate CA key was compromised. In 4622 the same way, timestamping CA CRLs, will stop any attacker from issuing 4623 bogus CA CRLs which could be claimed to existing before the CA key was 4624 compromised. 4626 Timestamping of commonly used certificates and CRLs can be done 4627 centrally, e.g. inside a company or by a service provider. This method 4628 reduces the amount of data the verifier has to timestamp, for example 4629 it could reduce to just one time stamp per day (i.e. in the case were 4630 all the signers use the same CA and the CRL applies for the whole day). 4631 The information that needs to be time stamped is not the actual 4632 certificates and CRLs but the unambiguous references to those 4633 certificates and CRLs. 4635 To comply with extended validation data, type 2 Timestamped, this 4636 document requires the following: 4637 * All the CA certificates references and revocation information 4638 references (i.e. CRLs) used in validating the ES-C are covered 4639 by one or more timestamp. 4641 Thus a ES-C with a timestamp signature value at time T1, can be proved 4642 valid if all the CA and CRL references are timestamped at time T1+. 4644 B.4.7 Timestamping for Long Life of Signature 4646 Advances in computing increase the probability of being able to break 4647 algorithms and compromise keys. There is therefore a requirement to be 4648 able to protect electronic signatures against this probability. 4650 Over a period of time weaknesses may occur in the cryptographic 4651 algorithms used to create an electronic signature (e.g. due to the time 4652 available for cryptoanalysis, or improvements in cryptoanalytical 4653 techniques). Before this such weaknesses become likely, a verifier 4654 should take extra measures to maintain the validity of the electronic 4655 signature. Several techniques could be used to achieve this goal 4656 depending on the nature of the weakened cryptography. In order to 4657 simplify, a single technique, called Archive validation data, covering 4658 all the cases is being used in this document. 4660 Archive validation data consists of the Complete validation data and 4661 the complete certificate and revocation data, time stamped together 4662 with the electronic signature. The Archive validation data is 4663 necessary if the hash function and the crypto algorithms that were used 4664 to create the signature are no longer secure. Also, if it cannot be 4665 assumed that the hash function used by the Time Stamping Authority is 4666 secure, then nested timestamps of Archived Electronic Signature are 4667 required. 4669 Internet Draft Electronic Signature Formats 4671 The potential for Trusted Service Provider (TSP) key compromise should 4672 be significantly lower than user keys, because TSP(s) are expected to 4673 use stronger cryptography and better key protection. It can be expected 4674 that new algorithms (or old ones with greater key lengths) will be 4675 used. In such a case, a sequence of timestamps will protect against 4676 forgery. Each timestamp needs to be affixed before either the 4677 compromise of the signing key or of the cracking of the algorithms used 4678 by the TSA. TSAs (TimeStamping Authorities) should have long keys (e.g. 4679 which at the time of drafting this document was 2048 bits for the 4680 signing RSA algorithm) and/or a "good" or different algorithm. 4682 Nested timestamps will also protect the verifier against key compromise 4683 or cracking the algorithm on the old electronic signatures. 4685 The process will need to be performed and iterated before the 4686 cryptographic algorithms used for generating the previous time stamp 4687 are no longer secure. Archive validation data may thus bear multiple 4688 embedded time stamps. 4690 B.4.8 Reference to Additional Data 4692 Using type 1 or 2 of Timestamped extended validation data verifiers 4693 still needs to keep track of all the components that were used to 4694 validate the signature, in order to be able to retrieve them again 4695 later on. These components may be archived by an external source like a 4696 trusted service provider, in which case referenced information that is 4697 provided as part of the ES with Complete validation data (ES-C) is 4698 adequate. The actual certificates and CRL information reference in the 4699 ES-C can be gathered when needed for arbitration. 4701 B.4.9 Timestamping for Mutual Recognition 4703 In some business scenarios both the signer and the verifier need to 4704 timestamp their own copy of the signature value. Ideally the two 4705 timestamps should be as close as possible to each other. 4707 Example: A contract is signed by two parties A and B representing their 4708 respective organizations, to timestamp the signer and verifier data two 4709 approaches are possible: 4711 * under the terms of the contract pre-defined common "trusted" 4712 TSA may be used; 4713 * if both organizations run their own timestamping services, A 4714 and B can have the transaction timestamped by these two 4715 timestamping services.In the latter case, the electronic 4716 signature will only be considered as valid, if both timestamps 4717 were obtained in due time (i.e. there should not be a long 4718 delay between obtaining the two timestamps). Thus, neither A 4719 nor B can repudiate the signing time indicated by their own 4720 timestamping service. 4722 Therefore, A and B do not need to agree on a common "trusted" TSA to 4723 get a valid transaction. 4725 Internet Draft Electronic Signature Formats 4727 It is important to note that signatures may be generated "off-line" and 4728 timestamped at a later time by anyone, e.g. by the signer or any 4729 recipient interested in validating the signature. The timestamp over 4730 the signature from the signer can thus be provided by the signer 4731 together with the signed document, and /or obtained by the verifier 4732 following receipt of the signed document. 4734 The business scenarios may thus dictate that one or more of the long- 4735 term signature timestamping methods describe above be used. This will 4736 need to be part of a mutually agreed the Signature Validation Policy 4737 with is part of the overall signature policy under which digital 4738 signature may be used to support the business relationship between the 4739 two parties. 4741 B.4.10 TSA Key Compromise 4743 TSA servers should be built in such a way that once the private 4744 signature key is installed, that there is minimal likelihood of 4745 compromise over as long as possible period. Thus the validity period 4746 for the TSA's keys should be as long as possible. 4748 Both the ES-T and the ES-C contain at least one time stamp over the 4749 signer's signature. In order to protect against the compromise of the 4750 private signature key used to produce that timestamp, the Archive 4751 validation data can be used when a different TimeStamping Authority key 4752 is involved to produce the additional timestamp. If it is believed that 4753 the TSA key used in providing an earlier timestamp may ever be 4754 compromised (e.g. outside its validity period), then the ES-A should be 4755 used. For extremely long periods this may be applied repeatedly using 4756 new TSA keys. 4758 B.5 Multiple Signatures 4760 Some electronic signatures may only be valid if they bear more than one 4761 signature. This is the case generally when a contract is signed between 4762 two parties. The ordering of the signatures may or may not be 4763 important, i.e. one may or may not need to be applied before the other. 4765 Several forms of multiple and counter signatures need to be supported, 4766 which fall into two basic categories: 4767 * independent signatures; 4768 * embedded signatures. 4769 Independent signatures are parallel signatures where the ordering of 4770 the signatures is not important. The capability to have more than one 4771 independent signature over the same data must be provided. 4773 Embedded signatures are applied one after the other and are used where 4774 the order the signatures are applied is important. The capability to 4775 sign over signed data must be provided. 4777 These forms are described in clause 4.13. All other multiple signature 4778 schemes, e.g. a signed document with a countersignature, double 4779 countersignatures or multiple signatures, can be reduced to one or more 4780 occurrence of the above two cases. 4782 Internet Draft Electronic Signature Formats 4784 Annex C (informative): 4786 C.1 Signature Policy and Signature Validation Policy 4788 The definition of electronic signature mentions: "a commitment has been 4789 explicitly endorsed under a "Signature Policy", at a given time, by a 4790 signer under an identifier, e.g. a name or a pseudonym, and optionally 4791 a role. " 4793 Electronic signatures are commonly applied within the context of a 4794 legal or contractual framework. This establishes the requirements on 4795 the electronic signatures and any special semantics (e.g. agreement, 4796 intent). These requirements may be defined in very general abstract 4797 terms or in terms of detailed rules. The specific semantics associated 4798 with an electronic signature implied by a legal or contractual 4799 framework are outside the scope of this document. 4801 If the signature policy is recognized, within the legal/contractual 4802 context, as providing commitment, then the signer explicitly agrees 4803 with terms and conditions which are implicitly or explicitly part of 4804 the signed data. 4806 When two independent parties want to evaluate an electronic signature, 4807 it is fundamental that they get the same result. It is therefore 4808 important that the conditions agreed by the signer at the time of 4809 signing are indicated to the verifier and any arbitrator. An aspect 4810 that enables this to be known by all parties is the signature policy. 4811 The technical implications of the signature policy on the electronic 4812 signature with all the validation data are called the "Signature 4813 Validation Policy". The signature validation policy specifies 4814 the rules used to validate the signature. 4816 This document does not mandate the form and encoding of the 4817 specification of the signature policy. However, for a given signature 4818 policy there must be one definitive form that has a unique binary 4819 encoded value. 4821 This document includes, as an option, a formal structure for signature 4822 validation policy based on the use of Abstract Syntax Notation 1 4823 (ASN.1). 4825 Given the specification of the signature policy and its hash value an 4826 implementation of a verification process must obey the rules defined 4827 in the specification. 4829 This document places no restriction on how it should be implemented. 4830 Provide the implementation conforms to the conformance requirements as 4831 define in clause 14.1, 14.2 and 14.3 implementation options include: 4833 Internet Draft Electronic Signature Formats 4835 A validation process that supports a specific signature policy as 4836 identified by the signature policy OID. Such an implementation should 4837 conform to a human readable description provided all the processing 4838 rules of the signature policy are clearly defined. However, if 4839 additional policies need to be supported, then such an implementation 4840 would need to be customized for each additional policy. This type of 4841 implementation may be simpler to implement initially, but can be 4842 difficult to enhance to support numerous additional signature policies. 4844 A validation process that is dynamically programmable and able to adapt 4845 its validation rules in accordance with a description of the signature 4846 policy provided in a computer-processable language. This present 4847 document defines such a policy using an ASN.1 structure (see 6.1). This 4848 type of implementation could support multiple signature policies 4849 without being modified every time, provided all the validation rules 4850 specified as part of the signature policy are known by the 4851 implementation. (i.e. only requires modification if there are 4852 additional rules specified). 4854 The precise content of a signature policy is not mandated by the 4855 current document. However, a signature policy must be sufficiently 4856 definitive to avoid any ambiguity as to its implementation 4857 requirements. It must be absolutely clear under which conditions an 4858 electronic signature should be accepted. For this reason, it should 4859 contain the following information: 4861 * General information about the signature policy which includes: 4862 - a unique identifier of the policy; 4863 - the name of the issuer of the policy; 4864 - the date the policy was issued; 4865 - the field of application of the policy. 4867 * The signature verification policy which includes: 4868 - the signing period, 4869 - a list of recognized commitment types; 4870 - rules for Use of Certification Authorities; 4871 - rules for Use of Revocation Status Information; 4872 - rules for Use of Roles; 4873 - rules for use of Timestamping and Timing; 4874 - signature verification data to be provided by the 4875 signer/collected by verifier; 4876 - any constraints on signature algorithms and key lengths. 4877 * Other signature policy rules required to meet the objectives of 4878 the signature. 4880 Variations of the validation policy rules may apply to different 4881 commitment types. 4883 Internet Draft Electronic Signature Formats 4885 C.2 Identification of Signature Policy 4887 When data is signed the signer indicates the signature policy 4888 applicable to that electronic signature by including an object 4889 identifier for the signature policy with the signature. The signer and 4890 verifier must apply the rules specified by the identified policy. In 4891 addition to the identifier of the signature policy the signer must 4892 include the hash of the signature policy, so it can be verified that 4893 the policy selected by the signer is the identical to the one being 4894 used the verifier. 4896 A signature policy may be qualified by additional information. This can 4897 includes: 4899 * A URL where a copy of the Signature Policy may be obtained; 4900 * A user notice that should be displayed when the signature is 4901 verified; 4903 If no signature policy is identified then the signature may be assumed 4904 to have been generated/verified without any policy constraints, and 4905 hence may be given no specific legal or contractual significance 4906 through the context of a signature policy. 4908 A "Signature Policy" will be identifiable by an OID (Object Identifier) 4909 and verifiable using a hash of the signature policy. 4911 C.3 General Signature Policy Information 4913 General information should be recorded about the signature policy along 4914 with the definition of the rules which form the signature policy as 4915 described in subsequent subclauses. This should include: 4917 * Policy Object Identifier: The "Signature Policy" will be 4918 identifiable by an OID (Object Identifier) whose last component 4919 (i.e. right most) is an integer that is specific to a particular 4920 version issued on the given date. 4921 * Date of issue: When the "Signature Policy" was issued. 4922 * Signature Policy Issuer name: An identifier for the body 4923 responsible for issuing the Signature Policy. This may be used 4924 by the signer or verifying in deciding if a policy is to be 4925 trusted, in which case the signer/verifier must authenticate 4926 the origin of the signature policy as coming from the identified 4927 issuer. 4928 * Signing period: The start time and date, optionally with an end 4929 time and date, for the period over which the signature policy 4930 may be used to generate electronic signatures. 4931 * Field of application: This defines in general terms the general 4932 legal/contract/application contexts in which the signature 4933 policy is to be used and the specific purposes for which the 4934 electronic signature is to be applied. 4936 Internet Draft Electronic Signature Formats 4938 C.4 Recognized Commitment Types 4940 The signature validation policy may recognize one or more types of 4941 commitment as being supported by electronic signatures produced under 4942 the security policy.If an electronic signature does not contain a 4943 recognized commitment type then the semantics of the electronic 4944 signature is dependent on the data being signed and the context in 4945 which it is being used. 4947 Only recognized commitment types are allowed in an electronic 4948 signature. 4950 The definition of a commitment type includes: 4951 * the object identifier for the commitment; 4952 * the contractual/legal/application context in which the signature 4953 may be used (e.g. submission of messages); 4954 * a description of the support provided within the terms of the 4955 context (e.g. proof that the identified source submitted the 4956 message if the signature is created when message submission is 4957 initiated). 4959 The definition of a commitment type can be registered: 4960 * as part of the validation policy; 4961 * as part of the application/contract/legal environment; 4962 * as part of generic register of definitions. 4964 The legal/contractual context will determine the rules applied to the 4965 signature, as defined by the signature policy and its recognized 4966 commitment types, make it fit for purpose intended. 4968 C.5 Rules for Use of Certification Authorities 4970 The certificate validation process of the verifier, and hence the 4971 certificates that may be used by the signer for a valid electronic 4972 signature, may be constrained by the combination of the trust point and 4973 certificate path constraints in the signature validation policy. 4975 C.5.1 Trust Points 4977 The signature validation policy defines the certification authority 4978 trust points that are to be used for signature verification. Several 4979 trust points may be specified under one signature policy. Specific 4980 trust points may be specified for a particular type of commitment 4981 defined under the signature policy. For a signature to be valid a 4982 certification path must exists between the Certification Authority 4983 that has granted the certificate selected by the signer (i.e. the used 4984 user-certificate) and one of the trust point of the "Signature 4985 Validation Policy". 4987 Internet Draft Electronic Signature Formats 4989 C.5.2 Certification Path 4991 There may be constraints on the use of certificates issued by one or 4992 more CA(s) in the certificate chain and trust points. The two prime 4993 constraints are certificate policy constraints and naming constraints: 4995 * Certificate policy constraints limit the certification chain 4996 between the user certificate and the certificate of the trusted 4997 point to a given set of certificate policies, or equivalents 4998 identified through certificate policy mapping. 4999 * The naming constraints limit the forms of names that the CA is 5000 allowed to certify. 5002 Name constraints are particularly important when a "Signature policy" 5003 identifies more than one trust point. In this case, a certificate of a 5004 particular trusted point may only be used to verify signatures from 5005 users with names permitted under the name constraint. 5007 Certificate Authorities may be organized in a tree structure, this tree 5008 structure may represent the trust relationship between various CA(s) 5009 and the users CA. Alternatively, a mesh relationship may exist where a 5010 combination of tree and peer cross-certificates may be used. The 5011 requirement of the certificate path in this document is that it 5012 provides the trust relationship between all the CAs and the signers 5013 user certificate. The starting point from a verification point of view, 5014 is the "trust point". A trust point is usually a CA that publishes 5015 self-certified certificates, is the starting point from which the 5016 verifier verifies the certificate chain. Naming constraints may 5017 apply from the trust point, in which case they apply throughout the set 5018 of certificates that make up the certificate path down to the signer's 5019 user certificate. 5021 Policy constraints can be easier to process but to be effective require 5022 the presence of a certificate policy identifier in the certificates 5023 used in a certification path. 5025 Certificate path processing, thus generally starts with one of the 5026 trust point from the signature policy and ends with the user 5027 certificate. The certificate path processing procedures defined in RFC 5028 2459 clause 6 identifies the following initial parameters that are 5029 selected by the verifier in certificate path processing: 5031 * acceptable certificate policies; 5032 * naming constraints in terms of constrained and excluded naming 5033 subtree; 5034 * requirements for explicit certificate policy indication and 5035 whether certificate policy mapping are allowed; 5036 * restrictions on the certificate path length. 5038 The signature validation policy identifies constraints on these 5039 parameters. 5041 Internet Draft Electronic Signature Formats 5043 C.5 Revocation Rules 5045 The signature policy should defines rules specifying requirements for 5046 the use of certificate revocation lists (CRLs) and/or on-line 5047 certificate status check service to check the validity of a certificate. 5048 These rules specify the mandated minimum checks that must be carried 5049 out. 5051 It is expected that in many cases either check may be selected with 5052 CRLs checks being carried out for certificate status that are 5053 unavailable from OCSP servers. The verifier may take into account 5054 information in the certificate in deciding how best to check the 5055 revocation status (e.g. a certificate extension field about authority 5056 information access or a CRL distribution point) provided that it does 5057 not conflict with the signature policy revocation rules. 5059 C.6 Rules for the Use of Roles 5061 Roles can be supported as claimed roles or as certified roles using 5062 Attribute Certificates. 5064 C.6.1 Attribute Values 5066 When signature under a role is mandated by the signature policy, then 5067 either Attribute Certificates may be used or the signer may provide a 5068 claimed role attribute. The acceptable attribute types or values may be 5069 dependent on the type of commitment. For example, a user may have 5070 several roles that allow the user to sign data that imply commitments 5071 based on one or more of his roles. 5073 C.6.2 Trust Points for Certified Attributes 5075 When a signature under a certified role is mandated by the signature 5076 policy, Attribute Authorities are used and need to be validated as part 5077 of the overall validation of the electronic signature. The trust points 5078 for Attribute Authorities do not need to be the same as the trust 5079 points to evaluate a certificate from the CA of the signer. Thus the 5080 trust point for verifying roles need not be the same as trust point 5081 used to validate the certificate path of the user's key. 5083 Naming and certification policy constraints may apply to the AA in 5084 similar circumstance to when they apply to CA. Constraints on the AA 5085 and CA need not be exactly the same. 5087 AA(s) may be used when a signer is creating a signature on behalf of an 5088 organization, they can be particularly useful when the signature 5089 represents an organizational role. AA(s) may or may not be the same 5090 authority as CA(s). 5092 Thus, the Signature Policy identifies trust points that can be used for 5093 Attribute Authorities, either by reference to the same trust points as 5094 used for Certification Authorities, or by an independent list. 5096 Internet Draft Electronic Signature Formats 5098 C.6.3 Certification Path for Certified Attributes 5100 Attribute Authorities may be organized in a tree structure in similar 5101 way to CA where the AAs are the leafs of such a tree. Naming and other 5102 constraints may be required on attribute certificate paths in a similar 5103 manner to other electronic signature certificate paths. 5105 Thus, the Signature Policy identify constraints on the following 5106 parameters used as input to the certificate path processing: 5108 * acceptable certificate policies, including requirements for 5109 explicit certificate policy indication and whether certificate 5110 policy mapping is allowed; 5111 * naming constraints in terms of constrained and excluded naming 5112 subtrees; 5113 * restrictions on the certificate path length. 5115 C.7 Rules for the Use of Timestamping and Timing 5117 The following rules should be used when specifying, constraints on the 5118 certificate paths for timestamping authorities, constraints on the 5119 timestamping authority names and general timing constraints. 5121 C.7.1 Trust Points and Certificate Paths 5123 Signature keys from timestamping authorities will need to be supported 5124 by a certification path. The certification path used for timestamping 5125 authorities requires a trustpoint and possibly path constraints in the 5126 same way that the certificate path for the signer's key. 5128 C.7.2 Timestamping Authority Names 5130 Restrictions may need to be placed by the validation policy on the 5131 named entities that may act a timestamping authorities. 5133 C.7.3 Timing Constraints - Caution Period 5135 Before an electronic signature may really be valid, the verifier has to 5136 be sure that the holder of the private key was really the only one in 5137 possession of key at the time of signing. However, there is an 5138 inevitable delay between a compromise or loss of key being noted, and a 5139 report of revocation being distributed. To allow greater confidence in 5140 the validity of a signature, a "cautionary period" may be identified 5141 before a signature may be said to be valid with high confidence. A 5142 verifier may revalidate a signature after this cautionary signature, or 5143 wait for this period before validating a signature. 5145 The validation policy may specify such a cautionary period. 5147 Internet Draft Electronic Signature Formats 5149 C.7.4 Timing Constraints - Timestamp Delay 5151 There will be some delay between the time that a signature is created 5152 and the time the signer's digital signature is timestamped. However, 5153 the longer this elapsed period the greater the risk of the signature 5154 being invalidated due to compromise or deliberate revocation of its 5155 private signing key by the signer. Thus the signature policy should 5156 specify a maximum acceptable delay between the signing time as claimed 5157 by the signer and the time included within the timestamp. 5159 C.8 Rules for Verification Data to be followed 5161 By specifying the requirements on the signer and verifier the 5162 responsibilities of the two parties can be clearly defined to establish 5163 all the necessary information. 5165 These verification data rules should include: 5166 * requirements on the signer to provide given signed attributes; 5167 * requirements on the verifier to obtain additional certificates, CRLs, 5168 results of on line certificate status checks and to use timestamps (if 5169 no already provided by the signer). 5171 C.9 Rules for Algorithm Constraints and Key Lengths 5172 The signature validation policy may identify a set of signing 5173 algorithms (hashing, public key, combinations) and minimum key lengths 5174 that may be used: 5176 * by the signer in creating the signature; 5177 * in end entity public key Certificates; 5178 * CA Certificates; 5179 * attribute Certificates; 5180 * by the timestamping authority. 5182 C.10 Other Signature Policy Rules 5184 The signature policy may specify additional policy rules, for example 5185 rules that relate to the environment used by the signer. These 5186 additional rules may be defined in computer processable and/or human 5187 readable form. 5189 C.11 Signature Policy Protection 5191 When signer or verifier obtains a copy of the Signature Policy from an 5192 issuer, the source should be authenticated (for example by using 5193 electronic signatures). When the signer references a signature policy 5194 the Object Identifier (OID) of the policy, the hash value and the hash 5195 algorithm OID of that policy must be included in the Electronic 5196 Signature. 5198 Internet Draft Electronic Signature Formats 5200 It is a mandatory requirement of this present document that the 5201 signature policy value computes to one, and only one hash value using 5202 the specified hash algorithm. This means that there must be a single 5203 binary value of the encoded form of the signature policy for the unique 5204 hash value to be calculated. For example, there may exist a particular 5205 file type, length and format on which the hash value is calculated 5206 which is fixed and definitive for a particular signature policy. 5208 The hash value may be obtained by: 5210 the signer performing his own computation of the hash over the 5211 signature policy using his preferred hash algorithm permitted by 5212 the signature policy, and the definitive binary encoded form. 5214 the signer, having verified the source of the policy, may use 5215 both the hash algorithm and the hash value included in the 5216 computer processable form of the policy (see section 6.1). 5218 Internet Draft Electronic Signature Formats 5220 Annex D (informative): 5222 Identifiers and roles 5223 D.1 Signer Name Forms 5225 The name used by the signer, held as the subject in the signer's 5226 certificate, must uniquely identify the entity. The name must be 5227 allocated and verified on registration with the Certification 5228 Authority, either directly or indirectly through a Registration 5229 Authority, before being issued with a Certificate. 5231 This document places no restrictions on the form of the name. The 5232 subject's name may be a distinguished name, as defined in ITU-T 5233 Recommendation X.500 [15], held in the subject field of the 5234 certificate, or any other name form held in the X.509 subjectAltName 5235 certificate extension field. In the case that the subject has no 5236 distinguished name, the subject name can be an empty 5237 sequence and the subjectAltName extension must be critical. 5239 D.2 TSP Name Forms 5241 All TSP name forms (Certification Authorities, Attribute Authorities 5242 and TimeStamping Authorities) must be in the form of a distinguished 5243 name held in the subject field of the certificate. 5245 The TSP name form must include identifiers for the organization 5246 providing the service and the legal jurisdiction (e.g. country) under 5247 which it operates. 5249 D.3 Roles and Signer Attributes 5251 Where a signer signs as an individual but wishes to also identify 5252 him/herself as acting on behalf of an organization, it may be necessary 5253 to provide two independent forms of identification. The first identity, 5254 with is directly associated with the signing key identifies him/her as 5255 an individual. The second, which is managed independently, identifies 5256 that person acting as part of the organization, possibly with a given 5257 role. 5259 In this case the first identity is carried in the 5260 subject/subjectAltName field of the signer's certificate as described 5261 above. 5263 This document supports the following means of providing a second form 5264 of identification: 5265 * by placing a secondary name field containing a claimed role in 5266 the CMS signed attributes field; 5267 * by placing an attribute certificate containing a certified role 5268 in the CMS signed attributes field.