On Tue, Sep 27, 2022 at 09:00:54AM -0500, Orie Steele wrote: > Daisuke, > > Thank you for your reply and the link to the deck. > > Your proposal on slide 4 makes your argument very clear. > > Inline: > > On Mon, Sep 26, 2022 at 5:35 PM AJITOMI Daisuke <[email protected]> wrote: > > > Hi Orie, > > > > > I would expect ANY new 'alg' values to have some mapping to JWK / CWK. > > > > As Ilari mentioned, this is false for the encapsulated key in the first > > place but I'd like to know why the encapsulated key should be mapped to > > JWK/CWK. > > > > I agree regarding encapsulated keys, disagree regarding serialized public > keys or private keys.
It is also false for stateful signature private keys. COSE has "HSS-LMS" kty, which does not have private key format. However, it should be true for all encryption private keys. Modern designs that are not frameworks (e.g., Kyber) have simple mapping to OKP. For frameworks (e.g., HPKE) or non-modern designs (likely not good), it may be new kty. However, while adding Kyber keys is trivial, adding the algorithm is not, because it doesn't work like existing algorithms. However, it has a lot of overlap with HPKE in the general case. > This is based on my limited understanding, and this comment: > https://mailarchive.ietf.org/arch/msg/jose/IKIR_XusfHD26ewqZSt5ad2WUc8 > <https://mailarchive.ietf.org/arch/msg/jose/IKIR_XusfHD26ewqZSt5ad2WUc8/> > > I understand the chairs to be asking this question, as well.... and it > maps to your proposal on slide 4. > > > > Why do you want to encode encapsulated keys to JWK/COSE_Key in spite of > > the fact that the encapsulated key (NOT recipient's public key) is > > generated and consumed inside the COSE-HPKE process and any applications > > don't need to know the format and don't need to handle the format directly? > > > > To be clear, I don't... in the examples I tried to show the 2 examples > based on the comment above. > > I was trying to sketch your proposal as "Case 1"... but using JSON syntax > seems to have created more confusion than helped. > > > > Additionally, please tell me why you can ignore the five shortcomings I > > mentioned on my slide. > > > > https://docs.google.com/presentation/d/1azfHu93NCm5M9KUbpbtRze7aitvpBAj9SxhpvHe877M > > > > > >From your slides: > > 1) Will the addition of a new HPKE algorithm cause any changes to the > specifications and existing implementations on the COSE side? > > For the current draft (-02), you said: Yes. Whenever a new cipher suite is > added to HPKE, it is necessary to develop a mapping specification for > COSE_Key (including alg/crv value registration to IANA) and implement an > additional enc->COSE_Key conversion process in existing many COSE libraries. > > I agree the answer is currently Yes. > > Your proposal says No. > > I think when you generate a new key pair for use with HPKE, you should set > an alg value for use at that time, and not change it. In HPKE, that only appiles to KEM and KDF identifiers. It is perfectly sound to mix and match AEAD algorithms; the only concern is what AEAD algorithms the recipient supports. The KEM identifier obviously can not be changed, because it subtypes the key. The situation with KDF identifier is a lot more subtle: Due to KEM interface shortcomings, HPKE can not soundly contextualize on the KDF. This is why my HPKE kty design has single-valued field for KDF and why the AEAD field is an optional hint. > This means when new alg values are created, new keys are created, and > regististries must be updated before these keys can be understood. It is not just registry updates: Due to how relevant registeries work, a full specification is needed. And if that specification contains anything nontrivial, that is going to add a lot of implementation complexity. What COSE-HPKE implementation backed by HPKE library actually needs to know is what values to feed into HPKE library. Obviously that task is the simplest when it can just extract those values raw from the key and the message. Why would COSE-HPKE implementation care about what is KEM 48? Or KDF 4? or AEAD 4? (none of those are presently registered). It should just shove those into HPKE libarary code and let it figure it out. > 2) Can HPKE cipher suites be negotiated dynamically and flexibly between a > recipient and a sender? > > For the current draft (-02), you said: No. KDF cannot be negotiated. In > the current draft, acceptable combinations of KEM and KDF are restricted. > This kind of restriction might be acceptable on upper-layer application > spec but it is not good for common layer spec. Right. And the reason is that restricting combinations of KEM and KDF adds a lot of specification complexity, and might also lead to a lot of implementation complexity. > I agree the answer is currently No. > > I don't have enough expertise to comment on this part of the spec, or your > proposal. > > 3) Is the information sent from a sender to a recipient necessary and > sufficient? > For the current draft (-02), you said No. kty (and crv) are mandatory in > COSE_Key but it’s not necessary for a recipient. Moreover, it’s not > sufficient because it does not have an HPKE cipher suite information enough > for a recipient to determine a specific HPKE cipher suite chosen by a > sender. > > I believe this last point is where most of the confusion lies. > > In the case of an encapsulated key, my understanding is that the only > "missing necessary requirement" is the HPKE cipher suite. The HPKE cipher suite consists of KEM, KDF and AEAD. And the key absolutely has to tell what the KEM is. This only leaves KDF and AEAD. I think key should also specify KDF. This only leaves AEAD to the message. > ^ Your proposal defines this as a new `alg`. Is it legal for this `alg` to > also show up in a COSE_Key?... This is where the lines are getting blurry. alg is legal in COSE_Key. However, it has very specific meaning, and deviating from that is not a good idea. > In the case of a serialized public key (epk), my understanding is that if > it's a COSE_Key, kty (and crv) are mandatory, but that they may not be > necessary, because they can be inferred. For COSE_Key, the only mandatory field is kty. However, specific kty's can make other fields mandatory. E.g., EC2 and OKP make crv mandatory. It is the same for JWK. > The point I am making regarding preference for established key formats, > such as JWK/COSE_Key, only applies to this last sentence ^. > > The position I am advocating for is to continue to support `epk` in a > standard format, because I believe that's what most developers with > experience would expect. That only works in special cases. Kyber _will_ break it in very ugly way. The very next KEM to be added to HPKE probably breaks it in very ugly way (and if it is not the next one, eventually there _will_ be one). > In your proposal you refer to this value as "HPKE Sender Information", > where "kty" and "crv" are not required but `alg` is... and the missing > values are inferred from the recipient. > > Your proposal saves bytes, at the cost of introducing a new "epk like" > thing. As said above, Kyber and HPKE will need such thing. Epk just will not do for those. > I realize my position "wastes bytes", but in my experience new keys or key > like formats are "more expensive" in human terms and complexity. > > It's also possible I don't know what I am talking about. > > I am new to HPKE and I am bringing a bunch of assumptions from years of > working with JOSE. I think the biggest sources of misunderstanding is how HPKE interface works and how it is typed. Not so much thinking COSE is like JOSE (it mostly is, but is a bit more flexible). I don't think RFC 9180 (HPKE) even explicitly says how things are typed, it just needs to inferred what is the one type that makes sense in each instance (most are either u16 or bstr, but there are others, and there is even a type sum in there). > I hope I have answered your questions, I find the visual examples really > helpful when trying to understand the arguments... but I can also see how > they might add to the confusion. > > I consider Daisuke to have provided an example of an alternative approach, > but I am not enough of an expert to know if it's sufficient for > specification. > > Similarly Ilari has provided an alternative approach, but I am not enough > of an expert to know if it's sufficient for specification. I think the only thing missing is codepoint integer assignments. > Based on my understanding of their arguments, a new `alg` would NOT need to > be registered for new HPKE cipher suites. Right. And that is actually explicit goal in my latest designs. > And therefore new keys would not be bound to a specific HPKE cipher suites, > but rather to the family of all HPKE in general... with the details of that > binding conveyed via cose headers. > > This does not map to my intuition looking at the test vectors. > > https://www.rfc-editor.org/rfc/rfc9180.html#name-test-vectors > > I would love to hear from the authors of the RFC on this point. It would still be bound to partial HPKE cipher suite. And such partial binding absolutely has to happen, because KEM is both part of cipher suite and the key itself. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
