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 Fri, Mar 11, 2022 at 05:23:48AM +0100, Anders Rundgren wrote:
> Before deciding to overload "OKP" for a new crypto system, I would discuss the matter with maintainers of cryptographic libraries and APIs.
> 
> In the Java platform overloading the native counterparts to OKP keys
> [1,2] won't happen because that would break a lot.  I guess the same
> is valid for OpenSSL.

The way it is supposed to work is to use the raw key parts as key
material in underlying cryptographic implementation. Implementations
where that is not possible are just broken.

> It seems to me that reusing OKP would rather create an artificial
> "semantic gap" which doesn't exist today where "kty" indeed is
> synonymous with key type/family (RSA, EC, Ed etc):
> https://datatracker.ietf.org/doc/html/rfc7517#section-4.1

There are already two "subtypes" of OKP keys that are not
interchangeable:

- Key agreement keys.
- Signature keys.

NISTPQC signatures would fit into signature keys "subtype", but NISTPQC
KEMs will not fit into the key agreement keys "subtype", so that would
be a third "subtype" (all NISTPQC algorithms have OKP-style key format,
as this was required by NIST).


This is very different from RSA and EC2, where there are no subtypes,
and all keys are interchangeable.


Another place similar multi-subtype non-interchangeable keys are seen
is symmetric algorithms, as there are at least two "subtypes":

- AE(AD) Encryption keys.
- MAC keys.



-Ilari