Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

[Mike Prorock <[e-mail]>]

+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 <[e-mail]>
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 <[e-mail]>
> *Sent:* Thursday, March 10, 2022 9:06 AM
> *To:* Anders Rundgren <[e-mail]>
> *Cc:* Orie Steele <[e-mail]>es>; Mike Jones <
> [e-mail]>gt;; Russ Housley <[e-mail]>om>;
> [e-mail]
> *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 <
> [e-mail]> 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>)t;)...
> 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 <[e-mail] <mailto:
> [e-mail]>> 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>
>
>