tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7906

Informational
Pages: 68
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ~sec-cms

NSA's Cryptographic Message Syntax (CMS) Key Management Attributes

Part 1 of 3, p. 1 to 21
None       Next RFC Part

 


Top       ToC       Page 1 
Independent Submission                                         P. Timmel
Request for Comments: 7906                      National Security Agency
Category: Informational                                       R. Housley
ISSN: 2070-1721                                           Vigil Security
                                                               S. Turner
                                                                    IECA
                                                               June 2016


   NSA's Cryptographic Message Syntax (CMS) Key Management Attributes

Abstract

   This document defines key management attributes used by the National
   Security Agency (NSA).  The attributes can appear in asymmetric
   and/or symmetric key packages as well as the Cryptographic Message
   Syntax (CMS) content types that subsequently envelope the key
   packages.  Key packages described in RFCs 5958 and 6031 are examples
   of where these attributes can be used.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7906.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................3
      1.1. Attribute Locations ........................................3
      1.2. ASN.1 Notation .............................................4
      1.3. Terminology ................................................5
   2. CMS-Defined Attributes ..........................................6
   3. Community Identifiers ...........................................7
   4. Key Province Attribute ..........................................8
   5. Binary Signing Time .............................................8
   6. Manifest ........................................................9
   7. Key Algorithm ...................................................9
   8. User Certificate ...............................................11
   9. Key Package Receivers ..........................................11
   10. TSEC Nomenclature .............................................13
   11. Key Purpose ...................................................16
   12. Key Use .......................................................17
   13. Transport Key .................................................20
   14. Key Distribution Period .......................................20
   15. Key Validity Period ...........................................22
   16. Key Duration ..................................................23
   17. Classification ................................................24
      17.1. Security Label ...........................................25
   18. Split Key Identifier ..........................................29
   19. Key Package Type ..............................................30
   20. Signature Usage ...............................................30
   21. Other Certificate Format ......................................33
   22. PKI Path ......................................................34
   23. Useful Certificates ...........................................35
   24. Key Wrap Algorithm ............................................35
   25. Content Decryption Key Identifier .............................36
      25.1. Content Decryption Key Identifier: Symmetric Key
            and Symmetric ............................................36
      25.2. Content Decryption Key Identifier: Unprotected ...........37
   26. Certificate Pointers ..........................................37
   27. CRL Pointers ..................................................38
   28. Key Package Identifier and Receipt Request ....................38
   29. Additional Error Codes ........................................39
   30. Processing Key Package Attribute Values and CMS
       Content Constraints ...........................................39
   31. Attribute Scope ...............................................41
   32. Security Considerations .......................................48
   33. References ....................................................48
      33.1. Normative References .....................................48
      33.2. Informative References ...................................51
   Appendix A. ASN.1 Module ..........................................52
   Authors' Addresses ................................................68

Top      ToC       Page 3 
1.  Introduction

   This document defines key management attributes used by the National
   Security Agency (NSA).  The attributes can appear in asymmetric
   and/or symmetric key packages as well as the Cryptographic Message
   Syntax (CMS) content types that subsequently envelope the key
   packages.

   This document contains definitions for new attributes as well as
   previously defined attributes.  References are provided to the
   previously defined attributes; however, their definitions are
   included herein for convenience.

   CMS allows for arbitrary nesting of content types.  Attributes are
   also supported in various locations in content types and key
   packages, which are themselves content types (see Section 1.1).  An
   implementation that supports all of the possibilities would be
   extremely complex.  Instead of implementing the full flexibility
   supported by this document, some devices may choose to support one or
   more templates, which is a profile for a combination of CMS content
   type(s), key package, and attribute(s); see Section 19.

1.1.  Attribute Locations

   There are a number of CMS content types that support attributes
   SignedData [RFC5652], EnvelopedData [RFC5652], EncryptedData
   [RFC5652], AuthenticatedData [RFC5652], and AuthEnvelopedData
   [RFC5083] as well as ContentWithAttributes [RFC4073].  There are also
   a number of other content types defined with CONTENT-TYPE [RFC6268]
   that support attributes including AsymmetricKeyPackage [RFC5958] and
   SymmetricKeyPackage [RFC6031].

   CMS defines a number of "protecting content types" -- SignedData
   [RFC5652], EnvelopedData [RFC5652], EncryptedData [RFC5652],
   AuthenticatedData [RFC5652], and AuthEnvelopedData [RFC5083] -- that
   provide some type of security service.  There are also other CMS
   content types -- Data [RFC5652], ContentWithAttributes [RFC4073], and
   ContentCollection [RFC4073] -- that provide no security service.

   There are also different kinds of attributes in these content types:

      o  SignedData supports two kinds of attributes: signed and
         unsigned attributes in the signedAttrs and unsignedAttrs
         fields, respectively.

      o  EnvelopedData and EncryptedData each support one kind of
         attribute: unprotected attributes in the unprotectedAttrs
         field.

