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 <[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> <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
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
