Inline.
On Thu, 2025-03-27 at 11:40 -0500, Orie Steele wrote:
> Hi Simo, Filip, Daniel, COSE & JOSE,
>
> Inline:
>
> On Thu, Mar 27, 2025 at 8:22 AM Simo Sorce <[email protected]>
> wrote:
>
> > On Thu, 2025-03-27 at 10:46 +0100, Filip Skokan wrote:
> > > Dear JOSE WG, COSE WG, and Daniel,
> > >
> > > (draft-ietf-cose-sphincs-plus
> > > <https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/> and
> > > draft-ietf-jose-pqc-kem
> > > <https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/> authors,
> > please
> > > note there's feedback towards your drafts in this message as well).
> > >
> > > As promised in the IETF 122 JOSE WG meeting where I've presented the
> > topic.
> > > Having digested the discussion that occurred, here's the promised follow
> > up
> > > feedback to the upcoming extension to the Web Cryptography API with my
> > > recommendations to its author/editor, a heads up for the COSE and JOSE
> > > Working Groups, as well as feedback towards some of the WG drafts.
> > >
> > > The Web Cryptography API <https://w3c.github.io/webcrypto/> (javascript
> > > cryptography interface available in most javascript runtimes) is about to
> > > have its second extension proposed to the Web Platform Community
> > > Group. This specification defines a number of modern cryptographic
> > > algorithms for the Web Cryptography API, currently that's ML-KEM, ML-DSA,
> > > SLH-DSA, AES-OCB, ChaCha20-Poly1305, SHA-3, cSHAKE, KMAC, and Argon2.
> > >
> > > The APIs intersection with the JOSE WG is the JSON Web Key format used
> > for
> > > key import/export operations. This brings the COSE WG draft into the
> > > discussion because for some of the algorithms the new JWK Key Type and
> > > algorithms are being defined in COSE WG drafts.
> > >
> > > Here are my suggestions for Daniel, the extension's author and the API's
> > > current editor, regarding the current algorithms in the draft's scope.
> > >
> > > *JWK Key Type - AKP - Algorithm Key Pair*
> > > This new key type is being defined in draft-ietf-cose-dilithium
> > > <https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/>. This key
> > > type requires that "alg" be always present and uses the "kty" value
> > "AKP".
> >
> > Can someone explain what is the point of neutering the menaning of kty,
> > and requiring two attribute (kty + alg) to determine the key type?
> >
>
> You currently need 2 attributes to determine if a key type might support a
> given algorithm:
>
> kty: EC, crv: P-256 --> alg: ES256 (JOSE)
>
> kty: EC, crv: P-256 --> alg: ES256, ES384, ES512, ESP256 (COSE)
This has always been a bad thing of the EC keys, and should not be seen
as a good idea to expand on ...
> The point of AKP is to ensure that a key is generated with the intention to
> support a specific algorithm.
And that may work in some contexts but not others.
In some context you have a "generic" ML-DSA key and no restrictions on
which algorithm to use (ML-DSA vs HashML-DSA), now how do you generate
a JWK out of it ?
> If HashML-DSA is specified for JOSE / COSE in the future it would be fine
> to create a HashML-DSA key:
>
> {
> "kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o",
> "kty": "AKP",
> "alg": "HASH-ML-DSA-44",
> "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ",
> "priv": "129kadu...DZgbTP07e7gEWzw4MFRr54"
> }
This is not helpful on systems that use the same key for both
algorithms, which is a perfectly valid thing to do.
> > What is the point?
> > A kty of ML-DSA-XX would work just the same and make integration in
> > existing software much easier.
> >
>
> Thanks for this feedback.
>
> Is your proposal to register a new kty for each ML-DSA parameter set?
>
> For example:
>
> {
> "kty": "ML-DSA-44",
> "alg": "ML-DSA-44",
> ...
> }
> ...
> {
> "kty": "ML-DSA-65",
> "alg": "ML-DSA-65",
> ...
> }
> {
> "kty": "ML-DSA-65",
> "alg": "HASH-ML-DSA-65",
> ...
> }
> {
> "kty": "ML-DSA-65",
> "alg": "EXTERNAL-MU-ML-DSA-65",
> ...
> }
> ...
Only if "alg" is optional, ie you *can* restrict a key to a specific
algorithms but you should not be required to.
>
> > Moreover the use of "alg" sounds misleading as the same ML-DSA-XX keys
> > can be used already with at least 2 algorithms: ML-DSA and HashML-DSA,
> > and potentially soon with a "new one" based on external-mu
> > precomputation ...
> >
>
> Its less misleading in the context of the JWK and COSE RFCs which state:
>
> ```
> The "alg" (algorithm) parameter identifies the algorithm intended for use
> with the key.
> ```
> https://datatracker.ietf.org/doc/html/rfc7517#section-4.4
>
> ```
> The JWS Signature value is not valid if the "alg" value does not represent
> a supported algorithm or if there is not a key for use with that algorithm
> associated with the party that digitally signed or MACed the content.
> ```
> https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.1
>
> Keep in mind that in COSE, alg is optional in both headers and keys,
> whereas in JOSE alg is mandatory in headers, and optional in keys.
>
> ```
> This parameter is used to restrict the algorithm that is used with the key.
> If this parameter is present in the key structure, the application MUST
> verify that this algorithm matches the algorithm for which the key is being
> used.
> If the algorithms do not match, then this key object MUST NOT be used to
> perform the cryptographic operation.
All of the above is know and also intentionally optional.
> *Note that the same key can be in a different key structure with a
> different or no algorithm specified; however, this is considered to be a
> poor security practice.*
In some contexts it may be, but you can't make a general rule out of
it, yet by forcing a single valued "alg" parameter you are making the
standard un-neccessarily overly restrictive. The outcome of overly
restrictive standards is that implementations then tend to relax and
become incompatible with one another at the edges.
> ```
> https://datatracker.ietf.org/doc/html/rfc9052#section-7.1-3.4
> Given that 9052 comes after 7517, it would seem that using the same key
> type (with alg remaining optional) for "ML-DSA-65", "HASH-ML-DSA-65" and
> "EXTERNAL-MU-ML-DSA-65" would be encouraging a poor security practice (same
> key *different algorithms*).
A recommendation is a fine thing, but you made a construction that
dictates thing, that is quite different.
>
> In the context of JOSE and COSE, one could infer that "in a different key
> structure" could mean JWK, in which case, I could have a COSE Sign1 that is
> verifying with a JWK.
> If the JWK does not have a mandatory algorithm present for ML-DSA, then
> COSE signatures would have the same security issue as JWS example above,
> but cross protocol:
> A COSE Sign1 ("ML-DSA-65", "HASH-ML-DSA-65" and "EXTERNAL-MU-ML-DSA-65")
> might verify with a JWK that had *no algorithm.*
>
> Tackling the design position head on, I consider it a feature of AKP that
> it cannot easily be used to create keys that work for both "ML-DSA-65" and
> "HASH-ML-DSA-65".
> Putting on my attacker hat, I would copy the AKP key, update its algorithm,
> regenerate its fingerprint if it had one, and then exploit the weaker
> algorithm.
>
> This is the reasoning behind the current design at least from my
> perspective, although the draft has passed WGLC and is currently in AD
> Evaluation.
The reasoning defeats itself as you described.
Nothing prevents a user to use the same key with two algorithms, you
just make it awkward and hidden.
>
>
> > > All keys must include a "pub" public key parameter. Private keys in
> > > addition also include "priv", or "priv_exp", or both where applicable
> > (see
> > > archive)
> > > <https://mailarchive.ietf.org/arch/msg/cose/-vIaTIvZoSh21_2vqPakAvzzwSw/
> > > .
> > >
> >
> > If priv is the seed, why not call it just 'seed' ?
> >
>
> :) Thanks for this feedback, I will admit that I considered trying to move
> AKP to SPHINCS-PLUS just to avoid this issue while introducing AKP.
> ... I still prefer not to do that, despite the frustration regarding seeds
> and external mu.
>
> "priv_exp" is not in
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-05
>
> It's proposed in the branch:
> https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/16 (this won't be
> merged if there are objections, can I count this as an objection to
> merging?)
>
Absolutely not, in some cases the expanded key is all that it is
available and need to be possible to be carried.
>
> > A seed is not technically a private key, you do not have a full private
> > key until you expand it.
> >
>
> This is a fair point.
>
> I take it your proposal might look like:
>
> {
> "kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o",
> "kty": "AKP",
> "alg": "ML-DSA-44",
> "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ",
> "seed": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
> "priv": "129kadu...DZgbTP07e7gEWzw4MFRr54"
> }
>
> And for contrast with SPHINCS-PLUS:
>
> {
> "kid": "T4xl7...o0Gu6o",
> "kty": "AKP",
> "alg": "SLH-DSA-SHA2-128s",
> "pub": "unH5...djbDQ",
> "priv": "129ka...FRr54"
> }
>
> This could be seen as still in keeping with what I believe LAMPs has plans
> to do, although the draft is not yet updated:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-07#appendix-C.1
>
> I'd like to hear from others if they prefer "seed" + "priv" over "priv" and
> "priv_exp"... I proposed "priv" as "seed" only to keep with the current -07
> framing above.
>
TBH I do not care *that* much for names, but it brings confusion when a
name is used for very different things depending on context of very
similar objects.
> ... these same considerations apply to ML-KEM and X-WING btw...
> https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-06#name-test-vectors-todo-replace-w
> (note
> seed and sk are the same)...
>
> Except that for X-Wing, there is no expanded private key, so we would end
> up with:
>
> {
> "kty": "AKP",
> "alg": "ML-DSA-44",
> "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ",
> "seed": "AAAA....AAAA",
> "priv": "129kadu...DZgbTP07e7gEWzw4MFRr54" // actually an expanded
> private key, but need the seed to validate it
> }
>
> {
> "kty": "AKP",
> "alg": "X-WING",
> "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ",
> "priv": "AAAAAAAAA....AAAAA", // sk, actually a seed, but expanded to
> both an x25519 and an ml-kem private key internally.
> }
>
> I will admit that I sorta like the proposal to switch to "seed" + "priv",
> especially in the context of this thread:
>
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/gaHWR-Fs3yQ
>
> I would note that DJB used the terms "seed" + "expanded", which if we were
> to do that in JWK, we would end with 3 private information classes for JWKs
> that use kty: AKP ( seed(ml-dsa), expanded(ml-dsa), priv(slh-dsa, x-wing,
> ...) ).
I do favor seed+expanded, or may be priv_seed + priv_expanded to be
extra clear that does alues need to be kept secret.
>
> Note that I asked the pqc-forum, for ML-DSA when "priv_expanded" is present
> SHOULD / MUST "seed/priv" be present?
SHOULD, you can't have MUST.
>
> This is part of why I chose "priv" and "priv_exp", so that multiple
> algorithms could use the "priv" parameter, and "priv" always represents the
> minimal information necessary to represent a private key for a given
> algorithm.
>
> Also, no matter which words we use, we will be nudging towards thinking
> that the seed is or is not the critical private information for the scheme.
> ... from that perspective I think I prefer the word "priv" for seed (in
> external interfaces), given that you will always need it to validate the
> expanded private key(s)
>
>
>
> > > *ML-DSA*
> > >
> > > - uses AKP
> > > - "alg" values are being defined in draft-ietf-cose-dilithium
> > > <https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/>
> > > - "priv" is the seed
> > > - "priv_exp" is the expanded private key
> > > - when both "priv" and "priv_exp" are present during import then
> > "priv"
> > > must expand to "priv_exp"
> > > - @Daniel Huigens <[email protected]> the above is fully
> > > supporting the API's JWK import/export operations.
> > >
> > > *ML-KEM*
> > >
> > > - feedback to draft-ietf-jose-pqc-kem
> > > <https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/> authors:
> > The
> > > draft currently does mention key representations. My assumption is
> > that the
> > > AKP key type is to be used and to support that the draft needs to
> > > explicitly mention doing so and explain how the AKP Key Parameters
> > are to
> > > be used.
> > > - @Daniel Huigens <[email protected]> assuming ML-KEM JWK keys
> > > will be represented the same as ML-DSA this is fully supporting the
> > API's
> > > JWK import/export operations.
> > >
> > > *SLH-DSA*
> > >
> > > - worked on in draft-ietf-cose-sphincs-plus
> > > <https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/>
> > > - SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s, and SLH-DSA-SHA2-128f alg
> > > values are defined in the draft
> > > - @Daniel Huigens <[email protected]> for parameter sets not
> > > planned to be registered by the COSE WG draft the API extension
> > > specification may request registration similar to how RSA-OAEP-384 was
> > > registered in the original Web Cryptography API spec, that's with
> > Algorithm
> > > Usage Location(s): "alg" and JOSE Implementation Requirements:
> > Optional
> > > - feedback to draft-ietf-cose-sphincs-plus
> > > <https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/>
> > authors:
> > > The draft currently mentions key representations to use the AKP type
> > but
> > > does not explicitly mention what "priv" and "priv_exp" parameters
> > > represent, while I think this is very much clear it would be prudent
> > for
> > > your draft to expand on the topic similar to how cose-dilithium does
> > or how
> > > cose-sphincs-plus hopefully will in its future revisions.
> >
>
> : ) See above.
>
> I would expect SLH-DSA draft to be updated to say something to the effect
> of:
>
> Note that SLH-DSA does not have a "seed" and similar to CMS, this draft
> does not specify a pre-hash mode, see
> https://www.ietf.org/archive/id/draft-ietf-lamps-cms-sphincs-plus-19.html#section-6-2
> .
>
> I would expect SLH-DSA to use the "priv" parameter (as registered by
> draft-ietf-cose-dilithium) to represent private information for a given key.
>
>
> > >
> > > *AES-OCB*
> > >
> > > - @Daniel Huigens <[email protected]> the API extension
> > > specification may request registration similar to how other AES modes
> > were
> > > registered in the original Web Cryptography API spec, that's with
> > Algorithm
> > > Usage Location(s): "JWK" and JOSE Implementation Requirements:
> > Prohibited
> > > - Can anyone familiar with the original registrations chime in on why
> > > the JWK-only Usage Location registrations were done as Prohibited?
> > > - Uses "oct" key type
> >
> > To be honest it woud be nice to define typed ktys for different
> > algorithm types, you definitely never want to use the same keys for
> > both AES and ChaCha20-Poly1305 encryption anyway, but branding every
> > secret as a generic "octet" makes it impossible to determine for what
> > purpose a symmetirc key was created. This is especially problematic if
> > software wants to back this with an HSM via something like PKCS#11 APIS
> > where the key type is required and you can't mix key types with
> > mechanisms (ie you can't use a CKK_AES key with anything but a
> > CKM_AES_XXX mechanism, so you need to know at the time of creation what
> > the key is going to be used for).
> >
> > Note that using "alg" is not what I am after, because "alg" for
> > something like AES would be exceedingly restrictive in most cases, as
> > there is no generic "AES" alg, but only specific mode+purpose
> > algorithms.
> > for example an AES key used for key wrapping can be used with different
> > algorithms for wrapping safely. (ie A128KW and PBES2-H256+A128KW and
> > ECDH-ES+A128KW)
> >
> > And the key could be generate via derivation operation that does not
> > know exactly which AES operation will the key be used for...
> >
> > > *ChaCha20-Poly1305*
> > >
> > > - @Daniel Huigens <[email protected]> same as AES-OCB, note
> > that
> > > the value "C20P" was previously used in an I-D
> > > <https://datatracker.ietf.org/doc/draft-amringer-jose-chacha/> and
> > some
> > > libraries implement it, you may consider registering that value
> > > - Uses "oct" key type
> > >
> > > *SHA-3 and cSHAKE*
> > >
> > > - These Web Cryptography Algorithms interact with other algorithms
> > that
> > > specify a hash as part of either its CryptoKey algorithm or the
> > operation's
> > > algorithm (HMAC, RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, RSA-OAEP
> > > - In the past JWK registrations were done for HS1, RS1, and PS1
> > > - @Daniel Huigens <[email protected]> much like HS1, RS1, and
> > PS1
> > > I believe a registering every combination of the new digest
> > algorithms with
> > > existing hash-based algorithms is impractical (and would not find any
> > use
> > > outside of the API itself similar to its past HS1, RS1 and PS1
> > > registrations). Therefore I recommend that either the API support JWK
> > > import/export of such keys but
> > > - during JWK import the "alg" member must not be present
> > > - during JWK export the "alg" member is omitted;
> > > - - or -
> > > - the API only supports non-JWK export/import key formats when the
> > > new digest algorithms are present on the key algorithm.
> > >
> > > *KMAC*
> > >
> > > - @Daniel Huigens <[email protected]> given the updated
> > guidance
> > > on registrations in the JSON Web Signature and Encryption Algorithms
> > IANA
> > > registry we would not be able to register the algorithms for KMAC128
> > and
> > > KMAC256 unless they also implied an empty customization (S input
> > parameter)
> > > member and a fixed length (L input parameter) members. As such I
> > recommend
> > > that either the API support JWK import/export of such keys using the
> > "oct"
> > > key type but
> > > - during JWK import the "alg" member must not be present
> > > - during JWK export the "alg" member is omitted;
> > > - - or -
> > > - the API only supports non-JWK export/import key formats for the
> > > KMAC algorithm
> > >
> > > *Argon2*
> > >
> > > - has no interaction with JWK :check:
> > >
> > >
> > > S pozdravem,
> > > *Filip Skokan*
> > > _______________________________________________
> > > jose mailing list -- [email protected]
> > > To unsubscribe send an email to [email protected]
> >
> > --
> > Simo Sorce
> > Distinguished Engineer
> > RHEL Crypto Team
> > Red Hat, Inc
> >
> > _______________________________________________
> > COSE mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> >
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
