I support seed only unless someone has a very strong use case to use private keys generated in 2024 in a 2024 legacy HSM in COSE and JOSE.
John (as an individual) Sent from Commodore VIC-20 ________________________________ From: Neil Madden <[email protected]> Sent: Wednesday, April 2, 2025 8:44:41 AM To: tirumal reddy <[email protected]> Cc: Michael Jones <[email protected]>; Simo Sorce <[email protected]>; Orie Steele <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [jose] Re: [COSE] Re: Do COSE and JOSE need both "priv" and "seed"? 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]<mailto:[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]<mailto:[email protected]>> Sent: Tuesday, April 1, 2025 12:09 PM To: Michael Jones <[email protected]<mailto:[email protected]>>; Orie Steele <[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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]<mailto:[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<http://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]><mailto:[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<http://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<http://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<http://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]><mailto:[email protected]<mailto:[email protected]>> > To unsubscribe send an email to > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > _______________________________________________ > jose mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]> -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ 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]
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