Top      ToC       Page 4 
      o  AuthEnvelopedData supports two kinds of attributes:
         authenticated and unauthenticated attributes in the authAttrs
         and unauthAttrs fields, respectively.  Both of these attributes
         are also unprotected (i.e., they are not encrypted); therefore,
         when referring to AuthEnvelopedData attributes, they are
         authenticated&unprotected and unauthenticated&unprotected.  For
         this specification, unauthenticated attributes MUST NOT be
         included.

      o  AuthenticatedData supports two kinds of attributes:
         authenticated and unauthenticated attributes in the authAttrs
         and unauthAttrs fields, respectively.  For this specification,
         unauthenticated attributes MUST NOT be included.

      o  ContentWithAttributes supports one kind of attribute: content
         attributes in the attrs field.

      o  AsymmetricKeyPackage supports one kind of attribute: asymmetric
         key attributes in the attributes field.  If an attribute
         appears as part of an asymmetric key package, it SHOULD appear
         in the attributes field of the AsymmetricKeyPackage.

      o  SymmetricKeyPackage supports two kinds of attributes: symmetric
         key and symmetric key package attributes in the sKeyAttrs and
         sKeyPkgAttrs fields, respectively.  Note that [RFC6031]
         prohibits the same attribute from appearing in both locations
         in the same SymmetricKeyPackage.

   Note that this specification updates the following information object
   sets SignedAttributesSet, UnsignedAttributes,
   UnprotectedEnvAttributes, UnprotectedEncAttributes, AuthAttributeSet,
   UnauthAttributeSet, AuthEnvDataAttributeSet,
   UnauthEnvDataAttributeSet, and ContentAttributeSet from [RFC6268] as
   well as OneAsymmetricKeyAttributes from [RFC5958], SKeyPkgAttributes
   from [RFC6031], and SKeyAttributes from [RFC6031] to constrain the
   permissible locations for attributes.  See Appendix A for the ASN.1
   for the information object sets.

1.2.  ASN.1 Notation

   The attributes defined in this document use 2002 ASN.1 [X.680]
   [X.681] [X.682] [X.683].  The attributes MUST be DER [X.690] encoded.

   Each of the attributes has a single attribute value instance in the
   values set.  Even though the syntax is defined as a set, there MUST
   be exactly one instance of AttributeValue present.  Further, the
   SignedAttributes, UnsignedAttributes, UnprotectedAttributes,
   AuthAttributes, and UnauthAttributes are also defined as a set, and

Top      ToC       Page 5 
   this set MUST include only one instance of any particular type of
   attribute.  That is, any object identifier appearing in AttributeType
   MUST only appear one time in the set of attributes.

   SignedData, EnvelopedData, EncryptedData, AuthenticatedData,
   AuthEnvelopedData, and ContentWithAttributes were originally defined
   using the 1988 version of ASN.1.  These definitions were updated to
   the 2008 version of ASN.1 by [RFC6268].  None of the new 2008 ASN.1
   tokens are used; this allows 2002 compilers to compile 2008 ASN.1.
   AsymmetricKeyPackage and SymmetricKeyPackage are defined using the
   2002 ASN.1.

   [RFC5652] and [RFC2634] define generally useful attributes for CMS
   using the 1988 version of ASN.1.  These definitions were updated to
   the 2008 version of ASN.1 by [RFC6268] and the 2002 version of ASN.1
   by [RFC5911], respectively.  [RFC4108] and [RFC6019] also defined
   attributes using the 1988 version of ASN.1, which this document uses.
   Both were updated by [RFC5911] to the 2002 ASN.1.  Refer to
   [RFC2634], [RFC4108], [RFC5652], and [RFC6019] for the attribute's
   semantics, but refer to [RFC5911] or [RFC6268] for the attribute's
   ASN.1 syntax.

1.3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   Attribute Scope: The scope of an attribute is the compilation of
   keying material to which the attribute value is assigned.  The scope
   of each attribute is determined by its placement within the key
   package or content collection.  See Section 31.

   SIR: Source Intermediary Receiver is a model with three entities:

      o  A source initiates the delivery of a key to one or more
         receivers.  It may wrap or encrypt the key for delivery.  This
         is expected to be the common case, since a cleartext key is
         vulnerable to exposure and compromise.  If the sender is to
         encrypt the key for delivery, it must know how to encrypt the
         key so that the receiver(s) can decrypt it.  A sender may also
         carry out any of the functions of an intermediary.

         *  The original key package creators are sometimes referred to
            as key source authorities.  These entities create the
            symmetric and/or asymmetric key package and apply the
            initial CMS protecting layer, which is normally a SignedData

