idnits 2.17.1 draft-ietf-smime-escertid-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 667. ** 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 are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2634, but the abstract doesn't seem to directly say this. It does mention RFC2634 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 174 has weird spacing: '... certs conta...' == Line 197 has weird spacing: '...olicies conta...' == Line 272 has weird spacing: '...hashAlg conta...' == Line 275 has weird spacing: '...ertHash is co...' == Line 278 has weird spacing: '...rSerial holds...' == (2 more instances...) (Using the creation date from RFC2634, updated by this document, for RFC5378 checks: 1997-11-19) -- 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 (January 4, 2007) is 6320 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: 'RFC 3852' is mentioned on line 393, but not defined ** Obsolete undefined reference: RFC 3852 (Obsoleted by RFC 5652) == Missing Reference: 'RFC 3280' is mentioned on line 408, but not defined ** Obsolete undefined reference: RFC 3280 (Obsoleted by RFC 5280) == Missing Reference: 'UNIVERSAL 12' is mentioned on line 424, but not defined == Missing Reference: 'UTF8' is mentioned on line 425, but not defined -- Looks like a reference, but probably isn't: '0' on line 571 -- Looks like a reference, but probably isn't: '1' on line 572 -- Looks like a reference, but probably isn't: '2' on line 573 == Unused Reference: 'RFC3280' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC3852' is defined on line 377, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (ref. 'PKIXCERT') (Obsoleted by RFC 5280) -- Duplicate reference: RFC3280, mentioned in 'RFC3280', was also mentioned in 'PKIXCERT'. ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 12 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 Updates: 2634 (if approved) January 4, 2007 5 Intended status: Standards Track 6 Expires: July 8, 2007 8 ESS Update: Adding CertID Algorithm Agility 9 draft-ietf-smime-escertid-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 8, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2007). 40 Abstract 42 In the original Enhanced Security Services for S/MIME document (RFC 43 2634), a structure for cryptographically linking the certificate to 44 be used in validation with the signature was introduced, this 45 structure was hardwired to use SHA-1. This document allows for the 46 structure to have algorithm agility and defines a new attribute for 47 this purpose. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Updates to RFC 2634 . . . . . . . . . . . . . . . . . . . 3 54 2. Replace Section 5.4 'Signing Certificate Attribute 55 Definitions' . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Insert new section 5.4.1 'Signing Certificate Attribute 57 Definition Version 2' . . . . . . . . . . . . . . . . . . . . 5 58 4. Insert new section 5.4.1.1 'Certificate Identification 59 Version 2' . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Insert new section 5.4.2 ' Signing Certificate Attribute 61 Defintion Version 1 . . . . . . . . . . . . . . . . . . . . . 9 62 6. Renumber Section 5.4.1 Certificate Identification Version 1 . 11 63 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 64 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 66 Intellectual Property and Copyright Statements . . . . . . . . . . 19 68 1. Introduction 70 In the original Enhanced Security Services (ESS) for S/MIME document 71 [ESS], a structure for cryptographically linking the certificate to 72 be used in validation with the signature was defined. This 73 structure, called ESSCertID was hardwired to use a SHA-1 hash value. 74 The recent attacks on SHA-1 require that we define a new attribute 75 which allows for the use of a different algorithms. This document 76 performs that task. 78 This document defines the structure ESSCertIDv2 along with a new 79 attribute SigningCertificateV2 which uses the updated structure. 80 This document allows for the structure to have algorithm agility and 81 defines new attributes to deal with the updating. 83 1.1. Notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 1.2. Updates to RFC 2634 91 This document updates section 5.4 of RFC 2634. Once the updates are 92 applied, the revised section will have the following structure: 94 5.4 Signing Certificate Attribute Definitions 96 5.4.1 Signing Certificate Attribute Definition Version 2 98 5.4.1.1 Certificate Identification Version 2 100 5.4.2 Signing Certificate Attribute Definition Version 1 102 5.4.2.1 Certificate Identification Version 1 104 In addition, the ASN.1 module in Appendix A is replaced. 106 2. Replace Section 5.4 'Signing Certificate Attribute Definitions' 108 The signing certificate attribute is designed to prevent simple 109 substitution and re-issue attacks, and to allow for a restricted set 110 of certificates to be used in verifying a signature. 112 Two different attributes exist for this due to a flaw in the original 113 design. The only substantial difference between the two attributes 114 is that SigningCertificateV2 allows for hash algorithm agility, while 115 SigningCertificate forces the use of the SHA-1 hash algorithm. With 116 the recent advances in the ability to create hash collisions for 117 SHA-1 it is wise to move forward sooner rather than later. 119 When the SHA-1 hash function is used, the SigningCertificate 120 attribute MUST be used. The SigningCertificateV2 attribute MUST be 121 used if any algorithm other than SHA-1 is used and SHOULD NOT be used 122 for SHA-1. Applications SHOULD recognize both attributes as long as 123 they consider SHA-1 able to distinguish between two different 124 certificates. (I.e. the possibility of a collision is sufficently 125 low.) 127 Four cases exist which need to be taken into account when using this 128 attribute for correct processing: 130 1. Signature Validates and the hashes match: This is the success 131 case. 133 2. Signature Validates and the hashes do not match: In this case the 134 certificate contained the correct public key, but the certificate 135 containing the public key is not the one that the signer intended 136 to be used. In this case the application should attempt a search 137 for a different certificate with the same public key and for 138 which the hashes match. If no such certificate can be found, 139 this is a failure case. 141 3. Signature Fails Validation and the hashes match: In this case it 142 can be assumed that the signature has been modified in some 143 fashion. This is a failure case. 145 4. Signature Fails Validation and the Hashes do not match: In this 146 case it can be either that the signature has been modified, or 147 that the wrong certificate has been used. Applications should 148 attempt a search for a different certificate which matches the 149 hash value in the attribute and use the new certificate to retry 150 the signature validation. 152 3. Insert new section 5.4.1 'Signing Certificate Attribute Definition 153 Version 2' 155 5.4.1 Signing Certificate Attribute Definition Version 2 157 The signing certificate attribute is designed to prevent the simple 158 substitution and re-issue attacks, and to allow for a restricted set 159 of certificates to be used in verifying a signature. 161 SigningCertificateV2 is identified by the OID: 163 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 164 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 165 smime(16) id-aa(2) 47 } 167 The attribute has the ASN.1 definition: 169 SigningCertificateV2 ::= SEQUENCE { 170 certs SEQUENCE OF ESSCertIDv2, 171 policies SEQUENCE OF PolicyInformation OPTIONAL 172 } 174 certs contains the list of certificates that are to be used in 175 validating the message. The first certificate identified in the 176 sequence of certificate identifiers MUST be the certificate used 177 to verify the signature. The encoding of the ESSCertIDv2 for this 178 certificate SHOULD include the issuerSerial field. If other 179 constraints ensure that issuerAndSerialNumber will be present in 180 the SignerInfo, the issuerSerial field MAY be omitted. The 181 certificate identified is used during the signature verification 182 process. If the hash of the certificate does not match the 183 certificate used to verify the signature, the signature MUST be 184 considered invalid. 186 If more than one certificate is present, subsequent certificates 187 limit the set of certificates that are used during signature 188 validation. Certificates can be either attribute certificates or 189 normal certificates. The issuerSerial field (in the ESSCertIDv2 190 structure) SHOULD be present for these certificates, unless the 191 client who is validating the signature is expected to have easy 192 access to all the certificates required for validation. If only 193 the signing certificate is present in the sequence, there are no 194 restrictions on the set of certificates used in validating the 195 signature. 197 policies contains a sequence of policy information terms that 198 identify those certificate policies that the signer asserts apply 199 to the certificate, and under which the certificate should be 200 relied upon. This value suggests a policy value to be used in the 201 relying party's certification path validation. The definition of 202 PolicyInformation can be found in [PKIXCERT]. 204 If present, the SigningCertificateV2 attribute MUST be a signed 205 attribute; it MUST NOT be an unsigned attribute. CMS defines 206 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 207 include multiple instances of the SigningCertificate attribute. CMS 208 defines the ASN.1 syntax for the signed attributes to include 209 attrValues SET OF AttributeValue. A SigningCertificate attribute 210 MUST include only a single instance of AttributeValue. There MUST 211 NOT be zero or multiple instances of AttributeValue present in the 212 attrValues SET OF AttributeValue. 214 4. Insert new section 5.4.1.1 'Certificate Identification Version 2' 216 Insert the following text as a new section 218 5.4.1.1 Certificate Identification Version 2 220 The best way to identify certificates is an often-discussed issue. 221 The ESSCertIDv2 structure supplies two different fields that are used 222 for this purpose. 224 The hash of the entire certificate allows for a verifier to check 225 that the certificate used in the verification process was the same 226 certificate the signer intended. Hashes are convenient in that they 227 are frequently used by certificate stores as a method of indexing and 228 retrieving certificates as well. The use of the hash is required by 229 this structure since the detection of substituted certificates is 230 based on the fact they would map to different hash values. 232 The issuer/serial number pair is the method of identification of 233 certificates used in [PKIXCERT]. That document imposes a restriction 234 for certificates that the issuer distinguished name must be present. 235 The issuer/serial number pair would therefore normally be sufficient 236 to identify the correct signing certificate. (This assumes the same 237 issuer name is not re-used from the set of trust anchors.) The 238 issuer/serial number pair can be stored in the sid field of the 239 SignerInfo object. However the sid field is not covered by the 240 signature. In the cases where the issuer/serial number pair is not 241 used in the sid or the issuer/serial number pair needs to be signed, 242 it SHOULD be placed in the issuerSerial field of the ESSCertIDv2 243 structure. 245 Attribute certificates and additional public key certificates 246 containing information do not have an issuer/serial number pair 247 represented anywhere in a SignerInfo object. When an attribute 248 certificate or an additional public key certificate is not included 249 in the SignedData object, it becomes much more difficult to get the 250 correct set of certificates based only on a hash of the certificate. 251 For this reason, these certificates SHOULD be identified by the 252 IssuerSerial object. 254 This document defines a certificate identifier as: 256 ESSCertIDv2 ::= SEQUENCE { 257 hashAlgorithm AlgorithmIdentifier 258 DEFAULT {algorithm id-sha256 parameters NULL}, 259 certHash Hash, 260 issuerSerial IssuerSerial OPTIONAL 261 } 263 Hash ::= OCTET STRING 265 IssuerSerial ::= SEQUENCE { 266 issuer GeneralNames, 267 serialNumber CertificateSerialNumber 268 } 270 The fields of ESSCertIDv2 are defined as follows: 272 hashAlg contains the identifier of the algorithm used in computing 273 certHash. 275 certHash is computed over the entire DER encoded certificate 276 including the signature. 278 issuerSerial holds the identification of the certificate. The 279 issuerSerial would normally be present unless the value can be 280 inferred from other information (e.g. the sid field of the 281 SignerInfo object). 283 The fields of IssuerSerial are defined as follows: 285 issuer contains the issuer name of the certificate. For non- 286 attribute certificates, the issuer MUST contain only the issuer 287 name from the certificate encoded in the directoryName choice of 288 GeneralNames. For attribute certificates, the issuer MUST contain 289 the issuer name field from the attribute certificate. 291 serialNumber holds the serial number that uniquely identifies the 292 certificate for the issuer. 294 5. Insert new section 5.4.2 ' Signing Certificate Attribute Defintion 295 Version 1 297 5.4.2 Signing Certificate Attribute Definition Version 1 299 The signing certificate attribute is designed to prevent the simple 300 substitution and re-issue attacks, and to allow for a restricted set 301 of certificates to be used in verifying a signature. 303 The definition of SigningCertificate is 305 SigningCertificate ::= SEQUENCE { 306 certs SEQUENCE OF ESSCertID, 307 policies SEQUENCE OF PolicyInformation OPTIONAL 308 } 310 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 311 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 312 smime(16) id-aa(2) 12 } 314 The first certificate identified in the sequence of certificate 315 identifiers MUST be the certificate used to verify the signature. 316 The encoding of the ESSCertID for this certificate SHOULD include the 317 issuerSerial field. If other constraints ensure that 318 issuerAndSerialNumber will be present in the SignerInfo, the 319 issuerSerial field MAY be omitted. The certificate identified is 320 used during the signature verification process. If the hash of the 321 certificate does not match the certificate used to verify the 322 signature, the signature MUST be considered invalid. 324 If more than one certificate is present in the sequence of 325 ESSCertIDs, the certificates after the first one limit the set of 326 certificates that are used during signature validation. Certificates 327 can be either attribute certificates or public key certificates. The 328 issuerSerial field (in the ESSCertID structure) SHOULD be present for 329 these certificates, unless the client who is validating the signature 330 is expected to have easy access to all the certificates required for 331 validation. If only the signing certificate is present in the 332 sequence, there are no restrictions on the set of certificates used 333 in validating the signature. 335 The sequence of policy information terms identifies those certificate 336 policies that the signer asserts apply to the certificate, and under 337 which the certificate should be relied upon. This value suggests a 338 policy value to be used in the relying party's certification path 339 validation. 341 If present, the SigningCertificate attribute MUST be a signed 342 attribute; it MUST NOT be an unsigned attribute. CMS defines 343 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 344 include multiple instances of the SigningCertificate attribute. CMS 345 defines the ASN.1 syntax for the signed attributes to include 346 attrValues SET OF AttributeValue. A SigningCertificate attribute 347 MUST include only a single instance of AttributeValue. There MUST 348 NOT be zero or multiple instances of AttributeValue present in the 349 attrValues SET OF AttributeValue. 351 6. Renumber Section 5.4.1 Certificate Identification Version 1 353 Change the number on this section from 5.4.1 to 5.4.2.1. 355 Change the title on this section to "Certificate Identification 356 Version 1". 358 7. Normative References 360 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 361 RFC 2634, June 1999. 363 [PKIXCERT] 364 Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 365 X.509 Public Key Infrastructure Certificate and 366 Certificate Revocation List (CRL) Profile", RFC 3280, 367 April 2002. 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", RFC 2119, BCP 14, March 1997. 372 [RFC3280] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 373 X.509 Public Key Infrastructure Certificate and 374 Certificate Revocation List (CRL) Profile", RFC 3280, 375 April 2002. 377 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 378 RFC 3852, July 2004. 380 Appendix A. ASN.1 Module 382 Replace the ASN.1 module in RFC 2634 with this one. 384 ExtendedSecurityServices-2006 385 { iso(1) member-body(2) us(840) rsadsi(113549) 386 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 388 DEFINITIONS IMPLICIT TAGS ::= 389 BEGIN 391 IMPORTS 393 -- Cryptographic Message Syntax (CMS) [RFC 3852] 394 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier 395 FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) 396 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 397 cms-2004(24)} 399 -- PKIX Certificate and CRL Profile, Section A.1 Explicity Tagged Module 400 -- 1988 Syntax [RFC 3280] 401 AlgorithmIdentifier, CertificateSerialNumber 402 FROM PKIX1Explicit88 403 { iso(1) identified-organization(3) dod(6) internet(1) 404 security(5) mechanisms(5) pkix(7) id-mod(0) pkix1-explicit(18) } 405 ; 407 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 408 -- 1988 Syntax [RFC 3280] 409 PolicyInformation, CertificateSerialNumber, GeneralNames 410 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 411 internet(1) 412 security(5) mechanisms(5) pkix(7)id-mod(0) 413 id-pkix1-implicit(19)}; 415 -- Extended Security Services 417 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 418 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 419 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 420 -- have at least one entry. MAX indicates the upper bound is unspecified. 421 -- Implementations are free to choose an upper bound that suits their 422 -- environment. 424 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 425 -- The contents are formatted as described in [UTF8] 427 -- Section 2.7 429 ReceiptRequest ::= SEQUENCE { 430 signedContentIdentifier ContentIdentifier, 431 receiptsFrom ReceiptsFrom, 432 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } 434 ub-receiptsTo INTEGER ::= 16 436 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 437 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 439 ContentIdentifier ::= OCTET STRING 441 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 442 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 444 ReceiptsFrom ::= CHOICE { 445 allOrFirstTier [0] AllOrFirstTier, 446 -- formerly "allOrNone [0]AllOrNone" 447 receiptList [1] SEQUENCE OF GeneralNames } 449 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 450 allReceipts (0), 451 firstTierRecipients (1) } 453 -- Section 2.8 455 Receipt ::= SEQUENCE { 456 version ESSVersion, 457 contentType ContentType, 458 signedContentIdentifier ContentIdentifier, 459 originatorSignatureValue OCTET STRING } 461 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 462 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 464 ESSVersion ::= INTEGER { v1(1) } 466 -- Section 2.9 468 ContentHints ::= SEQUENCE { 469 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 470 contentType ContentType } 472 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 473 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 475 -- Section 2.10 477 MsgSigDigest ::= OCTET STRING 478 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 479 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 481 -- Section 2.11 483 ContentReference ::= SEQUENCE { 484 contentType ContentType, 485 signedContentIdentifier ContentIdentifier, 486 originatorSignatureValue OCTET STRING } 488 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 489 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 491 -- Section 3.2 493 ESSSecurityLabel ::= SET { 494 security-policy-identifier SecurityPolicyIdentifier, 495 security-classification SecurityClassification OPTIONAL, 496 privacy-mark ESSPrivacyMark OPTIONAL, 497 security-categories SecurityCategories OPTIONAL } 499 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 500 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 502 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 504 SecurityClassification ::= INTEGER { 505 unmarked (0), 506 unclassified (1), 507 restricted (2), 508 confidential (3), 509 secret (4), 510 top-secret (5) } (0..ub-integer-options) 512 ub-integer-options INTEGER ::= 256 514 ESSPrivacyMark ::= CHOICE { 515 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 516 utf8String UTF8String (SIZE (1..MAX)) 517 } 519 ub-privacy-mark-length INTEGER ::= 128 521 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 522 SecurityCategory 524 ub-security-categories INTEGER ::= 64 525 SecurityCategory ::= SEQUENCE { 526 type [0] OBJECT IDENTIFIER, 527 value [1] ANY DEFINED BY type 528 } 530 --Note: The aforementioned SecurityCategory syntax produces identical 531 --hex encodings as the following SecurityCategory syntax that is 532 --documented in the X.411 specification: 533 -- 534 --SecurityCategory ::= SEQUENCE { 535 -- type [0] SECURITY-CATEGORY, 536 -- value [1] ANY DEFINED BY type } 537 -- 538 --SECURITY-CATEGORY MACRO ::= 539 --BEGIN 540 --TYPE NOTATION ::= type | empty 541 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 542 --END 544 -- Section 3.4 546 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 548 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 549 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 551 -- Section 4.4 553 MLExpansionHistory ::= SEQUENCE 554 SIZE (1..ub-ml-expansion-history) OF MLData 556 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 557 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 559 ub-ml-expansion-history INTEGER ::= 64 561 MLData ::= SEQUENCE { 562 mailListIdentifier EntityIdentifier, 563 expansionTime GeneralizedTime, 564 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 566 EntityIdentifier ::= CHOICE { 567 issuerAndSerialNumber IssuerAndSerialNumber, 568 subjectKeyIdentifier SubjectKeyIdentifier } 570 MLReceiptPolicy ::= CHOICE { 571 none [0] NULL, 572 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 573 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 575 -- Section 5.4 577 SigningCertificate ::= SEQUENCE { 578 certs SEQUENCE OF ESSCertID, 579 policies SEQUENCE OF PolicyInformation OPTIONAL 580 } 582 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 583 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 584 smime(16) id-aa(2) 12 } 586 SigningCertificateV2 ::= SEQUENCE { 587 certs SEQUENCE OF ESSCertIDv2, 588 policies SEQUENCE OF PolicyInformation OPTIONAL 589 } 591 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 592 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 593 smime(16) id-aa(2) 47 } 595 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 596 country(16) us(840) organization(1) gov(101) 597 csor(3) nistalgorithm(4) hashalgs(2) 1 } 599 ESSCertIDv2 ::= SEQUENCE { 600 hashAlgorithm AlgorithmIdentifier 601 DEFAULT {algorithm id-sha256 parameters NULL}, 602 certHash Hash, 603 issuerSerial IssuerSerial OPTIONAL 604 } 606 ESSCertID ::= SEQUENCE { 607 certHash Hash, 608 issuerSerial IssuerSerial OPTIONAL 609 } 611 Hash ::= OCTET STRING 613 IssuerSerial ::= SEQUENCE { 614 issuer GeneralNames, 615 serialNumber CertificateSerialNumber 616 } 618 END -- of ExtendedSecurityServices-2006 619 Author's Address 621 Jim Schaad 622 Soaring Hawk Consulting 623 PO Box 675 624 Gold Bar, WA 98251 626 Phone: (425) 785-1031 627 Email: jimsch@exmsft.com 629 Full Copyright Statement 631 Copyright (C) The Internet Society (2007). 633 This document is subject to the rights, licenses and restrictions 634 contained in BCP 78, and except as set forth therein, the authors 635 retain all their rights. 637 This document and the information contained herein are provided on an 638 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 639 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 640 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 641 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 642 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 643 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 645 Intellectual Property 647 The IETF takes no position regarding the validity or scope of any 648 Intellectual Property Rights or other rights that might be claimed to 649 pertain to the implementation or use of the technology described in 650 this document or the extent to which any license under such rights 651 might or might not be available; nor does it represent that it has 652 made any independent effort to identify any such rights. Information 653 on the procedures with respect to rights in RFC documents can be 654 found in BCP 78 and BCP 79. 656 Copies of IPR disclosures made to the IETF Secretariat and any 657 assurances of licenses to be made available, or the result of an 658 attempt made to obtain a general license or permission for the use of 659 such proprietary rights by implementers or users of this 660 specification can be obtained from the IETF on-line IPR repository at 661 http://www.ietf.org/ipr. 663 The IETF invites any interested party to bring to its attention any 664 copyrights, patents or patent applications, or other proprietary 665 rights that may cover technology that may be required to implement 666 this standard. Please address the information to the IETF at 667 ietf-ipr@ietf.org. 669 Acknowledgment 671 Funding for the RFC Editor function is provided by the IETF 672 Administrative Support Activity (IASA).