CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates
Extracted elements (25)
Constrained devices are not necessarily expected to evaluate and process X.509 certificates themselves; a device may carry a provisioned certificate and provide it to a capable relying party, or hold only a certificate thumbprint without storing the full certificate.
No 'x5bag-sender' is defined for static-static ECDH because the existing 'x5bag' attribute is used for both sender and recipient certificates, making a sender-specific variant redundant.
The COSE Working Group originally omitted X.509 certificate support from RFC 8152 and RFC 9052 because no use cases were presented at the time. This document was created after subsequent use cases emerged, such as constrained BRSKI device enrollment and EDHOC long-term certificate authentication.
The 'x5bag' and 'x5chain' header parameters may be placed in either the protected or unprotected header bucket since their contents are treated as untrusted input regardless. Placing them in the unprotected header allows intermediaries to add or remove certificates.
The 'x5u' header parameter supports multiple media types for the referenced resource: application/pkix-cert, application/pkcs7-mime with smime-type=certs-only, application/cose-x509, and application/cose-x509 with usage=chain. When application/cose-x509 is used, data is a CBOR sequence of single-entry COSE_X509 bstr structures.
For interoperability, applications that use the 'x5t' header parameter MUST support the hash algorithm 'SHA-256' but can use other hash algorithms. This ensures different implementations can be configured to use an interoperable algorithm.
If a certificate retrieved via 'x5u' does not chain to an existing trust anchor, that certificate MUST NOT be trusted unless the URI provides integrity protection and server authentication and the server is configured as trusted for new trust anchors, or out-of-band confirmation can be received.
If an HTTP or CoAP GET request is used to retrieve a certificate via 'x5u', TLS, DTLS, or OSCORE SHOULD be used to protect the retrieval.
The end-entity certificate MUST be integrity protected by COSE when using 'x5bag', 'x5chain', 'x5t', or 'x5u'. This can be done by placing the parameter in the protected header, combining an unprotected certificate parameter with an 'x5t' in the protected header, or including the certificate in the external_aad.
The trust mechanism MUST process any certificates in the 'x5bag' or 'x5chain' header parameters as untrusted input. The presence of a self-signed certificate in these parameters MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation.
The 'x5bag' header parameter (label 32, value type COSE_X509) carries an unordered bag of X.509 certificates. The bag may contain self-signed certificates, duplicate certificates, or certificates extraneous to the message. The relying party must be capable of building the certificate path from this unordered set.
The 'x5chain' header parameter (label 33, value type COSE_X509) carries an ordered array of X.509 certificates, starting with the end-entity certificate followed by the signing certificate and so on. The full chain need not be present if the relying party can locate missing certificates.
The 'x5t' header parameter (label 34, value type COSE_CertHash) identifies the end-entity X.509 certificate by a hash thumbprint. It is a two-element array containing the hash algorithm identifier (integer or string from the COSE Algorithms registry) and the binary hash computed over the DER-encoded certificate.
The 'x5u' header parameter (label 35, value type uri) identifies or locates an X.509 certificate via a URI. The referenced resource may be application/pkix-cert, application/pkcs7-mime, application/cose-x509, or application/cose-x509 with usage=chain.
Three algorithm-specific header parameters are defined for static-static ECDH: 'x5t-sender' (label -27, COSE_CertHash), 'x5u-sender' (label -28, uri), and 'x5chain-sender' (label -29, COSE_X509). These identify or transport the sender's key exchange certificate for ECDH-SS algorithms.
IANA registered four new entries in the 'COSE Header Parameters' registry: x5bag (label 32, COSE_X509), x5chain (label 33, COSE_X509), x5t (label 34, COSE_CertHash), and x5u (label 35, uri), all referencing RFC 9360.
IANA registered the media type 'application/cose-x509' for a CBOR sequence of single-entry COSE_X509 structures. An optional 'usage' parameter may be set to 'chain' to indicate the sequence represents a certificate chain.
IANA registered three new entries in the 'COSE Header Algorithm Parameters' registry for static-static ECDH: x5t-sender (label -27), x5u-sender (label -28), and x5chain-sender (label -29), applicable to ECDH-SS+HKDF-256/512 and ECDH-SS+A128/192/256KW algorithms.
Before using the key in a certificate, the key MUST be checked against the algorithm to be used, including validating elliptic curve points are on the correct curve and RSA key sizes are within acceptable ranges. Use of unvalidated keys can cause loss of security or excessive resource consumption.
Both signature validation and certificate validation MUST be completed successfully before acting on any requests. On constrained devices there is a trade-off: validating certificates first consumes power/bandwidth for revocation checks, but validating signatures first may enable an oracle attack by revealing which messages pass signature validation via observable network access.
End-entity X.509 certificates, as well as 'x5t' and 'x5u' parameters, expose permanent identifiers that a passive on-path attacker can use to identify and track the subject. COSE does not provide identity protection; wrapping COSE inside a confidential transport is required to prevent tracking.
The security of the hash algorithm used for 'x5t' does not affect the security of the system because 'x5t' only selects a certificate already present on the system and does not itself provide trust. Placing 'x5bag', 'x5chain', and 'x5t' in the protected header helps mitigate risks from a misbehaving CA.
Unless the CA required proof of possession of the subject's private key, the end-entity certificate MUST be integrity protected by COSE to prevent identity-misbinding attacks, where an on-path attacker replaces the real end-entity certificate with a CA-issued certificate containing a borrowed public key but different subject.
COSE_CertHash is a two-element CBOR array: COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ], where hashAlg is the algorithm identifier from the COSE Algorithms registry and hashValue is the hash computed over the DER-encoded certificate.
COSE_X509 is encoded as either a single CBOR byte string (bstr) containing one DER-encoded certificate, or a CBOR array of two or more byte strings each containing one DER-encoded certificate: COSE_X509 = bstr / [ 2*certs: bstr ].