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

[Ilari Liusvaara <[e-mail]>]

On Thu, Mar 10, 2022 at 04:56:55PM +0100, Anders Rundgren 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.

No, each "kty" represents a key format. Each key format may or may not
have multiple key types.

For example, OKP is the key format with octet string private and public
keys. It explicitly has nothing to more to do with elliptic curves than
that initial key types all happened to be based on elliptic cuves.

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

Each alg is compatible with key types it is compatible with. That might
include some key types of some key format (happens especially with OKP)
or it might include entiere key formats (happens especially with EC2),
or both at once.

That might turn out to be bit problematic if, e.g., some joker defines
some coordinate-swapped Edwards curve as EC2. Those things work just
fine for ECDH. Attempting to perform ECDSA technically works, but breaks
ECDSA specification.

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

It goes the other way around: Once one has a new key type, one goes to
see if it has existing key format, or if one should define a new key
format for it.

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

Not being able to introduce new key types would for example imply that
new elliptic curves can not be added.

> 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 :)

In general,  using the same key with multiple signature algoritihms is
not cryptographically kosher. In fact, RSA-PKCS#1v1.5 is one of the rare
exceptions (it has encoded message level indication of hash algorithm
used).

It depends on algorithm if trying to use mismatching key and algorithm
is guranteed to blow up as implementation is faced trying to do the
impossible (e.g., trying to mismatch dilithium2 and dilithium3),  or if
it is just omittable implementation checks that prevent some
key/algorithm pair from working (e.g. trying to mismatch ES384 and
P-256 curve).


However, there is no "key says what alg this actually is" alg value in
COSE and JOSE. However, in current HTTP signatures work, there is such
value (omitted alg means exactly that).



-Ilari