idnits 2.17.1 draft-ietf-smime-espolicies-01.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 Internet-Drafts being working documents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 55 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 367 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 756 has weird spacing: '... either using...' == 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 2001) is 8441 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1577 -- Looks like a reference, but probably isn't: '1' on line 1579 -- Looks like a reference, but probably isn't: '2' on line 1581 -- Looks like a reference, but probably isn't: '3' on line 1583 -- Looks like a reference, but probably isn't: '4' on line 1585 -- Looks like a reference, but probably isn't: '5' on line 1397 -- Looks like a reference, but probably isn't: '7' on line 517 == Unused Reference: 'ES201733' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'OCSP' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'ESS' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'CMS' is defined on line 893, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'PKCS9' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'ISONR' is defined on line 904, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft ETSI TC-SEC (ETSI) 2 S/MIME Working Group J Ross (Security & Standards) 3 expires in six months D Pinkas (Bull) 4 Target Category: Experimental N Pope (Security & Standards) 5 March 2001 7 Electronic Signature Policies 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This RFC defines signature policies for electronic signatures. 32 A signature policy is a set of rules for the creation and validation 33 of an electronic signature, under which the validity of signature can 34 be determined. A given legal/contractual context may recognize a 35 particular signature policy as meeting its requirements. 37 A signature policy has a globally unique reference, which is bound to 38 an electronic signature by the signer as part of the signature 39 calculation. 41 The signature policy needs to be available in human readable form so 42 that it can be assessed to meet the requirements of the legal and 43 contractual context in which it is being applied. 45 To allow for the automatic processing of an electronic signature 46 another part of the signature policy specifies the electronic 47 rules for the creation and validation of the electronic signature in 48 a computer processable form. In the current document the format of the 49 signature policy is defined using ASN.1. 51 The contents of this RFC is based on the signature policy defined in 52 ETSI TS 101 733 V1.2.2 The ETSI TS is under the ETSI Copyright (C). 53 Individual copies of this ETSI deliverable can be downloaded from 54 http://www.etsi.org. 56 Internet Draft Electronic Signature Policies 58 TABLE OF CONTENTS 60 Abstract 1 61 Table of contents 2 62 1. Introduction 3 63 2. Major Parties 3 64 3. Signature Policy Specification 5 65 3.1 Overall ASN.1 Structure 5 66 3.2 Signature Validation Policy 6 67 3.3 Common Rules 7 68 3.4 Commitment Rules 8 69 3.5 Signer and Verifier Rules 9 70 3.5.1 Signer Rules 9 71 3.5.2 Verifier Rules 10 72 3.6 Certificate and Revocation Requirements 11 73 3.6.1 Certificate Requirements 11 74 3.6.2 Revocation Requirements 13 75 3.7 Signing Certificate Trust Conditions 14 76 3.8 TimeStamp Trust Conditions 15 77 3.9 Attribute Trust Conditions 15 78 3.10 Algorithm Constraints 16 79 3.11 Signature Policy Extensions 17 80 4. Security considerations 18 81 5. Conformance Requirements 18 82 6. References 18 83 7. Authors' Addresses 19 84 8. Full Copyright Statement 20 85 Annex A (normative): 21 86 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 21 87 A.2 Definitions Using X.680 (1997) ASN.1 Syntax 27 88 Annex B (informative): 34 89 B.1 Signature Policy and Signature Validation Policy 34 90 B.2 Identification of Signature Policy 36 91 B.3 General Signature Policy Information 36 92 B.4 Recognized Commitment Types 37 93 B.5 Rules for Use of Certification Authorities 37 94 B.5.1 Trust Points 37 95 B.5.2 Certification Path 38 96 B.6 Revocation Rules 39 97 B.7 Rules for the Use of Roles 39 98 B.7.1 Attribute Values 39 99 B.7.2 Trust Points for Certified Attributes 39 100 B.7.3 Certification Path for Certified Attributes 40 101 B.8 Rules for the Use of Timestamping and Timing 40 102 B.8.1 Trust Points and Certificate Paths 40 103 B.8.2 Timestamping Authority Names 40 104 B.8.3 Timing Constraints - Caution Period 40 105 B.8.4 Timing Constraints - Timestamp Delay 41 106 B.9 Rules for Verification Data to be followed 41 107 B.10 Rules for Algorithm Constraints and Key Lengths 41 108 B.11 Other Signature Policy Rules 41 109 B.12 Signature Policy Protection 41 111 Internet Draft A Signature Policy Format 113 1. Introduction 115 This document is intended to cover signature policies which can be 116 used with electronic signatures for various types of transactions, 117 including business transactions (e.g. purchase requisition, contract, 118 and invoice applications). Electronic signatures can be used for any 119 transaction between an individual and a company, between two 120 companies, between an individual and a governmental body, etc. 121 This document is independent of any environment. It can be applied 122 to any environment e.g. smart cards, GSM SIM cards, special programs 123 for electronic signatures etc. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 126 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 127 as shown) are to be interpreted as described in [RFC2119]. 129 2.3 Major Parties 131 The document uses the following terms: 133 * the Signature Policy Issuer; 134 * the Signer; 135 * the Verifier; 136 * the Arbitrator; 137 * Trusted Service Providers (TSP); 139 The Signature Policy Issuer (which is a Trusted Service Provider (TSP)) 140 issues signatures policies that define the technical and procedural 141 requirements for electronic signature creation, and validation/ 142 verification, in order to meet a particular business need. 144 The Signer is the entity that creates the electronic signature. When 145 the signer digitally signs over an signature policy identifier, it 146 represents a commitment on behalf of the signing entity that the data 147 being signed is signed under the rules defined by the signature policy. 149 The Verifier is the entity that validates the electronic signature, it 150 may be a single entity or multiple entities. The verifier MUST validate 151 the electronic signature under the rules defined by the electronic signature 152 policy for the signature to be valid. 154 An arbitrator, is an entity which arbitrates disputes between a signer 155 and a verifier. It acts as verifier when it verifies the electronic 156 signature after it has been previously validated. 158 Internet Draft Electronic Signature Policies 160 The Trusted Service Providers (TSPs) are one or more entities that help 161 to build trust relationships between the signer and verifier. Use of TSP 162 specific services MAY be mandated by signature policy. TSP supporting 163 services include: user certificates, cross-certificates, timestamping 164 tokens,CRLs, ARLs, OCSP responses. 166 A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer, as 167 Such, the TSP MUST define the technical and procedural requirements for 168 electronic signature creation and validation, in order to meet a 169 particular business need. 171 The following other TSPs are used to support the 172 functions defined in this document: 174 * Certification Authorities; 175 * Registration Authorities; 176 * Repository Authorities (e.g. a Directory); 177 * TimeStamping Authorities; 178 * One-line Certificate Status Protocol responders; 179 * Attribute Authorities. 181 Certification Authorities provide users with public key certificates. 183 Registration Authorities allows the registration of entities before a 184 CA generates certificates. 186 Repository Authorities publish CRLs issued by CAs, , cross-certificates 187 (i.e. CA certificates) issued by CAs, signature policies 188 issued by Signature Policy Issuers and optionally public key 189 certificates (i.e. leaf certificates) issued by CAs. 191 TimeStamping Authorities attest that some data was formed before a 192 given trusted time. 194 One-line Certificate Status Protocol responders (OSCP responders) 195 provide information about the status (i.e. revoked, not revoked, 196 unknown) of a particular certificate. 198 Attributes Authorities provide users with attributes linked to public 199 key certificates 201 An Arbitrator is an entity that arbitrates disputes between a signer 202 and a verifier. 204 Internet Draft Electronic Signature Policies 206 3. Signature Policy Specification 208 A signature policy specification includes general information about the 209 policy, the validation policy rules and other signature policy 210 information. 212 This document mandates that: 213 * an electronic signature must be processed by the signer and 214 verifier in accordance with the signature policy referenced by 215 the signer; 216 * the signature policy referenced by the signer must be 217 identifiable by an Object Identifier; 218 * there must exist a specification of the signature policy; 219 * for a given signature policy there must be one definitive form 220 of the specification which has a unique binary encoding; 221 * a hash of the definitive specification, using an agreed 222 algorithm, must be provided by the signer and checked by the 223 verifier. 225 This document defines but does not mandate the form of the signature 226 policy specification. The signature policy may be specified either: 228 * in a free form document for human interpretation; or 229 * in a structured form using an agreed syntax and encoding. 231 This document defines an ASN.1 based syntax that may be used to define 232 a structured signature policy. Future versions of this document may 233 include structured a signature policy specification using XML. 235 3.1 Overall ASN.1 Structure 237 The overall structure of a signature policy defined using ASN.1 is 238 given in this section. Use of this ASN.1 structure is optional. 240 This ASN.1 syntax is encoded using the Distinguished Encoding Rules 241 (DER). 243 Internet Draft Electronic Signature Policies 245 In this structure the policy information is preceded by an identifier 246 for the hashing algorithm used to protect the signature policy and 247 followed by the hash value which must be re-calculated and checked 248 whenever the signature policy is passed between the issuer and 249 signer/verifier. 250 The hash is calculated without the outer type and length fields. 252 SignaturePolicy ::= SEQUENCE { 253 signPolicyHashAlg AlgorithmIdentifier, 254 signPolicyInfo SignPolicyInfo, 255 signPolicyHash SignPolicyHash OPTIONAL } 257 SignPolicyHash ::= OCTET STRING 259 SignPolicyInfo ::= SEQUENCE { 260 signPolicyIdentifier SignPolicyId, 261 dateOfIssue GeneralizedTime, 262 policyIssuerName PolicyIssuerName, 263 fieldOfApplication FieldOfApplication, 264 signatureValidationPolicy SignatureValidationPolicy, 265 signPolExtensions SignPolExtensions 266 OPTIONAL 267 } 269 SignPolicyId ::= OBJECT IDENTIFIER 271 PolicyIssuerName ::= GeneralNames 273 FieldOfApplication ::= DirectoryString 275 The policyIssuerName field identifies the policy issuer in one or more 276 of the general name forms. 278 The fieldofApplication is a description of the expected application of 279 this policy. 281 The signature validation policy rules are fully processable to allow 282 the validation of electronic signatures issued under that form of 283 signature policy. They are described in the rest of this section. 285 The signPolExtensions is a generic way to extend the definition of any 286 sub-component of a signature policy. 288 3.2 Signature Validation Policy 290 The signature validation policy defines for the signer which data 291 elements must be present in the electronic signature he provides and 292 for the verifier which data elements must be present under that 293 signature policy for an electronic signature to be potentially valid. 295 Internet Draft Electronic Signature Policies 297 The signature validation policy is described as follows: 299 SignatureValidationPolicy ::= SEQUENCE { 300 signingPeriod SigningPeriod, 301 commonRules CommonRules, 302 commitmentRules CommitmentRules, 303 signPolExtensions SignPolExtensions OPTIONAL 304 } 306 The signingPeriod identifies the date and time before which the 307 signature policy SHOULD NOT be used for creating signatures, and an 308 optional date after which it should not be used for creating 309 signatures. 311 SigningPeriod ::= SEQUENCE { 312 notBefore GeneralizedTime, 313 notAfter GeneralizedTime OPTIONAL } 315 3.3 Common Rules 317 The CommonRules define rules that are common to all commitment types. 318 These rules are defined in terms of trust conditions for certificates, 319 timestamps and attributes, along with any constraints on attributes 320 that may be included in the electronic signature. 322 CommonRules ::= SEQUENCE { 323 signerAndVeriferRules [0] SignerAndVerifierRules 324 OPTIONAL, 325 signingCertTrustCondition [1] SigningCertTrustCondition 326 OPTIONAL, 327 timeStampTrustCondition [2] TimestampTrustCondition 328 OPTIONAL, 329 attributeTrustCondition [3] AttributeTrustCondition 330 OPTIONAL, 331 algorithmConstraintSet [4] AlgorithmConstraintSet 332 OPTIONAL, 333 signPolExtensions [5] SignPolExtensions 334 OPTIONAL 335 } 337 If a field is present in CommonRules then the equivalent field must 338 not be present in any of the CommitmentRules (see below). If any of the 339 following fields are not present in CommonRules then it must be 340 present in each CommitmentRule: 342 * signerAndVeriferRules; 343 * signingCertTrustCondition; 344 * timeStampTrustCondition. 346 Internet Draft Electronic Signature Policies 348 3.4 Commitment Rules 350 The CommitmentRules consists of the validation rules which apply to 351 given commitment types: 353 CommitmentRules ::= SEQUENCE OF CommitmentRule 355 The CommitmentRule for given commitment types are defined in terms of 356 trust conditions for certificates, timestamps and attributes, along 357 with any constraints on attributes that may be included in the 358 electronic signature. 360 CommitmentRule ::= SEQUENCE { 361 selCommitmentTypes SelectedCommitmentTypes, 362 signerAndVeriferRules [0] SignerAndVerifierRules 363 OPTIONAL, 364 signingCertTrustCondition [1] SigningCertTrustCondition 365 OPTIONAL, 366 timeStampTrustCondition [2] TimestampTrustCondition 367 OPTIONAL, 368 attributeTrustCondition [3] AttributeTrustCondition 369 OPTIONAL, 370 algorithmConstraintSet [4] AlgorithmConstraintSet 371 OPTIONAL, 372 signPolExtensions [5] SignPolExtensions 373 OPTIONAL 374 } 376 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 377 empty NULL, 378 recognizedCommitmentType CommitmentType } 380 If the SelectedCommitmentTypes indicates "empty" then this rule applied 381 when a commitment type is not present (i.e. the type of commitment is 382 indicated in the semantics of the message). Otherwise, the electronic 383 signature must contain a commitment type indication that must fit one 384 of the commitments types that are mentioned in CommitmentType. 386 A specific commitment type identifier must not appear in more than one 387 commitment rule. 389 CommitmentType ::= SEQUENCE { 390 identifier CommitmentTypeIdentifier, 391 fieldOfApplication [0] FieldOfApplication OPTIONAL, 392 semantics [1] DirectoryString OPTIONAL } 394 The fieldOfApplication and semantics fields define the specific use and 395 meaning of the commitment within the overall field of application 396 defined for the policy. 398 Internet Draft Electronic Signature Policies 400 3.5 Signer and Verifier Rules 402 The following rules apply to the format of electronic signatures defined using 403 [ES-FORMATS]. 405 The SignerAndVerifierRules consists of signer rule and verification 406 rules as defined below: 407 SignerAndVerifierRules ::= SEQUENCE { 408 signerRules SignerRules, 409 verifierRules VerifierRules } 411 3.5.1 Signer Rules 413 The signer rules identify: 415 * if the eContent is empty and the signature is calculated using 416 a hash of signed data external to CMS structure. 418 * the CMS signed attributes that must be provided by the signer 419 under this policy; 421 * the CMS unsigned attribute that must be provided by the signer 422 under this policy; 424 * whether the certificate identifiers from the full certification 425 path up to the trust point must be provided by the signer in 426 the SigningCertificate attribute; 428 * whether a signer's certificate, or all certificates in the 429 certification path to the trust point must be provided by the 430 signer in the certificates field of SignedData. 432 SignerRules ::= SEQUENCE { 433 externalSignedData BOOLEAN OPTIONAL, 434 -- True if signed data is external to CMS structure 435 -- False if signed data part of CMS structure 436 -- not present if either allowed 437 mandatedSignedAttr CMSAttrs, 438 -- Mandated CMS signed attributes 439 mandatedUnsignedAttr CMSAttrs, 440 -- Mandated CMS unsigned attributed 441 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 442 -- Mandated Certificate Reference 443 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 444 -- Mandated Certificate Info 445 signPolExtensions [2] SignPolExtensions OPTIONAL 446 } 448 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 450 The mandatedSignedAttr field must include the object identifier for 451 all those signed attributes required by this document as well as 452 additional attributes required by this policy. 454 Internet Draft Electronic Signature Policies 456 The mandatedUnsignedAttr field must include the object identifier for 457 all those unsigned attributes required by this document as well as 458 additional attributes required this policy. For example, if a signature 459 timestamp is required by the signer the object identifier for this 460 attribute must be included. 462 The mandatedCertificateRef identifies whether just the signer's 463 certificate, or all the full certificate path must be provided by the 464 signer. 466 CertRefReq ::= ENUMERATED { 467 signerOnly (1), 468 -- Only reference to signer cert mandated 469 fullPath (2) 471 -- References for full cert path up to a trust point required 472 } 474 The mandatedCertificateInfo field identifies whether a signer's 475 certificate, or all certificates in the certification path to the trust 476 point must be provided by the signer in the certificates field of 477 SignedData. 479 CertInfoReq ::= ENUMERATED { 480 none (0) , 481 -- No mandatory requirements 482 signerOnly (1) , 483 -- Only reference to signer cert mandated 484 fullPath (2) 485 -- References for full cert path up to a 486 -- trust point mandated 487 } 489 3.5.2 Verifier Rules 491 The verifier rules identify: 492 * The CMS unsigned attributes that must be present under this policy 493 and must be added by the verifier if not added by the signer. 495 VerifierRules ::= SEQUENCE { 496 mandatedUnsignedAttr MandatedUnsignedAttr, 497 signPolExtensions SignPolExtensions OPTIONAL 498 } 500 MandatedUnsignedAttr ::= CMSAttrs 501 -- Mandated CMS unsigned attributed 503 Internet Draft Electronic Signature Policies 505 3.6 Certificate and Revocation Requirement 507 The SigningCertTrustCondition, TimestampTrustCondition and 508 AttributeTrustCondition (defined in subsequent sub-sections) make use of 509 two ASN1 structures which are defined below: CertificateTrustTrees and 510 CertRevReq. 512 3.6.1 Certificate Requirements 514 The certificateTrustTrees identifies a set of self signed certificates 515 for the trust points used to start (or end) certificate path processing 516 and the initial conditions for certificate path validation as defined 517 RFC 2459 [7] section 4. This ASN1 structure is used to define policy 518 for validating the signing certificate, the TSA's certificate and 519 attribute certificates. 521 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 523 CertificateTrustPoint ::= SEQUENCE { 524 trustpoint Certificate, 525 -- self-signed certificate 526 pathLenConstraint [0] PathLenConstraint OPTIONAL, 527 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 528 -- If not present "any policy" 529 nameConstraints [2] NameConstraints OPTIONAL, 530 policyConstraints [3] PolicyConstraints OPTIONAL } 532 The trustPoint field gives the self signed certificate for the CA that 533 is used as the trust point for the start of certificate path 534 processing. 536 The pathLenConstraint field gives the maximum number of CA certificates 537 that may be in a certification path following the trustpoint. A value 538 of zero indicates that only the given trustpoint certificate and an 539 end-entity certificate may be used. If present, the pathLenConstraint 540 field must be greater than or equal to zero. Where pathLenConstraint 541 is not present, there is no limit to the allowed length of the 542 certification path. 544 PathLenConstraint ::= INTEGER (0..MAX) 546 The acceptablePolicySet field identifies the initial set of certificate 547 policies, any of which are acceptable under the signature policy. 548 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 550 CertPolicyId ::= OBJECT IDENTIFIER 552 Internet Draft Electronic Signature Policies 554 The nameConstraints field indicates a name space within which all 555 subject names in subsequent certificates in a certification path must 556 be located. Restrictions may apply to the subject distinguished name or 557 subject alternative names. Restrictions apply only when the specified 558 name form is present. If no name of the type is in the certificate, the 559 certificate is acceptable. 561 Restrictions are defined in terms of permitted or excluded name 562 subtrees. Any name matching a restriction in the excludedSubtrees field 563 is invalid regardless of information appearing in the ermittedSubtrees. 565 NameConstraints ::= SEQUENCE { 566 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 567 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 569 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 571 GeneralSubtree ::= SEQUENCE { 572 base GeneralName, 573 minimum [0] BaseDistance DEFAULT 0, 574 maximum [1] BaseDistance OPTIONAL } 576 BaseDistance ::= INTEGER (0..MAX) 578 The policyConstraints extension constrains path processing in two ways. 579 It can be used to prohibit policy mapping or require that each 580 certificate in a path contain an acceptable policy identifier. 582 The policyConstraints field, if present specifies requirement for 583 explicit indication of the certificate policy and/or the constraints on 584 policy mapping. 586 PolicyConstraints ::= SEQUENCE { 587 requireExplicitPolicy [0] SkipCerts OPTIONAL, 588 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 590 SkipCerts ::= INTEGER (0..MAX) 592 If the inhibitPolicyMapping field is present, the value indicates the 593 number of additional certificates that may appear in the path 594 (including the trustpoint's self certificate) before policy mapping is 595 no longer permitted. For example, a value of one indicates that policy 596 mapping may be processed in certificates issued by the subject of this 597 certificate, but not in additional certificates in the path. 599 If the requireExplicitPolicy field is present, subsequent certificates 600 must include an acceptable policy identifier. The value of 601 requireExplicitPolicy indicates the number of additional certificates 602 that may appear in the path (including the trustpoint's self 603 certificate) before an explicit policy is required. An acceptable 604 policy identifier is the identifier of a policy required by the user of 605 the certification path or the identifier of a policy which has been 606 declared equivalent through policy mapping. 608 Internet Draft Electronic Signature Policies 610 3.6.2 Revocation Requirements 612 The RevocRequirements field specifies minimum requirements for 613 revocation information, obtained through CRLs and/or OCSP responses, to 614 be used in checking the revocation status of certificates. This ASN1 615 structure is used to define policy for validating the signing 616 certificate, the TSA's certificate and attribute certificates. 618 CertRevReq ::= SEQUENCE { 619 endCertRevReq RevReq, 620 caCerts [0] RevReq 621 } 623 Certificate revocation requirements are specified in terms of checks 624 required on: 625 * endCertRevReq: end certificates (i.e. the signers certificate, 626 the attribute certificate or the timestamping authority 627 certificate). 629 * caCerts: CA certificates. 631 RevReq ::= SEQUENCE { 632 enuRevReq EnuRevReq, 633 exRevReq SignPolExtensions OPTIONAL} 635 An authority certificate is certificate issued to an authority (e.g. 636 either to a certification authority or to an attribute authority (AA)). 638 A TimeStamping Authority (TSA) is a trusted third party that creates 639 time stamp tokens in order to indicate that a datum existed at a 640 particular point in time. See [TSP] 642 EnuRevReq ::= ENUMERATED { 643 clrCheck (0), 644 --Checks must be made against current CRLs 645 -- (or authority revocation lists (ARL)) 646 ocspCheck (1), -- The revocation status must be checked 647 -- using the Online Certificate Status Protocol 648 -- (OCSP),RFC 2450. 649 bothCheck (2), 650 -- Both CRL and OCSP checks must be carried out 651 eitherCheck (3), 652 -- At least one of CRL or OCSP checks must be 653 -- carried out 654 noCheck (4), 655 -- no check is mandated 656 other (5) 657 -- Other mechanism as defined by signature policy 658 -- extension 659 } 661 Internet Draft Electronic Signature Policies 663 Revocation requirements are specified in terms of: 664 * clrCheck: Checks must be made against current CRLs (or 665 authority revocation lists); 666 * ocspCheck: The revocation status must be checked using the 667 Online Certificate Status Protocol (RFC 2450); 668 * bothCheck: Both OCSP and CRL checks must be carried out; 669 * eitherCheck: Either OCSP or CRL checks must be carried out; 670 * noCheck: No check is mandated. 672 3.7 Signing Certificate Trust Conditions 674 The SigningCertTrustCondition field identifies trust conditions for 675 certificate path processing used to validate the signing certificate. 677 SigningCertTrustCondition ::= SEQUENCE { 678 signerTrustTrees CertificateTrustTrees, 679 signerRevReq CertRevReq 680 } 682 3.8 TimeStamp Trust Conditions 684 The TimeStampTrustCondition field identifies trust conditions for 685 certificate path processing used to authenticate the timstamping 686 authority and constraints on the name of the timestamping authority. 687 This applies to the timestamp that must be present in every ES-T. 689 TimestampTrustCondition ::= SEQUENCE { 690 ttsCertificateTrustTrees [0] CertificateTrustTrees 691 OPTIONAL, 692 ttsRevReq [1] CertRevReq 693 OPTIONAL, 694 ttsNameConstraints [2] NameConstraints 695 OPTIONAL, 696 cautionPeriod [3] DeltaTime 697 OPTIONAL, 698 signatureTimestampDelay [4] DeltaTime 699 OPTIONAL } 701 DeltaTime ::= SEQUENCE { 702 deltaSeconds INTEGER, 703 deltaMinutes INTEGER, 704 deltaHours INTEGER, 705 deltaDays INTEGER } 707 If ttsCertificateTrustTrees is not present then the same rule as 708 defined in certificateTrustCondition applies to certification of the 709 timestamping authorities public key. 711 Internet Draft Electronic Signature Policies 713 The tstrRevReq specifies minimum requirements for revocation 714 information, obtained through CRLs and/or OCSP responses, to be used in 715 checking the revocation status of the time stamp that must be present 716 in the ES-T. 718 If ttsNameConstraints is not present then there are no additional 719 naming constraints on the trusted timestamping authority other than 720 those implied by the ttsCertificateTrustTrees. 722 The cautionPeriod field specifies a caution period after the signing 723 time that it is mandated the verifier must wait to get high assurance 724 of the validity of the signer's key and that any relevant revocation 725 has been notified. The revocation status information forming the ES 726 with Complete validation data must not be collected and used to 727 validate the electronic signature until after this caution period. 729 The signatureTimestampDelay field specifies a maximum acceptable time 730 between the signing time and the time at which the signature timestamp, 731 as used to form the ES Timestamped, is created for the verifier. If the 732 signature timestamp is later that the time in the signing-time 733 attribute by more than the value given in signatureTimestampDelay, the 734 signature must be considered invalid. 736 3.9 Attribute Trust Conditions 738 If the attributeTrustCondition field is not present then any certified 739 attributes may not considered to be valid under this validation policy. 740 The AttributeTrustCondition field is defined as follows: 742 AttributeTrustCondition ::= SEQUENCE { 743 attributeMandated BOOLEAN, 744 -- Attribute must be present 745 howCertAttribute HowCertAttribute, 746 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 747 attrRevReq [1] CertRevReq OPTIONAL, 748 attributeConstraints [2] AttributeConstraints OPTIONAL } 750 If attributeMandated is true then an attribute, certified within the 751 following constraints, must be present. If false, then the signature 752 is still valid if no attribute is specified. 754 The howCertAttribute field specifies whether attributes uncertified 755 attributes "claimed" by the signer, or certified attributes 756 (i.e. Attribute Certificates) or either using the signer 757 attributes attribute defined in [ES-FORMATS] section 3.12.3. 759 HowCertAttribute ::= ENUMERATED { 760 claimedAttribute (0), 761 certifiedAttribtes (1), 762 either (2) } 764 Internet Draft Electronic Signature Policies 766 The attrCertificateTrustTrees specifies certificate path conditions for 767 any attribute certificate. If not present the same rules apply as in 768 certificateTrustCondition. 770 The attrRevReq specifies minimum requirements for revocation 771 information, obtained through CRLs and/or OCSP responses, to be used in 772 checking the revocation status of Attribute Certificates, if any are 773 present. 775 If the attributeConstraints field is not present then there are no 776 constraints on the attributes that may be validated under this policy. 777 The attributeConstraints field is defined as follows: 779 AttributeConstraints ::= SEQUENCE { 780 attributeTypeConstarints [0] AttributeTypeConstraints 781 OPTIONAL, 782 attributeValueConstarints [1] AttributeValueConstraints 783 OPTIONAL } 785 If present, the attributeTypeConstarints field specifies the attribute 786 types which are considered valid under the signature policy. Any value 787 for that attribute is considered valid. 789 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 791 If present, the attributeTypeConstraints field specifies the specific 792 attribute values which are considered valid under the signature policy. 794 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 796 3.10 Algorithm Constraints 798 The algorithmConstrains fields, if present, identifies the signing 799 algorithms (hash, public key cryptography, combined hash and public key 800 cryptography) that may be used for specific purposes and any minimum 801 length. If this field is not present then the policy applies no 802 constraints. 804 AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on: 805 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 806 -- signer 807 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 808 -- issuer of end entity certs. 809 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 810 -- issuer of CA certificates 811 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 812 -- Attribute Authority 813 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 814 -- TimeStamping Authority 815 } 817 Internet Draft Electronic Signature Policies 819 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 821 AlgAndLength ::= SEQUENCE { 822 algID OBJECT IDENTIFIER, 823 minKeyLength INTEGER OPTIONAL, 824 -- Minimum key length in bits 825 other SignPolExtensions OPTIONAL 826 } 828 An Attribute Authority (AA)is authority which assigns privileges by 829 issuing attribute certificates 831 3.11 Signature Policy Extensions 833 Additional signature policy rules may be added to: 835 * the overall signature policy structure, as defined in 836 section 3.1; 837 * the signature validation policy structure, as defined in 838 section 3.2; 839 * the common rules, as defined in section 3.3; 840 * the commitment rules, as defined in section 3.4; 841 * the signer rules, as defined in section 3.5.1; 842 * the verifier rules, as defined in section 3.5.2; 843 * the revocation requirements in section 3.6.2; 844 * the algorithm constraints in section 3.10. 846 These extensions to the signature policy rules must be defined using 847 an ASN.1 syntax with an associated object identifier carried in the 848 SignPolExtn as defined below: 850 SignPolExtensions ::= SEQUENCE OF SignPolExtn 852 SignPolExtn ::= SEQUENCE { 853 extnID OBJECT IDENTIFIER, 854 extnValue OCTET STRING } 856 The extnID field must contain the object identifier for the extension. 857 The extnValue field must contain the DER (see ITU-T Recommendation 858 X.690 [4]) encoded value of the extension. The definition of an 859 extension, as identified by extnID must include a definition of the 860 syntax and semantics of the extension. 862 Internet Draft Electronic Signature Policies 864 4. Security considerations 865 To be defined 867 5. Conformance Requirements 869 To be defined 871 6. References 873 [ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic 874 Signature Formats. Note: copies of ETSI ES 201 733 can be freely download 875 from the ETSI web site www.etsi.org. 877 [ES-FORMATS] ETSI TC-SEC, D.Pinkas, J.Ross, N.Pope. Electronic Signature 878 formats for long term electronic signatures 879 To be published as an INFORMATIONAL RFC. 881 [TSP] C. Adams, D. Pinkas, R. Zuccherato, P. Cain. Time Stamp Protocol . 884 [OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. 885 On-line Status Certificate Protocol, RFC 2560. 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, March 1997. 890 [ESS] P. Hoffman, "Enhanced Security Services for S/MIME", RFC 2634 891 June 1999 893 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, RFC 2630, 894 June 1999. 896 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 897 Key Infrastructure, Certificate and CRL Profile," RFC 2459, January 898 1999. 900 [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards 901 (PKCS)", RSA Data Security Inc., Redwood City, California, November 902 1993 Release. 904 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 905 Non-Repudiation Framework. April 1997. 907 Internet Draft Electronic Signature Policies 909 7. Authors' Addresses 911 This Experimental RFC has been produced in ETSI TC-SEC. 913 ETSI 914 F-06921 Sophia Antipolis, Cedex - FRANCE 915 650 Route des Lucioles - Sophia Antipolis 916 Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 917 secretariat@etsi.fr 918 http://www.etsi.org 920 Contact Point 922 Harri Rasilainen 923 ETSI 924 650 Route des Lucioles 925 F-06921 Sophia Antipolis Cedex 926 FRANCE 927 harri.rasilainen@etsi.fr 929 John Ross 930 Security & Standards 931 192 Moulsham Street 932 Chelmsford, Essex 933 CM2 0LG 934 United Kingdom 935 ross@secstan.com 937 Denis Pinkas Nick Pope 938 Bull S.A. Security & Standards 939 12, rue de Paris 192 Moulsham Street 940 B.P. 59 Chelmsford, Essex 941 78231 Le Pecq CM2 0LG 942 FRANCE United Kingdom 943 pinkas.denis@bull.net pope@secstan.com 945 Internet Draft Electronic Signature Policies 947 8. Full Copyright Statement 949 Copyright (C) The Internet Society (2000). All Rights Reserved. 950 This document and translations of it may be copied and furnished to 951 others,and derivative works that comment on or otherwise explain it or 952 assist in its implementation may be prepared, copied, published and 953 distributed, in whole or in part, without restriction of any kind, 954 provided that the above copyright notice and this paragraph are included 955 on all such copies and derivative works. However, this document itself may 956 not be modified in any way, such as by removing the copyright notice or 957 references to the Internet Society or other Internet organizations, except 958 as needed for the purpose ofdeveloping Internet standards in which case 959 the procedures for copyrights defined in the Internet Standards process 960 must be followed, or as required to translate it into languages other than 961 English. 963 The limited permissions granted above are perpetual and will not be revoked 964 by the Internet Society or its successors or assigns. 966 This document and the information contained herein is provided on an 967 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 968 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 969 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 970 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 971 FITNESS FOR A PARTICULAR PURPOSE. 973 Internet Draft Electronic Signature Policies 975 Annex A (normative): 976 ASN.1 Definitions 977 This annex provides the reference definition of the ASN.1 syntax 978 signature policies definitions for new syntax defined in this document. 980 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 981 NOTE: The ASN.1 Module defined in section A.1 has precedence over that defined 982 in 983 Annex A-2 in the case of any conflict. 985 ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2) 986 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 7} 988 DEFINITIONS EXPLICIT TAGS ::= 989 BEGIN 990 -- EXPORTS All 992 IMPORTS 994 -- Internet X.509 Public Key Infrastructure 995 - Certificate and CRL Profile: RFC 2459 996 Certificate, AlgorithmIdentifier, CertificateList, Name, 997 GeneralNames, GeneralName, DirectoryString,Attribute, 998 AttributeTypeAndValue, AttributeType, AttributeValue, 999 PolicyInformation, BMPString, UTF8String 1001 FROM PKIX1Explicit88 1002 {iso(1) identified-organization(3) dod(6) internet(1) 1003 security(5) mechanisms(5) pkix(7) id-mod(0) 1004 id-pkix1-explicit-88(1)} 1005 ; 1007 -- Signature Policy Specification 1008 -- ============================== 1010 SignaturePolicy ::= SEQUENCE { 1011 signPolicyHashAlg AlgorithmIdentifier, 1012 signPolicyInfo SignPolicyInfo, 1013 signPolicyHash SignPolicyHash OPTIONAL } 1015 SignPolicyHash ::= OCTET STRING 1017 SignPolicyInfo ::= SEQUENCE { 1018 signPolicyIdentifier SignPolicyId, 1019 dateOfIssue GeneralizedTime, 1020 policyIssuerName PolicyIssuerName, 1021 fieldOfApplication FieldOfApplication, 1022 signatureValidationPolicy SignatureValidationPolicy, 1023 signPolExtensions SignPolExtensions 1024 OPTIONAL 1025 } 1027 SignPolicyId ::= OBJECT IDENTIFIER 1029 Internet Draft Electronic Signature Policies 1031 PolicyIssuerName ::= GeneralNames 1033 FieldOfApplication ::= DirectoryString 1035 SignatureValidationPolicy ::= SEQUENCE { 1036 signingPeriod SigningPeriod, 1037 commonRules CommonRules, 1038 commitmentRules CommitmentRules, 1039 signPolExtensions SignPolExtensions 1040 OPTIONAL 1041 } 1043 SigningPeriod ::= SEQUENCE { 1044 notBefore GeneralizedTime, 1045 notAfter GeneralizedTime OPTIONAL } 1047 CommonRules ::= SEQUENCE { 1048 signerAndVeriferRules [0] SignerAndVerifierRules 1049 OPTIONAL, 1050 signingCertTrustCondition [1] SigningCertTrustCondition 1051 OPTIONAL, 1052 timeStampTrustCondition [2] TimestampTrustCondition 1053 OPTIONAL, 1054 attributeTrustCondition [3] AttributeTrustCondition 1055 OPTIONAL, 1056 algorithmConstraintSet [4] AlgorithmConstraintSet 1057 OPTIONAL, 1058 signPolExtensions [5] SignPolExtensions 1059 OPTIONAL 1060 } 1062 CommitmentRules ::= SEQUENCE OF CommitmentRule 1064 CommitmentRule ::= SEQUENCE { 1065 selCommitmentTypes SelectedCommitmentTypes, 1066 signerAndVeriferRules [0] SignerAndVerifierRules 1067 OPTIONAL, 1068 signingCertTrustCondition [1] SigningCertTrustCondition 1069 OPTIONAL, 1070 timeStampTrustCondition [2] TimestampTrustCondition 1071 OPTIONAL, 1072 attributeTrustCondition [3] AttributeTrustCondition 1073 OPTIONAL, 1074 algorithmConstraintSet [4] AlgorithmConstraintSet 1075 OPTIONAL, 1076 signPolExtensions [5] SignPolExtensions 1077 OPTIONAL 1078 } 1080 Internet Draft Electronic Signature Policies 1082 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 1083 empty NULL, 1084 recognizedCommitmentType CommitmentType } 1086 CommitmentType ::= SEQUENCE { 1087 identifier CommitmentTypeIdentifier, 1088 fieldOfApplication [0] FieldOfApplication OPTIONAL, 1089 semantics [1] DirectoryString OPTIONAL } 1091 SignerAndVerifierRules ::= SEQUENCE { 1092 signerRules SignerRules, 1093 verifierRules VerifierRules } 1095 SignerRules ::= SEQUENCE { 1096 externalSignedData BOOLEAN OPTIONAL, 1097 -- True if signed data is external to CMS structure 1098 -- False if signed data part of CMS structure 1099 -- not present if either allowed 1100 mandatedSignedAttr CMSAttrs, 1101 -- Mandated CMS signed attributes 1102 mandatedUnsignedAttr CMSAttrs, 1103 -- Mandated CMS unsigned attributed 1104 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 1105 -- Mandated Certificate Reference 1106 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 1107 -- Mandated Certificate Info 1108 signPolExtensions [2] SignPolExtensions 1109 OPTIONAL} 1111 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 1113 CertRefReq ::= ENUMERATED { 1114 signerOnly (1), 1115 -- Only reference to signer cert mandated 1116 fullPath (2) 1117 -- References for full cert path up to a trust point required 1119 } 1121 CertInfoReq ::= ENUMERATED { 1122 none (0), 1123 -- No mandatory requirements 1124 signerOnly (1), 1125 -- Only reference to signer cert mandated 1126 fullPath (2) 1127 -- References for full cert path up to a trust point mandated 1128 } 1130 Internet Draft Electronic Signature Policies 1132 VerifierRules ::= SEQUENCE { 1133 mandatedUnsignedAttr MandatedUnsignedAttr, 1134 signPolExtensions SignPolExtensions OPTIONAL 1135 } 1137 MandatedUnsignedAttr ::= CMSAttrs 1138 -- Mandated CMS unsigned attributed 1140 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 1142 CertificateTrustPoint ::= SEQUENCE { 1143 trustpoint Certificate, 1144 -- self-signed certificate 1145 pathLenConstraint [0] PathLenConstraint OPTIONAL, 1146 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 1147 -- If not present "any policy" 1148 nameConstraints [2] NameConstraints OPTIONAL, 1149 policyConstraints [3] PolicyConstraints OPTIONAL } 1151 PathLenConstraint ::= INTEGER (0..MAX) 1153 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 1155 CertPolicyId ::= OBJECT IDENTIFIER 1157 NameConstraints ::= SEQUENCE { 1158 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1159 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1161 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1163 GeneralSubtree ::= SEQUENCE { 1164 base GeneralName, 1165 minimum [0] BaseDistance DEFAULT 0, 1166 maximum [1] BaseDistance OPTIONAL } 1168 BaseDistance ::= INTEGER (0..MAX) 1170 PolicyConstraints ::= SEQUENCE { 1171 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1172 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1174 SkipCerts ::= INTEGER (0..MAX) 1176 CertRevReq ::= SEQUENCE { 1177 endCertRevReq RevReq, 1178 caCerts [0] RevReq 1179 } 1181 RevReq ::= SEQUENCE { 1182 enuRevReq EnuRevReq, 1183 exRevReq SignPolExtensions OPTIONAL} 1185 Internet Draft Electronic Signature Policies 1187 EnuRevReq ::= ENUMERATED { 1188 clrCheck (0), --Checks must be made against current CRLs 1189 -- (or authority revocation lists) 1190 ocspCheck (1), -- The revocation status must be checked 1191 -- using the Online Certificate Status Protocol (RFC 2450) 1192 bothCheck (2), 1193 -- Both CRL and OCSP checks must be carried out 1194 eitherCheck (3), 1195 -- At least one of CRL or OCSP checks must be carried out 1196 noCheck (4), 1197 -- no check is mandated 1198 other (5) 1199 -- Other mechanism as defined by signature policy extension 1200 } 1202 SigningCertTrustCondition ::= SEQUENCE { 1203 signerTrustTrees CertificateTrustTrees, 1204 signerRevReq CertRevReq 1205 } 1207 TimestampTrustCondition ::= SEQUENCE { 1208 ttsCertificateTrustTrees [0] CertificateTrustTrees 1209 OPTIONAL, 1210 ttsRevReq [1] CertRevReq 1211 OPTIONAL, 1212 ttsNameConstraints [2] NameConstraints 1213 OPTIONAL, 1214 cautionPeriod [3] DeltaTime 1215 OPTIONAL, 1216 signatureTimestampDelay [4] DeltaTime 1217 OPTIONAL } 1219 DeltaTime ::= SEQUENCE { 1220 deltaSeconds INTEGER, 1221 deltaMinutes INTEGER, 1222 deltaHours INTEGER, 1223 deltaDays INTEGER } 1225 AttributeTrustCondition ::= SEQUENCE { 1226 attributeMandated BOOLEAN, 1227 -- Attribute must be present 1228 howCertAttribute HowCertAttribute, 1229 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 1230 attrRevReq [1] CertRevReq OPTIONAL, 1231 attributeConstraints [2] AttributeConstraints OPTIONAL } 1233 HowCertAttribute ::= ENUMERATED { 1234 claimedAttribute (0), 1235 certifiedAttribtes (1), 1236 either (2) } 1238 Internet Draft Electronic Signature Policies 1240 AttributeConstraints ::= SEQUENCE { 1241 attributeTypeConstarints [0] AttributeTypeConstraints 1242 OPTIONAL, 1243 attributeValueConstarints [1] AttributeValueConstraints 1244 OPTIONAL } 1246 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 1248 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 1250 AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on: 1251 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 1252 -- signer 1253 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 1254 -- issuer of end entity certs. 1255 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 1256 -- issuer of CA certificates 1257 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 1258 -- Attribute Authority 1259 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 1260 -- TimeStamping Authority 1261 } 1263 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 1265 AlgAndLength ::= SEQUENCE { 1266 algID OBJECT IDENTIFIER, 1267 minKeyLength INTEGER OPTIONAL, 1268 -- Minimum key length in bits other 1269 SignPolExtensions OPTIONAL 1270 } 1272 SignPolExtensions ::= SEQUENCE OF SignPolExtn 1274 SignPolExtn ::= SEQUENCE { 1275 extnID OBJECT IDENTIFIER, 1276 extnValue OCTET STRING } 1278 END -- ETS-ElectronicSignaturePolicies-88syntax -- 1280 Internet Draft Electronic Signature Policies 1282 A.2 Definitions Using X.680 1997 ASN.1 Syntax 1284 NOTE: The ASN.1 module defined in section A.1 has precedence over that 1285 defined in section A.2 in the case of any conflict. 1287 ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2) 1288 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8} 1290 DEFINITIONS EXPLICIT TAGS ::= 1291 BEGIN 1292 -- EXPORTS All - 1294 IMPORTS 1296 -- Internet X.509 Public Key Infrastructure 1297 -- Certificate and CRL Profile: RFC 2459 1298 Certificate, AlgorithmIdentifier, CertificateList, Name, 1299 GeneralNames, GeneralName, DirectoryString, Attribute, 1300 AttributeTypeAndValue, AttributeType, AttributeValue, 1301 PolicyInformation 1303 FROM PKIX1Explicit93 1304 {iso(1) identified-organization(3) dod(6) internet(1) 1305 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1306 ; 1308 -- S/MIME Object Identifier arcs used in the present document 1309 -- ================================================================== 1311 -- S/MIME OID arc used in the present document 1312 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1313 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 1315 -- S/MIME Arcs 1316 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 1317 -- modules 1318 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 1319 -- content types 1320 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 1321 -- attributes 1322 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 1323 -- signature policy qualifier 1324 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 1325 -- commitment type identifier 1327 Internet Draft Electronic Signature Policies 1329 -- Signature Policy Specification 1330 -- ============================== 1332 SignaturePolicy ::= SEQUENCE { 1333 signPolicyHashAlg AlgorithmIdentifier, 1334 signPolicyInfo SignPolicyInfo, 1335 signPolicyHash SignPolicyHash OPTIONAL } 1337 SignPolicyHash ::= OCTET STRING 1339 SignPolicyInfo ::= SEQUENCE { 1340 signPolicyIdentifier SignPolicyId, 1341 dateOfIssue GeneralizedTime, 1342 policyIssuerName PolicyIssuerName, 1343 fieldOfApplication FieldOfApplication, 1344 signatureValidationPolicy SignatureValidationPolicy, 1345 signPolExtensions SignPolExtensions 1346 OPTIONAL 1347 } 1349 SignPolicyId ::= OBJECT IDENTIFIER 1351 PolicyIssuerName ::= GeneralNames 1353 FieldOfApplication ::= DirectoryString 1355 SignatureValidationPolicy ::= SEQUENCE { 1356 signingPeriod SigningPeriod, 1357 commonRules CommonRules, 1358 commitmentRules CommitmentRules, 1359 signPolExtensions SignPolExtensions OPTIONAL 1360 } 1362 SigningPeriod ::= SEQUENCE { 1363 notBefore GeneralizedTime, 1364 notAfter GeneralizedTime OPTIONAL } 1366 Internet Draft Electronic Signature Policies 1368 CommonRules ::= SEQUENCE { 1369 signerAndVeriferRules [0] SignerAndVerifierRules 1370 OPTIONAL, 1371 signingCertTrustCondition [1] SigningCertTrustCondition 1372 OPTIONAL, 1373 timeStampTrustCondition [2] TimestampTrustCondition 1374 OPTIONAL, 1375 attributeTrustCondition [3] AttributeTrustCondition 1376 OPTIONAL, 1377 algorithmConstraintSet [4] AlgorithmConstraintSet 1378 OPTIONAL, 1379 signPolExtensions [5] SignPolExtensions 1380 OPTIONAL 1381 } 1383 CommitmentRules ::= SEQUENCE OF CommitmentRule 1385 CommitmentRule ::= SEQUENCE { 1386 selCommitmentTypes SelectedCommitmentTypes, 1387 signerAndVeriferRules [0] SignerAndVerifierRules 1388 OPTIONAL, 1389 signingCertTrustCondition [1] SigningCertTrustCondition 1390 OPTIONAL, 1391 timeStampTrustCondition [2] TimestampTrustCondition 1392 OPTIONAL, 1393 attributeTrustCondition [3] AttributeTrustCondition 1394 OPTIONAL, 1395 algorithmConstraintSet [4] AlgorithmConstraintSet 1396 OPTIONAL, 1397 signPolExtensions [5] SignPolExtensions 1398 OPTIONAL 1399 } 1401 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 1402 empty NULL, 1403 recognizedCommitmentType CommitmentType } 1405 CommitmentType ::= SEQUENCE { 1406 identifier CommitmentTypeIdentifier, 1407 fieldOfApplication [0] FieldOfApplication OPTIONAL, 1408 semantics [1] DirectoryString OPTIONAL } 1410 SignerAndVerifierRules ::= SEQUENCE { 1411 signerRules SignerRules, 1412 verifierRules VerifierRules } 1414 Internet Draft Electronic Signature Policies 1416 SignerRules ::= SEQUENCE { 1417 externalSignedData BOOLEAN OPTIONAL, 1418 -- True if signed data is external to CMS structure 1419 -- False if signed data part of CMS structure 1420 -- not present if either allowed 1421 mandatedSignedAttr CMSAttrs, 1422 -- Mandated CMS signed attributes 1423 mandatedUnsignedAttr CMSAttrs, 1424 -- Mandated CMS unsigned attributed 1425 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 1426 -- Mandated Certificate Reference 1427 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 1428 -- Mandated Certificate Info 1429 signPolExtensions [2] SignPolExtensions OPTIONAL 1430 } 1432 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 1434 CertRefReq ::= ENUMERATED { 1435 signerOnly (1), 1436 -- Only reference to signer cert mandated 1437 fullPath (2) 1438 -- References for full cert path up to a trust 1439 -- point required 1440 } 1442 CertInfoReq ::= ENUMERATED { 1443 none (0) , 1444 -- No mandatory requirements 1445 signerOnly (1) , 1446 -- Only reference to signer cert mandated 1447 fullPath (2) 1448 -- References for full cert path up to a 1449 -- trust point mandated 1450 } 1452 VerifierRules ::= SEQUENCE { 1453 mandatedUnsignedAttr MandatedUnsignedAttr, 1454 signPolExtensions SignPolExtensions OPTIONAL 1455 } 1457 MandatedUnsignedAttr ::= CMSAttrs 1458 -- Mandated CMS unsigned attributed 1460 Internet Draft Electronic Signature Policies 1462 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 1464 CertificateTrustPoint ::= SEQUENCE { 1465 trustpoint Certificate, 1466 -- self-signed certificate 1467 pathLenConstraint [0] PathLenConstraint OPTIONAL, 1468 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 1469 -- If not present "any policy" 1470 nameConstraints [2] NameConstraints OPTIONAL, 1471 policyConstraints [3] PolicyConstraints OPTIONAL } 1473 PathLenConstraint ::= INTEGER (0..MAX) 1475 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 1477 CertPolicyId ::= OBJECT IDENTIFIER 1479 NameConstraints ::= SEQUENCE { 1480 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1481 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1483 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1485 GeneralSubtree ::= SEQUENCE { 1486 base GeneralName, 1487 minimum [0] BaseDistance DEFAULT 0, 1488 maximum [1] BaseDistance OPTIONAL } 1490 BaseDistance ::= INTEGER (0..MAX) 1492 PolicyConstraints ::= SEQUENCE { 1493 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1494 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1496 SkipCerts ::= INTEGER (0..MAX) 1498 CertRevReq ::= SEQUENCE { 1499 endCertRevReq RevReq, 1500 caCerts [0] RevReq 1501 } 1503 RevReq ::= SEQUENCE { 1504 enuRevReq EnuRevReq, 1505 exRevReq SignPolExtensions OPTIONAL} 1507 Internet Draft Electronic Signature Policies 1509 EnuRevReq ::= ENUMERATED { 1510 clrCheck (0), 1511 -- Checks must be made against current CRLs 1512 -- (or authority revocation lists) 1513 ocspCheck (1), 1514 -- The revocation status must be checked using 1515 -- the Online Certificate Status Protocol (RFC 2450) 1516 bothCheck (2), 1517 -- Both CRL and OCSP checks must be carried out 1518 eitherCheck (3), 1519 -- At least one of CRL or OCSP checks must be carried out 1520 noCheck (4), 1521 -- no check is mandated 1522 other (5) 1523 -- Other mechanism as defined by signature policy 1524 -- extension 1525 } 1527 SigningCertTrustCondition ::= SEQUENCE { 1528 signerTrustTrees CertificateTrustTrees, 1529 signerRevReq CertRevReq 1530 } 1532 TimestampTrustCondition ::= SEQUENCE { 1533 ttsCertificateTrustTrees [0] CertificateTrustTrees 1534 OPTIONAL, 1535 ttsRevReq [1] CertRevReq 1536 OPTIONAL, 1537 ttsNameConstraints [2] NameConstraints 1538 OPTIONAL, 1539 cautionPeriod [3] DeltaTime 1540 OPTIONAL, 1541 signatureTimestampDelay [4] DeltaTime 1542 OPTIONAL } 1544 DeltaTime ::= SEQUENCE { 1545 deltaSeconds INTEGER, 1546 deltaMinutes INTEGER, 1547 deltaHours INTEGER, 1548 deltaDays INTEGER } 1550 AttributeTrustCondition ::= SEQUENCE { 1551 attributeMandated BOOLEAN, 1552 -- Attribute must be present 1553 howCertAttribute HowCertAttribute, 1554 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 1555 attrRevReq [1] CertRevReq OPTIONAL, 1556 attributeConstraints [2] AttributeConstraints OPTIONAL } 1558 Internet Draft Electronic Signature Policies 1560 HowCertAttribute ::= ENUMERATED { 1561 claimedAttribute (0), 1562 certifiedAttribtes (1), 1563 either (2) } 1565 AttributeConstraints ::= SEQUENCE { 1566 attributeTypeConstarints [0] AttributeTypeConstraints 1567 OPTIONAL, 1568 attributeValueConstarints [1] AttributeValueConstraints 1569 OPTIONAL } 1571 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 1573 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 1575 AlgorithmConstraintSet ::= SEQUENCE { 1576 -- Algorithm constrains on: 1577 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 1578 -- signer 1579 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 1580 -- issuer of end entity certs. 1581 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 1582 -- issuer of CA certificates 1583 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 1584 -- Attribute Authority 1585 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 1586 -- TimeStamping Authority 1587 } 1589 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 1591 AlgAndLength ::= SEQUENCE { 1592 algID OBJECT IDENTIFIER, 1593 minKeyLength INTEGER OPTIONAL, 1594 -- Minimum key length in bits 1595 other SignPolExtensions OPTIONAL 1596 } 1598 SignPolExtensions ::= SEQUENCE OF SignPolExtn 1600 SignPolExtn ::= SEQUENCE { 1601 extnID OBJECT IDENTIFIER, 1602 extnValue OCTET STRING } 1604 END -- ETS-ElectronicPolicies-97Syntax 1606 Internet Draft Electronic Signature Policies 1608 Annex B (informative): 1610 B.1 Signature Policy and Signature Validation Policy 1612 The definition of electronic signature mentions: "a commitment has been 1613 explicitly endorsed under a "Signature Policy", at a given time, by a 1614 signer under an identifier, e.g. a name or a pseudonym, and optionally 1615 a role. " 1617 Electronic signatures are commonly applied within the context of a 1618 legal or contractual framework. This establishes the requirements on 1619 the electronic signatures and any special semantics (e.g. agreement, 1620 intent). These requirements may be defined in very general abstract 1621 terms or in terms of detailed rules. The specific semantics associated 1622 with an electronic signature implied by a legal or contractual 1623 framework are outside the scope of this document. 1625 If the signature policy is recognized, within the legal/contractual 1626 context, as providing commitment, then the signer explicitly agrees 1627 with terms and conditions which are implicitly or explicitly part of 1628 the signed data. 1630 When two independent parties want to evaluate an electronic signature, 1631 it is fundamental that they get the same result. It is therefore 1632 important that the conditions agreed by the signer at the time of 1633 signing are indicated to the verifier and any arbitrator. An aspect 1634 that enables this to be known by all parties is the signature policy. 1635 The technical implications of the signature policy on the electronic 1636 signature with all the validation data are called the "Signature 1637 Validation Policy". The signature validation policy specifies 1638 the rules used to validate the signature. 1640 This document does not mandate the form and encoding of the 1641 specification of the signature policy. However, for a given signature 1642 policy there must be one definitive form that has a unique binary 1643 encoded value. 1645 This document includes, as an option, a formal structure for signature 1646 validation policy based on the use of Abstract Syntax Notation 1 1647 (ASN.1). 1649 Given the specification of the signature policy and its hash value an 1650 implementation of a verification process must obey the rules defined 1651 in the specification. 1653 This document places no restriction on how it should be implemented. 1654 Provide the implementation conforms to the conformance requirements as 1655 define in section 5 implementation options include: 1657 Internet Draft Electronic Signature Policies 1659 A validation process that supports a specific signature policy as 1660 identified by the signature policy OID. Such an implementation should 1661 conform to a human readable description provided all the processing 1662 rules of the signature policy are clearly defined. However, if 1663 additional policies need to be supported, then such an implementation 1664 would need to be customized for each additional policy. This type of 1665 implementation may be simpler to implement initially, but can be 1666 difficult to enhance to support numerous additional signature policies. 1668 A validation process that is dynamically programmable and able to adapt 1669 its validation rules in accordance with a description of the signature 1670 policy provided in a computer-processable language. This present 1671 document defines such a policy using an ASN.1 structure (see 6.1). This 1672 type of implementation could support multiple signature policies 1673 without being modified every time, provided all the validation rules 1674 specified as part of the signature policy are known by the 1675 implementation. (i.e. only requires modification if there are 1676 additional rules specified). 1678 The precise content of a signature policy is not mandated by the 1679 current document. However, a signature policy must be sufficiently 1680 definitive to avoid any ambiguity as to its implementation 1681 requirements. It must be absolutely clear under which conditions an 1682 electronic signature should be accepted. For this reason, it should 1683 contain the following information: 1685 * General information about the signature policy which includes: 1686 - a unique identifier of the policy; 1687 - the name of the issuer of the policy; 1688 - the date the policy was issued; 1689 - the field of application of the policy. 1691 * The signature verification policy which includes: 1692 - the signing period, 1693 - a list of recognized commitment types; 1694 - rules for Use of Certification Authorities; 1695 - rules for Use of Revocation Status Information; 1696 - rules for Use of Roles; 1697 - rules for use of Timestamping and Timing; 1698 - signature verification data to be provided by the 1699 signer/collected by verifier; 1700 - any constraints on signature algorithms and key lengths. 1701 * Other signature policy rules required to meet the objectives of 1702 the signature. 1704 Variations of the validation policy rules may apply to different 1705 commitment types. 1707 Internet Draft Electronic Signature Policies 1709 B.2 Identification of Signature Policy 1711 When data is signed the signer indicates the signature policy 1712 applicable to that electronic signature by including an object 1713 identifier for the signature policy with the signature. The signer and 1714 verifier must apply the rules specified by the identified policy. In 1715 addition to the identifier of the signature policy the signer must 1716 include the hash of the signature policy, so it can be verified that 1717 the policy selected by the signer is the identical to the one being 1718 used the verifier. 1720 A signature policy may be qualified by additional information. This can 1721 includes: 1723 * A URL where a copy of the Signature Policy may be obtained; 1724 * A user notice that should be displayed when the signature is 1725 verified; 1727 If no signature policy is identified then the signature may be assumed 1728 to have been generated/verified without any policy constraints, and 1729 hence may be given no specific legal or contractual significance 1730 through the context of a signature policy. 1732 A "Signature Policy" will be identifiable by an OID (Object Identifier) 1733 and verifiable using a hash of the signature policy. 1735 B.3 General Signature Policy Information 1737 General information should be recorded about the signature policy along 1738 with the definition of the rules which form the signature policy as 1739 described in subsequent subsections. This should include: 1741 * Policy Object Identifier: The "Signature Policy" will be 1742 identifiable by an OID (Object Identifier) whose last component 1743 (i.e. right most) is an integer that is specific to a particular 1744 version issued on the given date. 1745 * Date of issue: When the "Signature Policy" was issued. 1746 * Signature Policy Issuer name: An identifier for the body 1747 responsible for issuing the Signature Policy. This may be used 1748 by the signer or verifying in deciding if a policy is to be 1749 trusted, in which case the signer/verifier must authenticate 1750 the origin of the signature policy as coming from the identified 1751 issuer. 1752 * Signing period: The start time and date, optionally with an end 1753 time and date, for the period over which the signature policy 1754 may be used to generate electronic signatures. 1755 * Field of application: This defines in general terms the general 1756 legal/contract/application contexts in which the signature 1757 policy is to be used and the specific purposes for which the 1758 electronic signature is to be applied. 1760 Internet Draft Electronic Signature Policies 1762 B.4 Recognized Commitment Types 1764 The signature validation policy may recognize one or more types of 1765 commitment as being supported by electronic signatures produced under 1766 the security policy. If an electronic signature does not contain a 1767 recognized commitment type then the semantics of the electronic 1768 signature is dependent on the data being signed and the context in 1769 which it is being used. 1771 Only recognized commitment types are allowed in an electronic 1772 signature. 1774 The definition of a commitment type includes: 1775 * the object identifier for the commitment; 1776 * the contractual/legal/application context in which the signature 1777 may be used (e.g. submission of messages); 1778 * a description of the support provided within the terms of the 1779 context (e.g. proof that the identified source submitted the 1780 message if the signature is created when message submission is 1781 initiated). 1783 The definition of a commitment type can be registered: 1784 * as part of the validation policy; 1785 * as part of the application/contract/legal environment; 1786 * as part of generic register of definitions. 1788 The legal/contractual context will determine the rules applied to the 1789 signature, as defined by the signature policy and its recognized 1790 commitment types, make it fit for purpose intended. 1792 B.5 Rules for Use of Certification Authorities 1794 The certificate validation process of the verifier, and hence the 1795 certificates that may be used by the signer for a valid electronic 1796 signature, may be constrained by the combination of the trust point and 1797 certificate path constraints in the signature validation policy. 1799 B.5.1 Trust Points 1801 The signature validation policy defines the certification authority 1802 trust points that are to be used for signature verification. Several 1803 trust points may be specified under one signature policy. Specific 1804 trust points may be specified for a particular type of commitment 1805 defined under the signature policy. For a signature to be valid a 1806 certification path must exists between the Certification Authority 1807 that has granted the certificate selected by the signer (i.e. the used 1808 user-certificate) and one of the trust point of the "Signature 1809 Validation Policy". 1811 Internet Draft Electronic Signature Policies 1813 B.5.2 Certification Path 1815 There may be constraints on the use of certificates issued by one or 1816 more CA(s) in the certificate chain and trust points. The two prime 1817 constraints are certificate policy constraints and naming constraints: 1819 * Certificate policy constraints limit the certification chain 1820 between the user certificate and the certificate of the trusted 1821 point to a given set of certificate policies, or equivalents 1822 identified through certificate policy mapping. 1823 * The naming constraints limit the forms of names that the CA is 1824 allowed to certify. 1826 Name constraints are particularly important when a "Signature policy" 1827 identifies more than one trust point. In this case, a certificate of a 1828 particular trusted point may only be used to verify signatures from 1829 users with names permitted under the name constraint. 1831 Certificate Authorities may be organized in a tree structure, this tree 1832 structure may represent the trust relationship between various CA(s) 1833 and the users CA. Alternatively, a mesh relationship may exist where a 1834 combination of tree and peer cross-certificates may be used. The 1835 requirement of the certificate path in this document is that it 1836 provides the trust relationship between all the CAs and the signers 1837 user certificate. The starting point from a verification point of view, 1838 is the "trust point". A trust point is usually a CA that publishes 1839 self-certified certificates, is the starting point from which the 1840 verifier verifies the certificate chain. Naming constraints may 1841 apply from the trust point, in which case they apply throughout the set 1842 of certificates that make up the certificate path down to the signer's 1843 user certificate. 1845 Policy constraints can be easier to process but to be effective require 1846 the presence of a certificate policy identifier in the certificates 1847 used in a certification path. 1849 Certificate path processing, thus generally starts with one of the 1850 trust point from the signature policy and ends with the user 1851 certificate. The certificate path processing procedures defined in RFC 1852 2459 section 6 identifies the following initial parameters that are 1853 selected by the verifier in certificate path processing: 1855 * acceptable certificate policies; 1856 * naming constraints in terms of constrained and excluded naming 1857 subtree; 1858 * requirements for explicit certificate policy indication and 1859 whether certificate policy mapping are allowed; 1860 * restrictions on the certificate path length. 1862 The signature validation policy identifies constraints on these 1863 parameters. 1865 Internet Draft Electronic Signature Policies 1867 B.6 Revocation Rules 1869 The signature policy should defines rules specifying requirements for 1870 the use of certificate revocation lists (CRLs) and/or on-line 1871 certificate status check service to check the validity of a certificate. 1872 These rules specify the mandated minimum checks that must be carried 1873 out. 1875 It is expected that in many cases either check may be selected with 1876 CRLs checks being carried out for certificate status that are 1877 unavailable from OCSP servers. The verifier may take into account 1878 information in the certificate in deciding how best to check the 1879 revocation status (e.g. a certificate extension field about authority 1880 information access or a CRL distribution point) provided that it does 1881 not conflict with the signature policy revocation rules. 1883 B.7 Rules for the Use of Roles 1885 Roles can be supported as claimed roles or as certified roles using 1886 Attribute Certificates. 1888 B.7.1 Attribute Values 1890 When signature under a role is mandated by the signature policy, then 1891 either Attribute Certificates may be used or the signer may provide a 1892 claimed role attribute. The acceptable attribute types or values may be 1893 dependent on the type of commitment. For example, a user may have 1894 several roles that allow the user to sign data that imply commitments 1895 based on one or more of his roles. 1897 B.7.2 Trust Points for Certified Attributes 1899 When a signature under a certified role is mandated by the signature 1900 policy, Attribute Authorities are used and need to be validated as part 1901 of the overall validation of the electronic signature. The trust points 1902 for Attribute Authorities do not need to be the same as the trust 1903 points to evaluate a certificate from the CA of the signer. Thus the 1904 trust point for verifying roles need not be the same as trust point 1905 used to validate the certificate path of the user's key. 1907 Naming and certification policy constraints may apply to the AA in 1908 similar circumstance to when they apply to CA. Constraints on the AA 1909 and CA need not be exactly the same. 1911 AA(s) may be used when a signer is creating a signature on behalf of an 1912 organization, they can be particularly useful when the signature 1913 represents an organizational role. AA(s) may or may not be the same 1914 authority as CA(s). 1916 Thus, the Signature Policy identifies trust points that can be used for 1917 Attribute Authorities, either by reference to the same trust points as 1918 used for Certification Authorities, or by an independent list. 1920 Internet Draft Electronic Signature Policies 1922 B.7.3 Certification Path for Certified Attributes 1924 Attribute Authorities may be organized in a tree structure in similar 1925 way to CA where the AAs are the leafs of such a tree. Naming and other 1926 constraints may be required on attribute certificate paths in a similar 1927 manner to other electronic signature certificate paths. 1929 Thus, the Signature Policy identify constraints on the following 1930 parameters used as input to the certificate path processing: 1932 * acceptable certificate policies, including requirements for 1933 explicit certificate policy indication and whether certificate 1934 policy mapping is allowed; 1935 * naming constraints in terms of constrained and excluded naming 1936 subtrees; 1937 * restrictions on the certificate path length. 1939 B.8 Rules for the Use of Timestamping and Timing 1941 The following rules should be used when specifying, constraints on the 1942 certificate paths for timestamping authorities, constraints on the 1943 timestamping authority names and general timing constraints. 1945 B.8.1 Trust Points and Certificate Paths 1947 Signature keys from timestamping authorities will need to be supported 1948 by a certification path. The certification path used for timestamping 1949 authorities requires a trustpoint and possibly path constraints in the 1950 same way that the certificate path for the signer's key. 1952 B.8.2 Timestamping Authority Names 1954 Restrictions may need to be placed by the validation policy on the 1955 named entities that may act a timestamping authorities. 1957 B.8.3 Timing Constraints - Caution Period 1959 Before an electronic signature may really be valid, the verifier has to 1960 be sure that the holder of the private key was really the only one in 1961 possession of key at the time of signing. However, there is an 1962 inevitable delay between a compromise or loss of key being noted, and a 1963 report of revocation being distributed. To allow greater confidence in 1964 the validity of a signature, a "cautionary period" may be identified 1965 before a signature may be said to be valid with high confidence. A 1966 verifier may revalidate a signature after this cautionary signature, or 1967 wait for this period before validating a signature. 1969 The validation policy may specify such a cautionary period. 1971 Internet Draft Electronic Signature Policies 1973 B.8.4 Timing Constraints - Timestamp Delay 1975 There will be some delay between the time that a signature is created 1976 and the time the signer's digital signature is timestamped. However, 1977 the longer this elapsed period the greater the risk of the signature 1978 being invalidated due to compromise or deliberate revocation of its 1979 private signing key by the signer. Thus the signature policy should 1980 specify a maximum acceptable delay between the signing time as claimed 1981 by the signer and the time included within the timestamp. 1983 B.9 Rules for Verification Data to be followed 1985 By specifying the requirements on the signer and verifier the 1986 responsibilities of the two parties can be clearly defined to establish 1987 all the necessary information. 1989 These verification data rules should include: 1990 * requirements on the signer to provide given signed attributes; 1991 * requirements on the verifier to obtain additional certificates, CRLs, 1992 results of on line certificate status checks and to use timestamps (if 1993 no already provided by the signer). 1995 B.10 Rules for Algorithm Constraints and Key Lengths 1996 The signature validation policy may identify a set of signing 1997 algorithms (hashing, public key, combinations) and minimum key lengths 1998 that may be used: 2000 * by the signer in creating the signature; 2001 * in end entity public key Certificates; 2002 * CA Certificates; 2003 * attribute Certificates; 2004 * by the timestamping authority. 2006 B.11 Other Signature Policy Rules 2008 The signature policy may specify additional policy rules, for example 2009 rules that relate to the environment used by the signer. These 2010 additional rules may be defined in computer processable and/or human 2011 readable form. 2013 B.12 Signature Policy Protection 2015 When signer or verifier obtains a copy of the Signature Policy from an 2016 issuer, the source should be authenticated (for example by using 2017 electronic signatures). When the signer references a signature policy 2018 the Object Identifier (OID) of the policy, the hash value and the hash 2019 algorithm OID of that policy must be included in the Electronic 2020 Signature. 2022 Internet Draft Electronic Signature Policies 2024 It is a mandatory requirement of this present document that the 2025 signature policy value computes to one, and only one hash value using 2026 the specified hash algorithm. This means that there must be a single 2027 binary value of the encoded form of the signature policy for the unique 2028 hash value to be calculated. For example, there may exist a particular 2029 file type, length and format on which the hash value is calculated 2030 which is fixed and definitive for a particular signature policy. 2032 The hash value may be obtained by: 2034 the signer performing his own computation of the hash over the 2035 signature policy using his preferred hash algorithm permitted by 2036 the signature policy, and the definitive binary encoded form. 2038 the signer, having verified the source of the policy, may use 2039 both the hash algorithm and the hash value included in the 2040 computer processable form of the policy (see section 6.1).