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