idnits 2.17.1 draft-turner-km-attributes-05.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 1884 has weird spacing: '...alue of the k...' -- The document date (November 10, 2014) is 3452 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2919 -- Looks like a reference, but probably isn't: '2' on line 2920 -- Looks like a reference, but probably isn't: '0' on line 2917 -- Looks like a reference, but probably isn't: '3' on line 2921 -- Looks like a reference, but probably isn't: '4' on line 2763 -- Looks like a reference, but probably isn't: '5' on line 2778 -- Looks like a reference, but probably isn't: '6' on line 2779 -- Looks like a reference, but probably isn't: '7' on line 2790 -- Looks like a reference, but probably isn't: '8' on line 2791 Summary: 0 errors (**), 0 flaws (~~), 2 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: May 14, 2015 Vigil Security 6 S. Turner 7 IECA 8 November 10, 2014 10 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes 11 draft-turner-km-attributes-05.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) 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 [RFC7191] or a CommunityIdentifier (see Section 3). The 525 SIREntityName syntax does not impose any particular structure on the 526 receiver identifier, but it does require registration of receiver 527 identifier types. The nameType ensures that two receiver identifiers 528 of different types that contain the same values are not interpreted 529 as equivalent. Name types are expected to be defined that represent 530 several different granularities. For example, one name type will 531 represent the receiver organization. At a finer granularity, the 532 name type will identify a specific cryptographic device, perhaps 533 using a manufacturer identifier and serial number. 535 If a receiver does not recognize a particular nameType or a community 536 identifier, then keying material within the scope of the unrecognized 537 nameType or community identifier MUST NOT be used in any manner. 538 However, the receiver need not discard the associated key package. 539 Since many cryptographic devices are programmable, a different 540 firmware load may recognize the nameType. Likewise, a change in the 541 configuration may lead to the recognition of a previously 542 unrecognized community identifier. Therefore, the receiver may 543 retain the key package, but refuse to use it for anything with a 544 firmware load that does not recognize the nameType or a configuration 545 that does not recognize the community identifier. 547 Whenever a key package is saved for later processing due to an 548 unrecognized nameType or community identifier, subsequent processing 549 MUST NOT rely on any checks that were made the first time the key 551 ID NSA's CMS Key Management Attributes November 10, 2014 553 package processing was attempted. That is, the subsequent processing 554 MUST include the full complement of checks. Further, a receipt for 555 the packages MUST NOT be generated unless all of these checks are 556 successfully completed. 558 Due to multiple layers of encapsulation or the use of content 559 collections, the key-package-receivers-v2 attribute can appear in 560 more than one location in the overall key package. When there are 561 multiple occurrences of the key-package-receivers-v2 attribute, each 562 occurrence is evaluated independently. 564 In a content collection, each member of the collection might contain 565 its own signed, authenticated, authenticated/unprotected, or content 566 attribute that includes a key-package-receivers-v2 attribute. In 567 this situation, each member of the collection is evaluated 568 separately, and any member that includes an acceptable receiver 569 SHOULD be retained. Other members SHOULD be rejected or retained for 570 later processing with a different firmware load. 572 10. TSEC Nomenclature 574 The Telecommunications Security Nomenclature (TSEC-Nomenclature) 575 attribute provides the name for a piece of keying material, which 576 always includes the short title. The TSEC-Nomenclature attribute 577 also contains other identifiers when the short title is insufficient 578 to uniquely name a particular piece of keying material. This 579 attribute can appear as a symmetric key, symmetric key package, 580 asymmetric key, signed, authenticated, authenticated/unprotected, or 581 content attribute. If this attribute appears in the sKeyAttrs field, 582 the EditionID, RegisterID, and SegmentID attribute fields MUST NOT be 583 ranges. If this attribute appears as a signed, authenticated, 584 authenticated/unprotected, or content attribute, all of the keying 585 material within the associated content MUST have the same short 586 title, and the attribute value MUST contain only a short title. That 587 is, when this attribute appears as a signed, authenticated, 588 authenticated/unprotected, or content attribute, all of the optional 589 fields MUST be absent. If this attribute is associated with a 590 collection, all of the keying material within the collection MUST 591 have the same short title; however, the edition, register, and 592 segment identifiers will be different for each key package in the 593 collection. This attribute MUST be supported. 595 The TSEC-Nomenclature attribute has the following syntax: 597 aa-tsecNomenclature ATTRIBUTE ::= { 598 TYPE TSECNomenclature 599 IDENTIFIED BY id-kma-TSECNomenclature } 601 ID NSA's CMS Key Management Attributes November 10, 2014 603 id-kma-TSECNomenclature OBJECT IDENTIFIER ::= { 604 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 605 dod(2) infosec(1) keying-material-attributes(13) 3 } 607 TSECNomenclature ::= SEQUENCE { 608 shortTitle ShortTitle, 609 editionID EditionID OPTIONAL, 610 registerID RegisterID OPTIONAL, 611 segmentID SegmentID OPTIONAL } 613 ShortTitle ::= PrintableString 615 EditionID ::= CHOICE { 616 char CHOICE { 617 charEdition [1] CharEdition, 618 charEditionRange [2] CharEditionRange } 619 num CHOICE { 620 numEdition [3] NumEdition, 621 numEditionRange [4] NumEditionRange } } 623 CharEdition ::= PrintableString 625 CharEditionRange ::= SEQUENCE { 626 firstCharEdition CharEdition, 627 lastCharEdition CharEdition } 629 NumEdition ::= INTEGER (0..308915776) 631 NumEditionRange ::= SEQUENCE { 632 firstNumEdition NumEdition, 633 lastNumEdition NumEdition } 635 RegisterID ::= CHOICE { 636 register [5] Register, 637 registerRange [6] RegisterRange } 639 Register ::= INTEGER (0..2147483647) 641 RegisterRange ::= SEQUENCE { 642 firstRegister Register, 643 lastRegister Register } 645 SegmentID ::= CHOICE { 646 segmentNumber [7] SegmentNumber, 647 segmentRange [8] SegmentRange } 649 SegmentNumber ::= INTEGER (1..127) 651 ID NSA's CMS Key Management Attributes November 10, 2014 653 SegmentRange ::= SEQUENCE { 654 firstSegment SegmentNumber, 655 lastSegment SegmentNumber } 657 The fields in the TSEC-Nomenclature attribute have the following 658 semantics: 660 o The short title consists of up to 32 alphanumeric characters. 661 Short title processing always uses the value in its entirety. 663 o The edition identifier is OPTIONAL, and the edition identifier is 664 used to distinguish accountable items. The edition identifier 665 consists either of six alphanumeric characters or an integer. 666 When present, the edition identifier is either a single value or 667 a range. The integer encoding should be used when it is 668 important to keep key package size to a minimum. 670 o The register identifier is OPTIONAL. For electronic keying 671 material, the register identifier is usually omitted. The 672 register identifier is an accounting number assigned to identify 673 COMSEC material. The register identifier is either a single 674 value or a range. 676 o The segment identifier is OPTIONAL, and it distinguishes the 677 individual symmetric keys delivered in one edition. A unique 678 segment number is assigned to each key in an edition. The 679 segment number is set to one for the first item in each edition, 680 and it is incremented by one for each additional item within that 681 edition. The segment identifier is either a single value or a 682 range. 684 The order that the keying material will appear in the key package is 685 illustrated by the following example. A cryptographic device may 686 require fresh keying material every day. An edition represents the 687 keying material for a single month, and the segments represent the 688 keying material for a day within that month. Consider a key package 689 that contains the keying material for July and August; it will 690 contain keying material for 62 days. The keying material will appear 691 in the following order: Edition 1, Segment 1; Edition 1, Segment 2; 692 Edition 1, Segment 3; ...; Edition 1, Segment 31; Edition 2, Segment 693 1; Edition 2, Segment 2; Edition 2, Segment 3; ...; Edition 2, 694 Segment 31. 696 Due to multiple layers of encapsulation or the use of content 697 collections, the TSEC-Nomenclature attribute can appear in more than 698 one location in the overall key package. When there are multiple 699 occurrences of the TSEC-Nomenclature attribute within the same scope, 700 the shortTitle field MUST match in all instances. Recall that the 702 ID NSA's CMS Key Management Attributes November 10, 2014 704 optional parts MUST be omitted when the TSEC-Nomenclature attribute 705 appears as a signed, authenticated, authenticated/unprotected, or 706 content attribute. Receivers MUST reject any key package that fails 707 these consistency checks. 709 When the manifest attribute from Section 6 is included in an outer 710 layer, the shortTitle field values present in TSEC-Nomenclature 711 attributes MUST be one of the values in the manifest attribute. 712 Receivers MUST reject any key package that fails this consistency 713 checks. 715 11. Key Purpose 717 The key-purpose attribute specifies the intended purpose of the key 718 material. It can appear as a symmetric key, symmetric key package, 719 asymmetric key, signed, authenticated, authenticated/unprotected, or 720 content attribute. If the key-purpose attribute appears as a signed, 721 authenticated, authenticated/unprotected, or content attribute, then 722 all of the keying material within the associated content MUST have 723 the same key purpose value. 725 The key-purpose attribute has the following syntax: 727 aa-keyPurpose ATTRIBUTE ::= { 728 TYPE KeyPurpose 729 IDENTIFIED BY id-kma-keyPurpose } 731 id-kma-keyPurpose OBJECT IDENTIFIER ::= { 732 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 733 dod(2) infosec(1) keying-material-attributes(13) 13 } 735 KeyPurpose ::= ENUMERATED { 736 n-a (0), -- Not Applicable 737 a (65), -- Operational 738 b (66), -- Compatible Multiple Key 739 l (76), -- Logistics Combinations 740 m (77), -- Maintenance 741 r (82), -- Reference 742 s (83), -- Sample 743 t (84), -- Training 744 v (86), -- Developmental 745 x (88), -- Exercise 746 z (90), -- "On the Air" Testing 747 ... -- Expect additional key purpose values -- } 749 Due to multiple layers of encapsulation or the use of content 750 collections, the key-purpose attribute can appear in more than one 751 location in the overall key package. When there are multiple 753 ID NSA's CMS Key Management Attributes November 10, 2014 755 occurrences of the key-purpose attribute within the same scope, all 756 fields within the attribute MUST contain exactly the same values. 757 Receivers MUST reject any key package that fails these consistency 758 checks. 760 12. Key Use 762 The key-use attribute specifies the intended use of the key material. 763 It can appear as a symmetric key, symmetric key package, asymmetric, 764 signed, authenticated, authenticated/unprotected, or content 765 attribute. If the key-use attribute appears as a signed, 766 authenticated, authenticated/unprotected, or content attribute, then 767 all of the keying material within the associated content MUST have 768 the same key use value. 770 The key-use attribute has the following syntax: 772 aa-key-Use ATTRIBUTE ::= { 773 TYPE KeyUse 774 IDENTIFIED BY id-kma-keyUse } 776 id-kma-keyUse OBJECT IDENTIFIER ::= { 777 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 778 dod(2) infosec(1) keying-material-attributes(13) 14 } 780 KeyUse ::= ENUMERATED { 781 n-a (0), -- Not applicable 782 ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format) 783 kek (2), -- Key Encryption Key 784 kpk (3), -- Key Production Key 785 msk (4), -- Message Signature Key 786 qkek (5), -- QUADRANT Key Encryption Key 787 tek (6), -- Traffic Encryption Key 788 tsk (7), -- Transmission Security Key 789 trkek (8), -- Transfer Key Encryption Key 790 nfk (9), -- Netted FIREFLY Key 791 effk (10), -- FIREFLY Key (Enhanced Format) 792 ebfk (11), -- FIREFLY Key (Enhanceable Basic Format) 793 aek (12), -- Algorithm Encryption Key 794 wod (13), -- Word of Day 795 kesk (246), -- Key Establishment Key 796 eik (247), -- Entity Identification Key 797 ask (248), -- Authority Signature Key 798 kmk (249), -- Key Modifier Key 799 rsk (250), -- Revocation Signature Key 800 csk (251), -- Certificate Signature Key 801 sak (252), -- Symmetric Authentication Key 802 rgk (253), -- Random Generation Key 804 ID NSA's CMS Key Management Attributes November 10, 2014 806 cek (254), -- Certificate Encryption Key 807 exk (255), -- Exclusion Key 808 ... -- Expect additional key use values -- } 810 The values for the key-use attribute has the following semantics: 812 o ffk: A FIREFLY/CROSSTALK key is used to establish a Key 813 Establishment Key (KEK) or a Transmission Encryption Key (TEK) 814 between two parties. The KEK or TEK generated from the exchange 815 is used with a symmetric encryption algorithm. This key use 816 value is associated with keys in the basic format. 818 o kek: A Key Encryption Key is used to encrypt or decrypt other 819 keys for transmission or storage. 821 o kpk: A Key Production Key is used to initialize a keystream 822 generator for the production of other electronically generated 823 keys. 825 o msk: A Message Signature Key is used in a digital signature 826 process that operates on a message to assure message source 827 authentication, message integrity, and non-repudiation. 829 o qkek: QUADRANT Key Encryption Key is one part of a tamper 830 resistance solution. 832 o tek: A Traffic Encryption Key is used to encrypt plaintext or to 833 superencrypt previously encrypted data and/or to decrypt 834 ciphertext. 836 o tsk: A Transmission Security Key is used to protect transmissions 837 from interception and exploitation by means other than 838 cryptanalysis. 840 o trkek: Transfer Key Encryption Key. For example, the keys used 841 by the KP and DTD. 843 o nfk: A Netted FIREFLY Key is a FIREFLY key that has an edition 844 number associated with it. When rekeyed, it is incremented, 845 preventing communications with FIREFLY key of previous editions. 846 This edition number is maintained within a universal edition. 848 o effk: Enhanced FIREFLY Key is used to establish a KEK or a TEK 849 between two parties. The KEK or TEK generated from an exchange 850 is used with a symmetric encryption algorithm. This key use 851 value is associated with keys in the enhanced format. 853 o ebfk: Enhanceable Basic FIREFLY Key is used to establish a KEK or 855 ID NSA's CMS Key Management Attributes November 10, 2014 857 a TEK between two parties. The KEK or TEK generated from an 858 exchange is used with a symmetric encryption algorithm. This key 859 use value is associated with keys in the enhanceable basic 860 format. 862 o aek: An Algorithm Encryption Key is used to encrypt or decrypt an 863 algorithm implementation as well as other functionality in the 864 implementation. 866 o wod: A key used to generate the Word of the Day (WOD). 868 o kek: A Key Establishment Key is an asymmetric key set (e.g. 869 public/private/parameters) used to enable the establishment of 870 symmetric key(s) between entities. 872 o eik: An Entity Identification Key is an asymmetric key set (e.g. 873 public/private/parameters) used to identify one entity to another 874 for access control and other similar purposes. 876 o ask: An Authority Signature Key is an asymmetric key set (e.g. 877 public/private/parameters) used by designated authorities to sign 878 objects such as TAMP messages and firmware packages. 880 o kmk: A Key Modifier Key is a symmetric key used to modify the 881 results of the process that forms a symmetric key from a public 882 key exchange process. 884 o rsk: A Revocation Signature Key is an asymmetric key set (e.g. 885 public/private/parameters) used to sign and authenticate 886 revocation lists and compromised key lists. 888 o csk: A Certificate Signature Key is an asymmetric key set (e.g. 889 public/private/parameters) used to sign and authenticate public- 890 key certificates. 892 o sak: A Symmetric Authentication Key is used in a Message 893 Authentication Code (MAC) algorithm to provide message integrity. 894 Differs from a Message Signature Key in that it is symmetric key 895 material and it does not provide source authentication or non- 896 repudiation. 898 o rgk: Random Generation Key is a key used to seed a deterministic 899 pseudo-random number generator. 901 o cek: A Certificate Encryption Key is used to encrypt public-key 902 certificates to support privacy. 904 o exk: An Exclusion Key is a symmetric key used to 906 ID NSA's CMS Key Management Attributes November 10, 2014 908 cryptographically subdivide a single large security domain into 909 smaller segregated domains. 911 Due to multiple layers of encapsulation or the use of content 912 collections, the key-use attribute can appear in more than one 913 location in the overall key package. When there are multiple 914 occurrences of the key-use attribute within the same scope, all 915 fields within the attribute MUST contain exactly the same values. 916 Receivers MUST reject any key package that fails these consistency 917 checks. 919 13. Transport Key 921 The transport-key attribute identifies whether an asymmetric key is a 922 transport key or an operational key (i.e., the key can either be used 923 as is or not). It can appear as an asymmetric key, signed, 924 authenticated, authenticated/unprotected, or content attribute. If 925 the transport-key attribute appears as a signed, authenticated, 926 authenticated/unprotected, or content attribute, then all of the 927 keying material within the associated content MUST have the same 928 operational/transport key material. 930 aa-transportKey ATTRIBUTE ::= { 931 TYPE TransOp 932 IDENTIFIED BY id-kma-transportKey } 934 id-kma-transportKey OBJECT IDENTIFIER ::= { 935 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 936 dod(2) infosec(1) keying-material-attributes(13) 15 } 938 TransOp ::= ENUMERATED { 939 transport (1), 940 operational (2) } 942 Due to multiple layers of encapsulation or the use of content 943 collections, the transport-key attribute can appear in more than one 944 location in the overall key package. When there are multiple 945 occurrences of the transport-key attribute within the same scope, all 946 fields within the attribute MUST contain exactly the same values. 947 Receivers MUST reject any key package that fails these consistency 948 checks. 950 14. Key Distribution Period 952 The key-distribution-period attribute indicates the period of time 953 that the keying material is intended for distribution. Keying 954 material is often distributed before it is intended to be used. Time 955 of day must be represented in Coordinated Universal Time (UTC). It 957 ID NSA's CMS Key Management Attributes November 10, 2014 959 can appear as a symmetric key, symmetric key package, asymmetric key, 960 signed, authenticated, authenticated/unprotected, or content 961 attribute. If the key-distribution-period attribute appears as a 962 signed, authenticated, authenticated/unprotected, or content 963 attribute, then all of the keying material within the content MUST 964 have the same key distribution period. 966 The key-distribution-period attribute has the following syntax: 968 aa-keyDistributionPeriod ATTRIBUTE ::= { 969 TYPE KeyDistPeriod 970 IDENTIFIED BY id-kma-keyDistPeriod } 972 id-kma-keyDistPeriod OBJECT IDENTIFIER ::= { 973 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 974 dod(2) infosec(1) keying-material-attributes(13) 5 } 976 KeyDistPeriod ::= SEQUENCE { 977 doNotDistBefore [0] BinaryTime OPTIONAL, 978 doNotDistAfter BinaryTime } 980 BinaryTime ::= INTEGER 982 The fields in the key-distribution-period attribute have the 983 following semantics: 985 o The doNotDistBefore field is OPTIONAL, and when it is present, 986 the keying material SHOULD NOT be distributed before the date and 987 time provided. 989 o The doNotDistAfter field is REQUIRED, and the keying material 990 SHOULD NOT be distributed after the date and time provided. 992 When the key-distribution-period attribute is associated with a 993 collection of keying material, the distribution period applies to all 994 of the keys in the collection. None of the keying material in the 995 collection SHOULD be distributed outside the indicated period. 997 Due to multiple layers of encapsulation or the use of content 998 collections, the key-distribution-period attribute can appear in more 999 than one location in the overall key package. When there are 1000 multiple occurrences of the key-distribution-period attribute within 1001 the same scope, all of the included attribute fields MUST contain 1002 exactly the same value. However, if the doNotDistBefore field is 1003 absent in an inner layer, a value MAY appear in an outer layer. 1004 Receivers MUST reject any key package that fails these consistency 1005 checks. 1007 ID NSA's CMS Key Management Attributes November 10, 2014 1009 15. Key Validity Period 1011 The key-validity-period attribute indicates the period of time that 1012 the keying material is intended for use. Time of day MUST be 1013 represented in Coordinated Universal Time (UTC). It can appear as a 1014 symmetric key, symmetric key package, asymmetric key, signed, 1015 authenticated, authenticated/unprotected, or content attribute. If 1016 the key-validity-period attribute appears as a signed, authenticated, 1017 authenticated/unprotected, or content attribute, then all of the 1018 keying material within the content MUST have the same key validity 1019 period. 1021 The key-validity-period attribute has the following syntax: 1023 aa-keyValidityPeriod ATTRIBUTE ::= { 1024 TYPE KeyValidityPeriod 1025 IDENTIFIED BY id-kma-keyValidityPeriod } 1027 id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= { 1028 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1029 dod(2) infosec(1) keying-material-attributes(13) 6 } 1031 KeyValidityPeriod ::= SEQUENCE { 1032 doNotUseBefore BinaryTime, 1033 doNotUseAfter BinaryTime OPTIONAL } 1035 BinaryTime ::= INTEGER 1037 The fields in the key-distribution-period attribute have the 1038 following semantics: 1040 o The doNotUseBefore field is required, and the keying material 1041 should not be used before the date and time provided. 1043 o The doNotUseAfter field is optional, and when it is present, the 1044 keying material should not be used after the date and time 1045 provided. 1047 For a key package that is being used for rekey, the doNotUseAfter 1048 field MAY be required even though the syntax is OPTIONAL. 1050 When the key-validity-period attribute is associated with a 1051 collection of keying material, the validity period applies to all of 1052 the keys in the collection. None of the keying material in the 1053 collection SHOULD be used outside the indicated period. The key- 1054 validity-period attribute described in this section and the key- 1055 duration attribute described in the next section provide a 1056 complementary function. The key-validity-period attribute provides 1058 ID NSA's CMS Key Management Attributes November 10, 2014 1060 explicit date and time values, which indicate the beginning and 1061 ending of the keying material usage period. The key-duration 1062 attribute provides the maximum length of time that the keying 1063 material SHOULD be used. If both attributes are provided, this 1064 duration MAY occur at any time within the specified period, but the 1065 limits imposed by both attributes SHOULD be honored. 1067 Due to multiple layers of encapsulation or the use of content 1068 collections, the key-validity-period attribute can appear in more 1069 than one location in the overall key package. When there are 1070 multiple occurrences of the key-validity-period attribute within the 1071 same scope, all of the included attribute fields MUST contain exactly 1072 the same value. However, if the doNotUseAfter field is absent in an 1073 inner layer, a value MAY appear in an outer layer. Receivers MUST 1074 reject any key package that fails these consistency checks. 1076 16. Key Duration 1078 The key-duration attribute indicates the maximum period of time that 1079 the keying material is intended for use. The date and time that the 1080 duration begins is not specified, but the maximum amount of time that 1081 the keying material can be used to provide security services is 1082 specified. It can appear as a symmetric key, symmetric key package, 1083 asymmetric key, signed, authenticated, authenticated/unprotected, or 1084 content attribute. If the key-duration attribute appears as a 1085 signed, authenticated, authenticated/unprotected, or content 1086 attribute, then all of the keying material within the content MUST 1087 have the same key duration. 1089 The key-duration attribute has the following syntax: 1091 aa-keyDurationPeriod ATTRIBUTE ::= { 1092 TYPE KeyDuration 1093 IDENTIFIED BY id-kma-keyDuration } 1095 id-kma-keyDuration OBJECT IDENTIFIER ::= { 1096 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1097 dod(2) infosec(1) keying-material-attributes(13) 7 } 1099 KeyDuration ::= CHOICE { 1100 hours [0] INTEGER (1..ub-KeyDuration-hours), 1101 days INTEGER (1..ub-KeyDuration-days), 1102 weeks [1] INTEGER (1..ub-KeyDuration-weeks), 1103 months [2] INTEGER (1..ub-KeyDuration-months), 1104 years [3] INTEGER (1..ub-KeyDuration-years) } 1106 ub-KeyDuration-hours INTEGER ::= 96 1107 ub-KeyDuration-days INTEGER ::= 732 1109 ID NSA's CMS Key Management Attributes November 10, 2014 1111 ub-KeyDuration-weeks INTEGER ::= 104 1112 ub-KeyDuration-months INTEGER ::= 72 1113 ub-KeyDuration-years INTEGER ::= 100 1115 The key-validity-period attribute described in the previous section 1116 and the key-duration attribute described in this section provide a 1117 complementary function. The relationship between these attributes is 1118 described in the previous section. 1120 Due to multiple layers of encapsulation or the use of content 1121 collections, the key-duration attribute can appear in more than one 1122 location in the overall key package. When there are multiple 1123 occurrences of the key-duration attribute within the same scope, all 1124 of the included attribute fields MUST contain exactly the same value. 1125 Receivers MUST reject any key package that fails these consistency 1126 checks. 1128 17. Classification 1130 The classification attribute indicates level of classification. The 1131 classification attribute specifies the aggregate classification of 1132 the package content. It can appear as a symmetric key, symmetric key 1133 package, asymmetric key, signed, authenticated, 1134 authenticated/unprotected, or content attribute. If the 1135 classification attribute appears as a signed, authenticated, 1136 authenticated/unprotected, or content attribute, then the value MUST 1137 represent the classification of all of the keying material within the 1138 content. Encrypted layers MAY contain content at a higher 1139 classification that will be revealed once they are decrypted. If the 1140 classification attribute is associated with a collection, then the 1141 sensitivity of all the data within the collection MUST be dominated 1142 by the classification carried in this attribute. 1144 The classification attribute makes use of the ESSSecurityLabel 1145 defined in Section 17.1 and from [RFC2634][RFC5911]. The term 1146 "classification" is used in this document, but the term "security 1147 label" is used in [RFC2634]. The two terms have the same meaning. 1149 [RFC2634][RFC5911] specifies an object identifier and syntax for the 1150 security label attribute. The same values are used for the 1151 classification attribute: 1153 aa-classificationAttribute ATTRIBUTE ::= { 1154 TYPE Classification 1155 IDENTIFIED BY id-aa-KP-classification } 1157 id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel 1159 ID NSA's CMS Key Management Attributes November 10, 2014 1161 -- id-aa-securityLabel OBJECT IDENTIFIER ::= { 1162 -- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1163 -- pkcs-9(9) smime(16) id-aa(2) 2 } 1165 Classification ::= ESSSecurityLabel 1167 The syntax of ESSSecurityLabel is not repeated here; however, see 1168 section 17.1 for security label conventions that MUST be followed by 1169 implementations of this specification. See [RFC2634] for a complete 1170 discussion of the semantics and syntax. 1172 When the classification attribute appears in more than one location 1173 in the overall key package, each occurrence is evaluated 1174 independently. The content originator MUST ensure that the 1175 classification attribute represents the sensitivity of the plaintext 1176 within the content. That is, the classification MUST dominate any 1177 other plaintext classification attribute value that is present 1178 elsewhere in the overall key package. Note that the classification 1179 attribute value may exceed these other plaintext classification 1180 attribute values if the other attribute values within the SignerInfo, 1181 AuthEnvelopedData, or AuthenticatedData are themselves classified and 1182 warrant the higher security label value. 1184 When the classification attribute appears in more than one location 1185 in the overall key package, each security label might be associated 1186 with a different security policy. Content originators SHOULD avoid 1187 mixing multiple security policies in the same key package whenever 1188 possible since this requires that receivers and intermediaries that 1189 check the classification attribute values to include support for the 1190 union of the security policies that are present. Failure to 1191 recognize an included security policy MUST result in rejection of the 1192 key package. 1194 Receivers MUST reject any key package that includes a classification 1195 for which the receiver's processing environment is not authorized. 1197 17.1. Security Label 1199 The ESSSecurityLabel ASN.1 type is used to represent the 1200 classification. The ESSSecurityLabel is defined in Section 3.2 of 1201 [RFC2634]. 1203 The classification attribute values and classification attribute 1204 values have ASN.1 type ESSSecurityLabel. Part of the syntax 1205 definition is repeated here to facilitate discussion: 1207 ESSSecurityLabel ::= SET { 1208 security-policy-identifier SecurityPolicyIdentifier, 1210 ID NSA's CMS Key Management Attributes November 10, 2014 1212 security-classification SecurityClassification OPTIONAL, 1213 privacy-mark ESSPrivacyMark OPTIONAL, 1214 security-categories SecurityCategories OPTIONAL } 1216 A security policy is a set of criteria for the provision of security 1217 services. The security-policy-identifier, which is an object 1218 identifier, is used to identify the security policy associated with 1219 the security label. It indicates the semantics of the other security 1220 label components. 1222 If the key package receiver does not recognize the object identifier 1223 in the security-policy-identifier field and the security label 1224 includes a security-categories field, then the key package contents 1225 MUST NOT be accepted and the enclosed keying material MUST NOT be 1226 used. If the key package receiver does not recognize the object 1227 identifier in the security-policy-identifier field and the security 1228 label does not include a security-categories field, then the key 1229 package contents MAY be accepted only if the security-classification 1230 field is present and it contains a value from the basic hierarchy as 1231 described below. 1233 This specification defines the use of the SecurityClassification 1234 field exactly as is it specified in the 1988 edition of ITU-T 1235 Recommendation X.411 [X.411], which states in part: 1237 "If present, a security-classification may have one of a 1238 hierarchical list of values. The basic security-classification 1239 hierarchy is defined in this Recommendation, but the use of these 1240 values is defined by the security-policy in force. Additional 1241 values of security-classification, and their position in the 1242 hierarchy, may also be defined by a security-policy as a local 1243 matter or by bilateral agreement. The basic security- 1244 classification hierarchy is, in ascending order: unmarked, 1245 unclassified, restricted, confidential, secret, top-secret." 1247 Implementations MUST support the basic security classification 1248 hierarchy. Such implementations MAY also support other security- 1249 classification values; however, the placement of additional values in 1250 the hierarchy MUST be specified by the security policy. 1252 Implementations MUST NOT make access control decisions based on the 1253 privacy-mark. However, information in the privacy-mark can be 1254 displayed to human users by devices that have displays to do so. The 1255 privacy-mark length MUST NOT exceed 128 characters. The privacy-mark 1256 SHALL use the PrintableString choice if all of the characters in the 1257 privacy mark are members of the printable string character set. 1259 If present, security-categories provide further granularity for the 1261 ID NSA's CMS Key Management Attributes November 10, 2014 1263 keying material. The security policy in force indicates the 1264 permitted syntaxes of any entries in the set of security categories. 1265 At most, 64 security categories may be present. The security- 1266 categories have ASN.1 type SecurityCategories and further 1267 SecurityCategory [RFC5912], which are both repeated here to 1268 facilitate discussion: 1270 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 1271 SecurityCategory 1272 {{SupportedSecurityCategories}} 1274 SecurityCategory {SECURITY-CATEGORY:Supported} ::= SEQUENCE { 1275 type [0] IMPLICIT SECURITY-CATEGORY. 1276 &id({Supported}), 1277 value [1] EXPLICIT SECURITY-CATEGORY. 1278 &Type({Supported}{@type}) 1279 } 1281 Four security categories are defined and are referred to as the 1282 Restrictive Tag, the Enumerated Tag, the Permissive Tag, and the 1283 Informative Tag. Only the Enumerated Tag and Informative Tag are 1284 permitted in the classification attribute. 1286 The Enumerated Tag is composed of one or more non-negative integers. 1287 Each non-negative integer represents a non-hierarchical security 1288 attribute that applies to the labeled content. Use of the integer 1289 representation is intended to minimize the size of the label since a 1290 particular key package generally contains only a few security 1291 categories attributes, even though a security policy might define a 1292 large set of security categories attributes. Security attributes 1293 enumerated by tags of this type could be restrictive (such as 1294 compartments) or permissive (such as release permissions). Two 1295 object identifiers for the SecurityCategory type field have been 1296 defined, one restrictive and one for permissive. The object 1297 identifiers are: 1299 id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= { 1300 2 16 840 1 101 2 1 8 3 4 } 1302 id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= { 1303 2 16 840 1 101 2 1 8 3 1 } 1305 With both the restrictive and permissive security category types, the 1306 corresponding SecurityCategory value has the following ASN.1 1307 definition: 1309 EnumeratedTag ::= SEQUENCE { 1310 tagName OBJECT IDENTIFIER, 1312 ID NSA's CMS Key Management Attributes November 10, 2014 1314 attributeList SET OF SecurityAttribute } 1316 SecurityAttribute ::= INTEGER (0..MAX) 1318 Any security policy that makes use of security categories MUST assign 1319 object identifiers for each tagName, assign the set of integer values 1320 associated with each tagName, and specify the semantic meaning for 1321 each integer value. Restrictive security attributes and permissive 1322 security attributes SHOULD be associated with different tagName 1323 object identifiers. 1325 The Informative Tag is composed of either one or more non-negative 1326 integers or a bit string. Only the integer choice is allowed in this 1327 specification. Each non-negative integer represents a non- 1328 hierarchical security attribute that applies to the labeled content. 1329 Use of the integer representation is intended to minimize the size of 1330 the label since a particular key package generally contains only a 1331 few security categories attributes, even though a security policy 1332 might define a large set of security categories attributes. Security 1333 attributes enumerated by tags of this type are informative (i.e., no 1334 access control is performed). One object identifier for the 1335 SecurityCategory type field has been defined and it is as follows: 1337 id-informativeAttributes OBJECT IDENTIFIER ::= { 1338 2 16 840 1 101 2 1 8 3 3 } 1340 The corresponding SecurityCategory value has the following ASN.1 1341 definition: 1343 InformativeTag ::= SEQUENCE { 1344 tagName OBJECT IDENTIFIER, 1345 attributes FreeFormField } 1347 FreeFormField ::= CHOICE { 1348 bitSetAttributes BIT STRING, 1349 securityAttributes SET OF SecurityAttribute } 1351 Any security policy that makes use of security categories MUST assign 1352 object identifiers for each tagName, assign the set of integer values 1353 associated with each tagName, and specify the semantic meaning for 1354 each integer value. 1356 18. Split Key Identifier 1358 The key package originator may include a split-identifier attribute 1359 to designate that the keying material contains a split rather than a 1360 complete key. It may appear as a symmetric and asymmetric key 1361 attribute. The split-identifier attribute MUST NOT appear as a 1363 ID NSA's CMS Key Management Attributes November 10, 2014 1365 symmetric key package, signed, authenticated, 1366 authenticated/unprotected, or content attribute. Split keys have two 1367 halves, which are called "A" and "B." The split-identifier attribute 1368 indicates which half is included in the key package, and it 1369 optionally indicates the algorithm that is needed to combine the two 1370 halves. The combine algorithm is OPTIONAL since each key algorithm 1371 has a default mechanism for this purpose, and the combine algorithm 1372 is present only if the default mechanism is not employed. 1374 The key-split-identifier attribute has the following syntax: 1376 aa-splitIdentifier ATTRIBUTE ::= { 1377 TYPE SplitID 1378 IDENTIFIED BY id-kma-splitID } 1380 id-kma-splitID OBJECT IDENTIFIER ::= { 1381 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1382 dod(2) infosec(1) keying-material-attributes(13) 11 } 1384 SplitID ::= SEQUENCE { 1385 ENUMERATED { a(0), b(1) }, 1386 combineAlg AlgorithmIdentifier 1387 {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL } 1389 In most cases the default combine algorithm will be employed, which 1390 makes this attribute a simple constant that identifies either the "A" 1391 or "B" half of the split key, which supports implementation of some 1392 key distribution policies. 1394 Note that each split might have its own CRC, but the key and the 1395 check word are both recovered when the two splits are combined. 1397 Since the split-identifier attribute MUST NOT appear as a signed, 1398 authenticated, authenticated/unprotected, or content attribute, a key 1399 package cannot include multiple occurrences of the split-identifier 1400 attribute within the same scope. Receivers MUST reject any key 1401 package in which the split-identifier attribute appears as a signed, 1402 authenticated, authenticated/unprotected, or content attribute. 1404 19. Key Package Type 1406 The key-package-type attribute is a shorthand method for specifying 1407 all aspects of the key package format, including which attributes are 1408 present and the structure of the encapsulated content. The key- 1409 package-type attribute can be used as a signed, authenticated, 1410 authenticated/unprotected, or content attribute. If a key-package- 1411 type attribute appears in a content attribute associated with a 1412 collection, it is a shorthand method for specifying all aspects of 1414 ID NSA's CMS Key Management Attributes November 10, 2014 1416 the key packages that comprise the collection. 1418 Rather than implementing the full flexibility of this specification, 1419 some devices may implement support for one or more specific key 1420 package formats instantiating this specification. Those specific 1421 formats are called templates and can be identified using a key- 1422 package-type attribute. 1424 The key-package-type attribute has the following syntax: 1426 aa-keyPackageType ATTRIBUTE ::= { 1427 TYPE KeyPkgType 1428 IDENTIFIED BY id-kma-keyPkgType } 1430 id-kma-keyPkgType OBJECT IDENTIFIER ::= { 1431 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1432 dod(2) infosec(1) keying-material-attributes(13) 12 } 1434 KeyPkgType ::= OBJECT IDENTIFIER 1436 Due to multiple layers of encapsulation or the use of content 1437 collections, the key-package-type attribute can appear in more than 1438 one location in the overall key package. When there are multiple 1439 occurrences of the key-package-type attribute, each occurrence is 1440 used independently. Since the receiver is likely to use the key- 1441 package-type attribute value as a decoding aid, any error will most 1442 likely lead to parsing problems, and these problems could result in 1443 many different errors being reported. 1445 20. Signature Usage 1447 The signature-usage attribute provides the intended usage for a 1448 signature key. Symmetric key packages do not contain signature 1449 generation or signature validation keying material, so the signature- 1450 usage attribute MUST NOT appear in a symmetric key package. For an 1451 asymmetric key package, the signature-usage attribute indicates the 1452 kind of objects that are to be signed with the private key in the 1453 package. However, if the asymmetric key package contains a 1454 Certificate Signature Key, then the signature-usage attribute also 1455 indicates what signed objects can be validated using certificates 1456 that are signed by the private key in the asymmetric key package. 1457 Therefore, the signature-usage attribute also indicates what kind of 1458 objects that can be signed by the private keys associated with these 1459 certificates. The signature-usage attribute MUST NOT appear as a 1460 signed, authenticated, authenticated/unprotected, or content 1461 attribute. 1463 The signature-usage attribute has the following syntax: 1465 ID NSA's CMS Key Management Attributes November 10, 2014 1467 aa-signatureUsage-v3 ATTRIBUTE ::= { 1468 TYPE SignatureUsage 1469 IDENTIFIED BY id-kma-sigUsageV3 } 1471 id-kma-sigUsageV3 OBJECT IDENTIFIER ::= { 1472 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1473 dod(2) infosec(1) keying-material-attributes(13) 22 } 1475 SignatureUsage ::= CMSContentConstraints 1477 The SignatureUsage structure has the same syntax as the 1478 CMSContentConstraints structure in [RFC6010], and it is repeated here 1479 for convenience. 1481 CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF 1482 ContentTypeConstraint 1484 ContentTypeConstraint ::= SEQUENCE { 1485 contentType CONTENT-TYPE.&id ({ContentSet|ct-Any,...}), 1486 canSource ContentTypeGeneration DEFAULT canSource, 1487 attrConstraints AttrConstraintList OPTIONAL } 1489 Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE { 1490 attrType ATTRIBUTE.&id({ConstraintList}), 1491 attrValues SET SIZE (1..MAX) OF ATTRIBUTE. 1492 &Type({ConstraintList}{@attrType}) } 1494 SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... } 1496 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF 1497 Constraint {{ SupportedConstraints }} 1499 The SignatureUsage contains a type of CMSContentConstraints. One or 1500 more ContentTypeConstraint MUST appear in CMSContentConstraints. 1502 Within ContentTypeConstraint, the contentType field indicates the 1503 encapsulated content type identifier that can be signed with the 1504 signature key. A particular content type MUST NOT appear more than 1505 once in the list. The CMS protecting content types need not be 1506 included in the list of permitted content types as the use of CMS is 1507 always authorized (see [RFC6010]). 1509 Within ContentTypeConstraint, the canSource enumeration indicates 1510 whether the signature key can be used to directly sign the indicated 1511 content type. If the ContentTypeConstraint is canSource (the default 1512 value), then the signature key can be used to directly sign the 1513 specified content type. If the ContentTypeConstraint is 1514 cannotSource, then the signature key can only be used with the 1516 ID NSA's CMS Key Management Attributes November 10, 2014 1518 specified content type if it encapsulates a signature that was 1519 generated by an originator with a ContentTypeConstraint that is 1520 canSource. 1522 Within ContentTypeList, the attrConstraints OPTIONAL field contains a 1523 sequence of content type specific constraints. If the 1524 attrConstraints field is absent, the signature key can be used to 1525 sign the specified content type, without any further checking. If 1526 the either the attrConstraints field is present, then the signature 1527 key can only be used to sign the specified content type if all of the 1528 constraints for that content type are satisfied. Content type 1529 constraints are checked by matching the attribute values in the 1530 attrConstraint field against the attribute value in the content. The 1531 constraints succeed if the attribute is not present; they fail if the 1532 attribute is present and the value is not one of the values provided 1533 in attrConstraint. 1535 The fields of attrConstraints implement content type-specific 1536 constraints. The attrType field is an AttributeType, which is an 1537 object identifier of a signed attribute carried in the SignerInfo of 1538 the content. The attrValues field provides one or more acceptable 1539 signed attribute values. It is a set of AttributeValue. For a 1540 signed content to satisfy the constraint, the SignerInfo MUST include 1541 a signed attribute of the type identified in the attrType field, and 1542 the signed attribute MUST contain one of the values in the set 1543 carried in attrValues. 1545 Since the signature-usage attribute MUST NOT appear as a signed, 1546 authenticated, authenticated/unprotected, or content attribute, an 1547 asymmetric key package cannot include multiple occurrences of the 1548 signature-usage attribute within the same scope. Receivers MUST 1549 reject any asymmetric key package in which the signature-usage 1550 attribute appears as a signed, authenticated, 1551 authenticated/unprotected, or content attribute. 1553 21. Other Certificate Format 1555 The other-certificate-formats attribute specifies the type, format, 1556 and value of certificates that are not X.509 public key certificates. 1557 Symmetric key packages do not contain any certificates, so the 1558 other-certificate-formats attribute MUST NOT appear in a symmetric 1559 key package. It SHOULD appear in the attributes field, when the 1560 publicKey field is absent and the certificate format is not X.509. 1561 This attribute MUST NOT appear in an attributes field that includes 1562 the user-certificate attribute from Section 8. The other- 1563 certificate-formats attribute MUST NOT appear as a signed, 1564 authenticated, authenticated/unprotected, or content attribute. 1566 ID NSA's CMS Key Management Attributes November 10, 2014 1568 The other-certificate-formats attribute has the following syntax: 1570 aa-otherCertificateFormats ATTRIBUTE ::= { 1571 TYPE CertificateChoices 1572 IDENTIFIED BY id-kma-otherCertFormats } 1574 id-kma-otherCertFormats OBJECT IDENTIFIER ::= { 1575 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1576 dod(2) infosec(1) keying-material-attributes(13) 19 } 1578 CertificateChoices ::= CHOICE { 1579 certificate Certificate, 1580 extendedCertificate [0] IMPLICIT ExtendedCertificate, 1581 -- Obsolete 1582 v1AttrCert [1] IMPLICIT AttributeCertificateV1, 1583 -- Obsolete 1584 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 1585 other [3] IMPLICIT OtherCertificateFormat } 1587 OtherCertificateFormat ::= SEQUENCE { 1588 otherCertFormat OBJECT IDENTIFIER, 1589 otherCert ANY DEFINED BY otherCertFormat } 1591 The other-certificate-formats attribute makes use of the 1592 CertificateChoices field defined in Section 10.2.2 of [RFC5652]. The 1593 certificate, extendedCertificate, and v1AttrCert fields MUST be 1594 omitted. The v2AttrCert field can include Version 2 Attribute 1595 Certificates. The other field can include EFF certificates and other 1596 as-yet undefined certificate formats. 1598 Since the other-certificate-formats attribute MUST NOT appear as a 1599 signed, authenticated, authenticated/unprotected, or content 1600 attribute, an asymmetric key package cannot include multiple 1601 occurrences of the other-certificate-formats attribute within the 1602 same scope. Receivers MUST reject any asymmetric key package in 1603 which the other-certificate-formats attribute appears as a signed, 1604 authenticated, authenticated/unprotected, or content attribute. 1606 22. PKI Path 1608 The pki-path attribute includes certificates that can aid in the 1609 validation of the certificate carried in the user-certificate 1610 attribute. Symmetric key packages do not contain any certificates, 1611 so the pkiPath attribute MUST NOT appear in a symmetric key package. 1612 It can appear as an asymmetric key, signed, authenticated, 1613 authenticated/unprotected, or content attribute. It can appear in 1614 the attributes field, when the publicKey field is absent and the 1615 certificate format is X.509. This attribute MUST NOT appear in an 1617 ID NSA's CMS Key Management Attributes November 10, 2014 1619 AsymmetricKeyPackage that has an other-certificate-formats attribute 1620 in the attributes field. If the pki-path attribute appears as a 1621 signed, authenticated, authenticated/unprotected, or content 1622 attribute, then the value includes certificates that can be used to 1623 construct certification path to all of the keying material within the 1624 content. This attribute MUST be supported. 1626 The syntax is taken from [X.509] but redefined using the ATTRIBUTE 1627 CLASS from [RFC5911]. The pki-path attribute has the following 1628 syntax: 1630 aa-pkiPath ATTRIBUTE ::= { 1631 TYPE PkiPath 1632 IDENTIFIED BY id-at-pkiPath } 1634 id-at-pkiPath OBJECT IDENTIFIER ::= { 1635 joint-iso-itu-t(2) ds(5) attributes(4) 70 } 1637 PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate 1639 The first certificate in the sequence is the subject's parent 1640 Certification Authority (CA). The next certificate is that CA's 1641 parent, and so on. The end-entity and Trust Anchor are not included 1642 in this attribute. 1644 Due to multiple layers of encapsulation or the use of content 1645 collections, the pki-path attribute can appear in more than one 1646 location in the overall key package. When the pki-path attribute 1647 appears in more than one location in the overall key package, each 1648 occurrence is evaluated independently. 1650 23. Useful Certificates 1652 The useful-certificates attribute includes certificates that can aid 1653 in the validation of certificates associated with other parties with 1654 whom secure communications are anticipated. It can appear as an 1655 asymmetric key, signed, authenticated, authenticated/unprotected, or 1656 content attribute. For an asymmetric key that has an other- 1657 certificate-formats attribute from Section 21 in the attributes 1658 field, the useful-certificates attribute MUST NOT appear. If the 1659 useful-certificates attribute appears as a signed, authenticated, 1660 authenticated/unprotected, or content attribute, then the value 1661 includes certificates that may be used to validate certificate of 1662 others the receiver communicates with. This attribute MUST be 1663 supported. 1665 The useful-certificates attribute has the following syntax: 1667 ID NSA's CMS Key Management Attributes November 10, 2014 1669 aa-usefulCertificates ATTRIBUTE ::= { 1670 TYPE CertificateSet 1671 IDENTIFIED BY id-kma-usefulCerts } 1673 id-kma-usefulCerts OBJECT IDENTIFIER ::= { 1674 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1675 dod(2) infosec(1) keying-material-attributes(13) 20 } 1677 CertificateSet ::= SET OF CertificateChoices 1679 The useful-certificates attribute makes use of the CertificateSet 1680 field defined in Section 10.2.3 of [RFC5652]. Within the 1681 CertificateChoices field, the extendedCertificate and v1AttrCert 1682 fields MUST always be omitted. If the userCertificate attribute from 1683 Section 8 is included, the other field MUST NOT be present. If the 1684 other-certificate-formats attribute from Section 21 is included, the 1685 certificate field MUST NOT be present. 1687 Due to multiple layers of encapsulation or the use of content 1688 collections, the useful-certificates attribute can appear in more 1689 than one location in the overall key package. When the useful- 1690 certificates attribute appears in more than one location in the 1691 overall key package, each occurrence is evaluated independently. 1693 24. Key Wrap Algorithm 1695 The key-wrap-algorithm attribute identifies a key wrap algorithm with 1696 an algorithm identifier. It can appear as a symmetric key or 1697 symmetric key package attribute. When this attribute is present in 1698 sKeyAttrs, it indicates that the associated sKey field contains a 1699 black key that was wrapped by the identified algorithm. When this 1700 attribute is present in sKeyPkgAttrs, it indicates that every sKey 1701 field in that symmetric key package contains a black key, and that 1702 all keys are wrapped by the same designated algorithm. 1704 The key-wrap-algorithm attribute has the following syntax: 1706 aa-keyWrapAlgorithm ATTRIBUTE ::= { 1707 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}} 1708 IDENTIFIED BY id-kma-keyWrapAlgorithm } 1710 id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= { 1711 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1712 dod(2) infosec(1) keying-material-attributes(13) 21 } 1714 KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... } 1716 25. Content Decryption Key Identifier 1717 ID NSA's CMS Key Management Attributes November 10, 2014 1719 The content-decryption-key-identifier attribute can appear as an 1720 unprotected attribute as well as a symmetric and symmetric key 1721 package attribute. The attribute's semantics differ based on the 1722 location. 1724 25.1. Content Decryption Key Identifier: Symmetric Key and Symmetric Key 1725 Package 1727 The content-decryption-key-identifier attribute [RFC6032] identifies 1728 the keying material needed to decrypt the sKey. It can appear as a 1729 symmetric key and symmetric key package attribute. If the key-wrap- 1730 algorithm attribute appears in sKeyPkgAttrs, then the corresponding 1731 content-decryption-identifier attribute can appear in either 1732 sKeyPkgAttrs or sKeyAttrs. If the key-wrap-algorithm attribute 1733 appears from Section 24 in sKeyAttrs, then the corresponding content- 1734 decryption-identifier attribute MUST appear in sKeyAttrs. 1736 The content-decryption-key-identifier attribute in included for 1737 convenience: 1739 aa-contentDecryptKeyIdentifier ATTRIBUTE ::= { 1740 TYPE ContentDecryptKeyID 1741 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 1743 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= { 1744 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1745 dod(2) infosec(1) attributes(5) 66 } 1747 ContentDecryptKeyID ::= OCTET STRING 1749 The content decryption key identifier contains an octet string, and 1750 this syntax does not impose any particular structure on the 1751 identifier value. 1753 25.2. Content Decryption Key Identifier: Unprotected 1755 The content-decryption-key-identifier attribute can be used to 1756 identify the keying material that is needed for decryption of the 1757 EncryptedData content if there is any ambiguity. 1759 The content-decryption-key-identifier attribute syntax is found in 1760 Section 25.1. The content decryption key identifier contains an octet 1761 string, and this syntax does not impose any particular structure on 1762 the identifier value. 1764 Due to multiple layers of encryption, the content-decryption-key- 1765 identifier attribute can appear in more than one location in the 1766 overall key package. When there are multiple occurrences of the 1768 ID NSA's CMS Key Management Attributes November 10, 2014 1770 content-decryption-key-identifier attribute, each occurrence is 1771 evaluated independently. Each one is used to identify the needed 1772 keying material for that layer of encryption. 1774 26. Certificate Pointers 1776 The certificate-pointers attribute can be used to reference one or 1777 more certificates that may be helpful in the processing of the 1778 content once it is decrypted. Sometimes certificates are omitted if 1779 they can be easily fetched. However, an intermediary may have better 1780 facilities to perform the fetching than the receiver. The 1781 certificate-pointers attribute may be useful in some environments. 1782 This attribute can appear as an unprotected and an 1783 unauthenticated/unprotected attribute. 1785 The certificate-pointers attribute uses the same syntax and semantics 1786 as the subject information access certificate extension [RFC5280]. 1787 The certificate-pointers attribute has the following syntax: 1789 aa-certificatePointers ATTRIBUTE ::= { 1790 TYPE SubjectInfoAccessSyntax 1791 IDENTIFIED BY id-pe-subjectInfoAccess } 1793 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { 1794 iso(1) identified-organization(3) dod(6) internet(1) 1795 security(5) mechanisms(5) pkix(7) pe(1) 11 } 1797 SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF 1798 AccessDescription 1800 AccessDescription ::= SEQUENCE { 1801 accessMethod OBJECT IDENTIFIER, 1802 accessLocation GeneralName } 1804 As specified in [RFC5280], the id-ad-caRepository access method can 1805 be used to point to a repository where a Certification Authority 1806 publishes certificates and Certificate Revocation Lists (CRLs). In 1807 this case, the accessLocation field tells how to access the 1808 repository. Where the information is available via http, ftp, or 1809 ldap, accessLocation contains a uniform resource identifier (URI). 1810 Where the information is available via the directory access protocol 1811 (dap), accessLocation contains a directory name. 1813 27. CRL Pointers 1815 The CRL-pointers attribute can be used to reference one or more CRLs 1816 that may be helpful in the processing of the content once it is 1817 decrypted. Sometimes CRLs are omitted to conserve space or to ensure 1819 ID NSA's CMS Key Management Attributes November 10, 2014 1821 that the most recent CRL is obtained when the certificate is 1822 validated. However, an intermediary may have better facilities to 1823 perform the fetching than the receiver. The CRL-pointers attribute 1824 may be useful in some environments. This attribute can appear as an 1825 unprotected and unauthenticated/unprotected attribute. 1827 The CRL-pointers attribute has the following syntax: 1829 aa-crlPointers ATTRIBUTE ::= { 1830 TYPE GeneralNames 1831 IDENTIFIED BY id-aa-KP-crlPointers } 1833 id-aa-KP-crlPointers OBJECT IDENTIFIER ::= { 1834 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1835 dod(2) infosec(1) attributes(5) 70 } 1837 The CRL-pointers attribute uses the GeneralNames syntax from 1838 [RFC5280]. Each name describes a different mechanism to obtain the 1839 same CRL. Where the information is available via http, ftp, or ldap, 1840 GeneralNames contains a uniform resource identifier (URI). Where the 1841 information is available via the directory access protocol (dap), 1842 GeneralNames contains a directory name. 1844 28. Key Package Identifier and Receipt Request 1846 The Key Package Identifier and Receipt Request attribute from 1847 [RFC7191] is also supported. It can appear as a signed attribute, 1848 authenticated, authenticated/unprotected, or content attribute. 1850 29. Additional Error Codes 1852 This specification also defines three additional extendedErrorCodes 1853 [RFC7191]: 1855 id-errorCodes OBJECT IDENTIFIER ::= { 1856 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1857 dod(2) infosec(1) errorCodes(22) } 1859 id-missingKeyType OBJECT IDENTIFIER ::= { 1860 id-errorCodes 1 } 1862 id-privacyMarkTooLong OBJECT IDENTIFIER ::= { 1863 id-errorCodes 2 } 1865 id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= { 1866 id-errorCodes 3 } 1868 id-incorrectKeyProvince OBJECT IDENTIFIER ::= { 1870 ID NSA's CMS Key Management Attributes November 10, 2014 1872 id-errorCodes 4 } 1874 missingKeyType indicates that all keying material within a package is 1875 of the same type; however, the key type attribute is not specified in 1876 sKeyPkgAttrs [RFC6031]. 1878 privacyMarkTooLong indicates that a classification attribute includes 1879 a privacy mark that exceeds 128 characters in length. 1881 unrecognizedSecurityPolicy indicates that a security-policy- 1882 identifier is not supported. 1884 incorrectKeyProvince indicates that the value of the key province 1885 attribute in a key package does not match the key province constraint 1886 of the TA used to validate the key package. 1888 30. Processing Key Package Attribute Values and CMS Content Constraints 1890 Trust anchors may contain constraints for any content type [RFC5934]. 1891 When the trust anchor contains constraints for the symmetric key 1892 package content type or the asymmetric key package content type, then 1893 the constraints provide default values for key package attributes 1894 that are not present in the key package and define the set of 1895 acceptable values for key package attributes that are present. 1897 When a trust anchor delegates authority by issuing an X.509 1898 certificate, the CMS content constraints certificate extension 1899 [RFC6010] may be included to constrain the authorizations. The trust 1900 anchor and the X.509 certification path provide default values for 1901 key package attributes that are not present in the key package and 1902 define the set of acceptable of values for key package attributes 1903 that are present. 1905 Constraints on content type usage are represented as attributes. 1907 The processing procedures for the CMS content constraints certificate 1908 extension [RFC6010] are part of the validation of a signed or 1909 authenticated object, and the procedures yield three output values: 1910 cms_constraints, cms_effective_attributes, and 1911 cms_default_attributes. Object validation MUST be performed before 1912 processing the key package contents, and these outputs values are 1913 used as part of key package processing. These same output values are 1914 easily generated directly from a trust anchor and the key package 1915 when no X.509 certification path is involved in validation. 1917 The cms_effective_attributes provides the set of acceptable values 1918 for attributes. Each attribute present in the key package that 1920 ID NSA's CMS Key Management Attributes November 10, 2014 1922 corresponds to an entry in cms_effective_attributes MUST contain a 1923 value that appears in cms_effective_attributes entry. Attributes 1924 that do not correspond to an entry in cms_effective_attributes are 1925 unconstrained and may contain any value. Correspondence between 1926 attributes and cms_effective_attributes is determined by comparing 1927 the attribute object identifier to object identifier for each entry 1928 in cms_effective_attributes. 1930 The cms_default_attributes provides values for attributes that do not 1931 appear in the key package. If cms_default_attributes includes only 1932 one attribute value for a particular attribute, then that value is 1933 used as if it were included in the key package itself. However, if 1934 cms_default_attributes includes more than one value for a particular 1935 attribute, then the appropriate value remains ambiguous and the key 1936 package should be rejected. 1938 Some attributes can appear in more than one place in the key package, 1939 and for this reason, the attribute definitions include consistency 1940 checks. These checks are independent of constraints checking. In 1941 addition to the consistency checks, each instance of the attribute 1942 MUST be checked against the set of cms_effective_attributes, and the 1943 key package MUST be rejected if any of the attributes values are not 1944 in the set of authorized set of values. 1946 31. Attribute Scope 1948 This section provides an example symmetric key package in order to 1949 provide a discussion of the scope of attributes. This is an 1950 informative section; it is not a normative portion of this 1951 specification. Figure 1 provides the example. All of the concepts 1952 apply to either a symmetric key package or an asymmetric key package, 1953 with the exception of the key-algorithm attribute which is only 1954 applicable to a symmetric key package. Each of the components is 1955 labeled with a number inside parentheses for easy reference: 1957 o (1) is the ContentInfo that must be present as the outermost 1958 layer of encapsulation. It contains no attributes. It is shown 1959 for completeness. 1961 o (2) is a SignedData content type, which includes six signed 1962 attributes. Four of the signed attributes are keying material 1963 attributes. 1965 o (3) is a ContentCollection that includes two encapsulated content 1966 types: a ContentWithAttributes and an EncryptedKeyPackage. This 1967 content type does not provide any attributes. 1969 o (4) is a ContentWithAttributes content type. It encapsulates a 1971 ID NSA's CMS Key Management Attributes November 10, 2014 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 o The key-package-receivers-v2 attribute indicates the authorized 2022 ID NSA's CMS Key Management Attributes November 10, 2014 2024 key package receivers, and it has no further scope. The key- 2025 package-receivers-v2 attribute value within (4) is evaluated 2026 without regard to the value of this attribute. 2028 o The key-distribution-period attribute contains two date values: 2029 doNotDistBefore and doNotDistAfter. These values must match all 2030 others within the same scope, which in this example is the key- 2031 distribution-period within (4). 2033 o The key-package-type attributes indicates the format of the key 2034 package, and it has no further scope. The key-package-type 2035 attributes values within (5) and (8) are evaluated without regard 2036 to the value of this attribute. 2038 ContentWithAttributes content type (4) includes four attributes: 2040 o The classification attribute contains security label for all of 2041 the plaintext in the encapsulated content. Each classification 2042 attribute is evaluated separately; it has no further scope. 2044 o The TSEC-Nomenclature attribute includes only the shortTitle 2045 field, and the value must match all other instances within the 2046 same scope, which appear in (5) and (6). Note that the TSEC- 2047 Nomenclature attribute values in (8) and (9) are not in the same 2048 scope as the TSEC-Nomenclature attribute that appears in (4). 2050 o The key-package-receivers-v2 attribute indicates the authorized 2051 key package receivers, and it has no further scope. The key- 2052 package-receivers-v2 attribute value within (2) is evaluated 2053 without regard to the value of this attribute. 2055 o The key-distribution-period attribute contains two date values: 2056 doNotDistBefore and doNotDistAfter. These values must match all 2057 others within the same scope, which in this example is the key- 2058 distribution-period within (2). 2060 SignedData content type (5) includes six signed attributes: 2062 o The content-type attribute contains id-ct-KP-skeyPackage to 2063 indicate the type of the encapsulated content, and it has no 2064 further scope. 2066 o The message-digest attribute contains the one-way hash value of 2067 the encapsulated content; it is needed to validate the digital 2068 signature. It has no further scope. 2070 o The classification attribute contains security label for all of 2071 the plaintext in the encapsulated content. Each classification 2073 ID NSA's CMS Key Management Attributes November 10, 2014 2075 attribute is evaluated separately; it has no further scope. 2077 o The TSEC-Nomenclature attribute includes only the shortTitle 2078 field, and the value must match all other instances within the 2079 same scope, which appear in (6). Since this is within the scope 2080 of (4), these shortTitle field values must match as well. Note 2081 that the TSEC-Nomenclature attribute values in (8) and (9) are 2082 not in the same scope. 2084 o The key-purpose attribute specifies the purpose of the key 2085 material. All occurrences within the scope must have the same 2086 value, but in this example, there are no other occurrences within 2087 the scope. The key-purpose attribute value within (8) is 2088 evaluated without regard to the value of this value. 2090 o The key-package-type attribute indicates the format of the key 2091 package, and it has no further scope. The key-package-type 2092 attribute values within (2) and (8) are evaluated without regard 2093 to the value of this attribute. 2095 SymmetricKeyPackage content type (6) includes three keying material 2096 attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs 2097 fields: 2099 o The key-algorithm attribute includes only the keyAlg field, and 2100 it must match all other occurrences within the same scope. 2101 However, there are no other key-algorithm attribute occurrences 2102 in the same scope; the key-algorithm attribute value in (9) is 2103 not in the same scope. 2105 o The classification attribute contains security label for all of 2106 the plaintext in the key package. Each classification attribute 2107 is evaluated separately; it has no further scope. 2109 o The TSEC-Nomenclature attribute includes the shortTitle field as 2110 well as some of the optional fields. The shortTitle field value 2111 must match the values in (4) and (5), since this content type is 2112 within their scope. Note that the TSEC-Nomenclature attribute 2113 values in (8) and (9) are not in the same scope. 2115 EncryptedKeyPackage content type (7) includes one unprotected 2116 attribute, and the encryption will prevent any intermediary that does 2117 not have the ability to decrypt the content from making any 2118 consistency checks on (8) and (9): 2120 o The content-decryption-key-identifier attribute identifies the 2121 key that is needed to decrypt the encapsulated content; it has no 2122 further scope. 2124 ID NSA's CMS Key Management Attributes November 10, 2014 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 2172 must match the values in (8), since this content type is within 2173 its scope. Note that the TSEC-Nomenclature attributes values in 2175 ID NSA's CMS Key Management Attributes November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 November 10, 2014 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 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 2311 Message Syntax (CMS) Content Constraints Extension", 2312 RFC 6010, September 2010. 2314 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 2315 Representing Date and Time in ASN.1", RFC 6019, September 2316 2010. 2318 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2319 (CMS) Symmetric Key Package Content Type", RFC 6031, 2320 December 2010. 2322 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 2323 (CMS) Encrypted Key Package Content Type", RFC 6032, 2324 December 2010. 2326 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 2327 (CMS) Protection of Symmetric Key Package Content Types", 2328 RFC 6160, April 2011. 2330 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 2331 Message Syntax (CMS) Asymmetric Key Package Content Type", 2332 RFC 6162, April 2011. 2334 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 2335 for the Cryptographic Message Syntax (CMS) and the Public 2337 ID NSA's CMS Key Management Attributes November 10, 2014 2339 Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 2340 2011. 2342 [RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key 2343 Package Receipt and Error Content Types", RFC 7191, April 2344 2014. 2346 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 2347 Information technology - Open Systems Interconnection - 2348 The Directory: Public-key and attribute certificate 2349 frameworks. 2351 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 2352 Information Technology - Abstract Syntax Notation One. 2354 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 2355 Information Technology - Abstract Syntax Notation One: 2356 Information Object Specification. 2358 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 2359 Information Technology - Abstract Syntax Notation One: 2360 Constraint Specification. 2362 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 2363 Information Technology - Abstract Syntax Notation One: 2364 Parameterization of ASN.1 Specifications. 2366 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 2367 Information Technology - ASN.1 encoding rules: 2368 Specification of Basic Encoding Rules (BER), Canonical 2369 Encoding Rules (CER) and Distinguished Encoding Rules 2370 (DER). 2372 34.2 Informative References 2374 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2375 Management Protocol (TAMP)", RFC 5934, August 2010. 2377 [X.411] ITU-T Recommendation X.411 (1988) | ISO/IEC 10021-4:1988, 2378 Data Communication Networks Message Handling Systems - 2379 Message Transfer System - Abstract Service Definition and 2380 Procedures. 2382 ID NSA's CMS Key Management Attributes November 10, 2014 2384 Appendix A. ASN.1 Module 2386 KMAttributes2012 2387 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2388 smime(16) modules(0) 39 } 2390 DEFINITIONS IMPLICIT TAGS ::= 2392 BEGIN 2394 -- EXPORT ALL 2396 IMPORTS 2398 -- From [RFC5911] 2400 aa-communityIdentifiers, CommunityIdentifier 2401 FROM CMSFirmwareWrapper-2009 2402 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2403 smime(16) modules(0) id-mod-cms-firmware-wrap-02(40) } 2405 -- From [RFC5911] 2407 aa-contentHint, ESSSecurityLabel, id-aa-securityLabel 2408 FROM ExtendedSecurityServices-2009 2409 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2410 smime(16) modules(0) id-mod-ess-2006-02(42) } 2412 -- From [RFC5911] [RFC5912] 2414 AlgorithmIdentifier{}, SMIME-CAPS, ParamOptions, KEY-WRAP 2415 FROM AlgorithmInformation-2009 2416 { iso(1) identified-organization(3) dod(6) internet(1) 2417 security(5) mechanisms(5) pkix(7) id-mod(0) 2418 id-mod-algorithmInformation-02(58) } 2420 -- From [RFC5912] 2422 Name, Certificate 2423 FROM PKIX1Explicit-2009 2424 { iso(1) identified-organization(3) dod(6) internet(1) 2425 security(5) mechanisms(5) pkix(7) id-mod(0) 2426 id-mod-pkix1-explicit-02(51) } 2428 ID NSA's CMS Key Management Attributes November 10, 2014 2430 -- From [RFC5912] 2432 GeneralNames, SubjectInfoAccessSyntax, id-pe-subjectInfoAccess 2433 FROM PKIX1Implicit-2009 2434 { iso(1) identified-organization(3) dod(6) internet(1) 2435 security(5) mechanisms(5) pkix(7) id-mod(0) 2436 id-mod-pkix1-implicit-02(59) } 2438 -- FROM [RFC5912] 2440 ATTRIBUTE 2441 FROM PKIX-CommonTypes-2009 2442 { iso(1) identified-organization(3) dod(6) internet(1) 2443 security(5) mechanisms(5) pkix(7) id-mod(0) 2444 id-mod-pkixCommon-02(57) } 2446 -- From [RFC6010] 2448 CMSContentConstraints 2449 FROM CMSContentConstraintsCertExtn 2450 { iso(1) identified-organization(3) dod(6) internet(1) 2451 security(5) mechanisms(5) pkix(7) id-mod(0) 2452 cmsContentConstr-93(42) } 2454 -- From [RFC6268] 2456 aa-binarySigningTime, BinaryTime 2457 FROM BinarySigningTimeModule-2010 2458 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2459 smime(16) modules(0) id-mod-binSigningTime-2009(55) } 2461 -- From [RFC6268] 2463 CertificateChoices, CertificateSet, Attribute {}, 2464 aa-contentType, aa-messageDigest 2465 FROM CryptographicMessageSyntax-2010 2466 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2467 smime(16) modules(0) id-mod-cms-2009(58) } 2469 -- From [RFC7191] 2471 aa-keyPackageIdentifierAndReceiptRequest, SIREntityName 2472 FROM KeyPackageReceiptAndErrorModuleV2 2473 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2474 smime(16) modules(0) id-mod-keyPkgReceiptAndErrV2(63) } 2476 ID NSA's CMS Key Management Attributes November 10, 2014 2478 -- From [X.509] 2480 certificateExactMatch 2481 FROM CertificateExtensions 2482 { joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4 } 2484 ; 2486 -- ATTRIBUTES 2488 -- Replaces SignedAttributesSet information object set from 2489 -- [RFC6268]. 2491 SignedAttributesSet ATTRIBUTE ::= { 2492 aa-contentType | 2493 aa-messageDigest | 2494 aa-contentHint | 2495 aa-communityIdentifiers | 2496 aa-binarySigningTime | 2497 aa-keyProvince-v2 | 2498 aa-keyPackageIdentifierAndReceiptRequest | 2499 aa-manifest | 2500 aa-keyAlgorithm | 2501 aa-userCertificate | 2502 aa-keyPackageReceivers-v2 | 2503 aa-tsecNomenclature | 2504 aa-keyPurpose | 2505 aa-keyUse | 2506 aa-transportKey | 2507 aa-keyDistributionPeriod | 2508 aa-keyValidityPeriod | 2509 aa-keyDurationPeriod | 2510 aa-classificationAttribute | 2511 aa-keyPackageType | 2512 aa-pkiPath | 2513 aa-usefulCertificates, 2514 ... } 2516 -- Replaces UnsignedAttributes from [RFC6268]. 2518 UnsignedAttributes ATTRIBUTE ::= { 2519 ... 2520 } 2522 ID NSA's CMS Key Management Attributes November 10, 2014 2524 -- Replaces UnprotectedEnvAttributes from [RFC6268]. 2526 UnprotectedEnvAttributes ATTRIBUTE ::= { 2527 aa-contentDecryptKeyIdentifier | 2528 aa-certificatePointers | 2529 aa-cRLDistributionPoints, 2530 ... 2531 } 2533 -- Replaces UnprotectedEncAttributes from [RFC6268]. 2535 UnprotectedEncAttributes ATTRIBUTE ::= { 2536 aa-certificatePointers | 2537 aa-cRLDistributionPoints, 2538 ... 2539 } 2541 -- Replaces AuthAttributeSet from [RFC6268] 2543 AuthAttributeSet ATTRIBUTE ::= { 2544 aa-contentType | 2545 aa-messageDigest | 2546 aa-contentHint | 2547 aa-communityIdentifiers | 2548 aa-keyProvice-v2 | 2549 aa-binarySigningTime | 2550 aa-keyPackageIdentifierAndReceiptRequest | 2551 aa-manifest | 2552 aa-keyAlgorithm | 2553 aa-userCertificate | 2554 aa-keyPackageReceivers-v2 | 2555 aa-tsecNomenclature | 2556 aa-keyPurpose | 2557 aa-keyUse | 2558 aa-transportKey | 2559 aa-keyDistributionPeriod | 2560 aa-keyValidityPeriod | 2561 aa-keyDurationPeriod | 2562 aa-classificationAttribute | 2563 aa-keyPackageType | 2564 aa-pkiPath | 2565 aa-usefulCertificates, 2566 ... } 2568 ID NSA's CMS Key Management Attributes November 10, 2014 2570 -- Replaces UnauthAttributeSet from [RFC6268] 2572 UnauthAttributeSet ATTRIBUTE ::= { 2573 ... 2574 } 2576 -- Replaces AuthEnvDataAttributeSet from [RFC6268] 2578 AuthEnvDataAttributeSet ATTRIBUTE ::= { 2579 aa-certificatePointers | 2580 aa-cRLDistributionPoints, 2581 ... 2582 } 2584 -- Replaces UnauthEnvDataAttributeSet from [RFC6268] 2586 UnauthEnvDataAttributeSet ATTRIBUTE ::= { 2587 ... 2588 } 2590 -- Replaces OneAsymmetricKeyAttributes from [RFC5958] 2592 OneAsymmetricKeyAttributes ATTRIBUTE ::= { 2593 aa-userCertificate | 2594 aa-tsecNomenclature | 2595 aa-keyPurpose | 2596 aa-keyUse | 2597 aa-transportKey | 2598 aa-keyDistributionPeriod | 2599 aa-keyValidityPeriod | 2600 aa-keyDurationPeriod | 2601 aa-classificationAttribute | 2602 aa-splitIdentifier | 2603 aa-signatureUsage-v3 | 2604 aa-otherCertificateFormats | 2605 aa-pkiPath | 2606 aa-usefulCertificates, 2607 ... } 2609 ID NSA's CMS Key Management Attributes November 10, 2014 2611 -- Replaces SKeyPkgAttributes from [RFC6031] 2613 SKeyPkgAttributes ATTRIBUTE ::= { 2614 aa-keyAlgorithm | 2615 aa-tsecNomenclature | 2616 aa-keyPurpose | 2617 aa-keyUse | 2618 aa-keyDistributionPeriod | 2619 aa-keyValidityPeriod | 2620 aa-keyDurationPeriod | 2621 aa-classificationAttribute | 2622 aa-keyWrapAlgorithm | 2623 aa-contentDecryptKeyIdentifier, 2624 ... } 2626 -- Replaces SKeyAttributes from [RFC6031] 2628 SKeyAttributes ATTRIBUTE ::= { 2629 aa-keyAlgorithm | 2630 aa-tsecNomenclature | 2631 aa-keyPurpose | 2632 aa-keyUse | 2633 aa-keyDistributionPeriod | 2634 aa-keyValidityPeriod | 2635 aa-keyDurationPeriod | 2636 aa-classificationAttribute | 2637 aa-splitIdentifier | 2638 aa-keyWrapAlgorithm | 2639 aa-contentDecryptKeyIdentifier, 2640 ... } 2642 ID NSA's CMS Key Management Attributes November 10, 2014 2644 -- Replaces ContentAttributeSet from [RFC6268] 2646 ContentAttributeSet ATTRIBUTE ::= { 2647 aa-communityIdentifiers | 2648 aa-keyPackageIdentifierAndReceiptRequest | 2649 aa-keyAlgorithm | 2650 aa-keyPackageReceivers-v2 | 2651 aa-tsecNomenclature | 2652 aa-keyPurpose | 2653 aa-keyUse | 2654 aa-transportKey | 2655 aa-keyDistributionPeriod | 2656 aa-transportKey | 2657 aa-keyDistributionPeriod | 2658 aa-keyValidityPeriod | 2659 aa-keyDurationPeriod | 2660 aa-classificationAttribute | 2661 aa-keyPackageType | 2662 aa-pkiPath | 2663 aa-usefulCertificates, 2664 ... } 2666 -- Content Type, Message Digest, and Content Hint, and Binary Signing 2667 -- Time are imported from [RFC6268]. 2668 -- Community Identifiers is imported from [RFC5911]. 2670 -- Key Province 2672 aa-keyProvince-v2 ATTRIBUTE ::= { 2673 TYPE KeyProvinceV2 2674 IDENTIFIED BY id-aa-KP-keyProvinceV2 } 2676 id-aa-KP-keyProvinceV2 OBJECT IDENTIFIER ::= 2677 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2678 dod(2) infosec(1) attributes(5) 71 } 2680 KeyProvinceV2 ::= OBJECT IDENTIFIER 2682 -- Manifest Attribute 2684 aa-manifest ATTRIBUTE ::= { 2685 TYPE Manifest 2686 IDENTIFIED BY id-aa-KP-manifest } 2688 id-aa-KP-manifest OBJECT IDENTIFIER ::= 2689 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2690 dod(2) infosec(1) attributes(5) 72 } 2692 ID NSA's CMS Key Management Attributes November 10, 2014 2694 Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle 2696 -- Key Algorithm Attribute 2698 aa-keyAlgorithm ATTRIBUTE ::= { 2699 TYPE KeyAlgorithm 2700 IDENTIFIED BY id-kma-keyAlgorithm } 2702 id-kma-keyAlgorithm OBJECT IDENTIFIER ::= 2703 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2704 dod(2) infosec(1) keying-material-attributes(13) 1 } 2706 KeyAlgorithm ::= SEQUENCE { 2707 keyAlg OBJECT IDENTIFIER, 2708 checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL, 2709 crcAlg [2] OBJECT IDENTIFIER OPTIONAL } 2711 -- User Certificate Attribute 2713 aa-userCertificate ATTRIBUTE ::= { 2714 TYPE Certificate 2715 EQUALITY MATCHING RULE certificateExactMatch 2716 IDENTIFIED BY id-at-userCertificate } 2718 id-at-userCertificate OBJECT IDENTIFIER ::= 2719 { joint-iso-itu-t(2) ds(5) attributes(4) 36 } 2721 -- Key Package Receivers Attribute 2723 aa-keyPackageReceivers-v2 ATTRIBUTE ::= { 2724 TYPE KeyPkgReceiversV2 2725 IDENTIFIED BY id-kma-keyPkgReceiversV2 } 2727 id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= 2728 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2729 dod(2) infosec(1) keying-material-attributes(13) 16 } 2731 KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver 2733 KeyPkgReceiver ::= CHOICE { 2734 sirEntity [0] SIREntityName, 2735 community [1] CommunityIdentifier } 2737 ID NSA's CMS Key Management Attributes November 10, 2014 2739 -- TSEC Nomenclature Attribute 2741 aa-tsecNomenclature ATTRIBUTE ::= { 2742 TYPE TSECNomenclature 2743 IDENTIFIED BY id-kma-TSECNomenclature } 2745 id-kma-TSECNomenclature OBJECT IDENTIFIER ::= 2746 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2747 dod(2) infosec(1) keying-material-attributes(13) 3 } 2749 TSECNomenclature ::= SEQUENCE { 2750 shortTitle ShortTitle, 2751 editionID EditionID OPTIONAL, 2752 registerID RegisterID OPTIONAL, 2753 segmentID SegmentID OPTIONAL } 2755 ShortTitle ::= PrintableString 2757 EditionID ::= CHOICE { 2758 char CHOICE { 2759 charEdition [1] CharEdition, 2760 charEditionRange [2] CharEditionRange }, 2761 num CHOICE { 2762 numEdition [3] NumEdition, 2763 numEditionRange [4] NumEditionRange } } 2765 CharEdition ::= PrintableString 2767 CharEditionRange ::= SEQUENCE { 2768 firstCharEdition CharEdition, 2769 lastCharEdition CharEdition } 2771 NumEdition ::= INTEGER (0..308915776) 2773 NumEditionRange ::= SEQUENCE { 2774 firstNumEdition NumEdition, 2775 lastNumEdition NumEdition } 2777 RegisterID ::= CHOICE { 2778 register [5] Register, 2779 registerRange [6] RegisterRange } 2781 Register ::= INTEGER (0..2147483647) 2783 RegisterRange ::= SEQUENCE { 2784 firstRegister Register, 2785 lastRegister Register } 2787 ID NSA's CMS Key Management Attributes November 10, 2014 2789 SegmentID ::= CHOICE { 2790 segmentNumber [7] SegmentNumber, 2791 segmentRange [8] SegmentRange } 2793 SegmentNumber ::= INTEGER (1..127) 2795 SegmentRange ::= SEQUENCE { 2796 firstSegment SegmentNumber, 2797 lastSegment SegmentNumber } 2799 -- Key Purpose Attribute 2801 aa-keyPurpose ATTRIBUTE ::= { 2802 TYPE KeyPurpose 2803 IDENTIFIED BY id-kma-keyPurpose } 2805 id-kma-keyPurpose OBJECT IDENTIFIER ::= 2806 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2807 dod(2) infosec(1) keying-material-attributes(13) 13 } 2809 KeyPurpose ::= ENUMERATED { 2810 n-a (0), -- Not Applicable 2811 a (65), -- Operational 2812 b (66), -- Compatible Multiple Key 2813 l (76), -- Logistics Combinations 2814 m (77), -- Maintenance 2815 r (82), -- Reference 2816 s (83), -- Sample 2817 t (84), -- Training 2818 v (86), -- Developmental 2819 x (88), -- Exercise 2820 z (90), -- "On the Air" Testing 2821 ... -- Expect additional key purpose values -- } 2823 -- Key Use Attribute 2825 aa-keyUse ATTRIBUTE ::= { 2826 TYPE KeyUse 2827 IDENTIFIED BY id-kma-keyUse } 2829 id-kma-keyUse OBJECT IDENTIFIER ::= 2830 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2831 dod(2) infosec(1) keying-material-attributes(13) 14 } 2833 ID NSA's CMS Key Management Attributes November 10, 2014 2835 KeyUse ::= ENUMERATED { 2836 n-a (0), -- Not Applicable 2837 ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format) 2838 kek (2), -- Key Encryption Key 2839 kpk (3), -- Key Production Key 2840 msk (4), -- Message Signature Key 2841 qkek (5), -- QUADRANT Key Encryption Key 2842 tek (6), -- Traffic Encryption Key 2843 tsk (7), -- Transmission Security Key 2844 trkek (8), -- Transfer Key Encryption Key 2845 nfk (9), -- Netted FIREFLY Key 2846 effk (10), -- FIREFLY Key (Enhanced Format) 2847 ebfk (11), -- FIREFLY Key (Enhanceable Basic Format) 2848 aek (12), -- Algorithm Encryption Key 2849 wod (13), -- Word of Day 2850 kesk (246), -- Key Establishment Key 2851 eik (247), -- Entity Identification Key 2852 ask (248), -- Authority Signature Key 2853 kmk (249), -- Key Modifier Key 2854 rsk (250), -- Revocation Signature Key 2855 csk (251), -- Certificate Signature Key 2856 sak (252), -- Symmetric Authentication Key 2857 rgk (253), -- Random Generation Key 2858 cek (254), -- Certificate Encryption Key 2859 exk (255), -- Exclusion Key 2860 ... -- Expect additional key use values -- } 2862 -- Transport Key Attribute 2864 aa-transportKey ATTRIBUTE ::= { 2865 TYPE TransOp 2866 IDENTIFIED BY id-kma-transportKey } 2868 id-kma-transportKey OBJECT IDENTIFIER ::= 2869 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2870 dod(2) infosec(1) keying-material-attributes(13) 15 } 2872 TransOp ::= ENUMERATED { 2873 transport (1), 2874 operational (2) } 2876 -- Key Distribution Period Attribute 2878 aa-keyDistributionPeriod ATTRIBUTE ::= { 2879 TYPE KeyDistPeriod 2880 IDENTIFIED BY id-kma-keyDistPeriod } 2882 ID NSA's CMS Key Management Attributes November 10, 2014 2884 id-kma-keyDistPeriod OBJECT IDENTIFIER ::= 2885 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2886 dod(2) infosec(1) keying-material-attributes(13) 5 } 2888 KeyDistPeriod ::= SEQUENCE { 2889 doNotDistBefore [0] BinaryTime OPTIONAL, 2890 doNotDistAfter BinaryTime } 2892 -- Key Validity Period Attribute 2894 aa-keyValidityPeriod ATTRIBUTE ::= { 2895 TYPE KeyValidityPeriod 2896 IDENTIFIED BY id-kma-keyValidityPeriod } 2898 id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= 2899 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2900 dod(2) infosec(1) keying-material-attributes(13) 6 } 2902 KeyValidityPeriod ::= SEQUENCE { 2903 doNotUseBefore BinaryTime, 2904 doNotUseAfter BinaryTime OPTIONAL } 2906 -- Key Duration Attribute 2908 aa-keyDurationPeriod ATTRIBUTE ::= { 2909 TYPE KeyDuration 2910 IDENTIFIED BY id-kma-keyDuration } 2912 id-kma-keyDuration OBJECT IDENTIFIER ::= 2913 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2914 dod(2) infosec(1) keying-material-attributes(13) 7 } 2916 KeyDuration ::= CHOICE { 2917 hours [0] INTEGER (1..ub-KeyDuration-hours), 2918 days INTEGER (1..ub-KeyDuration-days), 2919 weeks [1] INTEGER (1..ub-KeyDuration-weeks), 2920 months [2] INTEGER (1..ub-KeyDuration-months), 2921 years [3] INTEGER (1..ub-KeyDuration-years) } 2923 ub-KeyDuration-hours INTEGER ::= 96 2924 ub-KeyDuration-days INTEGER ::= 732 2925 ub-KeyDuration-weeks INTEGER ::= 104 2926 ub-KeyDuration-months INTEGER ::= 72 2927 ub-KeyDuration-years INTEGER ::= 100 2929 ID NSA's CMS Key Management Attributes November 10, 2014 2931 -- Classification Attribute 2933 -- The attribute syntax is imported from [RFC6268]. The term 2934 -- "classification" is used in this document, but the term "security 2935 -- label" is used in [RFC2634]. The terms have the same meaning. 2937 aa-classificationAttribute ATTRIBUTE ::= { 2938 TYPE Classification 2939 IDENTIFIED BY id-aa-KP-classification } 2941 id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel 2943 Classification ::= ESSSecurityLabel 2945 id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= 2946 { 2 16 840 1 101 2 1 8 3 4 } 2948 id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= 2949 { 2 16 840 1 101 2 1 8 3 1 } 2951 EnumeratedTag ::= SEQUENCE { 2952 tagName OBJECT IDENTIFIER, 2953 attributeList SET OF SecurityAttribute } 2955 SecurityAttribute ::= INTEGER (0..MAX) 2957 -- Split Identifier Attribute 2959 aa-splitIdentifier ATTRIBUTE ::= { 2960 TYPE SplitID 2961 IDENTIFIED BY id-kma-splitID } 2963 id-kma-splitID OBJECT IDENTIFIER ::= 2964 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2965 dod(2) infosec(1) keying-material-attributes(13) 11 } 2967 SplitID ::= SEQUENCE { 2968 half ENUMERATED { a(0), b(1) }, 2969 combineAlg AlgorithmIdentifier 2970 {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL } 2972 ID NSA's CMS Key Management Attributes November 10, 2014 2974 COMBINE-ALGORITHM ::= CLASS { 2975 &id OBJECT IDENTIFIER UNIQUE, 2976 &Params OPTIONAL, 2977 ¶mPresence ParamOptions DEFAULT absent, 2978 &smimeCaps SMIME-CAPS OPTIONAL 2979 } 2980 WITH SYNTAX { 2981 IDENTIFIER &id 2982 [PARAMS [TYPE &Params] ARE ¶mPresence] 2983 [SMIME-CAPS &smimeCaps] 2984 } 2986 CombineAlgorithms COMBINE-ALGORITHM ::= { 2987 ... 2988 } 2990 -- Key Package Type Attribute 2992 aa-keyPackageType ATTRIBUTE ::= { 2993 TYPE KeyPkgType 2994 IDENTIFIED BY id-kma-keyPkgType } 2996 id-kma-keyPkgType OBJECT IDENTIFIER ::= 2997 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2998 dod(2) infosec(1) keying-material-attributes(13) 12 } 3000 KeyPkgType ::= OBJECT IDENTIFIER 3002 -- Signature Usage Attribute 3004 aa-signatureUsage-v3 ATTRIBUTE ::= { 3005 TYPE SignatureUsage 3006 IDENTIFIED BY id-kma-sigUsageV3 } 3008 id-kma-sigUsageV3 OBJECT IDENTIFIER ::= 3009 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3010 dod(2) infosec(1) keying-material-attributes(13) 22 } 3012 SignatureUsage ::= CMSContentConstraints 3014 -- Other Certificate Format Attribute 3016 aa-otherCertificateFormats ATTRIBUTE ::= { 3017 TYPE CertificateChoices 3018 IDENTIFIED BY id-kma-otherCertFormats } 3020 ID NSA's CMS Key Management Attributes November 10, 2014 3022 id-kma-otherCertFormats OBJECT IDENTIFIER ::= 3023 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3024 dod(2) infosec(1) keying-material-attributes(13) 19 } 3026 -- PKI Path Attribute 3028 aa-pkiPath ATTRIBUTE ::= { 3029 TYPE PkiPath 3030 IDENTIFIED BY id-at-pkiPath } 3032 id-at-pkiPath OBJECT IDENTIFIER ::= 3033 { joint-iso-itu-t(2) ds(5) attributes(4) 70 } 3035 PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate 3037 -- Useful Certificates Attribute 3039 aa-usefulCertificates ATTRIBUTE ::= { 3040 TYPE CertificateSet 3041 IDENTIFIED BY id-kma-usefulCerts } 3043 id-kma-usefulCerts OBJECT IDENTIFIER ::= 3044 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3045 dod(2) infosec(1) keying-material-attributes(13) 20 } 3047 -- Key Wrap Attribute 3049 aa-keyWrapAlgorithm ATTRIBUTE ::= { 3050 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}} 3051 IDENTIFIED BY id-kma-keyWrapAlgorithm } 3053 id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= 3054 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3055 dod(2) infosec(1) keying-material-attributes(13) 21 } 3057 KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... } 3059 -- Content Decryption Key Identifier Attribute 3061 aa-contentDecryptKeyIdentifier ATTRIBUTE ::= { 3062 TYPE ContentDecryptKeyID 3063 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 3065 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= 3066 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3067 dod(2) infosec(1) attributes(5) 66 } 3069 ContentDecryptKeyID::= OCTET STRING 3071 ID NSA's CMS Key Management Attributes November 10, 2014 3073 -- Certificate Pointers Attribute 3075 aa-certificatePointers ATTRIBUTE ::= { 3076 TYPE SubjectInfoAccessSyntax 3077 IDENTIFIED BY id-pe-subjectInfoAccess } 3079 -- CRL Pointers Attribute 3081 aa-cRLDistributionPoints ATTRIBUTE ::= { 3082 TYPE GeneralNames 3083 IDENTIFIED BY id-aa-KP-crlPointers } 3085 id-aa-KP-crlPointers OBJECT IDENTIFIER ::= 3086 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3087 dod(2) infosec(1) attributes (5) 70 } 3089 -- ExtendedErrorCodes 3091 id-errorCodes OBJECT IDENTIFIER ::= 3092 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3093 dod(2) infosec(1) errorCodes(22) } 3095 id-missingKeyType OBJECT IDENTIFIER ::= { 3096 id-errorCodes 1 } 3098 id-privacyMarkTooLong OBJECT IDENTIFIER ::= { 3099 id-errorCodes 2 } 3101 id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= { 3102 id-errorCodes 3 } 3104 END 3106 ID NSA's CMS Key Management Attributes November 10, 2014 3108 Authors' Addresses 3110 Paul Timmel 3111 National Information Assurance Research Laboratory 3112 National Security Agency 3114 Email: pstimme@tycho.ncsc.mil 3116 Russ Housley 3117 Vigil Security, LLC 3118 918 Spring Knoll Drive 3119 Herndon, VA 20170 3120 USA 3122 Email: : housley@vigilsec.com 3124 Sean Turner 3125 IECA, Inc. 3126 3057 Nutley Street, Suite 106 3127 Fairfax, VA 22031 3128 USA 3130 Email: turners@ieca.com