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

[Russ Housley <[e-mail]>]

> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[e-mail]> wrote:
> 
> 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).

Right.  It makes sense to add support for KEM.  We can figure that out without waiting for NIST to announce Round 3 winners.  We can do the work based on RFC 5990.

Russ