Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types
Extracted elements (27)
The errorOf field in KeyPackageError is OPTIONAL because encryption may prevent an intermediary from obtaining any of the identifiers, and a receiver may be unable to parse the received data at all to determine the package identifier.
The SIR entity name uses an object identifier for nameType to avoid the need for a central registry of name types, and to ensure identifiers of different types with the same value are not mistakenly considered equivalent.
When the key-package-identifier-and-receipt-request attribute appears in more than one location in the overall key package, each occurrence is evaluated independently, potentially resulting in more than one receipt generated for a single key package.
A receiver SHOULD ignore the nameValue associated with any unrecognized nameType in either the receiptsFrom or receiptsTo field.
All devices generating signed key package error reports MUST store their own certificate or have a means of obtaining the key identifier of their public key.
For KeyPackageReceipt, the default version v2 MUST be used; v1 was defined in an earlier version but its use is deprecated. The pkgID alternative in receiptOf MUST be supported.
If the encryptReceipt boolean in KeyPkgReceiptReq is set to TRUE, then the receipt SHOULD be encrypted.
If the receipt signer has access to a real-time clock, the binary-signing-time signed attribute SHOULD be included in the key package receipt to provide the date and time of generation.
Key package receipts MUST be encapsulated in a CMS SignedData content type. They MAY be encrypted using EncryptedData, EnvelopedData, or AuthEnvelopedData. When both signed and encrypted, the receipt MUST be signed prior to being encrypted.
The EnumeratedErrorCode alternative in ErrorCodeChoice MUST be supported; the object identifier alternative MAY be supported.
The key package error content type MUST be signed if the entity generating it is capable of signing. When signed it MUST be encapsulated in CMS SignedData; when encrypted in CMS EnvelopedData, EncryptedData, or AuthEnvelopedData. When both signed and encrypted, it MUST be signed prior to encryption.
The key-package-identifier-and-receipt-request attribute MUST have a single attribute value; zero or multiple instances of AttributeValue are not permitted.
The key package or collection of key packages for which a receipt is being generated MUST be signed, and the key package MUST include the key-package-identifier-and-receipt-request attribute.
The key package receipt content type MUST be encoded using Distinguished Encoding Rules (DER).
The pkgID value in a receipt MUST exactly match the key package identifier value of the key-package-identifier-and-receipt-request attribute in the received key package.
Use of the 'other' error code SHOULD be avoided; it is a catch-all for reasons not covered by any assigned status codes.
When the receiptsFrom field is present in a receipt request, a receiver SHOULD return a receipt only if their SIR entity name appears on the list.
EnumeratedErrorCode defines 40+ enumerated error codes covering CMS processing failures including decode failures, bad structures (SignedData, EnvelopedData, AuthenticatedData, AuthEnvelopedData), cryptographic failures, authorization errors, and key package-specific errors. Values 1–33 are aligned with RFC 5934 (TAMP).
The SIR (Source Intermediary Recipient) entity name identifies participants in a key distribution system. It uses a nameType OID and a nameValue OCTET STRING, with two names of the same type considered equal when their octet strings are identical.
IANA updated the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry: entry 63 (id-mod-keyPkgReceiptAndErrV2) now references RFC 7191.
In environments with multiple key sources, the same key package identifier could be used by more than one source, leading to receipts being confused across sources and potential ambiguity about available keying material. A convention for identifier assignment can avoid this.
Returning detailed error codes can provide attackers with insight into security processing. Implementations should support configurable generic vs. detailed error responses, reserving detail for development, debugging, and interoperability testing.
The receiptsFrom and receiptsTo lists in KeyPkgReceiptReq have no enforced size limit, and receiptsTo entries need not relate to the key package sender. To avoid denial-of-service amplification, receipts should only be returned for key packages with a valid signature from a trusted signer.
KeyPackageError is an ASN.1 SEQUENCE with version (KeyPkgVersion DEFAULT v2), optional errorOf [0] KeyPkgIdentifier, errorBy (SIREntityName), and errorCode (ErrorCodeChoice — either EnumeratedErrorCode or OBJECT IDENTIFIER). OID is id-ct-KP-keyPackageError.
KeyPackageReceipt is an ASN.1 SEQUENCE with version (KeyPkgVersion DEFAULT v2), receiptOf (KeyPkgIdentifier CHOICE of pkgID or attribute), and receivedBy (SIREntityName). OID is id-ct-KP-keyPackageReceipt.
KeyPkgIdentifierAndReceiptReq is an ASN.1 SEQUENCE with pkgID (KeyPkgID, an OCTET STRING) and an optional receiptReq (KeyPkgReceiptReq containing encryptReceipt BOOLEAN, optional receiptsFrom SIREntityNames, and receiptsTo SIREntityNames).
SIREntityName is an ASN.1 SEQUENCE with sirenType (an OID) and sirenValue (OCTET STRING). The DN type uses id-dn OID and carries an ASN.1-encoded DistinguishedName as defined in RFC 5280.