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

[Orie Steele <[e-mail]>]

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)...
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]> 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
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>