idnits 2.17.1 draft-turner-km-attributes-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1848 has weird spacing: '...alue of the k...' -- The document date (March 15, 2016) is 2964 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 2841 -- Looks like a reference, but probably isn't: '2' on line 2842 -- Looks like a reference, but probably isn't: '0' on line 2839 -- Looks like a reference, but probably isn't: '3' on line 2843 -- Looks like a reference, but probably isn't: '4' on line 2691 -- Looks like a reference, but probably isn't: '5' on line 2706 -- Looks like a reference, but probably isn't: '6' on line 2707 -- Looks like a reference, but probably isn't: '7' on line 2716 -- Looks like a reference, but probably isn't: '8' on line 2717 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Timmel 3 Internet-Draft National Security Agency 4 Intended Status: Informational R. Housley 5 Expires: September 16, 2016 Vigil Security 6 S. Turner 7 IECA 8 March 15, 2016 10 NSA's Cryptographic Message Syntax (CMS) Key Management Attributes 11 draft-turner-km-attributes-07.txt 13 Abstract 15 This document defines key management attributes used by the National 16 Security Agency (NSA). The attributes can appear in asymmetric 17 and/or symmetric key packages as well as the Cryptographic Message 18 Syntax (CMS) content types that subsequently envelope the key 19 packages. Key packages described in RFC 5958 and RFC 6031 are 20 examples where these attributes can be used. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 Copyright and License Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. CMS-Defined Attributes . . . . . . . . . . . . . . . . . . . . 6 59 3. Community Identifiers . . . . . . . . . . . . . . . . . . . . . 7 60 4. Key Province Attribute . . . . . . . . . . . . . . . . . . . . 8 61 5. Binary Signing Time . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. User Certificate . . . . . . . . . . . . . . . . . . . . . . . 11 65 9. Key Package Receivers . . . . . . . . . . . . . . . . . . . . . 11 66 10. TSEC Nomenclature . . . . . . . . . . . . . . . . . . . . . . 13 67 11. Key Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 12. Key Use . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 13. Transport Key . . . . . . . . . . . . . . . . . . . . . . . . 20 70 14. Key Distribution Period . . . . . . . . . . . . . . . . . . . 20 71 15. Key Validity Period . . . . . . . . . . . . . . . . . . . . . 21 72 16. Key Duration . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 17. Classification . . . . . . . . . . . . . . . . . . . . . . . . 24 74 17.1. Security Label . . . . . . . . . . . . . . . . . . . . . . 25 75 18. Split Key Identifier . . . . . . . . . . . . . . . . . . . . . 28 76 19. Key Package Type . . . . . . . . . . . . . . . . . . . . . . . 29 77 20. Signature Usage . . . . . . . . . . . . . . . . . . . . . . . 30 78 21. Other Certificate Format . . . . . . . . . . . . . . . . . . . 32 79 22. PKI Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 80 23. Useful Certificates . . . . . . . . . . . . . . . . . . . . . 34 81 24. Key Wrap Algorithm . . . . . . . . . . . . . . . . . . . . . . 35 82 25. Content Decryption Key Identifier . . . . . . . . . . . . . . 36 83 25.1. Content Decryption Key Identifier: Symmetric Key and 84 Symmetric Key Package . . . . . . . . . . . . . . . . . . 36 85 25.2. Content Decryption Key Identifier: Unprotected . . . . . . 36 86 26. Certificate Pointers . . . . . . . . . . . . . . . . . . . . . 37 87 27. CRL Pointers . . . . . . . . . . . . . . . . . . . . . . . . . 38 88 28. Key Package Identifier and Receipt Request . . . . . . . . . . 38 89 29. Additional Error Codes . . . . . . . . . . . . . . . . . . . . 38 90 30. Processing Key Package Attribute Values and CMS Content 91 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 39 92 31. Attribute Scope . . . . . . . . . . . . . . . . . . . . . . . 40 93 32. Security Considerations . . . . . . . . . . . . . . . . . . . 47 94 33. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 95 34. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 96 34.1 Normative References . . . . . . . . . . . . . . . . . . . 48 97 34.2 Informative References . . . . . . . . . . . . . . . . . . 50 99 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 51 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 102 1. Introduction 104 This document defines key management attributes used by the National 105 Security Agency (NSA). The attributes can appear in asymmetric 106 and/or symmetric key packages as well as the Cryptographic Message 107 Syntax (CMS) content types that subsequently envelope the key 108 packages. 110 This document contains definitions for new attributes as well as 111 previously defined attributes. References are provided to the 112 previously defined attributes however their definitions are included 113 herein for convenience. 115 CMS allows for arbitrary nesting of content types. Attributes are 116 also supported in various locations in content types and key 117 packages, which are themselves content types (see Section 1.1). An 118 implementation that supports all of the possibilities would be 119 extremely complex. Instead of implementing the full flexibility 120 supported by this document, some devices may choose to support one or 121 more templates, which is a profile for a combination of CMS content 122 type(s), key package, and attribute(s) (see Section 19). 124 1.1. Attribute Locations 126 There are a number of CMS content types that support attributes 127 SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData 128 [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData 129 [RFC5083] as well as ContentWithAttributes [RFC4073]. There are also 130 a number of other content types defined with CONTENT-TYPE [RFC6268] 131 that support attributes including AsymmetricKeyPackage [RFC5958] and 132 SymmetricKeyPackage [RFC6031]. 134 CMS defines a number of "protecting content types", SignedData 135 [RFC5652], EnvelopedData [RFC5652], EncryptedData [RFC5652], 136 AuthenticatedData [RFC5652], and AuthEnvelopedData [RFC5083], that 137 provide some type of security service. There are also other CMS 138 content types, Data [RFC5652], ContentWithAttributes [RFC4073], and 139 ContentCollection [RFC4073] that provide no security service. 141 There are also different kinds of attributes in these content types: 143 o SignedData supports two kinds of attributes: signed and unsigned 144 attributes in the signedAttrs and unsignedAttrs fields, 145 respectively. 147 o EnvelopedData and EncryptedData each support one kind of 148 attribute: unprotected attributes in the unprotectedAttrs field. 150 o AuthEnvelopedData supports two kinds of attributes: authenticated 151 and unauthenticated attributes in the authAttrs and unauthAttrs 152 fields, respectively. Both of these attributes are also 153 unprotected (i.e., they are not encrypted); therefore, when 154 referring to AuthEnvelopedData attributes they are 155 authenticated/unprotected and unauthenticated/unprotected. For 156 this specification, unauthenticated attributes MUST NOT be 157 included. 159 o AuthenticatedData supports two kinds of attributes: 160 authenticated and unauthenticated attributes in the authAttrs and 161 unauthAttrs fields, respectively. For this specification, 162 unauthenticated attributes MUST NOT be included. 164 o ContentWithAttributes supports one kind of attribute: content 165 attributes in the attrs field. 167 o AsymmetricKeyPackage supports one kind of attribute: asymmetric 168 key attributes in the attributes field. If an attribute appears 169 as part of an asymmetric key package, it SHOULD appear in the 170 attributes field of the AsymmetricKeyPackage. 172 o SymmetricKeyPackage supports two kinds of attributes: symmetric 173 key and symmetric key package attributes in the sKeyAttrs and 174 sKeyPkgAttrs fields, respectively. Note that [RFC6031] prohibits 175 the same attribute from appearing in both locations in the same 176 SymmetricKeyPackage. 178 Note that this specification updates the following information object 179 sets SignedAttributesSet, UnsignedAttributes, 180 UnprotectedEnvAttributes, UnprotectedEncAttributes, AuthAttributeSet, 181 UnauthAttributeSet, AuthEnvDataAttributeSet, 182 UnauthEnvDataAttributeSet, and ContentAttributeSet from [RFC6268] as 183 well as OneAsymmetricKeyAttributes from [RFC5958], SKeyPkgAttributes 184 from [RFC6031], SKeyAttributes from [RFC6031] to constrain the 185 permissible locations for attributes. See Appendix A for the ASN.1 186 for the information object sets. 188 1.2. ASN.1 Notation 190 The attributes defined in this document use 2002 ASN.1 191 [X.680][X.681][X.682][X.683]. The attributes MUST be DER [X.690] 192 encoded. 194 Each of the attributes has a single attribute value instance in the 195 values set. Even though the syntax is defined as a set, there MUST 196 be exactly one instance of AttributeValue present. Further, the 197 SignedAttributes, UnsignedAttributes, UnprotectedAttributes, 198 AuthAttributes, and UnauthAttributes are also defined as a set, and 199 this set MUST include only one instance of any particular type of 200 attribute. That is, any object identifier appearing in AttributeType 201 MUST only appear one time in the set of attributes. 203 SignedData, EnvelopedData, EncryptedData, AuthenticatedData, 204 AuthEnvelopedData, and ContentWithAttributes were originally defined 205 using the 1988 version of ASN.1. These definitions were updated to 206 the 2008 version of ASN.1 by [RFC6268]. None of the new 2008 ASN.1 207 tokens are used, which allows 2002 compilers to compile 2008 ASN.1. 208 AsymmetricKeyPackage and SymmetricKeyPackage are defined using the 209 2002 ASN.1. 211 [RFC5652] and [RFC2634] define generally useful attributes for CMS 212 using the 1988 version of ASN.1. These definitions were updated to 213 the 2008 version of ASN.1 by [RFC6268] and the 2002 version of ASN.1 214 by [RFC5911], respectively. [RFC4108] and [RFC6019] also defined 215 attributes using the 1988 version of ASN.1, which this document uses. 216 Both were updated by [RFC5911] to the 2002 ASN.1. Refer to 217 [RFC2634], [RFC4108], [RFC5652], and [RFC6019] for the attribute's 218 semantics but refer to [RFC5911] or [RFC6268] for the attribute's 219 ASN.1 syntax. 221 1.3. Terminology 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in RFC 226 2119 [RFC2119]. 228 Attribute Scope: The scope of an attribute is the compilation of 229 keying material to which the attribute value is assigned. The scope 230 of each attribute is determined by its placement within the key 231 package or content collection. See Section 31. 233 SIR: Sender-Intermediary-Receiver is a model with three entities: 235 o A sender initiates the delivery of a key to one or more 236 receivers. It may wrap or encrypt the key for delivery. This is 237 expected to be the common case, since cleartext key is vulnerable 238 to exposure and compromise. If the sender is to encrypt the key 239 for delivery, it must know how to encrypt the key so that the 240 receiver(s) can decrypt it. A sender may also carry out any of 241 the functions of an intermediary. 243 * The original key package creators are sometimes referred to as 244 key source authorities. These entities create the symmetric 245 and/or asymmetric key package and apply the initial CMS 246 protecting layer, which is normally a SignedData but sometimes 247 an AuthenticatedData. This initial CMS protecting layer is 248 maintained through any intermediary for the receivers of the 249 key package to ensure that receivers can validate the key 250 source authority. 252 o An intermediary does not have access to cleartext key. An 253 intermediary may perform source authentication on key packages, 254 and may append or remove management information related to the 255 package. It may encapsulate the encrypted key packages in larger 256 packages that contain other user data destined for later 257 intermediaries or receivers. 259 o A receiver has access to cleartext key. If the received key 260 package is encrypted, it can unwrap or decrypt the encrypted key 261 to obtain the cleartext key. A receiver may be the final 262 destination of the cryptographic product. An element that acts 263 as a receiver and is not the final destination of the key package 264 may also act as a sender or as an intermediary. After receiving 265 a key, a receiver may encrypt the received key for local storage. 267 NOTE: As noted in Section 1, a receiver can be tailored to support a 268 particular combination of CMS content type(s), key package, and 269 attribute(s) resulting in less complex implementations. All of these 270 tailored receivers can be supported by a common key management 271 infrastructure that uses this specification, which also can yield 272 efficiencies in generation and provisioning. Senders and 273 intermediaries that have to understand multiple tailored receivers 274 get the efficiency of a common specification language and modular 275 implementation, as opposed to needing stove-piped processing for each 276 different receiver. 278 2. CMS-Defined Attributes 280 The following attributes are defined for [RFC5652]: 282 o content-type [RFC5652][RFC5911][RFC6268] uniquely specifies the 283 CMS content type. This attribute MUST be included as a signed, 284 authenticated, or authenticated/unprotected attribute. 286 o message-digest [RFC5652][RFC5911][RFC6268] is the message digest 287 of the encapsulated content calculated using the signer's message 288 digest algorithm. As specified in [RFC5652], it must be included 289 as a signed attribute and an authenticated attribute; as 290 specified in [RFC5652], it must not be an unsigned attribute, 291 unauthenticated attribute, or unprotected attribute; as specified 292 in [RFC5083], it should not be included as an 293 authenticated/unprotected attribute in AuthEnvelopedData. This 294 attribute MUST NOT be included elsewhere. 296 o content-hints [RFC2634][RFC5911][RFC6268] identifies the 297 innermost content when multiple layers of encapsulation have been 298 applied. Every instance of SignedData, AuthenticatedData, and 299 AuthEnvelopedData that does not directly encapsulate a 300 SymmetricKeyPackage, an AsymmetricKeyPackage, or an 301 EncryptedKeyPackage [RFC6032] MUST include this attribute. 303 3. Community Identifiers 305 The community-identifiers attribute, defined in [RFC4108][RFC5911], 306 lists the communities that are authorized recipients of the signed 307 content. It can appear as a signed, authenticated, 308 authenticated/unprotected, or content attribute. This attribute MUST 309 be supported. 311 The 2002 ASN.1 syntax for the community-identifier attribute is 312 included for convenience: 314 aa-communityIdentifiers ATTRIBUTE ::= { 315 TYPE CommunityIdentifiers 316 IDENTIFIED BY id-aa-communityIdentifiers } 318 id-aa-communityIdentifiers OBJECT IDENTIFIER ::= { 319 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 320 smime(16) aa(2) 40 } 322 CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier 324 CommunityIdentifier ::= CHOICE { 325 communityOID OBJECT IDENTIFIER, 326 hwModuleList HardwareModules } 328 HardwareModules ::= SEQUENCE { 329 hwType OBJECT IDENTIFIER, 330 hwSerialEntries SEQUENCE OF HardwareSerialEntry } 332 HardwareSerialEntry ::= CHOICE { 333 all NULL, 334 single OCTET STRING, 335 block SEQUENCE { 336 low OCTET STRING, 337 high OCTET STRING } } 339 Consult [RFC4108] for the attribute's semantics. 341 4. Key Province Attribute 343 The key-province-v2 attribute identifies the scope, range, or 344 jurisdiction in which the key is to be used. The key-province-v2 345 attribute MUST be present as a signed attribute or an authenticated 346 attribute in the innermost CMS protection content type that provides 347 authentication (i.e., SignedData, AuthEnvelopedData, or 348 AuthenticatedData) and encapsulates a symmetric key package or an 349 asymmetric key package. 351 The key-province attribute has the following syntax: 353 aa-keyProvince-v2 ATTRIBUTE ::= { 354 TYPE KeyProvinceV2 355 IDENTIFIED BY id-aa-KP-keyProvinceV2 } 357 id-aa-KP-keyProvinceV2 OBJECT IDENTIFIER ::= 358 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 359 dod(2) infosec(1) attributes(5) 71 } 361 KeyProvinceV2 ::= OBJECT IDENTIFIER 363 5. Binary Signing Time 365 The binary-signing-time attribute, defined in [RFC6019][RFC6268], 366 specifies the time at which the signature or the message 367 authentication code was applied to the encapsulated content. It can 368 appear as a signed, authenticated, or authenticated/unprotected 369 attribute. 371 The 2002 ASN.1 syntax is included for convenience: 373 aa-binarySigningTime ATTRIBUTE ::= { 374 TYPE BinarySigningTime 375 IDENTIFIED BY id-aa-binarySigningTime } 377 id-aa-binarySigningTime OBJECT IDENTIFIER ::= { 378 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 379 smime(16) aa(2) 46 } 381 BinarySigningTime ::= BinaryTime 383 BinaryTime ::= INTEGER (0..MAX) 385 Consult [RFC6019] for the binary-signing-time attribute's semantics. 387 6. Manifest 389 The manifest attribute lists the short titles of all the Transmission 390 Security Nomenclature (TSEC-Nomenclature) attributes from inner key 391 packages. It MUST only appear as an outer-most signed, 392 authenticated, or authenticated/unprotected attribute. If a short 393 title is repeated in inner packages, it need only appear once in the 394 manifest attribute. The manifest attribute MUST NOT appear in the 395 same level as the TSEC-Nomenclature from the Section 10. 397 The manifest attribute has the following syntax: 399 aa-manifest ATTRIBUTE ::= { 400 TYPE Manifest 401 IDENTIFIED BY id-aa-KP-manifest } 403 id-aa-KP-manifest OBJECT IDENTIFIER ::= { 404 joint-iso-itu-t(2) country(16) us(840) organization(1) 405 gov(101) dod(2) infosec(1) attributes(5) 72 } 407 Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle 409 7. Key Algorithm 411 The key-algorithm attribute indirectly specifies the size and format 412 of the keying material in the skey field of a symmetric key package, 413 which is defined in [RFC6031]. It can appear as a symmetric key, 414 symmetric key package, signed, authenticated, 415 authenticated/unprotected, or content attribute. If this attribute 416 appears as a signed attribute, then all of the keying material within 417 the SignedData content MUST be associated with the same algorithm. 418 If this attribute appears as an authenticated or 419 authenticated/unprotected attribute, then all of the keying material 420 within the AuthenticatedData or AuthEnvelopedData content type MUST 421 be associated with the same algorithm. If this attribute appears as 422 a content attribute, then all of the keying material within the 423 collection MUST be associated with the same algorithm. If both the 424 key-algorithm and key-wrap-algorithm attributes apply from the 425 Section 24 to an sKey, then the key-algorithm attribute refers to the 426 decrypted value of sKey rather than to the content of sKey itself. 427 This attribute MUST be supported. 429 The key-algorithm attribute has the following syntax: 431 aa-keyAlgorithm ATTRIBUTE ::= { 432 TYPE KeyAlgorithm 433 IDENTIFIED BY id-kma-keyAlgorithm } 435 id-kma-keyAlgorithm OBJECT IDENTIFIER ::= { 436 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 437 dod(2) infosec(1) keying-material-attributes(13) 1 } 439 KeyAlgorithm ::= SEQUENCE { 440 keyAlg OBJECT IDENTIFIER, 441 checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL, 442 crcAlg [2] OBJECT IDENTIFIER OPTIONAL } 444 The fields in the key-algorithm attribute have the following 445 semantics: 447 o keyAlg specifies the size and format of the keying material. 449 o If the particular key format supports more than one check word 450 algorithm, then the OPTIONAL checkWordAlg identifier indicates 451 which check word algorithm was used to generate the check word 452 that is present. If the check word algorithm is implied by the 453 key algorithm, then the checkWordAlg field SHOULD be omitted. 455 o If the particular key format supports more than one Cyclic 456 Redundancy Check (CRC) algorithm, then the OPTIONAL crcAlg 457 identifier indicates which CRC algorithm was used to generate the 458 value that is present. If the CRC algorithm is implied by the 459 key algorithm, then the crcAlg field SHOULD be omitted. 461 The keyAlg identifier, the checkWordAlg identifier, and the crcAlg 462 identifier are object identifiers. The use of an object identifier 463 accommodates any algorithm from any registry. 465 The format of the keying material in the skey field of a symmetric 466 key package will not match this attribute if the keying material is 467 split (see section 18 for a discussion on the split-identifier 468 attribute). In this situation, this attribute identifies the format 469 of the keying material once the two splits are combined. 471 Due to multiple layers of encapsulation or the use of content 472 collections, the key-algorithm attribute can appear in more than one 473 location in the overall key package. When there are multiple 474 occurrences of the key-algorithm attribute within the same scope, the 475 keyAlg field MUST match in all instances. The OPTIONAL checkWordAlg 476 and crcAlg fields can be omitted in the key-algorithm attribute when 477 it appears as a signed, authenticated, authenticated/unprotected, or 478 content attribute. However, if these optional fields are present, 479 they MUST also match the other occurrences within the same scope. 480 Receivers MUST reject any key package that fails these consistency 481 checks. 483 8. User Certificate 485 The user-certificate attribute specifies the type, format, and value 486 of an X.509 certificate and is used in asymmetric key package's 487 attributes field. This attribute can appear as an asymmetric key 488 attribute. This attribute MUST NOT appear in an asymmetric key 489 package attributes field that includes the other-certificate-formats 490 attribute. Symmetric key packages do not contain any certificates, 491 so the user-certificate attribute MUST NOT appear in a symmetric key 492 package. The user-certificate attribute MUST NOT appear as a signed, 493 authenticated, authenticated/unprotected, or content attribute. This 494 attribute MUST be supported. 496 The syntax is taken from [X.509] but redefined using the ATTRIBUTE 497 CLASS from [RFC5911]. The user-certificate attribute has the 498 following syntax: 500 aa-userCertificate ATTRIBUTE ::= { 501 TYPE Certificate 502 EQUALITY MATCHING RULE certificateExactMatch 503 IDENTIFIED BY id-at-userCertificate } 505 id-at-userCertificate OBJECT IDENTIFIER ::= { 506 joint-iso-itu-t(2) ds(5) attributes(4) 36 } 508 Since the user-certificate attribute MUST NOT appear as a signed, 509 authenticated, authenticated/unprotected, or content attribute, an 510 asymmetric key package cannot include multiple occurrences of the 511 user-certificate attribute within the same scope. Receivers MUST 512 reject any asymmetric key package in which the user-certificate 513 attribute appears as a signed, authenticated, 514 authenticated/unprotected, or content attribute. 516 9. Key Package Receivers 518 The key-package-receivers-v2 attribute indicates the intended 519 audience for the key package. The key-package-receivers-v2 attribute 520 is not intended for access control decisions, rather intermediate 521 systems may use this attribute to make routing and relaying 522 decisions. If the receiver is not listed, it will not be able to 523 decrypt the package, therefore the receiver SHOULD reject the key 524 package if the key-package-receivers-v2 attribute is present and they 525 are not listed as an intended receiver. The key-package-receivers-v2 526 attribute can be used as a signed, authenticated, 527 authenticated/unprotected, or content attribute. If key-package- 528 receivers-v2 attribute is associated with a collection, then the 529 named receivers MUST be able to receive all of the key packages 530 within the collection. This attribute MUST be supported. 532 The key-package-receivers-v2 attribute has the following syntax: 534 aa-keyPackageReceivers-v2 ATTRIBUTE ::= { 535 TYPE KeyPkgReceiversV2 536 IDENTIFIED BY id-kma-keyPkgReceiversV2 } 538 id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= { 539 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 540 dod(2) infosec(1) keying-material-attributes(13) 16 } 542 KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver 544 KeyPkgReceiver ::= CHOICE { 545 sirEntity [0] SIREntityName, 546 community [1] CommunityIdentifier } 548 The key-package-receivers-v2 attribute contains a list of receiver 549 identifiers. The receiver identifier is either a SIREntityName 550 [RFC7191] or a CommunityIdentifier (see Section 3). The 551 SIREntityName syntax does not impose any particular structure on the 552 receiver identifier, but it does require registration of receiver 553 identifier types. The nameType ensures that two receiver identifiers 554 of different types that contain the same values are not interpreted 555 as equivalent. Name types are expected to be defined that represent 556 several different granularities. For example, one name type will 557 represent the receiver organization. At a finer granularity, the 558 name type will identify a specific cryptographic device, perhaps 559 using a manufacturer identifier and serial number. 561 If a receiver does not recognize a particular nameType or a community 562 identifier, then keying material within the scope of the unrecognized 563 nameType or community identifier MUST NOT be used in any manner. 564 However, the receiver need not discard the associated key package. 565 Since many cryptographic devices are programmable, a different 566 firmware load may recognize the nameType. Likewise, a change in the 567 configuration may lead to the recognition of a previously 568 unrecognized community identifier. Therefore, the receiver may 569 retain the key package, but refuse to use it for anything with a 570 firmware load that does not recognize the nameType or a configuration 571 that does not recognize the community identifier. 573 Whenever a key package is saved for later processing due to an 574 unrecognized nameType or community identifier, subsequent processing 575 MUST NOT rely on any checks that were made the first time the key 576 package processing was attempted. That is, the subsequent processing 577 MUST include the full complement of checks. Further, a receipt for 578 the packages MUST NOT be generated unless all of these checks are 579 successfully completed. 581 Due to multiple layers of encapsulation or the use of content 582 collections, the key-package-receivers-v2 attribute can appear in 583 more than one location in the overall key package. When there are 584 multiple occurrences of the key-package-receivers-v2 attribute, each 585 occurrence is evaluated independently. 587 In a content collection, each member of the collection might contain 588 its own signed, authenticated, authenticated/unprotected, or content 589 attribute that includes a key-package-receivers-v2 attribute. In 590 this situation, each member of the collection is evaluated 591 separately, and any member that includes an acceptable receiver 592 SHOULD be retained. Other members can be rejected or retained for 593 later processing with a different firmware load. 595 10. TSEC Nomenclature 597 The Telecommunications Security Nomenclature (TSEC-Nomenclature) 598 attribute provides the name for a piece of keying material, which 599 always includes a printable string called a "short title" (see 600 below). The TSEC-Nomenclature attribute also contains other 601 identifiers when the shortTitle is insufficient to uniquely name a 602 particular piece of keying material. This attribute can appear as a 603 symmetric key, symmetric key package, asymmetric key, signed, 604 authenticated, authenticated/unprotected, or content attribute. If 605 this attribute appears in the sKeyAttrs field, the editionID, 606 registerID, and segmentID attribute fields MUST NOT be ranges. If 607 this attribute appears as a signed, authenticated, 608 authenticated/unprotected, or content attribute, all of the keying 609 material within the associated content MUST have the same shortTitle, 610 and the attribute value MUST contain only a shortTitle. That is, 611 when this attribute appears as a signed, authenticated, 612 authenticated/unprotected, or content attribute, all of the optional 613 fields MUST be absent. If this attribute is associated with a 614 collection, all of the keying material within the collection MUST 615 have the same shortTitle; however, the editionID, registerID, and 616 segmentID will be different for each key package in the collection. 617 This attribute MUST be supported. 619 The TSEC-Nomenclature attribute has the following syntax: 621 aa-tsecNomenclature ATTRIBUTE ::= { 622 TYPE TSECNomenclature 623 IDENTIFIED BY id-kma-TSECNomenclature } 625 id-kma-TSECNomenclature OBJECT IDENTIFIER ::= { 626 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 627 dod(2) infosec(1) keying-material-attributes(13) 3 } 629 TSECNomenclature ::= SEQUENCE { 630 shortTitle ShortTitle, 631 editionID EditionID OPTIONAL, 632 registerID RegisterID OPTIONAL, 633 segmentID SegmentID OPTIONAL } 635 ShortTitle ::= PrintableString 637 EditionID ::= CHOICE { 638 char CHOICE { 639 charEdition [1] CharEdition, 640 charEditionRange [2] CharEditionRange } 641 num CHOICE { 642 numEdition [3] NumEdition, 643 numEditionRange [4] NumEditionRange } } 645 CharEdition ::= PrintableString 647 CharEditionRange ::= SEQUENCE { 648 firstCharEdition CharEdition, 649 lastCharEdition CharEdition } 651 NumEdition ::= INTEGER (0..308915776) 653 NumEditionRange ::= SEQUENCE { 654 firstNumEdition NumEdition, 655 lastNumEdition NumEdition } 657 RegisterID ::= CHOICE { 658 register [5] Register, 659 registerRange [6] RegisterRange } 661 Register ::= INTEGER (0..2147483647) 663 RegisterRange ::= SEQUENCE { 664 firstRegister Register, 665 lastRegister Register } 667 SegmentID ::= CHOICE { 668 segmentNumber [7] SegmentNumber, 669 segmentRange [8] SegmentRange } 671 SegmentNumber ::= INTEGER (1..127) 673 SegmentRange ::= SEQUENCE { 674 firstSegment SegmentNumber, 675 lastSegment SegmentNumber } 677 The fields in the TSEC-Nomenclature attribute have the following 678 semantics: 680 o The shortTitle consists of up to 32 alphanumeric characters. 681 shortTitle processing always uses the value in its entirety. 683 o The editionID is OPTIONAL, and the editionIdentifier is used to 684 distinguish accountable items. The editionID consists either of 685 six alphanumeric characters or an integer. When present, the 686 editionID is either a single value or a range. The integer 687 encoding should be used when it is important to keep key package 688 size to a minimum. 690 o The registerID is OPTIONAL. For electronic keying material, the 691 registerID is usually omitted. The registerID is an accounting 692 number assigned to identify COMSEC material. The registerID is 693 either a single value or a range. 695 o The segmentID is OPTIONAL, and it distinguishes the individual 696 symmetric keys delivered in one edition. A unique segmentNumber 697 is assigned to each key in an edition. The segmentNumber is set 698 to one for the first item in each edition, and it is incremented 699 by one for each additional item within that edition. The 700 segmentID is either a single value or a range. 702 The order that the keying material will appear in the key package is 703 illustrated by the following example: a cryptographic device may 704 require fresh keying material every day, an edition represents the 705 keying material for a single month, and the segments represent the 706 keying material for a day within that month. Consider a key package 707 that contains the keying material for July and August; it will 708 contain keying material for 62 days. The keying material will appear 709 in the following order: Edition 1, Segment 1; Edition 1, Segment 2; 710 Edition 1, Segment 3; ...; Edition 1, Segment 31; Edition 2, Segment 711 1; Edition 2, Segment 2; Edition 2, Segment 3; ...; Edition 2, 712 Segment 31. 714 Due to multiple layers of encapsulation or the use of content 715 collections, the TSEC-Nomenclature attribute can appear in more than 716 one location in the overall key package. When there are multiple 717 occurrences of the TSEC-Nomenclature attribute within the same scope, 718 the shortTitle field MUST match in all instances. Receivers MUST 719 reject any key package that fails these consistency checks. 721 When the manifest attribute from Section 6 is included in an outer 722 layer, the ShortTitle field values present in TSEC-Nomenclature 723 attributes MUST be one of the values in the manifest attribute. 724 Receivers MUST reject any key package that fails this consistency 725 checks. 727 11. Key Purpose 729 The key-purpose attribute specifies the intended purpose of the key 730 material. It can appear as a symmetric key, symmetric key package, 731 asymmetric key, signed, authenticated, authenticated/unprotected, or 732 content attribute. If the key-purpose attribute appears as a signed, 733 authenticated, authenticated/unprotected, or content attribute, then 734 all of the keying material within the associated content MUST have 735 the same key purpose value. 737 The key-purpose attribute has the following syntax: 739 aa-keyPurpose ATTRIBUTE ::= { 740 TYPE KeyPurpose 741 IDENTIFIED BY id-kma-keyPurpose } 743 id-kma-keyPurpose OBJECT IDENTIFIER ::= { 744 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 745 dod(2) infosec(1) keying-material-attributes(13) 13 } 747 KeyPurpose ::= ENUMERATED { 748 n-a (0), -- Not Applicable 749 A (65), -- Operational 750 B (66), -- Compatible Multiple Key 751 L (76), -- Logistics Combinations 752 M (77), -- Maintenance 753 R (82), -- Reference 754 S (83), -- Sample 755 T (84), -- Training 756 V (86), -- Developmental 757 X (88), -- Exercise 758 Z (90), -- "On the Air" Testing 759 ... -- Expect additional key purpose values -- } 761 Due to multiple layers of encapsulation or the use of content 762 collections, the key-purpose attribute can appear in more than one 763 location in the overall key package. When there are multiple 764 occurrences of the key-purpose attribute within the same scope, all 765 fields within the attribute MUST contain exactly the same values. 766 Receivers MUST reject any key package that fails these consistency 767 checks. 769 12. Key Use 771 The key-use attribute specifies the intended use of the key material. 772 It can appear as a symmetric key, symmetric key package, asymmetric, 774 signed, authenticated, authenticated/unprotected, or content 775 attribute. If the key-use attribute appears as a signed, 776 authenticated, authenticated/unprotected, or content attribute, then 777 all of the keying material within the associated content MUST have 778 the same key use value. 780 The key-use attribute has the following syntax: 782 aa-key-Use ATTRIBUTE ::= { 783 TYPE KeyUse 784 IDENTIFIED BY id-kma-keyUse } 786 id-kma-keyUse OBJECT IDENTIFIER ::= { 787 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 788 dod(2) infosec(1) keying-material-attributes(13) 14 } 790 KeyUse ::= ENUMERATED { 791 n-a (0), -- Not applicable 792 ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format) 793 kek (2), -- Key Encryption Key 794 kpk (3), -- Key Production Key 795 msk (4), -- Message Signature Key 796 qkek (5), -- QUADRANT Key Encryption Key 797 tek (6), -- Traffic Encryption Key 798 tsk (7), -- Transmission Security Key 799 trkek (8), -- Transfer Key Encryption Key 800 nfk (9), -- Netted FIREFLY Key 801 effk (10), -- FIREFLY Key (Enhanced Format) 802 ebfk (11), -- FIREFLY Key (Enhanceable Basic Format) 803 aek (12), -- Algorithm Encryption Key 804 wod (13), -- Word of Day 805 kesk (246), -- Key Establishment Key 806 eik (247), -- Entity Identification Key 807 ask (248), -- Authority Signature Key 808 kmk (249), -- Key Modifier Key 809 rsk (250), -- Revocation Signature Key 810 csk (251), -- Certificate Signature Key 811 sak (252), -- Symmetric Authentication Key 812 rgk (253), -- Random Generation Key 813 cek (254), -- Certificate Encryption Key 814 exk (255), -- Exclusion Key 815 ... -- Expect additional key use values -- } 817 The values for the key-use attribute has the following semantics: 819 o ffk: A FIREFLY/CROSSTALK key is used to establish a Key 820 Establishment Key (KEK) or a Transmission Encryption Key (TEK) 821 between two parties. The KEK or TEK generated from the exchange 822 is used with a symmetric encryption algorithm. This key use 823 value is associated with keys in the basic format. 825 o kek: A Key Encryption Key is used to encrypt or decrypt other 826 keys for transmission or storage. 828 o kpk: A Key Production Key is used to initialize a keystream 829 generator for the production of other electronically generated 830 keys. 832 o msk: A Message Signature Key is used in a digital signature 833 process that operates on a message to assure message source 834 authentication, message integrity, and non-repudiation. 836 o qkek: QUADRANT Key Encryption Key is one part of a tamper 837 resistance solution. 839 o tek: A Traffic Encryption Key is used to encrypt plaintext or to 840 superencrypt previously encrypted data and/or to decrypt 841 ciphertext. 843 o tsk: A Transmission Security Key is used to protect transmissions 844 from interception and exploitation by means other than 845 cryptanalysis. 847 o trkek: Transfer Key Encryption Key. For example, the keys used 848 by the KP and DTD. 850 o nfk: A Netted FIREFLY Key is a FIREFLY key that has an edition 851 number associated with it. When rekeyed, it is incremented, 852 preventing communications with FIREFLY key of previous editions. 853 This edition number is maintained within a universal edition. 855 o effk: Enhanced FIREFLY Key is used to establish a KEK or a TEK 856 between two parties. The KEK or TEK generated from an exchange 857 is used with a symmetric encryption algorithm. This key use 858 value is associated with keys in the enhanced format. 860 o ebfk: Enhanceable Basic FIREFLY Key is used to establish a KEK or 861 a TEK between two parties. The KEK or TEK generated from an 862 exchange is used with a symmetric encryption algorithm. This key 863 use value is associated with keys in the enhanceable basic 864 format. 866 o aek: An Algorithm Encryption Key is used to encrypt or decrypt an 867 algorithm implementation as well as other functionality in the 868 implementation. 870 o wod: A key used to generate the Word of the Day (WOD). 872 o kek: A Key Establishment Key is an asymmetric key set (e.g. 873 public/private/parameters) used to enable the establishment of 874 symmetric key(s) between entities. 876 o eik: An Entity Identification Key is an asymmetric key set (e.g. 877 public/private/parameters) used to identify one entity to another 878 for access control and other similar purposes. 880 o ask: An Authority Signature Key is an asymmetric key set (e.g. 881 public/private/parameters) used by designated authorities to sign 882 objects such as TAMP messages and firmware packages. 884 o kmk: A Key Modifier Key is a symmetric key used to modify the 885 results of the process that forms a symmetric key from a public 886 key exchange process. 888 o rsk: A Revocation Signature Key is an asymmetric key set (e.g. 889 public/private/parameters) used to sign and authenticate 890 revocation lists and compromised key lists. 892 o csk: A Certificate Signature Key is an asymmetric key set (e.g. 893 public/private/parameters) used to sign and authenticate public- 894 key certificates. 896 o sak: A Symmetric Authentication Key is used in a Message 897 Authentication Code (MAC) algorithm to provide message integrity. 898 Differs from a Message Signature Key in that it is symmetric key 899 material and it does not provide source authentication or non- 900 repudiation. 902 o rgk: Random Generation Key is a key used to seed a deterministic 903 pseudo-random number generator. 905 o cek: A Certificate Encryption Key is used to encrypt public-key 906 certificates to support privacy. 908 o exk: An Exclusion Key is a symmetric key used to 909 cryptographically subdivide a single large security domain into 910 smaller segregated domains. 912 Due to multiple layers of encapsulation or the use of content 913 collections, the key-use attribute can appear in more than one 914 location in the overall key package. When there are multiple 915 occurrences of the key-use attribute within the same scope, all 916 fields within the attribute MUST contain exactly the same values. 917 Receivers MUST reject any key package that fails these consistency 918 checks. 920 13. Transport Key 922 The transport-key attribute identifies whether an asymmetric key is a 923 transport key or an operational key (i.e., the key can either be used 924 as is or not). It can appear as an asymmetric key, signed, 925 authenticated, authenticated/unprotected, or content attribute. If 926 the transport-key attribute appears as a signed, authenticated, 927 authenticated/unprotected, or content attribute, then all of the 928 keying material within the associated content MUST have the same 929 operational/transport key material. 931 aa-transportKey ATTRIBUTE ::= { 932 TYPE TransOp 933 IDENTIFIED BY id-kma-transportKey } 935 id-kma-transportKey OBJECT IDENTIFIER ::= { 936 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 937 dod(2) infosec(1) keying-material-attributes(13) 15 } 939 TransOp ::= ENUMERATED { 940 transport (1), 941 operational (2) } 943 Due to multiple layers of encapsulation or the use of content 944 collections, the transport-key attribute can appear in more than one 945 location in the overall key package. When there are multiple 946 occurrences of the transport-key attribute within the same scope, all 947 fields within the attribute MUST contain exactly the same values. 948 Receivers MUST reject any key package that fails these consistency 949 checks. 951 14. Key Distribution Period 953 The key-distribution-period attribute indicates the period of time 954 that the keying material is intended for distribution. Keying 955 material is often distributed before it is intended to be used. Time 956 of day must be represented in Coordinated Universal Time (UTC). It 957 can appear as a symmetric key, symmetric key package, asymmetric key, 958 signed, authenticated, authenticated/unprotected, or content 959 attribute. If the key-distribution-period attribute appears as a 960 signed, authenticated, authenticated/unprotected, or content 961 attribute, then all of the keying material within the content MUST 962 have the same key distribution period. 964 The key-distribution-period attribute has the following syntax: 966 aa-keyDistributionPeriod ATTRIBUTE ::= { 967 TYPE KeyDistPeriod 968 IDENTIFIED BY id-kma-keyDistPeriod } 970 id-kma-keyDistPeriod OBJECT IDENTIFIER ::= { 971 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 972 dod(2) infosec(1) keying-material-attributes(13) 5 } 974 KeyDistPeriod ::= SEQUENCE { 975 doNotDistBefore [0] BinaryTime OPTIONAL, 976 doNotDistAfter BinaryTime } 978 BinaryTime ::= INTEGER 980 The fields in the key-distribution-period attribute have the 981 following semantics: 983 o The doNotDistBefore field is OPTIONAL, and when it is present, 984 the keying material SHOULD NOT be distributed before the date and 985 time provided. 987 o The doNotDistAfter field is REQUIRED, and the keying material 988 SHOULD NOT be distributed after the date and time provided. 990 When the key-distribution-period attribute is associated with a 991 collection of keying material, the distribution period applies to all 992 of the keys in the collection. None of the keying material in the 993 collection SHOULD be distributed outside the indicated period. 995 Due to multiple layers of encapsulation or the use of content 996 collections, the key-distribution-period attribute can appear in more 997 than one location in the overall key package. When there are 998 multiple occurrences of the key-distribution-period attribute within 999 the same scope, all of the included attribute fields MUST contain 1000 exactly the same value. However, if the doNotDistBefore field is 1001 absent in an inner layer, a value MAY appear in an outer layer 1002 because the outer layer constrains the inner layer. Receivers MUST 1003 reject any key package that fails these consistency checks. 1005 15. Key Validity Period 1007 The key-validity-period attribute indicates the period of time that 1008 the keying material is intended for use. Time of day MUST be 1009 represented in Coordinated Universal Time (UTC). It can appear as a 1010 symmetric key, symmetric key package, asymmetric key, signed, 1011 authenticated, authenticated/unprotected, or content attribute. If 1012 the key-validity-period attribute appears as a signed, authenticated, 1013 authenticated/unprotected, or content attribute, then all of the 1014 keying material within the content MUST have the same key validity 1015 period. 1017 The key-validity-period attribute has the following syntax: 1019 aa-keyValidityPeriod ATTRIBUTE ::= { 1020 TYPE KeyValidityPeriod 1021 IDENTIFIED BY id-kma-keyValidityPeriod } 1023 id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= { 1024 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1025 dod(2) infosec(1) keying-material-attributes(13) 6 } 1027 KeyValidityPeriod ::= SEQUENCE { 1028 doNotUseBefore BinaryTime, 1029 doNotUseAfter BinaryTime OPTIONAL } 1031 BinaryTime ::= INTEGER 1033 The fields in the key-validity-period attribute have the following 1034 semantics: 1036 o The doNotUseBefore field is required, and the keying material 1037 should not be used before the date and time provided. 1039 o The doNotUseAfter field is optional, and when it is present, the 1040 keying material should not be used after the date and time 1041 provided. 1043 For a key package that is being used for rekey, the doNotUseAfter 1044 field MAY be required by some templates even though the syntax is 1045 OPTIONAL. 1047 When the key-validity-period attribute is associated with a 1048 collection of keying material, the validity period applies to all of 1049 the keys in the collection. None of the keying material in the 1050 collection SHOULD be used outside the indicated period. 1052 The key-validity-period attribute described in this section and the 1053 key-duration attribute described in the next section provide a 1054 complementary function. The key-validity-period attribute provides 1055 explicit date and time values, which indicate the beginning and 1056 ending of the keying material usage period. The key-duration 1057 attribute provides the maximum length of time that the keying 1058 material SHOULD be used. If both attributes are provided, this 1059 duration MAY occur at any time within the specified period, but the 1060 limits imposed by both attributes SHOULD be honored. 1062 Due to multiple layers of encapsulation or the use of content 1063 collections, the key-validity-period attribute can appear in more 1064 than one location in the overall key package. When there are 1065 multiple occurrences of the key-validity-period attribute within the 1066 same scope, all of the included attribute fields MUST contain exactly 1067 the same value. However, if the doNotUseAfter field is absent in an 1068 inner layer, a value MAY appear in an outer layer. Receivers MUST 1069 reject any key package that fails these consistency checks. 1071 16. Key Duration 1073 The key-duration attribute indicates the maximum period of time that 1074 the keying material is intended for use. The date and time that the 1075 duration begins is not specified, but the maximum amount of time that 1076 the keying material can be used to provide security services is 1077 specified. It can appear as a symmetric key, symmetric key package, 1078 asymmetric key, signed, authenticated, authenticated/unprotected, or 1079 content attribute. If the key-duration attribute appears as a 1080 signed, authenticated, authenticated/unprotected, or content 1081 attribute, then all of the keying material within the content MUST 1082 have the same key duration. 1084 The key-duration attribute has the following syntax: 1086 aa-keyDurationPeriod ATTRIBUTE ::= { 1087 TYPE KeyDuration 1088 IDENTIFIED BY id-kma-keyDuration } 1090 id-kma-keyDuration OBJECT IDENTIFIER ::= { 1091 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1092 dod(2) infosec(1) keying-material-attributes(13) 7 } 1094 KeyDuration ::= CHOICE { 1095 hours [0] INTEGER (1..ub-KeyDuration-hours), 1096 days INTEGER (1..ub-KeyDuration-days), 1097 weeks [1] INTEGER (1..ub-KeyDuration-weeks), 1098 months [2] INTEGER (1..ub-KeyDuration-months), 1099 years [3] INTEGER (1..ub-KeyDuration-years) } 1101 ub-KeyDuration-hours INTEGER ::= 96 1102 ub-KeyDuration-days INTEGER ::= 732 1103 ub-KeyDuration-weeks INTEGER ::= 104 1104 ub-KeyDuration-months INTEGER ::= 72 1105 ub-KeyDuration-years INTEGER ::= 100 1107 The key-validity-period attribute described in the previous section 1108 and the key-duration attribute described in this section provide a 1109 complementary function. The relationship between these attributes is 1110 described in the previous section. 1112 Due to multiple layers of encapsulation or the use of content 1113 collections, the key-duration attribute can appear in more than one 1114 location in the overall key package. When there are multiple 1115 occurrences of the key-duration attribute within the same scope, all 1116 of the included attribute fields MUST contain exactly the same value. 1117 Receivers MUST reject any key package that fails these consistency 1118 checks. 1120 17. Classification 1122 The classification attribute indicates level of classification. The 1123 classification attribute specifies the aggregate classification of 1124 the package content. It can appear as a symmetric key, symmetric key 1125 package, asymmetric key, signed, authenticated, 1126 authenticated/unprotected, or content attribute. If the 1127 classification attribute appears as a signed, authenticated, 1128 authenticated/unprotected, or content attribute, then the value MUST 1129 represent the classification of all of the keying material within the 1130 content. Encrypted layers MAY contain content at a higher 1131 classification that will be revealed once they are decrypted. If the 1132 classification attribute is associated with a collection, then the 1133 sensitivity of all the data within the collection MUST be dominated 1134 by the classification carried in this attribute. 1136 The classification attribute makes use of the ESSSecurityLabel 1137 defined in Section 17.1 and from [RFC2634][RFC5911]. The term 1138 "classification" is used in this document, but the term "security 1139 label" is used in [RFC2634]. The two terms have the same meaning. 1141 [RFC2634][RFC5911] specifies an object identifier and syntax for the 1142 security label attribute. The same values are used for the 1143 classification attribute: 1145 aa-classificationAttribute ATTRIBUTE ::= { 1146 TYPE Classification 1147 IDENTIFIED BY id-aa-KP-classification } 1149 id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel 1151 -- id-aa-securityLabel OBJECT IDENTIFIER ::= { 1152 -- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1153 -- pkcs-9(9) smime(16) id-aa(2) 2 } 1155 Classification ::= ESSSecurityLabel 1157 The syntax of ESSSecurityLabel is not repeated here; however, see 1158 section 17.1 for security label conventions that MUST be followed by 1159 implementations of this specification. See [RFC2634] for a complete 1160 discussion of the semantics and syntax. 1162 When the classification attribute appears in more than one location 1163 in the overall key package, each occurrence is evaluated 1164 independently. The content originator MUST ensure that the 1165 classification attribute represents the sensitivity of the plaintext 1166 within the content. That is, the classification MUST dominate any 1167 other plaintext classification attribute value that is present 1168 elsewhere in the overall key package. Note that the classification 1169 attribute value may exceed these other plaintext classification 1170 attribute values if the other attribute values within the SignerInfo, 1171 AuthEnvelopedData, or AuthenticatedData are themselves classified and 1172 warrant the higher security label value. 1174 When the classification attribute appears in more than one location 1175 in the overall key package, each security label might be associated 1176 with a different security policy. Content originators SHOULD avoid 1177 mixing multiple security policies in the same key package whenever 1178 possible since this requires that receivers and intermediaries that 1179 check the classification attribute values to include support for the 1180 union of the security policies that are present. Failure to 1181 recognize an included security policy MUST result in rejection of the 1182 key package. 1184 Receivers MUST reject any key package that includes a classification 1185 for which the receiver's processing environment is not authorized. 1187 17.1. Security Label 1189 The ESSSecurityLabel ASN.1 type is used to represent the 1190 classification. The ESSSecurityLabel is defined in Section 3.2 of 1191 [RFC2634]. 1193 The classification attribute values and classification attribute 1194 values have ASN.1 type ESSSecurityLabel, which is defined in 1195 [RFC2634]. The syntax definition is repeated here to facilitate 1196 discussion: 1198 ESSSecurityLabel ::= SET { 1199 security-policy-identifier SecurityPolicyIdentifier, 1200 security-classification SecurityClassification OPTIONAL, 1201 privacy-mark ESSPrivacyMark OPTIONAL, 1202 security-categories SecurityCategories OPTIONAL } 1204 ESSPrivacyMark ::= CHOICE { 1205 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 1206 utf8String UTF8String (SIZE (1..MAX)) } 1208 A security policy is a set of criteria for the provision of security 1209 services. The security-policy-identifier, which is an object 1210 identifier, is used to identify the security policy associated with 1211 the security label. It indicates the semantics of the other security 1212 label components. 1214 If the key package receiver does not recognize the object identifier 1215 in the security-policy-identifier field and the security label 1216 includes a security-categories field, then the key package contents 1217 MUST NOT be accepted and the enclosed keying material MUST NOT be 1218 used. If the key package receiver does not recognize the object 1219 identifier in the security-policy-identifier field and the security 1220 label does not include a security-categories field, then the key 1221 package contents MAY be accepted only if the security-classification 1222 field is present and it contains a value from the basic hierarchy as 1223 described below. 1225 This specification defines the use of the SecurityClassification 1226 field exactly as is it specified in the 1988 edition of ITU-T 1227 Recommendation X.411 [X.411], which states in part: 1229 "If present, a security-classification may have one of a 1230 hierarchical list of values. The basic security-classification 1231 hierarchy is defined in this Recommendation, but the use of these 1232 values is defined by the security-policy in force. Additional 1233 values of security-classification, and their position in the 1234 hierarchy, may also be defined by a security-policy as a local 1235 matter or by bilateral agreement. The basic security- 1236 classification hierarchy is, in ascending order: unmarked, 1237 unclassified, restricted, confidential, secret, top-secret." 1239 Implementations MUST support the basic security classification 1240 hierarchy. Such implementations MAY also support other security- 1241 classification values; however, the placement of additional values in 1242 the hierarchy MUST be specified by the security policy. 1244 Implementations MUST NOT make access control decisions based on the 1245 privacy-mark. However, information in the privacy-mark can be 1246 displayed to human users by devices that have displays to do so. The 1247 privacy-mark length MUST NOT exceed 128 characters. The privacy-mark 1248 SHALL use the PrintableString choice if all of the characters in the 1249 privacy mark are members of the printable string character set. 1251 If present, security-categories provide further granularity for the 1252 keying material. The security policy in force indicates the 1253 permitted syntaxes of any entries in the set of security categories. 1255 At most, 64 security categories may be present. The security- 1256 categories have ASN.1 type SecurityCategories and further 1257 SecurityCategory [RFC5912], which are both repeated here to 1258 facilitate discussion: 1260 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 1261 SecurityCategory 1262 {{SupportedSecurityCategories}} 1264 SecurityCategory {SECURITY-CATEGORY:Supported} ::= SEQUENCE { 1265 type [0] IMPLICIT SECURITY-CATEGORY. 1266 &id({Supported}), 1267 value [1] EXPLICIT SECURITY-CATEGORY. 1268 &Type({Supported}{@type}) 1269 } 1271 Four security categories are defined and are referred to as the 1272 Restrictive Tag, the Enumerated Tag, the Permissive Tag, and the 1273 Informative Tag. Only the Enumerated Tag and Informative Tag are 1274 permitted in the classification attribute. 1276 The Enumerated Tag is composed of one or more non-negative integers. 1277 Each non-negative integer represents a non-hierarchical security 1278 attribute that applies to the labeled content. Use of the integer 1279 representation is intended to minimize the size of the label since a 1280 particular key package generally contains only a few security 1281 categories attributes, even though a security policy might define a 1282 large set of security categories attributes. Security attributes 1283 enumerated by tags of this type could be restrictive (such as 1284 compartments) or permissive (such as release permissions). Two 1285 object identifiers for the SecurityCategory type field have been 1286 defined, one restrictive and one for permissive. The object 1287 identifiers are: 1289 id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= { 1290 2 16 840 1 101 2 1 8 3 4 } 1292 id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= { 1293 2 16 840 1 101 2 1 8 3 1 } 1295 With both the restrictive and permissive security category types, the 1296 corresponding SecurityCategory value has the following ASN.1 1297 definition: 1299 EnumeratedTag ::= SEQUENCE { 1300 tagName OBJECT IDENTIFIER, 1301 attributeList SET OF SecurityAttribute } 1303 SecurityAttribute ::= INTEGER (0..MAX) 1305 Any security policy that makes use of security categories MUST assign 1306 object identifiers for each tagName, assign the set of integer values 1307 associated with each tagName, and specify the semantic meaning for 1308 each integer value. Restrictive security attributes and permissive 1309 security attributes SHOULD be associated with different tagName 1310 object identifiers. 1312 The Informative Tag is composed of either one or more non-negative 1313 integers or a bit string. Only the integer choice is allowed in this 1314 specification. Each non-negative integer represents a non- 1315 hierarchical security attribute that applies to the labeled content. 1316 Use of the integer representation is intended to minimize the size of 1317 the label since a particular key package generally contains only a 1318 few security categories attributes, even though a security policy 1319 might define a large set of security categories attributes. Security 1320 attributes enumerated by tags of this type are informative (i.e., no 1321 access control is performed). One object identifier for the 1322 SecurityCategory type field has been defined and it is as follows: 1324 id-informativeAttributes OBJECT IDENTIFIER ::= { 1325 2 16 840 1 101 2 1 8 3 3 } 1327 The corresponding SecurityCategory value has the following ASN.1 1328 definition: 1330 InformativeTag ::= SEQUENCE { 1331 tagName OBJECT IDENTIFIER, 1332 attributes FreeFormField } 1334 FreeFormField ::= CHOICE { 1335 bitSetAttributes BIT STRING, 1336 securityAttributes SET OF SecurityAttribute } 1338 Any security policy that makes use of security categories MUST assign 1339 object identifiers for each tagName, assign the set of integer values 1340 associated with each tagName, and specify the semantic meaning for 1341 each integer value. 1343 18. Split Key Identifier 1345 The key package originator may include a split-identifier attribute 1346 to designate that the keying material contains a split rather than a 1347 complete key. It may appear as a symmetric and asymmetric key 1348 attribute. The split-identifier attribute MUST NOT appear as a 1349 symmetric key package, signed, authenticated, 1350 authenticated/unprotected, or content attribute. Split keys have two 1351 halves, which are called "A" and "B." The split-identifier attribute 1352 indicates which half is included in the key package, and it 1353 optionally indicates the algorithm that is needed to combine the two 1354 halves. The combine algorithm is OPTIONAL since each key algorithm 1355 has a default mechanism for this purpose, and the combine algorithm 1356 is present only if the default mechanism is not employed. 1358 The key-split-identifier attribute has the following syntax: 1360 aa-splitIdentifier ATTRIBUTE ::= { 1361 TYPE SplitID 1362 IDENTIFIED BY id-kma-splitID } 1364 id-kma-splitID OBJECT IDENTIFIER ::= { 1365 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1366 dod(2) infosec(1) keying-material-attributes(13) 11 } 1368 SplitID ::= SEQUENCE { 1369 ENUMERATED { a(0), b(1) }, 1370 combineAlg AlgorithmIdentifier 1371 {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL } 1373 In most cases the default combine algorithm will be employed, which 1374 makes this attribute a simple constant that identifies either the "A" 1375 or "B" half of the split key, which supports implementation of some 1376 key distribution policies. 1378 Note that each split might have its own CRC, but the key and the 1379 check word are both recovered when the two splits are combined. 1381 Since the split-identifier attribute MUST NOT appear as a signed, 1382 authenticated, authenticated/unprotected, or content attribute, a key 1383 package cannot include multiple occurrences of the split-identifier 1384 attribute within the same scope. Receivers MUST reject any key 1385 package in which the split-identifier attribute appears as a signed, 1386 authenticated, authenticated/unprotected, or content attribute. 1388 19. Key Package Type 1390 The key-package-type attribute is a shorthand method for specifying 1391 all aspects of the key package format, including which attributes are 1392 present and the structure of the encapsulated content or collection. 1393 The key-package-type attribute can be used as a signed, 1394 authenticated, authenticated/unprotected, or content attribute. 1396 Rather than implementing the full flexibility of this specification, 1397 some devices may implement support for one or more specific key 1398 package formats instantiating this specification. Those specific 1399 formats are called templates and can be identified using a key- 1400 package-type attribute. 1402 The key-package-type attribute has the following syntax: 1404 aa-keyPackageType ATTRIBUTE ::= { 1405 TYPE KeyPkgType 1406 IDENTIFIED BY id-kma-keyPkgType } 1408 id-kma-keyPkgType OBJECT IDENTIFIER ::= { 1409 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1410 dod(2) infosec(1) keying-material-attributes(13) 12 } 1412 KeyPkgType ::= OBJECT IDENTIFIER 1414 Due to multiple layers of encapsulation or the use of content 1415 collections, the key-package-type attribute can appear in more than 1416 one location in the overall key package. When there are multiple 1417 occurrences of the key-package-type attribute, each occurrence is 1418 used independently. Since the receiver is likely to use the key- 1419 package-type attribute value as a decoding aid, any error will most 1420 likely lead to parsing problems, and these problems could result in 1421 many different errors being reported. 1423 20. Signature Usage 1425 The signature-usage attribute identifies the CMS content types that 1426 this key can be used to sign, or be in the cert path for validation. 1427 Symmetric key packages do not contain signature generation or 1428 signature validation keying material, so the signature-usage 1429 attribute MUST NOT appear in a symmetric key package. For an 1430 asymmetric key package, the signature-usage attribute indicates the 1431 kind of objects that are to be signed with the private key in the 1432 package. However, if the asymmetric key package contains a 1433 Certificate Signature Key, then the signature-usage attribute also 1434 indicates what signed objects can be validated using certificates 1435 that are signed by the private key in the asymmetric key package. 1436 Therefore, the signature-usage attribute also indicates what kind of 1437 objects that can be signed by the private keys associated with these 1438 certificates. The signature-usage attribute MUST NOT appear as a 1439 signed, authenticated, authenticated/unprotected, or content 1440 attribute. 1442 The signature-usage attribute has the following syntax: 1444 aa-signatureUsage-v3 ATTRIBUTE ::= { 1445 TYPE SignatureUsage 1446 IDENTIFIED BY id-kma-sigUsageV3 } 1448 id-kma-sigUsageV3 OBJECT IDENTIFIER ::= { 1449 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1450 dod(2) infosec(1) keying-material-attributes(13) 22 } 1452 SignatureUsage ::= CMSContentConstraints 1454 The SignatureUsage structure has the same syntax as the 1455 CMSContentConstraints structure from [RFC6010], and it is repeated 1456 here for convenience. 1458 CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF 1459 ContentTypeConstraint 1461 ContentTypeGeneration ::= ENUMERATED { 1462 canSource(0), 1463 cannotSource(1)} 1465 ContentTypeConstraint ::= SEQUENCE { 1466 contentType CONTENT-TYPE.&id ({ContentSet|ct-Any,...}), 1467 canSource ContentTypeGeneration DEFAULT canSource, 1468 attrConstraints AttrConstraintList OPTIONAL } 1470 Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE { 1471 attrType ATTRIBUTE.&id({ConstraintList}), 1472 attrValues SET SIZE (1..MAX) OF ATTRIBUTE. 1473 &Type({ConstraintList}{@attrType}) } 1475 SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... } 1477 AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF 1478 Constraint {{ SupportedConstraints }} 1480 NOTE: SignedAttributesSet is updated by this specification. 1482 The SignatureUsage contains a type of CMSContentConstraints. One or 1483 more ContentTypeConstraint MUST appear in CMSContentConstraints. 1485 Within ContentTypeConstraint, the contentType field indicates the 1486 encapsulated content type identifier that can be signed with the 1487 signature key. A particular content type MUST NOT appear more than 1488 once in the list. The CMS protecting content types need not be 1489 included in the list of permitted content types as the use of CMS is 1490 always authorized (see [RFC6010]). 1492 Within ContentTypeConstraint, the canSource enumeration indicates 1493 whether the signature key can be used to directly sign the indicated 1494 content type. If the ContentTypeConstraint is canSource (the default 1495 value), then the signature key can be used to directly sign the 1496 specified content type. If the ContentTypeConstraint is 1497 cannotSource, then the signature key can only be used with the 1498 specified content type if it encapsulates a signature that was 1499 generated by an originator with a ContentTypeConstraint that is 1500 canSource. 1502 Within ContentTypeList, the attrConstraints OPTIONAL field contains a 1503 sequence of content type specific constraints. If the 1504 attrConstraints field is absent, the signature key can be used to 1505 sign the specified content type, without any further checking. If 1506 the either the attrConstraints field is present, then the signature 1507 key can only be used to sign the specified content type if all of the 1508 constraints for that content type are satisfied. Content type 1509 constraints are checked by matching the attribute values in the 1510 attrConstraint field against the attribute value in the content. The 1511 constraints succeed if the attribute is not present; they fail if the 1512 attribute is present and the value is not one of the values provided 1513 in attrConstraint. 1515 The fields of attrConstraints implement content type-specific 1516 constraints. The attrType field is an AttributeType, which is an 1517 object identifier of a signed attribute carried in the SignerInfo of 1518 the content. The attrValues field provides one or more acceptable 1519 signed attribute values. It is a set of AttributeValue. For a 1520 signed content to satisfy the constraint, the SignerInfo MUST include 1521 a signed attribute of the type identified in the attrType field, and 1522 the signed attribute MUST contain one of the values in the set 1523 carried in attrValues. 1525 Since the signature-usage attribute MUST NOT appear as a signed, 1526 authenticated, authenticated/unprotected, or content attribute, an 1527 asymmetric key package cannot include multiple occurrences of the 1528 signature-usage attribute within the same scope. Receivers MUST 1529 reject any asymmetric key package in which the signature-usage 1530 attribute appears as a signed, authenticated, 1531 authenticated/unprotected, or content attribute. 1533 21. Other Certificate Format 1535 The other-certificate-formats attribute specifies the type, format, 1536 and value of certificates that are not X.509 public key certificates. 1537 Symmetric key packages do not contain any certificates, so the 1538 other-certificate-formats attribute MUST NOT appear in a symmetric 1539 key package. It SHOULD appear in the attributes field, when the 1540 publicKey field is absent and the certificate format is not X.509. 1541 This attribute MUST NOT appear in an attributes field that includes 1542 the user-certificate attribute from Section 8. The other- 1543 certificate-formats attribute MUST NOT appear as a signed, 1544 authenticated, authenticated/unprotected, or content attribute. 1546 The other-certificate-formats attribute has the following syntax: 1548 aa-otherCertificateFormats ATTRIBUTE ::= { 1549 TYPE CertificateChoices 1550 IDENTIFIED BY id-kma-otherCertFormats } 1552 id-kma-otherCertFormats OBJECT IDENTIFIER ::= { 1553 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1554 dod(2) infosec(1) keying-material-attributes(13) 19 } 1556 CertificateChoices ::= CHOICE { 1557 certificate Certificate, 1558 extendedCertificate [0] IMPLICIT ExtendedCertificate, 1559 -- Obsolete 1560 v1AttrCert [1] IMPLICIT AttributeCertificateV1, 1561 -- Obsolete 1562 v2AttrCert [2] IMPLICIT AttributeCertificateV2, 1563 other [3] IMPLICIT OtherCertificateFormat } 1565 OtherCertificateFormat ::= SEQUENCE { 1566 otherCertFormat OBJECT IDENTIFIER, 1567 otherCert ANY DEFINED BY otherCertFormat } 1569 The other-certificate-formats attribute makes use of the 1570 CertificateChoices field defined in Section 10.2.2 of [RFC5652]. The 1571 certificate, extendedCertificate, and v1AttrCert fields MUST be 1572 omitted. The v2AttrCert field can include Version 2 Attribute 1573 Certificates. The other field can include EFF certificates and other 1574 as-yet undefined certificate formats. 1576 Since the other-certificate-formats attribute MUST NOT appear as a 1577 signed, authenticated, authenticated/unprotected, or content 1578 attribute, an asymmetric key package cannot include multiple 1579 occurrences of the other-certificate-formats attribute within the 1580 same scope. Receivers MUST reject any asymmetric key package in 1581 which the other-certificate-formats attribute appears as a signed, 1582 authenticated, authenticated/unprotected, or content attribute. 1584 22. PKI Path 1586 The pki-path attribute includes certificates that can aid in the 1587 validation of the certificate carried in the user-certificate 1588 attribute. Symmetric key packages do not contain any certificates, 1589 so the pkiPath attribute MUST NOT appear in a symmetric key package. 1590 It can appear as an asymmetric key, signed, authenticated, 1591 authenticated/unprotected, or content attribute. It can appear in 1592 the attributes field, when the publicKey field is absent and the 1593 certificate format is X.509. This attribute MUST NOT appear in an 1594 AsymmetricKeyPackage that has an other-certificate-formats attribute 1595 in the attributes field. If the pki-path attribute appears as a 1596 signed, authenticated, authenticated/unprotected, or content 1597 attribute, then the value includes certificates that can be used to 1598 construct certification path to all of the keying material within the 1599 content. This attribute MUST be supported. 1601 The syntax is taken from [X.509] but redefined using the ATTRIBUTE 1602 CLASS from [RFC5911]. The pki-path attribute has the following 1603 syntax: 1605 aa-pkiPath ATTRIBUTE ::= { 1606 TYPE PkiPath 1607 IDENTIFIED BY id-at-pkiPath } 1609 id-at-pkiPath OBJECT IDENTIFIER ::= { 1610 joint-iso-itu-t(2) ds(5) attributes(4) 70 } 1612 PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate 1614 The first certificate in the sequence is the subject's parent 1615 Certification Authority (CA). The next certificate is that CA's 1616 parent, and so on. The end-entity and Trust Anchor are not included 1617 in this attribute. 1619 Due to multiple layers of encapsulation or the use of content 1620 collections, the pki-path attribute can appear in more than one 1621 location in the overall key package. When the pki-path attribute 1622 appears in more than one location in the overall key package, each 1623 occurrence is evaluated independently. 1625 23. Useful Certificates 1627 The useful-certificates attribute includes certificates that can aid 1628 in the validation of certificates associated with other parties with 1629 whom secure communications are anticipated. It can appear as an 1630 asymmetric key, signed, authenticated, authenticated/unprotected, or 1631 content attribute. For an asymmetric key that has an other- 1632 certificate-formats attribute from Section 21 in the attributes 1633 field, the useful-certificates attribute MUST NOT appear. If the 1634 useful-certificates attribute appears as a signed, authenticated, 1635 authenticated/unprotected, or content attribute, then the value 1636 includes certificates that may be used to validate certificate of 1637 others the receiver communicates with. This attribute MUST be 1638 supported. 1640 The useful-certificates attribute has the following syntax: 1642 aa-usefulCertificates ATTRIBUTE ::= { 1643 TYPE CertificateSet 1644 IDENTIFIED BY id-kma-usefulCerts } 1646 id-kma-usefulCerts OBJECT IDENTIFIER ::= { 1647 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1648 dod(2) infosec(1) keying-material-attributes(13) 20 } 1650 CertificateSet ::= SET OF CertificateChoices 1652 The useful-certificates attribute makes use of the CertificateSet 1653 field defined in Section 10.2.3 of [RFC5652]. Within the 1654 CertificateChoices field, the extendedCertificate and v1AttrCert 1655 fields MUST always be omitted. If the userCertificate attribute from 1656 Section 8 is included, the other field MUST NOT be present. If the 1657 other-certificate-formats attribute from Section 21 is included, the 1658 certificate field MUST NOT be present. 1660 Due to multiple layers of encapsulation or the use of content 1661 collections, the useful-certificates attribute can appear in more 1662 than one location in the overall key package. When the useful- 1663 certificates attribute appears in more than one location in the 1664 overall key package, each occurrence is evaluated independently. 1666 24. Key Wrap Algorithm 1668 The key-wrap-algorithm attribute identifies a key wrap algorithm with 1669 an algorithm identifier. It can appear as a symmetric key or 1670 symmetric key package attribute. When this attribute is present in 1671 sKeyAttrs, it indicates that the associated sKey field contains a 1672 black key, which is an encrypted key, that that was wrapped by the 1673 identified algorithm. When this attribute is present in 1674 sKeyPkgAttrs, it indicates that every sKey field in that symmetric 1675 key package contains a black key, and that all keys are wrapped by 1676 the same designated algorithm. 1678 The key-wrap-algorithm attribute has the following syntax: 1680 aa-keyWrapAlgorithm ATTRIBUTE ::= { 1681 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}} 1682 IDENTIFIED BY id-kma-keyWrapAlgorithm } 1684 id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= { 1685 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1686 dod(2) infosec(1) keying-material-attributes(13) 21 } 1688 KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... } 1690 25. Content Decryption Key Identifier 1692 The content-decryption-key-identifier attribute can appear as an 1693 unprotected attribute as well as a symmetric and symmetric key 1694 package attribute. The attribute's semantics differ based on the 1695 location. 1697 25.1. Content Decryption Key Identifier: Symmetric Key and Symmetric Key 1698 Package 1700 The content-decryption-key-identifier attribute [RFC6032] identifies 1701 the keying material needed to decrypt the sKey. It can appear as a 1702 symmetric key and symmetric key package attribute. If the key-wrap- 1703 algorithm attribute appears in sKeyPkgAttrs, then the corresponding 1704 content-decryption-identifier attribute can appear in either 1705 sKeyPkgAttrs or sKeyAttrs. If the key-wrap-algorithm attribute 1706 appears from Section 24 in sKeyAttrs, then the corresponding content- 1707 decryption-identifier attribute MUST appear in sKeyAttrs. 1709 The content-decryption-key-identifier attribute in included for 1710 convenience: 1712 aa-contentDecryptKeyIdentifier ATTRIBUTE ::= { 1713 TYPE ContentDecryptKeyID 1714 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 1716 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= { 1717 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1718 dod(2) infosec(1) attributes(5) 66 } 1720 ContentDecryptKeyID ::= OCTET STRING 1722 The content decryption key identifier contains an octet string, and 1723 this syntax does not impose any particular structure on the 1724 identifier value. 1726 25.2. Content Decryption Key Identifier: Unprotected 1728 The content-decryption-key-identifier attribute can be used to 1729 identify the keying material that is needed for decryption of the 1730 EncryptedData content if there is any ambiguity. 1732 The content-decryption-key-identifier attribute syntax is found in 1733 Section 25.1. The content decryption key identifier contains an octet 1734 string, and this syntax does not impose any particular structure on 1735 the identifier value. 1737 Due to multiple layers of encryption, the content-decryption-key- 1738 identifier attribute can appear in more than one location in the 1739 overall key package. When there are multiple occurrences of the 1740 content-decryption-key-identifier attribute, each occurrence is 1741 evaluated independently. Each one is used to identify the needed 1742 keying material for that layer of encryption. 1744 26. Certificate Pointers 1746 The certificate-pointers attribute can be used to reference one or 1747 more certificates that may be helpful in the processing of the 1748 content once it is decrypted. Sometimes certificates are omitted if 1749 they can be easily fetched. However, an intermediary may have better 1750 facilities to perform the fetching than the receiver. The 1751 certificate-pointers attribute may be useful in some environments. 1752 This attribute can appear as an unprotected and an 1753 unauthenticated/unprotected attribute. 1755 The certificate-pointers attribute uses the same syntax and semantics 1756 as the subject information access certificate extension [RFC5280]. 1757 The certificate-pointers attribute has the following syntax: 1759 aa-certificatePointers ATTRIBUTE ::= { 1760 TYPE SubjectInfoAccessSyntax 1761 IDENTIFIED BY id-pe-subjectInfoAccess } 1763 id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { 1764 iso(1) identified-organization(3) dod(6) internet(1) 1765 security(5) mechanisms(5) pkix(7) pe(1) 11 } 1767 SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF 1768 AccessDescription 1770 AccessDescription ::= SEQUENCE { 1771 accessMethod OBJECT IDENTIFIER, 1772 accessLocation GeneralName } 1774 As specified in [RFC5280], the id-ad-caRepository access method can 1775 be used to point to a repository where a Certification Authority 1776 publishes certificates and Certificate Revocation Lists (CRLs). In 1777 this case, the accessLocation field tells how to access the 1778 repository. Where the information is available via http, ftp, or 1779 ldap, accessLocation contains a uniform resource identifier (URI). 1780 Where the information is available via the directory access protocol 1781 (dap), accessLocation contains a directory name. 1783 27. CRL Pointers 1785 The CRL-pointers attribute can be used to reference one or more CRLs 1786 that may be helpful in the processing of the content once it is 1787 decrypted. Sometimes CRLs are omitted to conserve space or to ensure 1788 that the most recent CRL is obtained when the certificate is 1789 validated. However, an intermediary may have better facilities to 1790 perform the fetching than the receiver. The CRL-pointers attribute 1791 may be useful in some environments. This attribute can appear as an 1792 unprotected and unauthenticated/unprotected attribute. 1794 The CRL-pointers attribute has the following syntax: 1796 aa-crlPointers ATTRIBUTE ::= { 1797 TYPE GeneralNames 1798 IDENTIFIED BY id-aa-KP-crlPointers } 1800 id-aa-KP-crlPointers OBJECT IDENTIFIER ::= { 1801 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1802 dod(2) infosec(1) attributes(5) 70 } 1804 The CRL-pointers attribute uses the GeneralNames syntax from 1805 [RFC5280]. Each name describes a different mechanism to obtain the 1806 same CRL. Where the information is available via http, ftp, or ldap, 1807 GeneralNames contains a uniform resource identifier (URI). Where the 1808 information is available via the directory access protocol (dap), 1809 GeneralNames contains a directory name. 1811 28. Key Package Identifier and Receipt Request 1813 The Key Package Identifier and Receipt Request attribute from 1814 [RFC7191] is also supported. It can appear as a signed attribute, 1815 authenticated, authenticated/unprotected, or content attribute. 1817 29. Additional Error Codes 1819 This specification also defines three additional extendedErrorCodes 1820 [RFC7191]: 1822 id-errorCodes OBJECT IDENTIFIER ::= { 1823 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 1824 dod(2) infosec(1) errorCodes(22) } 1826 id-missingKeyType OBJECT IDENTIFIER ::= { 1827 id-errorCodes 1 } 1829 id-privacyMarkTooLong OBJECT IDENTIFIER ::= { 1830 id-errorCodes 2 } 1832 id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= { 1833 id-errorCodes 3 } 1835 id-incorrectKeyProvince OBJECT IDENTIFIER ::= { 1836 id-errorCodes 4 } 1838 missingKeyType indicates that all keying material within a package is 1839 of the same type; however, the key type attribute is not specified in 1840 sKeyPkgAttrs [RFC6031]. 1842 privacyMarkTooLong indicates that a classification attribute includes 1843 a privacy mark that exceeds 128 characters in length. 1845 unrecognizedSecurityPolicy indicates that a security-policy- 1846 identifier is not supported. 1848 incorrectKeyProvince indicates that the value of the key province 1849 attribute in a key package does not match the key province constraint 1850 of the TA used to validate the key package. 1852 30. Processing Key Package Attribute Values and CMS Content Constraints 1854 Trust anchors may contain constraints for any content type [RFC5934]. 1855 When the trust anchor contains constraints for the symmetric key 1856 package content type or the asymmetric key package content type, then 1857 the constraints provide default values for key package attributes 1858 that are not present in the key package and define the set of 1859 acceptable values for key package attributes that are present. 1861 When a trust anchor delegates authority by issuing an X.509 1862 certificate, the CMS content constraints certificate extension 1863 [RFC6010] may be included to constrain the authorizations. The trust 1864 anchor and the X.509 certification path provide default values for 1865 key package attributes that are not present in the key package and 1866 define the set of acceptable of values for key package attributes 1867 that are present. 1869 Constraints on content type usage are represented as attributes. 1871 The processing procedures for the CMS content constraints certificate 1872 extension [RFC6010] are part of the validation of a signed or 1873 authenticated object, and the procedures yield three output values: 1874 cms_constraints, cms_effective_attributes, and 1875 cms_default_attributes. Object validation MUST be performed before 1876 processing the key package contents, and these outputs values are 1877 used as part of key package processing. These same output values are 1878 easily generated directly from a trust anchor and the key package 1879 when no X.509 certification path is involved in validation. 1881 The cms_effective_attributes provides the set of acceptable values 1882 for attributes. Each attribute present in the key package that 1883 corresponds to an entry in cms_effective_attributes MUST contain a 1884 value that appears in cms_effective_attributes entry. Attributes 1885 that do not correspond to an entry in cms_effective_attributes are 1886 unconstrained and may contain any value. Correspondence between 1887 attributes and cms_effective_attributes is determined by comparing 1888 the attribute object identifier to object identifier for each entry 1889 in cms_effective_attributes. 1891 The cms_default_attributes provides values for attributes that do not 1892 appear in the key package. If cms_default_attributes includes only 1893 one attribute value for a particular attribute, then that value is 1894 used as if it were included in the key package itself. However, if 1895 cms_default_attributes includes more than one value for a particular 1896 attribute, then the appropriate value remains ambiguous and the key 1897 package should be rejected. 1899 Some attributes can appear in more than one place in the key package, 1900 and for this reason, the attribute definitions include consistency 1901 checks. These checks are independent of constraints checking. In 1902 addition to the consistency checks, each instance of the attribute 1903 MUST be checked against the set of cms_effective_attributes, and the 1904 key package MUST be rejected if any of the attributes values are not 1905 in the set of authorized set of values. 1907 31. Attribute Scope 1909 This section provides an example symmetric key package in order to 1910 provide a discussion of the scope of attributes. This is an 1911 informative section; it is not a normative portion of this 1912 specification. Figure 1 provides the example. All of the concepts 1913 apply to either a symmetric key package or an asymmetric key package, 1914 with the exception of the key-algorithm attribute which is only 1915 applicable to a symmetric key package. Each of the components is 1916 labeled with a number inside parentheses for easy reference: 1918 o (1) is the ContentInfo that must be present as the outermost 1919 layer of encapsulation. It contains no attributes. It is shown 1920 for completeness. 1922 o (2) is a SignedData content type, which includes six signed 1923 attributes. Four of the signed attributes are keying material 1924 attributes. 1926 o (3) is a ContentCollection that includes two encapsulated content 1927 types: a ContentWithAttributes and an EncryptedKeyPackage. This 1928 content type does not provide any attributes. 1930 o (4) is a ContentWithAttributes content type. It encapsulates a 1931 SignedData content type. Four key material attributes are 1932 provided. 1934 o (5) is a SignedData content type. It encapsulates a 1935 SymmetricKeyPackage content type. Six signed attributes are 1936 provided. Four attributes are key material attributes. 1938 o (6) is a SymmetricKeyPackage content type, and it includes three 1939 key material attributes. Note that the contents of this key 1940 package are not encrypted, but the contents are covered by two 1941 digital signatures. 1943 o (7) is an EncryptedKeyPackage content type. It encapsulates a 1944 SignedData content type. This content type provides one 1945 unprotected attribute. 1947 o (8) is a SignedData content type. It encapsulates a 1948 SymmetricKeyPackage content type. Six signed attributes are 1949 provided. Four attributes are key material attributes. 1951 o (9) is a SymmetricKeyPackage content type, and it includes three 1952 key material attributes. Note that the contents of this key 1953 package are encrypted, and the plaintext keying material is 1954 covered by one digital signature, and the ciphertext keying 1955 material is covered by another digital signature. 1957 SignedData content type (2) includes six signed attributes: 1959 o The content-type attribute contains id-ct-contentCollection to 1960 indicate the type of the encapsulated content, and it has no 1961 further scope. 1963 o The message-digest attribute contains the one-way hash value of 1964 the encapsulated content; it is needed to validate the digital 1965 signature. It has no further scope. 1967 o The classification attribute contains security label for all of 1968 the plaintext in the encapsulated content. Each classification 1969 attribute is evaluated separately; it has no further scope. In 1970 general, the values of this attribute will match or dominate the 1971 security label values in (4), (5), and (6). The value of this 1972 attribute might not match or dominate the security label values 1973 in (8) and (9) since they are encrypted. It is possible that 1974 these various security label values are associated with different 1975 security policies. Comparison is not required in order to avoid 1976 the processing complexity associated with policy mapping. 1978 o The key-package-receivers-v2 attribute indicates the authorized 1979 key package receivers, and it has no further scope. The key- 1980 package-receivers-v2 attribute value within (4) is evaluated 1981 without regard to the value of this attribute. 1983 o The key-distribution-period attribute contains two date values: 1984 doNotDistBefore and doNotDistAfter. These values must match all 1985 others within the same scope, which in this example is the key- 1986 distribution-period within (4). 1988 o The key-package-type attributes indicates the format of the key 1989 package, and it has no further scope. The key-package-type 1990 attributes values within (5) and (8) are evaluated without regard 1991 to the value of this attribute. 1993 ContentWithAttributes content type (4) includes four attributes: 1995 o The classification attribute contains security label for all of 1996 the plaintext in the encapsulated content. Each classification 1997 attribute is evaluated separately; it has no further scope. 1999 o The TSEC-Nomenclature attribute includes only the shortTitle 2000 field, and the value must match all other instances within the 2001 same scope, which appear in (5) and (6). Note that the TSEC- 2002 Nomenclature attribute values in (8) and (9) are not in the same 2003 scope as the TSEC-Nomenclature attribute that appears in (4). 2005 o The key-package-receivers-v2 attribute indicates the authorized 2006 key package receivers, and it has no further scope. The key- 2007 package-receivers-v2 attribute value within (2) is evaluated 2008 without regard to the value of this attribute. 2010 o The key-distribution-period attribute contains two date values: 2011 doNotDistBefore and doNotDistAfter. These values must match all 2012 others within the same scope, which in this example is the key- 2013 distribution-period within (2). 2015 SignedData content type (5) includes six signed attributes: 2017 o The content-type attribute contains id-ct-KP-skeyPackage to 2018 indicate the type of the encapsulated content, and it has no 2019 further scope. 2021 o The message-digest attribute contains the one-way hash value of 2022 the encapsulated content; it is needed to validate the digital 2023 signature. It has no further scope. 2025 o The classification attribute contains security label for all of 2026 the plaintext in the encapsulated content. Each classification 2027 attribute is evaluated separately; it has no further scope. 2029 o The TSEC-Nomenclature attribute includes only the shortTitle 2030 field, and the value must match all other instances within the 2031 same scope, which appear in (6). Since this is within the scope 2032 of (4), these shortTitle field values must match as well. Note 2033 that the TSEC-Nomenclature attribute values in (8) and (9) are 2034 not in the same scope. 2036 o The key-purpose attribute specifies the purpose of the key 2037 material. All occurrences within the scope must have the same 2038 value, but in this example, there are no other occurrences within 2039 the scope. The key-purpose attribute value within (8) is 2040 evaluated without regard to the value of this value. 2042 o The key-package-type attribute indicates the format of the key 2043 package, and it has no further scope. The key-package-type 2044 attribute values within (2) and (8) are evaluated without regard 2045 to the value of this attribute. 2047 SymmetricKeyPackage content type (6) includes three keying material 2048 attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs 2049 fields: 2051 o The key-algorithm attribute includes only the keyAlg field, and 2052 it must match all other occurrences within the same scope. 2053 However, there are no other key-algorithm attribute occurrences 2054 in the same scope; the key-algorithm attribute value in (9) is 2055 not in the same scope. 2057 o The classification attribute contains security label for all of 2058 the plaintext in the key package. Each classification attribute 2059 is evaluated separately; it has no further scope. 2061 o The TSEC-Nomenclature attribute includes the shortTitle field as 2062 well as some of the optional fields. The shortTitle field value 2063 must match the values in (4) and (5), since this content type is 2064 within their scope. Note that the TSEC-Nomenclature attribute 2065 values in (8) and (9) are not in the same scope. 2067 EncryptedKeyPackage content type (7) includes one unprotected 2068 attribute, and the encryption will prevent any intermediary that does 2069 not have the ability to decrypt the content from making any 2070 consistency checks on (8) and (9): 2072 o The content-decryption-key-identifier attribute identifies the 2073 key that is needed to decrypt the encapsulated content; it has no 2074 further scope. 2076 SignedData content type (8) includes six signed attributes: 2078 o The content-type attribute contains id-ct-KP-skeyPackage to 2079 indicate the type of the encapsulated content, and it has no 2080 further scope. 2082 o The message-digest attribute contains the one-way hash value of 2083 the encapsulated content; it is needed to validate the digital 2084 signature. It has no further scope. 2086 o The classification attribute contains security label for content. 2087 Each classification attribute is evaluated separately; it has no 2088 further scope. 2090 o The TSEC-Nomenclature attribute includes only the shortTitle 2091 field, and the value must match all other instances within the 2092 same scope, which appear in (9). Note that the TSEC-Nomenclature 2093 attribute values in (4), (5), and (6) are not in the same scope. 2095 o The key-purpose attribute specifies the purpose of the key 2096 material. All occurrences within the scope must have the same 2097 value, but in this example, there are no other occurrences within 2098 the scope. The key-purpose attribute value within (5) is 2099 evaluated without regard to the value of this attribute. 2101 o The key-package-type attribute indicates the format of the key 2102 package, and it has no further scope. The key-package-type 2103 attribute values within (2) and (5) are evaluated without regard 2104 to the value of this attribute. 2106 SymmetricKeyPackage content type (9) includes three keying material 2107 attributes, which could appear in the sKeyPkgAttrs or sKeyAttrs 2108 fields: 2110 o The key-algorithm attribute includes only the keyAlg field, and 2111 it must match all other occurrences within the same scope. 2112 However, there are no other key-algorithm attribute occurrences 2113 in the same scope; the key-algorithm attribute value in (6) is 2114 not in the same scope. 2116 o The classification attribute contains security label for all of 2117 the plaintext in the key package. Each classification attribute 2118 is evaluated separately; it has no further scope. 2120 o The TSEC-Nomenclature attribute includes the shortTitle field as 2121 well as some of the optional fields. The shortTitle field value 2122 must match the values in (8), since this content type is within 2123 its scope. Note that the TSEC-Nomenclature attributes values in 2124 (4), (5), and (6) are not in the same scope. 2126 In summary, the scope of an attribute includes the encapsulated 2127 content of the CMS content type in which it appears, and some 2128 attributes also require consistency checks with other instances that 2129 appear within the encapsulated content. Proper recognition of scope 2130 is required to accurately perform attribute processing. 2132 +------------------------------------------------------------------+ 2133 | ContentInfo (1) | 2134 |+----------------------------------------------------------------+| 2135 || SignedData (2) || 2136 ||+--------------------------------------------------------------+|| 2137 ||| ContentCollection (3) ||| 2138 |||+-----------------------------++-----------------------------+||| 2139 |||| ContentWithAttributes (4) || EncryptedKeyPackage (7) |||| 2140 ||||+---------------------------+||+---------------------------+|||| 2141 ||||| SignedData (5) |||| SignedData (8) ||||| 2142 |||||+-------------------------+||||+-------------------------+||||| 2143 |||||| SymmetricKeyPackage (6) |||||| SymmetricKeyPackage (9) |||||| 2144 |||||| Attributes: |||||| Attributes: |||||| 2145 |||||| Key Algorithm |||||| Key Algorithm |||||| 2146 |||||| Classification |||||| Classification |||||| 2147 |||||| TSEC-Nomenclature |||||| TSEC-Nomenclature |||||| 2148 |||||+-------------------------+||||+-------------------------+||||| 2149 ||||| Attributes: |||| Attributes: ||||| 2150 ||||| Content Type |||| Content Type ||||| 2151 ||||| Message Digest |||| Message Digest ||||| 2152 ||||| Classification |||| Classification ||||| 2153 ||||| TSEC-Nomenclature |||| TSEC-Nomenclature ||||| 2154 ||||| Key Purpose |||| Key Purpose ||||| 2155 ||||| Key Package Type |||| Key Package Type ||||| 2156 ||||+-------------------------- +||+---------------------------+|||| 2157 |||| Attributes: || Unprotect Attributes: |||| 2158 |||| Classification || Content Decrypt Key ID |||| 2159 |||| TSEC-Nomenclature |+-----------------------------+||| 2160 |||| Key Package Receivers | ||| 2161 |||| Key Distribution Period | ||| 2162 |||+-----------------------------+ ||| 2163 ||+--------------------------------------------------------------+|| 2164 || Attributes: || 2165 || Content Type || 2166 || Message Digest || 2167 || Classification || 2168 || Key Package Receivers || 2169 || Key Distribution Period || 2170 || Key Package Type || 2171 |+----------------------------------------------------------------+| 2172 +------------------------------------------------------------------+ 2174 Figure 1: Example Illustrating Scope of Attributes 2176 32. Security Considerations 2178 The majority of this specification is devoted to the syntax and 2179 semantics of key package attributes. It relies on other 2180 specifications, especially [RFC2634] [RFC4073] [RFC4108] [RFC5652] 2181 [RFC5911] [RFC5912] [RFC5958] [RFC6010] [RFC6031]; their security 2182 considerations apply here. Additionally, cryptographic algorithms 2183 are used with CMS protecting content types [RFC5959] [RFC6160] 2184 [RFC6162]; their security considerations apply here as well. 2186 This specification also relies upon [RFC5280] for the syntax and 2187 semantics of X.509 certificates. Digital signatures provide data 2188 integrity or data origin authentication, and encryption provides 2189 confidentiality. 2191 Security factors outside the scope of this specification greatly 2192 affect the assurance provided. The procedures used by Certification 2193 Authorities (CAs) to validate the binding of the subject identity to 2194 their public key greatly affect the assurance that ought to be placed 2195 in the certificate. This is particularly important when issuing 2196 certificates to other CAs. 2198 The CMS AuthenticatedData content type MUST be used with care since a 2199 message authentication code (MAC) is used. The same key is needed to 2200 generate the MAC or validate the MAC. Thus, any party with access to 2201 the key needed to validate the MAC can generate a replacement that 2202 will be acceptable to other recipients. 2204 In some situations, returning very detailed error information can 2205 provide an attacker with insight into the security processing. Where 2206 this is a concern, the implementation should return the most generic 2207 error code that is appropriate. However, detailed error codes are 2208 very helpful during development, debugging, and interoperability 2209 testing. For this reason, implementations may want to have a way to 2210 configure the use of a generic error code or a detailed one. 2212 33. IANA Considerations 2214 None. 2216 34. References 2218 34.1 Normative References 2220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2221 Requirement Levels", BCP 14, RFC 2119, March 1997. 2223 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 2224 RFC 2634, June 1999. 2226 [RFC4073] Housley, R., "Protecting Multiple Contents with the 2227 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 2229 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 2230 Protect Firmware Packages", RFC 4108, August 2005. 2232 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 2233 Authenticated-Enveloped-Data Content Type", RFC 5083, 2234 November 2007. 2236 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2237 Housley, R., and W. Polk, "Internet X.509 Public Key 2238 Infrastructure Certificate and Certificate Revocation List 2239 (CRL) Profile", RFC 5280, May 2008. 2241 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2242 RFC 5652, September 2009. 2244 [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for 2245 Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, 2246 June 2010. 2248 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 2249 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 2250 June 2010. 2252 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2253 2010. 2255 [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content 2256 Type", RFC 5959, August 2010. 2258 [RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic 2259 Message Syntax (CMS) Content Constraints Extension", 2260 RFC 6010, September 2010. 2262 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 2263 Representing Date and Time in ASN.1", RFC 6019, September 2264 2010. 2266 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2267 (CMS) Symmetric Key Package Content Type", RFC 6031, 2268 December 2010. 2270 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 2271 (CMS) Encrypted Key Package Content Type", RFC 6032, 2272 December 2010. 2274 [RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax 2275 (CMS) Protection of Symmetric Key Package Content Types", 2276 RFC 6160, April 2011. 2278 [RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic 2279 Message Syntax (CMS) Asymmetric Key Package Content Type", 2280 RFC 6162, April 2011. 2282 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 2283 for the Cryptographic Message Syntax (CMS) and the Public 2284 Key Infrastructure Using X.509 (PKIX)", RFC 6268, July 2285 2011. 2287 [RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key 2288 Package Receipt and Error Content Types", RFC 7191, April 2289 2014. 2291 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 2292 Information technology - Open Systems Interconnection - 2293 The Directory: Public-key and attribute certificate 2294 frameworks. 2296 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 2297 Information Technology - Abstract Syntax Notation One. 2299 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 2300 Information Technology - Abstract Syntax Notation One: 2301 Information Object Specification. 2303 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 2304 Information Technology - Abstract Syntax Notation One: 2305 Constraint Specification. 2307 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 2309 Information Technology - Abstract Syntax Notation One: 2310 Parameterization of ASN.1 Specifications. 2312 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 2313 Information Technology - ASN.1 encoding rules: 2314 Specification of Basic Encoding Rules (BER), Canonical 2315 Encoding Rules (CER) and Distinguished Encoding Rules 2316 (DER). 2318 34.2 Informative References 2320 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 2321 Management Protocol (TAMP)", RFC 5934, August 2010. 2323 [X.411] ITU-T Recommendation X.411 (1988) | ISO/IEC 10021-4:1988, 2324 Data Communication Networks Message Handling Systems - 2325 Message Transfer System - Abstract Service Definition and 2326 Procedures. 2328 Appendix A. ASN.1 Module 2330 KMAttributes2012 2331 { joint-iso-itu-t(2) country(16) us(840) organization(1) 2332 gov(101) dod(2) infosec(1) modules(0) 39 } 2334 DEFINITIONS IMPLICIT TAGS ::= 2336 BEGIN 2338 -- EXPORT ALL 2340 IMPORTS 2342 -- From [RFC5911] 2344 aa-communityIdentifiers, CommunityIdentifier 2345 FROM CMSFirmwareWrapper-2009 2346 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2347 smime(16) modules(0) id-mod-cms-firmware-wrap-02(40) } 2349 -- From [RFC5911] 2351 aa-contentHint, ESSSecurityLabel, id-aa-securityLabel 2352 FROM ExtendedSecurityServices-2009 2353 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2354 smime(16) modules(0) id-mod-ess-2006-02(42) } 2356 -- From [RFC5911] [RFC5912] 2358 AlgorithmIdentifier{}, SMIME-CAPS, ParamOptions, KEY-WRAP 2359 FROM AlgorithmInformation-2009 2360 { iso(1) identified-organization(3) dod(6) internet(1) 2361 security(5) mechanisms(5) pkix(7) id-mod(0) 2362 id-mod-algorithmInformation-02(58) } 2364 -- From [RFC5912] 2366 Name, Certificate 2367 FROM PKIX1Explicit-2009 2368 { iso(1) identified-organization(3) dod(6) internet(1) 2369 security(5) mechanisms(5) pkix(7) id-mod(0) 2370 id-mod-pkix1-explicit-02(51) } 2372 -- From [RFC5912] 2374 GeneralNames, SubjectInfoAccessSyntax, id-pe-subjectInfoAccess 2375 FROM PKIX1Implicit-2009 2376 { iso(1) identified-organization(3) dod(6) internet(1) 2377 security(5) mechanisms(5) pkix(7) id-mod(0) 2378 id-mod-pkix1-implicit-02(59) } 2380 -- FROM [RFC5912] 2382 ATTRIBUTE 2383 FROM PKIX-CommonTypes-2009 2384 { iso(1) identified-organization(3) dod(6) internet(1) 2385 security(5) mechanisms(5) pkix(7) id-mod(0) 2386 id-mod-pkixCommon-02(57) } 2388 -- From [RFC6010] 2390 CMSContentConstraints 2391 FROM CMSContentConstraintsCertExtn 2392 { iso(1) identified-organization(3) dod(6) internet(1) 2393 security(5) mechanisms(5) pkix(7) id-mod(0) 2394 cmsContentConstr-93(42) } 2396 -- From [RFC6268] 2398 aa-binarySigningTime, BinaryTime 2399 FROM BinarySigningTimeModule-2010 2400 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2401 smime(16) modules(0) id-mod-binSigningTime-2009(55) } 2403 -- From [RFC6268] 2405 CertificateChoices, CertificateSet, Attribute {}, 2406 aa-contentType, aa-messageDigest 2407 FROM CryptographicMessageSyntax-2010 2408 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2409 smime(16) modules(0) id-mod-cms-2009(58) } 2411 -- From [RFC7191] 2413 aa-keyPackageIdentifierAndReceiptRequest, SIREntityName 2414 FROM KeyPackageReceiptAndErrorModuleV2 2415 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2416 smime(16) modules(0) id-mod-keyPkgReceiptAndErrV2(63) } 2418 -- From [X.509] 2420 certificateExactMatch 2421 FROM CertificateExtensions 2422 { joint-iso-itu-t ds(5) module(1) certificateExtensions(26) 4 } 2424 ; 2426 -- ATTRIBUTES 2428 -- Replaces SignedAttributesSet information object set from 2429 -- [RFC6268]. 2431 SignedAttributesSet ATTRIBUTE ::= { 2432 aa-contentType | 2433 aa-messageDigest | 2434 aa-contentHint | 2435 aa-communityIdentifiers | 2436 aa-binarySigningTime | 2437 aa-keyProvince-v2 | 2438 aa-keyPackageIdentifierAndReceiptRequest | 2439 aa-manifest | 2440 aa-keyAlgorithm | 2441 aa-userCertificate | 2442 aa-keyPackageReceivers-v2 | 2443 aa-tsecNomenclature | 2444 aa-keyPurpose | 2445 aa-keyUse | 2446 aa-transportKey | 2447 aa-keyDistributionPeriod | 2448 aa-keyValidityPeriod | 2449 aa-keyDurationPeriod | 2450 aa-classificationAttribute | 2451 aa-keyPackageType | 2452 aa-pkiPath | 2453 aa-usefulCertificates, 2454 ... } 2456 -- Replaces UnsignedAttributes from [RFC6268]. 2458 UnsignedAttributes ATTRIBUTE ::= { 2459 ... 2460 } 2462 -- Replaces UnprotectedEnvAttributes from [RFC6268]. 2464 UnprotectedEnvAttributes ATTRIBUTE ::= { 2465 aa-contentDecryptKeyIdentifier | 2466 aa-certificatePointers | 2467 aa-cRLDistributionPoints, 2468 ... 2469 } 2471 -- Replaces UnprotectedEncAttributes from [RFC6268]. 2473 UnprotectedEncAttributes ATTRIBUTE ::= { 2474 aa-certificatePointers | 2475 aa-cRLDistributionPoints, 2476 ... 2477 } 2479 -- Replaces AuthAttributeSet from [RFC6268] 2481 AuthAttributeSet ATTRIBUTE ::= { 2482 aa-contentType | 2483 aa-messageDigest | 2484 aa-contentHint | 2485 aa-communityIdentifiers | 2486 aa-keyProvice-v2 | 2487 aa-binarySigningTime | 2488 aa-keyPackageIdentifierAndReceiptRequest | 2489 aa-manifest | 2490 aa-keyAlgorithm | 2491 aa-userCertificate | 2492 aa-keyPackageReceivers-v2 | 2493 aa-tsecNomenclature | 2494 aa-keyPurpose | 2495 aa-keyUse | 2496 aa-transportKey | 2497 aa-keyDistributionPeriod | 2498 aa-keyValidityPeriod | 2499 aa-keyDurationPeriod | 2500 aa-classificationAttribute | 2501 aa-keyPackageType | 2502 aa-pkiPath | 2503 aa-usefulCertificates, 2504 ... } 2506 -- Replaces UnauthAttributeSet from [RFC6268] 2508 UnauthAttributeSet ATTRIBUTE ::= { 2509 ... 2510 } 2512 -- Replaces AuthEnvDataAttributeSet from [RFC6268] 2514 AuthEnvDataAttributeSet ATTRIBUTE ::= { 2515 aa-certificatePointers | 2516 aa-cRLDistributionPoints, 2517 ... 2518 } 2520 -- Replaces UnauthEnvDataAttributeSet from [RFC6268] 2522 UnauthEnvDataAttributeSet ATTRIBUTE ::= { 2523 ... 2524 } 2526 -- Replaces OneAsymmetricKeyAttributes from [RFC5958] 2528 OneAsymmetricKeyAttributes ATTRIBUTE ::= { 2529 aa-userCertificate | 2530 aa-tsecNomenclature | 2531 aa-keyPurpose | 2532 aa-keyUse | 2533 aa-transportKey | 2534 aa-keyDistributionPeriod | 2535 aa-keyValidityPeriod | 2536 aa-keyDurationPeriod | 2537 aa-classificationAttribute | 2538 aa-splitIdentifier | 2539 aa-signatureUsage-v3 | 2540 aa-otherCertificateFormats | 2541 aa-pkiPath | 2542 aa-usefulCertificates, 2543 ... } 2545 -- Replaces SKeyPkgAttributes from [RFC6031] 2547 SKeyPkgAttributes ATTRIBUTE ::= { 2548 aa-keyAlgorithm | 2549 aa-tsecNomenclature | 2550 aa-keyPurpose | 2551 aa-keyUse | 2552 aa-keyDistributionPeriod | 2553 aa-keyValidityPeriod | 2554 aa-keyDurationPeriod | 2555 aa-classificationAttribute | 2556 aa-keyWrapAlgorithm | 2557 aa-contentDecryptKeyIdentifier, 2558 ... } 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 -- Key Province 2604 aa-keyProvince-v2 ATTRIBUTE ::= { 2605 TYPE KeyProvinceV2 2606 IDENTIFIED BY id-aa-KP-keyProvinceV2 } 2608 id-aa-KP-keyProvinceV2 OBJECT IDENTIFIER ::= 2609 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2610 dod(2) infosec(1) attributes(5) 71 } 2612 KeyProvinceV2 ::= OBJECT IDENTIFIER 2614 -- Manifest Attribute 2616 aa-manifest ATTRIBUTE ::= { 2617 TYPE Manifest 2618 IDENTIFIED BY id-aa-KP-manifest } 2620 id-aa-KP-manifest OBJECT IDENTIFIER ::= 2621 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2622 dod(2) infosec(1) attributes(5) 72 } 2624 Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle 2626 -- Key Algorithm Attribute 2628 aa-keyAlgorithm ATTRIBUTE ::= { 2629 TYPE KeyAlgorithm 2630 IDENTIFIED BY id-kma-keyAlgorithm } 2632 id-kma-keyAlgorithm OBJECT IDENTIFIER ::= 2633 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2634 dod(2) infosec(1) keying-material-attributes(13) 1 } 2636 KeyAlgorithm ::= SEQUENCE { 2637 keyAlg OBJECT IDENTIFIER, 2638 checkWordAlg [1] OBJECT IDENTIFIER OPTIONAL, 2639 crcAlg [2] OBJECT IDENTIFIER OPTIONAL } 2641 -- User Certificate Attribute 2643 aa-userCertificate ATTRIBUTE ::= { 2644 TYPE Certificate 2645 EQUALITY MATCHING RULE certificateExactMatch 2646 IDENTIFIED BY id-at-userCertificate } 2648 id-at-userCertificate OBJECT IDENTIFIER ::= 2649 { joint-iso-itu-t(2) ds(5) attributes(4) 36 } 2651 -- Key Package Receivers Attribute 2653 aa-keyPackageReceivers-v2 ATTRIBUTE ::= { 2654 TYPE KeyPkgReceiversV2 2655 IDENTIFIED BY id-kma-keyPkgReceiversV2 } 2657 id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= 2658 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2659 dod(2) infosec(1) keying-material-attributes(13) 16 } 2661 KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver 2663 KeyPkgReceiver ::= CHOICE { 2664 sirEntity [0] SIREntityName, 2665 community [1] CommunityIdentifier } 2667 -- TSEC Nomenclature Attribute 2669 aa-tsecNomenclature ATTRIBUTE ::= { 2670 TYPE TSECNomenclature 2671 IDENTIFIED BY id-kma-TSECNomenclature } 2673 id-kma-TSECNomenclature OBJECT IDENTIFIER ::= 2674 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2675 dod(2) infosec(1) keying-material-attributes(13) 3 } 2677 TSECNomenclature ::= SEQUENCE { 2678 shortTitle ShortTitle, 2679 editionID EditionID OPTIONAL, 2680 registerID RegisterID OPTIONAL, 2681 segmentID SegmentID OPTIONAL } 2683 ShortTitle ::= PrintableString 2685 EditionID ::= CHOICE { 2686 char CHOICE { 2687 charEdition [1] CharEdition, 2688 charEditionRange [2] CharEditionRange }, 2689 num CHOICE { 2690 numEdition [3] NumEdition, 2691 numEditionRange [4] NumEditionRange } } 2693 CharEdition ::= PrintableString 2695 CharEditionRange ::= SEQUENCE { 2696 firstCharEdition CharEdition, 2697 lastCharEdition CharEdition } 2699 NumEdition ::= INTEGER (0..308915776) 2701 NumEditionRange ::= SEQUENCE { 2702 firstNumEdition NumEdition, 2703 lastNumEdition NumEdition } 2705 RegisterID ::= CHOICE { 2706 register [5] Register, 2707 registerRange [6] RegisterRange } 2709 Register ::= INTEGER (0..2147483647) 2711 RegisterRange ::= SEQUENCE { 2712 firstRegister Register, 2713 lastRegister Register } 2715 SegmentID ::= CHOICE { 2716 segmentNumber [7] SegmentNumber, 2717 segmentRange [8] SegmentRange } 2719 SegmentNumber ::= INTEGER (1..127) 2721 SegmentRange ::= SEQUENCE { 2722 firstSegment SegmentNumber, 2723 lastSegment SegmentNumber } 2725 -- Key Purpose Attribute 2727 aa-keyPurpose ATTRIBUTE ::= { 2728 TYPE KeyPurpose 2729 IDENTIFIED BY id-kma-keyPurpose } 2731 id-kma-keyPurpose OBJECT IDENTIFIER ::= 2732 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2733 dod(2) infosec(1) keying-material-attributes(13) 13 } 2735 KeyPurpose ::= ENUMERATED { 2736 n-a (0), -- Not Applicable 2737 a (65), -- Operational 2738 b (66), -- Compatible Multiple Key 2739 l (76), -- Logistics Combinations 2740 m (77), -- Maintenance 2741 r (82), -- Reference 2742 s (83), -- Sample 2743 t (84), -- Training 2744 v (86), -- Developmental 2745 x (88), -- Exercise 2746 z (90), -- "On the Air" Testing 2747 ... -- Expect additional key purpose values -- } 2749 -- Key Use Attribute 2751 aa-keyUse ATTRIBUTE ::= { 2752 TYPE KeyUse 2753 IDENTIFIED BY id-kma-keyUse } 2755 id-kma-keyUse OBJECT IDENTIFIER ::= 2756 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2757 dod(2) infosec(1) keying-material-attributes(13) 14 } 2759 KeyUse ::= ENUMERATED { 2760 n-a (0), -- Not Applicable 2761 ffk (1), -- FIREFLY/CROSSTALK Key (Basic Format) 2762 kek (2), -- Key Encryption Key 2763 kpk (3), -- Key Production Key 2764 msk (4), -- Message Signature Key 2765 qkek (5), -- QUADRANT Key Encryption Key 2766 tek (6), -- Traffic Encryption Key 2767 tsk (7), -- Transmission Security Key 2768 trkek (8), -- Transfer Key Encryption Key 2769 nfk (9), -- Netted FIREFLY Key 2770 effk (10), -- FIREFLY Key (Enhanced Format) 2771 ebfk (11), -- FIREFLY Key (Enhanceable Basic Format) 2772 aek (12), -- Algorithm Encryption Key 2773 wod (13), -- Word of Day 2774 kesk (246), -- Key Establishment Key 2775 eik (247), -- Entity Identification Key 2776 ask (248), -- Authority Signature Key 2777 kmk (249), -- Key Modifier Key 2778 rsk (250), -- Revocation Signature Key 2779 csk (251), -- Certificate Signature Key 2780 sak (252), -- Symmetric Authentication Key 2781 rgk (253), -- Random Generation Key 2782 cek (254), -- Certificate Encryption Key 2783 exk (255), -- Exclusion Key 2784 ... -- Expect additional key use values -- } 2786 -- Transport Key Attribute 2788 aa-transportKey ATTRIBUTE ::= { 2789 TYPE TransOp 2790 IDENTIFIED BY id-kma-transportKey } 2792 id-kma-transportKey OBJECT IDENTIFIER ::= 2793 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2794 dod(2) infosec(1) keying-material-attributes(13) 15 } 2796 TransOp ::= ENUMERATED { 2797 transport (1), 2798 operational (2) } 2800 -- Key Distribution Period Attribute 2802 aa-keyDistributionPeriod ATTRIBUTE ::= { 2803 TYPE KeyDistPeriod 2804 IDENTIFIED BY id-kma-keyDistPeriod } 2806 id-kma-keyDistPeriod OBJECT IDENTIFIER ::= 2807 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2808 dod(2) infosec(1) keying-material-attributes(13) 5 } 2810 KeyDistPeriod ::= SEQUENCE { 2811 doNotDistBefore [0] BinaryTime OPTIONAL, 2812 doNotDistAfter BinaryTime } 2814 -- Key Validity Period Attribute 2816 aa-keyValidityPeriod ATTRIBUTE ::= { 2817 TYPE KeyValidityPeriod 2818 IDENTIFIED BY id-kma-keyValidityPeriod } 2820 id-kma-keyValidityPeriod OBJECT IDENTIFIER ::= 2821 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2822 dod(2) infosec(1) keying-material-attributes(13) 6 } 2824 KeyValidityPeriod ::= SEQUENCE { 2825 doNotUseBefore BinaryTime, 2826 doNotUseAfter BinaryTime OPTIONAL } 2828 -- Key Duration Attribute 2830 aa-keyDurationPeriod ATTRIBUTE ::= { 2831 TYPE KeyDuration 2832 IDENTIFIED BY id-kma-keyDuration } 2834 id-kma-keyDuration OBJECT IDENTIFIER ::= 2835 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2836 dod(2) infosec(1) keying-material-attributes(13) 7 } 2838 KeyDuration ::= CHOICE { 2839 hours [0] INTEGER (1..ub-KeyDuration-hours), 2840 days INTEGER (1..ub-KeyDuration-days), 2841 weeks [1] INTEGER (1..ub-KeyDuration-weeks), 2842 months [2] INTEGER (1..ub-KeyDuration-months), 2843 years [3] INTEGER (1..ub-KeyDuration-years) } 2845 ub-KeyDuration-hours INTEGER ::= 96 2846 ub-KeyDuration-days INTEGER ::= 732 2847 ub-KeyDuration-weeks INTEGER ::= 104 2848 ub-KeyDuration-months INTEGER ::= 72 2849 ub-KeyDuration-years INTEGER ::= 100 2850 -- Classification Attribute 2852 -- The attribute syntax is imported from [RFC6268]. The term 2853 -- "classification" is used in this document, but the term "security 2854 -- label" is used in [RFC2634]. The terms have the same meaning. 2856 aa-classificationAttribute ATTRIBUTE ::= { 2857 TYPE Classification 2858 IDENTIFIED BY id-aa-KP-classification } 2860 id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel 2862 Classification ::= ESSSecurityLabel 2864 id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= 2865 { 2 16 840 1 101 2 1 8 3 4 } 2867 id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= 2868 { 2 16 840 1 101 2 1 8 3 1 } 2870 EnumeratedTag ::= SEQUENCE { 2871 tagName OBJECT IDENTIFIER, 2872 attributeList SET OF SecurityAttribute } 2874 SecurityAttribute ::= INTEGER (0..MAX) 2876 -- Split Identifier Attribute 2878 aa-splitIdentifier ATTRIBUTE ::= { 2879 TYPE SplitID 2880 IDENTIFIED BY id-kma-splitID } 2882 id-kma-splitID OBJECT IDENTIFIER ::= 2883 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2884 dod(2) infosec(1) keying-material-attributes(13) 11 } 2886 SplitID ::= SEQUENCE { 2887 half ENUMERATED { a(0), b(1) }, 2888 combineAlg AlgorithmIdentifier 2889 {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL } 2891 COMBINE-ALGORITHM ::= CLASS { 2892 &id OBJECT IDENTIFIER UNIQUE, 2893 &Params OPTIONAL, 2894 ¶mPresence ParamOptions DEFAULT absent, 2895 &smimeCaps SMIME-CAPS OPTIONAL 2896 } 2897 WITH SYNTAX { 2898 IDENTIFIER &id 2899 [PARAMS [TYPE &Params] ARE ¶mPresence] 2900 [SMIME-CAPS &smimeCaps] 2901 } 2903 CombineAlgorithms COMBINE-ALGORITHM ::= { 2904 ... 2905 } 2907 -- Key Package Type Attribute 2909 aa-keyPackageType ATTRIBUTE ::= { 2910 TYPE KeyPkgType 2911 IDENTIFIED BY id-kma-keyPkgType } 2913 id-kma-keyPkgType OBJECT IDENTIFIER ::= 2914 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2915 dod(2) infosec(1) keying-material-attributes(13) 12 } 2917 KeyPkgType ::= OBJECT IDENTIFIER 2919 -- Signature Usage Attribute 2921 aa-signatureUsage-v3 ATTRIBUTE ::= { 2922 TYPE SignatureUsage 2923 IDENTIFIED BY id-kma-sigUsageV3 } 2925 id-kma-sigUsageV3 OBJECT IDENTIFIER ::= 2926 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2927 dod(2) infosec(1) keying-material-attributes(13) 22 } 2929 SignatureUsage ::= CMSContentConstraints 2931 -- Other Certificate Format Attribute 2933 aa-otherCertificateFormats ATTRIBUTE ::= { 2934 TYPE CertificateChoices 2935 IDENTIFIED BY id-kma-otherCertFormats } 2937 id-kma-otherCertFormats OBJECT IDENTIFIER ::= 2938 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2939 dod(2) infosec(1) keying-material-attributes(13) 19 } 2941 -- PKI Path Attribute 2943 aa-pkiPath ATTRIBUTE ::= { 2944 TYPE PkiPath 2945 IDENTIFIED BY id-at-pkiPath } 2947 id-at-pkiPath OBJECT IDENTIFIER ::= 2948 { joint-iso-itu-t(2) ds(5) attributes(4) 70 } 2950 PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate 2952 -- Useful Certificates Attribute 2954 aa-usefulCertificates ATTRIBUTE ::= { 2955 TYPE CertificateSet 2956 IDENTIFIED BY id-kma-usefulCerts } 2958 id-kma-usefulCerts OBJECT IDENTIFIER ::= 2959 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2960 dod(2) infosec(1) keying-material-attributes(13) 20 } 2962 -- Key Wrap Attribute 2964 aa-keyWrapAlgorithm ATTRIBUTE ::= { 2965 TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}} 2966 IDENTIFIED BY id-kma-keyWrapAlgorithm } 2968 id-kma-keyWrapAlgorithm OBJECT IDENTIFIER ::= 2969 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2970 dod(2) infosec(1) keying-material-attributes(13) 21 } 2972 KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... } 2974 -- Content Decryption Key Identifier Attribute 2976 aa-contentDecryptKeyIdentifier ATTRIBUTE ::= { 2977 TYPE ContentDecryptKeyID 2978 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 2980 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= 2981 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2982 dod(2) infosec(1) attributes(5) 66 } 2984 ContentDecryptKeyID::= OCTET STRING 2985 -- Certificate Pointers Attribute 2987 aa-certificatePointers ATTRIBUTE ::= { 2988 TYPE SubjectInfoAccessSyntax 2989 IDENTIFIED BY id-pe-subjectInfoAccess } 2991 -- CRL Pointers Attribute 2993 aa-cRLDistributionPoints ATTRIBUTE ::= { 2994 TYPE GeneralNames 2995 IDENTIFIED BY id-aa-KP-crlPointers } 2997 id-aa-KP-crlPointers OBJECT IDENTIFIER ::= 2998 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 2999 dod(2) infosec(1) attributes (5) 70 } 3001 -- ExtendedErrorCodes 3003 id-errorCodes OBJECT IDENTIFIER ::= 3004 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 3005 dod(2) infosec(1) errorCodes(22) } 3007 id-missingKeyType OBJECT IDENTIFIER ::= { 3008 id-errorCodes 1 } 3010 id-privacyMarkTooLong OBJECT IDENTIFIER ::= { 3011 id-errorCodes 2 } 3013 id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= { 3014 id-errorCodes 3 } 3016 END 3018 Authors' Addresses 3020 Paul Timmel 3021 National Information Assurance Research Laboratory 3022 National Security Agency 3024 Email: pstimme@tycho.ncsc.mil 3026 Russ Housley 3027 Vigil Security, LLC 3028 918 Spring Knoll Drive 3029 Herndon, VA 20170 3030 USA 3032 Email: : housley@vigilsec.com 3034 Sean Turner 3035 IECA, Inc. 3036 3057 Nutley Street, Suite 106 3037 Fairfax, VA 22031 3038 USA 3040 Email: turners@ieca.com