RFC 7906
NSA's Cryptographic Message Syntax (CMS) Key Management Attributes
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.
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) }
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 }
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:
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.
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:
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 }
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
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
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.
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
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.
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.
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
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
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
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.
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
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 page on part 3)
