idnits 2.17.1 draft-ietf-smime-escertid-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 576. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 are 8 instances of too long lines in the document, the longest one being 4 characters 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 -- 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 17, 2006) is 6556 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UNIVERSAL 12' is mentioned on line 348, but not defined == Missing Reference: 'UTF8' is mentioned on line 349, but not defined -- Looks like a reference, but probably isn't: '0' on line 496 -- Looks like a reference, but probably isn't: '1' on line 497 -- Looks like a reference, but probably isn't: '2' on line 498 ** Obsolete normative reference: RFC 3280 (ref. 'PKIXCERT') (Obsoleted by RFC 5280) Summary: 7 errors (**), 0 flaws (~~), 5 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 Expires: October 19, 2006 April 17, 2006 6 ESS Update: Adding CertID Algorithm Agility 7 draft-ietf-smime-escertid-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 In the original Enhanced Security Services for S/MIME draft, a 41 structure for cryptographically linking the certificate to be used in 42 validation with the signature was introduced, this structure was 43 hardwired to use SHA-1. This document allows for the structure to 44 have algorithm agility and defines new attributes to deal with the 45 updating. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Replace Section 5.4 Signing Certificate Attribute 52 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Insert new section 5.4.1 . . . . . . . . . . . . . . . . . . . 5 54 4. Insert new section 5.4.1.1 . . . . . . . . . . . . . . . . . . 7 55 5. Insert new section 5.4.2 . . . . . . . . . . . . . . . . . . . 9 56 6. Renumber Section 5.4.1 Certificate Identification . . . . . . 11 57 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 58 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 60 Intellectual Property and Copyright Statements . . . . . . . . . . 18 62 1. Introduction 64 In the original Enhanced Security Services (ESS) for S/MIME draft 65 [ESS], a structure for cryptographically linking the certificate to 66 be used in validation with the signature was defined. This 67 structure, called ESSCertID was hardwired to use a SHA-1 hash value. 68 The recent attacks on SHA-1 require that we change define a new 69 attribute which allows for the use of a different algorithm. This 70 document performs that task. 72 This document defines the structure ESSCertIDv2 along with a new 73 attribute SigningCertificateV2 which uses the updated structure. 74 This document allows for the structure to have algorithm agility and 75 defines new attributes to deal with the updating. 77 1.1. Notation 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Replace Section 5.4 Signing Certificate Attribute Definitions 85 The signing certificate attribute is designed to prevent simple 86 substitution and re-issue attacks, and to allow for a restricted set 87 of authorization certificates to be used in verifying a signature. 89 Two different attributes exist for this due to a flaw in the original 90 design. The only substantial difference between the two attributes 91 is that SigningCertificateV2 allows for hash algorithm agility, while 92 SigningCertificate forces the use of the SHA-1 hash algorithm. With 93 the recent advances in the ability to create hash collisions for 94 SHA-1 it is deemed wise to move forward sooner rather than later. 96 When the SHA-1 hash function is used, the SigningCertificate 97 attribute MUST be used. The SigningCertificateV2 attribute MUST be 98 used if any algorithm other than SHA-1 is used and SHOULD NOT be used 99 for SHA-1. Applications SHOULD recognize both attributes as long as 100 they consider SHA-1 to be sufficiently descriminating. 102 3. Insert new section 5.4.1 104 5.4.1 Signing Certificate Attribute Definition 106 The signing certificate attribute is designed to prevent the simple 107 substitution and re-issue attacks, and to allow for a restricted set 108 of authorization certificates to be used in verifying a signature. 110 The definition of SigningCertificateV2 is 112 SigningCertificateV2 ::= SEQUENCE { 113 certs SEQUENCE OF ESSCertIDv2, 114 policies SEQUENCE OF PolicyInformation OPTIONAL 115 } 117 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 118 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 119 smime(16) id-aa(2) XX } 121 certs contains the list of certificates that are to be used in 122 validating the message. The first certificate identified in the 123 sequence of certificate identifiers MUST be the certificate used 124 to verify the signature. The encoding of the ESSCertIDv2 for this 125 certificate SHOULD include the issuerSerial field. If other 126 constraints ensure that issuerAndSerialNumber will be present in 127 the SignerInfo, the issuerSerial field MAY be omitted. The 128 certificate identified is used during the signature verification 129 process. If the hash of the certificate does not match the 130 certificate used to verify the signature, the signature MUST be 131 considered invalid. 133 If more than one certificate is present, subsequent certificates 134 limit the set of authorization certificates that are used during 135 signature validation. Authorization certificates can be either 136 attribute certificates or normal certificates. The issuerSerial 137 field (in the ESSCertIDv2 structure) SHOULD be present for these 138 certificates, unless the client who is validating the signature is 139 expected to have easy access to all the certificates required for 140 validation. If only the signing certificate is present in the 141 sequence, there are no restrictions on the set of authorization 142 certificates used in validating the signature. 144 policies contains a sequence of policy information terms that 145 identify those certificate policies that the signer asserts apply 146 to the certificate, and under which the certificate should be 147 relied upon. This value suggests a policy value to be used in the 148 relying party's certification path validation. The definition of 149 PolicyInformation can be found in [PKIXCERT]. 151 If present, the SigningCertificateV2 attribute MUST be a signed 152 attribute; it MUST NOT be an unsigned attribute. CMS defines 153 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 154 include multiple instances of the SigningCertificate attribute. CMS 155 defines the ASN.1 syntax for the signed attributes to include 156 attrValues SET OF AttributeValue. A SigningCertificate attribute 157 MUST include only a single instance of AttributeValue. There MUST 158 NOT be zero or multiple instances of AttributeValue present in the 159 attrValues SET OF AttributeValue. 161 4. Insert new section 5.4.1.1 163 Insert the following text as a new section 165 5.4.1.1 Certificate Identification 167 The best way to identify certificates is an often-discussed issue. 168 The ESSCertIDV2 structure supplies two different fields that are used 169 for this purpose. 171 The hash of the entire certificate allows for a verifier to check 172 that the certificate used in the verification process was the same as 173 the signer intended to be used. Hashes are convient in that they are 174 frequently used by certificate stores as a method of indexing and 175 retrieving certificates as well. The use of the hash is required by 176 this structure since the detection of substitued certificates is 177 based on the fact they would map to different hash values. 179 The issuer/serial number pair is the method of identification of 180 certificates used in [PKIXCERT]. That document imposes a restriction 181 for certificates that the issuer DN must be present. The issuer/ 182 serial number pair would therefore normally be sufficient to identify 183 the correct signing certificate. (This assumes the same issuer name 184 is not re-used from the set of trust anchors.) The issuer/serial 185 number pair can be stored in the sid field of the SignerInfo object. 186 However the sid field is not covered by the signature. In the cases 187 where the issuer/serial number pair is not used in the sid or the 188 issuer/serial number need to be signed, they should be placed in the 189 issuerSerial field of the ESSCertIDv2 structure. 191 Attribute certificates and additional public key certificates 192 containing authorization information do not have an issuer/serial 193 number pair represented anywhere in a SignerInfo object. When an 194 attribute certificate or an additional public key certificate is not 195 included in the SignedData object, it becomes much more difficult to 196 get the correct set of certificates based only on a hash of the 197 certificate. For this reason, these certificates SHOULD be 198 identified by the IssuerSerial object. 200 This document defines a certificate identifier as: 202 ESSCertIDv2 ::= SEQUENCE { 203 hashAlg AlgorithmIdentifier DEFAULT {id-sha256} 204 certHash Hash, 205 issuerSerial IssuerSerial OPTIONAL 206 } 208 Hash ::= OCTET STRING 210 IssuerSerial ::= SEQUENCE { 211 issuer GeneralNames, 212 serialNumber CertificateSerialNumber 213 } 215 The fields of ESSCertIDv2 are defined as follows: 217 certHash is computed over the entire DER encoded certificate 218 including the signature. The issuerSerial would normally be 219 present unless the value can be inferred from other information. 221 hashAlg contains the identifier of the algorithm used in computing 222 certHash. 224 issuerSerial holds the identification of the certificate. 226 The fields of IssuerSerial are defined as follows: 228 issuer contains the issuer name of the certificate. For non- 229 attribute certificates, the issuer MUST contain only the issuer 230 name from the certificate encoded in the directoryName choice of 231 GeneralNames. For attribute certificates, the issuer MUST contain 232 the issuer name field from the attribute certificate. 234 serialNumber holds the serial number that uniquely identifies the 235 certificate. 237 5. Insert new section 5.4.2 239 5.4.2 Signing Certificate Attribute Definition with SHA-1 241 The signing certificate attribute is designed to prevent the simple 242 substitution and re-issue attacks, and to allow for a restricted set 243 of authorization certificates to be used in verifying a signature. 245 The definition of SigningCertificate is 247 SigningCertificate ::= SEQUENCE { 248 certs SEQUENCE OF ESSCertID, 249 policies SEQUENCE OF PolicyInformation OPTIONAL 250 } 252 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 253 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 254 smime(16) id-aa(2) 12 } 256 The first certificate identified in the sequence of certificate 257 identifiers MUST be the certificate used to verify the signature. 258 The encoding of the ESSCertID for this certificate SHOULD include the 259 issuerSerial field. If other constraints ensure that 260 issuerAndSerialNumber will be present in the SignerInfo, the 261 issuerSerial field MAY be omitted. The certificate identified is 262 used during the signature verification process. If the hash of the 263 certificate does not match the certificate used to verify the 264 signature, the signature MUST be considered invalid. 266 If more than one certificate is present in the sequence of 267 ESSCertIDs, the certificates after the first one limit the set of 268 authorization certificates that are used during signature validation. 269 Authorization certificates can be either attribute certificates or 270 normal certificates. The issuerSerial field (in the ESSCertID 271 structure) SHOULD be present for these certificates, unless the 272 client who is validating the signature is expected to have easy 273 access to all the certificates required for validation. If only the 274 signing certificate is present in the sequence, there are no 275 restrictions on the set of authorization certificates used in 276 validating the signature. 278 The sequence of policy information terms identifies those certificate 279 policies that the signer asserts apply to the certificate, and under 280 which the certificate should be relied upon. This value suggests a 281 policy value to be used in the relying party's certification path 282 validation. 284 If present, the SigningCertificate attribute MUST be a signed 285 attribute; it MUST NOT be an unsigned attribute. CMS defines 286 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 287 include multiple instances of the SigningCertificate attribute. CMS 288 defines the ASN.1 syntax for the signed attributes to include 289 attrValues SET OF AttributeValue. A SigningCertificate attribute 290 MUST include only a single instance of AttributeValue. There MUST 291 NOT be zero or multiple instances of AttributeValue present in the 292 attrValues SET OF AttributeValue. 294 6. Renumber Section 5.4.1 Certificate Identification 296 Change the number on this section from 5.4.1 to 5.4.2.1 298 Change the title on this section to "Certificate Identification with 299 SHA-1". 301 7. Normative References 303 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 304 RFC 2634, June 1999. 306 [PKIXCERT] 307 Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 308 X.509 Public Key Infrastructure Certificate and 309 Certificate Revocation List (CRL) Profile", RFC 3280, 310 April 2002. 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", RFC 2119, BCP 14, March 1997. 315 Appendix A. ASN.1 Module 317 ExtendedSecurityServices-2006 318 { iso(1) member-body(2) us(840) rsadsi(113549) 319 pkcs(1) pkcs-9(9) smime(16) modules(0) ess-2006(TBD) } 321 DEFINITIONS IMPLICIT TAGS ::= 322 BEGIN 324 IMPORTS 326 -- Cryptographic Message Syntax (CMS) 327 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, 328 AlgorithmIdentifier 329 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 330 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} 332 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 333 -- 1988 Syntax 334 PolicyInformation, CertificateSerialNumber, GeneralNames FROM 335 PKIX1Implicit88 {iso(1) 336 identified-organization(3) dod(6) internet(1) security(5) 337 mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit(19)}; 339 -- Extended Security Services 341 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 342 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 343 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 344 -- have at least one entry. MAX indicates the upper bound is unspecified. 345 -- Implementations are free to choose an upper bound that suits their 346 -- environment. 348 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 349 -- The contents are formatted as described in [UTF8] 351 -- Section 2.7 353 ReceiptRequest ::= SEQUENCE { 354 signedContentIdentifier ContentIdentifier, 355 receiptsFrom ReceiptsFrom, 356 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } 358 ub-receiptsTo INTEGER ::= 16 360 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 361 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 363 ContentIdentifier ::= OCTET STRING 364 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 365 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 367 ReceiptsFrom ::= CHOICE { 368 allOrFirstTier [0] AllOrFirstTier, 369 -- formerly "allOrNone [0]AllOrNone" 370 receiptList [1] SEQUENCE OF GeneralNames } 372 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 373 allReceipts (0), 374 firstTierRecipients (1) } 376 -- Section 2.8 378 Receipt ::= SEQUENCE { 379 version ESSVersion, 380 contentType ContentType, 381 signedContentIdentifier ContentIdentifier, 382 originatorSignatureValue OCTET STRING } 384 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 385 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 387 ESSVersion ::= INTEGER { v1(1) } 389 -- Section 2.9 391 ContentHints ::= SEQUENCE { 392 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 393 contentType ContentType } 395 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 396 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 398 -- Section 2.10 400 MsgSigDigest ::= OCTET STRING 402 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 403 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 405 -- Section 2.11 407 ContentReference ::= SEQUENCE { 408 contentType ContentType, 409 signedContentIdentifier ContentIdentifier, 410 originatorSignatureValue OCTET STRING } 412 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 413 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 415 -- Section 3.2 417 ESSSecurityLabel ::= SET { 418 security-policy-identifier SecurityPolicyIdentifier, 419 security-classification SecurityClassification OPTIONAL, 420 privacy-mark ESSPrivacyMark OPTIONAL, 421 security-categories SecurityCategories OPTIONAL } 423 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 424 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 426 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 428 SecurityClassification ::= INTEGER { 429 unmarked (0), 430 unclassified (1), 431 restricted (2), 432 confidential (3), 433 secret (4), 434 top-secret (5) } (0..ub-integer-options) 436 ub-integer-options INTEGER ::= 256 438 ESSPrivacyMark ::= CHOICE { 439 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 440 utf8String UTF8String (SIZE (1..MAX)) 441 } 443 ub-privacy-mark-length INTEGER ::= 128 445 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 446 SecurityCategory 448 ub-security-categories INTEGER ::= 64 450 SecurityCategory ::= SEQUENCE { 451 type [0] OBJECT IDENTIFIER, 452 value [1] ANY DEFINED BY type -- defined by type 453 } 455 --Note: The aforementioned SecurityCategory syntax produces identical 456 --hex encodings as the following SecurityCategory syntax that is 457 --documented in the X.411 specification: 458 -- 459 --SecurityCategory ::= SEQUENCE { 460 -- type [0] SECURITY-CATEGORY, 461 -- value [1] ANY DEFINED BY type } 462 -- 463 --SECURITY-CATEGORY MACRO ::= 464 --BEGIN 465 --TYPE NOTATION ::= type | empty 466 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 467 --END 469 -- Section 3.4 471 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 473 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 474 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 476 -- Section 4.4 478 MLExpansionHistory ::= SEQUENCE 479 SIZE (1..ub-ml-expansion-history) OF MLData 481 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 482 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 484 ub-ml-expansion-history INTEGER ::= 64 486 MLData ::= SEQUENCE { 487 mailListIdentifier EntityIdentifier, 488 expansionTime GeneralizedTime, 489 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 491 EntityIdentifier ::= CHOICE { 492 issuerAndSerialNumber IssuerAndSerialNumber, 493 subjectKeyIdentifier SubjectKeyIdentifier } 495 MLReceiptPolicy ::= CHOICE { 496 none [0] NULL, 497 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 498 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 500 -- Section 5.4 502 SigningCertificate ::= SEQUENCE { 503 certs SEQUENCE OF ESSCertID, 504 policies SEQUENCE OF PolicyInformation OPTIONAL 505 } 506 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 507 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 508 smime(16) id-aa(2) 12 } 510 SigningCertificateV2 ::= SEQUENCE { 511 certs SEQUENCE OF ESSCertIDv2, 512 policies SEQUENCE OF PolicyInformation OPTIONAL 513 } 515 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 516 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 517 smime(16) id-aa(2) XX } 519 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 520 country(16) us(840) organization(1) gov(101) 521 csor(3) nistalgorithm(4) hashalgs(2) 1 } 523 ESSCertIDv2 ::= SEQUENCE { 524 certHash Hash, 525 hashAlgorithm AlgorithmIdentifier DEFAULT {algorithm 526 id-sha256 parameters NULL} 527 issuerSerial IssuerSerial OPTIONAL 528 } 530 ESSCertID ::= SEQUENCE { 531 certHash Hash, 532 issuerSerial IssuerSerial OPTIONAL 533 } 535 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 537 IssuerSerial ::= SEQUENCE { 538 issuer GeneralNames, 539 serialNumber CertificateSerialNumber 540 } 542 END -- of ExtendedSecurityServices-2006 544 Author's Address 546 Jim Schaad 547 Soaring Hawk Consulting 548 PO Box 675 549 Gold Bar, WA 98251 551 Phone: (425) 785-1031 552 Email: jimsch@exmsft.com 554 Intellectual Property Statement 556 The IETF takes no position regarding the validity or scope of any 557 Intellectual Property Rights or other rights that might be claimed to 558 pertain to the implementation or use of the technology described in 559 this document or the extent to which any license under such rights 560 might or might not be available; nor does it represent that it has 561 made any independent effort to identify any such rights. Information 562 on the procedures with respect to rights in RFC documents can be 563 found in BCP 78 and BCP 79. 565 Copies of IPR disclosures made to the IETF Secretariat and any 566 assurances of licenses to be made available, or the result of an 567 attempt made to obtain a general license or permission for the use of 568 such proprietary rights by implementers or users of this 569 specification can be obtained from the IETF on-line IPR repository at 570 http://www.ietf.org/ipr. 572 The IETF invites any interested party to bring to its attention any 573 copyrights, patents or patent applications, or other proprietary 574 rights that may cover technology that may be required to implement 575 this standard. Please address the information to the IETF at 576 ietf-ipr@ietf.org. 578 Disclaimer of Validity 580 This document and the information contained herein are provided on an 581 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 582 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 583 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 584 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 585 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Copyright Statement 590 Copyright (C) The Internet Society (2006). This document is subject 591 to the rights, licenses and restrictions contained in BCP 78, and 592 except as set forth therein, the authors retain all their rights. 594 Acknowledgment 596 Funding for the RFC Editor function is currently provided by the 597 Internet Society.