One real-world use case for private keys in JWK format is publishing private
keys so example cryptographic computations can be reproduced.
https://www.rfc-editor.org/rfc/rfc7520.html contains many such private keys in
JWK format. https://www.rfc-editor.org/rfc/rfc7515.html has one too.
-- Mike
From: Neil Madden <[email protected]>
Sent: Tuesday, April 1, 2025 11:45 PM
To: tirumal reddy <[email protected]>
Cc: Michael Jones <[email protected]>; Simo Sorce <[email protected]>;
Orie Steele <[email protected]>; [email protected]; [email protected]
Subject: Re: [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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
