On Mon, Apr 17, 2023 at 11:42:51AM -0500, Orie Steele wrote: > > On Mon, Apr 17, 2023 at 10:06 AM AJITOMI Daisuke <[email protected]> wrote: > > > Apple's use of "alg" is directly equivalent to your proposed key > representations, just simpler:
No, it is not equivalent. Nor is it simpler once integrated. <2 example JWKs> I presume these two are actually COSE_Key, just written using JWK syntax because that is easier? > > Since HPKE is designed to be cryptoagility-oriented, it is natural to > > follow that design philosophy in COSE-HPKE as well. > > > > No! : ) > > It is not natural to forward cryptographic algorithm > parameterization agility from a CRFG work item, to envelope formats and > application developers. > > What works well for cryptographers, does not always work well for > "traditional application developers", or developers used to working with > JOSE and COSE. The problem is that not forwarding it means lots of extra work that can not be done up front. And this is not just extra work for the COSE WG, it is also extra work for the implementers of COSE-HPKE. And I have never seen omnibus ciphersuites work well for anything transcending an simple application. And unfortunately, everybody's favorite of TLS 1.2- is from milder end of things going wrong. So absent some truly new ideas, I am going to assume that any omnibus ciphersuite system in specification is going to turn into a mess at best. Yes, sometimes combining algorithms makes perfect sense, but it must be considered carefully. And even if such combining originally would have made sense, it does not necressarily make sense if integrating something else. This is actually the case with HPKE: For HPKE, combining KEM and KDF would have made sense. However, for COSE-HPKE, it does not, because that would lead into lots of extra work. And with regards to integrating HPKE into protocol, I have seen three protocols so far, not counting COSE-HPKE. Two of those just forward the raw agility from HPKE. One uses ciphersuites. Let's just say the last is unfortunately not a counterexample to what I wrote above. > RSA expressions are often cited when this comes up... because normal > developers don't understand why they need all these values: > > https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3 > > ^ this is what HPKE is proposing to bring back... Parameters for > HPKE keys... instead of parameters for RSA Keys. The difference is that RSA parameters do not couple to anything else. This allows deparametrization with little downside. > > If someone wants to adopt a ciphersuite-based approach, they can do so on > > higher-level applications that utilize COSE-HPKE. > > > > > This really is the primary point of contention. > > Perhaps we should ask CFRG to do 2 new RFCs for ECDSA and ECDH so we can > add: > > Why use alg: ES256, when you can use this instead: <snip silly example> ECDSA is parameterized by curve and hash. curve naturally associates with the key, and hash naturally assoicates with the message. And this is in fact exactly how ECDSA in X.509 works. And well, (integer) registry of hashes is pretty perennial topic that comes up again and again in various places. I have already lost count. > Why use alg: ECDH-ES+A128KW, when you can use this instead: <snip another example> How does this differ from HPKE? Not allowing stuff where ciphertext is not a key? > Then COSE and JOSE registries can defer all future algorithm code points to > the CFRG established registries, like we are currently proposing for HPKE. There is another reason why this is silly with ECDSA: ECDSA only allows SHA-2 and SHA-3 as hashes, and you really do not want SHA-3 with ECDSA. That only leaves SHA-256, SHA-384 and SHA-512. Which are ES256, ES384 and ES512 in COSE. So we already have every alg needed. > If we leave COSE HPKE the way it currently is, I expect we will have to > keep explaining why kty: RSA, EC, OKP, and HPKE all look so different, and > why there was a brief window, where parameterization seemed to be unpopular. The only pair from that list that is even slighly nontrivial to explain is OKP vs. HPKE. Since that is subtyping on different registry instead of some blatant structural difference for some obvious reason. > It seems like answering this question with "because we learned from > mistakes made in RSA, fixed them with EC and OKP, and this is how it has > always been, and it's considered a best practice" is easier than: > > "because we wanted HPKE to be structured very differently from previous > COSE / JOSE standards (except for RSA)". Actually, The classic RSA mistakes already seem to be fixed in JOSE. But yeah, the present HPKE kty from the draft is just bizarre. It seems to mix subtyping and flawed negotiation mechanism. > > Laurence seems neutral so far > > > > ... at least, the definitions of the "alg" value (HPKE-v1-{Base, Auth, > > PSK, AuthPSK}) included in the COSE-HPKE specification and my draft were > > proposed by Laurence (I like this idea), so I believe that Laurence > > supports the current COSE-HPKE. Also, the definitions of the "alg" value > > are also an important part of my draft. Therefore, with Laurence's consent, > > we have added him as a co-author in the latest draft. Of course, I don't > > think Laurence fully agrees with my current draft. > > > > > As I said before, I am happy to be overruled on this point. > > I understand the 2 approaches, I think following the current JOSE / COSE > conventions and registering an "alg" per suite proposal is better, and I > can cite industry adoption to support my point. Why should I expect that not to lead into a mess at best? -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
