Summary

  • draft-ietf-cose-hpke-27 was posted on 12 September while the document remains in Area Director follow-up. It is a Standards Track Internet-Draft, not an RFC or an approved deployment profile.
  • The protected psk_id header selects PSK mode. Without it, COSE HPKE defaults to Base mode, which protects for the recipient but does not authenticate the sender at the HPKE KEM layer.
  • kid identifies the recipient key, not the sender. Daniel Kade proposes a privacy-bounded receipt that records the effective authentication and authorization path without storing PSKs or plaintext; this is editorial analysis, not an IETF requirement.

A successful open can still leave the actor unnamed

The 12 September revision of the IETF's COSE HPKE work arrives at a consequential moment. The Datatracker history shows the document submitted for publication and in AD Evaluation::AD Followup. Revision 27 makes the randomness language more explicit: HPKE needs a cryptographically secure source, and a content-encryption key in Key Encryption mode must also come from a cryptographically secure generator.

That is a real normative tightening, but not an RFC publication. The current record can still move, the text can change and final IANA assignments have not been made. The sharper governance question is already visible in the stable part of the design: what exactly should an application conclude after a COSE HPKE object decrypts?

HPKE gives a sender a way to protect data for the holder of a recipient private key. COSE supplies structured envelopes, protected headers and recipient layers around that operation. If the object opens successfully, the recipient learns that the ciphertext, associated data and selected keying inputs are internally consistent. In Base mode, it does not learn the sender's identity from the HPKE KEM.

That distinction is easy to miss because encryption and authentication appear together in the name of the AEAD component. AEAD authenticates ciphertext and associated data under the derived symmetric key. It does not, by itself, turn the party that created a fresh public-key encapsulation into a named or authorised sender.

Two encryption layouts, one separate authentication choice

The draft defines two COSE layouts. Integrated Encryption applies HPKE directly to plaintext in COSE_Encrypt0 and supports one recipient. Key Encryption first creates a content-encryption key, protects the content with the chosen COSE algorithm and uses HPKE in a recipient layer to encrypt that key. The second layout can serve multiple recipients.

Each new COSE algorithm identifier fixes a complete HPKE ciphersuite—KEM, KDF and AEAD—and whether it is for Integrated or Key Encryption. That reduces combinatorial ambiguity. A recipient should not use an Integrated Encryption identifier in a Key Encryption layer or silently substitute a different cryptographic triple.

The sender-authentication mode remains a different axis. If a protected psk_id is present, the operation uses mode_psk. If it is absent, the operation defaults to mode_base. The draft even notes that this mode is therefore not explicitly indicated by the ciphersuite.

This means two objects can advertise the same COSE algorithm while making different authentication claims. One carries a protected identifier for externally supplied shared key material. The other carries no psk_id and therefore makes no HPKE KEM claim about the sender. A policy engine that records only the algorithm number has omitted the field that selected the trust path.

kid points the other way

The draft recommends kid so a sender can identify the static recipient public key it used. A recipient may use that value to select the matching private key. That improves deterministic processing, especially when a service rotates keys or maintains several active keys.

But kid points toward the recipient. It says which public key the sender targeted. It does not say which sender made the choice, where that sender obtained the key or whether an application authorised the action contained in the plaintext.

The distribution problem is expressly outside the document's scope. Both HPKE and the COSE binding assume the sender already has the recipient public key. A stale directory entry, an unauthorised key export or a key copied into the wrong tenant can therefore produce a perfectly valid object for the wrong operational context. Cryptography can faithfully protect a mistaken input.

psk_id points to a different external dependency. The header is protected, and the PSK itself must never appear in the COSE object. In PSK mode, successful processing authenticates possession of that shared secret. It still does not name a person, prove that the key remains assigned to the same service or decide which request the holder may make. The current HPKE draft also warns that the PSK must have high entropy; a low-entropy password is not repaired merely by placing its identifier in a protected header.

Context can be bound without becoming policy

COSE's protected headers and external authenticated data let an application bind selected context to the ciphertext. In Key Encryption mode, the draft constructs a deterministic Recipient_structure that includes the immediate next-layer algorithm, protected recipient headers and optional extra information. That structure counters an algorithm-substitution problem at the boundary between the recipient layer and the bulk encryption layer.

This is good protocol hygiene. It does not choose the business or governance context that should be bound. A service might include a tenant, transaction class, policy version, expiry or request purpose. Another might leave external AAD empty. Both can conform at the encoding layer while making different claims about replay, delegation and authority.

The underlying HPKE work describes itself as a low-level mechanism. Beyond the ordered context it leaves replay handling, downgrade prevention, message-loss policy and several embedding choices to applications. A receiver that accepts the same single-shot object twice can therefore make the same authorised action happen twice unless the surrounding protocol supplies freshness and tracks it.

A detached ciphertext creates another seam. The COSE HPKE draft warns that applying an outer COSE signature or MAC does not automatically cover detached bytes. Implementers must ensure those bytes receive integrity protection too. A receipt that says only “signature valid” can be dangerously incomplete if it does not name the protected object and the detached content relationship.

Base mode is not a defect

None of this makes Base mode weak for its stated job. Anonymous public-key encryption is useful when any sender should be able to submit confidential material to a recipient, or when sender authentication comes from a separate signature, MAC, secure channel or application credential. The draft explicitly points to COSE_Sign, COSE_Sign1, COSE_Mac and COSE_Mac0 as mechanisms that can add authentication.

The error would be to infer that a successful HPKE open supplies a property the chosen mode never promised. Nor is PSK mode a universal answer. Shared secrets create their own questions: who provisioned the PSK, which principals share it, whether it has been rotated or revoked, and whether possession authorises the particular action.

Governance begins where these cryptographic statements become operational decisions. A security gateway may decrypt a command, a device may accept configuration, or a service may ingest a confidential report. The application needs to know whether confidentiality alone was sufficient, whether a separate signer was verified, whether a PSK mapped to an active principal and which policy allowed the resulting action.

Record the path that made acceptance legitimate

Daniel Kade proposes a sender-authentication receipt for each accepted COSE HPKE object. It would record the exact draft or deployed profile, Integrated or Key Encryption, ciphersuite, effective HPKE authentication mode, recipient-key fingerprint and key-distribution provenance. For PSK mode it would add a one-way fingerprint of psk_id, a non-secret PSK version and its lifecycle state. For Base mode it would name the separate signature, MAC, channel or application identity check—or state plainly that the profile permits anonymous submission.

The receipt would also bind the protected-context profile, freshness or replay result, detached-ciphertext integrity result, authorisation-policy version and final outcome. It must not contain PSK bytes, plaintext or more identity data than review requires. A digest and opaque event identifier can support audit without turning the log into a credential store.

This record is not required by the COSE HPKE draft, RFC 9052, RFC 8937 or the IANA COSE registry. It is the organisational evidence needed when conforming cryptography feeds an authorisation decision.

The separation follows Heng Lu's Policy Mirror: a valid mechanism output should not be promoted into an authority claim without the rule and evidence that justify it. The Minimum Initial Specification argues for a small common boundary that leaves applications room to strengthen local controls. Why BTW Media Exists supplies the reporting discipline: revision 27 is fresh evidence of a design under review, not evidence of an exploit or deployment failure.

Sources

  1. COSE HPKE, Working Group revision 27
  2. COSE HPKE, previous revision 26
  3. Current COSE HPKE Datatracker record
  4. COSE HPKE document history
  5. Current HPKE revision 04
  6. RFC 9052 — COSE Structures and Process
  7. RFC 8937 — Randomness Improvements for Security Protocols
  8. IANA COSE registry
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists