Richard: While getting the private key specified before any implementations were done would have avoided the situation that you describe, that was not possible. Too many people were too far down the implementation path.
At least one significant software implementation will not support the format that you suggest. That implementation does not have configuration knobs for the private key output format, and it only produces the "both" format. In my opinion, a common crypto library under LAMPS, TLS, JOSE, COSE, and so on is the most desirable outcome. Russ > On May 7, 2025, at 1:43 PM, Richard Barnes <[email protected]> wrote: > > The LAMPS solution may have achieved some of the WG's objectives, but > interoperability is not one of them. The interoperability goal is to be able > to export a key from one system and import it into another, and the LAMPS > approach is hostile to it, it enables the continued proliferation of > incompatible devices. It's precisely the "Postel was Wrong" problem [1]. > > JOSE and COSE should adopt a single format for ML-KEM and ML-DSA private > keys, and that format should be the seed format. We should skate to where > the puck is headed. > > If there is demand for the expanded key format, that can be a different "kty" > and should be explicitly marked as deprecated. > > --Richard > > [1] https://rfcs.online/rfcs/rfc9413.html > > > On Tue, May 6, 2025 at 3:24 PM Russ Housley <[email protected] > <mailto:[email protected]>> wrote: >> In my opinion, it would be best is all crypto libraries use the same format >> for public and private keys. LAMPS explored all possible combinations of >> seed and expanded forms of the private key. The same answer across all >> protocols that use ML-DSA and ML-KEM will greatly improve interoperability. >> >> Russ >> >> >>> On May 6, 2025, at 3:16 PM, Michael Jones <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I’ll ask more people to weigh in on this thread so we can resolve the >>> issue. Should we: >>> support only the seed private key representation for COSE and JOSE? >>> support both the expanded and seed private key representations for COSE and >>> JOSE? >>> >>> Please give the reasons for your choice. >>> >>> -- Mike (writing as a COSE >>> chair) >>> >>> From: Orie <[email protected] <mailto:[email protected]>> >>> Sent: Wednesday, April 2, 2025 6:09 PM >>> To: Ilari Liusvaara <[email protected] >>> <mailto:[email protected]>> >>> Cc: [email protected] <mailto:[email protected]>; [email protected] >>> <mailto:[email protected]> >>> Subject: [COSE] Re: [jose] Re: Re: Re: Re: Do COSE and JOSE need both >>> "priv" and "seed"? >>> >>> Inline: >>> >>> On Wed, Apr 2, 2025 at 9:10 AM Ilari Liusvaara <[email protected] >>> <mailto:[email protected]>> wrote: >>> On Wed, Apr 02, 2025 at 10:45:25AM +0200, Filip Skokan wrote: >>> > >>> > 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. >>> >>> I think that exclusively using "seed" does not make sense, and is not >>> currently allowed. >>> >>> Not correct. >>> >>> Specifically, it is legal to use "seed" and "pub", and to expand to "priv" >>> internally, see the example generated for the draft, and also this text: >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-06#name-ml-dsa-private-keys >>> >>> ``` >>> When both "seed" and "priv" are present, the "seed" parameter MUST expand >>> to the "priv" parameter. >>> When "priv" is present, "seed" SHOULD be present to enable validation of >>> the private key expansion process. >>> Validation and expansion of private keys might be skipped in constrained >>> environments. >>> ``` >>> >>> >>> What is currently allowed is algorithm exclusively uisng "priv" (e.g., >>> COSE-HPKE/JOSE-HPKE) or using both "seed" and "priv" (e.g., ML-DSA). >>> >>> Not true, see above. >>> >>> >>> If an algorithm has no meaningful expanded format (e.g., HPKE with >>> X-Wing, Ed25519 or Ed448), it uses "priv" exclusively. >>> >>> Correct, we added your text, and it applies generically to all AKP: >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-06#section-3-5 >>> >>> >>> >>> >>> >>> >>> >>> -Ilari >>> >>> _______________________________________________ >>> jose mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]>_______________________________________________ >>> 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]>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
