On Tue, Apr 18, 2023 at 11:24:20AM -0700, Laurence Lundblade wrote: > The main thing we have to do for a COSE_Key with HPKE is define how > to do algorithm restriction. We can’t do that in the normal COSE way > of just using an integer cipher suite. HPKE-v1-BASE doesn’t give > enough info. (RFC 8230 didn’t have to mention the alg parameter at > all because it is using integer cipher suites. Key use restriction > by algorithm just worked automatically).
Why would you want algorithm restriction? - Because multiple algorithms could interact harmfully? HPKE has internal protections against this. - To signal recipient algorithm preferences? There has never been a way to restrict or even advertise bulk ciphers, which are interop- critical. Now, some algorithm could interact harmfully with HPKE (even if this is highly unlikely). But for this case, 'alg: HPKE-v1-BASE' is completely sufficient (in COSE_Key, it does not work in JWK). In JWK, one would have to consider HPKE encryption/decryption to be its own operation or HPKE to be new key usage. COSE has key operations but not key usage. > So what I’d put in draft-ietf-cose-hpke is roughly this: > > When a COSE_Key is used with HPKE, the algorithm usage restriction is > expressed by having the alg parameter set to HPKE-v1-BASE and with an > additional COSE Key parameter called “hkc”. The “hkc” parameter gives > the additional listing of the AEADs, KDFs and KEMs for which the key > can be used. If the alg parameter is HPKE-v1-BASE, the “hkc” parameter > MUST be present and the key use MUST be restricted to HPKE with the > listed AEADs, KDFs and KEMs. As you note below, the last MUST is actually RFC 6919 "MUST (BUT WE KNOW YOU WON'T)". I don't think that should be there. There is nothing in "hkc" that is technically necressary for using HPKE. > I don’t think there is any need to say that keys uses with COSE_HPKE > must be of any key type or have any particular parameters. We don’t > do that anywhere else in COSE. It is fine to write security > considerations to recommend the COSE_Keys used with COSE-HPKE should > have an “hkc” parameter. If is also OK to use EC keys in PEM files, > in RFC 8230 format and such with COSE-HPKE. There is some stuff regarding "hkc" that should be added: - If using dedicated HPKE key, then the key KEM is implicitly considered acceptable. Anything else would place onerous requirements on implementations. - The key KEM in dedicated HPKE keys needs to be its own parameter. There can be only one, whereas there are completely valid reasons to have multiple supported KEMs (especially with EC2 keys). I don't imagine simpler implementations would be pleased at having to prase the key KEM from pointless-looking substructure. Especially as such implementations likely have supported algorithms as part of application profile anyway. - Any KDF that matches the internal KDF used by any acceptable KEM (including implicit ones) is implicitly considered acceptable. When encrypting, implementations SHOULD pick KDF that matches the internal KDF used by the selected KEM. The current mapping is: 16 -> 1, 17 -> 2, 18 -> 3, 32 -> 1, 33 -> 3. Of proposed: kyber -> 1, cp-256 -> 1, cp-384 -> 2, cp-521 -> 3. It is SHOULD, as following this recommendation might be impossible in some cases (e.g., If Kyber is added, but not 256-level SHA-3 KDF). Anything else would seem to be pointlessly asking for interop trouble. And of course, to actually have enough signaling for interop without having to assume anything, one would also need to signal the bulk encryption algorithms (int/tstr in COSE, str in JOSE). -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
