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: Mon, 14 Mar 2022 16:18:22 +0000

Requiring “alg” in a JWK for one class of algorithms and/or key type values would be non-parallel to other algorithms and/or key type values.  This matters not just for aesthetic reasons but also because it would make the JWK Thumbprint calculations [RFC 7638] have to special-case these algorithms and/or key type.

Yes, you always need to know the “alg” when using a key – but in JOSE and COSE you already authoritatively get that from the JOSE or COSE header parameters.  I believe there’s insufficient reason to make things different for this new class of algorithms.

                                                       -- Mike

From: COSE <[email-masked]> On Behalf Of Orie Steele
Sent: Monday, March 14, 2022 8:20 AM
To: Russ Housley <[email-masked]>
Cc: Ilari Liusvaara <[email-masked]>; [email-masked]
Subject: Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

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]<mailto:[email-masked]>> wrote:

> On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote:
>>
>>
>>> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> 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.
>
> 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.

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

_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose

--
ORIE STEELE
Chief Technical Officer
www.transmute.industries<http://www.transmute.industries>

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries/>

---

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

>  I believe there’s insufficient reason to make things different for this
new class of algorithms.

If that's the case, we will need to register a new "crv" like property for
post quantum keys, let's call it "pset" for now, as we had originally
intended to register this property, and it's still present in the current
draft.

And then define a mapping between that new property and every supported alg.

For example:

- kty:EC, crv:P-256 -> alg:ES256 / alg:ECDH-ES+A256KW
- kty:EC, crv:secp256k1 -> alg:ES256K
- kty:OKP, crv:Ed25519 -> alg:EdDSA
...
- kty:RSA, n / e -> alg:PS256 / RS256 ?
- kty:EC, crv:secp256k1... ? -> alg:ES256K / alg:SS256K?
...

- kty:PQK, pset: CRYD3 -> alg: CRYD3
- kty:PQK, pset: CRYD5 -> alg: CRYD5
- kty:PQK, pset: xmss.public_key.SHA2_10_256 -> alg: xmss.SHA2_10_256 ?

We have learned a lot since JOSE was first created.

In particular we have learned that handling optional parameters is a source
of security issues, especially related to "alg".

New registrations should not make this problem worse.

If we can't make "alg" required for "kty:PQK" we will need to define a new
"pset"  or similar, and it will have to have a mapping for every registered
`alg`.

So for a dilithium example:

kty: PQK (required)
pset: CRYD3 (required)
x: ... (required)
alg: CRYD3 (optional)

Obviously JWK thumbprint will need to be aware of all required fields, and
will need to drop all optional fields in order to be useful.

If we don't define something like "pset" and we don't make "alg" required
for "kty:PQK"... the only optional will be to explode based on mismatched
keys / signatures... unless I am missing something... we have the same
problem with P-256 keys today... when "alg" is not present, you can't tell
if the key is for "signing" or "key agreement"... which means that any JWE
/ JWS can target that key, and the key representation won't catch what the
key was intended for... unless "alg" and "use" are present... which nobody
can rely on, because they are marked optional.

Take a look at:
https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties

Notice that they include "alg" and "use"... if both are optional, why
include them in such an example?

FWIW I think making "alg" required is the best thing to do for new key
types moving forward (it addresses future ambiguity / explicit over
implicit makes me feel safer).

Extra language regarding thumbprint computation seems "worth it" for
removing parameter kty type to alg type ambiguity.

Keep in mind we will have this same issue for the families of lattice,
hash, and isogeny... So if we set a precedent of registering an alternative
for 'crv' for lattices say. "pset", we will need to follow through with the
others as well, either reusing that new parameter or creating a new one for
each family.

@Mike Jones

Should there be 1 new "crv' like property or 1 per family (3 in total).

What would you suggest for the new "crv" like parameter name? "pset" ?

Do you have an alternative proposal?

OS

On Mon, Mar 14, 2022 at 11:19 AM Mike Jones <[email-masked]>
wrote:

