Add priv_exp

[OR13]

This PR adds support for priv_exp, as discussed at IETF 122

https://datatracker.ietf.org/doc/slides-122-cose-ml-dsa-for-jose-and-cose/

[ilaril]

How would this work with hybrid signatures (or native hybrid KEMs)? Those can end up in cases like one of the components being seed-only and the other being expanded-only.

E.g., id-MLDSA65-Ed25519. There is no standard expanded private key format for Ed25519 (I have seen at least two formats that could qualify as "expanded" Ed25519 private keys), while there is for ML-DSA.

[selfissued]

Simo Sorce's suggestion on the list resonates with me:

If priv is the seed, why not call it just 'seed' ?

I suggest adding a "seed" ML-DSA-specific JWK parameter and using "priv" for the expanded form.

Likewise, I suggest a parallel change for COSE where "seed" is given the -3 label instead of "priv_exp" and "priv" with label -2 is used for the expanded private key.

(Note: I am writing this as an individual - not a COSE chair.)

[OR13]

@ilaril

How would this work with hybrid signatures (or native hybrid KEMs)? Those can end up in cases like one of the components being seed-only and the other being expanded-only.

E.g., id-MLDSA65-Ed25519. There is no standard expanded private key format for Ed25519 (I have seen at least two formats that could qualify as "expanded" Ed25519 private keys), while there is for ML-DSA.

At least for X-Wing, I would imagine:

{
   "kid": "T4xl70S7MT...yo0Gu6o",
   "kty": "AKP",
   "alg": "X-Wing",
   "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ",
   "seed/priv": "AAAAAAAAAAA...AAAAAAAAAAAAA", // (not the concatenated expansions)
}

Per https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-06#appendix-C (note that seed and sk are the same).

For the other cases, like chempat - https://datatracker.ietf.org/doc/html/draft-josefsson-chempat-03#section-10

You would have to store sk_T, sk_PQ... maybe:

{
   "kid": "T4xl70S7MT...yo0Gu6o",
   "kty": "AKP",
   "alg": "Chempat-X25519-mceliece8192128",
   "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ",
   "seed/priv": "...concat(sk_T, sk_PQ, pk_T, pk_PQ)...", // here sk_PQ is expanded I believe, but I could be wrong
}

The point would be that in order to use an AKP key, you would need to understand how to process all the mandatory key parameters for a given algorithm.

Some algorithms might be as simple as "priv", others might look like RSA does today...

I think we have learned that opaque byte string parameters are best, and so as much as possible, we should aim for the minimum number of opaque byte strings needed to support interop.

If you want "unbounded algorithmic agility (feature or bug, depending on your view of history)", where the same key is used with a potentially unbounded number of algorithms, you can easily do that with AKP, you just have to say which specific algorithm you are trying to support, and the fingerprint will commit to that algorithm.

[ilaril]

How would this work with hybrid signatures (or native hybrid KEMs)? Those can end up in cases like one of the components being seed-only and the other being expanded-only.

At least for X-Wing, I would imagine:

Yes, X-Wing is easy as it always uses "super-seed" (which is internally used to generate seeds for both components).

For the other cases, like chempat - https://datatracker.ietf.org/doc/html/draft-josefsson-chempat-03#section-10

You would have to store sk_T, sk_PQ... maybe:

There are 9 possible combinations of seeds and expanded keys there.

E.g., how does one store sk_T being seed-only, while sk_PQ is expanded-only?

The point would be that in order to use an AKP key, you would need to understand how to process all the mandatory key parameters for a given algorithm.

Some algorithms might be as simple as "priv", others might look like RSA does today...

I think we have learned that opaque byte string parameters are best, and so as much as possible, we should aim for the minimum number of opaque byte strings needed to support interop.

Because processing of the private key octet string can be algorithm-dependent, the minimum number of private parameters is 1.
That is, one can always do with just "priv", "priv_exp" is never needed.

E.g., with primitive algorithms, one can prepend a flag byte (01 => Seed, 02 => Expanded, 03 => Both). With composite algorithms, one can, e.g., do it like draft-ietf-lamps-pq-composite-sigs-04.

Ideally, the COSE/JOSE code would just stuff the raw private/public key to some library that then transparently handles the internals.

[OR13]

The current proposal in this draft is closed to this:

E.g., with primitive algorithms, one can prepend a flag byte (01 => Seed, 02 => Expanded, 03 => Both).

Its just we use CBOR / JSON to handle the prepending, and the both case, is handled by the presence of 2 map keys.

@ilaril would you mind giving a thumbs up / thumbs down to any of the suggested changes on this PR?

[ilaril]

I think this would be tolerable if the section "Algorithm Key Pair Type" made it clear what to do with algorithms that do not have defined seed expansion, and that the matching requirement is independent of algorithm.

For example, COSE-HPKE and JOSE-HPKE algorithms do not have seed expansion (even if using X-Wing as KEM!). Also, any hybrid signature algorithms are unlikely to have any defined seed expansion.

Maybe something like (with fields renamed):

If the associated "alg" value does not define seed expansion, then "seed" parameter MUST NOT be present, and the "priv" parameter is used for the private key, if present.

If both "seed" and "priv" parameters are both present, then the seed in "seed" parameter MUST expand to the key in "priv" parameter following the seed expansion procedure for the associated "alg" value.

[OR13]

@ilaril I agree, I will make it clear that the parameters for a given AKP come from the algorithm.

[selfissued]

I agree that this is now the right way to make this change, after the recent suggestions have been incorporated.

I do have questions (as an individual) whether this change is needed at all. But we should discuss that on the list.

[OR13]

@ilaril I ended up applying both suggestions, based on @selfissued 's comment.

I'm going to push a draft version to the list, to enable better review.