Hi all, Bit late to the party, but I was asked to comment from the perspective of the draft for PQC in Web Crypto [1].
FWIW, I think this is the right outcome, and it will simplify the use of JWK in Web Crypto (and in general) by only specifying a single key format. The current draft also only specifies a seed format for importing/exporting private keys, and this will make it consistent once JWK is added. (The alternative might've been to only allow the JWK format with a seed, as I'm contemplating to do for PKCS8.) Thanks! Best, Daniel [1]: https://twiss.github.io/webcrypto-modern-algos/pqc.html On 21-05-2025 at 07:10, Michael Jones wrote: > > Ivo and I discussed the results from the query “Do COSE and JOSE need > both "priv" and "seed"?” sent to the COSE and JOSE mailing lists and > have made the following consensus call together, so as to unblock > progress on completing the draft. While there wasn’t an easy answer, > we believe that our decision appropriately balances considerations of > simplicity, practicality, and interoperability. > > Authors of draft-ietf-cose-dilithium, > > Please apply these revisions and publish the result as draft 07. > > * Restore the meaning of “priv” to always be the seed value. > * Delete the “seed” AKP parameter. > * State that this specification intentionally does not define a > means of utilizing the expanded private key representation defined > by NIST so as to increase interoperability by having a single > ML-DSA private key representation for COSE and JOSE. > > I’ll note that much of this can be accomplished by restoring text from > draft 05. > > Following publication of 07 with these changes, the chairs will > request publication of the specification. > > The working group is aware of the LAMPS WG decision to specify both > seed and expanded representations, but that reason was mostly related > by the existence of hardware HSMs that only support the expanded > format. We do not anticipate that the same problem will exist for > COSE or JOSE. > > Proponents of having multiple private key representations, > > If any of you feel strongly enough about wanting to also have the > expanded key representation be possible for COSE and JOSE, we would > request that you create a separate draft doing so. Such a draft would > be expected to define an optional “expanded” parameter to the AKP key > type. It would include the rule that if both “priv” and “expanded” > are present, they must represent the same private key, just as “seed” > and “priv” must correspond in draft 06. The chairs are not taking a > position in this consensus call on whether such a draft should be > created or not. > > Writing as COSE chairs, > > -- Ivo and Mike > _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
