> On Apr 18, 2023, at 11:57 PM, Ilari Liusvaara <[email protected]> > wrote: > > 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?
To be honest, mostly because that is what the “alg” parameter is for and because it seems to be common practice. It seemed logical to extend the alg restriction to the details of “hkc”. Some more further down... > - Because multiple algorithms could interact harmfully? HPKE has > internal protections against this. No, not a reason for me. Maybe some other crypto person as some other idea? > - To signal recipient algorithm preferences? There has never been a way > to restrict or even advertise bulk ciphers, which are interop- > critical. Not particularly, though I don’t think it’s horrible if it used this way. Maybe some particular use case, some big end-end system, has a reason for a restriction. What if someone is using a very long high security key and want to say it should never be used with AES 128 because it is too weak? Maybe there’s a certification of regulatory conformance requirement. > 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). I suppose alg:HPKE-v1-BASE might suffice, but that seems a bit on the edge. I think we’d want some solid consensus before doing away with the “hkc” parameter entirely and relying solely on alg:HPKE-v1-BASE. The HPKE alg registry is a bit odd: - No space for proprietary claims - NO written policy for adding algorithms!? It seems possible that a variety of algorithms could get added or get used in a proprietary space. Seems like then the key algorithm restriction would be important in those scenarios. > ... > >> 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. I can go either way on the MUST/SHOULD, but it seems we’re already there with the concept of MUST for algorithm restriction. It’s more about implementations in a closed system that has agreed to do this rather than expecting every implementation to honor that for every key ever found on the Internet. > > There is nothing in "hkc" that is technically necessary for using HPKE. Agreed. And the alg and hkc parameters are always optional. LL _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