Top      ToC       Page 6 
            but sometimes an AuthenticatedData.  This initial CMS
            protecting layer is maintained through any intermediary for
            the receivers of the key package to ensure that receivers
            can validate the key source authority.

      o  An intermediary does not have access to the cleartext key.  An
         intermediary may perform source authentication on key packages
         and may append or remove management information related to the
         package.  It may encapsulate the encrypted key packages in
         larger packages that contain other user data destined for later
         intermediaries or receivers.

      o  A receiver has access to the cleartext key. If the received key
         package is encrypted, it can unwrap or decrypt the encrypted
         key to obtain the cleartext key.  A receiver may be the final
         destination of the cryptographic product.  An element that acts
         as a receiver and is not the final destination of the key
         package may also act as a sender or as an intermediary.  After
         receiving a key, a receiver may encrypt the received key for
         local storage.

   NOTE: As noted in Section 1, a receiver can be tailored to support a
   particular combination of CMS content type(s), key package, and
   attribute(s) resulting in less-complex implementations.  All of these
   tailored receivers can be supported by a common key management
   infrastructure that uses this specification; this also can yield
   efficiencies in generation and provisioning.  Senders and
   intermediaries that have to understand multiple tailored receivers
   get the efficiency of a common specification language and modular
   implementation, as opposed to needing stove-piped processing for each
   different receiver.

2.  CMS-Defined Attributes

   The following attributes are defined for [RFC5652]:

      o  content-type [RFC5652] [RFC5911] [RFC6268] uniquely specifies
         the CMS content type.  This attribute MUST be included as a
         signed, authenticated, or authenticated&unprotected attribute.

      o  message-digest [RFC5652] [RFC5911] [RFC6268] is the message
         digest of the encapsulated content calculated using the
         signer's message digest algorithm.  As specified in [RFC5652],
         it must be included as a signed attribute and an authenticated
         attribute; as specified in [RFC5652], it must not be an
         unsigned attribute, unauthenticated attribute, or unprotected

Top      ToC       Page 7 
         attribute; as specified in [RFC5083], it should not be included
         as an authenticated&unprotected attribute in AuthEnvelopedData.
         This attribute MUST NOT be included elsewhere.

      o  content-hints [RFC2634] [RFC5911] [RFC6268] identifies the
         innermost content when multiple layers of encapsulation have
         been applied.  Every instance of SignedData, AuthenticatedData,
         and AuthEnvelopedData that does not directly encapsulate a
         SymmetricKeyPackage, an AsymmetricKeyPackage, or an
         EncryptedKeyPackage [RFC6032] MUST include this attribute.

3.  Community Identifiers

   The community-identifiers attribute, defined in [RFC4108] and
   [RFC5911], lists the communities that are authorized recipients of
   the signed content.  It can appear as a signed, authenticated,
   authenticated&unprotected, or content attribute.  This attribute MUST
   be supported.

   The 2002 ASN.1 syntax for the community-identifiers attribute is
   included for convenience:

     aa-communityIdentifiers ATTRIBUTE ::= {
       TYPE CommunityIdentifiers
       IDENTIFIED BY id-aa-communityIdentifiers }

     id-aa-communityIdentifiers OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       smime(16) aa(2) 40 }

     CommunityIdentifiers ::= SEQUENCE OF CommunityIdentifier

     CommunityIdentifier ::= CHOICE {
       communityOID  OBJECT IDENTIFIER,
       hwModuleList  HardwareModules }

     HardwareModules ::= SEQUENCE {
       hwType           OBJECT IDENTIFIER,
       hwSerialEntries  SEQUENCE OF HardwareSerialEntry }

     HardwareSerialEntry ::= CHOICE {
       all    NULL,
       single OCTET STRING,
       block  SEQUENCE {
                low OCTET STRING,
                high OCTET STRING } }

   Consult [RFC4108] for the attribute's semantics.

Top      ToC       Page 8 
4.  Key Province Attribute

   The key-province-v2 attribute identifies the scope, range, or
   jurisdiction in which the key is to be used.  The key-province-v2
   attribute MUST be present as a signed attribute or an authenticated
   attribute in the innermost CMS protection content type that provides
   authentication (i.e., SignedData, AuthEnvelopedData, or
   AuthenticatedData) and encapsulates a symmetric key package or an
   asymmetric key package.

   The key-province attribute has the following syntax:

     aa-keyProvince-v2 ATTRIBUTE ::= {
       TYPE KeyProvinceV2
       IDENTIFIED BY id-aa-KP-keyProvinceV2 }

     id-aa-KP-keyProvinceV2 OBJECT IDENTIFIER ::=
       { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
         dod(2) infosec(1) attributes(5) 71 }

     KeyProvinceV2 ::= OBJECT IDENTIFIER

5.  Binary Signing Time

   The binary-signing-time attribute, defined in [RFC6019] and
   [RFC6268], specifies the time at which the signature or the Message
   Authentication Code (MAC) was applied to the encapsulated content.
   It can appear as a signed, authenticated, or
   authenticated&unprotected attribute.

   The 2002 ASN.1 syntax is included for convenience:

     aa-binarySigningTime ATTRIBUTE ::= {
       TYPE BinarySigningTime
       IDENTIFIED BY id-aa-binarySigningTime }

     id-aa-binarySigningTime OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       smime(16) aa(2) 46 }

     BinarySigningTime ::= BinaryTime

     BinaryTime ::= INTEGER (0..MAX)

   Consult [RFC6019] for the binary-signing-time attribute's semantics.

