On Tue, Jul 12, 2022 at 12:22:20PM +0200, Anders Rundgren wrote: > On 2022-07-11 18:20, Ilari Liusvaara wrote: > > On Mon, Jul 11, 2022 at 10:26:18AM -0500, Orie Steele wrote: > > > Would you mind replying with hypothetical JWK representations and a label > > > to refer to them, so we can work towards consensus on draft revisions? > > > > > > I am hearing a preference for more specific, which aligns with my option > > > 2, > > > but you go even further to include parameters in the `kty`... > > > > > > Option 4: > > > > <snip> > > > > > To me, this is starting to contradict the original RFC text... because > > > the `kty` no longer refers to a "family" it refers to an "individual". > > > > I think the JOSE RFC text is based on obsolete assumptions. > > If this is the case an errata should be issued.
I later came up with another interpretation of the RFC text. According to that interpretation: - RFC 8037 should have used three kty's: Ed25519, Ed448 and X-function. - Kyber and SIKE should both have same kty, despite being internally wildly different. And this would be new kty. - Dilithium2 and Dilithium3 should be different kty's. Despite being internally and externally extremely similar. - It obviously disagrees with how COSE defines kty. > > > What I think it assumes is that wild internal differences cause wild > > external differences. That is, each "family" has different "keyshape". > > However, that assumption is no longer true with modern cryptographic > > design. > > Object-oriented crypto APIs of the kind I'm working with do not burden > application developers with key shapes except when transforming back > or forth from external representations (*). I have never seen or have able to come up with design for API that can hide keyshapes without dealing with raw JSON blobs. That's exactly what the API I came up with when experimenting with full-dynamic JWS implementation: Dump the raw key JSON on factory object. This is in contrast to how that code handles OKP: It performs the key- shape decoding itself and feeds the factory object blobs that directly go into underlying cryptographic code. I saw some Java Sphincs+ APIs. That thing looked pretty messy to me, especially if one wanted to use it with JOSE with any sensible key representation. > In such systems, an X25519 key is class wise distinct to an Ed25519 > key. I have never come across system where backend implementations of X25519 and Ed25519 keys are any sort of unified. > As a consequence, the "family" concept remains relevant for > application developers which is the primary target for such systems, > while giving crypto system implementers freedom creating the perfect > internal representation. The thing that matters to application developers is what one can do with the key, and how these operations are parmetrized. Which would argue with different classification: - RFC 8037 should have used two kty's: X-function and SKP. - Kyber and SIKE should both have the same new kty. - Dilithium* and Falcon* would also use SKP. - This also obviously disagrees with how COSE defines kty. And another issue is that the kty EC is darn mess for interpretation like that. The secp256k1 being especially problematic. If one would like to make EC even worse mess than it already is, registering Edwards25519, Edwards448 or E-521 would do the trick. > I doubt this will change because it is helping application developers > who only occasionally qualify as cryptographers, which BTW include > yours truly :) Crypto is just too spicy for application developers. Which is why the modern cryptographic design handles keys the way it does. And such key handling maps neatly into OKP (and AKP in case of signature algorithms). -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