> Requiring “alg” in a JWK for one class of algorithms and/or key type
> values would be non-parallel to other algorithms and/or key type values.
> This matters not just for aesthetic reasons but also because it would make
> the JWK Thumbprint calculations [RFC 7638] have to special-case these
> algorithms and/or key type.
>
>
>
> Yes, you always need to know the “alg” when using a key – but in JOSE and
> COSE you already authoritatively get that from the JOSE or COSE header
> parameters.  I believe there’s insufficient reason to make things different
> for this new class of algorithms.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* COSE <[email-masked]> *On Behalf Of * Orie Steele
> *Sent:* Monday, March 14, 2022 8:20 AM
> *To:* Russ Housley <[email-masked]>
> *Cc:* Ilari Liusvaara <[email-masked]>; [email-masked]
> *Subject:* Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was:
> Re: Call for COSE Agenda Items for IETF 113 in Vienna]
>
>
>
> 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:
>
>
>
> > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[email-masked]>
> wrote:
> >
> >>> On Mar 11, 2022, at 11:11 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
>
> [email-masked]
> *ORIE STEELE*
> www.transmute.industries
> <https://www.transmute.industries/>
>

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

<https://www.transmute.industries>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 15 Mar 2022 05:03:48 +0100

Hi Orie,

To me PQK represents overloading since the anticipated crypto systems seem to be more or less unrelated. Overloaded identifiers make the introduction of new algorithms more difficult and is at odds with pluggability.

To avoid overloading kty:CRYD3 could be a possible choice.  For DH keys (if applicable), I would consider kty:CRYD3-DH which would give you basic algorithm separation.

BouncyCastle which has been the leading crypto provider for Java (until Java17), have indeed defined a unique key type for the single PQC algorithm they currently support:
https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/pqc/jcajce/spec/SPHINCSPlusParameterSpec.java

It would be valuable knowing what the PKIX folks are planning here since they have basically the same problem.  Russ?

Thanx,
Anders

On 2022-03-14 21:19, Orie Steele wrote:
>  >  I believe there’s insufficient reason to make things different for this new class of algorithms.
> 
> If that's the case, we will need to register a new "crv" like property for post quantum keys, let's call it "pset" for now, as we had originally intended to register this property, and it's still present in the current draft.
> 
> In particular we have learned that handling optional parameters is a source of security issues, especially related to "alg".
> 
> If we can't make "alg" required for "kty:PQK" we will need to define a new "pset"  or similar, and it will have to have a mapping for every registered `alg`.
> 
> Obviously JWK thumbprint will need to be aware of all required fields, and will need to drop all optional fields in order to be useful.
> 
> If we don't define something like "pset" and we don't make "alg" required for "kty:PQK"... the only optional will be to explode based on mismatched keys / signatures... unless I am missing something... we have the same problem with P-256 keys today... when "alg" is not present, you can't tell if the key is for "signing" or "key agreement"... which means that any JWE / JWS can target that key, and the key representation won't catch what the key was intended for... unless "alg" and "use" are present... which nobody can rely on, because they are marked optional.
> 
> Take a look at: https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties <https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties>
> 
> Notice that they include "alg" and "use"... if both are optional, why include them in such an example?
> 
> FWIW I think making "alg" required is the best thing to do for new key types moving forward (it addresses future ambiguity / explicit over implicit makes me feel safer).
> 
> Extra language regarding thumbprint computation seems "worth it" for removing parameter kty type to alg type ambiguity.
> 
> Keep in mind we will have this same issue for the families of lattice, hash, and isogeny... So if we set a precedent of registering an alternative for 'crv' for lattices say. "pset", we will need to follow through with the others as well, either reusing that new parameter or creating a new one for each family.
> 
> @Mike Jones
> 
> On Mon, Mar 14, 2022 at 11:19 AM Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Requiring “alg” in a JWK for one class of algorithms and/or key type values would be non-parallel to other algorithms and/or key type values.  This matters not just for aesthetic reasons but also because it would make the JWK Thumbprint calculations [RFC 7638] have to special-case these algorithms and/or key type.____
> 
>     __ __
> 
>     Yes, you always need to know the “alg” when using a key – but in JOSE and COSE you already authoritatively get that from the JOSE or COSE header parameters.  I believe there’s insufficient reason to make things different for this new class of algorithms.____
> 
>     __ __
> 
>                                                             -- Mike____
> 
>     __ __
> 
>     *From:* COSE <[email-masked] <mailto:[email-masked]>> *On Behalf Of * Orie Steele
>     *To:* Russ Housley <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Ilari Liusvaara <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]____
> 
>     __ __
> 
>     OS____
>     __ __
>     On Sun, Mar 13, 2022 at 11:39 AM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:____
> 
> 
> 
>          > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[email-masked] <mailto:[email-masked]>> wrote:
>          >
>          >>> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[email-masked] <mailto:[email-masked]>> wrote:
>          >>>
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>____
> 
> 
>     ____
> 
>     __ __
> 
>     -- ____
> 
>     *ORIE STEELE*____
> 
>     Chief Technical Officer____
> 
>     www.transmute.industries <http://www.transmute.industries>____
> 
>     __ __
> 
>     <https://www.transmute.industries/>____
> 
> 
> 
> -- 
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>

