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

[Anders Rundgren <[e-mail]>]

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.
> 
> 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 <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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> *On Behalf Of * Orie Steele
>     *Sent:* Monday, March 14, 2022 8:20 AM
>     *To:* Russ Housley <[e-mail] <mailto:[e-mail]>>
>     *Cc:* Ilari Liusvaara <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>     *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 <[e-mail] <mailto:[e-mail]>> wrote:____
> 
> 
> 
>          > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[e-mail] <mailto:[e-mail]>> wrote:
>          >
>          > On Fri, Mar 11, 2022 at 03:34:08PM -0500, Russ Housley wrote:
>          >>
>          >>
>          >>> On Mar 11, 2022, at 11:11 AM, Ilari Liusvaara <[e-mail] <mailto:[e-mail]>> 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
>         [e-mail] <mailto:[e-mail]>
>         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
> 
> <https://www.transmute.industries>
> 
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose