Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type
Extracted elements (18)
In CCC terminology, the EncryptedKeyPackage is a leaf node. This means additional authorization checks are required after decryption of the inner content (e.g., verifying the SignedData signature and certification path on the inner symmetric key package), enabling multi-layer authorization chains.
The encrypted key package content type was created to close an authorization gap in the CMS Content Constraints (CCC) extension: CCC can authorize originators of plaintext key packages but cannot constrain EncryptedData, EnvelopedData, or AuthEnvelopedData layers. A distinct content type allows the CCC OID to be placed in an originator's certificate to authorize production of encrypted key packages at intermediate relay points that cannot decrypt the content.
Interoperability between an originator and a recipient that do not support the same innermost content type (e.g., originator produces AsymmetricKeyPackage while recipient expects SymmetricKeyPackage) is not addressed by this specification; originators are expected to be aware of recipient capabilities, but the capability exchange mechanism is out of scope.
An EncryptedKeyPackage content type MUST contain at least one SymmetricKeyPackage or AsymmetricKeyPackage. Implementations MAY support additional encapsulating layers.
Implementations MUST support the EnvelopedData choice for the EncryptedKeyPackage content type.
Implementations SHOULD support the EncryptedData choice and MAY support the AuthEnvelopedData choice for the EncryptedKeyPackage content type.
Implementations that support AuthEnvelopedData to encapsulate with this content type MUST support an EncryptedKeyPackage that encapsulates either a SymmetricKeyPackage or an AsymmetricKeyPackage directly (without an intervening SignedData).
Implementations that support EnvelopedData or EncryptedData to encapsulate with this content type MUST support an EncryptedKeyPackage that encapsulates a SignedData further encapsulating either a SymmetricKeyPackage (RFC 6031) or an AsymmetricKeyPackage (RFC 5958).
There MUST be only one instance of the content-decryption-key-identifier attribute and there MUST be only one value for that attribute within a given layer.
When this content type is used, the CMS SignedData (RFC 5652) validation rules MUST be used. The PKCS #7 (RFC 2315) validation rules MUST NOT be used.
The content-decryption-key-identifier attribute (id-aa-KP-contentDecryptKeyID) is an unprotected attribute for use with EncryptedData to identify the symmetric keying material needed for decryption when ambiguity exists. Its value is an OCTET STRING (ContentDecryptKeyID) with no imposed structure.
The EncryptedKeyPackage content type is a CHOICE among three CMS protecting structures: encrypted (EncryptedData), enveloped ([0] EnvelopedData), and authEnveloped ([1] AuthEnvelopedData). It is identified by OID id-ct-KP-encryptedKeyPkg and differs from the underlying protecting content types only in its OID and one tag.
The object identifier for the encrypted key package content type is id-ct-KP-encryptedKeyPkg, assigned in the joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) formats(2) key-package-content-types(78) arc at value 2.
The OID for the content-decryption-key-identifier attribute is id-aa-KP-contentDecryptKeyID, assigned at joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) attributes(5) 66.
This document uses OIDs under the SMIME Working Group arc delegated by RSADSI to identify the content type (id-ct-KP-encryptedKeyPkg), the unprotected attribute (id-aa-KP-contentDecryptKeyID), and the ASN.1 module. No new IANA registries are created; the OIDs are pre-assigned in the DoD infosec arc.
Implementers are strongly encouraged to apply generally accepted principles of secure key management when integrating this capability within an overall security architecture. Security considerations from RFC 5083, 5652, 5911, 5912, 5958, 6031, and (if CCC is used) RFC 6010 apply.
The encrypted key package content type may not provide proof of origin if the content encryption algorithm does not support authenticated key exchange. To provide proof of origin, SignedData encapsulation of the SymmetricKeyPackage or AsymmetricKeyPackage is required for the EnvelopedData and EncryptedData choices.
ContentDecryptKeyID is encoded as an ASN.1 OCTET STRING. The attribute definition follows the ATTRIBUTE class from RFC 5912. No particular internal structure is imposed on the identifier value.