Change mandating ECDH-ES to mandating some version of HPKE

[GarethCOliver]

This is opening the discussion as to replace the JWE alg from ECDH-ES to one of the HPKE algs specified in https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt-08 before 1.0 final.

This is opened based on three things:

1. HPKE is generally considered to be preferable to ECDH-ES
2. The burden of shifting an ecosystem from one cryptography alg to another is very high
3. The jose hpke draft is now in WGLC so further along standardisation than HAIP, and so is able to be referenced

These things are true from my estimation, and justifies making the change, but we obviously need to discuss this as a working group.

[scvenema]

@GarethCOliver : I am in favor of adding HPKE; my question is how and when.

For reference, the only current mention of HPKE in the VP/VCI/HAIP specs is the following non-normative sentence in VP (added in draft-23):

Note: For encryption, implementers have a variety of options available through JOSE, including the use of Hybrid Public Key Encryption (HPKE) as detailed in [@I-D.ietf-jose-hpke-encrypt].

How
It seems to me that HAIP could reference the above VP text and add normative language to nail down which algorithm(s) implementers MUST support.

• Putting on my WG10 hat for a moment, I would love to see encryption parity between Annex C of 18013-7 (2nd Ed) and the draft Annex D -- at least for HAIP's mDL sub-profile. I believe that specifying the use of "alg": "HPKE-0" in HAIP would give us this parity? If we can get this in HPKE then a simple incorporate-HAIP-by-reference approach in Annex D should work quite well I think.
• Is there a need to specify other "HPKE-#" algorithm values as mandatory to implement? Or is just leaving room for those to be used ok? If the latter, that would seem to be problematic for interoperability, which arguably is one of the primary goals of HAIP.

When
Adding this change before v1.0 is finalized seems advantageous over adding it later (say, v1.1) due to what I would expect to be challenging (re)deployment after 1.0 is already deployed at scale (@GarethCOliver's point #2 above). I'm not even clear whether adding this in 1.1 would constitute a non-breaking change?

[jogu]

If we can do this before HAIP 1.0 that would be ideal and help solve some ISO worries.

Is there a proposal for what the HPKE detached info would contain? It would be good to share proposals for that with ISO WG10 members.

[selfissued]

Any of you who care about JOSE HPKE becoming a standard should reply to the thread "[jose] WGLC for draft-ietf-jose-hpke-encrypt-08" supporting the spec being published.

[Sakurann]

WG discussion:

• for HAIP 1.0 will start with ECDH-ES because jose-hpke will not be ready in 3 weeks when we need to start WGLC for HAIP 1.0 and as the industry shift to HPKE is highly likely to be inevitable because of post quantum.
• wg will continue working on jose-hpke, or vanilla hpke solution; and decide how to introduce HPKE, ideally in a non-breaking manner.

[bc-pi]

Just want to note/remind that, while there is a lot work in the area, HPKE is not a requirement for PQ public key encryption.