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

[Orie Steele <[e-mail]>]

>  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 <[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]> *On Behalf Of * Orie Steele
> *Sent:* Monday, March 14, 2022 8:20 AM
> *To:* Russ Housley <[e-mail]>
> *Cc:* Ilari Liusvaara <[e-mail]>om>; [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]>
> wrote:
>
>
>
> > On Mar 12, 2022, at 4:59 AM, Ilari Liusvaara <[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]> 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]
> https://www.ietf.org/mailman/listinfo/cose
>
>
>
>
> --
>
> *ORIE STEELE*
>
> Chief Technical Officer
>
> www.transmute.industries
>
>
>
> <https://www.transmute.industries/>
>


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

<https://www.transmute.industries>