idnits 2.17.1 draft-turner-km-attributes-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1885 has weird spacing: '...alue of the k...' -- The document date (December 18, 2013) is 3772 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2916 -- Looks like a reference, but probably isn't: '2' on line 2917 -- Looks like a reference, but probably isn't: '0' on line 2914 -- Looks like a reference, but probably isn't: '3' on line 2918 -- Looks like a reference, but probably isn't: '4' on line 2760 -- Looks like a reference, but probably isn't: '5' on line 2775 -- Looks like a reference, but probably isn't: '6' on line 2776 -- Looks like a reference, but probably isn't: '7' on line 2787 -- Looks like a reference, but probably isn't: '8' on line 2788 == Missing Reference: 'RFC6010' is mentioned on line 2443, but not defined == Outdated reference: A later version (-07) exists of draft-housley-ct-keypackage-receipt-n-error-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Timmel 3 Internet-Draft National Security Agency 4 Intended Status: Informational R. Housley 5 Expires: June 21, 2014 Vigil Security 6 S. Turner 7 IECA 8 December 18, 2013 10 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes 11 draft-turner-km-attributes-02.txt 13 Abstract 15 This document defines key management attributes used by the National 16 Security Agency (NSA). The attributes can appear in asymmetric 17 and/or symmetric key packages as well as the Cryptographic Message 18 Syntax (CMS) content types that subsequently envelope the key 19 packages. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 Copyright and License Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 50 ID NSA's CMS Key Management Attributes December 18, 2013 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Attribute Locations . . . . . . . . . . . . . . . . . . . . 3 58 1.2. ASN.1 Notation . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. CMS-Defined Attributes . . . . . . . . . . . . . . . . . . . . 5 61 3. Community Identifiers . . . . . . . . . . . . . . . . . . . . . 6 62 4. Key Province Attribute . . . . . . . . . . . . . . . . . . . . 7 63 5. Binary Signing Time . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. User Certificate . . . . . . . . . . . . . . . . . . . . . . . 10 67 9. Key Package Receivers . . . . . . . . . . . . . . . . . . . . . 10 68 10. TSEC Nomenclature . . . . . . . . . . . . . . . . . . . . . . 12 69 11. Key Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 12. Key Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 13. Transport Key . . . . . . . . . . . . . . . . . . . . . . . . 19 72 14. Key Distribution Period . . . . . . . . . . . . . . . . . . . 19 73 15. Key Validity Period . . . . . . . . . . . . . . . . . . . . . 21 74 16. Key Duration . . . . . . . . . . . . . . . . . . . . . . . . . 22 75 17. Classification . . . . . . . . . . . . . . . . . . . . . . . . 23 76 17.1. Security Label . . . . . . . . . . . . . . . . . . . . . . 24 77 18. Split Key Identifier . . . . . . . . . . . . . . . . . . . . . 27 78 19. Key Package Type . . . . . . . . . . . . . . . . . . . . . . . 28 79 20. Signature Usage . . . . . . . . . . . . . . . . . . . . . . . 29 80 21. Other Certificate Format . . . . . . . . . . . . . . . . . . . 31 81 22. PKI Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 82 23. Useful Certificates . . . . . . . . . . . . . . . . . . . . . 33 83 24. Key Wrap Algorithm . . . . . . . . . . . . . . . . . . . . . . 34 84 25. Content Decryption Key Identifier . . . . . . . . . . . . . . 34 85 25.1. Content Decryption Key Identifier: Symmetric Key and 86 Symmetric Key Package . . . . . . . . . . . . . . . . . . 35 87 25.2. Content Decryption Key Identifier: Unprotected . . . . . . 35 88 26. Certificate Pointers . . . . . . . . . . . . . . . . . . . . . 36 89 27. CRL Pointers . . . . . . . . . . . . . . . . . . . . . . . . . 36 90 28. Key Package Identifier and Receipt Request . . . . . . . . . . 37 91 29. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 37 92 30. Processing Key Package Attribute Values and CMS Content 93 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 38 94 31. Attribute Scope . . . . . . . . . . . . . . . . . . . . . . . 39 95 32. Security Considerations . . . . . . . . . . . . . . . . . . . 45 96 33. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 97 34. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 98 34.1 Normative References . . . . . . . . . . . . . . . . . . . 46 99 34.2 Informative References . . . . . . . . . . . . . . . . . . 48 101 ID NSA's CMS Key Management Attributes December 18, 2013 103 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 49 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65 106 1. Introduction 108 This document defines key management attributes used by the National 109 Security Agency (NSA). The attributes can appear in asymmetric 110 and/or symmetric key packages as well as the Cryptographic Message 111 Syntax (CMS) content types that subsequently envelope the key 112 packages. 114 1.1. Attribute Locations 116 There are a number of CMS content types that support attributes 117 SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData 118 [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData 119 [RFC5083] as well as ContentWithAttributes [RFC4073]. There are also 120 a number of other content types defined with CONTENT-TYPE [RFC6268] 121 that support attributes including AsymmetricKeyPackage [RFC5958] and 122 SymmetricKeyPackage [RFC6031]. 124 There are also different kinds of attributes in these content types: 126 o SignedData supports two kinds of attributes: signed and unsigned 127 attributes in the signedAttrs and unsignedAttrs fields, 128 respectively. 130 o EnvelopedData and EncryptedData each support one kind of 131 attribute: unprotected attributes in the unprotectedAttrs field. 133 o AuthenticatedData and AuthEnvelopedData each support two kinds of 134 attributes: authenticated and unauthenticated attributes in the 135 authAttrs and unauthAttrs fields, respectively. In 136 AuthEnvelopedData both attributes are also unprotected; 137 therefore, when specifically referring to AuthEnvelopedData 138 attributes they are authenticated/unprotected and 139 unauthenticated/unprotected. For this specification, 140 unauthenticated attributes MUST be omitted. 142 o ContentWithAttributes supports one kind of attribute: content 143 attributes in the attrs field. 145 o AsymmetricKeyPacakge supports one kind of attribute: asymmetric 146 key attributes in the attributes field. If an attribute appears 147 as part of an asymmetric key package, it SHOULD appear in the 148 attributes field of the AsymmetricKeyPackage. 150 ID NSA's CMS Key Management Attributes December 18, 2013 152 o SymmetricKeyPackage supports two kinds of attributes: symmetric 153 key and symmetric key package attributes in the sKeyAttrs and 154 sKeyPkgAttrs fields, respectively. Note that [RFC6031] prohibits 155 the same attribute from appearing in both locations in the same 156 SymmetricKeyPackage. 158 1.2. ASN.1 Notation 160 The attributes defined in this document use 2002 ASN.1 161 [X.680][X.681][X.682][X.683]. The attributes MUST be DER [X.690] 162 encoded. 164 Each of the attributes has a single attribute value instance in the 165 values set. Even though the syntax is defined as a set, there MUST 166 be exactly one instance of AttributeValue present. Further, the 167 SignedAttributes, UnsignedAttributes, UnprotectedAttributes, 168 AuthAttributes, and UnauthAttributes are also defined as a set, and 169 this set MUST include only one instance of any particular type of 170 attribute. That is, any object identifier appearing in AttributeType 171 MUST only appear one time in the set of attributes. 173 SignedData, EnvelopedData, EncryptedData, AuthenticatedData, 174 AuthEnvelopedData, and ContentWithAttributes were originally defined 175 using the 1988 version of ASN.1. These definitions were updated to 176 the 2008 version of ASN.1 by [RFC6268]. None of the new 2008 ASN.1 177 tokens are used, which allows 2002 compilers to compile 2008 ASN.1. 178 AsymmetricKeyPackage and SymmetricKeyPackage are defined using the 179 2002 ASN.1. 181 [RFC5652] and [RFC2634] define generally useful attributes for CMS 182 using the 1988 version of ASN.1. These definitions were updated to 183 the 2008 version of ASN.1 by [RFC6268] and the 2002 version of ASN.1 184 by [RFC5911], respectively. [RFC4108] and [RFC6019] also defined 185 attributes using the 1988 version of ASN.1, which this document uses. 186 Both were updated by [RFC5911] to the 2002 ASN.1. Refer to 187 [RFC2634], [RFC4108], [RFC5652], and [RFC6019] for the attribute's 188 semantics but refer to [RFC5911] or [RFC6268] for the attribute's 189 ASN.1 syntax. 191 1.3. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in RFC 196 2119 [RFC2119]. 198 CMS Protecting Content Types: SignedData [RFC5652], EnvelopedData 199 [RFC5652], EncryptedData [RFC5652], AuthenticatedData [RFC5652], and 201 ID NSA's CMS Key Management Attributes December 18, 2013 203 AuthEnvelopedData [RFC5083] are referred to as CMS protecting content 204 types because they provide some type of security service. While 205 ContentWithAttributes [RFC4073] and ContentCollection [RFC4073] are 206 CMS content types that provide no security service. 208 Attribute Scope: The scope of an attribute is the compilation of 209 keying material to which the attribute value is assigned. The scope 210 of each attribute is determined by its placement within the key 211 package or content collection. See Section 31. 213 SIR: Sender-Intermediary-Receiver is a model with three entities: 215 o A sender initiates the delivery of a key to one or more 216 receivers. It may wrap or encrypt the key for delivery. This is 217 expected to be the common case, since cleartext key is vulnerable 218 to exposure and compromise. If the sender is to encrypt the key 219 for delivery, it must know how to encrypt the key so that the 220 receiver(s) can decrypt it. A sender may also carry out any of 221 the functions of an intermediary. 223 * The original key package creators are sometimes referred to as 224 key source authorities. These entities create the symmetric 225 and/or asymmetric key package and apply the initial CMS 226 protecting layer, which is normally a SignedData but sometimes 227 an AuthenticatedData. This initial CMS protecting layer is 228 maintained through any intermediary for the receivers of the 229 key package to ensure that receivers can validate the key 230 source authority. 232 o An intermediary does not have access to cleartext key. An 233 intermediary may perform source authentication on key packages, 234 and may append or remove management information related to the 235 package. It may encapsulate the encrypted key packages in larger 236 packages that contain other user data destined for later 237 intermediaries or receivers. 239 o A receiver has access to cleartext key. If the received key 240 package is encrypted, it can unwrap or decrypt the encrypted key 241 to obtain the cleartext key. A receiver may be the final 242 destination of the cryptographic product. An element that acts 243 as a receiver and is not the final destination of the key package 244 may also act as a sender. After receiving a key, a receiver may 245 encrypt the received key for local storage. 247 2. CMS-Defined Attributes 249 The following attributes are defined for [RFC5652]: 251 ID NSA's CMS Key Management Attributes December 18, 2013 253 o content-type [RFC5652][RFC6268] uniquely specifies the CMS 254 content type. It MUST be included as signed, authenticated, and 255 authenticated/unprotected attributes. 257 o message-digest [RFC5652][RFC6268] is the message digest of the 258 encapsulated content calculated using the signer's message digest 259 algorithm. It MUST be included as signed and authenticated 260 attributes and SHOULD NOT be included as an 261 authenticated/unprotected attribute. 263 o content-hints [RFC2634][RFC6268] identifies the innermost content 264 when multiple layers of encapsulation have been applied. It MUST 265 be included in every instance of SignedData, AuthenticatedData, 266 and AuthEnvelopedData that does not directly encapsulate a 267 SymmetricKeyPackage, an AsymmetricKeyPackage, or an 268 EncryptedKeyPackage [RFC6032]. 270 3. Community Identifiers 272 The community-identifiers [RFC4108][RFC5911] attribute lists the 273 communities that are authorized recipients of the signed content. It 274 can appear as a signed, authenticated, authenticated/unprotected, or 275 content attribute. This attribute MUST be supported. 277 The 2002 ASN.1 syntax for the community-identifier attribute is 278 included for convenience: 280 aa-communityIdentifiers ATTRIBUTE ::= { 281 TYPE CommunityIdentifiers 282 IDENTIFIED BY id-aa-communityIdentifiers } 284 id-aa-communityIdentifiers OBJECT IDENTIFIER ::= { 285 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 286 smime(16) aa(2) 40 } 288 CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier 290 CommunityIdentifier ::= CHOICE { 291 communityOID OBJECT IDENTIFIER, 292 hwModuleList HardwareModules } 294 HardwareModules ::= SEQUENCE { 295 hwType OBJECT IDENTIFIER, 296 hwSerialEntries SEQUENCE OF HardwareSerialEntry } 298 HardwareSerialEntry ::= CHOICE { 299 all NULL, 300 single OCTET STRING, 302 ID NSA's CMS Key Management Attributes December 18, 2013 304 block SEQUENCE { 305 low OCTET STRING, 306 high OCTET STRING } } 308 Consult [RFC4108] for the attribute's semantics. 310 4. Key Province Attribute 312 The key-province-v2 attribute identifies the scope, range, or 313 jurisdiction in which the key is to be used. The key-province-v2 314 attribute MUST be present as a signed attribute or an authenticated 315 attribute in the innermost CMS protection content type that provides 316 authentication (i.e., SignedData, AuthEnvelopedData, or 317 AuthenticatedData) and encapsulates a symmetric key package or an 318 asymmetric key package. 320 The key-province attribute has the following syntax: 322 aa-keyProvince-v2 ATTRIBUTE ::= { 323 TYPE KeyProvinceV2 324 IDENTIFIED BY id-aa-KP-keyProvinceV2 } 326 id-aa-KP-keyProvinceV2 OBJECT IDENTIFIER ::= 327 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 328 dod(2) infosec(1) attributes(5) 71 } 330 KeyProvinceV2 ::= OBJECT IDENTIFIER 332 5. Binary Signing Time 334 The binary-signing-time [RFC6019][RFC6268] attribute specifies the 335 time at which the signature or the message authentication code was 336 applied to the encapsulated content. It can appear as a signed, 337 authenticated, or authenticated/unprotected attribute. 339 The 2002 ASN.1 syntax is included for convenience: 341 aa-binarySigningTime ATTRIBUTE ::= { 342 TYPE BinarySigningTime 343 IDENTIFIED BY id-aa-binarySigningTime } 345 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { 346 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 347 smime(16) aa(2) 46 } 349 BinarySigningTime ::= BinaryTime 351 BinaryTime ::= INTEGER (0..MAX) 353 ID NSA's CMS Key Management Attributes December 18, 2013 355 Consult [RFC6019] for the binary-signing-time attribute's semantics. 357 6. Manifest 359 The manifest attribute lists the short titles of all the TSEC- 360 Nomenclature attributes from inner key packages. It MUST only appear 361 as an outer-most signed, authenticated, or authenticated/unprotected 362 attribute. If a short title is repeated in inner packages, it need 363 only appear once in the manifest attribute. The manifest attribute 364 MUST NOT appear in the same level as the TSEC-Nomenclature from the 365 Section 10. 367 The manifest attribute has the following syntax: 369 aa-manifest ATTRIBUTE ::= { 370 TYPE Manifest 371 IDENTIFIED BY id-aa-KP-manifest } 373 id-aa-KP-manifest OBJECT IDENTIFIER ::= { 374 joint-iso-itu-t(2) country(16) us(840) organization(1) 375 gov(101) dod(2) infosec(1) attributes(5) 72 } 377 Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle 379 7. Key Algorithm 381 The key-algorithm attribute indirectly specifies the size and format 382 of the keying material in the skey field of a symmetric key package. 383 It can appear as a symmetric key, symmetric key package, signed, 384 authenticated, authenticated/unprotected, or content attribute. If 385 this attribute appears as a signed attribute, then all of the keying 386 material within the SignedData content MUST be associated with the 387 same algorithm. If this attribute appears as an authenticated or 388 authenticated/unprotected attribute, then all of the keying material 389 within the AuthenticatedData or AuthEnvelopedData content type MUST 390 be associated with the same algorithm. If this attribute appears as 391 a content attribute, then all of the keying material within the 392 collection MUST be associated with the same algorithm. If both the 393 key-algorithm and key-wrap-algorithm attributes apply from the 394 Section 24 to an sKey, then the key-algorithm attribute refers to the 395 decrypted value of sKey rather than to the content of sKey itself. 396 This attribute MUST be supported. 398 ID NSA's CMS Key Management Attributes December 18, 2013 400 The key-algorithm attribute has the following syntax: 402 aa-keyAlgorithm ATTRIBUTE ::= { 403 TYPE KeyAlgorithm 404 IDENTIFIED BY id-kma-keyAlgorithm } 406 id-kma-keyAlgorithm OBJECT IDENTIFIER ::= { 407 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 408 dod(2) infosec(1) keying-material-attributes(13) 1 } 410 KeyAlgorithm ::= SEQUENCE { 411 keyAlg OBJECT IDENTIFIER, 412 checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL, 413 crcAlg [2] OBJECT IDENTIFIER OPTIONAL } 415 The fields in the key-algorithm attribute have the following 416 semantics: 418 o keyAlg specifies the size and format of the keying material. 420 o If the particular key format supports more than one check word 421 algorithm, then the OPTIONAL checkWordAlg identifier indicates 422 which check word algorithm was used to generate the check word 423 that is present. If the check word algorithm is implied by the 424 key algorithm, then the checkWordAlg field SHOULD be omitted. 426 o If the particular key format supports more than one Cyclic 427 Redundancy Check (CRC) algorithm, then the OPTIONAL crcAlg 428 identifier indicates which CRC algorithm was used to generate the 429 value that is present. If the CRC algorithm is implied by the 430 key algorithm, then the crcAlg field SHOULD be omitted. 432 The keyAlg identifier, the checkWordAlg identifier, and the crcAlg 433 identifier are object identifiers. The use of an object identifier 434 accommodates any algorithm from any registry. 436 The format of the keying material in the skey field of a symmetric 437 key package will not match this attribute if the keying material is 438 split. In this situation, this attribute identifies the format of 439 the keying material once the two splits are combined. See section 18 440 for a discussion on the split-identifier attribute. Due to multiple 441 layers of encapsulation or the use of content collections, the key- 442 algorithm attribute can appear in more than one location in the 443 overall key package. When there are multiple occurrences of the key- 444 algorithm attribute within the same scope, the keyAlg field MUST 445 match in all instances. The OPTIONAL checkWordAlg and crcAlg fields 446 can be omitted in the key-algorithm attribute when it appears as a 447 signed, authenticated, authenticated/unprotected, or content 449 ID NSA's CMS Key Management Attributes December 18, 2013 451 attribute. However, if these optional fields are present, they MUST 452 also match the other occurrences within the same scope. Receivers 453 MUST reject any key package that fails these consistency checks. 455 8. User Certificate 457 The user-certificate attribute specifies the type, format, and value 458 of an X.509 certificate and is used in asymmetric key package's 459 attributes field. This attribute can appear as an asymmetric key 460 attribute. This attribute MUST NOT appear in an asymmetric key 461 package attributes field that includes the other-certificate-formats 462 attribute. Symmetric key packages do not contain any certificates, 463 so the user-certificate attribute MUST NOT appear in a symmetric key 464 package. The user-certificate attribute MUST NOT appear as a signed, 465 authenticated, authenticated/unprotected, or content attribute. This 466 attribute MUST be supported. 468 The syntax is taken from [X.509] but redefined using the ATTRIBUTE 469 CLASS from [RFC5911]. The user-certificate attribute has the 470 following syntax: 472 aa-userCertificate ATTRIBUTE ::= { 473 TYPE Certificate 474 EQUALITY MATCING RULE certificateExactMatch 475 IDENTIFIED BY id-at-userCertificate } 477 id-at-userCertificate OBJECT IDENTIFIER ::= { 478 joint-iso-itu-t(2) ds(5) attributes(4) 36 } 480 Since the user-certificate attribute MUST NOT appear as a signed, 481 authenticated, authenticated/unprotected, or content attribute, an 482 asymmetric key package cannot include multiple occurrences of the 483 user-certificate attribute within the same scope. Receivers MUST 484 reject any asymmetric key package in which the user-certificate 485 attribute appears as a signed, authenticated, 486 authenticated/unprotected, or content attribute. 488 9. Key Package Receivers 490 The key-package-receivers-v2 attribute indicates the intended 491 audience for the key package. The key-package-receivers-v2 attribute 492 is not intended for access control decisions, rather intermediate 493 systems may use this attribute to make routing and relaying 494 decisions. The receiver SHOULD reject the key package if the key- 495 package-receivers-v2 attribute is present and they are not listed as 496 an intended receiver. The key-package-receivers-v2 attribute can be 497 used as a signed, authenticated, authenticated/unprotected, or 498 content attribute. If key-package-receivers-v2 attribute is 500 ID NSA's CMS Key Management Attributes December 18, 2013 502 associated with a collection, then the named receivers MUST be able 503 to receive all of the key packages within the collection. This 504 attribute MUST be supported. 506 The key-package-receivers-v2 attribute has the following syntax: 508 aa-keyPackageReceivers-v2 ATTRIBUTE ::= { 509 TYPE KeyPkgReceiversV2 510 IDENTIFIED BY id-kma-keyPkgReceiversV2 } 512 id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= { 513 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 514 dod(2) infosec(1) keying-material-attributes(13) 16 } 516 KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver 518 KeyPkgReceiver ::= CHOICE { 519 sirEntity [0] SIREntityName, 520 community [1] CommunityIdentifier } 522 The key-package-receivers-v2 attribute contains a list of receiver 523 identifiers. The receiver identifier is either a SIREntityName 524 [ID.housley-keypackage-receipt-n-error] or a CommunityIdentifier (see 525 Section 3). The SIREntityName syntax does not impose any particular 526 structure on the receiver identifier, but it does require 527 registration of receiver identifier types. The nameType ensures that 528 two receiver identifiers of different types that contain the same 529 values are not interpreted as equivalent. Name types are expected to 530 be defined that represent several different granularities. For 531 example, one name type will represent the receiver organization. At 532 a finer granularity, the name type will identify a specific 533 cryptographic device, perhaps using a manufacturer identifier and 534 serial number. 536 If a receiver does not recognize a particular nameType or a community 537 identifier, then keying material within the scope of the unrecognized 538 nameType or community identifier MUST NOT be used in any manner. 539 However, the receiver need not discard the associated key package. 540 Since many cryptographic devices are programmable, a different 541 firmware load may recognize the nameType. Likewise, a change in the 542 configuration may lead to the recognition of a previously 543 unrecognized community identifier. Therefore, the receiver may 544 retain the key package, but refuse to use it for anything with a 545 firmware load that does not recognize the nameType or a configuration 546 that does not recognize the community identifier. 548 Whenever a key package is saved for later processing due to an 549 unrecognized nameType or community identifier, subsequent processing 551 ID NSA's CMS Key Management Attributes December 18, 2013 553 MUST NOT rely on any checks that were made the first time the key 554 package processing was attempted. That is, the subsequent processing 555 MUST include the full complement of checks. Further, a receipt for 556 the packages MUST NOT be generated unless all of these checks are 557 successfully completed. 559 Due to multiple layers of encapsulation or the use of content 560 collections, the key-package-receivers-v2 attribute can appear in 561 more than one location in the overall key package. When there are 562 multiple occurrences of the key-package-receivers-v2 attribute, each 563 occurrence is evaluated independently. 565 In a content collection, each member of the collection might contain 566 its own signed, authenticated, authenticated/unprotected, or content 567 attribute that includes a key-package-receivers-v2 attribute. In 568 this situation, each member of the collection is evaluated 569 separately, and any member that includes an acceptable receiver 570 SHOULD be retained. Other members SHOULD be rejected or retained for 571 later processing with a different firmware load. 573 10. TSEC Nomenclature 575 The Telecommunications Security Nomenclature (TSEC-Nomenclature) 576 attribute provides the name for a piece of keying material, which 577 always includes the short title. The TSEC-Nomenclature attribute 578 also contains other identifiers when the short title is insufficient 579 to uniquely name a particular piece of keying material. This 580 attribute can appear as a symmetric key, symmetric key package, 581 asymmetric key, signed, authenticated, authenticated/unprotected, or 582 content attribute. If this attribute appears in the sKeyAttrs field, 583 the EditionID, RegisterID, and SegmentID attribute fields MUST NOT be 584 ranges. If this attribute appears as a signed, authenticated, 585 authenticated/unprotected, or content attribute, all of the keying 586 material within the associated content MUST have the same short 587 title, and the attribute value MUST contain only a short title. That 588 is, when this attribute appears as a signed, authenticated, 589 authenticated/unprotected, or content attribute, all of the optional 590 fields MUST be absent. If this attribute is associated with a 591 collection, all of the keying material within the collection MUST 592 have the same short title; however, the edition, register, and 593 segment identifiers will be different for each key package in the 594 collection. This attribute MUST be supported. 596 The TSEC-Nomenclature attribute has the following syntax: 598 aa-tsecNomenclature ATTRIBUTE ::= { 599 TYPE TSECNomenclature 600 IDENTIFIED BY id-kma-TSECNomenclature } 602 ID NSA's CMS Key Management Attributes December 18, 2013 604 id-kma-TSECNomenclature OBJECT IDENTIFIER ::= { 605 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 606 dod(2) infosec(1) keying-material-attributes(13) 3 } 608 TSECNomenclature ::= SEQUENCE { 609 shortTitle ShortTitle, 610 editionID EditionID OPTIONAL, 611 registerID RegisterID OPTIONAL, 612 segmentID SegmentID OPTIONAL } 614 ShortTitle ::= PrintableString 616 EditionID ::= CHOICE { 617 char CHOICE { 618 charEdition [1] CharEdition, 619 charEditionRange [2] CharEditionRange } 620 num CHOICE { 621 numEdition [3] NumEdition, 622 numEditionRange [4] NumEditionRange } } 624 CharEdition ::= PrintableString 626 CharEditionRange ::= SEQUENCE { 627 firstCharEdition CharEdition, 628 lastCharEdition CharEdition } 630 NumEdition ::= INTEGER (0..308915776) 632 NumEditionRange ::= SEQUENCE { 633 firstNumEdition NumEdition, 634 lastNumEdition NumEdition } 636 RegisterID ::= CHOICE { 637 register [5] Register, 638 registerRange [6] RegisterRange } 640 Register ::= INTEGER (0..2147483647) 642 RegisterRange ::= SEQUENCE { 643 firstRegister Register, 644 lastRegister Register } 646 SegmentID ::= CHOICE { 647 segmentNumber [7] SegmentNumber, 648 segmentRange [8] SegmentRange } 650 SegmentNumber ::= INTEGER (1..127) 652 ID NSA's CMS Key Management Attributes December 18, 2013 654 SegmentRange ::= SEQUENCE { 655 firstSegment SegmentNumber, 656 lastSegment SegmentNumber } 658 The fields in the TSEC-Nomenclature attribute have the following 659 semantics: 661 o The short title consists of up to 32 alphanumeric characters. 662 Short title processing always uses the value in its entirety. 664 o The edition identifier is OPTIONAL, and the edition identifier is 665 used to distinguish accountable items. The edition identifier 666 consists either of six alphanumeric characters or an integer. 667 When present, the edition identifier is either a single value or 668 a range. The integer encoding should be used when it is 669 important to keep key package size to a minimum. 671 o The register identifier is OPTIONAL. For electronic keying 672 material, the register identifier is usually omitted. The 673 register identifier is an accounting number assigned to identify 674 COMSEC material. The register identifier is either a single 675 value or a range. 677 o The segment identifier is OPTIONAL, and it distinguishes the 678 individual symmetric keys delivered in one edition. A unique 679 segment number is assigned to each key in an edition. The 680 segment number is set to one for the first item in each edition, 681 and it is incremented by one for each additional item within that 682 edition. The segment identifier is either a single value or a 683 range. 685 The order that the keying material will appear in the key package is 686 illustrated by the following example. A cryptographic device may 687 require fresh keying material every day. An edition represents the 688 keying material for a single month, and the segments represent the 689 keying material for a day within that month. Consider a key package 690 that contains the keying material for July and August; it will 691 contain keying material for 62 days. The keying material will appear 692 in the following order: Edition 1, Segment 1; Edition 1, Segment 2; 693 Edition 1, Segment 3; ...; Edition 1, Segment 31; Edition 2, Segment 694 1; Edition 2, Segment 2; Edition 2, Segment 3; ...; Edition 2, 695 Segment 31. 697 Due to multiple layers of encapsulation or the use of content 698 collections, the TSEC-Nomenclature attribute can appear in more than 699 one location in the overall key package. When there are multiple 700 occurrences of the TSEC-Nomenclature attribute within the same scope, 701 the shortTitle field MUST match in all instances. Recall that the 703 ID NSA's CMS Key Management Attributes December 18, 2013 705 optional parts MUST be omitted when the TSEC-Nomenclature attribute 706 appears as a signed, authenticated, authenticated/unprotected, or 707 content attribute. Receivers MUST reject any key package that fails 708 these consistency checks. 710 When the manifest attribute from Section 6 is included in an outer 711 layer, the shortTitle field values present in TSEC-Nomenclature 712 attributes MUST be one of the values in the manifest attribute. 713 Receivers MUST reject any key package that fails this consistency 714 checks. 716 11. Key Purpose 718 The key-purpose attribute specifies the intended purpose of the key 719 material. It can appear as a symmetric key, symmetric key package, 720 asymmetric key, signed, authenticated, authenticated/unprotected, or 721 content attribute. If the key-purpose attribute appears as a signed, 722 authenticated, authenticated/unprotected, or content attribute, then 723 all of the keying material within the associated content MUST have 724 the same key purpose value. 726 The key-purpose attribute has the following syntax: 728 aa-keyPurpose ATTRIBUTE ::= { 729 TYPE KeyPurpose 730 IDENTIFIED BY id-kma-keyPurpose } 732 id-kma-keyPurpose OBJECT IDENTIFIER ::= { 733 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 734 dod(2) infosec(1) keying-material-attributes(13) 13 } 736 KeyPurpose ::= ENUMERATED { 737 n-a (0), -- Not Applicable 738 a (65), -- Operational 739 b (66), -- Compatible Multiple Key 740 l (76), -- Logistics Combinations 741 m (77), -- Maintenance 742 r (82), -- Reference 743 s (83), -- Sample 744 t (84), -- Training 745 v (86), -- Developmental 746 x (88), -- Exercise 747 z (90), -- "On the Air" Testing 748 ... -- Expect additional key purpose values -- } 750 Due to multiple layers of encapsulation or the use of content 751 collections, the key-purpose attribute can appear in more than one 752 location in the overall key package. When there are multiple 754 ID NSA's CMS Key Management Attributes December 18, 2013 756 occurrences of the key-purpose attribute within the same scope, all 757 fields within the attribute MUST contain exactly the same values. 758 Receivers MUST reject any key package that fails these consistency 759 checks. 761 12. Key Use 763 The key-use attribute specifies the intended use of the key material. 764 It can appear as a symmetric key, symmetric key package, asymmetric, 765 signed, authenticated, authenticated/unprotected, or content 766 attribute. If the key-use attribute appears as a signed, 767 authenticated, authenticated/unprotected, or content attribute, then 768 all of the keying material within the associated content MUST have 769 the same key use value. 771 The key-use attribute has the following syntax: 773 aa-key-Use ATTRIBUTE ::= { 774 TYPE KeyUse 775 IDENTIFIED BY id-kma-keyUse } 777 id-kma-keyUse OBJECT IDENTIFIER ::= { 778 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 779 dod(2) infosec(1) keying-material-attributes(13) 14 } 781 KeyUse ::= ENUMERATED { 782 n-a (0), -- Not applicable 783 ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format) 784 kek (2), -- Key Encryption Key 785 kpk (3), -- Key Production Key 786 msk (4), -- Message Signature Key 787 qkek (5), -- QUADRANT Key Encryption Key 788 tek (6), -- Traffic Encryption Key 789 tsk (7), -- Transmission Security Key 790 trkek (8), -- Transfer Key Encryption Key 791 nfk (9), -- Netted FIREFLY Key 792 effk (10), -- FIREFLY Key (Enhanced Format) 793 ebfk (11), -- FIREFLY Key (Enhanceable Basic Format) 794 aek (12), -- Algorithm Encryption Key 795 wod (13), -- Word of Day 796 kesk (246), -- Key Establishment Key 797 eik (247), -- Entity Identification Key 798 ask (248), -- Authority Signature Key 799 kmk (249), -- Key Modifier Key 800 rsk (250), -- Revocation Signature Key 801 csk (251), -- Certificate Signature Key 802 sak (252), -- Symmetric Authentication Key 803 rgk (253), -- Random Generation Key 805 ID NSA's CMS Key Management Attributes December 18, 2013 807 cek (254), -- Certificate Encryption Key 808 exk (255), -- Exclusion Key 809 ... -- Expect additional key use values -- } 811 The values for the key-use attribute has the following semantics: 813 o ffk: A FIREFLY/CROSSTALK key is used to establish a Key 814 Establishment Key (KEK) or a Transmission Encryption Key (TEK) 815 between two parties. The KEK or TEK generated from the exchange 816 is used with a symmetric encryption algorithm. This key use 817 value is associated with keys in the basic format. 819 o kek: A Key Encryption Key is used to encrypt or decrypt other 820 keys for transmission or storage. 822 o kpk: A Key Production Key is used to initialize a keystream 823 generator for the production of other electronically generated 824 keys. 826 o msk: A Message Signature Key is used in a digital signature 827 process that operates on a message to assure message source 828 authentication, message integrity, and non-repudiation. 830 o qkek: QUADRANT Key Encryption Key is one part of a tamper 831 resistance solution. 833 o tek: A Traffic Encryption Key is used to encrypt plaintext or to 834 superencrypt previously encrypted data and/or to decrypt 835 ciphertext. 837 o tsk: A Transmission Security Key is used to protect transmissions 838 from interception and exploitation by means other than 839 cryptanalysis. 841 o trkek: Transfer Key Encryption Key. For example, the keys used 842 by the KP and DTD. 844 o nfk: A Netted FIREFLY Key is a FIREFLY key that has an edition 845 number associated with it. When rekeyed, it is incremented, 846 preventing communications with FIREFLY key of previous editions. 847 This edition number is maintained within a universal edition. 849 o effk: Enhanced FIREFLY Key is used to establish a KEK or a TEK 850 between two parties. The KEK or TEK generated from an exchange 851 is used with a symmetric encryption algorithm. This key use 852 value is associated with keys in the enhanced format. 854 o ebfk: Enhanceable Basic FIREFLY Key is used to establish a KEK or 856 ID NSA's CMS Key Management Attributes December 18, 2013 858 a TEK between two parties. The KEK or TEK generated from an 859 exchange is used with a symmetric encryption algorithm. This key 860 use value is associated with keys in the enhanceable basic 861 format. 863 o aek: An Algorithm Encryption Key is used to encrypt or decrypt an 864 algorithm implementation as well as other functionality in the 865 implementation. 867 o wod: A key used to generate the Word of the Day (WOD). 869 o kek: A Key Establishment Key is an asymmetric key set (e.g. 870 public/private/parameters) used to enable the establishment of 871 symmetric key(s) between entities. 873 o eik: An Entity Identification Key is an asymmetric key set (e.g. 874 public/private/parameters) used to identify one entity to another 875 for access control and other similar purposes. 877 o ask: An Authority Signature Key is an asymmetric key set (e.g. 878 public/private/parameters) used by designated authorities to sign 879 objects such as TAMP messages and firmware packages. 881 o kmk: A Key Modifier Key is a symmetric key used to modify the 882 results of the process that forms a symmetric key from a public 883 key exchange process. 885 o rsk: A Revocation Signature Key is an asymmetric key set (e.g. 886 public/private/parameters) used to sign and authenticate 887 revocation lists and compromised key lists. 889 o csk: A Certificate Signature Key is an asymmetric key set (e.g. 890 public/private/parameters) used to sign and authenticate public- 891 key certificates. 893 o sak: A Symmetric Authentication Key is used in a Message 894 Authentication Code (MAC) algorithm to provide message integrity. 895 Differs from a Message Signature Key in that it is symmetric key 896 material and it does not provide source authentication or non- 897 repudiation. 899 o rgk: Random Generation Key is a key used to seed a deterministic 900 pseudo-random number generator. 902 o cek: A Certificate Encryption Key is used to encrypt public-key 903 certificates to support privacy. 905 o exk: An Exclusion Key is a symmetric key used to 907 ID NSA's CMS Key Management Attributes December 18, 2013 909 cryptographically subdivide a single large security domain into 910 smaller segregated domains. 912 Due to multiple layers of encapsulation or the use of content 913 collections, the key-use attribute can appear in more than one 914 location in the overall key package. When there are multiple 915 occurrences of the key-use attribute within the same scope, all 916 fields within the attribute MUST contain exactly the same values. 917 Receivers MUST reject any key package that fails these consistency 918 checks. 920 13. Transport Key 922 The transport-key attribute identifies whether an asymmetric key is a 923 transport key or an operational key (i.e., the key can either be used 924 as is or not). It can appear as an asymmetric key, signed, 925 authenticated, authenticated/unprotected, or content attribute. If 926 the transport-key attribute appears as a signed, authenticated, 927 authenticated/unprotected, or content attribute, then all of the 928 keying material within the associated content MUST have the same 929 operational/transport key material. 931 aa-transportKey ATTRIBUTE ::= { 932 TYPE TransOp 933 IDENTIFIED BY id-kma-transportKey } 935 id-kma-transportKey OBJECT IDENTIFIER ::= { 936 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 937 dod(2) infosec(1) keying-material-attributes(13) 15 } 939 TransOp ::= ENUMERATED { 940 transport (1), 941 operational (2) } 943 Due to multiple layers of encapsulation or the use of content 944 collections, the transport-key attribute can appear in more than one 945 location in the overall key package. When there are multiple 946 occurrences of the transport-key attribute within the same scope, all 947 fields within the attribute MUST contain exactly the same values. 948 Receivers MUST reject any key package that fails these consistency 949 checks. 951 14. Key Distribution Period 953 The key-distribution-period attribute indicates the period of time 954 that the keying material is intended for distribution. Keying 955 material is often distributed before it is intended to be used. Time 956 of day must be represented in Coordinated Universal Time (UTC). It 958 ID NSA's CMS Key Management Attributes December 18, 2013 960 can appear as a symmetric key, symmetric key package, asymmetric key, 961 signed, authenticated, authenticated/unprotected, or content 962 attribute. If the key-distribution-period attribute appears as a 963 signed, authenticated, authenticated/unprotected, or content 964 attribute, then all of the keying material within the content MUST 965 have the same key distribution period. 967 The key-distribution-period attribute has the following syntax: 969 aa-keyDistributionPeriod ATTRIBUTE ::= { 970 TYPE KeyDistPeriod 971 IDENTIFIED BY id-kma-keyDistPeriod } 973 id-kma-keyDistPeriod OBJECT IDENTIFIER ::= { 974 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 975 dod(2) infosec(1) keying-material-attributes(13) 5 } 977 KeyDistPeriod ::= SEQUENCE { 978 doNotDistBefore [0] BinaryTime OPTIONAL, 979 doNotDistAfter BinaryTime } 981 BinaryTime ::= INTEGER 983 The fields in the key-distribution-period attribute have the 984 following semantics: 986 o The doNotDistBefore field is OPTIONAL, and when it is present, 987 the keying material SHOULD NOT be distributed before the date and 988 time provided. 990 o The doNotDistAfter field is REQUIRED, and the keying material 991 SHOULD NOT be distributed after the date and time provided. 993 When the key-distribution-period attribute is associated with a 994 collection of keying material, the distribution period applies to all 995 of the keys in the collection. None of the keying material in the 996 collection SHOULD be distributed outside the indicated period. 998 Due to multiple layers of encapsulation or the use of content 999 collections, the key-distribution-period attribute can appear in more 1000 than one location in the overall key package. When there are 1001 multiple occurrences of the key-distribution-period attribute within 1002 the same scope, all of the included attribute fields MUST contain 1003 exactly the same value. However, if the doNotDistBefore field is 1004 absent in an inner layer, a value MAY appear in an outer layer. 1005 Receivers MUST reject any key package that fails these consistency 1006 checks. 1008 ID NSA's CMS Key Management Attributes December 18, 2013 1010 15. Key Validity Period 1012 The key-validity-period attribute indicates the period of time that 1013 the keying material is intended for use. Time of day MUST be 1014 represented in Coordinated Universal Time (UTC). It can appear as a 1015 symmetric key, symmetric key package, asymmetric key, signed, 1016 authenticated, authenticated/unprotected, or content attribute. If 1017 the key-validity-period attribute appears as a signed, authenticated, 1018 authenticated/unprotected, or content attribute, then all of the 1019 keying material within the content MUST have the same key validity 1020 period. 1022 The key-validity-period attribute has the following syntax: 1024 aa-keyValidityPeriod ATTRIBUTE ::= { 1025 TYPE KeyValidityPeriod 1026 IDENTIFIED BY id-kma-keyValidityPeriod } 1028 id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= { 1029 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1030 dod(2) infosec(1) keying-material-attributes(13) 6 } 1032 KeyValidityPeriod ::= SEQUENCE { 1033 doNotUseBefore BinaryTime, 1034 doNotUseAfter BinaryTime OPTIONAL } 1036 BinaryTime ::= INTEGER 1038 The fields in the key-distribution-period attribute have the 1039 following semantics: 1041 o The doNotUseBefore field is required, and the keying material 1042 should not be used before the date and time provided. 1044 o The doNotUseAfter field is optional, and when it is present, the 1045 keying material should not be used after the date and time 1046 provided. 1048 For a key package that is being used for rekey, the doNotUseAfter 1049 field MAY be required even though the syntax is OPTIONAL. 1051 When the key-validity-period attribute is associated with a 1052 collection of keying material, the validity period applies to all of 1053 the keys in the collection. None of the keying material in the 1054 collection SHOULD be used outside the indicated period. The key- 1055 validity-period attribute described in this section and the key- 1056 duration attribute described in the next section provide a 1057 complementary function. The key-validity-period attribute provides 1059 ID NSA's CMS Key Management Attributes December 18, 2013 1061 explicit date and time values, which indicate the beginning and 1062 ending of the keying material usage period. The key-duration 1063 attribute provides the maximum length of time that the keying 1064 material SHOULD be used. If both attributes are provided, this 1065 duration MAY occur at any time within the specified period, but the 1066 limits imposed by both attributes SHOULD be honored. 1068 Due to multiple layers of encapsulation or the use of content 1069 collections, the key-validity-period attribute can appear in more 1070 than one location in the overall key package. When there are 1071 multiple occurrences of the key-validity-period attribute within the 1072 same scope, all of the included attribute fields MUST contain exactly 1073 the same value. However, if the doNotUseAfter field is absent in an 1074 inner layer, a value MAY appear in an outer layer. Receivers MUST 1075 reject any key package that fails these consistency checks. 1077 16. Key Duration 1079 The key-duration attribute indicates the maximum period of time that 1080 the keying material is intended for use. The date and time that the 1081 duration begins is not specified, but the maximum amount of time that 1082 the keying material can be used to provide security services is 1083 specified. It can appear as a symmetric key, symmetric key package, 1084 asymmetric key, signed, authenticated, authenticated/unprotected, or 1085 content attribute. If the key-duration attribute appears as a 1086 signed, authenticated, authenticated/unprotected, or content 1087 attribute, then all of the keying material within the content MUST 1088 have the same key duration. 1090 The key-duration attribute has the following syntax: 1092 aa-keyDurationPeriod ATTRIBUTE ::= { 1093 TYPE KeyDuration 1094 IDENTIFIED BY id-kma-keyDuration } 1096 id-kma-keyDuration OBJECT IDENTIFIER ::= { 1097 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1098 dod(2) infosec(1) keying-material-attributes(13) 7 } 1100 KeyDuration ::= CHOICE { 1101 hours [0] INTEGER (1..ub-KeyDuration-hours), 1102 days INTEGER (1..ub-KeyDuration-days), 1103 weeks [1] INTEGER (1..ub-KeyDuration-weeks), 1104 months [2] INTEGER (1..ub-KeyDuration-months), 1105 years [3] INTEGER (1..ub-KeyDuration-years) } 1107 ub-KeyDuration-hours INTEGER ::= 96 1108 ub-KeyDuration-days INTEGER ::= 732 1110 ID NSA's CMS Key Management Attributes December 18, 2013 1112 ub-KeyDuration-weeks INTEGER ::= 104 1113 ub-KeyDuration-months INTEGER ::= 72 1114 ub-KeyDuration-years INTEGER ::= 100 1116 The key-validity-period attribute described in the previous section 1117 and the key-duration attribute described in this section provide a 1118 complementary function. The relationship between these attributes is 1119 described in the previous section. 1121 Due to multiple layers of encapsulation or the use of content 1122 collections, the key-duration attribute can appear in more than one 1123 location in the overall key package. When there are multiple 1124 occurrences of the key-duration attribute within the same scope, all 1125 of the included attribute fields MUST contain exactly the same value. 1126 Receivers MUST reject any key package that fails these consistency 1127 checks. 1129 17. Classification 1131 The classification attribute indicates level of classification. The 1132 classification attribute specifies the aggregate classification of 1133 the package content. It can appear as a symmetric key, symmetric key 1134 package, asymmetric key, signed, authenticated, 1135 authenticated/unprotected, or content attribute. If the 1136 classification attribute appears as a signed, authenticated, 1137 authenticated/unprotected, or content attribute, then the value MUST 1138 represent the classification of all of the keying material within the 1139 content. Encrypted layers MAY contain content at a higher 1140 classification that will be revealed once they are decrypted. If the 1141 classification attribute is associated with a collection, then the 1142 sensitivity of all the data within the collection MUST be dominated 1143 by the classification carried in this attribute. 1145 The classification attribute makes use of the ESSSecurityLabel 1146 defined in Section 17.1 and from [RFC2634][RFC5911]. The term 1147 "classification" is used in this document, but the term "security 1148 label" is used in [RFC2634]. The two terms have the same meaning. 1150 [RFC2634][RFC5911] specifies an object identifier and syntax for the 1151 security label attribute. The same values are used for the 1152 classification attribute: 1154 aa-classificationAttribute ATTRIBUTE ::= { 1155 TYPE Classification 1156 IDENTIFIED BY id-aa-KP-classification } 1158 id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel 1160 ID NSA's CMS Key Management Attributes December 18, 2013 1162 -- id-aa-securityLabel OBJECT IDENTIFIER ::= { 1163 -- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1164 -- pkcs-9(9) smime(16) id-aa(2) 2 } 1166 Classification ::= ESSSecurityLabel 1168 The syntax of ESSSecurityLabel is not repeated here; however, see 1169 section 17.1 for security label conventions that MUST be followed by 1170 implementations of this specification. See [RFC2634] for a complete 1171 discussion of the semantics and syntax. 1173 When the classification attribute appears in more than one location 1174 in the overall key package, each occurrence is evaluated 1175 independently. The content originator MUST ensure that the 1176 classification attribute represents the sensitivity of the plaintext 1177 within the content. That is, the classification MUST dominate any 1178 other plaintext classification attribute value that is present 1179 elsewhere in the overall key package. Note that the classification 1180 attribute value may exceed these other plaintext classification 1181 attribute values if the other attribute values within the SignerInfo, 1182 AuthEnvelopedData, or AuthenticatedData are themselves classified and 1183 warrant the higher security label value. 1185 When the classification attribute appears in more than one location 1186 in the overall key package, each security label might be associated 1187 with a different security policy. Content originators SHOULD avoid 1188 mixing multiple security policies in the same key package whenever 1189 possible since this requires that receivers and intermediaries that 1190 check the classification attribute values to include support for the 1191 union of the security policies that are present. Failure to 1192 recognize an included security policy MUST result in rejection of the 1193 key package. 1195 Receivers MUST reject any key package that includes a classification 1196 for which the receiver's processing environment is not authorized. 1198 17.1. Security Label 1200 The ESSSecurityLabel ASN.1 type is used to represent the 1201 classification. The ESSSecurityLabel is defined in Section 3.2 of 1202 [RFC2634]. 1204 The classification attribute values and classification attribute 1205 values have ASN.1 type ESSSecurityLabel. Part of the syntax 1206 definition is repeated here to facilitate discussion: 1208 ESSSecurityLabel ::= SET { 1209 security-policy-identifier SecurityPolicyIdentifier, 1211 ID NSA's CMS Key Management Attributes December 18, 2013 1213 security-classification SecurityClassification OPTIONAL, 1214 privacy-mark ESSPrivacyMark OPTIONAL, 1215 security-categories SecurityCategories OPTIONAL } 1217 A security policy is a set of criteria for the provision of security 1218 services. The security-policy-identifier, which is an object 1219 identifier, is used to identify the security policy associated with 1220 the security label. It indicates the semantics of the other security 1221 label components. 1223 If the key package receiver does not recognize the object identifier 1224 in the security-policy-identifier field and the security label 1225 includes a security-categories field, then the key package contents 1226 MUST NOT be accepted and the enclosed keying material MUST NOT be 1227 used. If the key package receiver does not recognize the object 1228 identifier in the security-policy-identifier field and the security 1229 label does not include a security-categories field, then the key 1230 package contents MAY be accepted only if the security-classification 1231 field is present and it contains a value from the basic hierarchy as 1232 described below. 1234 This specification defines the use of the SecurityClassification 1235 field exactly as is it specified in the 1988 edition of ITU-T 1236 Recommendation X.411 [X.411], which states in part: 1238 "If present, a security-classification may have one of a 1239 hierarchical list of values. The basic security-classification 1240 hierarchy is defined in this Recommendation, but the use of these 1241 values is defined by the security-policy in force. Additional 1242 values of security-classification, and their position in the 1243 hierarchy, may also be defined by a security-policy as a local 1244 matter or by bilateral agreement. The basic security- 1245 classification hierarchy is, in ascending order: unmarked, 1246 unclassified, restricted, confidential, secret, top-secret." 1248 Implementations MUST support the basic security classification 1249 hierarchy. Such implementations MAY also support other security- 1250 classification values; however, the placement of additional values in 1251 the hierarchy MUST be specified by the security policy. 1253 Implementations MUST NOT make access control decisions based on the 1254 privacy-mark. However, information in the privacy-mark can be 1255 displayed to human users by devices that have displays to do so. The 1256 privacy-mark length MUST NOT exceed 128 characters. The privacy-mark 1257 SHALL use the PrintableString choice if all of the characters in the 1258 privacy mark are members of the printable string character set. 1260 If present, security-categories provide further granularity for the 1262 ID NSA's CMS Key Management Attributes December 18, 2013 1264 keying material. The security policy in force indicates the 1265 permitted syntaxes of any entries in the set of security categories. 1266 At most, 64 security categories may be present. The security- 1267 categories have ASN.1 type SecurityCategories and further 1268 SecurityCategory [RFC5912], which are both repeated here to 1269 facilitate discussion: 1271 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 1272 SecurityCategory 1273 {{SupportedSecurityCategories}} 1275 SecurityCategory {SECURITY-CATEGORY:Supported} ::= SEQUENCE { 1276 type [0] IMPLICIT SECURITY-CATEGORY. 1277 &id({Supported}), 1278 value [1] EXPLICIT SECURITY-CATEGORY. 1279 &Type({Supported}{@type}) 1280 } 1282 Four security categories are defined and are referred to as the 1283 Restrictive Tag, the Enumerated Tag, the Permissive Tag, and the 1284 Informative Tag. Only the Enumerated Tag and Informative Tag are 1285 permitted in the classification attribute. 1287 The Enumerated Tag is composed of one or more non-negative integers. 1288 Each non-negative integer represents a non-hierarchical security 1289 attribute that applies to the labeled content. Use of the integer 1290 representation is intended to minimize the size of the label since a 1291 particular key package generally contains only a few security 1292 categories attributes, even though a security policy might define a 1293 large set of security categories attributes. Security attributes 1294 enumerated by tags of this type could be restrictive (such as 1295 compartments) or permissive (such as release permissions). Two 1296 object identifiers for the SecurityCategory type field have been 1297 defined, one restrictive and one for permissive. The object 1298 identifiers are: 1300 id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= { 1301 2 16 840 1 101 2 1 8 3 4 } 1303 id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= { 1304 2 16 840 1 101 2 1 8 3 1 } 1306 With both the restrictive and permissive security category types, the 1307 corresponding SecurityCategory value has the following ASN.1 1308 definition: 1310 EnumeratedTag ::= SEQUENCE { 1311 tagName OBJECT IDENTIFIER, 1313 ID NSA's CMS Key Management Attributes December 18, 2013 1315 attributeList SET OF SecurityAttribute } 1317 SecurityAttribute ::= INTEGER (0..MAX) 1319 Any security policy that makes use of security categories MUST assign 1320 object identifiers for each tagName, assign the set of integer values 1321 associated with each tagName, and specify the semantic meaning for 1322 each integer value. Restrictive security attributes and permissive 1323 security attributes SHOULD be associated with different tagName 1324 object identifiers. 1326 The Informative Tag is composed of either one or more non-negative 1327 integers or a bit string. Only the integer choice is allowed in this 1328 specification. Each non-negative integer represents a non- 1329 hierarchical security attribute that applies to the labeled content. 1330 Use of the integer representation is intended to minimize the size of 1331 the label since a particular key package generally contains only a 1332 few security categories attributes, even though a security policy 1333 might define a large set of security categories attributes. Security 1334 attributes enumerated by tags of this type are informative (i.e., no 1335 access control is performed). One object identifier for the 1336 SecurityCategory type field has been defined and it is as follows: 1338 id-informativeAttributes OBJECT IDENTIFIER ::= { 1339 2 16 840 1 101 2 1 8 3 3 } 1341 The corresponding SecurityCategory value has the following ASN.1 1342 definition: 1344 InformativeTag ::= SEQUENCE { 1345 tagName OBJECT IDENTIFIER, 1346 attributes FreeFormField } 1348 FreeFormField ::= CHOICE { 1349 bitSetAttributes BIT STRING, 1350 securityAttributes SET OF SecurityAttribute } 1352 Any security policy that makes use of security categories MUST assign 1353 object identifiers for each tagName, assign the set of integer values 1354 associated with each tagName, and specify the semantic meaning for 1355 each integer value. 1357 18. Split Key Identifier 1359 The key package originator may include a split-identifier attribute 1360 to designate that the keying material contains a split rather than a 1361 complete key. It may appear as a symmetric and asymmetric key 1362 attribute. The split-identifier attribute MUST NOT appear as a 1364 ID NSA's CMS Key Management Attributes December 18, 2013 1366 symmetric key package, signed, authenticated, 1367 authenticated/unprotected, or content attribute. Split keys have two 1368 halves, which are called "A" and "B." The split-identifier attribute 1369 indicates which half is included in the key package, and it 1370 optionally indicates the algorithm that is needed to combine the two 1371 halves. The combine algorithm is OPTIONAL since each key algorithm 1372 has a default mechanism for this purpose, and the combine algorithm 1373 is present only if the default mechanism is not employed. 1375 The key-split-identifier attribute has the following syntax: 1377 aa-splitIdentifier ATTRIBUTE ::= { 1378 TYPE SplitID 1379 IDENTIFIED BY id-kma-splitID } 1381 id-kma-splitID OBJECT IDENTIFIER ::= { 1382 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1383 dod(2) infosec(1) keying-material-attributes(13) 11 } 1385 SplitID ::= SEQUENCE { 1386 ENUMERATED { a(0), b(1) }, 1387 combineAlg AlgorithmIdentifier 1388 {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL } 1390 In most cases the default combine algorithm will be employed, which 1391 makes this attribute a simple constant that identifies either the "A" 1392 or "B" half of the split key, which supports implementation of some 1393 key distribution policies. 1395 Note that each split might have its own CRC, but the key and the 1396 check word are both recovered when the two splits are combined. 1398 Since the split-identifier attribute MUST NOT appear as a signed, 1399 authenticated, authenticated/unprotected, or content attribute, a key 1400 package cannot include multiple occurrences of the split-identifier 1401 attribute within the same scope. Receivers MUST reject any key 1402 package in which the split-identifier attribute appears as a signed, 1403 authenticated, authenticated/unprotected, or content attribute. 1405 19. Key Package Type 1407 The key-package-type attribute is a shorthand method for specifying 1408 all aspects of the key package format, including which attributes are 1409 present and the structure of the encapsulated content. The key- 1410 package-type attribute can be used as a signed, authenticated, 1411 authenticated/unprotected, or content attribute. If a key-package- 1412 type attribute appears in a content attribute associated with a 1413 collection, it is a shorthand method for specifying all aspects of 1415 ID NSA's CMS Key Management Attributes December 18, 2013 1417 the key packages that comprise the collection. 1419 Rather than implementing the full flexibility of this specification, 1420 some devices may implement support for one or more specific key 1421 package formats instantiating this specification. Those specific 1422 formats are called templates and can be identified using a key- 1423 package-type attribute. 1425 The key-package-type attribute has the following syntax: 1427 aa-keyPackageType ATTRIBUTE ::= { 1428 TYPE KeyPkgType 1429 IDENTIFIED BY id-kma-keyPkgType } 1431 id-kma-keyPkgType OBJECT IDENTIFIER ::= { 1432 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1433 dod(2) infosec(1) keying-material-attributes(13) 12 } 1435 KeyPkgType ::= OBJECT IDENTIFIER 1437 Due to multiple layers of encapsulation or the use of content 1438 collections, the key-package-type attribute can appear in more than 1439 one location in the overall key package. When there are multiple 1440 occurrences of the key-package-type attribute, each occurrence is 1441 used independently. Since the receiver is likely to use the key- 1442 package-type attribute value as a decoding aid, any error will most 1443 likely lead to parsing problems, and these problems could result in 1444 many different errors being reported. 1446 20. Signature Usage 1448 The signature-usage attribute provides the intended usage for a 1449 signature key. Symmetric key packages do not contain signature 1450 generation or signature validation keying material, so the signature- 1451 usage attribute MUST NOT appear in a symmetric key package. For an 1452 asymmetric key package, the signature-usage attribute indicates the 1453 kind of objects that are to be signed with the private key in the 1454 package. However, if the asymmetric key package contains a 1455 Certificate Signature Key, then the signature-usage attribute also 1456 indicates what signed objects can be validated using certificates 1457 that are signed by the private key in the asymmetric key package. 1458 Therefore, the signature-usage attribute also indicates what kind of 1459 objects that can be signed by the private keys associated with these 1460 certificates. The signature-usage attribute MUST NOT appear as a 1461 signed, authenticated, authenticated/unprotected, or content 1462 attribute. 1464 The signature-usage attribute has the following syntax: 1466 ID NSA's CMS Key Management Attributes December 18, 2013 1468 aa-signatureUsage-v3 ATTRIBUTE ::= { 1469 TYPE SignatureUsage 1470 IDENTIFIED BY id-kma-sigUsageV3 } 1472 id-kma-sigUsageV3 OBJECT IDENTIFIER ::= { 1473 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1474 dod(2) infosec(1) keying-material-attributes(13) 22 } 1476 SignatureUsage ::= CMSContentConstraints 1478 The SignatureUsage structure has the same syntax as the 1479 CMSContentConstraints structure in [RFC6010], and it is repeated here 1480 for convenience. 1482 CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF 1483 ContentTypeConstraint 1485 ContentTypeConstraint ::= SEQUENCE { 1486 contentType CONTENT-TYPE.&id ({ContentSet|ct-Any,...}), 1487 canSource ContentTypeGeneration DEFAULT canSource, 1488 attrConstraints AttrConstraintList OPTIONAL } 1490 Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE { 1491 attrType ATTRIBUTE.&id({ConstraintList}), 1492 attrValues SET SIZE (1..MAX) OF ATTRIBUTE. 1493 &Type({ConstraintList}{@attrType}) } 1495 SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... } 1497 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF 1498 Constraint {{ SupportedConstraints }} 1500 The SignatureUsage contains a type of CMSContentConstraints. One or 1501 more ContentTypeConstraint MUST appear in CMSContentConstraints. 1503 Within ContentTypeConstraint, the contentType field indicates the 1504 encapsulated content type identifier that can be signed with the 1505 signature key. A particular content type MUST NOT appear more than 1506 once in the list. The CMS protecting content types need not be 1507 included in the list of permitted content types as the use of CMS is 1508 always authorized (see [RFC6010]). 1510 Within ContentTypeConstraint, the canSource enumeration indicates 1511 whether the signature key can be used to directly sign the indicated 1512 content type. If the ContentTypeConstraint is canSource (the default 1513 value), then the signature key can be used to directly sign the 1514 specified content type. If the ContentTypeConstraint is 1515 cannotSource, then the signature key can only be used with the 1517 ID NSA's CMS Key Management Attributes December 18, 2013 1519 specified content type if it encapsulates a signature that was 1520 generated by an originator with a ContentTypeConstraint that is 1521 canSource. 1523 Within ContentTypeList, the attrConstraints OPTIONAL field contains a 1524 sequence of content type specific constraints. If the 1525 attrConstraints field is absent, the signature key can be used to 1526 sign the specified content type, without any further checking. If 1527 the either the attrConstraints field is present, then the signature 1528 key can only be used to sign the specified content type if all of the 1529 constraints for that content type are satisfied. Content type 1530 constraints are checked by matching the attribute values in the 1531 attrConstraint field against the attribute value in the content. The 1532 constraints succeed if the attribute is not present; they fail if the 1533 attribute is present and the value is not one of the values provided 1534 in attrConstraint. 1536 The fields of attrConstraints implement content type-specific 1537 constraints. The attrType field is an AttributeType, which is an 1538 object identifier of a signed attribute carried in the SignerInfo of 1539 the content. The attrValues field provides one or more acceptable 1540 signed attribute values. It is a set of AttributeValue. For a 1541 signed content to satisfy the constraint, the SignerInfo MUST include 1542 a signed attribute of the type identified in the attrType field, and 1543 the signed attribute MUST contain one of the values in the set 1544 carried in attrValues. 1546 Since the signature-usage attribute MUST NOT appear as a signed, 1547 authenticated, authenticated/unprotected, or content attribute, an 1548 asymmetric key package cannot include multiple occurrences of the 1549 signature-usage attribute within the same scope. Receivers MUST 1550 reject any asymmetric key package in which the signature-usage 1551 attribute appears as a signed, authenticated, 1552 authenticated/unprotected, or content attribute. 1554 21. Other Certificate Format 1556 The other-certificate-formats attribute specifies the type, format, 1557 and value of certificates that are not X.509 public key certificates. 1558 Symmetric key packages do not contain any certificates, so the 1559 other-certificate-formats attribute MUST NOT appear in a symmetric 1560 key package. It SHOULD appear in the attributes field, when the 1561 publicKey field is absent and the certificate format is not X.509. 1562 This attribute MUST NOT appear in an attributes field that includes 1563 the user-certificate attribute from Section 8. The other- 1564 certificate-formats attribute MUST NOT appear as a signed, 1565 authenticated, authenticated/unprotected, or content attribute. 1567 ID NSA's CMS Key Management Attributes December 18, 2013 1569 The other-certificate-formats attribute has the following syntax: 1571 aa-otherCertificateFormats ATTRIBUTE ::= { 1572 TYPE CertificateChoices 1573 IDENTIFIED BY id-kma-otherCertFormats } 1575 id-kma-otherCertFormats OBJECT IDENTIFIER ::= { 1576 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1577 dod(2) infosec(1) keying-material-attributes(13) 19 } 1579 CertificateChoices ::= CHOICE { 1580 certificate Certificate, 1581 extendedCertificate [0] IMPLICIT ExtendedCertificate, 1582 -- Obsolete 1583 v1AttrCert [1] IMPLICIT AttributeCertificateV1, 1584 -- Obsolete 1585 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 1586 other [3] IMPLICIT OtherCertificateFormat } 1588 OtherCertificateFormat ::= SEQUENCE { 1589 otherCertFormat OBJECT IDENTIFIER, 1590 otherCert ANY DEFINED BY otherCertFormat } 1592 The other-certificate-formats attribute makes use of the 1593 CertificateChoices field defined in Section 10.2.2 of [RFC5652]. The 1594 certificate, extendedCertificate, and v1AttrCert fields MUST be 1595 omitted. The v2AttrCert field can include Version 2 Attribute 1596 Certificates. The other field can include EFF certificates and other 1597 as-yet undefined certificate formats. 1599 Since the other-certificate-formats attribute MUST NOT appear as a 1600 signed, authenticated, authenticated/unprotected, or content 1601 attribute, an asymmetric key package cannot include multiple 1602 occurrences of the other-certificate-formats attribute within the 1603 same scope. Receivers MUST reject any asymmetric key package in 1604 which the other-certificate-formats attribute appears as a signed, 1605 authenticated, authenticated/unprotected, or content attribute. 1607 22. PKI Path 1609 The pki-path attribute includes certificates that can aid in the 1610 validation of the certificate carried in the user-certificate 1611 attribute. Symmetric key packages do not contain any certificates, 1612 so the pkiPath attribute MUST NOT appear in a symmetric key package. 1613 It can appear as an asymmetric key, signed, authenticated, 1614 authenticated/unprotected, or content attribute. It can appear in 1615 the attributes field, when the publicKey field is absent and the 1616 certificate format is X.509. This attribute MUST NOT appear in an 1618 ID NSA's CMS Key Management Attributes December 18, 2013 1620 AsymmetricKeyPackage that has an other-certificate-formats attribute 1621 in the attributes field. If the pki-path attribute appears as a 1622 signed, authenticated, authenticated/unprotected, or content 1623 attribute, then the value includes certificates that can be used to 1624 construct certification path to all of the keying material within the 1625 content. This attribute MUST be supported. 1627 The syntax is taken from [X.509] but redefined using the ATTRIBUTE 1628 CLASS from [RFC5911]. The pki-path attribute has the following 1629 syntax: 1631 aa-pkiPath ATTRIBUTE ::= { 1632 TYPE PkiPath 1633 IDENTIFIED BY id-at-pkiPath } 1635 id-at-pkiPath OBJECT IDENTIFIER ::= { 1636 joint-iso-itu-t(2) ds(5) attributes(4) 70 } 1638 PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate 1640 The first certificate in the sequence is the subject's parent 1641 Certification Authority (CA). The next certificate is that CA's 1642 parent, and so on. The end-entity and Trust Anchor are not included 1643 in this attribute. 1645 Due to multiple layers of encapsulation or the use of content 1646 collections, the pki-path attribute can appear in more than one 1647 location in the overall key package. When the pki-path attribute 1648 appears in more than one location in the overall key package, each 1649 occurrence is evaluated independently. 1651 23. Useful Certificates 1653 The useful-certificates attribute includes certificates that can aid 1654 in the validation of certificates associated with other parties with 1655 whom secure communications are anticipated. It can appear as an 1656 asymmetric key, signed, authenticated, authenticated/unprotected, or 1657 content attribute. For an asymmetric key that has an other- 1658 certificate-formats attribute from Section 21 in the attributes 1659 field, the useful-certificates attribute MUST NOT appear. If the 1660 useful-certificates attribute appears as a signed, authenticated, 1661 authenticated/unprotected, or content attribute, then the value 1662 includes certificates that may be used to validate certificate of 1663 others the receiver communicates with. This attribute MUST be 1664 supported. 1666 The useful-certificates attribute has the following syntax: 1668 ID NSA's CMS Key Management Attributes December 18, 2013 1670 aa-usefulCertificates ATTRIBUTE ::= { 1671 TYPE CertificateSet 1672 IDENTIFIED BY id-kma-usefulCerts } 1674 id-kma-usefulCerts OBJECT IDENTIFIER ::= { 1675 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1676 dod(2) infosec(1) keying-material-attributes(13) 20 } 1678 CertificateSet ::= SET OF CertificateChoices 1680 The useful-certificates attribute makes use of the CertificateSet 1681 field defined in Section 10.2.3 of [RFC5652]. Within the 1682 CertificateChoices field, the extendedCertificate and v1AttrCert 1683 fields MUST always be omitted. If the userCertificate attribute from 1684 Section 8 is included, the other field MUST NOT be present. If the 1685 other-certificate-formats attribute from Section 21 is included, the 1686 certificate field MUST NOT be present. 1688 Due to multiple layers of encapsulation or the use of content 1689 collections, the useful-certificates attribute can appear in more 1690 than one location in the overall key package. When the useful- 1691 certificates attribute appears in more than one location in the 1692 overall key package, each occurrence is evaluated independently. 1694 24. Key Wrap Algorithm 1696 The key-wrap-algorithm attribute identifies a key wrap algorithm with 1697 an algorithm identifier. It can appear as a symmetric key or 1698 symmetric key package attribute. When this attribute is present in 1699 sKeyAttrs, it indicates that the associated sKey field contains a 1700 black key that was wrapped by the identified algorithm. When this 1701 attribute is present in sKeyPkgAttrs, it indicates that every sKey 1702 field in that symmetric key package contains a black key, and that 1703 all keys are wrapped by the same designated algorithm. 1705 The key-wrap-algorithm attribute has the following syntax: 1707 aa-keyWrapAlgorithm ATTRIBUTE ::= { 1708 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}} 1709 IDENTIFIED BY id-kma-keyWrapAlgorithm } 1711 id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= { 1712 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1713 dod(2) infosec(1) keying-material-attributes(13) 21 } 1715 KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... } 1717 25. Content Decryption Key Identifier 1718 ID NSA's CMS Key Management Attributes December 18, 2013 1720 The content-decryption-key-identifier attribute can appear as an 1721 unprotected attribute as well as a symmetric and symmetric key 1722 package attribute. The attribute's semantics differ based on the 1723 location. 1725 25.1. Content Decryption Key Identifier: Symmetric Key and Symmetric Key 1726 Package 1728 The content-decryption-key-identifier attribute [RFC6032] identifies 1729 the keying material needed to decrypt the sKey. It can appear as a 1730 symmetric key and symmetric key package attribute. If the key-wrap- 1731 algorithm attribute appears in sKeyPkgAttrs, then the corresponding 1732 content-decryption-identifier attribute can appear in either 1733 sKeyPkgAttrs or sKeyAttrs. If the key-wrap-algorithm attribute 1734 appears from Section 24 in sKeyAttrs, then the corresponding content- 1735 decryption-identifier attribute MUST appear in sKeyAttrs. 1737 The content-decryption-key-identifier attribute in included for 1738 convenience: 1740 aa-contentDecryptKeyIdentifier ATTRIBUTE ::= { 1741 TYPE ContentDecryptKeyID 1742 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 1744 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= { 1745 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1746 dod(2) infosec(1) attributes(5) 66 } 1748 ContentDecryptKeyID ::= OCTET STRING 1750 The content decryption key identifier contains an octet string, and 1751 this syntax does not impose any particular structure on the 1752 identifier value. 1754 25.2. Content Decryption Key Identifier: Unprotected 1756 The content-decryption-key-identifier attribute can be used to 1757 identify the keying material that is needed for decryption of the 1758 EncryptedData content if there is any ambiguity. 1760 The content-decryption-key-identifier attribute syntax is found in 1761 Section 25.1. The content decryption key identifier contains an octet 1762 string, and this syntax does not impose any particular structure on 1763 the identifier value. 1765 Due to multiple layers of encryption, the content-decryption-key- 1766 identifier attribute can appear in more than one location in the 1767 overall key package. When there are multiple occurrences of the 1769 ID NSA's CMS Key Management Attributes December 18, 2013 1771 content-decryption-key-identifier attribute, each occurrence is 1772 evaluated independently. Each one is used to identify the needed 1773 keying material for that layer of encryption. 1775 26. Certificate Pointers 1777 The certificate-pointers attribute can be used to reference one or 1778 more certificates that may be helpful in the processing of the 1779 content once it is decrypted. Sometimes certificates are omitted if 1780 they can be easily fetched. However, an intermediary may have better 1781 facilities to perform the fetching than the receiver. The 1782 certificate-pointers attribute may be useful in some environments. 1783 This attribute can appear as an unprotected and an 1784 unauthenticated/unprotected attribute. 1786 The certificate-pointers attribute uses the same syntax and semantics 1787 as the subject information access certificate extension [RFC5280]. 1788 The certificate-pointers attribute has the following syntax: 1790 aa-certificatePointers ATTRIBUTE ::= { 1791 TYPE SubjectInfoAccessSyntax 1792 IDENTIFIED BY id-pe-subjectInfoAccess } 1794 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { 1795 iso(1) identified-organization(3) dod(6) internet(1) 1796 security(5) mechanisms(5) pkix(7) pe(1) 11 } 1798 SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF 1799 AccessDescription 1801 AccessDescription ::= SEQUENCE { 1802 accessMethod OBJECT IDENTIFIER, 1803 accessLocation GeneralName } 1805 As specified in [RFC5280], the id-ad-caRepository access method can 1806 be used to point to a repository where a Certification Authority 1807 publishes certificates and Certificate Revocation Lists (CRLs). In 1808 this case, the accessLocation field tells how to access the 1809 repository. Where the information is available via http, ftp, or 1810 ldap, accessLocation contains a uniform resource identifier (URI). 1811 Where the information is available via the directory access protocol 1812 (dap), accessLocation contains a directory name. 1814 27. CRL Pointers 1816 The CRL-pointers attribute can be used to reference one or more CRLs 1817 that may be helpful in the processing of the content once it is 1818 decrypted. Sometimes CRLs are omitted to conserve space or to ensure 1820 ID NSA's CMS Key Management Attributes December 18, 2013 1822 that the most recent CRL is obtained when the certificate is 1823 validated. However, an intermediary may have better facilities to 1824 perform the fetching than the receiver. The CRL-pointers attribute 1825 may be useful in some environments. This attribute can appear as an 1826 unprotected and unauthenticated/unprotected attribute. 1828 The CRL-pointers attribute has the following syntax: 1830 aa-crlPointers ATTRIBUTE ::= { 1831 TYPE GeneralNames 1832 IDENTIFIED BY id-aa-KP-crlPointers } 1834 id-aa-KP-crlPointers OBJECT IDENTIFIER ::= { 1835 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1836 dod(2) infosec(1) attributes(5) 70 } 1838 The CRL-pointers attribute uses the GeneralNames syntax from 1839 [RFC5280]. Each name describes a different mechanism to obtain the 1840 same CRL. Where the information is available via http, ftp, or ldap, 1841 GeneralNames contains a uniform resource identifier (URI). Where the 1842 information is available via the directory access protocol (dap), 1843 GeneralNames contains a directory name. 1845 28. Key Package Identifier and Receipt Request 1847 The Key Package Identifier and Receipt Request attribute from 1848 [ID.housley-keypackage-receipt-n-error] is also supported. It can 1849 appear as a signed attribute, authenticated, 1850 authenticated/unprotected, or content attribute. 1852 29. Additional Error Codes 1854 This specification also defines three additional extendedErrorCodes 1855 [ID.housley-keypackage-receipt-n-error]: 1857 id-errorCodes OBJECT IDENTIFIER ::= { 1858 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1859 dod(2) infosec(1) errorCodes(22) } 1861 id-missingKeyType OBJECT IDENTIFIER ::= { 1862 id-errorCodes 1 } 1864 id-privacyMarkTooLong OBJECT IDENTIFIER ::= { 1865 id-errorCodes 2 } 1867 id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= { 1868 id-errorCodes 3 } 1870 ID NSA's CMS Key Management Attributes December 18, 2013 1872 id-incorrectKeyProvince OBJECT IDENTIFIER ::= { 1873 id-errorCodes 4 } 1875 missingKeyType indicates that all keying material within a package is 1876 of the same type; however, the key type attribute is not specified in 1877 sKeyPkgAttrs [RFC6031]. 1879 privacyMarkTooLong indicates that a classification attribute includes 1880 a privacy mark that exceeds 128 characters in length. 1882 unrecognizedSecurityPolicy indicates that a security-policy- 1883 identifier is not supported. 1885 incorrectKeyProvince indicates that the value of the key province 1886 attribute in a key package does not match the key province constraint 1887 of the TA used to validate the key package. 1889 30. Processing Key Package Attribute Values and CMS Content Constraints 1891 Trust anchors may contain constraints for any content type [RFC5934]. 1892 When the trust anchor contains constraints for the symmetric key 1893 package content type or the asymmetric key package content type, then 1894 the constraints provide default values for key package attributes 1895 that are not present in the key package and define the set of 1896 acceptable values for key package attributes that are present. 1898 When a trust anchor delegates authority by issuing an X.509 1899 certificate, the CMS content constraints certificate extension 1900 [RFC6010] may be included to constrain the authorizations. The trust 1901 anchor and the X.509 certification path provide default values for 1902 key package attributes that are not present in the key package and 1903 define the set of acceptable of values for key package attributes 1904 that are present. 1906 Constraints on content type usage are represented as attributes. 1908 The processing procedures for the CMS content constraints certificate 1909 extension [RFC6010] are part of the validation of a signed or 1910 authenticated object, and the procedures yield three output values: 1911 cms_constraints, cms_effective_attributes, and 1912 cms_default_attributes. Object validation MUST be performed before 1913 processing the key package contents, and these outputs values are 1914 used as part of key package processing. These same output values are 1915 easily generated directly from a trust anchor and the key package 1916 when no X.509 certification path is involved in validation. 1918 The cms_effective_attributes provides the set of acceptable values 1920 ID NSA's CMS Key Management Attributes December 18, 2013 1922 for attributes. Each attribute present in the key package that 1923 corresponds to an entry in cms_effective_attributes MUST contain a 1924 value that appears in cms_effective_attributes entry. Attributes 1925 that do not correspond to an entry in cms_effective_attributes are 1926 unconstrained and may contain any value. Correspondence between 1927 attributes and cms_effective_attributes is determined by comparing 1928 the attribute object identifier to object identifier for each entry 1929 in cms_effective_attributes. 1931 The cms_default_attributes provides values for attributes that do not 1932 appear in the key package. If cms_default_attributes includes only 1933 one attribute value for a particular attribute, then that value is 1934 used as if it were included in the key package itself. However, if 1935 cms_default_attributes includes more than one value for a particular 1936 attribute, then the appropriate value remains ambiguous and the key 1937 package should be rejected. 1939 Some attributes can appear in more than one place in the key package, 1940 and for this reason, the attribute definitions include consistency 1941 checks. These checks are independent of constraints checking. In 1942 addition to the consistency checks, each instance of the attribute 1943 MUST be checked against the set of cms_effective_attributes, and the 1944 key package MUST be rejected if any of the attributes values are not 1945 in the set of authorized set of values. 1947 31. Attribute Scope 1949 This section provides an example symmetric key package in order to 1950 provide a discussion of the scope of attributes. This is an 1951 informative section; it is not a normative portion of this 1952 specification. Figure 1 provides the example. All of the concepts 1953 apply to either a symmetric key package or an asymmetric key package, 1954 with the exception of the key-algorithm attribute which is only 1955 applicable to a symmetric key package. Each of the components is 1956 labeled with a number inside parentheses for easy reference: 1958 o (1) is the ContentInfo that must be present as the outermost 1959 layer of encapsulation. It contains no attributes. It is shown 1960 for completeness. 1962 o (2) is a SignedData content type, which includes six signed 1963 attributes. Four of the signed attributes are keying material 1964 attributes. 1966 o (3) is a ContentCollection that includes two encapsulated content 1967 types: a ContentWithAttributes and an EncryptedKeyPackage. This 1968 content type does not provide any attributes. 1970 ID NSA's CMS Key Management Attributes December 18, 2013 1972 o (4) is a ContentWithAttributes content type. It encapsulates a 1973 SignedData content type. Four key material attributes are 1974 provided. 1976 o (5) is a SignedData content type. It encapsulates a 1977 SymmetricKeyPackage content type. Six signed attributes are 1978 provided. Four attributes are key material attributes. 1980 o (6) is a SymmetricKeyPackage content type, and it includes three 1981 key material attributes. Note that the contents of this key 1982 package are not encrypted, but the contents are covered by two 1983 digital signatures. 1985 o (7) is an EncryptedKeyPackage content type. It encapsulates a 1986 SignedData content type. This content type provides one 1987 unprotected attribute. 1989 o (8) is a SignedData content type. It encapsulates a 1990 SymmetricKeyPackage content type. Six signed attributes are 1991 provided. Four attributes are key material attributes. 1993 o (9) is a SymmetricKeyPackage content type, and it includes three 1994 key material attributes. Note that the contents of this key 1995 package are encrypted, and the plaintext keying material is 1996 covered by one digital signature, and the ciphertext keying 1997 material is covered by another digital signature. 1999 SignedData content type (2) includes six signed attributes: 2001 o The content-type attribute contains id-ct-contentCollection to 2002 indicate the type of the encapsulated content, and it has no 2003 further scope. 2005 o The message-digest attribute contains the one-way hash value of 2006 the encapsulated content; it is needed to validate the digital 2007 signature. It has no further scope. 2009 o The classification attribute contains security label for all of 2010 the plaintext in the encapsulated content. Each classification 2011 attribute is evaluated separately; it has no further scope. In 2012 general, the values of this attribute will match or dominate the 2013 security label values in (4), (5), and (6). The value of this 2014 attribute might not match or dominate the security label values 2015 in (8) and (9) since they are encrypted. It is possible that 2016 these various security label values are associated with different 2017 security policies. Comparison is not required in order to avoid 2018 the processing complexity associated with policy mapping. 2020 ID NSA's CMS Key Management Attributes December 18, 2013 2022 o The key-package-receivers-v2 attribute indicates the authorized 2023 key package receivers, and it has no further scope. The key- 2024 package-receivers-v2 attribute value within (4) is evaluated 2025 without regard to the value of this attribute. 2027 o The key-distribution-period attribute contains two date values: 2028 doNotDistBefore and doNotDistAfter. These values must match all 2029 others within the same scope, which in this example is the key- 2030 distribution-period within (4). 2032 o The key-package-type attributes indicates the format of the key 2033 package, and it has no further scope. The key-package-type 2034 attributes values within (5) and (8) are evaluated without regard 2035 to the value of this attribute. 2037 ContentWithAttributes content type (4) includes four attributes: 2039 o The classification attribute contains security label for all of 2040 the plaintext in the encapsulated content. Each classification 2041 attribute is evaluated separately; it has no further scope. 2043 o The TSEC-Nomenclature attribute includes only the shortTitle 2044 field, and the value must match all other instances within the 2045 same scope, which appear in (5) and (6). Note that the TSEC- 2046 Nomenclature attribute values in (8) and (9) are not in the same 2047 scope as the TSEC-Nomenclature attribute that appears in (4). 2049 o The key-package-receivers-v2 attribute indicates the authorized 2050 key package receivers, and it has no further scope. The key- 2051 package-receivers-v2 attribute value within (2) is evaluated 2052 without regard to the value of this attribute. 2054 o The key-distribution-period attribute contains two date values: 2055 doNotDistBefore and doNotDistAfter. These values must match all 2056 others within the same scope, which in this example is the key- 2057 distribution-period within (2). 2059 SignedData content type (5) includes six signed attributes: 2061 o The content-type attribute contains id-ct-KP-skeyPackage to 2062 indicate the type of the encapsulated content, and it has no 2063 further scope. 2065 o The message-digest attribute contains the one-way hash value of 2066 the encapsulated content; it is needed to validate the digital 2067 signature. It has no further scope. 2069 o The classification attribute contains security label for all of 2071 ID NSA's CMS Key Management Attributes December 18, 2013 2073 the plaintext in the encapsulated content. Each classification 2074 attribute is evaluated separately; it has no further scope. 2076 o The TSEC-Nomenclature attribute includes only the shortTitle 2077 field, and the value must match all other instances within the 2078 same scope, which appear in (6). Since this is within the scope 2079 of (4), these shortTitle field values must match as well. Note 2080 that the TSEC-Nomenclature attribute values in (8) and (9) are 2081 not in the same scope. 2083 o The key-purpose attribute specifies the purpose of the key 2084 material. All occurrences within the scope must have the same 2085 value, but in this example, there are no other occurrences within 2086 the scope. The key-purpose attribute value within (8) is 2087 evaluated without regard to the value of this value. 2089 o The key-package-type attribute indicates the format of the key 2090 package, and it has no further scope. The key-package-type 2091 attribute values within (2) and (8) are evaluated without regard 2092 to the value of this attribute. 2094 SymmetricKeyPackage content type (6) includes three keying material 2095 attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs 2096 fields: 2098 o The key-algorithm attribute includes only the keyAlg field, and 2099 it must match all other occurrences within the same scope. 2100 However, there are no other key-algorithm attribute occurrences 2101 in the same scope; the key-algorithm attribute value in (9) is 2102 not in the same scope. 2104 o The classification attribute contains security label for all of 2105 the plaintext in the key package. Each classification attribute 2106 is evaluated separately; it has no further scope. 2108 o The TSEC-Nomenclature attribute includes the shortTitle field as 2109 well as some of the optional fields. The shortTitle field value 2110 must match the values in (4) and (5), since this content type is 2111 within their scope. Note that the TSEC-Nomenclature attribute 2112 values in (8) and (9) are not in the same scope. 2114 EncryptedKeyPackage content type (7) includes one unprotected 2115 attribute, and the encryption will prevent any intermediary that does 2116 not have the ability to decrypt the content from making any 2117 consistency checks on (8) and (9): 2119 o The content-decryption-key-identifier attribute identifies the 2120 key that is needed to decrypt the encapsulated content; it has no 2122 ID NSA's CMS Key Management Attributes December 18, 2013 2124 further scope. 2126 SignedData content type (8) includes six signed attributes: 2128 o The content-type attribute contains id-ct-KP-skeyPackage to 2129 indicate the type of the encapsulated content, and it has no 2130 further scope. 2132 o The message-digest attribute contains the one-way hash value of 2133 the encapsulated content; it is needed to validate the digital 2134 signature. It has no further scope. 2136 o The classification attribute contains security label for content. 2137 Each classification attribute is evaluated separately; it has no 2138 further scope. 2140 o The TSEC-Nomenclature attribute includes only the shortTitle 2141 field, and the value must match all other instances within the 2142 same scope, which appear in (9). Note that the TSEC-Nomenclature 2143 attribute values in (4), (5), and (6) are not in the same scope. 2145 o The key-purpose attribute specifies the purpose of the key 2146 material. All occurrences within the scope must have the same 2147 value, but in this example, there are no other occurrences within 2148 the scope. The key-purpose attribute value within (5) is 2149 evaluated without regard to the value of this attribute. 2151 o The key-package-type attribute indicates the format of the key 2152 package, and it has no further scope. The key-package-type 2153 attribute values within (2) and (5) are evaluated without regard 2154 to the value of this attribute. 2156 SymmetricKeyPackage content type (9) includes three keying material 2157 attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs 2158 fields: 2160 o The key-algorithm attribute includes only the keyAlg field, and 2161 it must match all other occurrences within the same scope. 2162 However, there are no other key-algorithm attribute occurrences 2163 in the same scope; the key-algorithm attribute value in (6) is 2164 not in the same scope. 2166 o The classification attribute contains security label for all of 2167 the plaintext in the key package. Each classification attribute 2168 is evaluated separately; it has no further scope. 2170 o The TSEC-Nomenclature attribute includes the shortTitle field as 2171 well as some of the optional fields. The shortTitle field value 2173 ID NSA's CMS Key Management Attributes December 18, 2013 2175 must match the values in (8), since this content type is within 2176 its scope. Note that the TSEC-Nomenclature attributes values in 2177 (4), (5), and (6) are not in the same scope. 2179 In summary, the scope of an attribute includes the encapsulated 2180 content of the CMS content type in which it appears, and some 2181 attributes also require consistency checks with other instances that 2182 appear within the encapsulated content. Proper recognition of scope 2183 is required to accurately perform attribute processing. 2185 ID NSA's CMS Key Management Attributes December 18, 2013 2187 +------------------------------------------------------------------+ 2188 | ContentInfo (1) | 2189 |+----------------------------------------------------------------+| 2190 || SignedData (2) || 2191 ||+--------------------------------------------------------------+|| 2192 ||| ContentCollection (3) ||| 2193 |||+-----------------------------++-----------------------------+||| 2194 |||| ContentWithAttributes (4) || EncryptedKeyPackage (7) |||| 2195 ||||+---------------------------+||+---------------------------+|||| 2196 ||||| SignedData (5) |||| SignedData (8) ||||| 2197 |||||+-------------------------+||||+-------------------------+||||| 2198 |||||| SymmetricKeyPackage (6) |||||| SymmetricKeyPackage (9) |||||| 2199 |||||| Attributes: |||||| Attributes: |||||| 2200 |||||| Key Algorithm |||||| Key Algorithm |||||| 2201 |||||| Classification |||||| Classification |||||| 2202 |||||| TSEC-Nomenclature |||||| TSEC-Nomenclature |||||| 2203 |||||+-------------------------+||||+-------------------------+||||| 2204 ||||| Attributes: |||| Attributes: ||||| 2205 ||||| Content Type |||| Content Type ||||| 2206 ||||| Message Digest |||| Message Digest ||||| 2207 ||||| Classification |||| Classification ||||| 2208 ||||| TSEC-Nomenclature |||| TSEC-Nomenclature ||||| 2209 ||||| Key Purpose |||| Key Purpose ||||| 2210 ||||| Key Package Type |||| Key Package Type ||||| 2211 ||||+-------------------------- +||+---------------------------+|||| 2212 |||| Attributes: || Unprotect Attributes: |||| 2213 |||| Classification || Content Decrypt Key ID |||| 2214 |||| TSEC-Nomenclature |+-----------------------------+||| 2215 |||| Key Package Receivers | ||| 2216 |||| Key Distribution Period | ||| 2217 |||+-----------------------------+ ||| 2218 ||+--------------------------------------------------------------+|| 2219 || Attributes: || 2220 || Content Type || 2221 || Message Digest || 2222 || Classification || 2223 || Key Package Receivers || 2224 || Key Distribution Period || 2225 || Key Package Type || 2226 |+----------------------------------------------------------------+| 2227 +------------------------------------------------------------------+ 2229 Figure 1: Example Illustrating Scope of Attributes 2231 32. Security Considerations 2233 The majority of this specification is devoted to the syntax and 2235 ID NSA's CMS Key Management Attributes December 18, 2013 2237 semantics of key package attributes. It relies on other 2238 specifications, especially [RFC2634] [RFC4073] [RFC4108] [RFC5652] 2239 [RFC5911] [RFC5912] [RFC5958] [RFC6010] [RFC6031]; their security 2240 considerations apply here. Additionally, cryptographic algorithms 2241 are used with CMS protecting content types [RFC5959] [RFC6160] 2242 [RFC6162]; their security considerations apply here as well. 2244 This specification also relies upon [RFC5280] for the syntax and 2245 semantics of X.509 certificates. Digital signatures provide data 2246 integrity or data origin authentication, and encryption provides 2247 confidentiality. 2249 Security factors outside the scope of this specification greatly 2250 affect the assurance provided. The procedures used by Certification 2251 Authorities (CAs) to validate the binding of the subject identity to 2252 their public key greatly affect the assurance that ought to be placed 2253 in the certificate. This is particularly important when issuing 2254 certificates to other CAs. 2256 The CMS AuthenticatedData content type MUST be used with care since a 2257 message authentication code (MAC) is used. The same key is needed to 2258 generate the MAC or validate the MAC. Thus, any party with access to 2259 the key needed to validate the MAC can generate a replacement that 2260 will be acceptable to other recipients. 2262 33. IANA Considerations 2264 None. 2266 34. References 2268 34.1 Normative References 2270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2271 Requirement Levels", BCP 14, RFC 2119, March 1997. 2273 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 2274 RFC 2634, June 1999. 2276 [RFC4073] Housley, R., "Protecting Multiple Contents with the 2277 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 2279 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 2280 Protect Firmware Packages", RFC 4108, August 2005. 2282 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 2283 Authenticated-Enveloped-Data Content Type", RFC 5083, 2284 November 2007. 2286 ID NSA's CMS Key Management Attributes December 18, 2013 2288 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2289 Housley, R., and W. Polk, "Internet X.509 Public Key 2290 Infrastructure Certificate and Certificate Revocation List 2291 (CRL) Profile", RFC 5280, May 2008. 2293 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2294 RFC 5652, September 2009. 2296 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 2297 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 2298 June 2010. 2300 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 2301 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 2302 June 2010. 2304 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2305 2010. 2307 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 2308 Type", RFC 5959, August 2010. 2310 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 2311 Representing Date and Time in ASN.1", RFC 6019, September 2312 2010. 2314 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2315 (CMS) Symmetric Key Package Content Type", RFC 6031, 2316 December 2010. 2318 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 2319 (CMS) Encrypted Key Package Content Type", RFC 6032, 2320 December 2010. 2322 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 2323 (CMS) Protection of Symmetric Key Package Content Types", 2324 RFC 6160, April 2011. 2326 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 2327 Message Syntax (CMS) Asymmetric Key Package Content Type", 2328 RFC 6162, April 2011. 2330 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 2331 for the Cryptographic Message Syntax (CMS) and the Public 2332 Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 2333 2011. 2335 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 2337 ID NSA's CMS Key Management Attributes December 18, 2013 2339 Information technology - Open Systems Interconnection - 2340 The Directory: Public-key and attribute certificate 2341 frameworks. 2343 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 2344 Information Technology - Abstract Syntax Notation One. 2346 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 2347 Information Technology - Abstract Syntax Notation One: 2348 Information Object Specification. 2350 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 2351 Information Technology - Abstract Syntax Notation One: 2352 Constraint Specification. 2354 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 2355 Information Technology - Abstract Syntax Notation One: 2356 Parameterization of ASN.1 Specifications. 2358 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 2359 Information Technology - ASN.1 encoding rules: 2360 Specification of Basic Encoding Rules (BER), Canonical 2361 Encoding Rules (CER) and Distinguished Encoding Rules 2362 (DER). 2364 [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic 2365 Message Syntax (CMS) Key Package Receipt and Error Content 2366 Types", draft-housley-ct-keypackage-receipt-n-error- 2367 04.txt, (work-in-progress). 2369 34.2 Informative References 2371 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2372 Management Protocol (TAMP)", RFC 5934, August 2010. 2374 [X.411] ITU-T Recommendation X.411 (1988) | ISO/IEC 10021-4:1988, 2375 Data Communication Networks Message Handling Systems - 2376 Message Transfer System - Abstract Service Definition and 2377 Procedures. 2379 ID NSA's CMS Key Management Attributes December 18, 2013 2381 Appendix A. ASN.1 Module 2383 KMAttributes2012 2384 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2385 smime(16) modules(0) 39 } 2387 DEFINITIONS IMPLICIT TAGS ::= 2389 BEGIN 2391 -- EXPORT ALL 2393 IMPORTS 2395 -- From [RFC5911] 2397 aa-communityIdentifiers, CommunityIdentifier 2398 FROM CMSFirmwareWrapper-2009 2399 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2400 smime(16) modules(0) id-mod-cms-firmware-wrap-02(40) } 2402 -- From [RFC5911] 2404 aa-contentHint, ESSSecurityLabel, id-aa-securityLabel 2405 FROM ExtendedSecurityServices-2009 2406 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2407 smime(16) modules(0) id-mod-ess-2006-02(42) } 2409 -- From [RFC5911] [RFC5912] 2411 AlgorithmIdentifier{}, SMIME-CAPS, ParamOptions, KEY-WRAP 2412 FROM AlgorithmInformation-2009 2413 { iso(1) identified-organization(3) dod(6) internet(1) 2414 security(5) mechanisms(5) pkix(7) id-mod(0) 2415 id-mod-algorithmInformation-02(58) } 2417 -- From [RFC5912] 2419 Name, Certificate 2420 FROM PKIX1Explicit-2009 2421 { iso(1) identified-organization(3) dod(6) internet(1) 2422 security(5) mechanisms(5) pkix(7) id-mod(0) 2423 id-mod-pkix1-explicit-02(51) } 2425 ID NSA's CMS Key Management Attributes December 18, 2013 2427 -- From [RFC5912] 2429 GeneralNames, SubjectInfoAccessSyntax, id-pe-subjectInfoAccess 2430 FROM PKIX1Implicit-2009 2431 { iso(1) identified-organization(3) dod(6) internet(1) 2432 security(5) mechanisms(5) pkix(7) id-mod(0) 2433 id-mod-pkix1-implicit-02(59) } 2435 -- FROM [RFC5912] 2437 ATTRIBUTE 2438 FROM PKIX-CommonTypes-2009 2439 { iso(1) identified-organization(3) dod(6) internet(1) 2440 security(5) mechanisms(5) pkix(7) id-mod(0) 2441 id-mod-pkixCommon-02(57) } 2443 -- From [RFC6010] 2445 CMSContentConstraints 2446 FROM CMSContentConstraintsCertExtn 2447 { iso(1) identified-organization(3) dod(6) internet(1) 2448 security(5) mechanisms(5) pkix(7) id-mod(0) 2449 cmsContentConstr-93(42) } 2451 -- From [RFC6268] 2453 aa-binarySigningTime, BinaryTime 2454 FROM BinarySigningTimeModule-2010 2455 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2456 smime(16) modules(0) id-mod-binSigningTime-2009(55) } 2458 -- From [RFC6268] 2460 CertificateChoices, CertificateSet, Attribute {}, 2461 aa-contentType, aa-messageDigest 2462 FROM CryptographicMessageSyntax-2010 2463 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2464 smime(16) modules(0) id-mod-cms-2009(58) } 2466 -- From [ID.housley-keypackage-receipt-n-error] 2468 aa-keyPackageIdentifierAndReceiptRequest, SIREntityName 2469 FROM KeyPackageReceiptAndErrorModuleV2 2470 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2471 smime(16) modules(0) id-mod-keyPkgReceiptAndErrV2(63) } 2473 ID NSA's CMS Key Management Attributes December 18, 2013 2475 -- From [X.509] 2477 certificateExactMatch 2478 FROM CertificateExtensions 2479 { joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4 } 2481 ; 2483 -- ATTRIBUTES 2485 -- Replaces SignedAttributesSet information object set from 2486 -- [RFC6268]. 2488 SignedAttributesSet ATTRIBUTE ::= { 2489 aa-contentType | 2490 aa-messageDigest | 2491 aa-contentHint | 2492 aa-communityIdentifiers | 2493 aa-binarySigningTime | 2494 aa-keyProvince-v2 | 2495 aa-keyPackageIdentifierAndReceiptRequest | 2496 aa-manifest | 2497 aa-keyAlgorithm | 2498 aa-userCertificate | 2499 aa-keyPackageReceivers-v2 | 2500 aa-tsecNomenclature | 2501 aa-keyPurpose | 2502 aa-keyUse | 2503 aa-transportKey | 2504 aa-keyDistributionPeriod | 2505 aa-keyValidityPeriod | 2506 aa-keyDurationPeriod | 2507 aa-classificationAttribute | 2508 aa-keyPackageType | 2509 aa-pkiPath | 2510 aa-usefulCertificates, 2511 ... } 2513 -- Replaces UnsignedAttributes from [RFC6268]. 2515 UnsignedAttributes ATTRIBUTE ::= { 2516 ... 2517 } 2519 ID NSA's CMS Key Management Attributes December 18, 2013 2521 -- Replaces UnprotectedEnvAttributes from [RFC6268]. 2523 UnprotectedEnvAttributes ATTRIBUTE ::= { 2524 aa-contentDecryptKeyIdentifier | 2525 aa-certificatePointers | 2526 aa-cRLDistributionPoints, 2527 ... 2528 } 2530 -- Replaces UnprotectedEncAttributes from [RFC6268]. 2532 UnprotectedEncAttributes ATTRIBUTE ::= { 2533 aa-certificatePointers | 2534 aa-cRLDistributionPoints, 2535 ... 2536 } 2538 -- Replaces AuthAttributeSet from [RFC6268] 2540 AuthAttributeSet ATTRIBUTE ::= { 2541 aa-contentType | 2542 aa-messageDigest | 2543 aa-contentHint | 2544 aa-communityIdentifiers | 2545 aa-keyProvice-v2 | 2546 aa-binarySigningTime | 2547 aa-keyPackageIdentifierAndReceiptRequest | 2548 aa-manifest | 2549 aa-keyAlgorithm | 2550 aa-userCertificate | 2551 aa-keyPackageReceivers-v2 | 2552 aa-tsecNomenclature | 2553 aa-keyPurpose | 2554 aa-keyUse | 2555 aa-transportKey | 2556 aa-keyDistributionPeriod | 2557 aa-keyValidityPeriod | 2558 aa-keyDurationPeriod | 2559 aa-classificationAttribute | 2560 aa-keyPackageType | 2561 aa-pkiPath | 2562 aa-usefulCertificates, 2563 ... } 2565 ID NSA's CMS Key Management Attributes December 18, 2013 2567 -- Replaces UnauthAttributeSet from [RFC6268] 2569 UnauthAttributeSet ATTRIBUTE ::= { 2570 ... 2571 } 2573 -- Replaces AuthEnvDataAttributeSet from [RFC6268] 2575 AuthEnvDataAttributeSet ATTRIBUTE ::= { 2576 aa-certificatePointers | 2577 aa-cRLDistributionPoints, 2578 ... 2579 } 2581 -- Replaces UnauthEnvDataAttributeSet from [RFC6268] 2583 UnauthEnvDataAttributeSet ATTRIBUTE ::= { 2584 ... 2585 } 2587 -- Replaces OneAsymmetricKeyAttributes from [RFC5958] 2589 OneAsymmetricKeyAttributes ATTRIBUTE ::= { 2590 aa-userCertificate | 2591 aa-tsecNomenclature | 2592 aa-keyPurpose | 2593 aa-keyUse | 2594 aa-transportKey | 2595 aa-keyDistributionPeriod | 2596 aa-keyValidityPeriod | 2597 aa-keyDurationPeriod | 2598 aa-classificationAttribute | 2599 aa-splitIdentifier | 2600 aa-signatureUsage-v3 | 2601 aa-otherCertificateFormats | 2602 aa-pkiPath | 2603 aa-usefulCertificates, 2604 ... } 2606 ID NSA's CMS Key Management Attributes December 18, 2013 2608 -- Replaces SKeyPkgAttributes from [RFC6031] 2610 SKeyPkgAttributes ATTRIBUTE ::= { 2611 aa-keyAlgorithm | 2612 aa-tsecNomenclature | 2613 aa-keyPurpose | 2614 aa-keyUse | 2615 aa-keyDistributionPeriod | 2616 aa-keyValidityPeriod | 2617 aa-keyDurationPeriod | 2618 aa-classificationAttribute | 2619 aa-keyWrapAlgorithm | 2620 aa-contentDecryptKeyIdentifier, 2621 ... } 2623 -- Replaces SKeyAttributes from [RFC6031] 2625 SKeyAttributes ATTRIBUTE ::= { 2626 aa-keyAlgorithm | 2627 aa-tsecNomenclature | 2628 aa-keyPurpose | 2629 aa-keyUse | 2630 aa-keyDistributionPeriod | 2631 aa-keyValidityPeriod | 2632 aa-keyDurationPeriod | 2633 aa-classificationAttribute | 2634 aa-splitIdentifier | 2635 aa-keyWrapAlgorithm | 2636 aa-contentDecryptKeyIdentifier, 2637 ... } 2639 ID NSA's CMS Key Management Attributes December 18, 2013 2641 -- Replaces ContentAttributeSet from [RFC6268] 2643 ContentAttributeSet ATTRIBUTE ::= { 2644 aa-communityIdentifiers | 2645 aa-keyPackageIdentifierAndReceiptRequest | 2646 aa-keyAlgorithm | 2647 aa-keyPackageReceivers-v2 | 2648 aa-tsecNomenclature | 2649 aa-keyPurpose | 2650 aa-keyUse | 2651 aa-transportKey | 2652 aa-keyDistributionPeriod | 2653 aa-transportKey | 2654 aa-keyDistributionPeriod | 2655 aa-keyValidityPeriod | 2656 aa-keyDurationPeriod | 2657 aa-classificationAttribute | 2658 aa-keyPackageType | 2659 aa-pkiPath | 2660 aa-usefulCertificates, 2661 ... } 2663 -- Content Type, Message Digest, and Content Hint, and Binary Signing 2664 -- Time are imported from [RFC6268]. 2665 -- Community Identifiers is imported from [RFC5911]. 2667 -- Key Province 2669 aa-keyProvince-v2 ATTRIBUTE ::= { 2670 TYPE KeyProvinceV2 2671 IDENTIFIED BY id-aa-KP-keyProvinceV2 } 2673 id-aa-KP-keyProvinceV2 OBJECT IDENTIFIER ::= 2674 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2675 dod(2) infosec(1) attributes(5) 71 } 2677 KeyProvinceV2 ::= OBJECT IDENTIFIER 2679 -- Manifest Attribute 2681 aa-manifest ATTRIBUTE ::= { 2682 TYPE Manifest 2683 IDENTIFIED BY id-aa-KP-manifest } 2685 id-aa-KP-manifest OBJECT IDENTIFIER ::= 2686 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2687 dod(2) infosec(1) attributes(5) 72 } 2689 ID NSA's CMS Key Management Attributes December 18, 2013 2691 Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle 2693 -- Key Algorithm Attribute 2695 aa-keyAlgorithm ATTRIBUTE ::= { 2696 TYPE KeyAlgorithm 2697 IDENTIFIED BY id-kma-keyAlgorithm } 2699 id-kma-keyAlgorithm OBJECT IDENTIFIER ::= 2700 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2701 dod(2) infosec(1) keying-material-attributes(13) 1 } 2703 KeyAlgorithm ::= SEQUENCE { 2704 keyAlg OBJECT IDENTIFIER, 2705 checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL, 2706 crcAlg [2] OBJECT IDENTIFIER OPTIONAL } 2708 -- User Certificate Attribute 2710 aa-userCertificate ATTRIBUTE ::= { 2711 TYPE Certificate 2712 EQUALITY MATCHING RULE certificateExactMatch 2713 IDENTIFIED BY id-at-userCertificate } 2715 id-at-userCertificate OBJECT IDENTIFIER ::= 2716 { joint-iso-itu-t(2) ds(5) attributes(4) 36 } 2718 -- Key Package Receivers Attribute 2720 aa-keyPackageReceivers-v2 ATTRIBUTE ::= { 2721 TYPE KeyPkgReceiversV2 2722 IDENTIFIED BY id-kma-keyPkgReceiversV2 } 2724 id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= 2725 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2726 dod(2) infosec(1) keying-material-attributes(13) 16 } 2728 KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver 2730 KeyPkgReceiver ::= CHOICE { 2731 sirEntity [0] SIREntityName, 2732 community [1] CommunityIdentifier } 2734 ID NSA's CMS Key Management Attributes December 18, 2013 2736 -- TSEC Nomenclature Attribute 2738 aa-tsecNomenclature ATTRIBUTE ::= { 2739 TYPE TSECNomenclature 2740 IDENTIFIED BY id-kma-TSECNomenclature } 2742 id-kma-TSECNomenclature OBJECT IDENTIFIER ::= 2743 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2744 dod(2) infosec(1) keying-material-attributes(13) 3 } 2746 TSECNomenclature ::= SEQUENCE { 2747 shortTitle ShortTitle, 2748 editionID EditionID OPTIONAL, 2749 registerID RegisterID OPTIONAL, 2750 segmentID SegmentID OPTIONAL } 2752 ShortTitle ::= PrintableString 2754 EditionID ::= CHOICE { 2755 char CHOICE { 2756 charEdition [1] CharEdition, 2757 charEditionRange [2] CharEditionRange }, 2758 num CHOICE { 2759 numEdition [3] NumEdition, 2760 numEditionRange [4] NumEditionRange } } 2762 CharEdition ::= PrintableString 2764 CharEditionRange ::= SEQUENCE { 2765 firstCharEdition CharEdition, 2766 lastCharEdition CharEdition } 2768 NumEdition ::= INTEGER (0..308915776) 2770 NumEditionRange ::= SEQUENCE { 2771 firstNumEdition NumEdition, 2772 lastNumEdition NumEdition } 2774 RegisterID ::= CHOICE { 2775 register [5] Register, 2776 registerRange [6] RegisterRange } 2778 Register ::= INTEGER (0..2147483647) 2780 RegisterRange ::= SEQUENCE { 2781 firstRegister Register, 2782 lastRegister Register } 2784 ID NSA's CMS Key Management Attributes December 18, 2013 2786 SegmentID ::= CHOICE { 2787 segmentNumber [7] SegmentNumber, 2788 segmentRange [8] SegmentRange } 2790 SegmentNumber ::= INTEGER (1..127) 2792 SegmentRange ::= SEQUENCE { 2793 firstSegment SegmentNumber, 2794 lastSegment SegmentNumber } 2796 -- Key Purpose Attribute 2798 aa-keyPurpose ATTRIBUTE ::= { 2799 TYPE KeyPurpose 2800 IDENTIFIED BY id-kma-keyPurpose } 2802 id-kma-keyPurpose OBJECT IDENTIFIER ::= 2803 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2804 dod(2) infosec(1) keying-material-attributes(13) 13 } 2806 KeyPurpose ::= ENUMERATED { 2807 n-a (0), -- Not Applicable 2808 a (65), -- Operational 2809 b (66), -- Compatible Multiple Key 2810 l (76), -- Logistics Combinations 2811 m (77), -- Maintenance 2812 r (82), -- Reference 2813 s (83), -- Sample 2814 t (84), -- Training 2815 v (86), -- Developmental 2816 x (88), -- Exercise 2817 z (90), -- "On the Air" Testing 2818 ... -- Expect additional key purpose values -- } 2820 -- Key Use Attribute 2822 aa-keyUse ATTRIBUTE ::= { 2823 TYPE KeyUse 2824 IDENTIFIED BY id-kma-keyUse } 2826 id-kma-keyUse OBJECT IDENTIFIER ::= 2827 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2828 dod(2) infosec(1) keying-material-attributes(13) 14 } 2830 ID NSA's CMS Key Management Attributes December 18, 2013 2832 KeyUse ::= ENUMERATED { 2833 n-a (0), -- Not Applicable 2834 ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format) 2835 kek (2), -- Key Encryption Key 2836 kpk (3), -- Key Production Key 2837 msk (4), -- Message Signature Key 2838 qkek (5), -- QUADRANT Key Encryption Key 2839 tek (6), -- Traffic Encryption Key 2840 tsk (7), -- Transmission Security Key 2841 trkek (8), -- Transfer Key Encryption Key 2842 nfk (9), -- Netted FIREFLY Key 2843 effk (10), -- FIREFLY Key (Enhanced Format) 2844 ebfk (11), -- FIREFLY Key (Enhanceable Basic Format) 2845 aek (12), -- Algorithm Encryption Key 2846 wod (13), -- Word of Day 2847 kesk (246), -- Key Establishment Key 2848 eik (247), -- Entity Identification Key 2849 ask (248), -- Authority Signature Key 2850 kmk (249), -- Key Modifier Key 2851 rsk (250), -- Revocation Signature Key 2852 csk (251), -- Certificate Signature Key 2853 sak (252), -- Symmetric Authentication Key 2854 rgk (253), -- Random Generation Key 2855 cek (254), -- Certificate Encryption Key 2856 exk (255), -- Exclusion Key 2857 ... -- Expect additional key use values -- } 2859 -- Transport Key Attribute 2861 aa-transportKey ATTRIBUTE ::= { 2862 TYPE TransOp 2863 IDENTIFIED BY id-kma-transportKey } 2865 id-kma-transportKey OBJECT IDENTIFIER ::= 2866 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2867 dod(2) infosec(1) keying-material-attributes(13) 15 } 2869 TransOp ::= ENUMERATED { 2870 transport (1), 2871 operational (2) } 2873 -- Key Distribution Period Attribute 2875 aa-keyDistributionPeriod ATTRIBUTE ::= { 2876 TYPE KeyDistPeriod 2877 IDENTIFIED BY id-kma-keyDistPeriod } 2879 ID NSA's CMS Key Management Attributes December 18, 2013 2881 id-kma-keyDistPeriod OBJECT IDENTIFIER ::= 2882 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2883 dod(2) infosec(1) keying-material-attributes(13) 5 } 2885 KeyDistPeriod ::= SEQUENCE { 2886 doNotDistBefore [0] BinaryTime OPTIONAL, 2887 doNotDistAfter BinaryTime } 2889 -- Key Validity Period Attribute 2891 aa-keyValidityPeriod ATTRIBUTE ::= { 2892 TYPE KeyValidityPeriod 2893 IDENTIFIED BY id-kma-keyValidityPeriod } 2895 id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= 2896 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2897 dod(2) infosec(1) keying-material-attributes(13) 6 } 2899 KeyValidityPeriod ::= SEQUENCE { 2900 doNotUseBefore BinaryTime, 2901 doNotUseAfter BinaryTime OPTIONAL } 2903 -- Key Duration Attribute 2905 aa-keyDurationPeriod ATTRIBUTE ::= { 2906 TYPE KeyDuration 2907 IDENTIFIED BY id-kma-keyDuration } 2909 id-kma-keyDuration OBJECT IDENTIFIER ::= 2910 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2911 dod(2) infosec(1) keying-material-attributes(13) 7 } 2913 KeyDuration ::= CHOICE { 2914 hours [0] INTEGER (1..ub-KeyDuration-hours), 2915 days INTEGER (1..ub-KeyDuration-days), 2916 weeks [1] INTEGER (1..ub-KeyDuration-weeks), 2917 months [2] INTEGER (1..ub-KeyDuration-months), 2918 years [3] INTEGER (1..ub-KeyDuration-years) } 2920 ub-KeyDuration-hours INTEGER ::= 96 2921 ub-KeyDuration-days INTEGER ::= 732 2922 ub-KeyDuration-weeks INTEGER ::= 104 2923 ub-KeyDuration-months INTEGER ::= 72 2924 ub-KeyDuration-years INTEGER ::= 100 2926 ID NSA's CMS Key Management Attributes December 18, 2013 2928 -- Classification Attribute 2930 -- The attribute syntax is imported from [RFC6268]. The term 2931 -- "classification" is used in this document, but the term "security 2932 -- label" is used in [RFC2634]. The terms have the same meaning. 2934 aa-classificationAttribute ATTRIBUTE ::= { 2935 TYPE Classification 2936 IDENTIFIED BY id-aa-KP-classification } 2938 id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel 2940 Classification ::= ESSSecurityLabel 2942 id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= 2943 { 2 16 840 1 101 2 1 8 3 4 } 2945 id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= 2946 { 2 16 840 1 101 2 1 8 3 1 } 2948 EnumeratedTag ::= SEQUENCE { 2949 tagName OBJECT IDENTIFIER, 2950 attributeList SET OF SecurityAttribute } 2952 SecurityAttribute ::= INTEGER (0..MAX) 2954 -- Split Identifier Attribute 2956 aa-splitIdentifier ATTRIBUTE ::= { 2957 TYPE SplitID 2958 IDENTIFIED BY id-kma-splitID } 2960 id-kma-splitID OBJECT IDENTIFIER ::= 2961 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2962 dod(2) infosec(1) keying-material-attributes(13) 11 } 2964 SplitID ::= SEQUENCE { 2965 half ENUMERATED { a(0), b(1) }, 2966 combineAlg AlgorithmIdentifier 2967 {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL } 2969 ID NSA's CMS Key Management Attributes December 18, 2013 2971 COMBINE-ALGORITHM ::= CLASS { 2972 &id OBJECT IDENTIFIER UNIQUE, 2973 &Params OPTIONAL, 2974 ¶mPresence ParamOptions DEFAULT absent, 2975 &smimeCaps SMIME-CAPS OPTIONAL 2976 } 2977 WITH SYNTAX { 2978 IDENTIFIER &id 2979 [PARAMS [TYPE &Params] ARE ¶mPresence] 2980 [SMIME-CAPS &smimeCaps] 2981 } 2983 CombineAlgorithms COMBINE-ALGORITHM ::= { 2984 ... 2985 } 2987 -- Key Package Type Attribute 2989 aa-keyPackageType ATTRIBUTE ::= { 2990 TYPE KeyPkgType 2991 IDENTIFIED BY id-kma-keyPkgType } 2993 id-kma-keyPkgType OBJECT IDENTIFIER ::= 2994 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2995 dod(2) infosec(1) keying-material-attributes(13) 12 } 2997 KeyPkgType ::= OBJECT IDENTIFIER 2999 -- Signature Usage Attribute 3001 aa-signatureUsage-v3 ATTRIBUTE ::= { 3002 TYPE SignatureUsage 3003 IDENTIFIED BY id-kma-sigUsageV3 } 3005 id-kma-sigUsageV3 OBJECT IDENTIFIER ::= 3006 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3007 dod(2) infosec(1) keying-material-attributes(13) 22 } 3009 SignatureUsage ::= CMSContentConstraints 3011 -- Other Certificate Format Attribute 3013 aa-otherCertificateFormats ATTRIBUTE ::= { 3014 TYPE CertificateChoices 3015 IDENTIFIED BY id-kma-otherCertFormats } 3017 ID NSA's CMS Key Management Attributes December 18, 2013 3019 id-kma-otherCertFormats OBJECT IDENTIFIER ::= 3020 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3021 dod(2) infosec(1) keying-material-attributes(13) 19 } 3023 -- PKI Path Attribute 3025 aa-pkiPath ATTRIBUTE ::= { 3026 TYPE PkiPath 3027 IDENTIFIED BY id-at-pkiPath } 3029 id-at-pkiPath OBJECT IDENTIFIER ::= 3030 { joint-iso-itu-t(2) ds(5) attributes(4) 70 } 3032 PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate 3034 -- Useful Certificates Attribute 3036 aa-usefulCertificates ATTRIBUTE ::= { 3037 TYPE CertificateSet 3038 IDENTIFIED BY id-kma-usefulCerts } 3040 id-kma-usefulCerts OBJECT IDENTIFIER ::= 3041 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3042 dod(2) infosec(1) keying-material-attributes(13) 20 } 3044 -- Key Wrap Attribute 3046 aa-keyWrapAlgorithm ATTRIBUTE ::= { 3047 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}} 3048 IDENTIFIED BY id-kma-keyWrapAlgorithm } 3050 id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= 3051 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3052 dod(2) infosec(1) keying-material-attributes(13) 21 } 3054 KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... } 3056 -- Content Decryption Key Identifier Attribute 3058 aa-contentDecryptKeyIdentifier ATTRIBUTE ::= { 3059 TYPE ContentDecryptKeyID 3060 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 3062 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= 3063 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3064 dod(2) infosec(1) attributes(5) 66 } 3066 ContentDecryptKeyID::= OCTET STRING 3068 ID NSA's CMS Key Management Attributes December 18, 2013 3070 -- Certificate Pointers Attribute 3072 aa-certificatePointers ATTRIBUTE ::= { 3073 TYPE SubjectInfoAccessSyntax 3074 IDENTIFIED BY id-pe-subjectInfoAccess } 3076 -- CRL Pointers Attribute 3078 aa-cRLDistributionPoints ATTRIBUTE ::= { 3079 TYPE GeneralNames 3080 IDENTIFIED BY id-aa-KP-crlPointers } 3082 id-aa-KP-crlPointers OBJECT IDENTIFIER ::= 3083 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3084 dod(2) infosec(1) attributes (5) 70 } 3086 -- ExtendedErrorCodes 3088 id-errorCodes OBJECT IDENTIFIER ::= 3089 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3090 dod(2) infosec(1) errorCodes(22) } 3092 id-missingKeyType OBJECT IDENTIFIER ::= { 3093 id-errorCodes 1 } 3095 id-privacyMarkTooLong OBJECT IDENTIFIER ::= { 3096 id-errorCodes 2 } 3098 id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= { 3099 id-errorCodes 3 } 3101 END 3103 ID NSA's CMS Key Management Attributes December 18, 2013 3105 Authors' Addresses 3107 Paul Timmel 3108 National Information Assurance Research Laboratory 3109 National Security Agency 3111 Email: pstimme@tycho.ncsc.mil 3113 Russ Housley 3114 Vigil Security, LLC 3115 918 Spring Knoll Drive 3116 Herndon, VA 20170 3117 USA 3119 Email: : housley@vigilsec.com 3121 Sean Turner 3122 IECA, Inc. 3123 3057 Nutley Street, Suite 106 3124 Fairfax, VA 22031 3125 USA 3127 Email: turners@ieca.com