Top      ToC       Page 9 
6.  Manifest

   The manifest attribute lists the short titles of all the Transmission
   Security Nomenclature (TSEC-Nomenclature) attributes from inner key
   packages.  It MUST only appear as an outermost signed, authenticated,
   or authenticated&unprotected attribute.  If a short title is repeated
   in inner packages, it need only appear once in the manifest
   attribute.  The manifest attribute MUST NOT appear in the same level
   as the TSEC-Nomenclature from Section 10.

   The manifest attribute has the following syntax:

     aa-manifest ATTRIBUTE ::= {
       TYPE Manifest
       IDENTIFIED BY id-aa-KP-manifest }

     id-aa-KP-manifest OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1)
       gov(101) dod(2) infosec(1) attributes(5) 72 }

     Manifest ::= SEQUENCE SIZE (1..MAX) OF ShortTitle

7.  Key Algorithm

   The key-algorithm attribute indirectly specifies the size and format
   of the keying material in the skey field of a symmetric key package,
   which is defined in [RFC6031].  It can appear as a symmetric key,
   symmetric key package, signed, authenticated,
   authenticated&unprotected, or content attribute.  If this attribute
   appears as a signed attribute, then all of the keying material within
   the SignedData content MUST be associated with the same algorithm.
   If this attribute appears as an authenticated or
   authenticated&unprotected attribute, then all of the keying material
   within the AuthenticatedData or AuthEnvelopedData content type MUST
   be associated with the same algorithm.  If this attribute appears as
   a content attribute, then all of the keying material within the
   collection MUST be associated with the same algorithm.  If both the
   key-wrap-algorithm (Section 24) and key-algorithm attributes apply to
   an sKey, then the key-algorithm attribute refers to the decrypted
   value of sKey rather than to the content of sKey itself.  This
   attribute MUST be supported.

   The key-algorithm attribute has the following syntax:

     aa-keyAlgorithm ATTRIBUTE ::= {
       TYPE KeyAlgorithm
       IDENTIFIED BY id-kma-keyAlgorithm }

Top      ToC       Page 10 
     id-kma-keyAlgorithm OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1)
       gov(101) dod(2) infosec(1) keying-material-attributes(13) 1 }

     KeyAlgorithm ::= SEQUENCE {
       keyAlg            OBJECT IDENTIFIER,
       checkWordAlg  [1] OBJECT IDENTIFIER OPTIONAL,
       crcAlg        [2] OBJECT IDENTIFIER OPTIONAL }

   The fields in the key-algorithm attribute have the following
   semantics:

      o  keyAlg specifies the size and format of the keying material.

      o  If the particular key format supports more than one check-word
         algorithm, then the OPTIONAL checkWordAlg identifier indicates
         which check-word algorithm was used to generate the check word
         that is present.  If the check-word algorithm is implied by the
         key algorithm, then the checkWordAlg field SHOULD be omitted.

      o  If the particular key format supports more than one Cyclic
         Redundancy Check (CRC) algorithm, then the OPTIONAL crcAlg
         identifier indicates which CRC algorithm was used to generate
         the value that is present.  If the CRC algorithm is implied by
         the key algorithm, then the crcAlg field SHOULD be omitted.

   The keyAlg identifier, the checkWordAlg identifier, and the crcAlg
   identifier are object identifiers.  The use of an object identifier
   accommodates any algorithm from any registry.

   The format of the keying material in the skey field of a symmetric
   key package will not match this attribute if the keying material is
   split (see Section 18 for a discussion of the split-identifier
   attribute).  In this situation, this attribute identifies the format
   of the keying material once the two splits are combined.

   Due to multiple layers of encapsulation or the use of content
   collections, the key-algorithm attribute can appear in more than one
   location in the overall key package.  When there are multiple
   occurrences of the key-algorithm attribute within the same scope, the
   keyAlg field MUST match in all instances.  The OPTIONAL checkWordAlg
   and crcAlg fields can be omitted in the key-algorithm attribute when
   it appears as a signed, authenticated, authenticated&unprotected, or
   content attribute.  However, if these optional fields are present,
   they MUST also match the other occurrences within the same scope.
   Receivers MUST reject any key package that fails these consistency
   checks.

Top      ToC       Page 11 
8.  User Certificate

   The user-certificate attribute specifies the type, format, and value
   of an X.509 certificate and is used in asymmetric key package's
   attributes field.  This attribute can appear as an asymmetric key
   attribute.  This attribute MUST NOT appear in an asymmetric key
   package attributes field that includes the other-certificate-formats
   attribute.  Symmetric key packages do not contain any certificates,
   so the user-certificate attribute MUST NOT appear in a symmetric key
   package.  The user-certificate attribute MUST NOT appear as a signed,
   authenticated, authenticated&unprotected, or content attribute.  This
   attribute MUST be supported.

   The syntax is taken from [X.509] but redefined using the ATTRIBUTE
   CLASS from [RFC5912].  The user-certificate attribute has the
   following syntax:

     aa-userCertificate ATTRIBUTE ::= {
       TYPE Certificate
       EQUALITY MATCHING RULE certificateExactMatch
       IDENTIFIED BY id-at-userCertificate }

     id-at-userCertificate OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) ds(5) attributes(4) 36 }

   Since the user-certificate attribute MUST NOT appear as a signed,
   authenticated, authenticated&unprotected, or content attribute, an
   asymmetric key package cannot include multiple occurrences of the
   user-certificate attribute within the same scope.  Receivers MUST
   reject any asymmetric key package in which the user-certificate
   attribute appears as a signed, authenticated,
   authenticated&unprotected, or content attribute.

9.  Key Package Receivers

   The key-package-receivers-v2 attribute indicates the intended
   audience for the key package.  The key-package-receivers-v2 attribute
   is not intended for access control decisions; rather, intermediate
   systems may use this attribute to make routing and relaying
   decisions.  If the receiver is not listed, it will not be able to
   decrypt the package; therefore, the receiver SHOULD reject the key
   package if the key-package-receivers-v2 attribute is present and they
   are not listed as an intended receiver.  The key-package-receivers-v2
   attribute can be used as a signed, authenticated,
   authenticated&unprotected, or content attribute.  If the key-package-
   receivers-v2 attribute is associated with a collection, then the
   named receivers MUST be able to receive all of the key packages
   within the collection.  This attribute MUST be supported.

Top      ToC       Page 12 
   The key-package-receivers-v2 attribute has the following syntax:

     aa-keyPackageReceivers-v2 ATTRIBUTE ::= {
       TYPE KeyPkgReceiversV2
       IDENTIFIED BY id-kma-keyPkgReceiversV2 }

     id-kma-keyPkgReceiversV2 OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
       dod(2) infosec(1) keying-material-attributes(13) 16 }

     KeyPkgReceiversV2 ::= SEQUENCE SIZE (1..MAX) OF KeyPkgReceiver

     KeyPkgReceiver ::= CHOICE {
       sirEntity  [0] SIREntityName,
       community  [1] CommunityIdentifier }

   The key-package-receivers-v2 attribute contains a list of receiver
   identifiers.  The receiver identifier is either a SIREntityName
   [RFC7191] or a CommunityIdentifier (see Section 3).  The
   SIREntityName syntax does not impose any particular structure on the
   receiver identifier, but it does require registration of receiver
   identifier types.  The nameType ensures that two receiver identifiers
   of different types that contain the same values are not interpreted
   as equivalent.  Name types are expected to be defined that represent
   several different granularities.  For example, one name type will
   represent the receiver organization.  At a finer granularity, the
   name type will identify a specific cryptographic device, perhaps
   using a manufacturer identifier and serial number.

   If a receiver does not recognize a particular nameType or a community
   identifier, then keying material within the scope of the unrecognized
   nameType or community identifier MUST NOT be used in any manner.
   However, the receiver need not discard the associated key package.
   Since many cryptographic devices are programmable, a different
   firmware load may recognize the nameType.  Likewise, a change in the
   configuration may lead to the recognition of a previously
   unrecognized community identifier.  Therefore, the receiver may
   retain the key package, but refuse to use it for anything with a
   firmware load that does not recognize the nameType or a configuration
   that does not recognize the community identifier.

   Whenever a key package is saved for later processing due to an
   unrecognized nameType or community identifier, subsequent processing
   MUST NOT rely on any checks that were made the first time the key
   package processing was attempted.  That is, the subsequent processing
   MUST include the full complement of checks.  Further, a receipt for
   the packages MUST NOT be generated unless all of these checks are
   successfully completed.

Top      ToC       Page 13 
   Due to multiple layers of encapsulation or the use of content
   collections, the key-package-receivers-v2 attribute can appear in
   more than one location in the overall key package.  When that
   happens, each occurrence is evaluated independently.

   In a content collection, each member of the collection might contain
   its own signed, authenticated, authenticated&unprotected, or content
   attribute that includes a key-package-receivers-v2 attribute.  In
   this situation, each member of the collection is evaluated
   separately, and any member that includes an acceptable receiver
   SHOULD be retained.  Other members can be rejected or retained for
   later processing with a different firmware load.

10.  TSEC Nomenclature

   The Telecommunications Security Nomenclature (TSEC-Nomenclature)
   attribute provides the name for a piece of keying material, which
   always includes a printable string called a "short title" (see
   below).  The TSEC-Nomenclature attribute also contains other
   identifiers when the shortTitle is insufficient to uniquely name a
   particular piece of keying material.  This attribute can appear as a
   symmetric key, symmetric key package, asymmetric key, signed,
   authenticated, authenticated&unprotected, or content attribute.  If
   this attribute appears in the sKeyAttrs field, the editionID,
   registerID, and segmentID attribute fields MUST NOT be ranges.  If
   this attribute appears as a signed, authenticated,
   authenticated&unprotected, or content attribute, all of the keying
   material within the associated content MUST have the same shortTitle,
   and the attribute value MUST contain only a shortTitle.  That is,
   when this attribute appears as a signed, authenticated,
   authenticated&unprotected, or content attribute, all of the optional
   fields MUST be absent.  If this attribute is associated with a
   collection, all of the keying material within the collection MUST
   have the same shortTitle; however, the editionID, registerID, and
   segmentID will be different for each key package in the collection.
   This attribute MUST be supported.

   The TSEC-Nomenclature attribute has the following syntax:

     aa-tsecNomenclature ATTRIBUTE ::= {
       TYPE TSECNomenclature
       IDENTIFIED BY id-kma-TSECNomenclature }

     id-kma-TSECNomenclature OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
       dod(2) infosec(1) keying-material-attributes(13) 3 }

Top      ToC       Page 14 
     TSECNomenclature ::= SEQUENCE {
       shortTitle  ShortTitle,
       editionID   EditionID OPTIONAL,
       registerID  RegisterID OPTIONAL,
       segmentID   SegmentID OPTIONAL }

     ShortTitle ::= PrintableString

     EditionID ::= CHOICE {
       char CHOICE {
           charEdition       [1] CharEdition,
           charEditionRange  [2] CharEditionRange }
       num CHOICE {
           numEdition        [3] NumEdition,
           numEditionRange   [4] NumEditionRange } }

     CharEdition ::= PrintableString

     CharEditionRange ::= SEQUENCE {
       firstCharEdition  CharEdition,
       lastCharEdition   CharEdition }

     NumEdition ::= INTEGER (0..308915776)

     NumEditionRange ::= SEQUENCE {
       firstNumEdition  NumEdition,
       lastNumEdition   NumEdition }

     RegisterID ::= CHOICE {
       register       [5] Register,
       registerRange  [6] RegisterRange }

     Register ::= INTEGER (0..2147483647)

     RegisterRange ::= SEQUENCE {
       firstRegister  Register,
       lastRegister   Register }

     SegmentID ::= CHOICE {
       segmentNumber  [7] SegmentNumber,
       segmentRange   [8] SegmentRange }

     SegmentNumber ::= INTEGER (1..127)

     SegmentRange ::= SEQUENCE {
       firstSegment  SegmentNumber,
       lastSegment   SegmentNumber }

Top      ToC       Page 15 
   The fields in the TSEC-Nomenclature attribute have the following
   semantics:

      o  The shortTitle consists of up to 32 alphanumeric characters.
         shortTitle processing always uses the value in its entirety.

      o  The editionID is OPTIONAL, and the editionIdentifier is used to
         distinguish accountable items.  The editionID consists of
         either six alphanumeric characters or an integer.  When
         present, the editionID is either a single value or a range.
         The integer encoding should be used when it is important to
         keep key package size to a minimum.

      o  The registerID is OPTIONAL.  For electronic keying material,
         the registerID is usually omitted.  The registerID is an
         accounting number assigned to identify Communications Security
         (COMSEC) material.  The registerID is either a single value or
         a range.

      o  The segmentID is OPTIONAL, and it distinguishes the individual
         symmetric keys delivered in one edition.  A unique
         segmentNumber is assigned to each key in an edition.  The
         segmentNumber is set to one for the first item in each edition,
         and it is incremented by one for each additional item within
         that edition.  The segmentID is either a single value or a
         range.

   The order that the keying material will appear in the key package is
   illustrated by the following example: a cryptographic device may
   require fresh keying material every day, an edition represents the
   keying material for a single month, and the segments represent the
   keying material for a day within that month.  Consider a key package
   that contains the keying material for July and August; it will
   contain keying material for 62 days.  The keying material will appear
   in the following order: Edition 1, Segment 1; Edition 1, Segment 2;
   Edition 1, Segment 3; ...; Edition 1, Segment 31; Edition 2,
   Segment 1; Edition 2, Segment 2; Edition 2, Segment 3; ...;
   Edition 2, Segment 31.

   Due to multiple layers of encapsulation or the use of content
   collections, the TSEC-Nomenclature attribute can appear in more than
   one location in the overall key package.  When there are multiple
   occurrences of the TSEC-Nomenclature attribute within the same scope,
   the shortTitle field MUST match in all instances.  Receivers MUST
   reject any key package that fails these consistency checks.

Top      ToC       Page 16 
   When the manifest attribute from Section 6 is included in an outer
   layer, the ShortTitle field values present in TSEC-Nomenclature
   attributes MUST be one of the values in the manifest attribute.
   Receivers MUST reject any key package that fails this consistency
   check.

11.  Key Purpose

   The key-purpose attribute specifies the intended purpose of the key
   material.  It can appear as a symmetric key, symmetric key package,
   asymmetric key, signed, authenticated, authenticated&unprotected, or
   content attribute.  If the key-purpose attribute appears as a signed,
   authenticated, authenticated&unprotected, or content attribute, then
   all of the keying material within the associated content MUST have
   the same key purpose value.

   The key-purpose attribute has the following syntax:

     aa-keyPurpose ATTRIBUTE ::= {
       TYPE KeyPurpose
       IDENTIFIED BY id-kma-keyPurpose }

     id-kma-keyPurpose OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
       dod(2) infosec(1) keying-material-attributes(13) 13 }

     KeyPurpose ::= ENUMERATED {
       n-a    (0),   -- Not Applicable
       A     (65),   -- Operational
       B     (66),   -- Compatible Multiple Key
       L     (76),   -- Logistics Combinations
       M     (77),   -- Maintenance
       R     (82),   -- Reference
       S     (83),   -- Sample
       T     (84),   -- Training
       V     (86),   -- Developmental
       X     (88),   -- Exercise
       Z     (90),   -- "On the Air" Testing
       ... -- Expect additional key purpose values -- }

   Due to multiple layers of encapsulation or the use of content
   collections, the key-purpose attribute can appear in more than one
   location in the overall key package.  When there are multiple
   occurrences of the key-purpose attribute within the same scope, all
   fields within the attribute MUST contain exactly the same values.
   Receivers MUST reject any key package that fails these consistency
   checks.

Top      ToC       Page 17 
12.  Key Use

   The key-use attribute specifies the intended use of the key material.
   It can appear as a symmetric key, symmetric key package, asymmetric,
   signed, authenticated, authenticated&unprotected, or content
   attribute.  If the key-use attribute appears as a signed,
   authenticated, authenticated&unprotected, or content attribute, then
   all of the keying material within the associated content MUST have
   the same key use value.

   The key-use attribute has the following syntax:

     aa-key-Use ATTRIBUTE ::= {
       TYPE KeyUse
       IDENTIFIED BY id-kma-keyUse }

     id-kma-keyUse OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
       dod(2) infosec(1) keying-material-attributes(13) 14 }

     KeyUse ::= ENUMERATED {
       n-a    (0),    -- Not applicable
       ffk    (1),    -- FIREFLY/CROSSTALK Key (Basic Format)
       kek    (2),    -- Key Encryption Key
       kpk    (3),    -- Key Production Key
       msk    (4),    -- Message Signature Key
       qkek   (5),    -- QUADRANT Key Encryption Key
       tek    (6),    -- Traffic Encryption Key
       tsk    (7),    -- Transmission Security Key
       trkek  (8),    -- Transfer Key Encryption Key
       nfk    (9),    -- Netted FIREFLY Key
       effk  (10),    -- FIREFLY Key (Enhanced Format)
       ebfk  (11),    -- FIREFLY Key (Enhanceable Basic Format)
       aek   (12),    -- Algorithm Encryption Key
       wod   (13),    -- Word of Day
       kesk (246),    -- Key Establishment Key
       eik  (247),    -- Entity Identification Key
       ask  (248),    -- Authority Signature Key
       kmk  (249),    -- Key Modifier Key
       rsk  (250),    -- Revocation Signature Key
       csk  (251),    -- Certificate Signature Key
       sak  (252),    -- Symmetric Authentication Key
       rgk  (253),    -- Random Generation Key
       cek  (254),    -- Certificate Encryption Key
       exk  (255),    -- Exclusion Key
       ... -- Expect additional key use values -- }

Top      ToC       Page 18 
   The values for the key-use attribute have the following semantics:

      o  ffk: A FIREFLY/CROSSTALK key is used to establish a Key
         Establishment Key (KEK) or a Transmission Encryption Key (TEK)
         between two parties.  The KEK or TEK generated from the
         exchange is used with a symmetric encryption algorithm.  This
         key use value is associated with keys in the basic format.

      o  kek: A Key Encryption Key is used to encrypt or decrypt other
         keys for transmission or storage.

      o  kpk: A Key Production Key is used to initialize a keystream
         generator for the production of other electronically generated
         keys.

      o  msk: A Message Signature Key is used in a digital signature
         process that operates on a message to assure message source
         authentication, message integrity, and non-repudiation.

      o  qkek: QUADRANT Key Encryption Key is one part of a tamper-
         resistance solution.

      o  tek: A Traffic Encryption Key is used to encrypt plaintext, to
         superencrypt previously encrypted data, and/or to decrypt
         ciphertext.

      o  tsk: A Transmission Security Key is used to protect
         transmissions from interception and exploitation by means other
         than cryptanalysis.

      o  trkek: Transfer Key Encryption Key.  The keys used to protect
         communications with an intermediary.

      o  nfk: A Netted FIREFLY Key is a FIREFLY key that has an edition
         number associated with it.  When rekeyed, it is incremented,
         preventing communications with FIREFLY key of previous
         editions.  This edition number is maintained within a universal
         edition.

      o  effk: Enhanced FIREFLY Key is used to establish a KEK or a TEK
         between two parties.  The KEK or TEK generated from an exchange
         is used with a symmetric encryption algorithm.  This key use
         value is associated with keys in the enhanced format.

Top      ToC       Page 19 
      o  ebfk: Enhanceable Basic FIREFLY Key is used to establish a KEK
         or a TEK between two parties.  The KEK or TEK generated from an
         exchange is used with a symmetric encryption algorithm.  This
         key use value is associated with keys in the enhanceable basic
         format.

      o  aek: An Algorithm Encryption Key is used to encrypt or decrypt
         an algorithm implementation as well as other functionality in
         the implementation.

      o  wod: A key used to generate the Word of the Day (WOD).

      o  kesk: A Key Establishment Key is an asymmetric key set (e.g.,
         public/private/parameters) used to enable the establishment of
         symmetric key(s) between entities.

      o  eik: An Entity Identification Key is an asymmetric key set
         (e.g., public/private/parameters) used to identify one entity
         to another for access control and other similar purposes.

      o  ask: An Authority Signature Key is an asymmetric key set (e.g.,
         public/private/parameters) used by designated authorities to
         sign objects such as Trust Anchor Management Protocol (TAMP)
         messages and firmware packages.

      o  kmk: A Key Modifier Key is a symmetric key used to modify the
         results of the process that forms a symmetric key from a public
         key exchange process.

      o  rsk: A Revocation Signature Key is an asymmetric key set (e.g.,
         public/private/parameters) used to sign and authenticate
         revocation lists and compromised key lists.

      o  csk: A Certificate Signature Key is an asymmetric key set
         (e.g., public/private/parameters) used to sign and authenticate
         public key certificates.

      o  sak: A Symmetric Authentication Key is used in a MAC algorithm
         to provide message integrity.  Differs from a Message Signature
         Key in that it is symmetric key material and it does not
         provide source authentication or non-repudiation.

      o  rgk: Random Generation Key is a key used to seed a
         deterministic pseudorandom number generator.

      o  cek: A Certificate Encryption Key is used to encrypt public key
         certificates to support privacy.

Top      ToC       Page 20 
      o  exk: An Exclusion Key is a symmetric key used to
         cryptographically subdivide a single large security domain into
         smaller segregated domains.

   Due to multiple layers of encapsulation or the use of content
   collections, the key-use attribute can appear in more than one
   location in the overall key package.  When there are multiple
   occurrences of the key-use attribute within the same scope, all
   fields within the attribute MUST contain exactly the same values.
   Receivers MUST reject any key package that fails these consistency
   checks.

13.  Transport Key

   The transport-key attribute identifies whether an asymmetric key is a
   transport key or an operational key (i.e., whether or not the key can
   be used as is).  It can appear as an asymmetric key, signed,
   authenticated, authenticated&unprotected, or content attribute.  If
   the transport-key attribute appears as a signed, authenticated,
   authenticated&unprotected, or content attribute, then all of the
   keying material within the associated content MUST have the same
   operational/transport key material.

     aa-transportKey ATTRIBUTE ::= {
       TYPE TransOp
       IDENTIFIED BY id-kma-transportKey }

     id-kma-transportKey OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
       dod(2) infosec(1) keying-material-attributes(13) 15 }

     TransOp ::= ENUMERATED {
       transport    (1),
       operational  (2) }

   Due to multiple layers of encapsulation or the use of content
   collections, the transport-key attribute can appear in more than one
   location in the overall key package.  When there are multiple
   occurrences of the transport-key attribute within the same scope, all
   fields within the attribute MUST contain exactly the same values.
   Receivers MUST reject any key package that fails these consistency
   checks.

14.  Key Distribution Period

   The key-distribution-period attribute indicates the period of time
   that the keying material is intended for distribution.  Keying
   material is often distributed before it is intended to be used.  Time

Top      ToC       Page 21 
   of day must be represented in Coordinated Universal Time (UTC).  It
   can appear as a symmetric key, symmetric key package, asymmetric key,
   signed, authenticated, authenticated&unprotected, or content
   attribute.  If the key-distribution-period attribute appears as a
   signed, authenticated, authenticated&unprotected, or content
   attribute, then all of the keying material within the content MUST
   have the same key distribution period.

   The key-distribution-period attribute has the following syntax:

     aa-keyDistributionPeriod ATTRIBUTE ::= {
       TYPE KeyDistPeriod
       IDENTIFIED BY id-kma-keyDistPeriod }

     id-kma-keyDistPeriod OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
       dod(2) infosec(1) keying-material-attributes(13) 5 }

     KeyDistPeriod ::= SEQUENCE {
       doNotDistBefore  [0] BinaryTime OPTIONAL,
       doNotDistAfter       BinaryTime }

     BinaryTime ::= INTEGER

   The fields in the key-distribution-period attribute have the
   following semantics:

      o  The doNotDistBefore field is OPTIONAL, and when it is present,
         the keying material SHOULD NOT be distributed before the date
         and time provided.

      o  The doNotDistAfter field is REQUIRED, and the keying material
         SHOULD NOT be distributed after the date and time provided.

   When the key-distribution-period attribute is associated with a
   collection of keying material, the distribution period applies to all
   of the keys in the collection.  None of the keying material in the
   collection SHOULD be distributed outside the indicated period.

   Due to multiple layers of encapsulation or the use of content
   collections, the key-distribution-period attribute can appear in more
   than one location in the overall key package.  When there are
   multiple occurrences of the key-distribution-period attribute within
   the same scope, all of the included attribute fields MUST contain
   exactly the same value.  However, if the doNotDistBefore field is
   absent in an inner layer, a value MAY appear in an outer layer
   because the outer layer constrains the inner layer.  Receivers MUST
   reject any key package that fails these consistency checks.


Next RFC Part