> > Are there real-world use cases for private key JWKs?
Yes, plenty of existing software allows BYOK in JWK formats. Quoting from the article For all currently supported values, this can easily be done by checking the > presence of a value "d". (Not sure if this is a coincidence, but for both > RSA and ECDSA, we tend to call the private key "d".) I don't foresee issues stemming from deviating this "pattern" if you would, but it's worth flagging. I think the AKP definition of having seed/priv/pub is fine, but I'd say that the individual uses of this key type could decide whether to exclusively use "seed" (e.g. ML-DSA), or "priv" (e.g. SLH-DSA). Does that make sense? I'm not convinced. S pozdravem, *Filip Skokan* On Wed, 2 Apr 2025 at 08:44, Neil Madden <[email protected]> wrote: > I don’t really understand the usecase where someone wants to store their > private key in a HSM but also wants to transport it as a plaintext JWK. Can > someone enlighten me? > > Given things like > https://blog.hboeck.de/archives/909-Mixing-up-Public-and-Private-Keys-in-OpenID-Connect-deployments.html > do > we actually even need to define JWK private key formats for new key types? > Are there real-world use cases for private key JWKs? > > — Neil > > On 2 Apr 2025, at 07:12, tirumal reddy <[email protected]> wrote: > > > Storing seeds is optimal for reducing the storage overhead on HSMs but > incurs computation overhead to generate public/private keys, see > https://www.ietf.org/archive/id/draft-reddy-pquip-pqc-hsm-00.html#section-2.1.1 > > -Tiru > > On Wed, 2 Apr 2025 at 06:07, Michael Jones <[email protected]> > wrote: > >> My assumption is that HSMs will enable the use of the seed as the private >> key. Yes, Lamps encountered an instance or a few that shipped before NIST >> allowed the use of the seed as the private key. But HSMs now are cleared >> by NIST to do so. Before this spec is an RFC, HSMs shipping should be >> using the new guidance. >> >> The other assumption is that we'll have fewer interop problems long term >> if we support exactly one private key format. >> >> -- Mike >> >> -----Original Message----- >> From: Simo Sorce <[email protected]> >> Sent: Tuesday, April 1, 2025 12:09 PM >> To: Michael Jones <[email protected]>; Orie Steele >> <[email protected]>; [email protected] >> Cc: [email protected] >> Subject: Re: [jose] Do COSE and JOSE need both "priv" and "seed"? >> >> Hi Michael, >> Is your assumption that if a HW token is used there is no need to use >> JWKs to transport keys ? >> >> On Tue, 2025-04-01 at 18:45 +0000, Michael Jones wrote: >> > Thanks for publishing this draft, Orie. It makes it clear what the >> treatment for ML-DSA would look like if we choose to support both the seed >> and expanded private key representations. >> > >> > I do question whether COSE and JOSE need both representations. What is >> the use case for needing to support the expanded private key representation >> for COSE and JOSE? >> > >> > I know why LAMPS did it - for HSMs signing X.509 certificates. But >> that use case doesn't apply to COSE or JOSE. >> > >> > Should we back this out and support only the seed representation and >> have that be the “priv” value, as it was in previous drafts? >> > >> > Discussion requested. >> > >> > Thanks, >> > -- >> > Mike >> > >> > From: Orie Steele <[email protected]> >> > Sent: Tuesday, April 1, 2025 11:13 AM >> > To: [email protected] >> > Subject: [COSE] Re: I-D Action: draft-ietf-cose-dilithium-06.txt >> > >> > This version includes the changes to support both "seeds" and "expanded >> private keys". >> > >> > I have also updated the code that generates the examples to give a >> sense of impact to implementations, have a look here: >> > >> > https://githu/ >> > b.com%2Fcose-wg%2Fdraft-ietf-cose-dilithium%2Fpull%2F18&data=05%7C02%7 >> > C%7C8df187c1e6484f0df0a808dd7150b7ca%7C84df9e7fe9f640afb435aaaaaaaaaaa >> > a%7C1%7C0%7C638791313675027457%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk >> > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >> > Q%3D%3D%7C0%7C%7C%7C&sdata=J2HkY4A4FURQ7wnur%2BVAFxrTpnsdgf0PXA%2BgjZG >> > HaEg%3D&reserved=0 >> > >> > Thanks to Ilari, Simo and Mike Jones for comments on this version. >> > >> > I believe there are still some concerns regarding the proposed text, >> but having -06 to argue over is better than looking at the editors draft in >> github. >> > >> > Regards, >> > >> > OS >> > >> > On Tue, Apr 1, 2025 at 1:10 PM <[email protected]<mailto: >> [email protected]>> wrote: >> > Internet-Draft draft-ietf-cose-dilithium-06.txt is now available. It >> > is a work item of the CBOR Object Signing and Encryption (COSE) WG of >> the IETF. >> > >> > Title: ML-DSA for JOSE and COSE >> > Authors: Michael Prorock >> > Orie Steele >> > Rafael Misoczki >> > Michael Osborne >> > Christine Cloostermans >> > Name: draft-ietf-cose-dilithium-06.txt >> > Pages: 19 >> > Dates: 2025-04-01 >> > >> > Abstract: >> > >> > This document describes JSON Object Signing and Encryption (JOSE) and >> > CBOR Object Signing and Encryption (COSE) serializations for Module- >> > Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum >> > Cryptography (PQC) digital signature scheme defined in FIPS 204. >> > >> > The IETF datatracker status page for this Internet-Draft is: >> > https://datat/ >> > racker.ietf.org%2Fdoc%2Fdraft-ietf-cose-dilithium%2F&data=05%7C02%7C%7 >> > C8df187c1e6484f0df0a808dd7150b7ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7 >> > C1%7C0%7C638791313675081563%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >> > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 >> > D%3D%7C0%7C%7C%7C&sdata=T9wT%2F25UZOWq8oSPMBpeN5OSt4kmQRzcycgKUf4qV2s% >> > 3D&reserved=0 >> > >> > There is also an HTML version available at: >> > https://www.i/ >> > etf.org%2Farchive%2Fid%2Fdraft-ietf-cose-dilithium-06.html&data=05%7C0 >> > 2%7C%7C8df187c1e6484f0df0a808dd7150b7ca%7C84df9e7fe9f640afb435aaaaaaaa >> > aaaa%7C1%7C0%7C638791313675128729%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h >> > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj >> > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=4%2BHVnCUFhs9%2BpQHr55WvTUasnO4CUh58qXgC >> > YudVD0g%3D&reserved=0 >> > >> > A diff from the previous version is available at: >> > https://autho/ >> > r-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-cose-dilithium-06&data=0 >> > 5%7C02%7C%7C8df187c1e6484f0df0a808dd7150b7ca%7C84df9e7fe9f640afb435aaa >> > aaaaaaaaa%7C1%7C0%7C638791313675177678%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >> > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI >> > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mpE8N2Uuvyui3p%2FQfo1D7Y0HPqCtQOL%2 >> > Fy433ybYAWO4%3D&reserved=0 >> > >> > Internet-Drafts are also available by rsync at: >> > rsync.ietf.org::internet-drafts >> > >> > >> > _______________________________________________ >> > COSE mailing list -- [email protected]<mailto:[email protected]> >> > To unsubscribe send an email to >> > [email protected]<mailto:[email protected]> >> > _______________________________________________ >> > 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] >> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
