Hi Ilari,

I fully understand what you are saying and how OKP was supposed to work.
That everything in crypto-land isn't great is also true.

However, overloading established identifiers is seldom a good idea because it 
obviously requires changes in well-functioning code.

I also believe that from a marketing point of view post-quantum algorithms may be 
entitled their own "kty" :) If it is sufficient with one is beyond my insight 
in the matter...

In the draft I also found additional optional fields which doesn't have an OKP 
counterpart.

Cheers,
Anders


On 2022-03-11 17:11, Ilari Liusvaara 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).


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

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to