idnits 2.17.1 draft-ietf-smime-escertid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 607. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 131 has weird spacing: '... certs conta...' == Line 154 has weird spacing: '...olicies conta...' == Line 227 has weird spacing: '...hashAlg conta...' == Line 230 has weird spacing: '...ertHash is co...' == Line 233 has weird spacing: '...rSerial holds...' == (2 more instances...) -- 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 (April 2006) is 6557 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UNIVERSAL 12' is mentioned on line 362, but not defined == Missing Reference: 'UTF8' is mentioned on line 363, but not defined -- Looks like a reference, but probably isn't: '0' on line 511 -- Looks like a reference, but probably isn't: '1' on line 512 -- Looks like a reference, but probably isn't: '2' on line 513 ** Obsolete normative reference: RFC 3280 (ref. 'PKIXCERT') (Obsoleted by RFC 5280) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Intended status: Informational April 2006 5 Expires: October 3, 2006 7 ESS Update: Adding CertID Algorithm Agility 8 draft-ietf-smime-escertid-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 3, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 In the original Enhanced Security Services for S/MIME draft, a 42 structure for cryptographically linking the certificate to be used in 43 validation with the signature was introduced, this structure was 44 hardwired to use SHA-1. This document allows for the structure to 45 have algorithm agility and defines new attributes to deal with the 46 updating. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Replace Section 5.4 'Signing Certificate Attribute 53 Definitions' . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Insert new section 5.4.1 'Signing Certificate Attribute 55 Definition Version 2' . . . . . . . . . . . . . . . . . . . . 5 56 4. Insert new section 5.4.1.1 'Certificate Identification 57 Version 2' . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Insert new section 5.4.2 ' Signing Certificate Attribute 59 Defintion Version 1 . . . . . . . . . . . . . . . . . . . . . 9 60 6. Renumber Section 5.4.1 Certificate Identification Version 1 . 11 61 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 62 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 64 Intellectual Property and Copyright Statements . . . . . . . . . . 19 66 1. Introduction 68 In the original Enhanced Security Services (ESS) for S/MIME draft 69 [ESS], a structure for cryptographically linking the certificate to 70 be used in validation with the signature was defined. This 71 structure, called ESSCertID was hardwired to use a SHA-1 hash value. 72 The recent attacks on SHA-1 require that we change define a new 73 attribute which allows for the use of a different algorithm. This 74 document performs that task. 76 This document defines the structure ESSCertIDv2 along with a new 77 attribute SigningCertificateV2 which uses the updated structure. 78 This document allows for the structure to have algorithm agility and 79 defines new attributes to deal with the updating. 81 1.1. Notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Replace Section 5.4 'Signing Certificate Attribute Definitions' 89 The signing certificate attribute is designed to prevent simple 90 substitution and re-issue attacks, and to allow for a restricted set 91 of authorization certificates to be used in verifying a signature. 93 Two different attributes exist for this due to a flaw in the original 94 design. The only substantial difference between the two attributes 95 is that SigningCertificateV2 allows for hash algorithm agility, while 96 SigningCertificate forces the use of the SHA-1 hash algorithm. With 97 the recent advances in the ability to create hash collisions for 98 SHA-1 it is deemed wise to move forward sooner rather than later. 100 When the SHA-1 hash function is used, the SigningCertificate 101 attribute MUST be used. The SigningCertificateV2 attribute MUST be 102 used if any algorithm other than SHA-1 is used and SHOULD NOT be used 103 for SHA-1. Applications SHOULD recognize both attributes as long as 104 they consider SHA-1 able to distingusih between two different 105 certificates. (I.e. the possiblity of a collision is suffiently 106 low.) 108 3. Insert new section 5.4.1 'Signing Certificate Attribute Definition 109 Version 2' 111 5.4.1 Signing Certificate Attribute Definition Version 2 113 The signing certificate attribute is designed to prevent the simple 114 substitution and re-issue attacks, and to allow for a restricted set 115 of authorization certificates to be used in verifying a signature. 117 SigningCertificateV2 is identified by the OID: 119 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 121 The attribute has the ASN.1 definition: 123 SigningCertificateV2 ::= SEQUENCE { 124 certs SEQUENCE OF ESSCertIDv2, 125 policies SEQUENCE OF PolicyInformation OPTIONAL 126 } 128 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 129 smime(16) id-aa(2) 47 } 131 certs contains the list of certificates that are to be used in 132 validating the message. The first certificate identified in the 133 sequence of certificate identifiers MUST be the certificate used 134 to verify the signature. The encoding of the ESSCertIDv2 for this 135 certificate SHOULD include the issuerSerial field. If other 136 constraints ensure that issuerAndSerialNumber will be present in 137 the SignerInfo, the issuerSerial field MAY be omitted. The 138 certificate identified is used during the signature verification 139 process. If the hash of the certificate does not match the 140 certificate used to verify the signature, the signature MUST be 141 considered invalid. 143 If more than one certificate is present, subsequent certificates 144 limit the set of authorization certificates that are used during 145 signature validation. Authorization certificates can be either 146 attribute certificates or normal certificates. The issuerSerial 147 field (in the ESSCertIDv2 structure) SHOULD be present for these 148 certificates, unless the client who is validating the signature is 149 expected to have easy access to all the certificates required for 150 validation. If only the signing certificate is present in the 151 sequence, there are no restrictions on the set of authorization 152 certificates used in validating the signature. 154 policies contains a sequence of policy information terms that 155 identify those certificate policies that the signer asserts apply 156 to the certificate, and under which the certificate should be 157 relied upon. This value suggests a policy value to be used in the 158 relying party's certification path validation. The definition of 159 PolicyInformation can be found in [PKIXCERT]. 161 If present, the SigningCertificateV2 attribute MUST be a signed 162 attribute; it MUST NOT be an unsigned attribute. CMS defines 163 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 164 include multiple instances of the SigningCertificate attribute. CMS 165 defines the ASN.1 syntax for the signed attributes to include 166 attrValues SET OF AttributeValue. A SigningCertificate attribute 167 MUST include only a single instance of AttributeValue. There MUST 168 NOT be zero or multiple instances of AttributeValue present in the 169 attrValues SET OF AttributeValue. 171 4. Insert new section 5.4.1.1 'Certificate Identification Version 2' 173 Insert the following text as a new section 175 5.4.1.1 Certificate Identification Version 2 177 The best way to identify certificates is an often-discussed issue. 178 The ESSCertIDV2 structure supplies two different fields that are used 179 for this purpose. 181 The hash of the entire certificate allows for a verifier to check 182 that the certificate used in the verification process was the same 183 certificate the signer intended. Hashes are convient in that they 184 are frequently used by certificate stores as a method of indexing and 185 retrieving certificates as well. The use of the hash is required by 186 this structure since the detection of substitued certificates is 187 based on the fact they would map to different hash values. 189 The issuer/serial number pair is the method of identification of 190 certificates used in [PKIXCERT]. That document imposes a restriction 191 for certificates that the issuer DN must be present. The issuer/ 192 serial number pair would therefore normally be sufficient to identify 193 the correct signing certificate. (This assumes the same issuer name 194 is not re-used from the set of trust anchors.) The issuer/serial 195 number pair can be stored in the sid field of the SignerInfo object. 196 However the sid field is not covered by the signature. In the cases 197 where the issuer/serial number pair is not used in the sid or the 198 issuer/serial number pair needs to be signed, they SHOULD be placed 199 in the issuerSerial field of the ESSCertIDv2 structure. 201 Attribute certificates and additional public key certificates 202 containing authorization information do not have an issuer/serial 203 number pair represented anywhere in a SignerInfo object. When an 204 attribute certificate or an additional public key certificate is not 205 included in the SignedData object, it becomes much more difficult to 206 get the correct set of certificates based only on a hash of the 207 certificate. For this reason, these certificates SHOULD be 208 identified by the IssuerSerial object. 210 This document defines a certificate identifier as: 212 ESSCertIDv2 ::= SEQUENCE { 213 hashAlg AlgorithmIdentifier DEFAULT {id-sha256} 214 certHash Hash, 215 issuerSerial IssuerSerial OPTIONAL 216 } 218 Hash ::= OCTET STRING 220 IssuerSerial ::= SEQUENCE { 221 issuer GeneralNames, 222 serialNumber CertificateSerialNumber 223 } 225 The fields of ESSCertIDv2 are defined as follows: 227 hashAlg contains the identifier of the algorithm used in computing 228 certHash. 230 certHash is computed over the entire DER encoded certificate 231 including the signature. 233 issuerSerial holds the identification of the certificate. The 234 issuerSerial would normally be present unless the value can be 235 inferred from other information. 237 The fields of IssuerSerial are defined as follows: 239 issuer contains the issuer name of the certificate. For non- 240 attribute certificates, the issuer MUST contain only the issuer 241 name from the certificate encoded in the directoryName choice of 242 GeneralNames. For attribute certificates, the issuer MUST contain 243 the issuer name field from the attribute certificate. 245 serialNumber holds the serial number that uniquely identifies the 246 certificate. 248 5. Insert new section 5.4.2 ' Signing Certificate Attribute Defintion 249 Version 1 251 5.4.2 Signing Certificate Attribute Definition Version 1 253 The signing certificate attribute is designed to prevent the simple 254 substitution and re-issue attacks, and to allow for a restricted set 255 of authorization certificates to be used in verifying a signature. 257 The definition of SigningCertificate is 259 SigningCertificate ::= SEQUENCE { 260 certs SEQUENCE OF ESSCertID, 261 policies SEQUENCE OF PolicyInformation OPTIONAL 262 } 264 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 265 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 266 smime(16) id-aa(2) 12 } 268 The first certificate identified in the sequence of certificate 269 identifiers MUST be the certificate used to verify the signature. 270 The encoding of the ESSCertID for this certificate SHOULD include the 271 issuerSerial field. If other constraints ensure that 272 issuerAndSerialNumber will be present in the SignerInfo, the 273 issuerSerial field MAY be omitted. The certificate identified is 274 used during the signature verification process. If the hash of the 275 certificate does not match the certificate used to verify the 276 signature, the signature MUST be considered invalid. 278 If more than one certificate is present in the sequence of 279 ESSCertIDs, the certificates after the first one limit the set of 280 authorization certificates that are used during signature validation. 281 Authorization certificates can be either attribute certificates or 282 normal certificates. The issuerSerial field (in the ESSCertID 283 structure) SHOULD be present for these certificates, unless the 284 client who is validating the signature is expected to have easy 285 access to all the certificates required for validation. If only the 286 signing certificate is present in the sequence, there are no 287 restrictions on the set of authorization certificates used in 288 validating the signature. 290 The sequence of policy information terms identifies those certificate 291 policies that the signer asserts apply to the certificate, and under 292 which the certificate should be relied upon. This value suggests a 293 policy value to be used in the relying party's certification path 294 validation. 296 If present, the SigningCertificate attribute MUST be a signed 297 attribute; it MUST NOT be an unsigned attribute. CMS defines 298 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 299 include multiple instances of the SigningCertificate attribute. CMS 300 defines the ASN.1 syntax for the signed attributes to include 301 attrValues SET OF AttributeValue. A SigningCertificate attribute 302 MUST include only a single instance of AttributeValue. There MUST 303 NOT be zero or multiple instances of AttributeValue present in the 304 attrValues SET OF AttributeValue. 306 6. Renumber Section 5.4.1 Certificate Identification Version 1 308 Change the number on this section from 5.4.1 to 5.4.2.1 310 Change the title on this section to "Certificate Identification 311 Version 1". 313 7. Normative References 315 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 316 RFC 2634, June 1999. 318 [PKIXCERT] 319 Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 320 X.509 Public Key Infrastructure Certificate and 321 Certificate Revocation List (CRL) Profile", RFC 3280, 322 April 2002. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", RFC 2119, BCP 14, March 1997. 327 Appendix A. ASN.1 Module 329 Replace the ASN.1 module with this one. 331 ExtendedSecurityServices-2006 332 { iso(1) member-body(2) us(840) rsadsi(113549) 333 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 335 DEFINITIONS IMPLICIT TAGS ::= 336 BEGIN 338 IMPORTS 340 -- Cryptographic Message Syntax (CMS) 341 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, 342 AlgorithmIdentifier 343 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 344 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} 346 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 347 -- 1988 Syntax 348 PolicyInformation, CertificateSerialNumber, GeneralNames FROM 349 PKIX1Implicit88 {iso(1) 350 identified-organization(3) dod(6) internet(1) security(5) 351 mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit(19)}; 353 -- Extended Security Services 355 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 356 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 357 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 358 -- have at least one entry. MAX indicates the upper bound is unspecified. 359 -- Implementations are free to choose an upper bound that suits their 360 -- environment. 362 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 363 -- The contents are formatted as described in [UTF8] 365 -- Section 2.7 367 ReceiptRequest ::= SEQUENCE { 368 signedContentIdentifier ContentIdentifier, 369 receiptsFrom ReceiptsFrom, 370 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } 372 ub-receiptsTo INTEGER ::= 16 374 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 375 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 377 ContentIdentifier ::= OCTET STRING 379 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 380 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 382 ReceiptsFrom ::= CHOICE { 383 allOrFirstTier [0] AllOrFirstTier, 384 -- formerly "allOrNone [0]AllOrNone" 385 receiptList [1] SEQUENCE OF GeneralNames } 387 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 388 allReceipts (0), 389 firstTierRecipients (1) } 391 -- Section 2.8 393 Receipt ::= SEQUENCE { 394 version ESSVersion, 395 contentType ContentType, 396 signedContentIdentifier ContentIdentifier, 397 originatorSignatureValue OCTET STRING } 399 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 400 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 402 ESSVersion ::= INTEGER { v1(1) } 404 -- Section 2.9 406 ContentHints ::= SEQUENCE { 407 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 408 contentType ContentType } 410 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 411 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 413 -- Section 2.10 415 MsgSigDigest ::= OCTET STRING 417 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 418 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 420 -- Section 2.11 422 ContentReference ::= SEQUENCE { 423 contentType ContentType, 424 signedContentIdentifier ContentIdentifier, 425 originatorSignatureValue OCTET STRING } 427 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 428 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 430 -- Section 3.2 432 ESSSecurityLabel ::= SET { 433 security-policy-identifier SecurityPolicyIdentifier, 434 security-classification SecurityClassification OPTIONAL, 435 privacy-mark ESSPrivacyMark OPTIONAL, 436 security-categories SecurityCategories OPTIONAL } 438 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 439 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 441 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 443 SecurityClassification ::= INTEGER { 444 unmarked (0), 445 unclassified (1), 446 restricted (2), 447 confidential (3), 448 secret (4), 449 top-secret (5) } (0..ub-integer-options) 451 ub-integer-options INTEGER ::= 256 453 ESSPrivacyMark ::= CHOICE { 454 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 455 utf8String UTF8String (SIZE (1..MAX)) 456 } 458 ub-privacy-mark-length INTEGER ::= 128 460 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 461 SecurityCategory 463 ub-security-categories INTEGER ::= 64 465 SecurityCategory ::= SEQUENCE { 466 type [0] OBJECT IDENTIFIER, 467 value [1] ANY DEFINED BY type -- defined by type 468 } 470 --Note: The aforementioned SecurityCategory syntax produces identical 471 --hex encodings as the following SecurityCategory syntax that is 472 --documented in the X.411 specification: 473 -- 474 --SecurityCategory ::= SEQUENCE { 475 -- type [0] SECURITY-CATEGORY, 476 -- value [1] ANY DEFINED BY type } 477 -- 478 --SECURITY-CATEGORY MACRO ::= 479 --BEGIN 480 --TYPE NOTATION ::= type | empty 481 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 482 --END 484 -- Section 3.4 486 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 488 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 489 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 491 -- Section 4.4 493 MLExpansionHistory ::= SEQUENCE 494 SIZE (1..ub-ml-expansion-history) OF MLData 496 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 497 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 499 ub-ml-expansion-history INTEGER ::= 64 501 MLData ::= SEQUENCE { 502 mailListIdentifier EntityIdentifier, 503 expansionTime GeneralizedTime, 504 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 506 EntityIdentifier ::= CHOICE { 507 issuerAndSerialNumber IssuerAndSerialNumber, 508 subjectKeyIdentifier SubjectKeyIdentifier } 510 MLReceiptPolicy ::= CHOICE { 511 none [0] NULL, 512 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 513 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 515 -- Section 5.4 517 SigningCertificate ::= SEQUENCE { 518 certs SEQUENCE OF ESSCertID, 519 policies SEQUENCE OF PolicyInformation OPTIONAL 520 } 522 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 523 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 524 smime(16) id-aa(2) 12 } 526 SigningCertificateV2 ::= SEQUENCE { 527 certs SEQUENCE OF ESSCertIDv2, 528 policies SEQUENCE OF PolicyInformation OPTIONAL 529 } 531 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 532 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 533 smime(16) id-aa(2) 47 } 535 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 536 country(16) us(840) organization(1) gov(101) 537 csor(3) nistalgorithm(4) hashalgs(2) 1 } 539 ESSCertIDv2 ::= SEQUENCE { 540 hashAlgorithm AlgorithmIdentifier DEFAULT {algorithm 541 id-sha256 parameters NULL} 542 certHash Hash, 543 issuerSerial IssuerSerial OPTIONAL 544 } 546 ESSCertID ::= SEQUENCE { 547 certHash Hash, 548 issuerSerial IssuerSerial OPTIONAL 549 } 551 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 553 IssuerSerial ::= SEQUENCE { 554 issuer GeneralNames, 555 serialNumber CertificateSerialNumber 556 } 558 END -- of ExtendedSecurityServices-2006 559 Author's Address 561 Jim Schaad 562 Soaring Hawk Consulting 563 PO Box 675 564 Gold Bar, WA 98251 566 Phone: (425) 785-1031 567 Email: jimsch@exmsft.com 569 Full Copyright Statement 571 Copyright (C) The Internet Society (2006). 573 This document is subject to the rights, licenses and restrictions 574 contained in BCP 78, and except as set forth therein, the authors 575 retain all their rights. 577 This document and the information contained herein are provided on an 578 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 579 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 580 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 581 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 582 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 583 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 585 Intellectual Property 587 The IETF takes no position regarding the validity or scope of any 588 Intellectual Property Rights or other rights that might be claimed to 589 pertain to the implementation or use of the technology described in 590 this document or the extent to which any license under such rights 591 might or might not be available; nor does it represent that it has 592 made any independent effort to identify any such rights. Information 593 on the procedures with respect to rights in RFC documents can be 594 found in BCP 78 and BCP 79. 596 Copies of IPR disclosures made to the IETF Secretariat and any 597 assurances of licenses to be made available, or the result of an 598 attempt made to obtain a general license or permission for the use of 599 such proprietary rights by implementers or users of this 600 specification can be obtained from the IETF on-line IPR repository at 601 http://www.ietf.org/ipr. 603 The IETF invites any interested party to bring to its attention any 604 copyrights, patents or patent applications, or other proprietary 605 rights that may cover technology that may be required to implement 606 this standard. Please address the information to the IETF at 607 ietf-ipr@ietf.org. 609 Acknowledgment 611 Funding for the RFC Editor function is provided by the IETF 612 Administrative Support Activity (IASA).