Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
Extracted elements (21)
The 'cnf' claim design is analogous to SAML 2.0 SubjectConfirmation, which supports multiple subject confirmation methods including PoP key information; this design allows other specifications to register additional confirmation methods.
The nonce/challenge mechanism for actually demonstrating PoP and the means of communicating signed nonces are intentionally not specified, because different protocols will communicate this information in different ways.
Key IDs for PoP keys are not necessarily the same value for different parties. When Key ID is not a cryptographic value derived from the key, implementers should expect collisions where different keys are assigned the same Key ID, and recipients must be prepared to handle them.
This specification provides functionality equivalent to RFC 7800 (Proof-of-Possession Key Semantics for JWTs) but uses CBOR and CWTs. The CWT confirmation method names map to JWT equivalents: COSE_Key↔jwk, Encrypted_COSE_Key↔jwe, kid↔kid.
Confirmation members that are not understood by implementations MUST be ignored in the absence of application-specific requirements to process them.
If the 'COSE_Key' member is used to carry a symmetric key and the CWT is not encrypted, the symmetric key MUST be encrypted as described in Section 3.3 (using Encrypted_COSE_Key).
The 'cnf' claim value MUST represent only a single proof-of-possession key. At most one of the 'COSE_Key' and 'Encrypted_COSE_Key' confirmation values may be present.
When representing an asymmetric PoP key, the 'COSE_Key' member MUST contain the required key members for that key type and MAY contain other COSE_Key members including 'kid'.
A proof-of-possession key can serve as a correlation handle if the same key is used on multiple occasions. For privacy reasons, it is recommended that different PoP keys be used when interacting with different parties.
A PoP key may be identified by Key ID rather than the actual key: the 'kid' member (cnf key 3) holds a binary string that identifies the key, provided the recipient can obtain the key using that identifier.
The 'cnf' (confirmation) claim in a CWT carries confirmation methods, including proof-of-possession keys. Its value is a CBOR map whose members identify the proof-of-possession key; it is assigned claim key 8.
The 'cnf' map defines three confirmation members: 'COSE_Key' (key 1, value type COSE_Key), 'Encrypted_COSE_Key' (key 2, value type COSE_Encrypt or COSE_Encrypt0), and 'kid' (key 3, value type binary string).
When the presenter holds a symmetric key, the 'Encrypted_COSE_Key' member (cnf key 2) carries the symmetric COSE_Key encrypted to a key known to the recipient using COSE_Encrypt or COSE_Encrypt0.
RFC 8747 establishes the IANA 'CWT Confirmation Methods' registry for CWT 'cnf' member values, with initial entries for COSE_Key (key 1), Encrypted_COSE_Key (key 2), and kid (key 3), all registered on a Specification Required basis.
RFC 8747 registers the 'cnf' claim (claim key 8, value type map, JWT claim name 'cnf') in the IANA 'CBOR Web Token (CWT) Claims' registry established by RFC 8392.
Applications utilizing proof of possession SHOULD also utilize audience restriction (RFC 8392 Section 3.1.3) to provide additional protection against replay and recipient confusion attacks.
Data origin authentication and integrity protection must be applied to CWTs via keyed message digest or digital signature. Symmetric keys inside a CWT additionally require confidentiality protection.
PoP only provides the intended security gains when the proof is known to be current and not subject to replay attacks; protocols using nonces and timestamps should be used to avoid replay risk.
Proof-of-possession keys are only valuable if kept secret. Appropriate means must be used to ensure unintended parties do not learn private or symmetric key values. Proof-of-possession signatures made with keys not meeting the application's trust criteria MUST NOT be relied upon.
An asymmetric PoP key is encoded as a COSE_Key structure placed in the 'cnf' map under key 1. For EC2 keys, the map includes kty (1), crv (-1), x (-2), and y (-3) fields as byte strings.
An encrypted symmetric PoP key is encoded as a COSE_Encrypt or COSE_Encrypt0 structure placed in the 'cnf' map under key 2. The plaintext of the encryption is the CBOR-serialized COSE_Key of the symmetric key.