---

From: David Waite <[email-masked]>
Date: Tue, 15 Mar 2022 00:48:52 -0600

> On Mar 14, 2022, at 2:19 PM, Orie Steele <[email-masked]> wrote:
<snip>
> So for a dilithium example:

Would you expect additional parameters (say “s1” and “s2”) for private keys?

Is X consistent within a parameter set, or is there variability (such as the algorithm to generate the matrix from a seed value, or the option to include a full matrix)

> Obviously JWK thumbprint will need to be aware of all required fields, and will need to drop all optional fields in order to be useful.

And if those rules aren’t generic and simple, it is possible we have rolled multiple key types into one “kty”. The “EC” key type allowed just “X” coordinates for other curves, but my interpretation is that “OKP” was still created because the public value for Edwards curves was defined with a different packed binary format.

I posit it is better to have experimental key types for experimental key formats, vs the potential for a complex set of key forms in future production deployments. That is not to say that I have an informed opinion on stability of any proposal.

> If we don't define something like "pset" and we don't make "alg" required for "kty:PQK"... the only optional will be to explode based on mismatched keys / signatures... unless I am missing somethin…

Parameter set seems appropriate, as long as it is the term of art for the category of key type, and (for a given parameter set name) is in a non-extensible format.

WRT the usage of “alg” - there can be multiple algorithms that leverage the same underlying key object, which means a subtype is a different level of restrictiveness/specificity than specifying an algorithm. A single instantiated key of a subtype can be used with multiple algorithms (“RS” and “PS” families), and a single algorithm can be used with multiple key subtypes - such as “ECDH-ES” and “EdDSA”.

This would make the subtype of a key and its algorithmic usage restrictions orthogonal.

> FWIW I think making "alg" required is the best thing to do for new key types moving forward (it addresses future ambiguity / explicit over implicit makes me feel safer).

The “alg” and “use” parameters are restrictions on key object usage, rather than specifying the key object cryptographic properties themselves. IMHO, one needs an underlying PKI or just blanket immutability which restricts a party from changing such parameters over time for them to have value.

Historically these have not been “self asserted”, but rather asserted by an authority in a PKI system who has made an integrity protected statement about the key (e.g. a public certificate). In this case they may not be self-imposed restrictions, but restrictions by the trust broker, such as “they can’t act as a sub-CA” or “check here to see if the authority marked this key as revoked”. 

Likewise, key usage restrictions are systems-specific. An example would be key operations (also specified in the JWK RFC, distinct from “use”). Verification relationships in decentralized identifier documents are arguably another example of operational restrictions, albeit in a graph rather than a simple broker hierarchy.

-DW

---

From: Mike Prorock <[email-masked]>
Date: Tue, 15 Mar 2022 08:20:00 -0400

Anders,
What are your thoughts on a kty for hash based, one for lattice, and then
later for isogeny or other families as required?  That seems in line with
the definition of kty from 4.1 of the jwk rfc "The 'kty' (key type)
parameter identifies the cryptographic algorithm family used with the key"

https://datatracker.ietf.org/doc/html/rfc7517#section-4.1

Mike Prorock
mesur.io

On Tue, Mar 15, 2022, 00:04 Anders Rundgren <[email-masked]>
wrote:

