tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7906

 
 
 

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

Part 2 of 3, p. 22 to 40
Prev RFC Part       Next RFC Part

 


prevText      Top      ToC       Page 22 
15.  Key Validity Period

   The key-validity-period attribute indicates the period of time that
   the keying material is intended for use.  Time 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-validity-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 validity
   period.

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

     aa-keyValidityPeriod ATTRIBUTE ::= {
       TYPE KeyValidityPeriod
       IDENTIFIED BY id-kma-keyValidityPeriod }

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

     KeyValidityPeriod ::= SEQUENCE {
       doNotUseBefore      BinaryTime,
       doNotUseAfter       BinaryTime OPTIONAL }

     BinaryTime ::= INTEGER

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

      o  The doNotUseBefore field is REQUIRED, and the keying material
         SHOULD NOT be used before the date and time provided.

      o  The doNotUseAfter field is OPTIONAL, and when it is present,
         the keying material SHOULD NOT be used after the date and time
         provided.

   For a key package that is being used for rekey, the doNotUseAfter
   field MAY be required by some templates even though the syntax is
   OPTIONAL.

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

Top      Up      ToC       Page 23 
   The key-validity-period attribute described in this section and the
   key-duration attribute described in the next section provide
   complementary functions.  The key-validity-period attribute provides
   explicit date and time values, which indicate the beginning and
   ending of the keying material usage period.  The key-duration
   attribute provides the maximum length of time that the keying
   material SHOULD be used.  If both attributes are provided, this
   duration MAY occur at any time within the specified period, but the
   limits imposed by both attributes SHOULD be honored.

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

16.  Key Duration

   The key-duration attribute indicates the maximum period of time that
   the keying material is intended for use.  The date and time that the
   duration begins is not specified, but the maximum amount of time that
   the keying material can be used to provide security services is
   specified.  It can appear as a symmetric key, symmetric key package,
   asymmetric key, signed, authenticated, authenticated&unprotected, or
   content attribute.  If the key-duration 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 duration.

   The key-duration attribute has the following syntax:

     aa-keyDurationPeriod ATTRIBUTE ::= {
       TYPE KeyDuration
       IDENTIFIED BY id-kma-keyDuration }

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

     KeyDuration ::= CHOICE {
       hours      [0] INTEGER (1..ub-KeyDuration-hours),
       days           INTEGER (1..ub-KeyDuration-days),
       weeks      [1] INTEGER (1..ub-KeyDuration-weeks),
       months     [2] INTEGER (1..ub-KeyDuration-months),
       years      [3] INTEGER (1..ub-KeyDuration-years) }

Top      Up      ToC       Page 24 
     ub-KeyDuration-hours  INTEGER ::=  96
     ub-KeyDuration-days   INTEGER ::= 732
     ub-KeyDuration-weeks  INTEGER ::= 104
     ub-KeyDuration-months INTEGER ::=  72
     ub-KeyDuration-years  INTEGER ::= 100

   The key-validity-period attribute described in the previous section
   and the key-duration attribute described in this section provide a
   complementary function.  The relationship between these attributes is
   described in the previous section.

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

17.  Classification

   The classification attribute indicates level of classification.  The
   classification attribute specifies the aggregate classification of
   the package content.  It can appear as a symmetric key, symmetric key
   package, asymmetric key, signed, authenticated,
   authenticated&unprotected, or content attribute.  If the
   classification attribute appears as a signed, authenticated,
   authenticated&unprotected, or content attribute, then the value MUST
   represent the classification of all of the keying material within the
   content.  Encrypted layers MAY contain content at a higher
   classification that will be revealed once they are decrypted.  If the
   classification attribute is associated with a collection, then the
   sensitivity of all the data within the collection MUST be dominated
   by the classification carried in this attribute.

   The classification attribute makes use of the ESSSecurityLabel
   defined in Section 17.1 as well as [RFC2634] and [RFC5911].  The term
   "classification" is used in this document, but the term "security
   label" is used in [RFC2634].  The two terms have the same meaning.

   [RFC2634] and [RFC5911] specify an object identifier and syntax for
   the security label attribute.  The same values are used for the
   classification attribute:

     aa-classificationAttribute ATTRIBUTE ::= {
       TYPE Classification
       IDENTIFIED BY id-aa-KP-classification }

Top      Up      ToC       Page 25 
     id-aa-KP-classification OBJECT IDENTIFIER ::= id-aa-securityLabel

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

     Classification ::= ESSSecurityLabel

   The syntax of ESSSecurityLabel is not repeated here; however, see
   Section 17.1 for security label conventions that MUST be followed by
   implementations of this specification.  See [RFC2634] for a complete
   discussion of the semantics and syntax.

   When the classification attribute appears in more than one location
   in the overall key package, each occurrence is evaluated
   independently.  The content originator MUST ensure that the
   classification attribute represents the sensitivity of the plaintext
   within the content.  That is, the classification MUST dominate any
   other plaintext classification attribute value that is present
   elsewhere in the overall key package.  Note that the classification
   attribute value may exceed these other plaintext classification
   attribute values if the other attribute values within the SignerInfo,
   AuthEnvelopedData, or AuthenticatedData are themselves classified and
   warrant the higher-security label value.

   When the classification attribute appears in more than one location
   in the overall key package, each security label might be associated
   with a different security policy.  Content originators SHOULD avoid
   mixing multiple security policies in the same key package whenever
   possible, since this requires that receivers and intermediaries that
   check the classification attribute values include support for the
   union of the security policies that are present.  Failure to
   recognize an included security policy MUST result in rejection of the
   key package.

   Receivers MUST reject any key package that includes a classification
   for which the receiver's processing environment is not authorized.

17.1.  Security Label

   The ESSSecurityLabel ASN.1 type is used to represent the
   classification.  The ESSSecurityLabel is defined in Section 3.2 of
   [RFC2634].  The syntax definition is repeated here to facilitate
   discussion:

Top      Up      ToC       Page 26 
     ESSSecurityLabel ::= SET {
       security-policy-identifier SecurityPolicyIdentifier,
       security-classification    SecurityClassification OPTIONAL,
       privacy-mark               ESSPrivacyMark OPTIONAL,
       security-categories        SecurityCategories OPTIONAL }

     ESSPrivacyMark ::= CHOICE {
       pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
       utf8String   UTF8String (SIZE (1..MAX)) }

   A security policy is a set of criteria for the provision of security
   services.  The security-policy-identifier, which is an object
   identifier, is used to identify the security policy associated with
   the security label.  It indicates the semantics of the other security
   label components.

   If the key package receiver does not recognize the object identifier
   in the security-policy-identifier field and the security label
   includes a security-categories field, then the key package contents
   MUST NOT be accepted and the enclosed keying material MUST NOT be
   used.  If the key package receiver does not recognize the object
   identifier in the security-policy-identifier field and the security
   label does not include a security-categories field, then the key
   package contents MAY be accepted only if the security-classification
   field is present and it contains a value from the basic hierarchy as
   described below.

   This specification defines the use of the SecurityClassification
   field exactly as is it specified in the 1988 edition of ITU-T
   Recommendation X.411 [X.411], which states in part:

      If present, a security-classification may have one of a
      hierarchical list of values.  The basic security-classification
      hierarchy is defined in this Recommendation, but the use of these
      values is defined by the security-policy in force.  Additional
      values of security-classification, and their position in the
      hierarchy, may also be defined by a security-policy as a local
      matter or by bilateral agreement.  The basic security-
      classification hierarchy is, in ascending order: unmarked,
      unclassified, restricted, confidential, secret, top-secret.

   Implementations MUST support the basic security classification
   hierarchy.  Such implementations MAY also support other security-
   classification values; however, the placement of additional values in
   the hierarchy MUST be specified by the security policy.

Top      Up      ToC       Page 27 
   Implementations MUST NOT make access control decisions based on the
   privacy-mark.  However, information in the privacy-mark can be
   displayed to human users by devices that have displays to do so.  The
   privacy-mark length MUST NOT exceed 128 characters.  The privacy-mark
   SHALL use the PrintableString choice if all of the characters in the
   privacy-mark are members of the printable string character set.

   If present, security-categories provide further granularity for the
   keying material.  The security policy in force indicates the
   permitted syntaxes of any entries in the set of security categories.
   At most, 64 security categories may be present.  The security-
   categories have ASN.1 type SecurityCategories and further
   SecurityCategory [RFC5912], which are both repeated here to
   facilitate discussion:

     SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
                              SecurityCategory
                                {{SupportedSecurityCategories}}

     SecurityCategory {SECURITY-CATEGORY:Supported} ::= SEQUENCE {
         type      [0]  IMPLICIT SECURITY-CATEGORY.
                          &id({Supported}),
         value     [1]  EXPLICIT SECURITY-CATEGORY.
                          &Type({Supported}{@type})
     }

   Four security categories are defined and are referred to as the
   Restrictive Tag, the Enumerated Tag, the Permissive Tag, and the
   Informative Tag.  Only the Enumerated Tag and Informative Tag are
   permitted in the classification attribute.

   The Enumerated Tag is composed of one or more non-negative integers.
   Each non-negative integer represents a non-hierarchical security
   attribute that applies to the labeled content.  A security policy
   might define a large set of security categories attributes, but a
   particular key package generally contains only a few security
   categories attributes.  In this case, use of the integer
   representation is intended to minimize the size of the label.
   Security attributes enumerated by tags of this type could be
   restrictive (such as compartments) or permissive (such as release
   permissions).  Two object identifiers for the SecurityCategory type
   field have been defined, one for restrictive and one for permissive.
   The object identifiers are:

Top      Up      ToC       Page 28 
     id-enumeratedRestrictiveAttributes OBJECT IDENTIFIER ::= {
       2 16 840 1 101 2 1 8 3 4 }

     id-enumeratedPermissiveAttributes OBJECT IDENTIFIER ::= {
       2 16 840 1 101 2 1 8 3 1 }

   With both the restrictive and permissive security category types, the
   corresponding SecurityCategory value has the following ASN.1
   definition:

     EnumeratedTag ::= SEQUENCE {
       tagName          OBJECT IDENTIFIER,
       attributeList    SET OF SecurityAttribute }

     SecurityAttribute ::= INTEGER (0..MAX)

   Any security policy that makes use of security categories MUST assign
   object identifiers for each tagName, assign the set of integer values
   associated with each tagName, and specify the semantic meaning for
   each integer value.  Restrictive security attributes and permissive
   security attributes SHOULD be associated with different tagName
   object identifiers.

   The Informative Tag is composed of either a) one or more non-negative
   integers or b) a bit string.  Only the integer choice is allowed in
   this specification.  Each non-negative integer represents a non-
   hierarchical security attribute that applies to the labeled content.
   Use of the integer representation is intended to minimize the size of
   the label since a particular key package generally contains only a
   few security categories attributes, even though a security policy
   might define a large set of security categories attributes.  Security
   attributes enumerated by tags of this type are informative (i.e., no
   access control is performed).  One object identifier for the
   SecurityCategory type field has been defined and is as follows:

     id-informativeAttributes OBJECT IDENTIFIER ::= {
       2 16 840 1 101 2 1 8 3 3 }

   The corresponding SecurityCategory value has the following ASN.1
   definition:

     InformativeTag ::= SEQUENCE {
       tagName     OBJECT IDENTIFIER,
       attributes  FreeFormField }

     FreeFormField ::= CHOICE {
       bitSetAttributes    BIT STRING,
       securityAttributes  SET OF SecurityAttribute }

Top      Up      ToC       Page 29 
   Any security policy that makes use of security categories MUST assign
   object identifiers for each tagName, assign the set of integer values
   associated with each tagName, and specify the semantic meaning for
   each integer value.

18.  Split Identifier

   The key package originator may include a split-identifier attribute
   to designate that the keying material contains a split rather than a
   complete key.  It may appear as a symmetric and asymmetric key
   attribute.  The split-identifier attribute MUST NOT appear as a
   symmetric key package, signed, authenticated,
   authenticated&unprotected, or content attribute.  Split keys have two
   halves, which are called "A" and "B".  The split-identifier attribute
   indicates which half is included in the key package, and it
   optionally indicates the algorithm that is needed to combine the two
   halves.  The combine algorithm is OPTIONAL since each key algorithm
   has a default mechanism for this purpose, and the combine algorithm
   is present only if the default mechanism is not employed.

   The split-identifier attribute has the following syntax:

     aa-splitIdentifier ATTRIBUTE ::= {
       TYPE SplitID
       IDENTIFIED BY id-kma-splitID }

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

     SplitID ::= SEQUENCE {
       ENUMERATED { a(0), b(1) },
       combineAlg  AlgorithmIdentifier
                   {COMBINE-ALGORITHM, {CombineAlgorithms}} OPTIONAL }

   In most cases, the default combine algorithm will be employed; it
   makes this attribute a simple constant that identifies either the "A"
   or "B" half of the split key.  This supports implementation of some
   key distribution policies.

   Note that each split might have its own CRC, but the key and the
   check word are both recovered when the two splits are combined.

   Since the split-identifier attribute MUST NOT appear as a signed,
   authenticated, authenticated&unprotected, or content attribute, a key
   package cannot include multiple occurrences of the split-identifier

Top      Up      ToC       Page 30 
   attribute within the same scope.  Receivers MUST reject any key
   package in which the split-identifier attribute appears as a signed,
   authenticated, authenticated&unprotected, or content attribute.

19.  Key Package Type

   The key-package-type attribute is a shorthand method for specifying
   all aspects of the key package format, including which attributes are
   present and the structure of the encapsulated content or collection.
   The key-package-type attribute can be used as a signed,
   authenticated, authenticated&unprotected, or content attribute.

   Rather than implementing the full flexibility of this specification,
   some devices may implement support for one or more specific key
   package formats instantiating this specification.  Those specific
   formats are called templates and can be identified using a key-
   package-type attribute.

   The key-package-type attribute has the following syntax:

     aa-keyPackageType ATTRIBUTE ::= {
       TYPE KeyPkgType
       IDENTIFIED BY id-kma-keyPkgType }

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

     KeyPkgType ::= OBJECT IDENTIFIER

   Due to multiple layers of encapsulation or the use of content
   collections, the key-package-type attribute can appear in more than
   one location in the overall key package.  When that happens, each
   occurrence is used independently.  Since the receiver is likely to
   use the key-package-type attribute value as a decoding aid, any error
   will most likely lead to parsing problems, and these problems could
   result in many different errors being reported.

20.  Signature Usage

   The signature-usage attribute identifies the CMS content types that
   this key can be used to sign, or that are permitted to be signed by
   the end-entity key in a cert path validated by this key.  Symmetric
   key packages do not contain signature generation or signature
   validation keying material, so the signature-usage attribute MUST NOT
   appear in a symmetric key package.  For an asymmetric key package,
   the signature-usage attribute indicates the kind of objects that are
   to be signed with the private key in the package.  However, if the

Top      Up      ToC       Page 31 
   asymmetric key package contains a Certificate Signature Key, then the
   signature-usage attribute also indicates what signed objects can be
   validated using certificates that are signed by the private key in
   the asymmetric key package.  Therefore, the signature-usage attribute
   also indicates what kind of objects can be signed by the private keys
   associated with these certificates.  The signature-usage attribute
   MUST NOT appear as a signed, authenticated,
   authenticated&unprotected, or content attribute.

   The signature-usage attribute has the following syntax:

     aa-signatureUsage-v3 ATTRIBUTE ::= {
       TYPE SignatureUsage
       IDENTIFIED BY id-kma-sigUsageV3 }

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

     SignatureUsage ::= CMSContentConstraints

   The SignatureUsage structure has the same syntax as the
   CMSContentConstraints structure from [RFC6010], and it is repeated
   here for convenience.

     CMSContentConstraints ::= SEQUENCE SIZE (1..MAX) OF
                                ContentTypeConstraint

     ContentTypeGeneration ::= ENUMERATED  {
       canSource(0),
       cannotSource(1)}

     ContentTypeConstraint ::= SEQUENCE {
       contentType      CONTENT-TYPE.&id ({ContentSet|ct-Any,...}),
       canSource        ContentTypeGeneration DEFAULT canSource,
       attrConstraints  AttrConstraintList OPTIONAL }

     Constraint { ATTRIBUTE:ConstraintList } ::= SEQUENCE {
       attrType    ATTRIBUTE.&id({ConstraintList}),
       attrValues  SET SIZE (1..MAX) OF ATTRIBUTE.
                     &Type({ConstraintList}{@attrType})  }

     SupportedConstraints ATTRIBUTE ::= {SignedAttributesSet, ... }

     AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF
                            Constraint {{ SupportedConstraints }}

     NOTE: SignedAttributesSet is updated by this specification.

Top      Up      ToC       Page 32 
   The SignatureUsage contains a type of CMSContentConstraints.  One or
   more ContentTypeConstraint MUST appear in CMSContentConstraints.

   Within ContentTypeConstraint, the contentType field indicates the
   encapsulated content type identifier that can be signed with the
   signature key.  A particular content type MUST NOT appear more than
   once in the list.  The CMS protecting content types need not be
   included in the list of permitted content types as the use of CMS is
   always authorized (see [RFC6010]).

   Within ContentTypeConstraint, the canSource enumeration indicates
   whether the signature key can be used to directly sign the indicated
   content type.  If the ContentTypeConstraint is canSource (the default
   value), then the signature key can be used to directly sign the
   specified content type.  If the ContentTypeConstraint is
   cannotSource, then the signature key can only be used with the
   specified content type if it encapsulates a signature that was
   generated by an originator with a ContentTypeConstraint that is
   canSource.

   Within ContentTypeList, the attrConstraints OPTIONAL field contains a
   sequence of constraints specific to the content type.  If the
   attrConstraints field is absent, the signature key can be used to
   sign the specified content type, without any further checking.  If
   the attrConstraints field is present, then the signature key can only
   be used to sign the specified content type if all of the constraints
   for that content type are satisfied.  Content type constraints are
   checked by matching the attribute values in the attrConstraint field
   against the attribute value in the content.  The constraints succeed
   if the attribute is not present; they fail if the attribute is
   present and the value is not one of the values provided in
   attrConstraint.

   The fields of attrConstraints implement constraints specific to the
   content type.  The attrType field is an AttributeType, which is an
   object identifier of a signed attribute carried in the SignerInfo of
   the content.  The attrValues field provides one or more acceptable
   signed attribute values.  It is a set of AttributeValue.  For a
   signed content to satisfy the constraint, the SignerInfo MUST include
   a signed attribute of the type identified in the attrType field, and
   the signed attribute MUST contain one of the values in the set
   carried in attrValues.

   Since the signature-usage attribute MUST NOT appear as a signed,
   authenticated, authenticated&unprotected, or content attribute, an
   asymmetric key package cannot include multiple occurrences of the
   signature-usage attribute within the same scope.  Receivers MUST

Top      Up      ToC       Page 33 
   reject any asymmetric key package in which the signature-usage
   attribute appears as a signed, authenticated,
   authenticated&unprotected, or content attribute.

21.  Other Certificate Format

   The other-certificate-formats attribute specifies the type, format,
   and value of certificates that are not X.509 public key certificates.
   Symmetric key packages do not contain any certificates, so the other-
   certificate-formats attribute MUST NOT appear in a symmetric key
   package.  It SHOULD appear in the attributes field, when the
   publicKey field is absent and the certificate format is not X.509.
   This attribute MUST NOT appear in an attributes field that includes
   the user-certificate attribute from Section 8.  The other-
   certificate-formats attribute MUST NOT appear as a signed,
   authenticated, authenticated&unprotected, or content attribute.

   The other-certificate-formats attribute has the following syntax:

     aa-otherCertificateFormats ATTRIBUTE ::= {
       TYPE CertificateChoices
       IDENTIFIED BY id-kma-otherCertFormats }

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

     CertificateChoices ::= CHOICE {
       certificate             Certificate,
       extendedCertificate [0] IMPLICIT ExtendedCertificate,
                                        -- Obsolete
       v1AttrCert          [1] IMPLICIT AttributeCertificateV1,
                                        -- Obsolete
       v2AttrCert          [2] IMPLICIT AttributeCertificateV2,
       other               [3] IMPLICIT OtherCertificateFormat }

     OtherCertificateFormat ::= SEQUENCE {
       otherCertFormat           OBJECT IDENTIFIER,
       otherCert ANY DEFINED BY  otherCertFormat }

   The other-certificate-formats attribute makes use of the
   CertificateChoices field defined in Section 10.2.2 of [RFC5652].  The
   certificate, extendedCertificate, and v1AttrCert fields MUST be
   omitted.  The v2AttrCert field can include Version 2 Attribute
   Certificates.  The other field can include Enhanced FIREFLY
   certificates and other as yet undefined certificate formats.

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

22.  PKI Path

   The pki-path attribute includes certificates that can aid in the
   validation of the certificate carried in the user-certificate
   attribute.  Symmetric key packages do not contain any certificates,
   so the pkiPath attribute MUST NOT appear in a symmetric key package.
   It can appear as an asymmetric key, signed, authenticated,
   authenticated&unprotected, or content attribute.  It can appear in
   the attributes field, when the publicKey field is absent and the
   certificate format is X.509.  This attribute MUST NOT appear in an
   AsymmetricKeyPackage that has an other-certificate-formats attribute
   in the attributes field.  If the pki-path attribute appears as a
   signed, authenticated, authenticated&unprotected, or content
   attribute, then the value includes certificates that can be used to
   construct a certification path to all of the keying material within
   the content.  This attribute MUST be supported.

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

     aa-pkiPath ATTRIBUTE ::= {
       TYPE PkiPath
       IDENTIFIED BY id-at-pkiPath }

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

     PkiPath ::= SEQUENCE SIZE (1..MAX) OF Certificate

   The first certificate in the sequence is the subject's parent
   Certification Authority (CA).  The next certificate is that CA's
   parent, and so on.  The end-entity and trust anchor are not included
   in this attribute.

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

Top      Up      ToC       Page 35 
23.  Useful Certificates

   The useful-certificates attribute includes certificates that can aid
   in the validation of certificates associated with other parties with
   whom secure communications are anticipated.  It can appear as an
   asymmetric key, signed, authenticated, authenticated&unprotected, or
   content attribute.  For an asymmetric key that has an other-
   certificate-formats attribute (Section 21) in the attributes field,
   the useful-certificates attribute MUST NOT appear.  If the useful-
   certificates attribute appears as a signed, authenticated,
   authenticated&unprotected, or content attribute, then the value
   includes certificates that may be used to validate certificates of
   others with whom the receiver communicates.  This attribute MUST be
   supported.

   The useful-certificates attribute has the following syntax:

     aa-usefulCertificates ATTRIBUTE ::= {
       TYPE CertificateSet
       IDENTIFIED BY id-kma-usefulCerts }

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

     CertificateSet ::= SET OF CertificateChoices

   The useful-certificates attribute makes use of the CertificateSet
   field defined in Section 10.2.3 of [RFC5652].  Within the
   CertificateChoices field, the extendedCertificate and v1AttrCert
   fields MUST always be omitted.  If the userCertificate attribute from
   Section 8 is included, the other field MUST NOT be present.  If the
   other-certificate-formats attribute (Section 21) is included, the
   certificate field MUST NOT be present.

   Due to multiple layers of encapsulation or the use of content
   collections, the useful-certificates attribute can appear in more
   than one location in the overall key package.  When the useful-
   certificates attribute appears in more than one location in the
   overall key package, each occurrence is evaluated independently.

24.  Key Wrap Algorithm

   The key-wrap-algorithm attribute identifies a key wrap algorithm with
   an algorithm identifier.  It can appear as a symmetric key or
   symmetric key package attribute.  When this attribute is present in
   sKeyAttrs, it indicates that the associated sKey field contains a
   black key, which is an encrypted key, that was wrapped by the

Top      Up      ToC       Page 36 
   identified algorithm.  When this attribute is present in
   sKeyPkgAttrs, it indicates that every sKey field in that symmetric
   key package contains a black key and that all keys are wrapped by the
   same designated algorithm.

   The key-wrap-algorithm attribute has the following syntax:

     aa-keyWrapAlgorithm ATTRIBUTE ::= {
       TYPE AlgorithmIdentifier{KEY-WRAP, {KeyEncryptionAlgorithmSet}}
       IDENTIFIED BY id-kma-keyWrapAlgorithm }

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

     KeyEncryptionAlgorithmSet KEY-WRAP ::= { ... }

25.  Content Decryption Key Identifier

   The content-decryption-key-identifier attribute can appear as an
   unprotected attribute as well as a symmetric and symmetric key
   package attribute.  The attribute's semantics differ based on the
   location.

25.1.  Content Decryption Key Identifier: Symmetric Key and Symmetric
       Key Package

   The content-decryption-key-identifier attribute [RFC6032] identifies
   the keying material needed to decrypt the sKey.  It can appear as a
   symmetric key and symmetric key package attribute.  If the key-wrap-
   algorithm attribute appears in sKeyPkgAttrs, then the corresponding
   content-decryption-identifier attribute can appear in either
   sKeyPkgAttrs or sKeyAttrs.  If the key-wrap-algorithm attribute
   (Section 24) appears in sKeyAttrs, then the corresponding content-
   decryption-identifier attribute MUST appear in sKeyAttrs.

   The content-decryption-key-identifier attribute in included for
   convenience:

     aa-contentDecryptKeyIdentifier ATTRIBUTE ::= {
       TYPE ContentDecryptKeyID
       IDENTIFIED BY id-aa-KP-contentDecryptKeyID }

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

     ContentDecryptKeyID ::= OCTET STRING

Top      Up      ToC       Page 37 
   The content decryption key identifier contains an octet string, and
   this syntax does not impose any particular structure on the
   identifier value.

25.2.  Content Decryption Key Identifier: Unprotected

   The content-decryption-key-identifier attribute can be used to
   identify the keying material that is needed for decryption of the
   EncryptedData content if there is any ambiguity.

   The content-decryption-key-identifier attribute syntax is found in
   Section 25.1.  The content decryption key identifier contains an
   octet string, and this syntax does not impose any particular
   structure on the identifier value.

   Due to multiple layers of encryption, the content-decryption-key-
   identifier attribute can appear in more than one location in the
   overall key package.  When that happens, each occurrence is evaluated
   independently.  Each one is used to identify the needed keying
   material for that layer of encryption.

26.  Certificate Pointers

   The certificate-pointers attribute can be used to reference one or
   more certificates that may be helpful in the processing of the
   content once it is decrypted.  Sometimes certificates are omitted if
   they can be easily fetched.  However, an intermediary may have better
   facilities to perform the fetching than the receiver.  The
   certificate-pointers attribute may be useful in some environments.
   This attribute can appear as an unprotected and an
   unauthenticated&unprotected attribute.

   The certificate-pointers attribute uses the same syntax and semantics
   as the subject information access certificate extension [RFC5280].
   The certificate-pointers attribute has the following syntax:

     aa-certificatePointers ATTRIBUTE ::= {
       TYPE SubjectInfoAccessSyntax
       IDENTIFIED BY id-pe-subjectInfoAccess }

     id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= {
       iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) pe(1) 11 }

     SubjectInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF
                                   AccessDescription

Top      Up      ToC       Page 38 
     AccessDescription ::= SEQUENCE {
       accessMethod       OBJECT IDENTIFIER,
       accessLocation     GeneralName }

   As specified in [RFC5280], the id-ad-caRepository access method can
   be used to point to a repository where a Certification Authority
   publishes certificates and Certificate Revocation Lists (CRLs).  In
   this case, the accessLocation field tells how to access the
   repository.  Where the information is available via HTTP, FTP, or the
   Lightweight Directory Access Protocol (LDAP), accessLocation contains
   a Uniform Resource Identifier (URI).  Where the information is
   available via the Directory Access Protocol (DAP), accessLocation
   contains a directory name.

27.  CRL Pointers

   The CRL-pointers attribute can be used to reference one or more CRLs
   that may be helpful in the processing of the content once it is
   decrypted.  Sometimes CRLs are omitted to conserve space or to ensure
   that the most recent CRL is obtained when the certificate is
   validated.  However, an intermediary may have better facilities to
   perform the fetching than the receiver.  The CRL-pointers attribute
   may be useful in some environments.  This attribute can appear as an
   unprotected and unauthenticated&unprotected attribute.

   The CRL-pointers attribute has the following syntax:

     aa-crlPointers ATTRIBUTE ::= {
       TYPE GeneralNames
       IDENTIFIED BY id-aa-KP-crlPointers }

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

   The CRL-pointers attribute uses the GeneralNames syntax from
   [RFC5280].  Each name describes a different mechanism to obtain the
   same CRL.  Where the information is available via HTTP, FTP, or LDAP,
   GeneralNames contains a URI.  Where the information is available via
   DAP, GeneralNames contains a directory name.

28.  Key Package Identifier and Receipt Request

   The key-package-identifier-and-receipt-request attribute from
   [RFC7191] is also supported.  It can appear as a signed attribute,
   authenticated, authenticated&unprotected, or content attribute.

Top      Up      ToC       Page 39 
29.  Additional Error Codes

   This specification also defines three additional extended
   ErrorCodeChoice object identifiers for the oid field [RFC7191]:

     id-errorCodes OBJECT IDENTIFIER ::= {
       joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
       dod(2) infosec(1) errorCodes(22) }

     id-missingKeyType OBJECT IDENTIFIER ::= {
       id-errorCodes 1 }

     id-privacyMarkTooLong OBJECT IDENTIFIER ::= {
       id-errorCodes 2 }

     id-unrecognizedSecurityPolicy OBJECT IDENTIFIER ::= {
       id-errorCodes 3 }

     id-incorrectKeyProvince OBJECT IDENTIFIER ::= {
       id-errorCodes 4 }


   missingKeyType indicates that all keying material within a package is
   of the same type; however, the key-package-type attribute is not
   specified in sKeyPkgAttrs [RFC6031].

   privacyMarkTooLong indicates that a classification attribute includes
   a privacy-mark that exceeds 128 characters in length.

   unrecognizedSecurityPolicy indicates that a security-policy-
   identifier is not supported.

   incorrectKeyProvince indicates that the value of the key-province-v2
   attribute in a key package does not match the key province constraint
   of the trust anchor used to validate the key package.

30.  Processing Key Package Attribute Values and CMS Content Constraints

   Trust anchors may contain constraints for any content type [RFC5934].
   When the trust anchor contains constraints for the symmetric key
   package content type or the asymmetric key package content type, then
   the constraints provide default values for key package attributes
   that are not present in the key package and define the set of
   acceptable values for key package attributes that are present.

   When a trust anchor delegates authority by issuing an X.509
   certificate, the CMS content constraints certificate extension
   [RFC6010] may be included to constrain the authorizations.  The trust

Top      Up      ToC       Page 40 
   anchor and the X.509 certification path provide default values for
   key package attributes that are not present in the key package and
   define the set of acceptable of values for key package attributes
   that are present.

   Constraints on content type usage are represented as attributes.

   The processing procedures for the CMS content constraints certificate
   extension [RFC6010] are part of the validation of a signed or
   authenticated object, and the procedures yield three output values:
   cms_constraints, cms_effective_attributes, and
   cms_default_attributes.  Object validation MUST be performed before
   processing the key package contents, and these output values are used
   as part of key package processing.  These same output values are
   easily generated directly from a trust anchor and the key package
   when no X.509 certification path is involved in validation.

   The cms_effective_attributes provides the set of acceptable values
   for attributes.  Each attribute present in the key package that
   corresponds to an entry in cms_effective_attributes MUST contain a
   value that appears in cms_effective_attributes entry.  Attributes
   that do not correspond to an entry in cms_effective_attributes are
   unconstrained and may contain any value.  Correspondence between
   attributes and cms_effective_attributes is determined by comparing
   the attribute object identifier to object identifier for each entry
   in cms_effective_attributes.

   The cms_default_attributes provides values for attributes that do not
   appear in the key package.  If cms_default_attributes includes only
   one attribute value for a particular attribute, then that value is
   used as if it were included in the key package itself.  However, if
   cms_default_attributes includes more than one value for a particular
   attribute, then the appropriate value remains ambiguous and the key
   package should be rejected.

   Some attributes can appear in more than one place in the key package,
   and for this reason, the attribute definitions include consistency
   checks.  These checks are independent of constraints checking.  In
   addition to the consistency checks, each instance of the attribute
   MUST be checked against the set of cms_effective_attributes, and the
   key package MUST be rejected if any of the attributes values are not
   in the set of authorized set of values.


Next RFC Part