On Sat, Apr 15, 2023 at 10:33:37AM -0500, Orie Steele wrote: > Thank you for this wonderful breakdown! > > On Fri, Apr 14, 2023 at 4:00 PM Laurence Lundblade <[email protected]> > wrote: > > When we say "public key" in a CRFG document, I think it is reasonable to > assume no specific representation (JWK, COSE Key, PGP, etc...) > > As a side note, HPKE requires more than just having a recipient public key, > it also requires knowledge of the recipient supported algorithms... (this > is extremely obvious per the security considerations). > It is natural to assume this will be solved differently in COSE, PGP, > etc... > Maybe it is in the key representation, maybe it is via negotiation, as you > mentioned earlier... > > But it has to actually be solved for, or the sender is just guessing that > the recipient will be able to process their messages.
Well, in store-and-forward system like COSE or JOSE, there are really only two ways: - negotiation. - assume based on application. And when it comes to COSE and JOSE, there are no usable negotation capabilties, so it is the latter: assuming based on application. > When we say "public key" in a COSE WG document, > folks will want to be sure if we are talking about the "abstract concept of > a public key" > or a concrete serialization conforming to normative requirements (JWK > Public Key or COSE Public Key). > > Holding a JWK or COSE "public key" with an algorithm, 🔥 has historically > meant 🔥 holding a recipient's encryption preferences. No, this is not correct. And this has been the case since the first RFCs for both. > There is no precedent for COSE Key or JWK containing "preferences for > parameterization" in addition to a "restriction of key use". However, there is precedent for parametrization. For both COSE and JOSE, since the first RFCs. > You can imagine COSE HPKE asking IANA to update the COSE registry to > communicate that "hkc" is bound to a specific value of "alg", similar to > how -27 is bound to "kty". > (! 🔥 kty and alg confusion intensifies... ) There is no precedent for key parameter being bound to "alg". Being bound to "kty" yes (that is the difference between the two kinds of key parameters in COSE). And in JOSE, analogous split exists, even if it is not explicit in registeries. > ... I prefer to imagine requesting registration of a few good choices for > HPKE COSE (to start), and not importing every option under the sun by > default from the CFRG established registries here: > > How many other preferences would we need to register? Only the ones people > actually want to use, and *they* need to do *some* work to justify why this > is a good idea... With a few plausible extensions to HPKE, over 70. As for how many there currently would be, either 12 or *none at all*, depending on how exactly one defines things. > we don't just hand out a blank check, and leave COSE implementers on the > hook for an ever expanding bill of CFRG registered algorithms. Currently, it is not COSE-HPKE that is on the hook for HPKE algorithms, it is HPKE itself. Just modified my test code to make the following work (with COSE-HPKE code having absolutely no idea what is going on): $ target/debug/cose-hpke-keygen /tmp/mystery-key.key TYPE21 $ echo "The crow flies at midnight" >/tmp/message $ target/debug/cose-hpke-encrypt --algorithm=TYPE2 /tmp/message /tmp/mystery-key.key.pub $ target/debug/cose-hpke-decrypt /tmp/message.chpke /tmp/mystery-key.key.priv $ cat /tmp/message.chpke.decrypted The crow flies at midnight $ In contrast, registering explicit algs would make COSE implementers to be on hook for the bill. And for JWK, explicit algs is non-starter. > HPKE is not actually usable in COSE without some work from this working > group, > we should not defer our responsibility to the (first ever, IIRC) CFRG > established registry, > it is not going to feel good for developers, if we try to start a 5 guy > revolution while the world is trying to upgrade to post quantum encryption. HPKE and its implementation has to update anyway for post-quantum. But does COSE-HPKE and its implementation *also* have to update for post-quantum? With updated HPKE implementation, in the example above, replacing "TYPE21" with "TYPE30" would have enabled Post-Quantum. TODO: Make the code dynamically link against HPKE library. > > Up until COSE_HPKE, 1) and 2) are a single integer ciphersuite. Probably > > anyone doing 3) up to until COSE_HPKE would also use the single integer too. > > > > Agreed. I don't agree. Even ignoring keys, no single integer ciphersuite ever existed in COSE. > > draft-ietf-cose-hpke has addressed 1) with the new HPKE_sender_info header > > parameter. Now the algorithm used is a special ciphersuite identifier that > > indicates further details in an additional parameter. > > > Agreed, there are "proposals for revolution", which I am all for, if they > are coming from enough reviewers / implementers. > I am happy to withdraw my objection if overwhelmed by counter arguments, I > don't find the current arguments from Ilari compelling, but I appreciate > his consistent engagement. If performing asymmetric encryption with COSE or JOSE, there is already further details in additional parameter. > > - In COSE_HPKE we’re requiring algorithm identification be made up of a > > special ciphersuite and a triple. This will/should apply in all contexts > > where COSE algorithm IDs are used. Maybe we should try to unify the > > definition of this in draft-ietf-cose-hpke > > and draft-ajitomi-cose-cose-key-jwk-hpke-kem? > > > I don't think we need another document. > > I think we should bend the knee to convention in COSE HPKE, even over the > objections of Ilari and Daisuke... (assuming they persist in advocating for > parameterization of alg). > > UNLESS, we have clear consensus on proceeding with a revolution, for that I > would want to see a lot more engagement :) Well, speaking for myself, I will continue advocating parametrization. Engagement seems to be very limited for COSE-HPKE. > > My opinions on 3) are: > > - The use cases are too widely varying for anyone to define an actual > > protocol > > - draft-ajitomi-cose-cose-key-jwk-hpke-kem can only work for a small > > fraction of negotiation use cases — those that use COSE_Key for negotiation > > - We might generalize the HPKE COSE algorithm identifier definition so the > > same thing can be used for 1), 2) and 3). That is probably splitting > > HPKE_sender_info > > into two, one structure that is the algorithm ID and one is the enc info. > > We still wouldn’t define actual protocol for 3) but we would have a clear > > common method for COSE HPKE algorithm identification that anyone could use > > for their use-case specific negotiation protocol. > > > I agree with you on 3. I do not see how that would work. And I think that negotiation mechanism that would work for majority of use cases would be straightforward extension of the key draft. No splitting needed. The question is, given that we have not needed negotiation mechanism in the past, why do we need one now? -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
