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

[Anders Rundgren <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>> 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:
>     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>
> 
>     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> <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]> <mailto:[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]> <mailto:[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]> <mailto:[e-mail] <mailto:[e-mail]>>>
>      >     *Cc:* Ilari Liusvaara <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>; [e-mail] <mailto:[e-mail]> <mailto:[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]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:____
>      >
>      >
>      >
>      >          > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[e-mail] <mailto:[e-mail]> <mailto:[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]> <mailto:[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]> <mailto:[e-mail] <mailto:[e-mail]>>
>      > 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*____
>      >
>      >     Chief Technical Officer____
>      >
>      >     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>>
>      >
>      > _______________________________________________
>      > COSE mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
> 
>     _______________________________________________
>     COSE mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/cose <https://www.ietf.org/mailman/listinfo/cose>
>