idnits 2.17.1 draft-turner-km-attributes-00.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 -- The document date (June 4, 2013) is 3972 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5083' is mentioned on line 195, but not defined == Missing Reference: 'RFC6069' is mentioned on line 305, but not defined -- Looks like a reference, but probably isn't: '1' on line 2839 -- Looks like a reference, but probably isn't: '2' on line 2840 -- Looks like a reference, but probably isn't: '0' on line 2837 -- Looks like a reference, but probably isn't: '3' on line 2841 -- Looks like a reference, but probably isn't: '4' on line 2683 -- Looks like a reference, but probably isn't: '5' on line 2698 -- Looks like a reference, but probably isn't: '6' on line 2699 -- Looks like a reference, but probably isn't: '7' on line 2710 -- Looks like a reference, but probably isn't: '8' on line 2711 == Missing Reference: 'RF4073' is mentioned on line 2181, but not defined == Missing Reference: 'RFC5959' is mentioned on line 2184, but not defined == Unused Reference: 'FIPS-186' is defined on line 2303, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-housley-ct-keypackage-receipt-n-error-00 Summary: 0 errors (**), 0 flaws (~~), 7 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: December 6, 2013 Vigil Security 6 S. Turner 7 IECA 8 June 4, 2013 10 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes 11 draft-turner-km-attributes-00.txt 13 Abstract 15 This document defines key management attributes used by the National 16 Security Agency. The attributes can appear in asymmetric and/or 17 symmetric key packages as well as the Cryptographic Message Syntax 18 (CMS) content types that subsequently envelope the key packages. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 Copyright and License Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 ID NSA's CMS Key Management Attributes June 4, 2013 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Attribute Locations . . . . . . . . . . . . . . . . . . . . 3 56 1.2. ASN.1 Notation . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. CMS-Defined Attributes . . . . . . . . . . . . . . . . . . . . 5 59 3. Community Identifiers . . . . . . . . . . . . . . . . . . . . . 6 60 4. Binary Signing Time . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. User Certificate . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. Key Package Receivers . . . . . . . . . . . . . . . . . . . . . 10 65 9. TSEC Nomenclature . . . . . . . . . . . . . . . . . . . . . . . 11 66 10. Key Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 11. Key Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 12. Transport Key . . . . . . . . . . . . . . . . . . . . . . . . 18 69 13. Key Distribution Period . . . . . . . . . . . . . . . . . . . 19 70 14. Key Validity Period . . . . . . . . . . . . . . . . . . . . . 20 71 15. Key Duration . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 16. Classification . . . . . . . . . . . . . . . . . . . . . . . . 22 73 16.1. Security Label . . . . . . . . . . . . . . . . . . . . . . 23 74 17. Split Key Identifier . . . . . . . . . . . . . . . . . . . . . 27 75 18. Key Package Type . . . . . . . . . . . . . . . . . . . . . . . 27 76 19. Signature Usage . . . . . . . . . . . . . . . . . . . . . . . 28 77 20. Other Certificate Format . . . . . . . . . . . . . . . . . . . 30 78 21. PKI Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 79 22. Useful Certificates . . . . . . . . . . . . . . . . . . . . . 32 80 23. Key Wrap Algorithm . . . . . . . . . . . . . . . . . . . . . . 33 81 24. Content Decryption Key Identifier . . . . . . . . . . . . . . 33 82 24.1. Content Decryption Key Identifier: Symmetric Key and 83 Symmetric Key Package . . . . . . . . . . . . . . . . . . 34 84 24.2. Content Decryption Key Identifier: Unprotected . . . . . . 34 85 25. Certificate Pointers . . . . . . . . . . . . . . . . . . . . . 35 86 26. CRL Pointers . . . . . . . . . . . . . . . . . . . . . . . . . 35 87 27. Key Package Identifier and Receipt Request . . . . . . . . . . 36 88 28. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 36 89 29. Processing Key Package Attribute Values and CMS Content 90 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 37 91 30. Attribute Scope . . . . . . . . . . . . . . . . . . . . . . . 38 92 31. Security Considerations . . . . . . . . . . . . . . . . . . . 43 93 32. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 94 33. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 95 33.1 Normative References . . . . . . . . . . . . . . . . . . . 44 96 33.2 Informative References . . . . . . . . . . . . . . . . . . 46 97 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 47 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 100 ID NSA's CMS Key Management Attributes June 4, 2013 102 1. Introduction 104 This document defines key management attributes used by the National 105 Security Agency. The attributes can appear in asymmetric and/or 106 symmetric key packages as well as the Cryptographic Message Syntax 107 (CMS) content types that subsequently envelope the key packages. 109 1.1. Attribute Locations 111 There are a number of CMS content types that support attributes 112 SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData 113 [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData 114 [RFC5083] as well as ContentWithAttributes [RFC4073]. There are also 115 a number of other content types defined with CONTENT-TYPE [RFC6268] 116 that support attributes including AsymmetricKeyPackage [RFC5958] and 117 SymmetricKeyPackage [RFC6031]. 119 There are also different kinds of attributes in these content types: 121 o SignedData supports two kinds of attributes: signed and unsigned 122 attributes in the signedAttrs and unsignedAttrs fields, 123 respectively. 125 o EnvelopedData and EncryptedData each support one kind of 126 attribute: unprotected attributes in the unprotectedAttrs field. 128 o AuthenticatedData and AuthEnvelopedData each support two kinds of 129 attributes: authenticated and unauthenticated attributes in the 130 authAttrs and unauthAttrs fields, respectively. In 131 AuthEnvelopedData both attributes are also unprotected; 132 therefore, when specifically referring to AuthEnvelopedData 133 attributes they're authenticated/unprotected and 134 unauthenticated/unprotected. For this specification, 135 unauthenticated attributes MUST be omitted. 137 o ContentWithAttributes supports one kind of attribute: content 138 attributes in the attrs field. 140 o AsymmetricKeyPacakge supports one kind of attribute: asymmetric 141 key attributes in the attributes field. If an attribute appears 142 as part of an asymmetric key package, it SHOULD appear in the 143 attributes field of the AsymmetricKeyPackage. 145 o SymmetricKeyPackage supports two kinds of attributes: symmetric 146 key and symmetric key package attributes in the sKeyAttrs and 147 sKeyPkgAttrs fields, respectively. Note that [RFC6031] prohibits 148 the same attribute from appearing in both locations in the same 149 SymmetricKeyPackage. 151 ID NSA's CMS Key Management Attributes June 4, 2013 153 1.2. ASN.1 Notation 155 The attributes defined in this document use 2002 ASN.1 156 [X.680][X.681][X.682][X.683]. The attributes MUST be DER [X.690] 157 encoded. 159 Each of the attributes has a single attribute value instance in the 160 values set. Even though the syntax is defined as a set, there MUST 161 be exactly one instance of AttributeValue present. Further, the 162 SignedAttributes, UnsignedAttributes, UnprotectedAttributes, 163 AuthAttributes, and UnauthAttributes are also defined as a set, and 164 this set MUST include only one instance of any particular type of 165 attribute. That is, any object identifier appearing in AttributeType 166 MUST only appear one time in the set of attributes. 168 SignedData, EnvelopedData, EncryptedData, AuthenticatedData, 169 AuthEnvelopedData, and ContentWithAttributes were originally defined 170 using the 1988 version of ASN.1. These definitions were updated to 171 the 2008 version of ASN.1 by [RFC6268]. None of the new 2008 ASN.1 172 tokens are used, which allows 2002 compilers to compile 2008 ASN.1. 173 AsymmetricKeyPackage and SymmetricKeyPackage are defined using the 174 2002 ASN.1. 176 [RFC5652] and [RFC2634] define generally useful attributes for CMS 177 using the 1988 version of ASN.1. These definitions were updated to 178 the 2008 version of ASN.1 by [RFC6268] and the 2002 version of ASN.1 179 by [RFC5911], respectively. [RFC4108] and [RFC6069] also defined 180 attributes using the 1988 version of ASN.1, which this document uses. 181 Both were updated by [RFC5911] to the 2002 ASN.1. Refer to 182 [RFC2634], [RFC4108], [RFC5652], and [RFC6069] for the attribute's 183 semantics but refer to [RFC5911] or [RFC6268] for the attribute's 184 ASN.1 syntax. 186 1.3. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in RFC 191 2119 [RFC2119]. 193 CMS Protecting Content Types: SignedData [RFC5652], EnvelopedData 194 [RFC5652], EncryptedData [RFC5652], AuthenticatedData [RFC5652], and 195 AuthEnvelopedData [RFC5083] are referred to as CMS protecting content 196 types because they provide some type of security service. While 197 ContentWithAttributes [RFC4073] and ContentCollection [RFC4073] are 198 CMS content types that provide no security service. 200 Attribute Scope: The scope of an attribute is the compilation of 202 ID NSA's CMS Key Management Attributes June 4, 2013 204 keying material to which the attribute value is assigned. The scope 205 of each attribute is determined by its placement within the key 206 package or content collection. See Section 29. SIR: Sender- 207 Intermediary-Receiver is a model with three entities: 209 o A sender initiates the delivery of a key to one or more 210 receivers. It may wrap or encrypt the key for delivery. This is 211 expected to be the common case, since cleartext key is vulnerable 212 to exposure and compromise. If the sender is to encrypt the key 213 for delivery, it must know how to encrypt the key so that the 214 receiver(s) can decrypt it. A sender may also carry out any of 215 the functions of an intermediary. 217 * The original key package creators are sometimes referred to as 218 key source authorities. These entities create the symmetric 219 and/or asymmetric key package and apply the initial CMS 220 protecting layer, which is normally a SignedData but sometimes 221 an AuthenticatedData. This initial CMS protecting layer is 222 maintained through any intermediary for the receivers of the 223 key package to ensure that receivers can validate the key 224 source authority. 226 o An intermediary does not have access to cleartext key. An 227 intermediary may perform source authentication on key packages, 228 and may append or remove management information related to the 229 package. It may encapsulate the encrypted key packages in larger 230 packages that contain other user data destined for later 231 intermediaries or receivers. 233 o A receiver has access to cleartext key. If the received key 234 package is encrypted, it can unwrap or decrypt the encrypted key 235 to obtain the cleartext key. A receiver may be the final 236 destination of the cryptographic product. An element that acts 237 as a receiver and is not the final destination of the key package 238 may also act as a sender. After receiving a key, a receiver may 239 encrypt the received key for local storage. 241 2. CMS-Defined Attributes 243 The following attributes have been previously defined: 245 o content-type [RFC5652][RFC6268] uniquely specifies the CMS 246 content type. It MUST be included as signed, authenticated, and 247 authenticated/unprotected attributes. 249 o message-digest [RFC5652][RFC6268] is the message digest of the 250 encapsulated content calculated using the signer's message digest 251 algorithm. It MUST be included as signed and authenticated 253 ID NSA's CMS Key Management Attributes June 4, 2013 255 attributes and SHOULD NOT be included as an 256 authenticated/unprotected attribute. 258 o content-hints [RFC2634][RFC6268] identifies the innermost content 259 when multiple layers of encapsulation have been applied. It MUST 260 be included in every instance of SignedData, AuthenticatedData, 261 and AuthEnvelopedData that does not directly encapsulate a 262 SymmetricKeyPackage, an AsymmetricKeyPackage, or an 263 EncryptedKeyPackage [RFC6032]. 265 3. Community Identifiers 267 The community-identifiers [RFC4108][RFC5911] attribute lists the 268 communities that are authorized recipients of the signed content. It 269 can appear as a signed, authenticated, authenticated/unprotected, or 270 content attribute. This attribute MUST be supported. 272 The 2002 ASN.1 syntax for the community-identifier attribute is 273 included for convenience: 275 aa-communityIdentifiers ATTRIBUTE ::= { 276 TYPE CommunityIdentifiers 277 IDENTIFIED BY id-aa-communityIdentifiers } 279 id-aa-communityIdentifiers OBJECT IDENTIFIER ::= { 280 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 281 smime(16) aa(2) 40 } 283 CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier 285 CommunityIdentifier ::= CHOICE { 286 communityOID OBJECT IDENTIFIER, 287 hwModuleList HardwareModules } 289 HardwareModules ::= SEQUENCE { 290 hwType OBJECT IDENTIFIER, 291 hwSerialEntries SEQUENCE OF HardwareSerialEntry } 293 HardwareSerialEntry ::= CHOICE { 294 all NULL, 295 single OCTET STRING, 296 block SEQUENCE { 297 low OCTET STRING, 298 high OCTET STRING } } 300 Consult [RFC4108] for the attribute's semantics. 302 4. Binary Signing Time 303 ID NSA's CMS Key Management Attributes June 4, 2013 305 The binary-signing-time [RFC6069][RFC6268] attribute specifies the 306 time at which the signature or the message authentication code was 307 applied to the encapsulated content. It can appear as a signed, 308 authenticated, or authenticated/unprotected attribute. 310 The 2002 ASN.1 syntax is included for convenience: 312 aa-binarySigningTime ATTRIBUTE ::= { 313 TYPE BinarySigningTime 314 IDENTIFIED BY id-aa-binarySigningTime } 316 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { 317 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 318 smime(16) aa(2) 46 } 320 BinarySigningTime ::= BinaryTime 322 BinaryTime ::= INTEGER (0..MAX) 324 Consult [RFC6010] for the binary-signing-time attribute's semantics. 326 5. Manifest 328 The manifest attribute lists the short titles of all the TSEC- 329 Nomenclature attributes from inner key packages. It MUST only appear 330 as an outer-most signed, authenticated, or authenticated/unprotected 331 attribute. If a short title is repeated in inner packages, it need 332 only appear once in the manifest attribute. The manifest attribute 333 MUST NOT appear in the same level as the TSEC-Nomenclature. 335 The manifest attribute has the following syntax: 337 aa-manifest ATTRIBUTE ::= { 338 TYPE Manifest 339 IDENTIFIED BY id-aa-KP-manifest } 341 id-aa-KP-manifest OBJECT IDENTIFIER ::= { 342 joint-iso-itu-t(2) country(16) us(840) organization(1) 343 gov(101) dod(2) infosec(1) attributes(5) 72 } 345 Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle 347 6. Key Algorithm 349 The key-algorithm attribute indirectly specifies the size and format 350 of the keying material in the skey field of a symmetric key package. 351 It can appear as a symmetric key, symmetric key package, signed, 352 authenticated, authenticated/unprotected, or content attribute. If 354 ID NSA's CMS Key Management Attributes June 4, 2013 356 this attribute appears as a signed attribute, then all of the keying 357 material within the SignedData content MUST be associated with the 358 same algorithm. If this attribute appears as an authenticated or 359 authenticated/unprotected attribute, then all of the keying material 360 within the AuthenticatedData or AuthEnvelopedData content type MUST 361 be associated with the same algorithm. If this attribute appears as 362 a content attribute, then all of the keying material within the 363 collection MUST be associated with the same algorithm. If both the 364 key-algorithm and key-wrap-algorithm attributes apply to an sKey, 365 then the key-algorithm attribute refers to the decrypted value of 366 sKey rather than to the content of sKey itself. This attribute MUST 367 be supported. 369 The key-algorithm attribute has the following syntax: 371 aa-keyAlgorithm ATTRIBUTE ::= { 372 TYPE KeyAlgorithm 373 IDENTIFIED BY id-kma-keyAlgorithm } 375 id-kma-keyAlgorithm OBJECT IDENTIFIER ::= { 376 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 377 dod(2) infosec(1) keying-material-attributes(13) 1 } 379 KeyAlgorithm ::= SEQUENCE { 380 keyAlg OBJECT IDENTIFIER, 381 checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL, 382 crcAlg [2] OBJECT IDENTIFIER OPTIONAL } 384 The fields in the key-algorithm attribute have the following 385 semantics: 387 o keyAlg specifies the size and format of the keying material. 389 o If the particular key format supports more than one check word 390 algorithm, then the OPTIONAL checkWordAlg identifier indicates 391 which check word algorithm was used to generate the check word 392 that is present. If the check word algorithm is implied by the 393 key algorithm, then the checkWordAlg field SHUOLD be omitted. 395 o If the particular key format supports more than one Cyclic 396 Redundancy Check (CRC) algorithm, then the OPTIONAL crcAlg 397 identifier indicates which CRC algorithm was used to generate the 398 value that is present. If the CRC algorithm is implied by the 399 key algorithm, then the crcAlg field SHOULD be omitted. 401 The keyAlg identifier, the checkWordAlg identifier, and the crcAlg 402 identifier are object identifiers. The use of an object identifier 403 accommodates any algorithm from any registry. 405 ID NSA's CMS Key Management Attributes June 4, 2013 407 The format of the keying material in the skey field of a symmetric 408 key package will not match this attribute if the keying material is 409 split. In this situation, this attribute identifies the format of 410 the keying material once the two splits are combined. See section 18 411 for a discussion on the split-identifier attribute. Due to multiple 412 layers of encapsulation or the use of content collections, the key- 413 algorithm attribute can appear in more than one location in the 414 overall key package. When there are multiple occurrences of the key- 415 algorithm attribute within the same scope, the keyAlg field MUST 416 match in all instances. The OPTIONAL checkWordAlg and crcAlg fields 417 can be omitted in the key-algorithm attribute when it appears as a 418 signed, authenticated, or content attribute. However, if these 419 optional fields are present, they MUST also match the other 420 occurrences within the same scope. Receivers MUST reject any key 421 package that fails these consistency checks. 423 7. User Certificate 425 The user-certificate attribute specifies the type, format, and value 426 of an X.509 certificate and is used in asymmetric key package's 427 attributes field. This attribute can appear as an asymmetric key 428 attribute. This attribute MUST NOT appear in an asymmetric key 429 package attributes field that includes the other-certificate-formats 430 attribute. Symmetric key packages do not contain any certificates, 431 so the user-certificate attribute MUST NOT appear in a symmetric key 432 package. The user-certificate attribute MUST NOT appear as a signed, 433 authenticated, authenticated/unprotected, or content attribute. This 434 attribute MUST be supported. 436 The syntax is taken from [X.509] but redefined using the ATTRIBUTE 437 CLASS from [RFC5911]. The user-certificate attribute has the 438 following syntax: 440 aa-userCertificate ATTRIBUTE ::= { 441 TYPE Certificate 442 EQUALITY MATCING RULE certificateExactMatch 443 IDENTIFIED BY id-at-userCertificate } 445 id-at-userCertificate OBJECT IDENTIFIER ::= { 446 joint-iso-itu-t(2) ds(5) attributes(4) 36 } 448 Since the user-certificate attribute MUST NOT appear as a signed, 449 authenticated, or content attribute, an asymmetric key package cannot 450 include multiple occurrences of the user-certificate attribute within 451 the same scope. Receivers MUST reject any asymmetric key package in 452 which the user-certificate attribute appears as a signed, 453 authenticated, or content attribute. 455 ID NSA's CMS Key Management Attributes June 4, 2013 457 8. Key Package Receivers 459 The key-package-receivers-v2 attribute indicates the intended 460 audience for the key package. The key-package-receivers-v2 attribute 461 is not intended for access control decisions, rather intermediate 462 systems may use this attribute to make routing and relaying 463 decisions. The receiver SHOULD reject the key package if the key- 464 package-receivers-v2 attribute is present and they are not listed as 465 an intended receiver. The key-package-receivers-v2 attribute can be 466 used as a signed, authenticated, authenticated/unprotected, or 467 content attribute. If key-package-receivers-v2 attribute is 468 associated with a collection, then the named receivers MUST be able 469 to receive all of the key packages within the collection. This 470 attribute MUST be supported. 472 The key-package-receivers-v2 attribute has the following syntax: 474 aa-keyPackageReceivers-v2 ATTRIBUTE ::= { 475 TYPE KeyPkgReceiversV2 476 IDENTIFIED BY id-kma-keyPkgReceiversV2 } 478 id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= { 479 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 480 dod(2) infosec(1) keying-material-attributes(13) 16 } 482 KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver 484 KeyPkgReceiver ::= CHOICE { 485 sirEntity [0] SIREntityName, 486 community [1] CommunityIdentifier } 488 The key-package-receivers-v2 attribute contains a list of receiver 489 identifiers. The receiver identifier is either a SIREntityName or a 490 CommunityIdentifier. The SIREntityName syntax does not impose any 491 particular structure on the receiver identifier, but it does require 492 registration of receiver identifier types. The nameType ensures that 493 two receiver identifiers of different types that contain the same 494 values are not interpreted as equivalent. Name types are expected to 495 be defined that represent several different granularities. For 496 example, one name type will represent the receiver organization. At 497 a finer granularity, the name type will identify a specific 498 cryptographic device, perhaps using a manufacturer identifier and 499 serial number. 501 If a receiver does not recognize a particular nameType or a community 502 identifier, then keying material within the scope of the unrecognized 503 nameType or community identifier MUST NOT be used in any manner. 504 However, the receiver need not discard the associated key package. 506 ID NSA's CMS Key Management Attributes June 4, 2013 508 Since many cryptographic devices are programmable, a different 509 firmware load may recognize the nameType. Likewise, a change in the 510 configuration may lead to the recognition of a previously 511 unrecognized community identifier. Therefore, the receiver may 512 retain the key package, but refuse to use it for anything with a 513 firmware load that does not recognize the nameType or a configuration 514 that does not recognized the community identifier. 516 Whenever a key package is saved for later processing due to an 517 unrecognized nameType or community identifier, subsequent processing 518 MUST NOT rely on any checks that were made the first time the key 519 package processing was attempted. That is, the subsequent processing 520 MUST include the full complement of checks. Further, a receipt for 521 the packages MUST NOT be generated unless all of these checks are 522 successfully completed. 524 Due to multiple layers of encapsulation or the use of content 525 collections, the key-package-receivers-v2 attribute can appear in 526 more than one location in the overall key package. When there are 527 multiple occurrences of the key-package-receivers-v2 attribute, each 528 occurrence is evaluated independently. 530 In a content collection, each member of the collection might contain 531 its own signed, authenticated, or content attribute that includes a 532 key-package-receivers-v2 attribute. In this situation, each member 533 of the collection is evaluated separately, and any member that 534 includes an acceptable receiver SHOULD be retained. Other members 535 SHOULD be rejected or retained for later processing with a different 536 firmware load. 538 9. TSEC Nomenclature 540 The Telecommunications Security Nomenclature (TSEC-Nomenclature) 541 attribute provides the name for a piece of keying material, which 542 always includes the short title. The TSEC-Nomenclature attribute 543 also contains other identifiers when the short title is insufficient 544 to uniquely name a particular piece of keying material. This 545 attribute can appear as a symmetric key, symmetric key package, 546 asymmetric key, signed, authenticated, authenticated/unprotected, or 547 content attribute. If this attribute appears in the sKeyAttrs field, 548 the EditionID, RegisterID, and SegmentID attribute fields MUST NOT be 549 ranges. If this attribute appears as a signed, authenticated, or 550 content attribute, all of the keying material within the associated 551 content MUST have the same short title, and the attribute value MUST 552 contain only a short title. That is, when this attribute appears as 553 a signed, authenticated, or content attribute, all of the optional 554 fields MUST be absent. If this attribute is associated with a 555 collection, all of the keying material within the collection MUST 557 ID NSA's CMS Key Management Attributes June 4, 2013 559 have the same short title; however, the edition, register, and 560 segment identifiers will be different for each key package in the 561 collection. This attribute MUST be supported. 563 The TSEC-Nomenclature attribute has the following syntax: 565 aa-tsecNomenclature ATTRIBUTE ::= { 566 TYPE TSECNomenclature 567 IDENTIFIED BY id-kma-TSECNomenclature } 569 id-kma-TSECNomenclature OBJECT IDENTIFIER ::= { 570 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 571 dod(2) infosec(1) keying-material-attributes(13) 3 } 573 TSECNomenclature ::= SEQUENCE { 574 shortTitle ShortTitle, 575 editionID EditionID OPTIONAL, 576 registerID RegisterID OPTIONAL, 577 segmentID SegmentID OPTIONAL } 579 ShortTitle ::= PrintableString 581 EditionID ::= CHOICE { 582 char CHOICE { 583 charEdition [1] CharEdition, 584 charEditionRange [2] CharEditionRange } 585 num CHOICE { 586 numEdition [3] NumEdition, 587 numEditionRange [4] NumEditionRange } } 589 CharEdition ::= PrintableString 591 CharEditionRange ::= SEQUENCE { 592 firstCharEdition CharEdition, 593 lastCharEdition CharEdition } 595 NumEdition ::= INTEGER (0..308915776) 597 NumEditionRange ::= SEQUENCE { 598 firstNumEdition NumEdition, 599 lastNumEdition NumEdition } 601 RegisterID ::= CHOICE { 602 register [5] Register, 603 registerRange [6] RegisterRange } 605 Register ::= INTEGER (0..2147483647) 607 ID NSA's CMS Key Management Attributes June 4, 2013 609 RegisterRange ::= SEQUENCE { 610 firstRegister Register, 611 lastRegister Register } 613 SegmentID ::= CHOICE { 614 segmentNumber [7] SegmentNumber, 615 segmentRange [8] SegmentRange } 617 SegmentNumber ::= INTEGER (1..127) 619 SegmentRange ::= SEQUENCE { 620 firstSegment SegmentNumber, 621 lastSegment SegmentNumber } 623 The fields in the TSEC-Nomenclature attribute have the following 624 semantics: 626 o The short title consists of up to 32 alphanumeric characters. 627 Short title processing always uses the value in its entirety. 629 o The edition identifier is OPTIONAL, and the edition identifier is 630 used to distinguish accountable items. The edition identifier 631 consists either of six alphanumeric characters or an integer. 632 When present, the edition identifier is either a single value or 633 a range. The integer encoding should be used when it is 634 important to keep key package size to a minimum. 636 o The register identifier is OPTIONAL. For electronic keying 637 material, the register identifier is usually omitted. The 638 register identifier is an accounting number assigned to identify 639 COMSEC material. The register identifier is either a single 640 value or a range. 642 o The segment identifier is OPTIONAL, and it distinguishes the 643 individual symmetric keys delivered in one edition. A unique 644 segment number is assigned to each key in an edition. The 645 segment number is set to one for the first item in each edition, 646 and it is incremented by one for each additional item within that 647 edition. The segment identifier is either a single value or a 648 range. 650 The order that the keying material will appear in the key package is 651 illustrated by the following example. A cryptographic device may 652 require fresh keying material every day. An edition represents the 653 keying material for a single month, and the segments represent the 654 keying material for a day within that month. Consider a key package 655 that contains the keying material for July and August; it will 656 contain keying material for 62 days. The keying material will appear 658 ID NSA's CMS Key Management Attributes June 4, 2013 660 in the following order: Edition 1, Segment 1; Edition 1, Segment 2; 661 Edition 1, Segment 3; ...; Edition 1, Segment 31; Edition 2, Segment 662 1; Edition 2, Segment 2; Edition 2, Segment 3; ...; Edition 2, 663 Segment 31. 665 Due to multiple layers of encapsulation or the use of content 666 collections, the TSEC-Nomenclature attribute can appear in more than 667 one location in the overall key package. When there are multiple 668 occurrences of the TSEC-Nomenclature attribute within the same scope, 669 the shortTitle field MUST match in all instances. Recall that the 670 optional parts MUST be omitted when the TSEC-Nomenclature attribute 671 appears as a signed, authenticated, or content attribute. Receivers 672 MUST reject any key package that fails these consistency checks. 674 When the manifest attribute is included in an outer layer, the 675 shortTitle field values present in TSEC-Nomenclature attributes MUST 676 be one of the values in the manifest attribute. Receivers MUST 677 reject any key package that fails this consistency checks. 679 10. Key Purpose 681 The key-purpose attribute specifies the intended purpose of the key 682 material. It can appear as a symmetric key, symmetric key package, 683 asymmetric key, signed, authenticated, authenticated/unprotected, or 684 content attribute. If the key-purpose attribute appears as a signed, 685 authenticated, or content attribute, then all of the keying material 686 within the associated content MUST have the same key purpose value. 688 The key-purpose attribute has the following syntax: 690 aa-keyPurpose ATTRIBUTE ::= { 691 TYPE KeyPurpose 692 IDENTIFIED BY id-kma-keyPurpose } 694 id-kma-keyPurpose OBJECT IDENTIFIER ::= { 695 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 696 dod(2) infosec(1) keying-material-attributes(13) 13 } 698 KeyPurpose ::= ENUMERATED { 699 n-a (0), -- Not Applicable 700 a (65), -- Operational 701 b (66), -- Compatible Multiple Key 702 l (76), -- Logistics Combinations 703 m (77), -- Maintenance 704 r (82), -- Reference 705 s (83), -- Sample 706 t (84), -- Training 707 v (86), -- Developmental 709 ID NSA's CMS Key Management Attributes June 4, 2013 711 x (88), -- Exercise 712 z (90), -- "On the Air" Testing 713 ... -- Expect additional key purpose values -- } 715 Due to multiple layers of encapsulation or the use of content 716 collections, the key-purpose attribute can appear in more than one 717 location in the overall key package. When there are multiple 718 occurrences of the key-purpose attribute within the same scope, all 719 fields within the attribute MUST contain exactly the same values. 720 Receivers MUST reject any key package that fails these consistency 721 checks. 723 11. Key Use 725 The key-use attribute specifies the intended use of the key material. 726 It can appear as a symmetric key, symmetric key package, asymmetric, 727 signed, authenticated, authenticated/unprotected, or content 728 attribute. If the key-use attribute appears as a signed, 729 authenticated, or content attribute, then all of the keying material 730 within the associated content MUST have the same key use value. 732 The key-use attribute has the following syntax: 734 aa-key-Use ATTRIBUTE ::= { 735 TYPE KeyUse 736 IDENTIFIED BY id-kma-keyUse } 738 id-kma-keyUse OBJECT IDENTIFIER ::= { 739 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 740 dod(2) infosec(1) keying-material-attributes(13) 14 } 742 KeyUse ::= ENUMERATED { 743 n-a (0), -- Not applicable 744 ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format) 745 kek (2), -- Key Encryption Key 746 kpk (3), -- Key Production Key 747 msk (4), -- Message Signature Key 748 qkek (5), -- QUADRANT Key Encryption Key 749 tek (6), -- Traffic Encryption Key 750 tsk (7), -- Transmission Security Key 751 trkek (8), -- Transfer Key Encryption Key 752 nfk (9), -- Netted FIREFLY Key 753 effk (10), -- FIREFLY Key (Enhanced Format) 754 ebfk (11), -- FIREFLY Key (Enhanceable Basic Format) 755 aek (12), -- Algorithm Encryption Key 756 wod (13), -- Word of Day 757 kesk (246), -- Key Establishment Key 758 eik (247), -- Entity Identification Key 760 ID NSA's CMS Key Management Attributes June 4, 2013 762 ask (248), -- Authority Signature Key 763 kmk (249), -- Key Modifier Key 764 rsk (250), -- Revocation Signature Key 765 csk (251), -- Certificate Signature Key 766 sak (252), -- Symmetric Authentication Key 767 rgk (253), -- Random Generation Key 768 cek (254), -- Certificate Encryption Key 769 exk (255), -- Exclusion Key 770 ... -- Expect additional key use values -- } 772 The values for the key-use attribute has the following semantics: 774 o ffk: A FIREFLY/CROSSTALK key is used to establish a Key 775 Establishment Key (KEK) or a Transmission Encryption Key (TEK) 776 between two parties. The KEK or TEK generated from the exchange 777 is used with a symmetric encryption algorithm. This key use 778 value is associated with keys in the basic format. 780 o kek: A Key Encryption Key is used to encrypt or decrypt other 781 keys for transmission or storage. 783 o kpk: A Key Production Key is used to initialize a keystream 784 generator for the production of other electronically generated 785 keys. 787 o msk: A Message Signature Key is used in a digital signature 788 process that operates on a message to assure message source 789 authentication, message integrity, and non-repudiation. 791 o qkek: QUADRANT Key Encryption Key is one part of a tamper 792 resistance solution. 794 o tek: A Traffic Encryption Key is used to encrypt plaintext or to 795 superencrypt previously encrypted data and/or to decrypt 796 ciphertext. 798 o tsk: A Transmission Security Key is used to protect transmissions 799 from interception and exploitation by means other than 800 cryptanalysis. 802 o trkek: Transfer Key Encryption Key. For example, the keys used 803 by the KP and DTD. 805 o nfk: A Netted FIREFLY Key is a FIREFLY key that has an edition 806 number associated with it. When rekeyed, it is incremented, 807 preventing communications with FIREFLY key of previous editions. 808 This edition number is maintained within a universal edition. 810 ID NSA's CMS Key Management Attributes June 4, 2013 812 o effk: Enhanced FIREFLY Key is used to establish a KEK or a TEK 813 between two parties. The KEK or TEK generated from an exchange 814 is used with a symmetric encryption algorithm. This key use 815 value is associated with keys in the enhanced format. 817 o ebkf: Enhanceable Basic FIREFLY Key is used to establish a KEK or 818 a TEK between two parties. The KEK or TEK generated from an 819 exchange is used with a symmetric encryption algorithm. This key 820 use value is associated with keys in the enhanceable basic 821 format. 823 o aek: An Algorithm Encryption Key is used to encrypt or decrypt an 824 algorithm implementation as well as other functionality in the 825 implementation. 827 o wod: A key used to generate the Word of the Day (WOD). 829 o kek: A Key Establishment Key is an asymmetric key set (e.g. 830 public/private/parameters) used to enable the establishment of 831 symmetric key(s) between entities. 833 o eik: An Entity Identification Key is an asymmetric key set (e.g. 834 public/private/parameters) used to identify one entity to another 835 for access control and other similar purposes. 837 o ask: An Authority Signature Key is an asymmetric key set (e.g. 838 public/private/parameters) used by designated authorities to sign 839 objects such as TAMP messages and firmware packages. 841 o kmk: A Key Modifier Key is a symmetric key used to modify the 842 results of the process that forms a symmetric key from a public 843 key exchange process. 845 o rsk: A Revocation Signature Key is an asymmetric key set (e.g. 846 public/private/parameters) used to sign and authenticate 847 revocation lists and compromised key lists. 849 o csk: A Certificate Signature Key is an asymmetric key set (e.g. 850 public/private/parameters) used to sign and authenticate public- 851 key certificates. 853 o sak: A Symmetric Authentication Key is used in a Message 854 Authentication Code (MAC) algorithm to provide message integrity. 855 Differs from a Message Signature Key in that it is symmetric key 856 material and it does not provide source authentication or non- 857 repudiation. 859 o rgk: Random Generation Key is a key used to seed a deterministic 861 ID NSA's CMS Key Management Attributes June 4, 2013 863 pseudo-random number generator. 865 o cek: A Certificate Encryption Key is used to encrypt public-key 866 certificates to support privacy. 868 o exk: An Exclusion Key is a symmetric key used to 869 cryptographically subdivide a single large security domain into 870 smaller segregated domains. 872 Due to multiple layers of encapsulation or the use of content 873 collections, the key-use attribute can appear in more than one 874 location in the overall key package. When there are multiple 875 occurrences of the key-use attribute within the same scope, all 876 fields within the attribute must contain exactly the same values. 877 Receivers must reject any key package that fails these consistency 878 checks. 880 12. Transport Key 882 The transport-key attribute identifies whether an asymmetric key is a 883 transport key or an operational key (i.e., the key can either be used 884 as is or not). It can appear as an asymmetric key, signed, 885 authenticated, authenticated/unprotected, or content attribute. If 886 the transport-key attribute appears as a signed, authenticated, or 887 content attribute, then all of the keying material within the 888 associated content MUST have the same operational/transport key 889 material. 891 aa-transportKey ATTRIBUTE ::= { 892 TYPE TransOp 893 IDENTIFIED BY id-kma-transportKey } 895 id-kma-transportKey OBJECT IDENTIFIER ::= { 896 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 897 dod(2) infosec(1) keying-material-attributes(13) 15 } 899 TransOp ::= ENUMERATED { 900 transport (1), 901 operational (2) } 903 Due to multiple layers of encapsulation or the use of content 904 collections, the transport-key attribute can appear in more than one 905 location in the overall key package. When there are multiple 906 occurrences of the transport-key attribute within the same scope, all 907 fields within the attribute MUST contain exactly the same values. 908 Receivers MUST reject any key package that fails these consistency 909 checks. 911 ID NSA's CMS Key Management Attributes June 4, 2013 913 13. Key Distribution Period 915 The key-distribution-period attribute indicates the period of time 916 that the keying material is intended for distribution. Keying 917 material is often distributed before it is intended to be used. Time 918 of day must be represented in Coordinated Universal Time (UTC). It 919 can appear as a symmetric key, symmetric key package, asymmetric key, 920 signed, authenticated, authenticated/unprotected, or content 921 attribute. If the key-distribution-period attribute appears as a 922 signed, authenticated, or content attribute, then all of the keying 923 material within the content MUST have the same key distribution 924 period. 926 The key-distribution-period attribute has the following syntax: 928 aa-keyDistributionPeriod ATTRIBUTE ::= { 929 TYPE KeyDistPeriod 930 IDENTIFIED BY id-kma-keyDistPeriod } 932 id-kma-keyDistPeriod OBJECT IDENTIFIER ::= { 933 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 934 dod(2) infosec(1) keying-material-attributes(13) 5 } 936 KeyDistPeriod ::= SEQUENCE { 937 doNotDistBefore [0] BinaryTime OPTIONAL, 938 doNotDistAfter BinaryTime } 940 BinaryTime ::= INTEGER 942 The fields in the key-distribution-period attribute have the 943 following semantics: 945 o The doNotDistBefore field is OPTIONAL, and when it is present, 946 the keying material SHOULD NOT be distributed before the date and 947 time provided. 949 o The doNotDistAfter field is REQUIRED, and the keying material 950 SHOULD NOT be distributed after the date and time provided. 952 When the key-distribution-period attribute is associated with a 953 collection of keying material, the distribution period applies to all 954 of the keys in the collection. None of the keying material in the 955 collection SHOULD be distributed outside the indicated period. 957 Due to multiple layers of encapsulation or the use of content 958 collections, the key-distribution-period attribute can appear in more 959 than one location in the overall key package. When there are 960 multiple occurrences of the key-distribution-period attribute within 962 ID NSA's CMS Key Management Attributes June 4, 2013 964 the same scope, all of the included attribute fields MUST contain 965 exactly the same value. However, if the doNotDistBefore field is 966 absent in an inner layer, a value MAY appear in an outer layer. 967 Receivers MUST reject any key package that fails these consistency 968 checks. 970 14. Key Validity Period 972 The key-validity-period attribute indicates the period of time that 973 the keying material is intended for use. Time of day MUST be 974 represented in Coordinated Universal Time (UTC). It can appear as a 975 symmetric key, symmetric key package, asymmetric key, signed, 976 authenticated, authenticated/unprotected, or content attribute. If 977 the key-validity-period attribute appears as a signed, authenticated, 978 authenticated/unprotected, or content attribute, then all of the 979 keying material within the content MUST have the same key validity 980 period. 982 The key-validity-period attribute has the following syntax: 984 aa-keyValidityPeriod ATTRIBUTE ::= { 985 TYPE KeyValidityPeriod 986 IDENTIFIED BY id-kma-keyValidityPeriod } 988 id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= { 989 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 990 dod(2) infosec(1) keying-material-attributes(13) 6 } 992 KeyValidityPeriod ::= SEQUENCE { 993 doNotUseBefore BinaryTime, 994 doNotUseAfter BinaryTime OPTIONAL } 996 BinaryTime ::= INTEGER 998 The fields in the key-distribution-period attribute have the 999 following semantics: 1001 o The doNotUseBefore field is required, and the keying material 1002 should not be used before the date and time provided. 1004 o The doNotUseAfter field is optional, and when it is present, the 1005 keying material should not be used after the date and time 1006 provided. 1008 For a key package that is being used for rekey, the doNotUseAfter 1009 field MAY be required even though the syntax is OPTIONAL. 1011 When the key-validity-period attribute is associated with a 1013 ID NSA's CMS Key Management Attributes June 4, 2013 1015 collection of keying material, the validity period applies to all of 1016 the keys in the collection. None of the keying material in the 1017 collection SHOULD be used outside the indicated period. The key- 1018 validity-period attribute described in this section and the key- 1019 duration attribute described in the next section provide a 1020 complementary function. The key-validity-period attribute provides 1021 explicit date and time values, which indicate the beginning and 1022 ending of the keying material usage period. The key-duration 1023 attribute provides the maximum length of time that the keying 1024 material SHOULD be used. If both attributes are provided, this 1025 duration MAY occur at any time within the specified period, but the 1026 limits imposed by both attributes SHOULD be honored. 1028 Due to multiple layers of encapsulation or the use of content 1029 collections, the key-validity-period attribute can appear in more 1030 than one location in the overall key package. When there are 1031 multiple occurrences of the key-validity-period attribute within the 1032 same scope, all of the included attribute fields MUST contain exactly 1033 the same value. However, if the doNotUseAfter field is absent in an 1034 inner layer, a value MAY appear in an outer layer. Receivers MUST 1035 reject any key package that fails these consistency checks. 1037 15. Key Duration 1039 The key-duration attribute indicates the maximum period of time that 1040 the keying material is intended for use. The date and time that the 1041 duration begins is not specified, but the maximum amount of time that 1042 the keying material can be used to provide security services is 1043 specified. It can appear as a symmetric key, symmetric key package, 1044 asymmetric key, signed, authenticated, authenticated/unprotected, or 1045 content attribute. If the key-duration attribute appears as a 1046 signed, authenticated, authenticated/unprotected, or content 1047 attribute, then all of the keying material within the content MUST 1048 have the same key duration. 1050 The key-duration attribute has the following syntax: 1052 aa-keyDurationPeriod ATTRIBUTE ::= { 1053 TYPE KeyDuration 1054 IDENTIFIED BY id-kma-keyDuration } 1056 id-kma-keyDuration OBJECT IDENTIFIER ::= { 1057 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1058 dod(2) infosec(1) keying-material-attributes(13) 7 } 1060 KeyDuration ::= CHOICE { 1061 hours [0] INTEGER (1..ub-KeyDuration-hours), 1062 days INTEGER (1..ub-KeyDuration-days), 1064 ID NSA's CMS Key Management Attributes June 4, 2013 1066 weeks [1] INTEGER (1..ub-KeyDuration-weeks), 1067 months [2] INTEGER (1..ub-KeyDuration-months), 1068 years [3] INTEGER (1..ub-KeyDuration-years) } 1070 ub-KeyDuration-hours INTEGER ::= 96 1071 ub-KeyDuration-days INTEGER ::= 732 1072 ub-KeyDuration-weeks INTEGER ::= 104 1073 ub-KeyDuration-months INTEGER ::= 72 1074 ub-KeyDuration-years INTEGER ::= 100 1076 The key-validity-period attribute described in the previous section 1077 and the key-duration attribute described in this section provide a 1078 complementary function. The relationship between these attributes is 1079 described in the previous section. 1081 Due to multiple layers of encapsulation or the use of content 1082 collections, the key-duration attribute can appear in more than one 1083 location in the overall key package. When there are multiple 1084 occurrences of the key-duration attribute within the same scope, all 1085 of the included attribute fields MUST contain exactly the same value. 1086 Receivers MUST reject any key package that fails these consistency 1087 checks. 1089 16. Classification 1091 The classification attribute indicates level of classification. The 1092 classification attribute specifies the aggregate classification of 1093 the package content. It can appear as a symmetric key, symmetric key 1094 package, asymmetric key, signed, authenticated, 1095 authenticated/unprotected, or content attribute. If the 1096 classification attribute appears as a signed, authenticated, 1097 authenticated/unprotected, or content attribute, then the value MUST 1098 represent the classification of all of the keying material within the 1099 content. Encrypted layers MAY contain content at a higher 1100 classification that will be revealed once they are decrypted. If the 1101 classification attribute is associated with a collection, then the 1102 sensitivity of all the data within the collection MUST be dominated 1103 by the classification carried in this attribute. 1105 The classification attribute makes use of the ESSSecurityLabel 1106 defined in Section 3.2 of [RFC2634][RFC5911]. The term 1107 "classification" is used in this document, but the term "security 1108 label" is used in [RFC2634]. The two terms have the same meaning. 1110 [RFC2634][RFC5911] specifies an object identifier and syntax for the 1111 security label attribute. The same values are used for the 1112 classification attribute: 1114 ID NSA's CMS Key Management Attributes June 4, 2013 1116 aa-classificationAttribute ATTRIBUTE ::= { 1117 TYPE Classification 1118 IDENTIFIED BY id-aa-KP-classification } 1120 id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel 1122 -- id-aa-securityLabel OBJECT IDENTIFIER ::= { 1123 -- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1124 -- pkcs-9(9) smime(16) id-aa(2) 2 } 1126 Classification ::= ESSSecurityLabel 1128 The syntax of ESSSecurityLabel is not repeated here; however, see 1129 section 17.1 for security label conventions that MUST be followed by 1130 implementations of this specification. See [RFC2634] for a complete 1131 discussion of the semantics and syntax. 1133 When the classification attribute appears in more than one location 1134 in the overall key package, each occurrence is evaluated 1135 independently. The content originator MUST ensure that the 1136 classification attribute represents the sensitivity of the plaintext 1137 within the content. That is, the classification MUST dominate any 1138 other plaintext classification attribute value that is present 1139 elsewhere in the overall key package. Note that the classification 1140 attribute value may exceed these other plaintext classification 1141 attribute values if the other attribute values within the SignerInfo, 1142 AuthEnvelopedData, or AuthenticatedData are themselves classified and 1143 warrant the higher security label value. 1145 When the classification attribute appears in more than one location 1146 in the overall key package, each security label might be associated 1147 with a different security policy. Content originators SHOULD avoid 1148 mixing multiple security policies in the same key package whenever 1149 possible since this requires that receivers and intermediaries that 1150 check the classification attribute values to include support for the 1151 union of the security policies that are present. Failure to 1152 recognize an included security policy MUST result in rejection of the 1153 key package. 1155 Receivers MUST reject any key package that includes a classification 1156 for which the receiver's processing environment is not authorized. 1158 16.1. Security Label 1160 The ESSSecurityLabel ASN.1 type is used to represent the 1161 classification. The ESSSecurityLabel is defined in Section 3.2 of 1162 [RFC2634]. 1164 ID NSA's CMS Key Management Attributes June 4, 2013 1166 The classification attribute values and classification attribute 1167 values have ASN.1 type ESSSecurityLabel. Part of the syntax 1168 definition is repeated here to facilitate discussion: 1170 ESSSecurityLabel ::= SET { 1171 security-policy-identifier SecurityPolicyIdentifier, 1172 security-classification SecurityClassification OPTIONAL, 1173 privacy-mark ESSPrivacyMark OPTIONAL, 1174 security-categories SecurityCategories OPTIONAL } 1176 A security policy is a set of criteria for the provision of security 1177 services. The security-policy-identifier, which is an object 1178 identifier, is used to identify the security policy associated with 1179 the security label. It indicates the semantics of the other security 1180 label components. 1182 If the key package receiver does not recognize the object identifier 1183 in the security-policy-identifier field and the security label 1184 includes a security-categories field, then the key package contents 1185 MUST NOT be accepted and the enclosed keying material MUST NOT be 1186 used. If the key package receiver does not recognize the object 1187 identifier in the security-policy-identifier field and the security 1188 label does not include a security-categories field, then the key 1189 package contents MAY be accepted only if the security-classification 1190 field is present and it contains a value from the basic hierarchy as 1191 described below. 1193 This specification defines the use of the SecurityClassification 1194 field exactly as is it specified in the 1988 edition of ITU-T 1195 Recommendation X.411 [X.411-88], which states in part: 1197 "If present, a security-classification may have one of a 1198 hierarchical list of values. The basic security-classification 1199 hierarchy is defined in this Recommendation, but the use of these 1200 values is defined by the security-policy in force. Additional 1201 values of security-classification, and their position in the 1202 hierarchy, may also be defined by a security-policy as a local 1203 matter or by bilateral agreement. The basic security- 1204 classification hierarchy is, in ascending order: unmarked, 1205 unclassified, restricted, confidential, secret, top-secret." 1207 Implementations MUST support the basic security classification 1208 hierarchy. Such implementations MAY also support other security- 1209 classification values; however, the placement of additional values in 1210 the hierarchy MUST be specified by the security policy. 1212 Implementations MUST NOT make access control decisions based on the 1213 privacy-mark. However, information in the privacy-mark can be 1215 ID NSA's CMS Key Management Attributes June 4, 2013 1217 displayed to human users by devices that have displays to do so. The 1218 privacy-mark length MUST NOT exceed 128 characters. The privacy-mark 1219 SHALL use the PrintableString choice if the all of the characters in 1220 the privacy mark are members of the printable string character set. 1222 If present, security-categories provide further granularity for the 1223 keying material. The security policy in force indicates the 1224 permitted syntaxes of any entries in the set of security categories. 1225 At most, 64 security categories may be present. The security- 1226 categories have ASN.1 type SecurityCategories and further 1227 SecurityCategory [RFC5912], which are both repeated here to 1228 facilitate discussion: 1230 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 1231 SecurityCategory 1232 {{SupportedSecurityCategories}} 1234 SecurityCategory {SECURITY-CATEGORY:Supported} ::= SEQUENCE { 1235 type [0] IMPLICIT SECURITY-CATEGORY. 1236 &id({Supported}), 1237 value [1] EXPLICIT SECURITY-CATEGORY. 1238 &Type({Supported}{@type}) 1239 } 1241 Four security categories are defined and are referred to as the 1242 Restrictive Tag, the Enumerated Tag, the Permissive Tag, and the 1243 Informative Tag. Only the Enumerated Tag and Informative Tag are 1244 permitted in the classification attribute. 1246 The Enumerated Tag is composed of one or more non-negative integers. 1247 Each non-negative integer represents a non-hierarchical security 1248 attribute that applies to the labeled content. Use of the integer 1249 representation is intended to minimize the size of the label since a 1250 particular key package generally contains only a few security 1251 categories attributes, even though a security policy might define a 1252 large set of security categories attributes. Security attributes 1253 enumerated by tags of this type could be restrictive (such as 1254 compartments) or permissive (such as release permissions). Two 1255 object identifiers for the SecurityCategory type field have been 1256 defined, one restrictive and one for permissive. The object 1257 identifiers are: 1259 id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= { 1260 2 16 840 1 101 2 1 8 3 4 } 1262 id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= { 1263 2 16 840 1 101 2 1 8 3 1 } 1265 ID NSA's CMS Key Management Attributes June 4, 2013 1267 With both the restrictive and permissive security category types, the 1268 corresponding SecurityCategory value has the following ASN.1 1269 definition: 1271 EnumeratedTag ::= SEQUENCE { 1272 tagName OBJECT IDENTIFIER, 1273 attributeList SET OF SecurityAttribute } 1275 SecurityAttribute ::= INTEGER (0..MAX) 1277 Any security policy that makes use of security categories MUST assign 1278 object identifiers for each tagName, assign the set of integer values 1279 associated with each tagName, and specify the semantic meaning for 1280 each integer value. Restrictive security attributes and permissive 1281 security attributes SHOULD be associated with different tagName 1282 object identifiers. 1284 The Informative Tag is composed of either one or more non-negative 1285 integers or a bit string. Only the integer choice is allowed in this 1286 specification. Each non-negative integer represents a non- 1287 hierarchical security attribute that applies to the labeled content. 1288 Use of the integer representation is intended to minimize the size of 1289 the label since a particular key package generally contains only a 1290 few security categories attributes, even though a security policy 1291 might define a large set of security categories attributes. Security 1292 attributes enumerated by tags of this type are informative (i.e., no 1293 access control is performed). One object identifier for the 1294 SecurityCategory type field has been defined and it is as follows: 1296 id-informativeAttributes OBJECT IDENTIFIER ::= { 1297 2 16 840 1 101 2 1 8 3 3 } 1299 The corresponding SecurityCategory value has the following ASN.1 1300 definition: 1302 InformativeTag ::= SEQUENCE { 1303 tagName OBJECT IDENTIFIER, 1304 attributes FreeFormField } 1306 FreeFormField ::= CHOICE { 1307 bitSetAttributes BIT STRING, 1308 securityAttributes SET OF SecurityAttribute } 1310 Any security policy that makes use of security categories MUST assign 1311 object identifiers for each tagName, assign the set of integer values 1312 associated with each tagName, and specify the semantic meaning for 1313 each integer value. 1315 ID NSA's CMS Key Management Attributes June 4, 2013 1317 17. Split Key Identifier 1319 The key package originator may include a split-identifier attribute 1320 to designate that the keying material contains a split rather than a 1321 complete key. It may appear as a symmetric and asymmetric key 1322 attribute. The split-identifier attribute MUST NOT appear as a 1323 symmetric key package, signed, authenticated, 1324 authenticated/unprotected, or content attribute. Split keys have two 1325 halves, which are called "A" and "B." The split-identifier attribute 1326 indicates which half is included in the key package, and it 1327 optionally indicates the algorithm that is needed to combine the two 1328 halves. The combine algorithm is OPTIONAL since each key algorithm 1329 has a default mechanism for this purpose, and the combine algorithm 1330 is present only if the default mechanism is not employed. 1332 The key-split-identifier attribute has the following syntax: 1334 aa-splitIdentifier ATTRIBUTE ::= { 1335 TYPE SplitID 1336 IDENTIFIED BY id-kma-splitID } 1338 id-kma-splitID OBJECT IDENTIFIER ::= { 1339 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1340 dod(2) infosec(1) keying-material-attributes(13) 11 } 1342 SplitID ::= SEQUENCE { 1343 ENUMERATED { a(0), b(1) }, 1344 combineAlg AlgorithmIdentifier 1345 {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL } 1347 In most cases the default combine algorithm will be employed, which 1348 makes this attribute a simple constant that identifies either the "A" 1349 or "B" half of the split key, which supports implementation of some 1350 key distribution policies. 1352 Note that each split might have its own CRC, but the key and the 1353 check word are both recovered when the two splits are combined. 1355 Since the split-identifier attribute MUST NOT appear as a signed, 1356 authenticated, or content attribute, a key package cannot include 1357 multiple occurrences of the split-identifier attribute within the 1358 same scope. Receivers MUST reject any key package in which the 1359 split-identifier attribute appears as a signed, authenticated, or 1360 content attribute. 1362 18. Key Package Type 1364 The key-package-type attribute is a shorthand method for specifying 1366 ID NSA's CMS Key Management Attributes June 4, 2013 1368 all aspects of the key package format, including which attributes are 1369 present and the structure of the encapsulated content. The key- 1370 package-type attribute can be used as a signed, authenticated, 1371 authenticated/unprotected, or content attribute. If a key-package- 1372 type attribute appears in a content attribute associated with a 1373 collection, it is a shorthand method for specifying all aspects of 1374 the key packages that comprise the collection. 1376 Rather than implementing the full flexibility of this specification, 1377 some devices may implement support for one or more specific key 1378 package formats instantiating this specification. Those specific 1379 formats are called templates and can be identified using a key- 1380 package-type attribute. 1382 The key-package-type attribute has the following syntax: 1384 aa-keyPackageType ATTRIBUTE ::= { 1385 TYPE KeyPkgType 1386 IDENTIFIED BY id-kma-keyPkgType } 1388 id-kma-keyPkgType OBJECT IDENTIFIER ::= { 1389 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1390 dod(2) infosec(1) keying-material-attributes(13) 12 } 1392 KeyPkgType ::= OBJECT IDENTIFIER 1394 Due to multiple layers of encapsulation or the use of content 1395 collections, the key-package-type attribute can appear in more than 1396 one location in the overall key package. When there are multiple 1397 occurrences of the key-package-type attribute, each occurrence is 1398 used independently. Since the receiver is likely to use the key- 1399 package-type attribute value as a decoding aid, any error will most 1400 likely lead to parsing problems, and these problems could result in 1401 many different errors being reported. 1403 19. Signature Usage 1405 The signature-usage attribute provides the intended usage for a 1406 signature key. Symmetric key packages do not contain signature 1407 generation or signature validation keying material, so the signature- 1408 usage attribute MUST NOT appear in a symmetric key package. For an 1409 asymmetric key package, the signature-usage attribute indicates the 1410 kind of objects that are to be signed with the private key in the 1411 package. However, if the asymmetric key package contains a 1412 Certificate Signature Key, then the signature-usage attribute also 1413 indicates what signed objects can be validated using certificates 1414 that are signed by the private key in the asymmetric key package. 1415 Therefore, the signature-usage attribute also indicates what kind of 1417 ID NSA's CMS Key Management Attributes June 4, 2013 1419 objects that can be signed by the private keys associated with these 1420 certificates. The signature-usage attribute MUST NOT appear as a 1421 signed, authenticated, authenticated/unprotected, or content 1422 attribute. 1424 The signature-usage attribute has the following syntax: 1426 aa-signatureUsage-v3 ATTRIBUTE ::= { 1427 TYPE SignatureUsage 1428 IDENTIFIED BY id-kma-sigUsageV3 } 1430 id-kma-sigUsageV3 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) 22 } 1434 SignatureUsage ::= CMSContentConstraints 1436 The SignatureUsage structure has the same syntax as the 1437 CMSContentConstraints structure in [RFC6010], and it is repeated here 1438 for convenience. 1440 CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF 1441 ContentTypeConstraint 1443 ContentTypeConstraint ::= SEQUENCE { 1444 contentType CONTENT-TYPE.&id ({ContentSet|ct-Any,...}), 1445 canSource ContentTypeGeneration DEFAULT canSource, 1446 attrConstraints AttrConstraintList OPTIONAL } 1448 Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE { 1449 attrType ATTRIBUTE.&id({ConstraintList}), 1450 attrValues SET SIZE (1..MAX) OF ATTRIBUTE. 1451 &Type({ConstraintList}{@attrType}) } 1453 SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... } 1455 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF 1456 Constraint {{ SupportedConstraints }} 1458 The SignatureUsage contains a type of CMSContentConstraints. One or 1459 more ContentTypeConstrin MUST appear in CMSContentConstraint. 1461 Within ContentTypeConstraint, the contentType field indicates the 1462 encapsulated content type identifier that can be signed with the 1463 signature key. A particular content type MUST NOT appear more than 1464 once in the list. The CMS protecting content types need not be 1465 included in the list of permitted content types as the use of CMS is 1466 always authorized (see [RFC6010]). 1468 ID NSA's CMS Key Management Attributes June 4, 2013 1470 Within ContentTypeConstraint, the canSource enumeration indicates 1471 whether the signature key can be used to directly sign the indicated 1472 content type. If the ContentTypeConstraint is canSource (the default 1473 value), then the signature key can be used to directly sign the 1474 specified content type. If the ContentTypeConstraint is 1475 cannotSource, then the signature key can only be used with the 1476 specified content type if it encapsulates a signature that was 1477 generated by an originator with a ContentTypeConstraint that is 1478 canSource. 1480 Within ContentTypeList, the attrConstraints OPTIONAL field contains a 1481 sequence of content type specific constraints. If the 1482 attrConstraints field is absent, the signature key can be used to 1483 sign the specified content type, without any further checking. If 1484 the either the attrConstraints field is present, then the signature 1485 key can only be used to sign the specified content type if all of the 1486 constraints for that content type are satisfied. Content type 1487 constraints are checked by matching the attribute values in the 1488 attrConstraint field against the attribute value in the content. The 1489 constraints succeed if the attribute is not present; they fail if the 1490 attribute is present and the value is not one of the values provided 1491 in attrConstraint. 1493 The fields of attrConstraints implement content type-specific 1494 constraints. The attrType field is an AttributeType, which is an 1495 object identifier of a signed attribute carried in the SignerInfo of 1496 the content. The attrValues field provides one or more acceptable 1497 signed attribute values. It is a set of AttributeValue. For a 1498 signed content to satisfy the constraint, the SignerInfo MUST include 1499 a signed attribute of the type identified in the attrType field, and 1500 the signed attribute MUST contain one of the values in the set 1501 carried in attrValues. 1503 Since the signature-usage attribute MUST NOT appear as a signed, 1504 authenticated, or content attribute, an asymmetric key package cannot 1505 include multiple occurrences of the signature-usage attribute within 1506 the same scope. Receivers MUST reject any asymmetric key package in 1507 which the signature-usage attribute appears as a signed, 1508 authenticated, or content attribute. 1510 20. Other Certificate Format 1512 The other-certificate-formats attribute specifies the type, format, 1513 and value of certificates that are not X.509 public key certificates. 1514 Symmetric key packages do not contain any certificates, so the 1515 other-certificate-formats attribute MUST NOT appear in a symmetric 1516 key package. It SHOULD appear in the attributes field, when the 1517 publicKey field is absent and the certificate format is not X.509. 1519 ID NSA's CMS Key Management Attributes June 4, 2013 1521 This attribute MUST NOT appear in an attributes field that includes 1522 the user-certificate attribute. The other-certificate-formats 1523 attribute MUST NOT appear as a signed, authenticated, 1524 authenticated/unprotected, or content attribute. 1526 The other-certificate-formats attribute has the following syntax: 1528 aa-otherCertificateFormats ATTRIBUTE ::= { 1529 TYPE CertificateChoices 1530 IDENTIFIED BY id-kma-otherCertFormats } 1532 id-kma-otherCertFormats OBJECT IDENTIFIER ::= { 1533 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1534 dod(2) infosec(1) keying-material-attributes(13) 19 } 1536 CertificateChoices ::= CHOICE { 1537 certificate Certificate, 1538 extendedCertificate [0] IMPLICIT ExtendedCertificate, 1539 -- Obsolete 1540 v1AttrCert [1] IMPLICIT AttributeCertificateV1, 1541 -- Obsolete 1542 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 1543 other [3] IMPLICIT OtherCertificateFormat } 1545 OtherCertificateFormat ::= SEQUENCE { 1546 otherCertFormat OBJECT IDENTIFIER, 1547 otherCert ANY DEFINED BY otherCertFormat } 1549 The other-certificate-formats attribute makes use of the 1550 CertificateChoices field defined in Section 10.2.2 of [RFC5652]. The 1551 certificate, extendedCertificate, and v1AttrCert fields MUST be 1552 omitted. The v2AttrCert field can include Version 2 Attribute 1553 Certificates. The other field can include EFF certificates and other 1554 as-yet undefined certificate formats. 1556 Since the other-certificate-formats attribute MUST NOT appear as a 1557 signed, authenticated, or content attribute, an asymmetric key 1558 package cannot include multiple occurrences of the other-certificate- 1559 formats attribute within the same scope. Receivers MUST reject any 1560 asymmetric key package in which the other-certificate-formats 1561 attribute appears as a signed, authenticated, or content attribute. 1563 21. PKI Path 1565 The pki-path attribute includes certificates that can aid in the 1566 validation of the certificate carried in the user-certificate 1567 attribute. Symmetric key packages do not contain any certificates, 1568 so the pkiPath attribute MUST NOT appear in a symmetric key package. 1570 ID NSA's CMS Key Management Attributes June 4, 2013 1572 It can appear as an asymmetric key, signed, authenticated, 1573 authenticated/unprotected, or content attribute. It can appear in 1574 the attributes field, when the publicKey field is absent and the 1575 certificate format is X.509. This attribute MUST NOT appear in an 1576 AsymmetricKeyPackage that has an other-certificate-formats attribute 1577 in the attributes field. If the pki-path attribute appears as a 1578 signed, authenticated, authenticated/unprotected, or content 1579 attribute, then the value includes certificates that can be used to 1580 construct certification path to all of the keying material within the 1581 content. This attribute MUST be supported. 1583 The syntax is taken from [X.509] but redefined using the ATTRIBUTE 1584 CLASS from [RFC5911] The pki-path attribute has the following syntax: 1586 aa-pkiPath ATTRIBUTE ::= { 1587 TYPE PkiPath 1588 IDENTIFIED BY id-at-pkiPath } 1590 id-at-pkiPath OBJECT IDENTIFIER ::= { 1591 joint-iso-itu-t(2) ds(5) attributes(4) 70 } 1593 PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate 1595 The first certificate in the sequence is the subject's parent CA. 1596 The next certificate is that CA's parent, and so on. The end-entity 1597 and Trust Anchor are not included in this attribute. 1599 Due to multiple layers of encapsulation or the use of content 1600 collections, the pki-path attribute can appear in more than one 1601 location in the overall key package. When the pki-path attribute 1602 appears in more than one location in the overall key package, each 1603 occurrence is evaluated independently. 1605 22. Useful Certificates 1607 The useful-certificates attribute includes certificates that can aid 1608 in the validation of certificates associated with other parties with 1609 whom secure communications are anticipated. It can appear as an 1610 asymmetric key, signed, authenticated, authenticated/unprotected, or 1611 content attribute. This attribute MUST NOT appear in an asymmetric 1612 key package that has an other-certificate-formats attribute in the 1613 attributes field. If the useful-certificates attribute appears as a 1614 signed, authenticated, authenticated/unprotected, or content 1615 attribute, then the value includes certificates that may be used to 1616 validate certificate of others the receiver communicates with. This 1617 attribute MUST be supported. 1619 The useful-certificates attribute has the following syntax: 1621 ID NSA's CMS Key Management Attributes June 4, 2013 1623 aa-usefulCertificates ATTRIBUTE ::= { 1624 TYPE CertificateSet 1625 IDENTIFIED BY id-kma-usefulCerts } 1627 id-kma-usefulCerts OBJECT IDENTIFIER ::= { 1628 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1629 dod(2) infosec(1) keying-material-attributes(13) 20 } 1631 CertificateSet ::= SET OF CertificateChoices 1633 The useful-certificates attribute makes use of the CertificateSet 1634 field defined in Section 10.2.3 of [RFC5652]. Within the 1635 CertificateChoices field, the extendedCertificate and v1AttrCert 1636 fields MUST always be omitted. If the userCertificate attribute is 1637 included, the other field MUST NOT be present. If the other- 1638 certificate-formats attribute is included, the certificate field MUST 1639 NOT be present. 1641 Due to multiple layers of encapsulation or the use of content 1642 collections, the useful-certificates attribute can appear in more 1643 than one location in the overall key package. When the useful- 1644 certificates attribute appears in more than one location in the 1645 overall key package, each occurrence is evaluated independently. 1647 23. Key Wrap Algorithm 1649 The key-wrap-algorithm attribute identifies a key wrap algorithm with 1650 an algorithm identifier. It can appear as a symmetric key or 1651 symmetric key package attribute. When this attribute is present in 1652 sKeyAttrs, it indicates that the associated sKey field contains a 1653 black key that was wrapped by the identified algorithm. When this 1654 attribute is present in sKeyPkgAttrs, it indicates that every sKey 1655 field in that symmetric key package contains a black key, and that 1656 all keys are wrapped by the same designated algorithm. 1658 The key-wrap-algorithm attribute has the following syntax: 1660 aa-keyWrapAlgorithm ATTRIBUTE ::= { 1661 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}} 1662 IDENTIFIED BY id-kma-keyWrapAlgorithm } 1664 id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= { 1665 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1666 dod(2) infosec(1) keying-material-attributes(13) 21 } 1668 KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... } 1670 24. Content Decryption Key Identifier 1671 ID NSA's CMS Key Management Attributes June 4, 2013 1673 The content-decryption-key-identifier attribute can appear as an 1674 unprotected and unauthenticated attribute as well as a symmetric and 1675 symmetric key package attribute. The attribute's semantics differ 1676 based on the location. 1678 24.1. Content Decryption Key Identifier: Symmetric Key and Symmetric Key 1679 Package 1681 The content-decryption-key-identifier attribute identifies the keying 1682 material needed to decrypt the sKey. It can appear as a symmetric 1683 key and symmetric key package attribute. If the key-wrap-algorithm 1684 attribute appears in sKeyPkgAttrs, then the corresponding content- 1685 decryption-identifier attribute can appear in either sKeyPkgAttrs or 1686 sKeyAttrs. If the key-wrap-algorithm attribute appears in sKeyAttrs, 1687 then the corresponding content-decryption-identifier attribute MUST 1688 appear in sKeyAttrs. 1690 The content-decryption-key-identifier attribute has the following 1691 syntax: 1693 aa-contentDecryptKeyIdentifier ATTRIBUTE ::= { 1694 TYPE ContentDecryptKeyID 1695 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 1697 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= { 1698 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1699 dod(2) infosec(1) attributes(5) 66 } 1701 ContentDecryptKeyID ::= OCTET STRING 1703 The content decryption key identifier contains an octet string, and 1704 this syntax does not impose any particular structure on the 1705 identifier value. 1707 24.2. Content Decryption Key Identifier: Unprotected 1709 The content-decryption-key-identifier attribute can be used to 1710 identify the keying material that is needed for decryption of the 1711 EncryptedData content if there is any ambiguity. 1713 The content-decryption-key-identifier attribute syntax is found in 1714 Section 25.1. The content decryption key identifier contains an octet 1715 string, and this syntax does not impose any particular structure on 1716 the identifier value. 1718 Due to multiple layers of encryption, the content-decryption-key- 1719 identifier attribute can appear in more than one location in the 1720 overall key package. When there are multiple occurrences of the 1722 ID NSA's CMS Key Management Attributes June 4, 2013 1724 content-decryption-key-identifier attribute, each occurrence is 1725 evaluated independently. Each one is used to identify the needed 1726 keying material for that layer of encryption. 1728 25. Certificate Pointers 1730 The certificate-pointers attribute can be used to reference one or 1731 more certificates that may be helpful in the processing of the 1732 content once it is decrypted. Sometimes certificates are omitted if 1733 they can be easily fetched. However, an intermediary may have better 1734 facilities to perform the fetching than the receiver. The 1735 certificate-pointers attribute may be useful in some environments. 1736 This attribute can appear as an unprotected and an 1737 unauthenticated/unprotected attribute. 1739 The certificate-pointers attribute uses the same syntax and semantics 1740 as the subject information access certificate extension [RFC5280]. 1741 The certificate-pointers attribute has the following syntax: 1743 aa-certificatePointers ATTRIBUTE ::= { 1744 TYPE SubjectInfoAccessSyntax 1745 IDENTIFIED BY id-pe-subjectInfoAccess } 1747 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { 1748 iso(1) identified-organization(3) dod(6) internet(1) 1749 security(5) mechanisms(5) pkix(7) pe(1) 11 } 1751 SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF 1752 AccessDescription 1754 AccessDescription ::= SEQUENCE { 1755 accessMethod OBJECT IDENTIFIER, 1756 accessLocation GeneralName } 1758 As specified in [RFC5280], the id-ad-caRepository access method can 1759 be used to point to a repository where a Certification Authority 1760 publishes certificates and CRLs. In this case, the accessLocation 1761 field tells how to access the repository. Where the information is 1762 available via http, ftp, or ldap, accessLocation contains a uniform 1763 resource identifier (URI). Where the information is available via 1764 the directory access protocol (dap), accessLocation contains a 1765 directory name. 1767 26. CRL Pointers 1769 The CRL-pointers attribute can be used to reference one or more 1770 certificate revocation lists (CRLs) that may be helpful in the 1771 processing of the content once it is decrypted. Sometimes CRLs are 1773 ID NSA's CMS Key Management Attributes June 4, 2013 1775 omitted to conserve space or to ensure that the most recent CRL is 1776 obtained when the certificate is validated. However, an intermediary 1777 may have better facilities to perform the fetching than the receiver. 1778 The CRL-pointers attribute may be useful in some environments. This 1779 attribute can appear as an unprotected and 1780 unauthenticated/unprotected attribute. 1782 The CRL-pointers attribute has the following syntax: 1784 aa-crlPointers ATTRIBUTE ::= { 1785 TYPE GeneralNames 1786 IDENTIFIED BY id-aa-KP-crlPointers } 1788 id-aa-KP-crlPointers OBJECT IDENTIFIER ::= { 1789 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1790 dod(2) infosec(1) attributes(5) 70 } 1792 The CRL-pointers attribute uses the GeneralNames syntax from 1793 [RFC5280]. Each name describes a different mechanism to obtain the 1794 same CRL. Where the information is available via http, ftp, or ldap, 1795 GeneralNames contains a uniform resource identifier (URI). Where the 1796 information is available via the directory access protocol (dap), 1797 GeneralNames contains a directory name. 1799 27. Key Package Identifier and Receipt Request 1801 The Key Package Identifier and Receipt Request attribute from 1802 [ID.housley-keypackage-receipt-n-error] is also supported. It can 1803 appear as a signed attribute, authenticated, 1804 authenticated/unprotected, or content attribute. 1806 28. Additional Error Codes 1808 This specification also defines four additional extendedErrorCodes 1809 [ID.housley-keypackage-receipt-n-error]: 1811 id-errorCodes OBJECT IDENTIFIER ::= { 1812 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1813 dod(2) infosec(1) errorCodes(22) } 1815 id-missingKeyType OBJECT IDENTIFIER ::= { 1816 id-errorCodes 1 } 1818 id-privacyMarkTooLong OBJECT IDENTIFIER ::= { 1819 id-errorCodes 2 } 1821 id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= { 1822 id-errorCodes 3 } 1824 ID NSA's CMS Key Management Attributes June 4, 2013 1826 missingKeyType indicates that all keying material within a package is 1827 of the same type; however, the key type attribute is not specified in 1828 sKeyPkgAttrs [RFC6031]. 1830 privacyMarkTooLong indicates that a classification attribute includes 1831 a privacy mark that exceeds 128 characters in length. 1833 unrecognizedSecurityPolicy indicates that a security-policy- 1834 identifier is not supported. 1836 29. Processing Key Package Attribute Values and CMS Content Constraints 1838 Trust anchors may contain constraints for any content type [RFC5934]. 1839 When the trust anchor contains constraints for the symmetric key 1840 package content type or the asymmetric key package content type, then 1841 the constraints provide default values for key package attributes 1842 that are not present in the key package and define the set of 1843 acceptable values for key package attributes that are present. 1845 When a trust anchor delegates authority by issuing an X.509 1846 certificate, the CMS content constraints certificate extension 1847 [RFC6010] may be included to constrain the authorizations. The trust 1848 anchor and the X.509 certification path provide default values for 1849 key package attributes that are not present in the key package and 1850 define the set of acceptable of values for key package attributes 1851 that are present. 1853 Constraints on content type usage are represented as attributes. 1855 The processing procedures for the CMS content constraints certificate 1856 extension [RFC6010] are part of the validation of a signed or 1857 authenticated object, and the procedures yield three output values: 1858 cms_constraints, cms_effective_attributes, and 1859 cms_default_attributes. Object validation MUST be performed before 1860 processing the key package contents, and these outputs values are 1861 used as part of key package processing. These same output values are 1862 easily generated directly from a trust anchor and the key package 1863 when no X.509 certification path is involved in validation. 1865 The cms_effective_attributes provides the set of acceptable values 1866 for attributes. Each attribute present in the key package that 1867 corresponds to an entry in cms_effective_attributes MUST contain a 1868 value that appears in cms_effective_attributes entry. Attributes 1869 that do not correspond to an entry in cms_effective_attributes are 1870 unconstrained and may contain any value. Correspondence between 1871 attributes and cms_effiective_attributes is determined by comparing 1872 the attribute object identifier to object identifier for each entry 1873 in cms_effective_attributes. 1875 ID NSA's CMS Key Management Attributes June 4, 2013 1877 The cms_default_attributes provides values for attributes that do not 1878 appear in the key package. If cms_default_attributes includes only 1879 one attribute value for a particular attribute, then that value is 1880 used as if it were included in the key package itself. However, if 1881 cms_default_attributes includes more than one value for a particular 1882 attribute, then the appropriate value remains ambiguous and the key 1883 package should be rejected. 1885 Some attributes can appear in more than one place in the key package, 1886 and for this reason, the attribute definitions include consistency 1887 checks. These checks are independent of constraints checking. In 1888 addition to the consistency checks, each instance of the attribute 1889 MUST be checked against the set of cms_effective_attributes, and the 1890 key package MUST be rejected if any of the attributes values are not 1891 in the set of authorized set of values. 1893 30. Attribute Scope 1895 This section provides an example symmetric key package in order to 1896 provide a discussion of the scope of attributes. This is an 1897 informative section; it is not a normative portion of this 1898 specification. Figure 1 provides the example. All of the concepts 1899 apply to either a symmetric key package or an asymmetric key package, 1900 with the exception of the key-algorithm attribute which is only 1901 applicable to a symmetric key pacakge. Each of the components is 1902 labeled with a number inside parentheses for easy reference: 1904 o (1) is the ContentInfo that must be present as the outermost 1905 layer of encapsulation. It contains no attributes. It is shown 1906 for completeness. 1908 o (2) is a SignedData content type, which includes six signed 1909 attributes. Four of the signed attributes are keying material 1910 attributes. 1912 o (3) is a ContentCollection that includes two encapsulated content 1913 types: a ContentWithAttributes and an EncryptedKeyPackage. This 1914 content type does not provide any attributes. 1916 o (4) is a ContentWithAttributes content type. It encapsulates a 1917 SignedData content type. Four key material attributes are 1918 provided. 1920 o (5) is a SignedData content type. It encapsulates a 1921 SymmetricKeyPackage content type. Six signed attributes are 1922 provided. Four attributes are key material attributes. 1924 o (6) is a SymmetricKeyPackage content type, and it includes three 1926 ID NSA's CMS Key Management Attributes June 4, 2013 1928 key material attributes. Note that the contents of this key 1929 package are not encrypted, but the contents are covered by two 1930 digital signatures. 1932 o (7) is an EncryptedKeyPackage content type. It encapsulates a 1933 SignedData content type. This content type provides one 1934 unprotected attribute. 1936 o (8) is a SignedData content type. It encapsulates a 1937 SymmetricKeyPackage content type. Six signed attributes are 1938 provided. Four attributes are key material attributes. 1940 o (9) is a SymmetricKeyPackage content type, and it includes three 1941 key material attributes. Note that the contents of this key 1942 package are encrypted, and the plaintext keying material is 1943 covered by one digital signature, and the ciphertext keying 1944 material is covered by another digital signature. 1946 SignedData content type (2) includes six signed attributes: 1948 o The content-type attribute contains id-ct-contentCollection to 1949 indicate the type of the encapsulated content, and it has no 1950 further scope. 1952 o The message-digest attribute contains the one-way hash value of 1953 the encapsulated content; it is needed to validate the digital 1954 signature. It has no further scope. 1956 o The classification attribute contains security label for all of 1957 the plaintext in the encapsulated content. Each classification 1958 attribute is evaluated separately; it has no further scope. In 1959 general, the values of this attribute will match or dominate the 1960 security label values in (4), (5), and (6). The value of this 1961 attribute might not match or dominate the security label values 1962 in (8) and (9) since they are encrypted. It is possible that 1963 these various security label values are associated with different 1964 security policies. Comparison is not required in order to avoid 1965 the processing complexity associated with policy mapping. 1967 o The key-package-receivers-v2 attribute indicates the authorized 1968 key package receivers, and it has no further scope. The key- 1969 package-receivers-v2 attribute value within (4) is evaluated 1970 without regard to the value of this attribute. 1972 o The key-distribution-period attribute contains two date values: 1973 doNotDistBefore and doNotDistAfter. These values must match all 1974 others within the same scope, which in this example is the key- 1975 distribution-period within (4). 1977 ID NSA's CMS Key Management Attributes June 4, 2013 1979 o The key-package-type attributes indicates the format of the key 1980 package, and it has no further scope. The key-package-type 1981 attributes values within (5) and (8) are evaluated without regard 1982 to the value of this attribute. 1984 ContentWithAttributes content type (4) includes four attributes: 1986 o The classification attribute contains security label for all of 1987 the plaintext in the encapsulated content. Each classification 1988 attribute is evaluated separately; it has no further scope. 1990 o The TSEC-Nomenclature attribute includes only the shortTitle 1991 field, and the value must match all other instances within the 1992 same scope, which appear in (5) and (6). Note that the TSEC- 1993 Nomenclature attribute values in (8) and (9) are not in the same 1994 scope as the TSEC-Nomenclature attribute that appears in (4). 1996 o The key-package-receivers-v2 attribute indicates the authorized 1997 key package receivers, and it has no further scope. The key- 1998 package-receivers-v2 attribute value within (2) is evaluated 1999 without regard to the value of this attribute. 2001 o The key-distribution-period attribute contains two date values: 2002 doNotDistBefore and doNotDistAfter. These values must match all 2003 others within the same scope, which in this example is the key- 2004 distribution-period within (2). 2006 SignedData content type (5) includes six signed attributes: 2008 o The content-type attribute contains id-ct-KP-skeyPackage to 2009 indicate the type of the encapsulated content, and it has no 2010 further scope. 2012 o The message-digest attribute contains the one-way hash value of 2013 the encapsulated content; it is needed to validate the digital 2014 signature. It has no further scope. 2016 o The classification attribute contains security label for all of 2017 the plaintext in the encapsulated content. Each classification 2018 attribute is evaluated separately; it has no further scope. 2020 o The TSEC-Nomenclature attribute includes only the shortTitle 2021 field, and the value must match all other instances within the 2022 same scope, which appear in (6). Since this is within the scope 2023 of (4), these shortTitle field values must match as well. Note 2024 that the TSEC-Nomenclature attribute values in (8) and (9) are 2025 not in the same scope. 2027 ID NSA's CMS Key Management Attributes June 4, 2013 2029 o The key-purpose attribute specifies the purpose of the key 2030 material. All occurrences within the scope must have the same 2031 value, but in this example, there are no other occurrences within 2032 the scope. The key-purpose attribute value within (8) is 2033 evaluated without regard to the value of this value. 2035 o The key-package-type attribute indicates the format of the key 2036 package, and it has no further scope. The key-package-type 2037 attribute values within (2) and (8) are evaluated without regard 2038 to the value of this attribute. 2040 SymmetricKeyPackage content type (6) includes three keying material 2041 attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs 2042 fields: 2044 o The key-algorithm attribute includes only the keyAlg field, and 2045 it must match all other occurrences within the same scope. 2046 However, there are no other key-algorithm attribute occurrences 2047 in the same scope; the key-algorithm attribute value in (9) is 2048 not in the same scope. 2050 o The classification attribute contains security label for all of 2051 the plaintext in the key package. Each classification attribute 2052 is evaluated separately; it has no further scope. 2054 o The TSEC-Nomenclature attribute includes the shortTitle field as 2055 well as some of the optional fields. The shortTitle field value 2056 must match the values in (4) and (5), since this content type is 2057 within their scope. Note that the TSEC-Nomenclature attribute 2058 values in (8) and (9) are not in the same scope. 2060 EncryptedKeyPackage content type (7) includes one unprotected 2061 attribute, and the encryption will prevent any intermediary that does 2062 not have the ability to decrypt the content from making any 2063 consistency checks on (8) and (9): 2065 o The content-decryption-key-identifier attribute identifies the 2066 key that is needed to decrypt the encapsulated content; it has no 2067 further scope. 2069 SignedData content type (8) includes six signed attributes: 2071 o The content-type attribute contains id-ct-KP-skeyPackage to 2072 indicate the type of the encapsulated content, and it has no 2073 further scope. 2075 o The message-digest attribute contains the one-way hash value of 2076 the encapsulated content; it is needed to validate the digital 2078 ID NSA's CMS Key Management Attributes June 4, 2013 2080 signature. It has no further scope. 2082 o The classification attribute contains security label for content. 2083 Each classification attribute is evaluated separately; it has no 2084 further scope. 2086 o The TSEC-Nomenclature attribute includes only the shortTitle 2087 field, and the value must match all other instances within the 2088 same scope, which appear in (9). Note that the TSEC-Nomenclature 2089 attribute values in (4), (5), and (6) are not in the same scope. 2091 o The key-purpose attribute specifies the purpose of the key 2092 material. All occurrences within the scope must have the same 2093 value, but in this example, there are no other occurrences within 2094 the scope. The key-purpose attribute value within (5) is 2095 evaluated without regard to the value of this attribute. 2097 o The key-package-type attribute indicates the format of the key 2098 package, and it has no further scope. The key-package-type 2099 attribute values within (2) and (5) are evaluated without regard 2100 to the value of this attribute. 2102 SymmetricKeyPackage content type (9) includes three keying material 2103 attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs 2104 fields: 2106 o The key-algorithm attribute includes only the keyAlg field, and 2107 it must match all other occurrences within the same scope. 2108 However, there are no other key-algorithm attribute occurrences 2109 in the same scope; the key-algorithm attribute value in (6) is 2110 not in the same scope. 2112 o The classification attribute contains security label for all of 2113 the plaintext in the key package. Each classification attribute 2114 is evaluated separately; it has no further scope. 2116 o The TSEC-Nomenclature attribute includes the shortTitle field as 2117 well as some of the optional fields. The shortTitle field value 2118 must match the values in (8), since this content type is within 2119 its scope. Note that the TSEC-Nomenclature attributes values in 2120 (4), (5), and (6) are not in the same scope. 2122 In summary, the scope of an attribute includes the encapsulated 2123 content of the CMS content type in which it appears, and some 2124 attributes also require consistency checks with other instances that 2125 appear within the encapsulated content. Proper recognition of scope 2126 is required to accurately perform attribute processing. 2128 ID NSA's CMS Key Management Attributes June 4, 2013 2130 +------------------------------------------------------------------+ 2131 | ContentInfo (1) | 2132 |+----------------------------------------------------------------+| 2133 || SignedData (2) || 2134 ||+--------------------------------------------------------------+|| 2135 ||| ContentCollection (3) ||| 2136 |||+-----------------------------++-----------------------------+||| 2137 |||| ContentWtihAttributes (4) || EncryptedKeyPackage (7) |||| 2138 ||||+---------------------------+||+---------------------------+|||| 2139 ||||| SignedData (5) |||| SignedData (8) ||||| 2140 |||||+-------------------------+||||+-------------------------+||||| 2141 |||||| SymmetricKeyPackage (6) |||||| SymmetricKeyPacakge (9) |||||| 2142 |||||| Attributes: |||||| Attributes: |||||| 2143 |||||| Key Algorithm |||||| Key Algorithm |||||| 2144 |||||| Classification |||||| Classification |||||| 2145 |||||| TSEC-Nomenclature |||||| TSEC-Nomenclature |||||| 2146 |||||+-------------------------+||||+-------------------------+||||| 2147 ||||| Attributes: |||| Attributes: ||||| 2148 ||||| Content Type |||| Content Type ||||| 2149 ||||| Message Digest |||| Message Digest ||||| 2150 ||||| Classification |||| Classification ||||| 2151 ||||| TSEC-Nomenclature |||| TSEC-Nomenclature ||||| 2152 ||||| Key Purpose |||| Key Purpose ||||| 2153 ||||| Key Package Type |||| Key Package Type ||||| 2154 ||||+-------------------------- +||+---------------------------+|||| 2155 |||| Attributes: || Unprotect Attributes: |||| 2156 |||| Classification || Content Decrypt Key ID |||| 2157 |||| TSEC-Nomenclature |+-----------------------------+||| 2158 |||| Key Package Receivers | ||| 2159 |||| Key Distribution Period | ||| 2160 |||+-----------------------------+ ||| 2161 ||+--------------------------------------------------------------+|| 2162 || Attributes: || 2163 || Content Type || 2164 || Message Digest || 2165 || Classification || 2166 || Key Package Receivers || 2167 || Key Distribution Period || 2168 || Key Package Type || 2169 |+----------------------------------------------------------------+| 2170 +------------------------------------------------------------------+ 2172 Figure 1: Example Illustrating Scope of Attributes 2174 31. Security Considerations 2176 The majority of this specification is devoted to the syntax and 2178 ID NSA's CMS Key Management Attributes June 4, 2013 2180 semantics of key package attributes. It relies on other 2181 specifications, especially [RFC2634] [RF4073] [RFC4108] [RFC5652] 2182 [RFC5911] [RFC5912] [RFC5958] [RFC6010] [RFC6031]; their security 2183 considerations apply here. Additionally, cryptographic algorithms 2184 are used with CMS protecting content types [RFC5959] [RFC6160] 2185 [RFC6162]; their security considerations apply here as well. 2187 This specification also relies upon [RFC5280] for the syntax and 2188 semantics of X.509 certificates. Digital signatures provide data 2189 integrity or data origin authentication, and encryption provides 2190 confidentiality. 2192 Security factors outside the scope of this specification greatly 2193 affect the assurance provided. The procedures used by Certification 2194 Authorities (CAs) to validate the binding of the subject identity to 2195 their public key greatly affect the assurance that ought to be placed 2196 in the certificate. This is particularly important when issuing 2197 certificates to other CAs. 2199 The CMS AuthenticatedData content type MUST be used with care since a 2200 message authentication code (MAC) is used. The same key is needed to 2201 generate the MAC or validate the MAC. Thus, any party with access to 2202 the key needed to validate the MAC can generate a replacement that 2203 will be acceptable to other recipients. 2205 32. IANA Considerations 2207 None. 2209 33. References 2211 33.1 Normative References 2213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2214 Requirement Levels", BCP 14, RFC 2119, March 1997. 2216 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 2217 RFC 2634, June 1999. 2219 [RFC4073] Housley, R., "Protecting Multiple Contents with the 2220 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 2222 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 2223 Protect Firmware Packages", RFC 4108, August 2005. 2225 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2226 Housley, R., and W. Polk, "Internet X.509 Public Key 2227 Infrastructure Certificate and Certificate Revocation List 2229 ID NSA's CMS Key Management Attributes June 4, 2013 2231 (CRL) Profile", RFC 5280, May 2008. 2233 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2234 RFC 5652, September 2009. 2236 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 2237 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 2238 June 2010. 2240 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 2241 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 2242 June 2010. 2244 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2245 2010. 2247 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 2248 Message Syntax (CMS) Content Constraints Extension", 2249 RFC 6010, September 2010. 2251 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2252 (CMS) Symmetric Key Package Content Type", RFC 6031, 2253 December 2010. 2255 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 2256 (CMS) Protection of Symmetric Key Package Content Types", 2257 RFC 6160, April 2011. 2259 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 2260 Message Syntax (CMS) Asymmetric Key Package Content Type", 2261 RFC 6162, April 2011. 2263 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 2264 for the Cryptographic Message Syntax (CMS) and the Public 2265 Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 2266 2011. 2268 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 2269 Information technology - Open Systems Interconnection - 2270 The Directory: Public-key and attribute certificate 2271 frameworks. 2273 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 2274 Information Technology - Abstract Syntax Notation One. 2276 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 2277 Information Technology - Abstract Syntax Notation One: 2278 Information Object Specification. 2280 ID NSA's CMS Key Management Attributes June 4, 2013 2282 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 2283 Information Technology - Abstract Syntax Notation One: 2284 Constraint Specification. 2286 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 2287 Information Technology - Abstract Syntax Notation One: 2288 Parameterization of ASN.1 Specifications. 2290 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 2291 Information Technology - ASN.1 encoding rules: 2292 Specification of Basic Encoding Rules (BER), Canonical 2293 Encoding Rules (CER) and Distinguished Encoding Rules 2294 (DER). 2296 [ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic 2297 Message Syntax (CMS) Key Package Receipt and Error Content 2298 Types", draft-housley-ct-keypackage-receipt-n-error- 2299 00.txt, (work-in-progress). 2301 33.2 Informative References 2303 [FIPS-186] National Institute of Standards and Technology (NIST), 2304 FIPS 186-3, Digital Signature Standard (DSS), June 2009. 2306 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2307 Management Protocol (TAMP)", RFC 5934, August 2010. 2309 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 2310 (CMS) Encrypted Key Package Content Type", RFC 6032, 2311 December 2010. 2313 [X.411] ITU-T Recommendation X.411 (1988) | ISO/IEC 10021-4:1988, 2314 Data Communication Networks Message Handling Systems - 2315 Message Transfer System - Abstract Service Definition and 2316 Procedures. 2318 ID NSA's CMS Key Management Attributes June 4, 2013 2320 Appendix A. ASN.1 Module 2322 KMAttributes2012 2323 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2324 smime(16) modules(0) 39 } 2326 DEFINITIONS IMPLICIT TAGS ::= 2328 BEGIN 2330 -- EXPORT ALL 2332 IMPORTS 2334 -- From [RFC5911] 2336 aa-communityIdentifiers, CommunityIdentifier 2337 FROM CMSFirmwareWrapper-2009 2338 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2339 smime(16) modules(0) id-mod-cms-firmware-wrap-02(40) } 2341 -- From [RFC5911] 2343 aa-contentHint, ESSSecurityLabel, id-aa-securityLabel 2344 FROM ExtendedSecurityServices-2009 2345 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2346 smime(16) modules(0) id-mod-ess-2006-02(42) } 2348 -- From [RFC5911] [RFC5912] 2350 AlgorithmIdentifier{}, SMIME-CAPS, ParamOptions, KEY-WRAP 2351 FROM AlgorithmInformation-2009 2352 { iso(1) identified-organization(3) dod(6) internet(1) 2353 security(5) mechanisms(5) pkix(7) id-mod(0) 2354 id-mod-algorithmInformation-02(58) } 2356 -- From [RFC5912] 2358 Name, Certificate 2359 FROM PKIX1Explicit-2009 2360 { iso(1) identified-organization(3) dod(6) internet(1) 2361 security(5) mechanisms(5) pkix(7) id-mod(0) 2362 id-mod-pkix1-explicit-02(51) } 2364 ID NSA's CMS Key Management Attributes June 4, 2013 2366 -- From [RFC5912] 2368 GeneralNames, SubjectInfoAccessSyntax, id-pe-subjectInfoAccess 2369 FROM PKIX1Implicit-2009 2370 { iso(1) identified-organization(3) dod(6) internet(1) 2371 security(5) mechanisms(5) pkix(7) id-mod(0) 2372 id-mod-pkix1-implicit-02(59) } 2374 -- FROM [RFC5912] 2376 ATTRIBUTE 2377 FROM PKIX-CommonTypes-2009 2378 { iso(1) identified-organization(3) dod(6) internet(1) 2379 security(5) mechanisms(5) pkix(7) id-mod(0) 2380 id-mod-pkixCommon-02(57) } 2382 -- From [RFC6010] 2384 CMSContentConstraints 2385 FROM CMSContentConstraintsCertExtn 2386 { iso(1) identified-organization(3) dod(6) internet(1) 2387 security(5) mechanisms(5) pkix(7) id-mod(0) 2388 cmsContentConstr-93(42) } 2390 -- From [RFC6268] 2392 aa-binarySigningTime, BinaryTime 2393 FROM BinarySigningTimeModule-2010 2394 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2395 smime(16) modules(0) id-mod-binSigningTime-2009(55) } 2397 -- From [RFC6268] 2399 CertificateChoices, CertificateSet, Attribute {}, 2400 aa-contentType, aa-messageDigest 2401 FROM CryptographicMessageSyntax-2010 2402 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2403 smime(16) modules(0) id-mod-cms-2009(58) } 2405 -- From [ID.housley-keypackage-receipt-n-error] 2407 aa-keyPackageIdentifierAndReceiptRequest, SIREntityName 2408 FROM KeyPackageReceiptAndErrorModuleV2 2409 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2410 smime(16) modules(0) TBD } 2412 ID NSA's CMS Key Management Attributes June 4, 2013 2414 -- From [X.509] 2416 certificateExactMatch 2417 FROM CertificateExtensions 2418 { joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4 } 2420 ; 2422 -- ATTRIBUTES 2424 -- Replaces SignedAttributesSet information object set from 2425 -- [RFC6268]. 2427 SignedAttributesSet ATTRIBUTE ::= { 2428 aa-contentType | 2429 aa-messageDigest | 2430 aa-contentHint | 2431 aa-communityIdentifiers | 2432 aa-binarySigningTime | 2433 aa-keyPackageIdentifierAndReceiptRequest | 2434 aa-manifest | 2435 aa-keyAlgorithm | 2436 aa-userCertificate | 2437 aa-keyPackageReceivers-v2 | 2438 aa-tsecNomenclature | 2439 aa-keyPurpose | 2440 aa-keyUse | 2441 aa-transportKey | 2442 aa-keyDistributionPeriod | 2443 aa-keyValidityPeriod | 2444 aa-keyDurationPeriod | 2445 aa-classificationAttribute | 2446 aa-keyPackageType | 2447 aa-pkiPath | 2448 aa-usefulCertificates, 2449 ... } 2451 -- Replaces UnsignedAttributes from [RFC6268]. 2453 UnsignedAttributes ATTRIBUTE ::= { 2454 ... 2455 } 2457 ID NSA's CMS Key Management Attributes June 4, 2013 2459 -- Replaces UnprotectedEnvAttributes from [RFC6268]. 2461 UnprotectedEnvAttributes ATTRIBUTE ::= { 2462 aa-contentDecryptKeyIdentifier | 2463 aa-certificatePointers | 2464 aa-cRLDistributionPoints, 2465 ... 2466 } 2468 -- Replaces UnprotectedEncAttributes from [RFC6268]. 2470 UnprotectedEncAttributes ATTRIBUTE ::= { 2471 aa-certificatePointers | 2472 aa-cRLDistributionPoints, 2473 ... 2474 } 2476 -- Replaces AuthAttributeSet from [RFC6268] 2478 AuthAttributeSet ATTRIBUTE ::= { 2479 aa-contentType | 2480 aa-messageDigest | 2481 aa-contentHint | 2482 aa-communityIdentifiers | 2483 aa-binarySigningTime | 2484 aa-keyPackageIdentifierAndReceiptRequest | 2485 aa-manifest | 2486 aa-keyAlgorithm | 2487 aa-userCertificate | 2488 aa-keyPackageReceivers-v2 | 2489 aa-tsecNomenclature | 2490 aa-keyPurpose | 2491 aa-keyUse | 2492 aa-transportKey | 2493 aa-keyDistributionPeriod | 2494 aa-keyValidityPeriod | 2495 aa-keyDurationPeriod | 2496 aa-classificationAttribute | 2497 aa-keyPackageType | 2498 aa-pkiPath | 2499 aa-usefulCertificates, 2500 ... } 2502 -- Replaces UnauthAttributeSet from [RFC6268] 2504 UnauthAttributeSet ATTRIBUTE ::= { 2505 ... 2506 } 2508 ID NSA's CMS Key Management Attributes June 4, 2013 2510 -- Replaces AuthEnvDataAttributeSet from [RFC6268] 2512 AuthEnvDataAttributeSet ATTRIBUTE ::= { 2513 aa-certificatePointers | 2514 aa-cRLDistributionPoints, 2515 ... 2516 } 2518 -- Replaces UnauthEnvDataAttributeSet from [RFC6268] 2520 UnauthEnvDataAttributeSet ATTRIBUTE ::= { 2521 ... 2522 } 2524 -- Replaces OneAsymmetricKeyAttributes from [RFC5958] 2526 OneAsymmetricKeyAttributes ATTRIBUTE ::= { 2527 aa-userCertificate | 2528 aa-tsecNomenclature | 2529 aa-keyPurpose | 2530 aa-keyUse | 2531 aa-transportKey | 2532 aa-keyDistributionPeriod | 2533 aa-keyValidityPeriod | 2534 aa-keyDurationPeriod | 2535 aa-classificationAttribute | 2536 aa-splitIdentifier | 2537 aa-signatureUsage-v3 | 2538 aa-otherCertificateFormats | 2539 aa-pkiPath | 2540 aa-usefulCertificates, 2541 ... } 2543 -- Replaces SKeyPkgAttributes from [RFC6031] 2545 SKeyPkgAttributes ATTRIBUTE ::= { 2546 aa-keyAlgorithm | 2547 aa-tsecNomenclature | 2548 aa-keyPurpose | 2549 aa-keyUse | 2550 aa-keyDistributionPeriod | 2551 aa-keyValidityPeriod | 2552 aa-keyDurationPeriod | 2553 aa-classificationAttribute | 2554 aa-keyWrapAlgorithm | 2555 aa-contentDecryptKeyIdentifier, 2556 ... } 2558 ID NSA's CMS Key Management Attributes June 4, 2013 2560 -- Replaces SKeyAttributes from [RFC6031] 2562 SKeyAttributes ATTRIBUTE ::= { 2563 aa-keyAlgorithm | 2564 aa-tsecNomenclature | 2565 aa-keyPurpose | 2566 aa-keyUse | 2567 aa-keyDistributionPeriod | 2568 aa-keyValidityPeriod | 2569 aa-keyDurationPeriod | 2570 aa-classificationAttribute | 2571 aa-splitIdentifier | 2572 aa-keyWrapAlgorithm | 2573 aa-contentDecryptKeyIdentifier, 2574 ... } 2576 -- Replaces ContentAttributeSet from [RFC6268] 2578 ContentAttributeSet ATTRIBUTE ::= { 2579 aa-communityIdentifiers | 2580 aa-keyPackageIdentifierAndReceiptRequest | 2581 aa-keyAlgorithm | 2582 aa-keyPackageReceivers-v2 | 2583 aa-tsecNomenclature | 2584 aa-keyPurpose | 2585 aa-keyUse | 2586 aa-transportKey | 2587 aa-keyDistributionPeriod | 2588 aa-transportKey | 2589 aa-keyDistributionPeriod | 2590 aa-keyValidityPeriod | 2591 aa-keyDurationPeriod | 2592 aa-classificationAttribute | 2593 aa-keyPackageType | 2594 aa-pkiPath | 2595 aa-usefulCertificates, 2596 ... } 2598 -- Content Type, Message Digest, and Content Hint, and Binary Signing 2599 -- Time are imported from [RFC6268]. 2600 -- Community Identifiers is imported from [RFC5911]. 2602 -- Manifest Attribute 2604 aa-manifest ATTRIBUTE ::= { 2605 TYPE Manifest 2606 IDENTIFIED BY id-aa-KP-manifest } 2608 ID NSA's CMS Key Management Attributes June 4, 2013 2610 id-aa-KP-manifest OBJECT IDENTIFIER ::= 2611 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2612 dod(2) infosec(1) attributes(5) 72 } 2614 Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle 2616 -- Key Algorithm Attribute 2618 aa-keyAlgorithm ATTRIBUTE ::= { 2619 TYPE KeyAlgorithm 2620 IDENTIFIED BY id-kma-keyAlgorithm } 2622 id-kma-keyAlgorithm OBJECT IDENTIFIER ::= 2623 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2624 dod(2) infosec(1) keying-material-attributes(13) 1 } 2626 KeyAlgorithm ::= SEQUENCE { 2627 keyAlg OBJECT IDENTIFIER, 2628 checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL, 2629 crcAlg [2] OBJECT IDENTIFIER OPTIONAL } 2631 -- User Certificate Attribute 2633 aa-userCertificate ATTRIBUTE ::= { 2634 TYPE Certificate 2635 EQUALITY MATCHING RULE certificateExactMatch 2636 IDENTIFIED BY id-at-userCertificate } 2638 id-at-userCertificate OBJECT IDENTIFIER ::= 2639 { joint-iso-itu-t(2) ds(5) attributes(4) 36 } 2641 -- Key Package Receivers Attribute 2643 aa-keyPackageReceivers-v2 ATTRIBUTE ::= { 2644 TYPE KeyPkgReceiversV2 2645 IDENTIFIED BY id-kma-keyPkgReceiversV2 } 2647 id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= 2648 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2649 dod(2) infosec(1) keying-material-attributes(13) 16 } 2651 KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver 2653 KeyPkgReceiver ::= CHOICE { 2654 sirEntity [0] SIREntityName, 2655 community [1] CommunityIdentifier } 2657 ID NSA's CMS Key Management Attributes June 4, 2013 2659 -- TSEC Nomenclature Attribute 2661 aa-tsecNomenclature ATTRIBUTE ::= { 2662 TYPE TSECNomenclature 2663 IDENTIFIED BY id-kma-TSECNomenclature } 2665 id-kma-TSECNomenclature OBJECT IDENTIFIER ::= 2666 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2667 dod(2) infosec(1) keying-material-attributes(13) 3 } 2669 TSECNomenclature ::= SEQUENCE { 2670 shortTitle ShortTitle, 2671 editionID EditionID OPTIONAL, 2672 registerID RegisterID OPTIONAL, 2673 segmentID SegmentID OPTIONAL } 2675 ShortTitle ::= PrintableString 2677 EditionID ::= CHOICE { 2678 char CHOICE { 2679 charEdition [1] CharEdition, 2680 charEditionRange [2] CharEditionRange }, 2681 num CHOICE { 2682 numEdition [3] NumEdition, 2683 numEditionRange [4] NumEditionRange } } 2685 CharEdition ::= PrintableString 2687 CharEditionRange ::= SEQUENCE { 2688 firstCharEdition CharEdition, 2689 lastCharEdition CharEdition } 2691 NumEdition ::= INTEGER (0..308915776) 2693 NumEditionRange ::= SEQUENCE { 2694 firstNumEdition NumEdition, 2695 lastNumEdition NumEdition } 2697 RegisterID ::= CHOICE { 2698 register [5] Register, 2699 registerRange [6] RegisterRange } 2701 Register ::= INTEGER (0..2147483647) 2703 RegisterRange ::= SEQUENCE { 2704 firstRegister Register, 2705 lastRegister Register } 2707 ID NSA's CMS Key Management Attributes June 4, 2013 2709 SegmentID ::= CHOICE { 2710 segmentNumber [7] SegmentNumber, 2711 segmentRange [8] SegmentRange } 2713 SegmentNumber ::= INTEGER (1..127) 2715 SegmentRange ::= SEQUENCE { 2716 firstSegment SegmentNumber, 2717 lastSegment SegmentNumber } 2719 -- Key Purpose Attribute 2721 aa-keyPurpose ATTRIBUTE ::= { 2722 TYPE KeyPurpose 2723 IDENTIFIED BY id-kma-keyPurpose } 2725 id-kma-keyPurpose OBJECT IDENTIFIER ::= 2726 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2727 dod(2) infosec(1) keying-material-attributes(13) 13 } 2729 KeyPurpose ::= ENUMERATED { 2730 n-a (0), -- Not Applicable 2731 a (65), -- Operational 2732 b (66), -- Compatible Multiple Key 2733 l (76), -- Logistics Combinations 2734 m (77), -- Maintenance 2735 r (82), -- Reference 2736 s (83), -- Sample 2737 t (84), -- Training 2738 v (86), -- Developmental 2739 x (88), -- Exercise 2740 z (90), -- "On the Air" Testing 2741 ... -- Expect additional key purpose values -- } 2743 -- Key Use Attribute 2745 aa-keyUse ATTRIBUTE ::= { 2746 TYPE KeyUse 2747 IDENTIFIED BY id-kma-keyUse } 2749 id-kma-keyUse OBJECT IDENTIFIER ::= 2750 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2751 dod(2) infosec(1) keying-material-attributes(13) 14 } 2753 ID NSA's CMS Key Management Attributes June 4, 2013 2755 KeyUse ::= ENUMERATED { 2756 n-a (0), -- Not Applicable 2757 ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format) 2758 kek (2), -- Key Encryption Key 2759 kpk (3), -- Key Production Key 2760 msk (4), -- Message Signature Key 2761 qkek (5), -- QUADRANT Key Encryption Key 2762 tek (6), -- Traffic Encryption Key 2763 tsk (7), -- Transmission Security Key 2764 trkek (8), -- Transfer Key Encryption Key 2765 nfk (9), -- Netted FIREFLY Key 2766 efk (10), -- FIREFLY Key (Enhanced Format) 2767 ebfk (11), -- FIREFLY Key (Enhanceable Basic Format) 2768 aek (12), -- Algorithm Encryption Key 2769 wod (13), -- Word of Day 2770 kesk (246), -- Key Establishment Key 2771 eik (247), -- Entity Identification Key 2772 ask (248), -- Authority Signature Key 2773 kmk (249), -- Key Modifier Key 2774 rsk (250), -- Revocation Signature Key 2775 csk (251), -- Certificate Signature Key 2776 sak (252), -- Symmetric Authentication Key 2777 rgk (253), -- Random Generation Key 2778 cek (254), -- Certificate Encryption Key 2779 exk (255), -- Exclusion Key 2780 ... -- Expect additional key use values -- } 2782 -- Transport Key Attribute 2784 aa-transportKey ATTRIBUTE ::= { 2785 TYPE TransOp 2786 IDENTIFIED BY id-kma-transportKey } 2788 id-kma-transportKey OBJECT IDENTIFIER ::= 2789 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2790 dod(2) infosec(1) keying-material-attributes(13) 15 } 2792 TransOp ::= ENUMERATED { 2793 transport (1), 2794 operational (2) } 2796 -- Key Distribution Period Attribute 2798 aa-keyDistributionPeriod ATTRIBUTE ::= { 2799 TYPE KeyDistPeriod 2800 IDENTIFIED BY id-kma-keyDistPeriod } 2802 ID NSA's CMS Key Management Attributes June 4, 2013 2804 id-kma-keyDistPeriod OBJECT IDENTIFIER ::= 2805 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2806 dod(2) infosec(1) keying-material-attributes(13) 5 } 2808 KeyDistPeriod ::= SEQUENCE { 2809 doNotDistBefore [0] BinaryTime OPTIONAL, 2810 doNotDistAfter BinaryTime } 2812 -- Key Validity Period Attribute 2814 aa-keyValidityPeriod ATTRIBUTE ::= { 2815 TYPE KeyValidityPeriod 2816 IDENTIFIED BY id-kma-keyValidityPeriod } 2818 id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= 2819 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2820 dod(2) infosec(1) keying-material-attributes(13) 6 } 2822 KeyValidityPeriod ::= SEQUENCE { 2823 doNotUseBefore BinaryTime, 2824 doNotUseAfter BinaryTime OPTIONAL } 2826 -- Key Duration Attribute 2828 aa-keyDurationPeriod ATTRIBUTE ::= { 2829 TYPE KeyDuration 2830 IDENTIFIED BY id-kma-keyDuration } 2832 id-kma-keyDuration OBJECT IDENTIFIER ::= 2833 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2834 dod(2) infosec(1) keying-material-attributes(13) 7 } 2836 KeyDuration ::= CHOICE { 2837 hours [0] INTEGER (1..ub-KeyDuration-hours), 2838 days INTEGER (1..ub-KeyDuration-days), 2839 weeks [1] INTEGER (1..ub-KeyDuration-weeks), 2840 months [2] INTEGER (1..ub-KeyDuration-months), 2841 years [3] INTEGER (1..ub-KeyDuration-years) } 2843 ub-KeyDuration-hours INTEGER ::= 96 2844 ub-KeyDuration-days INTEGER ::= 732 2845 ub-KeyDuration-weeks INTEGER ::= 104 2846 ub-KeyDuration-months INTEGER ::= 72 2847 ub-KeyDuration-years INTEGER ::= 100 2849 ID NSA's CMS Key Management Attributes June 4, 2013 2851 -- Classification Attribute 2853 -- The attribute syntax is imported from [RFC6268]. The term 2854 -- "classification" is used in this document, but the term "security 2855 -- label" is used in [RFC2634]. The terms have the same meaning. 2857 aa-classificationAttribute ATTRIBUTE ::= { 2858 TYPE Classification 2859 IDENTIFIED BY id-aa-KP-classification } 2861 id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel 2863 Classification ::= ESSSecurityLabel 2865 id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= 2866 { 2 16 840 1 101 2 1 8 3 4 } 2868 id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= 2869 { 2 16 840 1 101 2 1 8 3 1 } 2871 EnumeratedTag ::= SEQUENCE { 2872 tagName OBJECT IDENTIFIER, 2873 attributeList SET OF SecurityAttribute } 2875 SecurityAttribute ::= INTEGER (0..MAX) 2877 -- Split Identifier Attribute 2879 aa-splitIdentifier ATTRIBUTE ::= { 2880 TYPE SplitID 2881 IDENTIFIED BY id-kma-splitID } 2883 id-kma-splitID OBJECT IDENTIFIER ::= 2884 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2885 dod(2) infosec(1) keying-material-attributes(13) 11 } 2887 SplitID ::= SEQUENCE { 2888 half ENUMERATED { a(0), b(1) }, 2889 combineAlg AlgorithmIdentifier 2890 {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL } 2892 ID NSA's CMS Key Management Attributes June 4, 2013 2894 COMBINE-ALGORITHM ::= CLASS { 2895 &id OBJECT IDENTIFIER UNIQUE, 2896 &Params OPTIONAL, 2897 ¶mPresence ParamOptions DEFAULT absent, 2898 &smimeCaps SMIME-CAPS OPTIONAL 2899 } 2900 WITH SYNTAX { 2901 IDENTIFIER &id 2902 [PARAMS [TYPE &Params] ARE ¶mPresence] 2903 [SMIME-CAPS &smimeCaps] 2904 } 2906 CombineAlgorithms COMBINE-ALGORITHM ::= { 2907 ... 2908 } 2910 -- Key Package Type Attribute 2912 aa-keyPackageType ATTRIBUTE ::= { 2913 TYPE KeyPkgType 2914 IDENTIFIED BY id-kma-keyPkgType } 2916 id-kma-keyPkgType OBJECT IDENTIFIER ::= 2917 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2918 dod(2) infosec(1) keying-material-attributes(13) 12 } 2920 KeyPkgType ::= OBJECT IDENTIFIER 2922 -- Signature Usage Attribute 2924 aa-signatureUsage-v3 ATTRIBUTE ::= { 2925 TYPE SignatureUsage 2926 IDENTIFIED BY id-kma-sigUsageV3 } 2928 id-kma-sigUsageV3 OBJECT IDENTIFIER ::= 2929 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2930 dod(2) infosec(1) keying-material-attributes(13) 22 } 2932 SignatureUsage ::= CMSContentConstraints 2934 -- Other Certificate Format Attribute 2936 aa-otherCertificateFormats ATTRIBUTE ::= { 2937 TYPE CertificateChoices 2938 IDENTIFIED BY id-kma-otherCertFormats } 2940 ID NSA's CMS Key Management Attributes June 4, 2013 2942 id-kma-otherCertFormats OBJECT IDENTIFIER ::= 2943 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2944 dod(2) infosec(1) keying-material-attributes(13) 19 } 2946 -- PKI Path Attribute 2948 aa-pkiPath ATTRIBUTE ::= { 2949 TYPE PkiPath 2950 IDENTIFIED BY id-at-pkiPath } 2952 id-at-pkiPath OBJECT IDENTIFIER ::= 2953 { joint-iso-itu-t(2) ds(5) attributes(4) 70 } 2955 PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate 2957 -- Useful Certificates Attribute 2959 aa-usefulCertificates ATTRIBUTE ::= { 2960 TYPE CertificateSet 2961 IDENTIFIED BY id-kma-usefulCerts } 2963 id-kma-usefulCerts 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) 20 } 2967 -- Key Wrap Attribute 2969 aa-keyWrapAlgorithm ATTRIBUTE ::= { 2970 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}} 2971 IDENTIFIED BY id-kma-keyWrapAlgorithm } 2973 id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= 2974 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2975 dod(2) infosec(1) keying-material-attributes(13) 21 } 2977 KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... } 2979 -- Content Decryption Key Identifier Attribute 2981 aa-contentDecryptKeyIdentifier ATTRIBUTE ::= { 2982 TYPE ContentDecryptKeyID 2983 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 2985 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= 2986 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2987 dod(2) infosec(1) attributes(5) 66 } 2989 ContentDecryptKeyID::= OCTET STRING 2991 ID NSA's CMS Key Management Attributes June 4, 2013 2993 -- Certificate Pointers Attribute 2995 aa-certificatePointers ATTRIBUTE ::= { 2996 TYPE SubjectInfoAccessSyntax 2997 IDENTIFIED BY id-pe-subjectInfoAccess } 2999 -- CRL Pointers Attribute 3001 aa-cRLDistributionPoints ATTRIBUTE ::= { 3002 TYPE GeneralNames 3003 IDENTIFIED BY id-aa-KP-crlPointers } 3005 id-aa-KP-crlPointers OBJECT IDENTIFIER ::= 3006 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3007 dod(2) infosec(1) attributes (5) 70 } 3009 -- ExtendedErrorCodes 3011 id-errorCodes OBJECT IDENTIFIER ::= 3012 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3013 dod(2) infosec(1) errorCodes(22) } 3015 id-missingKeyType OBJECT IDENTIFIER ::= { 3016 id-errorCodes 1 } 3018 id-privacyMarkTooLong OBJECT IDENTIFIER ::= { 3019 id-errorCodes 2 } 3021 id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= { 3022 id-errorCodes 3 } 3024 END 3026 ID NSA's CMS Key Management Attributes June 4, 2013 3028 Authors' Addresses 3030 Paul Timmel 3031 National Information Assurance Research Laboratory 3032 National Security Agency 3034 Email: pstimme@tycho.ncsc.mil 3036 Russ Housley 3037 Vigil Security, LLC 3038 918 Spring Knoll Drive 3039 Herndon, VA 20170 3040 USA 3042 Email: : housley@vigilsec.com 3044 Sean Turner 3045 IECA, Inc. 3046 3057 Nutley Street, Suite 106 3047 Fairfax, VA 22031 3048 USA 3050 Email: turners@ieca.com