On Sun, Nov 30, 2025 at 07:06:36PM +0000, Michael Jones wrote:
> A design team formed and met after the JOSE working group
> <https://datatracker.ietf.org/group/jose/about/> meeting at IETF 124
> in Montreal<https://datatracker.ietf.org/meeting/124/proceedings/>
> to discuss possible next steps for the JOSE HPKE specification
> <https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/>. As
> recorded in the PR applying the decisions made
> <https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/84/>,
> the design team produced these recommendations:
> 
>   *   Not use "enc" when performing Integrated Encryption.
>   *   Define one new Key Management Mode for Integrated
>       Encryption.
>   *   Integrate the new mode into the Message Encryption and
>       Message Decryption instructions from RFC 7516 and replace them.
>   *   Utilize distinct algorithm identifiers for the use of HPKE for
>       Integrated Encryption and HPKE for Key Encryption.
>   *   Only use the Recipient_structure when doing Key Encryption and
>       not when doing Integrated Encryption.
> 
> Draft 15<https://www.ietf.org/archive/id/draft-ietf-jose-hpke-encrypt-15.html>
> has now been published, which incorporates these decisions. Note that
> the title of the specification has been changed to "Use of Hybrid
> Public Key Encryption (HPKE) with JSON Web Encryption (JWE)" to more
> precisely describe what it does.
> 
> 
> I believe the next steps are to apply the same decisions to the COSE
> HPKE specification<https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/>
> and then hold another set of concurrent working group last calls
> (WGLCs) for both specifications.

While those decisions made sense for JOSE, I do not think those
decisions make sense for COSE:


* Not use "enc" when performing Integrated Encryption.

COSE does not have "enc". The closest equivalent is layer 0 algorithm,
which has to be present, unless it can be inferred somehow (usually it
can not).


* Define one new Key Management Mode for Integrated Encryption

There is no need to explicitly define a new Key Managment Mode,
even if HPKE in COSE requires one — HPKE in COSE does not fit any
existing COSE Key Managment Mode for various reasons.

And as noted later, there are some security pitfalls here.


* Integrate the new mode into the Message Encryption and
  Message Decryption instructions from RFC 7516 and replace them.

COSE does not have any analogous instructions.


* Utilize distinct algorithm identifiers for the use of HPKE for
  Integrated Encryption and HPKE for Key Encryption.

This would actually be dangerous.

In COSE, any bulk encryption can be applied to CEK, so any bulk
encryption algorithm needs to be able to deal with CEKs properly.


* Only use the Recipient_structure when doing Key Encryption and
  not when doing Integrated Encryption.

COSE has per-level protected headers and application AADs, so
aad structures are required at every level.

What could make sense is always using Recipient_structure,
setting next_layer_alg to NULL on layer 0.




-Ilari

_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to