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

[John K <[e-mail]>]

I think there are several related items being discussed:

On 3/10/22 12:15, Mike Jones 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.
>
OK, so kty is intended to be a way of coding how the remaining 
parameters in a JWK should be treated? That is different than the "key 
generation algorithm", or mechanism used to generate the key (ie. which 
curve was used, which shows up in "crv").

> 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”.
>
 From my use of JOSE, I would say that 'alg' actually indicates a 
signature *profile* (a combination of algorithms), which may indicate 
both a signature algorithm AND a hashing algorithm, and even some other 
parameters (as in RSA-PSS use of MGF).

Regards,

- johnk

> -- 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]>om>; 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>)...
>     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> <http://mesur.io>
>     >
>     >
>     >
>     > --
>     > *ORIE STEELE*
>     > Chief Technical Officer
>     > www.transmute.industries <http://www.transmute.industries>
>     >
>     > <https://www.transmute.industries>
>
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose