+1 Mike - that is helpful. Any thoughts of applying that in this case? Seems like it would line up well with key types for the two main things in play here: 1) post quantum, hash based algorithms 2) post quantum, lattice based algorithms
This would also help on the implementation side as well per Ander's note Mike Prorock CTO, Founder https://mesur.io/ On Thu, Mar 10, 2022 at 12:15 PM Mike Jones <[email protected]> wrote: > As the inventor of “kty”, I’ll say that its intent is to indicate which > key syntax is used among keys representations that are syntactically > different. It’s for syntax – not semantics. > > > > To understand the semantics of how to use the key, you have to also know > the “alg” value, as many algorithms may use keys with the same syntax – > such as “OKP”. > > > > -- Mike > > > > *From:* Mike Prorock <[email protected]> > *Sent:* Thursday, March 10, 2022 9:06 AM > *To:* Anders Rundgren <[email protected]> > *Cc:* Orie Steele <[email protected]>; Mike Jones < > [email protected]>; Russ Housley <[email protected]>; > [email protected] > *Subject:* [EXTERNAL] Re: [COSE] > draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda > Items for IETF 113 in Vienna] > > > > Anders, > > That read closely matches my interpretation as well, and is part of why i > suggested that we might want one new 'kty' for post quantum, or perhaps two > in this case (breaking things apart by family of algorithms) - 1) for > lattice based algorithms, possibly 'PQL', and 2) for hash based approaches, > perhaps 'PQH' > > This way the kty is additionally informational in that we are indicating > that the algorithms are post quantum in nature, and then the specific > family of post quantum approach that is being followed. This could be very > beneficial with something like SPHINCS+ where then the 'alg' can break out > as required for: > > SPHINCS+-SHAKE256-[PARAMETERS] > SPHINCS+-SHA-256-[PARAMETERS] > SPHINCS+-Haraka-[PARAMETERS] > > > Mike Prorock > > CTO, Founder > > https://mesur.io/ > > > > > > > > On Thu, Mar 10, 2022 at 10:56 AM Anders Rundgren < > [email protected]> wrote: > > Hi Orie, > > TL;DR > > This is my interpretation of how things presumably were intended to work: > > Each "kty" represents a family of related key algorithms. > > Each signature "alg" represents a specific signature algorithm that is > compatible with exactly one "kty" family but not necessarily with all of > its members. For ECDH which is polymorphic things gets a little bit more > fuzzy since it involves multiple "kty" families. > > Since "kty" is a top-level item you should (IMO...) be free to define > within reason :) whatever sub-level items that matches the algorithm > specification. The bottom line is that it must be easy to figure out which > specific key- and signature-algorithms that were used, preferably > supporting table-driven designs as well. > > However, the existing "kty" definitions should (for not breaking existing > software) be regarded as frozen even if EC keys indeed can be used both for > ECDH and ECDSA (but the use-cases for that are few if any). > > If there are strong arguments for not using the same key with multiple > signature algorithms (assuming it is actually technically feasible as > well), the most robust solution would be to define signature and key > algorithms as pairs using the same identifier, but not under the same label > since "alg" already is reserved for use in "kty"s. You could also just say > that "alg" in a "kty" is RECOMMENDED. A problem here is that this scheme > does not necessarily work at the crypto API level and then it becomes > useless. If this problem is for real, I would talk to the algorithms > designers to get their view on this as well. This is obviously history in > the making :) > > Cheers, > Anders > > > On 2022-03-10 14:57, Orie Steele wrote: > > seems like I should have replied here first... I agree with the comments. > > > > If we think overloading will cause problems we should avoid it. > > > > The problem with switching on key type alone is that there are key types > used for multiple signature algorithms. > > > > I would recommend switching on kty + crv when present... but even then, > secp256k1 supports both ECDSA (ES256K) and Schnorr (unregistered, but I > once proposed SS256K at DIF - > https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019 < > https://github.com/decentralized-identity/SchnorrSecp256k1Signature2019>)... > we also have the problem of normalize to lower s in ES256K... we > would probably need a new alg to signal that all ES256K signatures had been > normalized... so there is a future where a single public key > representation might verify many unique signature formats... without the > requirement to signal which one it was "meant for". > > > > Our current approach with dilithium leaves us wishing `alg` were > required in all key formats... it's also a best practice not to use the > same key material for multiple algorithms... alg needs to be present to > help mitigate this, because otherwise any signature that verifies with the > key would be acceptable since the key representation does not signal an > intention.... depending on your perspective on security, you > might think this is a good thing. > > > > All this to say, if you are only looking at `kty` you might have other > issues, at least with certain crv values that are registered today, we > should avoid making this problem worse. > > > > OS > > > > > > On Thu, Mar 10, 2022 at 4:27 AM Mike Prorock <[email protected] <mailto: > [email protected]>> wrote: > > > > Thanks Anders, > > This implementation side is exactly why I set kty as a unique value > first. This work started when I was testing an implementation of > Dilithium, and then SPHINCS+ with some of our existing code and I wanted a > clean way to branch down a path to the new libs without adjusting our > existing code that switches on key types. This was so that we could begin > validating our ability to handle post quantum algorithms once NIST > finalizes, based on a few customer requests. > > > > Mike Prorock > > mesur.io <http://mesur.io> > > > > > > > > -- > > *ORIE STEELE* > > Chief Technical Officer > > www.transmute.industries > > > > <https://www.transmute.industries> > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
