idnits 2.17.1 draft-ietf-smime-espolicies-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 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 8 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 754 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 (July 2000) is 8684 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1574 -- Looks like a reference, but probably isn't: '1' on line 1576 -- Looks like a reference, but probably isn't: '2' on line 1578 -- Looks like a reference, but probably isn't: '3' on line 1580 -- Looks like a reference, but probably isn't: '4' on line 1582 -- Looks like a reference, but probably isn't: '5' on line 1394 -- Looks like a reference, but probably isn't: '7' on line 515 == Unused Reference: 'ES201733' is defined on line 871, but no explicit reference was found in the text == Unused Reference: 'OCSP' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'ESS' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'CMS' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC2459' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'PKCS9' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'ISONR' is defined on line 902, 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 July 2000 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 ES 201 733 V.1.1.3(2000-05) Copyright (C). 54 Internet Draft Electronic Signature Policies 56 TABLE OF CONTENTS 58 Abstract 1 59 Table of contents 2 60 1. Introduction 3 61 2. Major Parties 3 62 3. Signature Policy Specification 5 63 3.1 Overall ASN.1 Structure 5 64 3.2 Signature Validation Policy 6 65 3.3 Common Rules 7 66 3.4 Commitment Rules 8 67 3.5 Signer and Verifier Rules 9 68 3.5.1 Signer Rules 9 69 3.5.2 Verifier Rules 10 70 3.6 Certificate and Revocation Requirements 11 71 3.6.1 Certificate Requirements 11 72 3.6.2 Revocation Requirements 13 73 3.7 Signing Certificate Trust Conditions 14 74 3.8 TimeStamp Trust Conditions 15 75 3.9 Attribute Trust Conditions 15 76 3.10 Algorithm Constraints 16 77 3.11 Signature Policy Extensions 17 78 4. Security considerations 18 79 5. Conformance Requirements 18 80 6. References 18 81 7. Authors' Addresses 19 82 8. Full Copyright Statement 20 83 Annex A (normative): 21 84 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 21 85 A.2 Definitions Using X.680 (1997) ASN.1 Syntax 27 86 Annex B (informative): 34 87 B.1 Signature Policy and Signature Validation Policy 34 88 B.2 Identification of Signature Policy 36 89 B.3 General Signature Policy Information 36 90 B.4 Recognized Commitment Types 37 91 B.5 Rules for Use of Certification Authorities 37 92 B.5.1 Trust Points 37 93 B.5.2 Certification Path 38 94 B.6 Revocation Rules 39 95 B.7 Rules for the Use of Roles 39 96 B.7.1 Attribute Values 39 97 B.7.2 Trust Points for Certified Attributes 39 98 B.7.3 Certification Path for Certified Attributes 40 99 B.8 Rules for the Use of Timestamping and Timing 40 100 B.8.1 Trust Points and Certificate Paths 40 101 B.8.2 Timestamping Authority Names 40 102 B.8.3 Timing Constraints - Caution Period 40 103 B.8.4 Timing Constraints - Timestamp Delay 41 104 B.9 Rules for Verification Data to be followed 41 105 B.10 Rules for Algorithm Constraints and Key Lengths 41 106 B.11 Other Signature Policy Rules 41 107 B.12 Signature Policy Protection 41 109 Internet Draft A Signature Policy Format 111 1. Introduction 113 This document is intended to cover signature policies which can be 114 used with electronic signatures for various types of transactions, 115 including business transactions (e.g. purchase requisition, contract, 116 and invoice applications). Electronic signatures can be used for any 117 transaction between an individual and a company, between two 118 companies, between an individual and a governmental body, etc. 119 This document is independent of any environment. It can be applied 120 to any environment e.g. smart cards, GSM SIM cards, special programs 121 for electronic signatures etc. 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 124 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 125 as shown) are to be interpreted as described in [RFC2119]. 127 2.3 Major Parties 129 The document uses the following terms: 131 * the Signature Policy Issuer; 132 * the Signer; 133 * the Verifier; 134 * the Arbitrator; 135 * Trusted Service Providers (TSP); 137 The Signature Policy Issuer (which is a Trusted Service Provider (TSP)) 138 issues signatures policies that define the technical and procedural 139 requirements for electronic signature creation, and validation/ 140 verification, in order to meet a particular business need. 142 The Signer is the entity that creates the electronic signature. When 143 the signer digitally signs over an signature policy identifier, it 144 represents a commitment on behalf of the signing entity that the data 145 being signed is signed under the rules defined by the signature policy. 147 The Verifier is the entity that validates the electronic signature, it 148 may be a single entity or multiple entities. The verifier MUST validate 149 the electronic signature under the rules defined by the electronic signature 150 policy for the signature to be valid. 152 An arbitrator, is an entity which arbitrates disputes between a signer 153 and a verifier. It acts as verifier when it verifies the electronic 154 signature after it has been previously validated. 156 Internet Draft Electronic Signature Policies 158 The Trusted Service Providers (TSPs) are one or more entities that help 159 to build trust relationships between the signer and verifier. Use of TSP 160 specific services MAY be mandated by signature policy. TSP supporting 161 services include: user certificates, cross-certificates, timestamping 162 tokens,CRLs, ARLs, OCSP responses. 164 A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer, as 165 Such, the TSP MUST define the technical and procedural requirements for 166 electronic signature creation and validation, in order to meet a 167 particular business need. 169 The following other TSPs are used to support the 170 functions defined in this document: 172 * Certification Authorities; 173 * Registration Authorities; 174 * Repository Authorities (e.g. a Directory); 175 * TimeStamping Authorities; 176 * One-line Certificate Status Protocol responders; 177 * Attribute Authorities. 179 Certification Authorities provide users with public key certificates. 181 Registration Authorities allows the registration of entities before a 182 CA generates certificates. 184 Repository Authorities publish CRLs issued by CAs, , cross-certificates 185 (i.e. CA certificates) issued by CAs, signature policies 186 issued by Signature Policy Issuers and optionally public key 187 certificates (i.e. leaf certificates) issued by CAs. 189 TimeStamping Authorities attest that some data was formed before a 190 given trusted time. 192 One-line Certificate Status Protocol responders (OSCP responders) 193 provide information about the status (i.e. revoked, not revoked, 194 unknown) of a particular certificate. 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 Internet Draft Electronic Signature Policies 204 3. Signature Policy Specification 206 A signature policy specification includes general information about the 207 policy, the validation policy rules and other signature policy 208 information. 210 This document mandates that: 211 * an electronic signature must be processed by the signer and 212 verifier in accordance with the signature policy referenced by 213 the signer; 214 * the signature policy referenced by the signer must be 215 identifiable by an Object Identifier; 216 * there must exist a specification of the signature policy; 217 * for a given signature policy there must be one definitive form 218 of the specification which has a unique binary encoding; 219 * a hash of the definitive specification, using an agreed 220 algorithm, must be provided by the signer and checked by the 221 verifier. 223 This document defines but does not mandate the form of the signature 224 policy specification. The signature policy may be specified either: 226 * in a free form document for human interpretation; or 227 * in a structured form using an agreed syntax and encoding. 229 This document defines an ASN.1 based syntax that may be used to define 230 a structured signature policy. Future versions of this document may 231 include structured a signature policy specification using XML. 233 3.1 Overall ASN.1 Structure 235 The overall structure of a signature policy defined using ASN.1 is 236 given in this clause. Use of this ASN.1 structure is optional. 238 This ASN.1 syntax is encoded using the Distinguished Encoding Rules 239 (DER). 241 Internet Draft Electronic Signature Policies 243 In this structure the policy information is preceded by an identifier 244 for the hashing algorithm used to protect the signature policy and 245 followed by the hash value which must be re-calculated and checked 246 whenever the signature policy is passed between the issuer and 247 signer/verifier. 248 The hash is calculated without the outer type and length fields. 250 SignaturePolicy ::= SEQUENCE { 251 signPolicyHashAlg AlgorithmIdentifier, 252 signPolicyInfo SignPolicyInfo, 253 signPolicyHash SignPolicyHash OPTIONAL } 255 SignPolicyHash ::= OCTET STRING 257 SignPolicyInfo ::= SEQUENCE { 258 signPolicyIdentifier SignPolicyId, 259 dateOfIssue GeneralizedTime, 260 policyIssuerName PolicyIssuerName, 261 fieldOfApplication FieldOfApplication, 262 signatureValidationPolicy SignatureValidationPolicy, 263 signPolExtensions SignPolExtensions 264 OPTIONAL 265 } 267 SignPolicyId ::= OBJECT IDENTIFIER 269 PolicyIssuerName ::= GeneralNames 271 FieldOfApplication ::= DirectoryString 273 The policyIssuerName field identifies the policy issuer in one or more 274 of the general name forms. 276 The fieldofApplication is a description of the expected application of 277 this policy. 279 The signature validation policy rules are fully processable to allow 280 the validation of electronic signatures issued under that form of 281 signature policy. They are described in the rest of this clause. 283 The signPolExtensions is a generic way to extend the definition of any 284 sub-component of a signature policy. 286 3.2 Signature Validation Policy 288 The signature validation policy defines for the signer which data 289 elements must be present in the electronic signature he provides and 290 for the verifier which data elements must be present under that 291 signature policy for an electronic signature to be potentially valid. 293 Internet Draft Electronic Signature Policies 295 The signature validation policy is described as follows: 297 SignatureValidationPolicy ::= SEQUENCE { 298 signingPeriod SigningPeriod, 299 commonRules CommonRules, 300 commitmentRules CommitmentRules, 301 signPolExtensions SignPolExtensions OPTIONAL 302 } 304 The signingPeriod identifies the date and time before which the 305 signature policy SHOULD NOT be used for creating signatures, and an 306 optional date after which it should not be used for creating 307 signatures. 309 SigningPeriod ::= SEQUENCE { 310 notBefore GeneralizedTime, 311 notAfter GeneralizedTime OPTIONAL } 313 3.3 Common Rules 315 The CommonRules define rules that are common to all commitment types. 316 These rules are defined in terms of trust conditions for certificates, 317 timestamps and attributes, along with any constraints on attributes 318 that may be included in the electronic signature. 320 CommonRules ::= SEQUENCE { 321 signerAndVeriferRules [0] SignerAndVerifierRules 322 OPTIONAL, 323 signingCertTrustCondition [1] SigningCertTrustCondition 324 OPTIONAL, 325 timeStampTrustCondition [2] TimestampTrustCondition 326 OPTIONAL, 327 attributeTrustCondition [3] AttributeTrustCondition 328 OPTIONAL, 329 algorithmConstraintSet [4] AlgorithmConstraintSet 330 OPTIONAL, 331 signPolExtensions [5] SignPolExtensions 332 OPTIONAL 333 } 335 If a field is present in CommonRules then the equivalent field must 336 not be present in any of the CommitmentRules (see below). If any of the 337 following fields are not present in CommonRules then it must be 338 present in each CommitmentRule: 340 * signerAndVeriferRules; 341 * signingCertTrustCondition; 342 * timeStampTrustCondition. 344 Internet Draft Electronic Signature Policies 346 3.4 Commitment Rules 348 The CommitmentRules consists of the validation rules which apply to 349 given commitment types: 351 CommitmentRules ::= SEQUENCE OF CommitmentRule 353 The CommitmentRule for given commitment types are defined in terms of 354 trust conditions for certificates, timestamps and attributes, along 355 with any constraints on attributes that may be included in the 356 electronic signature. 358 CommitmentRule ::= SEQUENCE { 359 selCommitmentTypes SelectedCommitmentTypes, 360 signerAndVeriferRules [0] SignerAndVerifierRules 361 OPTIONAL, 362 signingCertTrustCondition [1] SigningCertTrustCondition 363 OPTIONAL, 364 timeStampTrustCondition [2] TimestampTrustCondition 365 OPTIONAL, 366 attributeTrustCondition [3] AttributeTrustCondition 367 OPTIONAL, 368 algorithmConstraintSet [4] AlgorithmConstraintSet 369 OPTIONAL, 370 signPolExtensions [5] SignPolExtensions 371 OPTIONAL 372 } 374 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 375 empty NULL, 376 recognizedCommitmentType CommitmentType } 378 If the SelectedCommitmentTypes indicates "empty" then this rule applied 379 when a commitment type is not present (i.e. the type of commitment is 380 indicated in the semantics of the message). Otherwise, the electronic 381 signature must contain a commitment type indication that must fit one 382 of the commitments types that are mentioned in CommitmentType. 384 A specific commitment type identifier must not appear in more than one 385 commitment rule. 387 CommitmentType ::= SEQUENCE { 388 identifier CommitmentTypeIdentifier, 389 fieldOfApplication [0] FieldOfApplication OPTIONAL, 390 semantics [1] DirectoryString OPTIONAL } 392 The fieldOfApplication and semantics fields define the specific use and 393 meaning of the commitment within the overall field of application 394 defined for the policy. 396 Internet Draft Electronic Signature Policies 398 3.5 Signer and Verifier Rules 400 The following rules apply to the format of electronic signatures defined using 401 [ES-FORMATS]. 403 The SignerAndVerifierRules consists of signer rule and verification 404 rules as defined below: 405 SignerAndVerifierRules ::= SEQUENCE { 406 signerRules SignerRules, 407 verifierRules VerifierRules } 409 3.5.1 Signer Rules 411 The signer rules identify: 413 * if the eContent is empty and the signature is calculated using 414 a hash of signed data external to CMS structure. 416 * the CMS signed attributes that must be provided by the signer 417 under this policy; 419 * the CMS unsigned attribute that must be provided by the signer 420 under this policy; 422 * whether the certificate identifiers from the full certification 423 path up to the trust point must be provided by the signer in 424 the SigningCertificate attribute; 426 * whether a signer's certificate, or all certificates in the 427 certification path to the trust point must be provided by the 428 signer in the certificates field of SignedData. 430 SignerRules ::= SEQUENCE { 431 externalSignedData BOOLEAN OPTIONAL, 432 -- True if signed data is external to CMS structure 433 -- False if signed data part of CMS structure 434 -- not present if either allowed 435 mandatedSignedAttr CMSAttrs, 436 -- Mandated CMS signed attributes 437 mandatedUnsignedAttr CMSAttrs, 438 -- Mandated CMS unsigned attributed 439 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 440 -- Mandated Certificate Reference 441 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 442 -- Mandated Certificate Info 443 signPolExtensions [2] SignPolExtensions OPTIONAL 444 } 446 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 448 The mandatedSignedAttr field must include the object identifier for 449 all those signed attributes required by this document as well as 450 additional attributes required by this policy. 452 Internet Draft Electronic Signature Policies 454 The mandatedUnsignedAttr field must include the object identifier for 455 all those unsigned attributes required by this document as well as 456 additional attributes required this policy. For example, if a signature 457 timestamp (see clause 1.1) is required by the signer the object 458 identifier for this attribute must be included. 460 The mandatedCertificateRef identifies whether just the signer's 461 certificate, or all the full certificate path must be provided by the 462 signer. 464 CertRefReq ::= ENUMERATED { 465 signerOnly (1), 466 -- Only reference to signer cert mandated 467 fullPath (2) 469 -- References for full cert path up to a trust point required 470 } 472 The mandatedCertificateInfo field identifies whether a signer's 473 certificate, or all certificates in the certification path to the trust 474 point must be provided by the signer in the certificates field of 475 SignedData. 477 CertInfoReq ::= ENUMERATED { 478 none (0) , 479 -- No mandatory requirements 480 signerOnly (1) , 481 -- Only reference to signer cert mandated 482 fullPath (2) 483 -- References for full cert path up to a 484 -- trust point mandated 485 } 487 3.5.2 Verifier Rules 489 The verifier rules identify: 490 * The CMS unsigned attributes that must be present under this policy 491 and must be added by the verifier if not added by the signer. 493 VerifierRules ::= SEQUENCE { 494 mandatedUnsignedAttr MandatedUnsignedAttr, 495 signPolExtensions SignPolExtensions OPTIONAL 496 } 498 MandatedUnsignedAttr ::= CMSAttrs 499 -- Mandated CMS unsigned attributed 501 Internet Draft Electronic Signature Policies 503 3.6 Certificate and Revocation Requirement 505 The SigningCertTrustCondition, TimestampTrustCondition and 506 AttributeTrustCondition (defined in subsequent sub-clauses) make use of 507 two ASN1 structures which are defined below: CertificateTrustTrees and 508 CertRevReq. 510 3.6.1 Certificate Requirements 512 The certificateTrustTrees identifies a set of self signed certificates 513 for the trust points used to start (or end) certificate path processing 514 and the initial conditions for certificate path validation as defined 515 RFC 2459 [7] section 4. This ASN1 structure is used to define policy 516 for validating the signing certificate, the TSA's certificate and 517 attribute certificates. 519 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 521 CertificateTrustPoint ::= SEQUENCE { 522 trustpoint Certificate, 523 -- self-signed certificate 524 pathLenConstraint [0] PathLenConstraint OPTIONAL, 525 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 526 -- If not present "any policy" 527 nameConstraints [2] NameConstraints OPTIONAL, 528 policyConstraints [3] PolicyConstraints OPTIONAL } 530 The trustPoint field gives the self signed certificate for the CA that 531 is used as the trust point for the start of certificate path 532 processing. 534 The pathLenConstraint field gives the maximum number of CA certificates 535 that may be in a certification path following the trustpoint. A value 536 of zero indicates that only the given trustpoint certificate and an 537 end-entity certificate may be used. If present, the pathLenConstraint 538 field must be greater than or equal to zero. Where pathLenConstraint 539 is not present, there is no limit to the allowed length of the 540 certification path. 542 PathLenConstraint ::= INTEGER (0..MAX) 544 The acceptablePolicySet field identifies the initial set of certificate 545 policies, any of which are acceptable under the signature policy. 546 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 548 CertPolicyId ::= OBJECT IDENTIFIER 550 Internet Draft Electronic Signature Policies 552 The nameConstraints field indicates a name space within which all 553 subject names in subsequent certificates in a certification path must 554 be located. Restrictions may apply to the subject distinguished name or 555 subject alternative names. Restrictions apply only when the specified 556 name form is present. If no name of the type is in the certificate, the 557 certificate is acceptable. 559 Restrictions are defined in terms of permitted or excluded name 560 subtrees. Any name matching a restriction in the excludedSubtrees field 561 is invalid regardless of information appearing in the ermittedSubtrees. 563 NameConstraints ::= SEQUENCE { 564 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 565 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 567 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 569 GeneralSubtree ::= SEQUENCE { 570 base GeneralName, 571 minimum [0] BaseDistance DEFAULT 0, 572 maximum [1] BaseDistance OPTIONAL } 574 BaseDistance ::= INTEGER (0..MAX) 576 The policyConstraints extension constrains path processing in two ways. 577 It can be used to prohibit policy mapping or require that each 578 certificate in a path contain an acceptable policy identifier. 580 The policyConstraints field, if present specifies requirement for 581 explicit indication of the certificate policy and/or the constraints on 582 policy mapping. 584 PolicyConstraints ::= SEQUENCE { 585 requireExplicitPolicy [0] SkipCerts OPTIONAL, 586 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 588 SkipCerts ::= INTEGER (0..MAX) 590 If the inhibitPolicyMapping field is present, the value indicates the 591 number of additional certificates that may appear in the path 592 (including the trustpoint's self certificate) before policy mapping is 593 no longer permitted. For example, a value of one indicates that policy 594 mapping may be processed in certificates issued by the subject of this 595 certificate, but not in additional certificates in the path. 597 If the requireExplicitPolicy field is present, subsequent certificates 598 must include an acceptable policy identifier. The value of 599 requireExplicitPolicy indicates the number of additional certificates 600 that may appear in the path (including the trustpoint's self 601 certificate) before an explicit policy is required. An acceptable 602 policy identifier is the identifier of a policy required by the user of 603 the certification path or the identifier of a policy which has been 604 declared equivalent through policy mapping. 606 Internet Draft Electronic Signature Policies 608 3.6.2 Revocation Requirements 610 The RevocRequirements field specifies minimum requirements for 611 revocation information, obtained through CRLs and/or OCSP responses, to 612 be used in checking the revocation status of certificates. This ASN1 613 structure is used to define policy for validating the signing 614 certificate, the TSA's certificate and attribute certificates. 616 CertRevReq ::= SEQUENCE { 617 endCertRevReq RevReq, 618 caCerts [0] RevReq 619 } 621 Certificate revocation requirements are specified in terms of checks 622 required on: 623 * endCertRevReq: end certificates (i.e. the signers certificate, 624 the attribute certificate or the timestamping authority 625 certificate). 627 * caCerts: CA certificates. 629 RevReq ::= SEQUENCE { 630 enuRevReq EnuRevReq, 631 exRevReq SignPolExtensions OPTIONAL} 633 An authority certificate is certificate issued to an authority (e.g. 634 either to a certification authority or to an attribute authority (AA)). 636 A TimeStamping Authority (TSA) is a trusted third party that creates 637 time stamp tokens in order to indicate that a datum existed at a 638 particular point in time. See [TSP] 640 EnuRevReq ::= ENUMERATED { 641 clrCheck (0), 642 --Checks must be made against current CRLs 643 -- (or authority revocation lists (ARL)) 644 ocspCheck (1), -- The revocation status must be checked 645 -- using the Online Certificate Status Protocol 646 -- (OCSP),RFC 2450. 647 bothCheck (2), 648 -- Both CRL and OCSP checks must be carried out 649 eitherCheck (3), 650 -- At least one of CRL or OCSP checks must be 651 -- carried out 652 noCheck (4), 653 -- no check is mandated 654 other (5) 655 -- Other mechanism as defined by signature policy 656 -- extension 657 } 659 Internet Draft Electronic Signature Policies 661 Revocation requirements are specified in terms of: 662 * clrCheck: Checks must be made against current CRLs (or 663 authority revocation lists); 664 * ocspCheck: The revocation status must be checked using the 665 Online Certificate Status Protocol (RFC 2450); 666 * bothCheck: Both OCSP and CRL checks must be carried out; 667 * eitherCheck: Either OCSP or CRL checks must be carried out; 668 * noCheck: No check is mandated. 670 3.7 Signing Certificate Trust Conditions 672 The SigningCertTrustCondition field identifies trust conditions for 673 certificate path processing used to validate the signing certificate. 675 SigningCertTrustCondition ::= SEQUENCE { 676 signerTrustTrees CertificateTrustTrees, 677 signerRevReq CertRevReq 678 } 680 3.8 TimeStamp Trust Conditions 682 The TimeStampTrustCondition field identifies trust conditions for 683 certificate path processing used to authenticate the timstamping 684 authority and constraints on the name of the timestamping authority. 685 This applies to the timestamp that must be present in every ES-T. 687 TimestampTrustCondition ::= SEQUENCE { 688 ttsCertificateTrustTrees [0] CertificateTrustTrees 689 OPTIONAL, 690 ttsRevReq [1] CertRevReq 691 OPTIONAL, 692 ttsNameConstraints [2] NameConstraints 693 OPTIONAL, 694 cautionPeriod [3] DeltaTime 695 OPTIONAL, 696 signatureTimestampDelay [4] DeltaTime 697 OPTIONAL } 699 DeltaTime ::= SEQUENCE { 700 deltaSeconds INTEGER, 701 deltaMinutes INTEGER, 702 deltaHours INTEGER, 703 deltaDays INTEGER } 705 If ttsCertificateTrustTrees is not present then the same rule as 706 defined in certificateTrustCondition applies to certification of the 707 timestamping authorities public key. 709 Internet Draft Electronic Signature Policies 711 The tstrRevReq specifies minimum requirements for revocation 712 information, obtained through CRLs and/or OCSP responses, to be used in 713 checking the revocation status of the time stamp that must be present 714 in the ES-T. 716 If ttsNameConstraints is not present then there are no additional 717 naming constraints on the trusted timestamping authority other than 718 those implied by the ttsCertificateTrustTrees. 720 The cautionPeriod field specifies a caution period after the signing 721 time that it is mandated the verifier must wait to get high assurance 722 of the validity of the signer's key and that any relevant revocation 723 has been notified. The revocation status information forming the ES 724 with Complete validation data must not be collected and used to 725 validate the electronic signature until after this caution period. 727 The signatureTimestampDelay field specifies a maximum acceptable time 728 between the signing time and the time at which the signature timestamp, 729 as used to form the ES Timestamped, is created for the verifier. If the 730 signature timestamp is later that the time in the signing-time 731 attribute by more than the value given in signatureTimestampDelay, the 732 signature must be considered invalid. 734 3.9 Attribute Trust Conditions 736 If the attributeTrustCondition field is not present then any certified 737 attributes may not considered to be valid under this validation policy. 738 The AttributeTrustCondition field is defined as follows: 740 AttributeTrustCondition ::= SEQUENCE { 741 attributeMandated BOOLEAN, 742 -- Attribute must be present 743 howCertAttribute HowCertAttribute, 744 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 745 attrRevReq [1] CertRevReq OPTIONAL, 746 attributeConstraints [2] AttributeConstraints OPTIONAL } 748 If attributeMandated is true then an attribute, certified within the 749 following constraints, must be present. If false, then the signature 750 is still valid if no attribute is specified. 752 The howCertAttribute field specifies whether attributes uncertified 753 attributes "claimed" by the signer, or certified attributes 754 (i.e. Attribute Certificates) or either using the signer 755 attributes attribute defined in [ES-FORMATS] section 3.12.3. 757 HowCertAttribute ::= ENUMERATED { 758 claimedAttribute (0), 759 certifiedAttribtes (1), 760 either (2) } 762 Internet Draft Electronic Signature Policies 764 The attrCertificateTrustTrees specifies certificate path conditions for 765 any attribute certificate. If not present the same rules apply as in 766 certificateTrustCondition. 768 The attrRevReq specifies minimum requirements for revocation 769 information, obtained through CRLs and/or OCSP responses, to be used in 770 checking the revocation status of Attribute Certificates, if any are 771 present. 773 If the attributeConstraints field is not present then there are no 774 constraints on the attributes that may be validated under this policy. 775 The attributeConstraints field is defined as follows: 777 AttributeConstraints ::= SEQUENCE { 778 attributeTypeConstarints [0] AttributeTypeConstraints 779 OPTIONAL, 780 attributeValueConstarints [1] AttributeValueConstraints 781 OPTIONAL } 783 If present, the attributeTypeConstarints field specifies the attribute 784 types which are considered valid under the signature policy. Any value 785 for that attribute is considered valid. 787 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 789 If present, the attributeTypeConstraints field specifies the specific 790 attribute values which are considered valid under the signature policy. 792 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 794 3.10 Algorithm Constraints 796 The algorithmConstrains fields, if present, identifies the signing 797 algorithms (hash, public key cryptography, combined hash and public key 798 cryptography) that may be used for specific purposes and any minimum 799 length. If this field is not present then the policy applies no 800 constraints. 802 AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on: 803 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 804 -- signer 805 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 806 -- issuer of end entity certs. 807 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 808 -- issuer of CA certificates 809 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 810 -- Attribute Authority 811 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 812 -- TimeStamping Authority 813 } 815 Internet Draft Electronic Signature Policies 817 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 819 AlgAndLength ::= SEQUENCE { 820 algID OBJECT IDENTIFIER, 821 minKeyLength INTEGER OPTIONAL, 822 -- Minimum key length in bits 823 other SignPolExtensions OPTIONAL 824 } 826 An Attribute Authority (AA)is authority which assigns privileges by 827 issuing attribute certificates 829 3.11 Signature Policy Extensions 831 Additional signature policy rules may be added to: 833 * the overall signature policy structure, as defined in 834 clause 3.1; 835 * the signature validation policy structure, as defined in 836 clause 3.2; 837 * the common rules, as defined in clause 3.3; 838 * the commitment rules, as defined in clause 3.4; 839 * the signer rules, as defined in clause 3.5.1; 840 * the verifier rules, as defined in clause 3.5.2; 841 * the revocation requirements in clause 3.6.2; 842 * the algorithm constraints in clause 3.10. 844 These extensions to the signature policy rules must be defined using 845 an ASN.1 syntax with an associated object identifier carried in the 846 SignPolExtn as defined below: 848 SignPolExtensions ::= SEQUENCE OF SignPolExtn 850 SignPolExtn ::= SEQUENCE { 851 extnID OBJECT IDENTIFIER, 852 extnValue OCTET STRING } 854 The extnID field must contain the object identifier for the extension. 855 The extnValue field must contain the DER (see ITU-T Recommendation 856 X.690 [4]) encoded value of the extension. The definition of an 857 extension, as identified by extnID must include a definition of the 858 syntax and semantics of the extension. 860 Internet Draft Electronic Signature Policies 862 4. Security considerations 863 To be defined 865 5. Conformance Requirements 867 To be defined 869 6. References 871 [ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic 872 Signature Formats. Note: copies of ETSI ES 201 733 can be freely download 873 from the ETSI web site www.etsi.org. 875 [ES-FORMATS] ETSI TC-SEC, D.Pinkas, J.Ross, N.Pope. Electronic Signature 876 formats for long term electronic signatures 877 To be published as an INFORMATIONAL RFC. 879 [TSP] C. Adams, D. Pinkas, R. Zuccherato, P. Cain. Time Stamp Protocol . 882 [OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. 883 On-line Status Certificate Protocol, RFC 2560. 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, March 1997. 888 [ESS] P. Hoffman, "Enhanced Security Services for S/MIME", RFC 2634 889 June 1999 891 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, RFC 2630, 892 June 1999. 894 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 895 Key Infrastructure, Certificate and CRL Profile," RFC 2459, January 896 1999. 898 [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards 899 (PKCS)", RSA Data Security Inc., Redwood City, California, November 900 1993 Release. 902 [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. 903 Non-Repudiation Framework. April 1997. 905 Internet Draft Electronic Signature Policies 907 7. Authors' Addresses 909 This Experimental RFC has been produced in ETSI TC-SEC. 911 ETSI 912 F-06921 Sophia Antipolis, Cedex - FRANCE 913 650 Route des Lucioles - Sophia Antipolis 914 Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 915 secretariat@etsi.fr 916 http://www.etsi.org 918 Contact Point 920 Harri Rasilainen 921 ETSI 922 650 Route des Lucioles 923 F-06921 Sophia Antipolis Cedex 924 FRANCE 925 harri.rasilainen@etsi.fr 927 John Ross 928 Security & Standards 929 192 Moulsham Street 930 Chelmsford, Essex 931 CM2 0LG 932 United Kingdom 933 ross@secstan.com 935 Denis Pinkas Nick Pope 936 Bull S.A. Security & Standards 937 12, rue de Paris 192 Moulsham Street 938 B.P. 59 Chelmsford, Essex 939 78231 Le Pecq CM2 0LG 940 FRANCE United Kingdom 941 pinkas.denis@bull.net pope@secstan.com 943 Internet Draft Electronic Signature Policies 945 8. Full Copyright Statement 947 Copyright (C) The Internet Society (2000). All Rights Reserved. 948 This document and translations of it may be copied and furnished to 949 others,and derivative works that comment on or otherwise explain it or 950 assist in its implementation may be prepared, copied, published and 951 distributed, in whole or in part, without restriction of any kind, 952 provided that the above copyright notice and this paragraph are included 953 on all such copies and derivative works. However, this document itself may 954 not be modified in any way, such as by removing the copyright notice or 955 references to the Internet Society or other Internet organizations, except 956 as needed for the purpose ofdeveloping Internet standards in which case 957 the procedures for copyrights defined in the Internet Standards process 958 must be followed, or as required to translate it into languages other than 959 English. 961 The limited permissions granted above are perpetual and will not be revoked 962 by the Internet Society or its successors or assigns. 964 This document and the information contained herein is provided on an 965 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 966 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 967 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 968 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 969 FITNESS FOR A PARTICULAR PURPOSE. 971 Internet Draft Electronic Signature Policies 973 Annex A (normative): 974 ASN.1 Definitions 975 This annex provides the reference definition of the ASN.1 syntax 976 signature policies definitions for new syntax defined in this document. 978 A.1 Definitions Using X.208 (1988) ASN.1 Syntax 979 NOTE: The ASN.1 Module defined in clause A.1 has precedence over that defined in 980 Annex A-2 in the case of any conflict. 982 ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2) 983 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 7} 985 DEFINITIONS EXPLICIT TAGS ::= 986 BEGIN 987 -- EXPORTS All 989 IMPORTS 991 -- Internet X.509 Public Key Infrastructure 992 - Certificate and CRL Profile: RFC 2459 993 Certificate, AlgorithmIdentifier, CertificateList, Name, 994 GeneralNames, GeneralName, DirectoryString,Attribute, 995 AttributeTypeAndValue, AttributeType, AttributeValue, 996 PolicyInformation, BMPString, UTF8String 998 FROM PKIX1Explicit88 999 {iso(1) identified-organization(3) dod(6) internet(1) 1000 security(5) mechanisms(5) pkix(7) id-mod(0) 1001 id-pkix1-explicit-88(1)} 1002 ; 1004 -- Signature Policy Specification 1005 -- ============================== 1007 SignaturePolicy ::= SEQUENCE { 1008 signPolicyHashAlg AlgorithmIdentifier, 1009 signPolicyInfo SignPolicyInfo, 1010 signPolicyHash SignPolicyHash OPTIONAL } 1012 SignPolicyHash ::= OCTET STRING 1014 SignPolicyInfo ::= SEQUENCE { 1015 signPolicyIdentifier SignPolicyId, 1016 dateOfIssue GeneralizedTime, 1017 policyIssuerName PolicyIssuerName, 1018 fieldOfApplication FieldOfApplication, 1019 signatureValidationPolicy SignatureValidationPolicy, 1020 signPolExtensions SignPolExtensions 1021 OPTIONAL 1022 } 1024 SignPolicyId ::= OBJECT IDENTIFIER 1026 Internet Draft Electronic Signature Policies 1028 PolicyIssuerName ::= GeneralNames 1030 FieldOfApplication ::= DirectoryString 1032 SignatureValidationPolicy ::= SEQUENCE { 1033 signingPeriod SigningPeriod, 1034 commonRules CommonRules, 1035 commitmentRules CommitmentRules, 1036 signPolExtensions SignPolExtensions 1037 OPTIONAL 1038 } 1040 SigningPeriod ::= SEQUENCE { 1041 notBefore GeneralizedTime, 1042 notAfter GeneralizedTime OPTIONAL } 1044 CommonRules ::= SEQUENCE { 1045 signerAndVeriferRules [0] SignerAndVerifierRules 1046 OPTIONAL, 1047 signingCertTrustCondition [1] SigningCertTrustCondition 1048 OPTIONAL, 1049 timeStampTrustCondition [2] TimestampTrustCondition 1050 OPTIONAL, 1051 attributeTrustCondition [3] AttributeTrustCondition 1052 OPTIONAL, 1053 algorithmConstraintSet [4] AlgorithmConstraintSet 1054 OPTIONAL, 1055 signPolExtensions [5] SignPolExtensions 1056 OPTIONAL 1057 } 1059 CommitmentRules ::= SEQUENCE OF CommitmentRule 1061 CommitmentRule ::= SEQUENCE { 1062 selCommitmentTypes SelectedCommitmentTypes, 1063 signerAndVeriferRules [0] SignerAndVerifierRules 1064 OPTIONAL, 1065 signingCertTrustCondition [1] SigningCertTrustCondition 1066 OPTIONAL, 1067 timeStampTrustCondition [2] TimestampTrustCondition 1068 OPTIONAL, 1069 attributeTrustCondition [3] AttributeTrustCondition 1070 OPTIONAL, 1071 algorithmConstraintSet [4] AlgorithmConstraintSet 1072 OPTIONAL, 1073 signPolExtensions [5] SignPolExtensions 1074 OPTIONAL 1075 } 1077 Internet Draft Electronic Signature Policies 1079 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 1080 empty NULL, 1081 recognizedCommitmentType CommitmentType } 1083 CommitmentType ::= SEQUENCE { 1084 identifier CommitmentTypeIdentifier, 1085 fieldOfApplication [0] FieldOfApplication OPTIONAL, 1086 semantics [1] DirectoryString OPTIONAL } 1088 SignerAndVerifierRules ::= SEQUENCE { 1089 signerRules SignerRules, 1090 verifierRules VerifierRules } 1092 SignerRules ::= SEQUENCE { 1093 externalSignedData BOOLEAN OPTIONAL, 1094 -- True if signed data is external to CMS structure 1095 -- False if signed data part of CMS structure 1096 -- not present if either allowed 1097 mandatedSignedAttr CMSAttrs, 1098 -- Mandated CMS signed attributes 1099 mandatedUnsignedAttr CMSAttrs, 1100 -- Mandated CMS unsigned attributed 1101 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 1102 -- Mandated Certificate Reference 1103 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 1104 -- Mandated Certificate Info 1105 signPolExtensions [2] SignPolExtensions 1106 OPTIONAL} 1108 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 1110 CertRefReq ::= ENUMERATED { 1111 signerOnly (1), 1112 -- Only reference to signer cert mandated 1113 fullPath (2) 1114 -- References for full cert path up to a trust point required 1116 } 1118 CertInfoReq ::= ENUMERATED { 1119 none (0), 1120 -- No mandatory requirements 1121 signerOnly (1), 1122 -- Only reference to signer cert mandated 1123 fullPath (2) 1124 -- References for full cert path up to a trust point mandated 1125 } 1127 Internet Draft Electronic Signature Policies 1129 VerifierRules ::= SEQUENCE { 1130 mandatedUnsignedAttr MandatedUnsignedAttr, 1131 signPolExtensions SignPolExtensions OPTIONAL 1132 } 1134 MandatedUnsignedAttr ::= CMSAttrs 1135 -- Mandated CMS unsigned attributed 1137 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 1139 CertificateTrustPoint ::= SEQUENCE { 1140 trustpoint Certificate, 1141 -- self-signed certificate 1142 pathLenConstraint [0] PathLenConstraint OPTIONAL, 1143 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 1144 -- If not present "any policy" 1145 nameConstraints [2] NameConstraints OPTIONAL, 1146 policyConstraints [3] PolicyConstraints OPTIONAL } 1148 PathLenConstraint ::= INTEGER (0..MAX) 1150 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 1152 CertPolicyId ::= OBJECT IDENTIFIER 1154 NameConstraints ::= SEQUENCE { 1155 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1156 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1158 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1160 GeneralSubtree ::= SEQUENCE { 1161 base GeneralName, 1162 minimum [0] BaseDistance DEFAULT 0, 1163 maximum [1] BaseDistance OPTIONAL } 1165 BaseDistance ::= INTEGER (0..MAX) 1167 PolicyConstraints ::= SEQUENCE { 1168 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1169 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1171 SkipCerts ::= INTEGER (0..MAX) 1173 CertRevReq ::= SEQUENCE { 1174 endCertRevReq RevReq, 1175 caCerts [0] RevReq 1176 } 1178 RevReq ::= SEQUENCE { 1179 enuRevReq EnuRevReq, 1180 exRevReq SignPolExtensions OPTIONAL} 1182 Internet Draft Electronic Signature Policies 1184 EnuRevReq ::= ENUMERATED { 1185 clrCheck (0), --Checks must be made against current CRLs 1186 -- (or authority revocation lists) 1187 ocspCheck (1), -- The revocation status must be checked 1188 -- using the Online Certificate Status Protocol (RFC 2450) 1189 bothCheck (2), 1190 -- Both CRL and OCSP checks must be carried out 1191 eitherCheck (3), 1192 -- At least one of CRL or OCSP checks must be carried out 1193 noCheck (4), 1194 -- no check is mandated 1195 other (5) 1196 -- Other mechanism as defined by signature policy extension 1197 } 1199 SigningCertTrustCondition ::= SEQUENCE { 1200 signerTrustTrees CertificateTrustTrees, 1201 signerRevReq CertRevReq 1202 } 1204 TimestampTrustCondition ::= SEQUENCE { 1205 ttsCertificateTrustTrees [0] CertificateTrustTrees 1206 OPTIONAL, 1207 ttsRevReq [1] CertRevReq 1208 OPTIONAL, 1209 ttsNameConstraints [2] NameConstraints 1210 OPTIONAL, 1211 cautionPeriod [3] DeltaTime 1212 OPTIONAL, 1213 signatureTimestampDelay [4] DeltaTime 1214 OPTIONAL } 1216 DeltaTime ::= SEQUENCE { 1217 deltaSeconds INTEGER, 1218 deltaMinutes INTEGER, 1219 deltaHours INTEGER, 1220 deltaDays INTEGER } 1222 AttributeTrustCondition ::= SEQUENCE { 1223 attributeMandated BOOLEAN, 1224 -- Attribute must be present 1225 howCertAttribute HowCertAttribute, 1226 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 1227 attrRevReq [1] CertRevReq OPTIONAL, 1228 attributeConstraints [2] AttributeConstraints OPTIONAL } 1230 HowCertAttribute ::= ENUMERATED { 1231 claimedAttribute (0), 1232 certifiedAttribtes (1), 1233 either (2) } 1235 Internet Draft Electronic Signature Policies 1237 AttributeConstraints ::= SEQUENCE { 1238 attributeTypeConstarints [0] AttributeTypeConstraints 1239 OPTIONAL, 1240 attributeValueConstarints [1] AttributeValueConstraints 1241 OPTIONAL } 1243 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 1245 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 1247 AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on: 1248 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 1249 -- signer 1250 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 1251 -- issuer of end entity certs. 1252 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 1253 -- issuer of CA certificates 1254 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 1255 -- Attribute Authority 1256 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 1257 -- TimeStamping Authority 1258 } 1260 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 1262 AlgAndLength ::= SEQUENCE { 1263 algID OBJECT IDENTIFIER, 1264 minKeyLength INTEGER OPTIONAL, 1265 -- Minimum key length in bits other 1266 SignPolExtensions OPTIONAL 1267 } 1269 SignPolExtensions ::= SEQUENCE OF SignPolExtn 1271 SignPolExtn ::= SEQUENCE { 1272 extnID OBJECT IDENTIFIER, 1273 extnValue OCTET STRING } 1275 END -- ETS-ElectronicSignaturePolicies-88syntax -- 1277 Internet Draft Electronic Signature Policies 1279 A.2 Definitions Using X.680 1997 ASN.1 Syntax 1281 NOTE: The ASN.1 module defined in clause A.1 has precedence over that 1282 defined in clause A.2 in the case of any conflict. 1284 ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2) 1285 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8} 1287 DEFINITIONS EXPLICIT TAGS ::= 1288 BEGIN 1289 -- EXPORTS All - 1291 IMPORTS 1293 -- Internet X.509 Public Key Infrastructure 1294 -- Certificate and CRL Profile: RFC 2459 1295 Certificate, AlgorithmIdentifier, CertificateList, Name, 1296 GeneralNames, GeneralName, DirectoryString, Attribute, 1297 AttributeTypeAndValue, AttributeType, AttributeValue, 1298 PolicyInformation 1300 FROM PKIX1Explicit93 1301 {iso(1) identified-organization(3) dod(6) internet(1) 1302 security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1303 ; 1305 -- S/MIME Object Identifier arcs used in the present document 1306 -- ================================================================== 1308 -- S/MIME OID arc used in the present document 1309 -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1310 -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 1312 -- S/MIME Arcs 1313 -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } 1314 -- modules 1315 -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } 1316 -- content types 1317 -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } 1318 -- attributes 1319 -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } 1320 -- signature policy qualifier 1321 -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } 1322 -- commitment type identifier 1324 Internet Draft Electronic Signature Policies 1326 -- Signature Policy Specification 1327 -- ============================== 1329 SignaturePolicy ::= SEQUENCE { 1330 signPolicyHashAlg AlgorithmIdentifier, 1331 signPolicyInfo SignPolicyInfo, 1332 signPolicyHash SignPolicyHash OPTIONAL } 1334 SignPolicyHash ::= OCTET STRING 1336 SignPolicyInfo ::= SEQUENCE { 1337 signPolicyIdentifier SignPolicyId, 1338 dateOfIssue GeneralizedTime, 1339 policyIssuerName PolicyIssuerName, 1340 fieldOfApplication FieldOfApplication, 1341 signatureValidationPolicy SignatureValidationPolicy, 1342 signPolExtensions SignPolExtensions 1343 OPTIONAL 1344 } 1346 SignPolicyId ::= OBJECT IDENTIFIER 1348 PolicyIssuerName ::= GeneralNames 1350 FieldOfApplication ::= DirectoryString 1352 SignatureValidationPolicy ::= SEQUENCE { 1353 signingPeriod SigningPeriod, 1354 commonRules CommonRules, 1355 commitmentRules CommitmentRules, 1356 signPolExtensions SignPolExtensions OPTIONAL 1357 } 1359 SigningPeriod ::= SEQUENCE { 1360 notBefore GeneralizedTime, 1361 notAfter GeneralizedTime OPTIONAL } 1363 Internet Draft Electronic Signature Policies 1365 CommonRules ::= SEQUENCE { 1366 signerAndVeriferRules [0] SignerAndVerifierRules 1367 OPTIONAL, 1368 signingCertTrustCondition [1] SigningCertTrustCondition 1369 OPTIONAL, 1370 timeStampTrustCondition [2] TimestampTrustCondition 1371 OPTIONAL, 1372 attributeTrustCondition [3] AttributeTrustCondition 1373 OPTIONAL, 1374 algorithmConstraintSet [4] AlgorithmConstraintSet 1375 OPTIONAL, 1376 signPolExtensions [5] SignPolExtensions 1377 OPTIONAL 1378 } 1380 CommitmentRules ::= SEQUENCE OF CommitmentRule 1382 CommitmentRule ::= SEQUENCE { 1383 selCommitmentTypes SelectedCommitmentTypes, 1384 signerAndVeriferRules [0] SignerAndVerifierRules 1385 OPTIONAL, 1386 signingCertTrustCondition [1] SigningCertTrustCondition 1387 OPTIONAL, 1388 timeStampTrustCondition [2] TimestampTrustCondition 1389 OPTIONAL, 1390 attributeTrustCondition [3] AttributeTrustCondition 1391 OPTIONAL, 1392 algorithmConstraintSet [4] AlgorithmConstraintSet 1393 OPTIONAL, 1394 signPolExtensions [5] SignPolExtensions 1395 OPTIONAL 1396 } 1398 SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { 1399 empty NULL, 1400 recognizedCommitmentType CommitmentType } 1402 CommitmentType ::= SEQUENCE { 1403 identifier CommitmentTypeIdentifier, 1404 fieldOfApplication [0] FieldOfApplication OPTIONAL, 1405 semantics [1] DirectoryString OPTIONAL } 1407 SignerAndVerifierRules ::= SEQUENCE { 1408 signerRules SignerRules, 1409 verifierRules VerifierRules } 1411 Internet Draft Electronic Signature Policies 1413 SignerRules ::= SEQUENCE { 1414 externalSignedData BOOLEAN OPTIONAL, 1415 -- True if signed data is external to CMS structure 1416 -- False if signed data part of CMS structure 1417 -- not present if either allowed 1418 mandatedSignedAttr CMSAttrs, 1419 -- Mandated CMS signed attributes 1420 mandatedUnsignedAttr CMSAttrs, 1421 -- Mandated CMS unsigned attributed 1422 mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, 1423 -- Mandated Certificate Reference 1424 mandatedCertificateInfo [1] CertInfoReq DEFAULT none, 1425 -- Mandated Certificate Info 1426 signPolExtensions [2] SignPolExtensions OPTIONAL 1427 } 1429 CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER 1431 CertRefReq ::= ENUMERATED { 1432 signerOnly (1), 1433 -- Only reference to signer cert mandated 1434 fullPath (2) 1435 -- References for full cert path up to a trust 1436 -- point required 1437 } 1439 CertInfoReq ::= ENUMERATED { 1440 none (0) , 1441 -- No mandatory requirements 1442 signerOnly (1) , 1443 -- Only reference to signer cert mandated 1444 fullPath (2) 1445 -- References for full cert path up to a 1446 -- trust point mandated 1447 } 1449 VerifierRules ::= SEQUENCE { 1450 mandatedUnsignedAttr MandatedUnsignedAttr, 1451 signPolExtensions SignPolExtensions OPTIONAL 1452 } 1454 MandatedUnsignedAttr ::= CMSAttrs 1455 -- Mandated CMS unsigned attributed 1457 Internet Draft Electronic Signature Policies 1459 CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint 1461 CertificateTrustPoint ::= SEQUENCE { 1462 trustpoint Certificate, 1463 -- self-signed certificate 1464 pathLenConstraint [0] PathLenConstraint OPTIONAL, 1465 acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, 1466 -- If not present "any policy" 1467 nameConstraints [2] NameConstraints OPTIONAL, 1468 policyConstraints [3] PolicyConstraints OPTIONAL } 1470 PathLenConstraint ::= INTEGER (0..MAX) 1472 AcceptablePolicySet ::= SEQUENCE OF CertPolicyId 1474 CertPolicyId ::= OBJECT IDENTIFIER 1476 NameConstraints ::= SEQUENCE { 1477 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 1478 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 1480 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 1482 GeneralSubtree ::= SEQUENCE { 1483 base GeneralName, 1484 minimum [0] BaseDistance DEFAULT 0, 1485 maximum [1] BaseDistance OPTIONAL } 1487 BaseDistance ::= INTEGER (0..MAX) 1489 PolicyConstraints ::= SEQUENCE { 1490 requireExplicitPolicy [0] SkipCerts OPTIONAL, 1491 inhibitPolicyMapping [1] SkipCerts OPTIONAL } 1493 SkipCerts ::= INTEGER (0..MAX) 1495 CertRevReq ::= SEQUENCE { 1496 endCertRevReq RevReq, 1497 caCerts [0] RevReq 1498 } 1500 RevReq ::= SEQUENCE { 1501 enuRevReq EnuRevReq, 1502 exRevReq SignPolExtensions OPTIONAL} 1504 Internet Draft Electronic Signature Policies 1506 EnuRevReq ::= ENUMERATED { 1507 clrCheck (0), 1508 -- Checks must be made against current CRLs 1509 -- (or authority revocation lists) 1510 ocspCheck (1), 1511 -- The revocation status must be checked using 1512 -- the Online Certificate Status Protocol (RFC 2450) 1513 bothCheck (2), 1514 -- Both CRL and OCSP checks must be carried out 1515 eitherCheck (3), 1516 -- At least one of CRL or OCSP checks must be carried out 1517 noCheck (4), 1518 -- no check is mandated 1519 other (5) 1520 -- Other mechanism as defined by signature policy 1521 -- extension 1522 } 1524 SigningCertTrustCondition ::= SEQUENCE { 1525 signerTrustTrees CertificateTrustTrees, 1526 signerRevReq CertRevReq 1527 } 1529 TimestampTrustCondition ::= SEQUENCE { 1530 ttsCertificateTrustTrees [0] CertificateTrustTrees 1531 OPTIONAL, 1532 ttsRevReq [1] CertRevReq 1533 OPTIONAL, 1534 ttsNameConstraints [2] NameConstraints 1535 OPTIONAL, 1536 cautionPeriod [3] DeltaTime 1537 OPTIONAL, 1538 signatureTimestampDelay [4] DeltaTime 1539 OPTIONAL } 1541 DeltaTime ::= SEQUENCE { 1542 deltaSeconds INTEGER, 1543 deltaMinutes INTEGER, 1544 deltaHours INTEGER, 1545 deltaDays INTEGER } 1547 AttributeTrustCondition ::= SEQUENCE { 1548 attributeMandated BOOLEAN, 1549 -- Attribute must be present 1550 howCertAttribute HowCertAttribute, 1551 attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, 1552 attrRevReq [1] CertRevReq OPTIONAL, 1553 attributeConstraints [2] AttributeConstraints OPTIONAL } 1555 Internet Draft Electronic Signature Policies 1557 HowCertAttribute ::= ENUMERATED { 1558 claimedAttribute (0), 1559 certifiedAttribtes (1), 1560 either (2) } 1562 AttributeConstraints ::= SEQUENCE { 1563 attributeTypeConstarints [0] AttributeTypeConstraints 1564 OPTIONAL, 1565 attributeValueConstarints [1] AttributeValueConstraints 1566 OPTIONAL } 1568 AttributeTypeConstraints ::= SEQUENCE OF AttributeType 1570 AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue 1572 AlgorithmConstraintSet ::= SEQUENCE { 1573 -- Algorithm constrains on: 1574 signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, 1575 -- signer 1576 eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, 1577 -- issuer of end entity certs. 1578 caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, 1579 -- issuer of CA certificates 1580 aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, 1581 -- Attribute Authority 1582 tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL 1583 -- TimeStamping Authority 1584 } 1586 AlgorithmConstraints ::= SEQUENCE OF AlgAndLength 1588 AlgAndLength ::= SEQUENCE { 1589 algID OBJECT IDENTIFIER, 1590 minKeyLength INTEGER OPTIONAL, 1591 -- Minimum key length in bits 1592 other SignPolExtensions OPTIONAL 1593 } 1595 SignPolExtensions ::= SEQUENCE OF SignPolExtn 1597 SignPolExtn ::= SEQUENCE { 1598 extnID OBJECT IDENTIFIER, 1599 extnValue OCTET STRING } 1601 END -- ETS-ElectronicPolicies-97Syntax 1603 Internet Draft Electronic Signature Policies 1605 Annex B (informative): 1607 B.1 Signature Policy and Signature Validation Policy 1609 The definition of electronic signature mentions: "a commitment has been 1610 explicitly endorsed under a "Signature Policy", at a given time, by a 1611 signer under an identifier, e.g. a name or a pseudonym, and optionally 1612 a role. " 1614 Electronic signatures are commonly applied within the context of a 1615 legal or contractual framework. This establishes the requirements on 1616 the electronic signatures and any special semantics (e.g. agreement, 1617 intent). These requirements may be defined in very general abstract 1618 terms or in terms of detailed rules. The specific semantics associated 1619 with an electronic signature implied by a legal or contractual 1620 framework are outside the scope of this document. 1622 If the signature policy is recognized, within the legal/contractual 1623 context, as providing commitment, then the signer explicitly agrees 1624 with terms and conditions which are implicitly or explicitly part of 1625 the signed data. 1627 When two independent parties want to evaluate an electronic signature, 1628 it is fundamental that they get the same result. It is therefore 1629 important that the conditions agreed by the signer at the time of 1630 signing are indicated to the verifier and any arbitrator. An aspect 1631 that enables this to be known by all parties is the signature policy. 1632 The technical implications of the signature policy on the electronic 1633 signature with all the validation data are called the "Signature 1634 Validation Policy". The signature validation policy specifies 1635 the rules used to validate the signature. 1637 This document does not mandate the form and encoding of the 1638 specification of the signature policy. However, for a given signature 1639 policy there must be one definitive form that has a unique binary 1640 encoded value. 1642 This document includes, as an option, a formal structure for signature 1643 validation policy based on the use of Abstract Syntax Notation 1 1644 (ASN.1). 1646 Given the specification of the signature policy and its hash value an 1647 implementation of a verification process must obey the rules defined 1648 in the specification. 1650 This document places no restriction on how it should be implemented. 1651 Provide the implementation conforms to the conformance requirements as 1652 define in clause 5 implementation options include: 1654 Internet Draft Electronic Signature Policies 1656 A validation process that supports a specific signature policy as 1657 identified by the signature policy OID. Such an implementation should 1658 conform to a human readable description provided all the processing 1659 rules of the signature policy are clearly defined. However, if 1660 additional policies need to be supported, then such an implementation 1661 would need to be customized for each additional policy. This type of 1662 implementation may be simpler to implement initially, but can be 1663 difficult to enhance to support numerous additional signature policies. 1665 A validation process that is dynamically programmable and able to adapt 1666 its validation rules in accordance with a description of the signature 1667 policy provided in a computer-processable language. This present 1668 document defines such a policy using an ASN.1 structure (see 6.1). This 1669 type of implementation could support multiple signature policies 1670 without being modified every time, provided all the validation rules 1671 specified as part of the signature policy are known by the 1672 implementation. (i.e. only requires modification if there are 1673 additional rules specified). 1675 The precise content of a signature policy is not mandated by the 1676 current document. However, a signature policy must be sufficiently 1677 definitive to avoid any ambiguity as to its implementation 1678 requirements. It must be absolutely clear under which conditions an 1679 electronic signature should be accepted. For this reason, it should 1680 contain the following information: 1682 * General information about the signature policy which includes: 1683 - a unique identifier of the policy; 1684 - the name of the issuer of the policy; 1685 - the date the policy was issued; 1686 - the field of application of the policy. 1688 * The signature verification policy which includes: 1689 - the signing period, 1690 - a list of recognized commitment types; 1691 - rules for Use of Certification Authorities; 1692 - rules for Use of Revocation Status Information; 1693 - rules for Use of Roles; 1694 - rules for use of Timestamping and Timing; 1695 - signature verification data to be provided by the 1696 signer/collected by verifier; 1697 - any constraints on signature algorithms and key lengths. 1698 * Other signature policy rules required to meet the objectives of 1699 the signature. 1701 Variations of the validation policy rules may apply to different 1702 commitment types. 1704 Internet Draft Electronic Signature Policies 1706 B.2 Identification of Signature Policy 1708 When data is signed the signer indicates the signature policy 1709 applicable to that electronic signature by including an object 1710 identifier for the signature policy with the signature. The signer and 1711 verifier must apply the rules specified by the identified policy. In 1712 addition to the identifier of the signature policy the signer must 1713 include the hash of the signature policy, so it can be verified that 1714 the policy selected by the signer is the identical to the one being 1715 used the verifier. 1717 A signature policy may be qualified by additional information. This can 1718 includes: 1720 * A URL where a copy of the Signature Policy may be obtained; 1721 * A user notice that should be displayed when the signature is 1722 verified; 1724 If no signature policy is identified then the signature may be assumed 1725 to have been generated/verified without any policy constraints, and 1726 hence may be given no specific legal or contractual significance 1727 through the context of a signature policy. 1729 A "Signature Policy" will be identifiable by an OID (Object Identifier) 1730 and verifiable using a hash of the signature policy. 1732 B.3 General Signature Policy Information 1734 General information should be recorded about the signature policy along 1735 with the definition of the rules which form the signature policy as 1736 described in subsequent subclauses. This should include: 1738 * Policy Object Identifier: The "Signature Policy" will be 1739 identifiable by an OID (Object Identifier) whose last component 1740 (i.e. right most) is an integer that is specific to a particular 1741 version issued on the given date. 1742 * Date of issue: When the "Signature Policy" was issued. 1743 * Signature Policy Issuer name: An identifier for the body 1744 responsible for issuing the Signature Policy. This may be used 1745 by the signer or verifying in deciding if a policy is to be 1746 trusted, in which case the signer/verifier must authenticate 1747 the origin of the signature policy as coming from the identified 1748 issuer. 1749 * Signing period: The start time and date, optionally with an end 1750 time and date, for the period over which the signature policy 1751 may be used to generate electronic signatures. 1752 * Field of application: This defines in general terms the general 1753 legal/contract/application contexts in which the signature 1754 policy is to be used and the specific purposes for which the 1755 electronic signature is to be applied. 1757 Internet Draft Electronic Signature Policies 1759 B.4 Recognized Commitment Types 1761 The signature validation policy may recognize one or more types of 1762 commitment as being supported by electronic signatures produced under 1763 the security policy. If an electronic signature does not contain a 1764 recognized commitment type then the semantics of the electronic 1765 signature is dependent on the data being signed and the context in 1766 which it is being used. 1768 Only recognized commitment types are allowed in an electronic 1769 signature. 1771 The definition of a commitment type includes: 1772 * the object identifier for the commitment; 1773 * the contractual/legal/application context in which the signature 1774 may be used (e.g. submission of messages); 1775 * a description of the support provided within the terms of the 1776 context (e.g. proof that the identified source submitted the 1777 message if the signature is created when message submission is 1778 initiated). 1780 The definition of a commitment type can be registered: 1781 * as part of the validation policy; 1782 * as part of the application/contract/legal environment; 1783 * as part of generic register of definitions. 1785 The legal/contractual context will determine the rules applied to the 1786 signature, as defined by the signature policy and its recognized 1787 commitment types, make it fit for purpose intended. 1789 B.5 Rules for Use of Certification Authorities 1791 The certificate validation process of the verifier, and hence the 1792 certificates that may be used by the signer for a valid electronic 1793 signature, may be constrained by the combination of the trust point and 1794 certificate path constraints in the signature validation policy. 1796 B.5.1 Trust Points 1798 The signature validation policy defines the certification authority 1799 trust points that are to be used for signature verification. Several 1800 trust points may be specified under one signature policy. Specific 1801 trust points may be specified for a particular type of commitment 1802 defined under the signature policy. For a signature to be valid a 1803 certification path must exists between the Certification Authority 1804 that has granted the certificate selected by the signer (i.e. the used 1805 user-certificate) and one of the trust point of the "Signature 1806 Validation Policy". 1808 Internet Draft Electronic Signature Policies 1810 B.5.2 Certification Path 1812 There may be constraints on the use of certificates issued by one or 1813 more CA(s) in the certificate chain and trust points. The two prime 1814 constraints are certificate policy constraints and naming constraints: 1816 * Certificate policy constraints limit the certification chain 1817 between the user certificate and the certificate of the trusted 1818 point to a given set of certificate policies, or equivalents 1819 identified through certificate policy mapping. 1820 * The naming constraints limit the forms of names that the CA is 1821 allowed to certify. 1823 Name constraints are particularly important when a "Signature policy" 1824 identifies more than one trust point. In this case, a certificate of a 1825 particular trusted point may only be used to verify signatures from 1826 users with names permitted under the name constraint. 1828 Certificate Authorities may be organized in a tree structure, this tree 1829 structure may represent the trust relationship between various CA(s) 1830 and the users CA. Alternatively, a mesh relationship may exist where a 1831 combination of tree and peer cross-certificates may be used. The 1832 requirement of the certificate path in this document is that it 1833 provides the trust relationship between all the CAs and the signers 1834 user certificate. The starting point from a verification point of view, 1835 is the "trust point". A trust point is usually a CA that publishes 1836 self-certified certificates, is the starting point from which the 1837 verifier verifies the certificate chain. Naming constraints may 1838 apply from the trust point, in which case they apply throughout the set 1839 of certificates that make up the certificate path down to the signer's 1840 user certificate. 1842 Policy constraints can be easier to process but to be effective require 1843 the presence of a certificate policy identifier in the certificates 1844 used in a certification path. 1846 Certificate path processing, thus generally starts with one of the 1847 trust point from the signature policy and ends with the user 1848 certificate. The certificate path processing procedures defined in RFC 1849 2459 clause 6 identifies the following initial parameters that are 1850 selected by the verifier in certificate path processing: 1852 * acceptable certificate policies; 1853 * naming constraints in terms of constrained and excluded naming 1854 subtree; 1855 * requirements for explicit certificate policy indication and 1856 whether certificate policy mapping are allowed; 1857 * restrictions on the certificate path length. 1859 The signature validation policy identifies constraints on these 1860 parameters. 1862 Internet Draft Electronic Signature Policies 1864 B.6 Revocation Rules 1866 The signature policy should defines rules specifying requirements for 1867 the use of certificate revocation lists (CRLs) and/or on-line 1868 certificate status check service to check the validity of a certificate. 1869 These rules specify the mandated minimum checks that must be carried 1870 out. 1872 It is expected that in many cases either check may be selected with 1873 CRLs checks being carried out for certificate status that are 1874 unavailable from OCSP servers. The verifier may take into account 1875 information in the certificate in deciding how best to check the 1876 revocation status (e.g. a certificate extension field about authority 1877 information access or a CRL distribution point) provided that it does 1878 not conflict with the signature policy revocation rules. 1880 B.7 Rules for the Use of Roles 1882 Roles can be supported as claimed roles or as certified roles using 1883 Attribute Certificates. 1885 B.7.1 Attribute Values 1887 When signature under a role is mandated by the signature policy, then 1888 either Attribute Certificates may be used or the signer may provide a 1889 claimed role attribute. The acceptable attribute types or values may be 1890 dependent on the type of commitment. For example, a user may have 1891 several roles that allow the user to sign data that imply commitments 1892 based on one or more of his roles. 1894 B.7.2 Trust Points for Certified Attributes 1896 When a signature under a certified role is mandated by the signature 1897 policy, Attribute Authorities are used and need to be validated as part 1898 of the overall validation of the electronic signature. The trust points 1899 for Attribute Authorities do not need to be the same as the trust 1900 points to evaluate a certificate from the CA of the signer. Thus the 1901 trust point for verifying roles need not be the same as trust point 1902 used to validate the certificate path of the user's key. 1904 Naming and certification policy constraints may apply to the AA in 1905 similar circumstance to when they apply to CA. Constraints on the AA 1906 and CA need not be exactly the same. 1908 AA(s) may be used when a signer is creating a signature on behalf of an 1909 organization, they can be particularly useful when the signature 1910 represents an organizational role. AA(s) may or may not be the same 1911 authority as CA(s). 1913 Thus, the Signature Policy identifies trust points that can be used for 1914 Attribute Authorities, either by reference to the same trust points as 1915 used for Certification Authorities, or by an independent list. 1917 Internet Draft Electronic Signature Policies 1919 B.7.3 Certification Path for Certified Attributes 1921 Attribute Authorities may be organized in a tree structure in similar 1922 way to CA where the AAs are the leafs of such a tree. Naming and other 1923 constraints may be required on attribute certificate paths in a similar 1924 manner to other electronic signature certificate paths. 1926 Thus, the Signature Policy identify constraints on the following 1927 parameters used as input to the certificate path processing: 1929 * acceptable certificate policies, including requirements for 1930 explicit certificate policy indication and whether certificate 1931 policy mapping is allowed; 1932 * naming constraints in terms of constrained and excluded naming 1933 subtrees; 1934 * restrictions on the certificate path length. 1936 B.8 Rules for the Use of Timestamping and Timing 1938 The following rules should be used when specifying, constraints on the 1939 certificate paths for timestamping authorities, constraints on the 1940 timestamping authority names and general timing constraints. 1942 B.8.1 Trust Points and Certificate Paths 1944 Signature keys from timestamping authorities will need to be supported 1945 by a certification path. The certification path used for timestamping 1946 authorities requires a trustpoint and possibly path constraints in the 1947 same way that the certificate path for the signer's key. 1949 B.8.2 Timestamping Authority Names 1951 Restrictions may need to be placed by the validation policy on the 1952 named entities that may act a timestamping authorities. 1954 B.8.3 Timing Constraints - Caution Period 1956 Before an electronic signature may really be valid, the verifier has to 1957 be sure that the holder of the private key was really the only one in 1958 possession of key at the time of signing. However, there is an 1959 inevitable delay between a compromise or loss of key being noted, and a 1960 report of revocation being distributed. To allow greater confidence in 1961 the validity of a signature, a "cautionary period" may be identified 1962 before a signature may be said to be valid with high confidence. A 1963 verifier may revalidate a signature after this cautionary signature, or 1964 wait for this period before validating a signature. 1966 The validation policy may specify such a cautionary period. 1968 Internet Draft Electronic Signature Policies 1970 B.8.4 Timing Constraints - Timestamp Delay 1972 There will be some delay between the time that a signature is created 1973 and the time the signer's digital signature is timestamped. However, 1974 the longer this elapsed period the greater the risk of the signature 1975 being invalidated due to compromise or deliberate revocation of its 1976 private signing key by the signer. Thus the signature policy should 1977 specify a maximum acceptable delay between the signing time as claimed 1978 by the signer and the time included within the timestamp. 1980 B.9 Rules for Verification Data to be followed 1982 By specifying the requirements on the signer and verifier the 1983 responsibilities of the two parties can be clearly defined to establish 1984 all the necessary information. 1986 These verification data rules should include: 1987 * requirements on the signer to provide given signed attributes; 1988 * requirements on the verifier to obtain additional certificates, CRLs, 1989 results of on line certificate status checks and to use timestamps (if 1990 no already provided by the signer). 1992 B.10 Rules for Algorithm Constraints and Key Lengths 1993 The signature validation policy may identify a set of signing 1994 algorithms (hashing, public key, combinations) and minimum key lengths 1995 that may be used: 1997 * by the signer in creating the signature; 1998 * in end entity public key Certificates; 1999 * CA Certificates; 2000 * attribute Certificates; 2001 * by the timestamping authority. 2003 B.11 Other Signature Policy Rules 2005 The signature policy may specify additional policy rules, for example 2006 rules that relate to the environment used by the signer. These 2007 additional rules may be defined in computer processable and/or human 2008 readable form. 2010 B.12 Signature Policy Protection 2012 When signer or verifier obtains a copy of the Signature Policy from an 2013 issuer, the source should be authenticated (for example by using 2014 electronic signatures). When the signer references a signature policy 2015 the Object Identifier (OID) of the policy, the hash value and the hash 2016 algorithm OID of that policy must be included in the Electronic 2017 Signature. 2019 Internet Draft Electronic Signature Policies 2021 It is a mandatory requirement of this present document that the 2022 signature policy value computes to one, and only one hash value using 2023 the specified hash algorithm. This means that there must be a single 2024 binary value of the encoded form of the signature policy for the unique 2025 hash value to be calculated. For example, there may exist a particular 2026 file type, length and format on which the hash value is calculated 2027 which is fixed and definitive for a particular signature policy. 2029 The hash value may be obtained by: 2031 the signer performing his own computation of the hash over the 2032 signature policy using his preferred hash algorithm permitted by 2033 the signature policy, and the definitive binary encoded form. 2035 the signer, having verified the source of the policy, may use 2036 both the hash algorithm and the hash value included in the 2037 computer processable form of the policy (see section 6.1).