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

From: Mike Jones <[email-masked]>
Date: Thu, 10 Mar 2022 17:15:48 +0000

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.

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

                                                       -- Mike

From: Mike Prorock <[email-masked]>
Sent: Thursday, March 10, 2022 9:06 AM
To: Anders Rundgren <[email-masked]>
Cc: Orie Steele <[email-masked]>; Mike Jones <[email-masked]>; Russ Housley <[email-masked]>; [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> 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>

---

From: Mike Prorock <[email-masked]>
Date: Thu, 10 Mar 2022 12:41:16 -0500

+1 Mike - that is helpful.

Any thoughts of applying that in this case?  Seems like it would line up
well with key types for the two main things in play here:
1) post quantum, hash based algorithms
2) post quantum, lattice based algorithms

This would also help on the implementation side as well per Ander's note

Mike Prorock
CTO, Founder
https://mesur.io/

On Thu, Mar 10, 2022 at 12:15 PM Mike Jones <[email-masked]>
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.
>
>
>
> 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”.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Mike Prorock <[email-masked]>
> *Sent:* Thursday, March 10, 2022 9:06 AM
> *To:* Anders Rundgren <[email-masked]>
> *Cc:* Orie Steele <[email-masked]>; Mike Jones <
> [email-masked]>; Russ Housley <[email-masked]>;
> [email-masked]
> *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:
>
> On Thu, Mar 10, 2022 at 10:56 AM Anders Rundgren <
> [email-masked]> wrote:
>
> Hi Orie,
>
> TL;DR
>
> 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
>
>
> > 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-masked] <mailto:
> [email-masked]>> 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>
> >
> >
> >
> > --
> > *ORIE STEELE*
> > Chief Technical Officer
> > www.transmute.industries
> >

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 10 Mar 2022 20:05:31 +0200

On Thu, Mar 10, 2022 at 12:41:16PM -0500, Mike Prorock wrote:
> Any thoughts of applying that in this case?  Seems like it would
> line up well with key types for the two main things in play here:

All of Falcon, Dilithium and SPHINCS+ use the same key format (this was
due to NISTPQC algorithm requirements). Which is byte string
public/private key, which would map to OKP in both COSE and JOSE.

As for mixing algorithms and keys, I think all wrong combinations are
guaranteed to blow up as key and signature sizes just do not match up.

-Ilari

---

From: John K <[email-masked]>
Date: Thu, 10 Mar 2022 15:31:27 -0500

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

> *Cc:* Orie Steele <[email-masked]>; Mike Jones 
> <[email-masked]>; Russ Housley <[email-masked]>; 
> [email-masked]
> 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:
>
> On Thu, Mar 10, 2022 at 10:56 AM Anders Rundgren 
> <[email-masked]> wrote:
>
>     Hi Orie,
>
>     TL;DR
>
>     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
>
>
>     > 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>)...
>     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".
>     >
>     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-masked]
>     <mailto:[email-masked]>> 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>
>     >
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 11 Mar 2022 05:23:48 +0100

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.

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

It is important to early on bring issues like this to a wider audience so we don't repeat the oddities we have seen in FIDO/COSE where EC signatures have different encodings and Ed25519 algorithm identifiers have different meanings.

Thanx,
Anders

1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/interfaces/EdECKey.html
2] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/interfaces/XECKey.html

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 11 Mar 2022 18:11:48 +0200

On Fri, Mar 11, 2022 at 05:23:48AM +0100, Anders Rundgren wrote:
> 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):

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

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 11 Mar 2022 17:33:49 +0100

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

---

From: Rafael Misoczki <[email-masked]>
Date: Fri, 11 Mar 2022 13:15:41 -0500

Re: creating a kty for PQC algorithms (or any other way of grouping these
algorithms to indicate they are PQ-secure), two things to consider:

