> > I have started to think of COSE_Key as “CBOR Key”. It’s just a key > serialization format using CBOR (rather than ASN.1).
I agree with that. COSE_Key is essentially just a CBOR_Key. This could also be one reason why it's not necessary to include the key representation for HPKE KEM into the COSE-HPKE specification :-) Currently, I'm starting to think that treating "hkc" as an extension (additional information) of "alg" may not be appropriate, as it contradicts the definition of alg in RFC9052 below. alg: This parameter is used to restrict the algorithm that is used with the > key. Actually, the kdfs and aeads in "hkc" have nothing to do with the KEM key. Therefore, I believe the description regarding "hkc" would be as follows. - When a recipient provides senders with its public keys for HPKE KEM in the form of JWK or COSE_Key, the recipient can declare the supported HPKE ciphersuites using hkc. If the recipient does not support all of the KEMs, KDFs, or AEADs which can be used with the key, the recipient SHOULD indicate the supported ciphersuites using "hkc". - If the recipient's public keys are provided in JWK or COSE_Key format, the senders of HPKE SHOULD check whether the "hkc" parameter is included in them, and if so, SHOULD select a specific ciphersuite to be used from the "hkc" value. The "alg" value is not mentioned above. This is because "hkc" is an auxiliary parameter independent of the "alg" value. AJITOMI Daisuke 2023年4月20日(木) 1:05 Laurence Lundblade <[email protected]>: > > > 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