> Hi Orie,
>
> To me PQK represents overloading since the anticipated crypto systems seem
> to be more or less unrelated. Overloaded identifiers make the introduction
> of new algorithms more difficult and is at odds with pluggability.
>
> To avoid overloading kty:CRYD3 could be a possible choice.  For DH keys
> (if applicable), I would consider kty:CRYD3-DH which would give you basic
> algorithm separation.
>
> BouncyCastle which has been the leading crypto provider for Java (until
> Java17), have indeed defined a unique key type for the single PQC algorithm
> they currently support:
>
> It would be valuable knowing what the PKIX folks are planning here since
> they have basically the same problem.  Russ?
>
> Thanx,
> Anders
>
> > If that's the case, we will need to register a new "crv" like property
> for post quantum keys, let's call it "pset" for now, as we had originally
> > In particular we have learned that handling optional parameters is a
> source of security issues, especially related to "alg".
> >
> > If we can't make "alg" required for "kty:PQK" we will need to define a
> new "pset"  or similar, and it will have to have a mapping for every
> registered `alg`.
> >
> > Obviously JWK thumbprint will need to be aware of all required fields,
> and will need to drop all optional fields in order to be useful.
> >
> > If we don't define something like "pset" and we don't make "alg"
> required for "kty:PQK"... the only optional will be to explode based on
> mismatched keys / signatures... unless I am missing something... we have
> the same problem with P-256 keys today... when "alg" is not present, you
> can't tell if the key is for "signing" or "key agreement"... which means
> that any JWE / JWS can target that key, and the key representation won't
> catch what the key was intended for... unless "alg" and "use" are
> present... which nobody can rely on, because they are marked optional.
> >
> > Take a look at:
> <
> > On Mon, Mar 14, 2022 at 11:19 AM Mike Jones <[email-masked]
> <mailto:[email-masked]>> wrote:
> >
> algorithms and/or key type.____
> >
> >     __ __
> >
> >     Yes, you always need to know the “alg” when using a key – but in
> JOSE and COSE you already authoritatively get that from the JOSE or COSE
> header parameters.  I believe there’s insufficient reason to make things
> different for this new class of algorithms.____
> >
> >     __ __
> >
> >                                                             -- Mike____
> >
> >     __ __
> >
> >     *Cc:* Ilari Liusvaara <[email-masked] <mailto:
> [email-masked]>>; [email-masked] <mailto:[email-masked]>
> >     *Subject:* Re: [COSE] draft-prorock-cose-post-quantum-signatures
> [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]____
> >
> >     __ __
> >
> >     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
> >     On Sun, Mar 13, 2022 at 11:39 AM Russ Housley <[email-masked]
> <mailto:[email-masked]>> wrote:____
> >
> >
> >
> >          > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <
> [email-masked] <mailto:[email-masked]>> wrote:
> >          >
> [email-masked] <mailto:[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
> >
> >         https://www.ietf.org/mailman/listinfo/cose <
> https://www.ietf.org/mailman/listinfo/cose>____
> >
> >
> >     ____
> >
> >     __ __
> >
> >     -- ____
> >
> >     *ORIE STEELE*____
> >

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 15 Mar 2022 13:54:04 +0100

On 2022-03-15 13:20, Mike Prorock wrote:
> Anders,
> What are your thoughts on a kty for hash based, one for lattice, and then later for isogeny or other families as required?  That seems in line with the definition of kty from 4.1 of the jwk rfc "The 'kty' (key type) parameter identifies the cryptographic algorithm family used with the key"

Hi Mike, I must confess that my insights in the actual algorithms are fairly modest (big understatement); I see this exclusively from an architectural point of view.

To avoid talking in riddles, consider the initial part of current X.509 public key definitions:

SEQUENCE {
   SEQUENCE {
     OBJECT IDENTIFIER rsaEncryption (1.2.840.113549.1.1.1)

SEQUENCE {
   SEQUENCE {
     OBJECT IDENTIFIER ecPublicKey (1.2.840.10045.2.1)
     OBJECT IDENTIFIER NIST-P-256 (1.2.840.10045.3.1.7)

SEQUENCE {
   SEQUENCE {
     OBJECT IDENTIFIER Ed25519 (1.3.101.112)

X.509 public keys follow the top-level identifier concept I'm advocating.  I would be very surprised if the PKIX folks lump all known PQ key algorithms under a single identifier even if it would be technically feasible.  If we want COSE/JOSE keys to eventually become first class citizens (like X.509) in cryptographic subsystems, a rethink may be necessary.

Yes, taking on such a scheme will require a bunch of RFCs but they would all be very short.

"One key container to rule them all!"  I hope not :)

Cheers,
Anders

> 
> https://datatracker.ietf.org/doc/html/rfc7517#section-4.1 <https://datatracker.ietf.org/doc/html/rfc7517#section-4.1>
> 
> Mike Prorock
> mesur.io <http://mesur.io>
> 
> On Tue, Mar 15, 2022, 00:04 Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Orie,
> 
>     https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/pqc/jcajce/spec/SPHINCSPlusParameterSpec.java <https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/pqc/jcajce/spec/SPHINCSPlusParameterSpec.java>
> 
>      >  >  I believe there’s insufficient reason to make things different for this new class of algorithms.
>      >
>      > Take a look at: https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties <https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties> <https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties <https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties>>
>      >
>      > On Mon, Mar 14, 2022 at 11:19 AM Mike Jones <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     *From:* COSE <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> *On Behalf Of * Orie Steele
>      >     *To:* Russ Housley <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>      >     *Cc:* Ilari Liusvaara <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      >     On Sun, Mar 13, 2022 at 11:39 AM Russ Housley <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:____
>      >
>      >
>      >
>      >          > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >          >
>      >          > On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote:
>      >          >>
>      >          >>
>      >          >>> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >          >>>
>      >          >>> 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.
>      >          >
>      >          > 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.
>      >
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>      > https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose> <https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>>____
>      >
>      >
>      >     ____
>      >
>      >     __ __
>      >
>      >     -- ____
>      >
>      >     *ORIE STEELE*____
>      >
>      >     www.transmute.industries <http://www.transmute.industries <http://www.transmute.industries>>____
>      >
>      >     __ __
>      >
>      >     <https://www.transmute.industries/ <https://www.transmute.industries/>>____
>      >
>      >
>      >
>      > --
>      > *ORIE STEELE*
>      > Chief Technical Officer
>      > www.transmute.industries
>      >
>      > <https://www.transmute.industries <https://www.transmute.industries>>
>      >
>      > https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
> 
>     https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Mar 2022 10:11:43 -0400

Anders:

The LAMPS WG will be talking about certificates and CMS support for PQC algorithms next week during IETF 113.

Also, BouncyCastle has supported HSS/LMS signatures, which are quantum-safe, for at least two years.  In addition, the specifications are done for using HSS/LMS with COSE and CMS.  The state that needs to be tracked for HSS/LMS does not need to be tracked for other quantum-safe signature algorithms.  So, other quantum-safe signature algoritms should be more straightforward.

Russ

> On Mar 15, 2022, at 12:03 AM, Anders Rundgren <[email-masked]> wrote:
> 
> Hi Orie,
>

---

From: Orie Steele <[email-masked]>
Date: Tue, 15 Mar 2022 09:32:02 -0500

The goal in registering new JWK and JWS compatible terms for the family of
post quantum crypto systems is to register only what is needed to identify
the key and the signature.

We are not trying to add any additional parameters, in the abstract, we
want to convey "key type", "public key" and "private key", while following
the conventions that came before us.

So far, we think the OKP style Ed25519 keys are the model to follow, here
is a reminder:

      "kty": "OKP",
      "crv": "Ed25519",
      "x": "3ygWe2mas7ZvquJ2E_aNh3wJEcLPsHp_8r0UXoyhBwQ",
      "d": "EKCZgwCYoasDC61z5aWR6LqvPbpxWPKFY1PexeW5WSw"

https://www.rfc-editor.org/rfc/rfc8037.html#section-2 (reminder that crv is
required... so sadly it seems we will need a new key type).

this would mean something like this:

kty: PQK
pset: CRYD3 // handled like "crv" was for kty: OKP, with a new value for
every new key type from lattice, hash or isogeny based systems
alg: CRYD3 // optional
x: pub
d: priv

another alternative would be:

kty: CRYD3 // with a new value for every new key type from lattice, hash or
isogeny based systems
alg: CRYD3 // optional
x: pub
d: priv

OS

On Tue, Mar 15, 2022 at 1:48 AM David Waite <[email-masked]>
wrote:

> Is X consistent within a parameter set, or is there variability (such as
> the algorithm to generate the matrix from a seed value, or the option to
> include a full matrix)
>
> And if those rules aren’t generic and simple, it is possible we have
> rolled multiple key types into one “kty”. The “EC” key type allowed just
> “X” coordinates for other curves, but my interpretation is that “OKP” was
> still created because the public value for Edwards curves was defined with
> a different packed binary format.
>
> I posit it is better to have experimental key types for experimental key
> formats, vs the potential for a complex set of key forms in future
> production deployments. That is not to say that I have an informed opinion
> on stability of any proposal.
>
> Parameter set seems appropriate, as long as it is the term of art for the
> category of key type, and (for a given parameter set name) is in a
> non-extensible format.
>
> WRT the usage of “alg” - there can be multiple algorithms that leverage
> the same underlying key object, which means a subtype is a different level
> of restrictiveness/specificity than specifying an algorithm. A single
> instantiated key of a subtype can be used with multiple algorithms (“RS”
> and “PS” families), and a single algorithm can be used with multiple key
> subtypes - such as “ECDH-ES” and “EdDSA”.
>
> The “alg” and “use” parameters are restrictions on key object usage,
> rather than specifying the key object cryptographic properties themselves.
> IMHO, one needs an underlying PKI or just blanket immutability which
> restricts a party from changing such parameters over time for them to have
> value.
>
> Historically these have not been “self asserted”, but rather asserted by
> an authority in a PKI system who has made an integrity protected statement
> about the key (e.g. a public certificate). In this case they may not be
> self-imposed restrictions, but restrictions by the trust broker, such as
> “they can’t act as a sub-CA” or “check here to see if the authority marked
> this key as revoked”.
>
> Likewise, key usage restrictions are systems-specific. An example would be
> key operations (also specified in the JWK RFC, distinct from “use”).
> Verification relationships in decentralized identifier documents are
> arguably another example of operational restrictions, albeit in a graph
> rather than a simple broker hierarchy.
>
> -DW
>

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

---

From: Mike Prorock <[email-masked]>
Date: Tue, 15 Mar 2022 11:09:13 -0400

That is very helpful.  I have similar thoughts, and setting a 'kty' by
family of algorithm, and in the post quantum case also requiring 'alg' to
specify the actual algorithm and parameter set within that family, is very
much in line with what you outlined.

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

On Tue, Mar 15, 2022 at 8:54 AM Anders Rundgren <
[email-masked]> wrote:

> > What are your thoughts on a kty for hash based, one for lattice, and
> then later for isogeny or other families as required?  That seems in line
> with the definition of kty from 4.1 of the jwk rfc "The 'kty' (key type)
> Hi Mike, I must confess that my insights in the actual algorithms are
> fairly modest (big understatement); I see this exclusively from an
> architectural point of view.
>
> X.509 public keys follow the top-level identifier concept I'm advocating.
> I would be very surprised if the PKIX folks lump all known PQ key
> algorithms under a single identifier even if it would be technically
> feasible.  If we want COSE/JOSE keys to eventually become first class
> citizens (like X.509) in cryptographic subsystems, a rethink may be
> necessary.
>
> > https://datatracker.ietf.org/doc/html/rfc7517#section-4.1 <
> https://datatracker.ietf.org/doc/html/rfc7517#section-4.1>
> >
> > Mike Prorock
> > On Tue, Mar 15, 2022, 00:04 Anders Rundgren <
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >     Hi Orie,
> >
> >     To me PQK represents overloading since the anticipated crypto
> systems seem to be more or less unrelated. Overloaded identifiers make the
> introduction of new algorithms more difficult and is at odds with
> pluggability.
> >
> >     To avoid overloading kty:CRYD3 could be a possible choice.  For DH
> keys (if applicable), I would consider kty:CRYD3-DH which would give you
> basic algorithm separation.
> >
> >     BouncyCastle which has been the leading crypto provider for Java
> (until Java17), have indeed defined a unique key type for the single PQC
> algorithm they currently support:
> >
> >     It would be valuable knowing what the PKIX folks are planning here
> since they have basically the same problem.  Russ?
> >
> >     Thanx,
> >     Anders
> >
> >      >  >  I believe there’s insufficient reason to make things
> different for this new class of algorithms.
> >      >
> >      > If that's the case, we will need to register a new "crv" like
> property for post quantum keys, let's call it "pset" for now, as we had
> originally intended to register this property, and it's still present in
> the current draft.
> >      >
> >      > - kty:PQK, pset:
> xmss.public_key.SHA2_10_256 -> alg: xmss.SHA2_10_256 ?
> >      >
> >      > In particular we have learned that handling optional parameters
> is a source of security issues, especially related to "alg".
> >      >
> >      > If we can't make "alg" required for "kty:PQK" we will need to
> define a new "pset"  or similar, and it will have to have a mapping for
> every registered `alg`.
> >      >
> >      > Obviously JWK thumbprint will need to be aware of all required
> fields, and will need to drop all optional fields in order to be useful.
> >      >
> https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-set-properties>
> <
> >      > FWIW I think making "alg" required is the best thing to do for
> new key types moving forward (it addresses future ambiguity / explicit over
> >      > Extra language regarding thumbprint computation seems "worth
> it" for removing parameter kty type to alg type ambiguity.
> >      >
> >      > Keep in mind we will have this same issue for the families of
> lattice, hash, and isogeny... So if we set a precedent of registering an
> alternative for 'crv' for lattices say. "pset", we will need to follow
> through with the others as well, either reusing that new parameter or
> creating a new one for each family.
> >      >
> >      > @Mike Jones
> >      >
> >      > On Mon, Mar 14, 2022 at 11:19 AM Mike Jones <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>> wrote:
> >      >
> >      >     Requiring “alg” in a JWK for one class of algorithms and/or
> key type values would be non-parallel to other algorithms and/or key type
> values.  This matters not just for aesthetic reasons but also because it
> would make the JWK Thumbprint calculations [RFC 7638] have to special-case
> these algorithms and/or key type.____
> >      >
> >      >     __ __
> >      >
> >      >     Yes, you always need to know the “alg” when using a key – but
> in JOSE and COSE you already authoritatively get that from the JOSE or COSE
> Mike____
> >      >     *From:* COSE <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>> *On Behalf Of * Orie Steele
> >      >     *To:* Russ Housley <[email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>>; [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>
> >      >     *Subject:* Re: [COSE]
> draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda
> Items for IETF 113 in Vienna]____
> >      >
> >      >     __ __
> >      >
> >      >     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
> >      >     On Sun, Mar 13, 2022 at 11:39 AM Russ Housley <
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>> wrote:____
> >      >
> >      >
> >      >
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>> wrote:
> >      >          >
> [email-masked] <mailto:[email-masked]> <mailto:
> [email-masked] <mailto:[email-masked]>>> wrote:
> >      >          >>>
> >      >          > - Add new alg values
> KEM+{A{128,192,256}KW,HKDF-{256,512}}, mirroring
> >      >          >  the ECDH-ES ones.
> >      >         If you are talking about ECC Point Compression, I agree
> that COSE should ignore it.  For a very long time, the patent kept many
> https://www.ietf.org/mailman/listinfo/cose> <
> https://www.ietf.org/mailman/listinfo/cose>>____
> >      >
> >      >
> >      >     ____
> >      >
> >      >     __ __
> >      >
> >      >     -- ____
> >      >
> >      >     *ORIE STEELE*____
> >      >
> https://www.ietf.org/mailman/listinfo/cose>
> >
> https://www.ietf.org/mailman/listinfo/cose>
> >
>
>

---

From: Mike Prorock <[email-masked]>
Date: Tue, 15 Mar 2022 11:16:34 -0400

Orie,
I think other alternative would be:
kty: PQL        // post quantum - lattice based
alg: CRYDI3  // crystals dilithium, parameter set 3
x: public
d: private

and
kty: PQH       // post quantum - hash based
alg: SP-SHAKE256-[n]-[w]-[h]-[d]-[k]-[t]  // SPHINCS+, shake256, parameter
set as noted
x: public
d: private

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

On Tue, Mar 15, 2022 at 10:32 AM Orie Steele <[email-masked]>
wrote:

> https://www.rfc-editor.org/rfc/rfc8037.html#section-2 (reminder that crv
> is required... so sadly it seems we will need a new key type).
>
> kty: CRYD3 // with a new value for every new key type from lattice, hash
> or isogeny based systems
> alg: CRYD3 // optional
> x: pub
> d: priv
>
> OS
>
>
>> Likewise, key usage restrictions are systems-specific. An example would
>> be key operations (also specified in the JWK RFC, distinct from “use”).

---

From: Mike Prorock <[email-masked]>
Date: Tue, 15 Mar 2022 11:37:49 -0400

note, with sphincs+ we may wind up with a simplified set of alg definitions
based on known and tested configs, eg something like the following (based
on the reference implementation here: https://github.com/sphincs/sphincsplus
):

SPHINCS+-SHAKE256-128s
SPHINCS+-SHAKE256-128f
SPHINCS+-SHAKE256-192s
SPHINCS+-SHAKE256-192f
SPHINCS+-SHAKE256-256s
SPHINCS+-SHAKE256-256f

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

On Tue, Mar 15, 2022 at 11:16 AM Mike Prorock <[email-masked]> wrote:

>> The goal in registering new JWK and JWS compatible terms for the family
>> of post quantum crypto systems is to register only what is needed to
>> identify the key and the signature.
>>
>>> Parameter set seems appropriate, as long as it is the term of art for
>>> the category of key type, and (for a given parameter set name) is in a
>>> non-extensible format.
>>>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 15 Mar 2022 20:57:50 +0200

> alg: CRYDI3  // crystals dilithium, parameter set 3

"Lattice-based post quantum" is not a valid key type. It is not a single
key shape (unlike every kty currently defined). And it does not look to
be helpful even working around algorithm dispatch issues in
implementations, as, e.g., Dilithium and Kyber are both lattice post-
quantum algorithms, but wildly different.

If that kty is supposed to be octet-keypair for given alg, that would
be defensible (mixing algorithms for the same key is unsound), but the
name for that kty would not be PQL.

There is also actual security problem with this: Serious cryptographers
are very unconfortable with unhybridized post-quantum algorithms (with
exception of hash signatures) at the moment. Gaining confidence on such
things will take years at the very least.

> alg: SP-SHAKE256-[n]-[w]-[h]-[d]-[k]-[t]  // SPHINCS+, shake256, parameter

One really should stay away from those parameters and use parameter
sets made by experts, as at least some of those parameters will
absolutely destroy security if set the wrong way.

And "Hash-based post quantum" is also not a valid key type.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 15 Mar 2022 21:15:51 +0200

> much in line with what you outlined.

X.509 does not actually work that way. X.509 has no equivalent to the
COSE/JOSE alg parameter in keys. For some key types, you are not going
to be able to use them in more than one way. E.g., you can't perform
anything but Ed25519 with Ed25519 key. But for many of the key types,
(I think this includes even X25519 keys, but it definitely includes
things like RSA and EC keys) there are many operations one can perform
(yes, it is unsound).

And turns out that one can't emulate the model X.509 uses in COSE/JOSE
by allowing second-chance dispatch on OKP crv (which is something an
implementation could just decide to do), due to the way COSE and
especially JOSE handle ECDSA.

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Tue, 15 Mar 2022 15:27:35 -0400

> On Mar 15, 2022, at 2:57 PM, Ilari Liusvaara <[email-masked]> wrote:
> 

Agree.  I am hoping that the key structure is invisible at the COSE level.  It is just an octet string at this level, but the crypto code knows about any internal structure, but not the COSE library.

> And "Hash-based post quantum" is also not a valid key type.

I think the intent is to ony register the alg strings that represent a set of parameters that are intended to be used together, not allow arbitrary values.

Russ

---

From: Mike Prorock <[email-masked]>
Date: Tue, 15 Mar 2022 16:01:59 -0400

>
> I think the intent is to ony register the alg strings that represent a set
> of parameters that are intended to be used together, not allow arbitrary
> values.
>
>
+1 Russ

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Mar 2022 16:02:23 -0400

> alg: SP-SHAKE256-[n]-[w]-[h]-[d]-[k]-[t]  // SPHINCS+, shake256, parameter

Just remember that while such a string might be super annoying in JSON,
in CBOR, it's gonna be an IANA assigned small integer.

(Not commenting for/against such a thing, but just to remind people)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide