Algorithm identifiers like HPKE-P256-SHA256-A128GCM are overly verbose

[selfissued]

The "alg" values should be short identifiers that fully-specify the computation to be performed. They should not contain syntax that is parsed, such as a required "HPKE" string prefix.

Let's decide on reasonable short identifiers for each of the algorithms - ideally 8 characters each or less.

[OR13]

Hpke Jose Cipher Suite 0 - HPKE-P256-SHA256-A128GCM -> HJCS-0 ?

[OR13]

ECDH-ES+A128KW has obvious structure.

https://www.iana.org/assignments/hpke/hpke.xhtml has the source of truth for the values.

There is also the problem of "why register all these in JOSE / COSE, who actually wants to use them"

[selfissued]

In order to have meaningful short algorithm names, I propose that we use alg names of the form "HPKEk-a", where "k" is the hexadecimal representation of the HPKE KEM number and "a" is the hexadecimal representation of the HPKE AEAD number, both as registered at https://www.iana.org/assignments/hpke/hpke.xhtml. In particular, I'm proposing these renamings:

• HPKE-P256-SHA256-A128GCM -> HPKE10-1
• HPKE-P384-SHA384-A256GCM -> HPKE11-2
• HPKE-P521-SHA512-A256GCM -> HPKE12-2
• HPKE-X25519-SHA256-A128GCM -> HPKE20-1
• HPKE-X25519-SHA256-ChaCha20Poly1305 -> HPKE20-3
• HPKE-X448-SHA512-A256GCM -> HPKE21-2
• HPKE-X448-SHA512-ChaCha20Poly1305 -> HPKE21-2

I will create a PR unless people make a counterproposal.

[OR13]

If we are going to go for shorter names, I think we can skip straight to HPKE-[0-N]

So that would yield:

HPKE-P256-SHA256-A128GCM -> HPKE-0
HPKE-P384-SHA384-A256GCM -> HPKE-1
HPKE-P521-SHA512-A256GCM -> HPKE-2
HPKE-X25519-SHA256-A128GCM -> HPKE-3
HPKE-X25519-SHA256-ChaCha20Poly1305 -> HPKE-4
HPKE-X448-SHA512-A256GCM -> HPKE-5
HPKE-X448-SHA512-ChaCha20Poly1305 -> HPKE-6

[selfissued]

The two numbers are aligned to the numbers in the registries at https://www.iana.org/assignments/hpke/hpke.xhtml. Then were not making anything up.

I could live with either approach. What do others think?

[OR13]

ahh, maybe just hpke-<kem>-<kdf>-<aead> but using numbers instead of string labels:

HPKE-P256-SHA256-A128GCM -> HPKE-10-01-01 / HPKE-100101

[OR13]

Still seems like it might be better to just go with hpke-0 though... shorter, and the registration can handle the mapping

[selfissued]

I could support hpke-kem-kdf-aead naming like HPKE-10-1-1 (leaving off the leading zeros). I'd rather go with names rooted in the existing HPKE registry than names we're completely making up.

[ilaril]

One subtle consideration is that any sort of systematic pattern can be interpreted as adding all the algorithms (since it is obvious what the algorithm name would be). Advantage of being systematic would be eliminating the possibility that an algorithm gets added in subtly incompatible way (which could cause major interoperability headaches).

Then these algorithms could presumably get used with kty=AKP. There is an obvious interpretation for "priv" and "pub" in this case (raw HPKE private and public keys).

However, it depends on KEM if it is possible to derive "pub" from "priv" (and including both causes possible security issue), or not (both are needed). I think KEM 0x30 (which is essentially deprecated) is currently the only one where it is not possible to derive public key from private key.

[ounsworth]

My vote (that doesn't count because I'm a tourist in JOSE):

Fully specified is useful so that devs don't need to fish around in the guts of RFCs to figure out what actually makes up a given cipher suite.

Short-forms over the wire are also fine. I have a slight preference for HPKE-0 rather than HPKE10-1 because A) if you have to look it up, then you have to look it up, and B) this scheme may not extend well to hybrid KEMs.

[selfissued]

It also occurred to me that names of the form HPKE-n will probably better correspond to COSE algorithm identifiers, where they will be a single integer anyway. So unless people voice objections here shortly, I'll plan to create a PR to accomplish that. Getting to stable algorithm identifiers is a big step towards enabling deployments (something being contemplated at openid/oid4vc-haip#131).

[lee-preimesberger]

late to the party, but i really prefer this approach with the short(est) codes. the verbose tags takes too much space - and like mentioned above if we need to refer back to the RFC anyway smaller is better.

[OR13]

Its also easier to read, write and compare "HPKE-0" in contrast to "HPKE-P256-SHA265-A128GCM" (review this carefully for a case in point).