- These algorithms are *currently* classified as post-quantum secure, and
the truth is that we can't guarantee this property in the long-term. As an
example of how these things may change quickly, we just saw a *3rd-Round
Finalist* candidate (Rainbow <https://www.pqcrainbow.org/>) being subject
to a devastating *classical* attack <https://eprint.iacr.org/2022/214.pdf>.

- Only very carefully selected parameters lead to instances of these
algorithms which can be (currently) called post-quantum secure. If
the community/NIST ends up standardizing parameters with overestimated
security, this may lead to quantum vulnerable instances of these algorithms
in this group of PQ-secure algorithms while they are not PQ-secure.

Just some food for thought for the situation where these algorithms are
grouped with some indication they are "PQ-secure" but later on we found
they are not. There might be some benefits for not officially labeling them
as "PQ-secure" in any way, and instead only indicate what is the underlying
class of problems (e.g. lattices, or hash, or isogney, etc).

On Fri, Mar 11, 2022 at 11:34 AM Anders Rundgren <
[email-masked]> wrote:

> 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...
>
> >> Before deciding to overload "OKP" for a new crypto system, I would
> discuss the matter with maintainers of cryptographic libraries and APIs.
> >>

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Mar 2022 15:34:08 -0500

> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

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

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 12 Mar 2022 06:02:15 +0100

You may also consider "pluggable" crypto provider schemes.  In such schemes, each core crypto system (RSA, EC, etc) have its own name space.

If you want COSE/JOSE keys to potentially become an integral part of pluggable crypto system architectures, unique, family specific, top level algorithm identifiers is a prerequisite.

Are there any pluggable crypto systems out there?  Not that I'm aware of but it would be possible to extend the (semi-pluggable) Java crypto system so that it could deal with external key representations in a fully transparent way instead of burden application and library developers with such details.  This already works out of the box (in just about all crypto platforms), for public keys in X.509 certificates although current implementations are "hard coded".

Cheers,
Anders

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 12 Mar 2022 11:59:00 +0200

On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote:
> 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.

One idea how (modelled on ECDH-ES, as operation of KEMs is very similar
to ECDH-ES):

- Add new alg values KEM+{A{128,192,256}KW,HKDF-{256,512}}, mirroring
  the ECDH-ES ones.
- Add new new header algorithm parameter "encapsulated ciphertext"
  (bstr) that carries the KEM ciphertext.
- Sender procedure:
  - Select the public key to encrypt to.
  - Apply the KEM encapsulate operation to the public key.
  - Use the encapsulate secret output as input for key derivation, just
    like in ECDH-ES.
  - Write the encapsulate ciphertext output into the "encapsulated
    ciphertext" header algorithm parameter.
- Receiver procedure:
  - Retretive the private key to use.
  - Read the ciphertext input from the "encapsulated ciphertext" header
    algorithm parameter.
  - Apply the KEM decapsulate operation to the private key and the
    ciphertext. If decapsulate fails, fail.
  - Use the decapsulate secret output as input for key derivation,  just
    like in ECDH-ES.

A word of cauntion: Altough it might seem that the "encapsulated
ciphertext" header can be reused for HPKE, there is a subtle issue:
This mechanism can not trivially support compressing the ciphertext. So
reusing it would require HPKE to define compact NIST curves, so COSE
could just forget about key compression.

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Sun, 13 Mar 2022 12:39:24 -0400

> On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[email-masked]> wrote:
> 

If you are talking about ECC Point Compression, I agree that COSE should ignore it.  For a very long time, the patent kept many implementations from supporting it.  Now that patent has expired, but the engineering effort to add support for ECC Point Compression is significant, and everyone will have to be prepared to encounter implementations that are not yet prepared to handle compression.  The savings of 32 bytes does not seem worth the transition pain.

Russ

---

From: Orie Steele <[email-masked]>
Date: Mon, 14 Mar 2022 10:19:57 -0500

Refocusing on the "kty" : "OKP" vs "PQK" issue.

As I understand it, "alg" is optional even when "kty": "OKP"... so a main
reason to choose "kty": "PQK" would be to say that "alg" is now required...
If we think overloading "OKP" would cause harm, we should make the new
"kty" bring more to the table, such as mandating the presence of "alg".

I expect we will be marking "alg" values as forbidden (when the become
unadvisable), and not marking whole "kty" families as forbidden in the
future... having the "alg" be required in "kty" "PQK"  seems like it
provides a better security posture in that context, but eager to hear from
others.

Regards,

OS

On Sun, Mar 13, 2022 at 11:39 AM Russ Housley <[email-masked]> wrote:

> If you are talking about ECC Point Compression, I agree that COSE should
> ignore it.  For a very long time, the patent kept many implementations from
> supporting it.  Now that patent has expired, but the engineering effort to
> add support for ECC Point Compression is significant, and everyone will
> have to be prepared to encounter implementations that are not yet prepared
> to handle compression.  The savings of 32 bytes does not seem worth the
> transition pain.
>
> Russ
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries