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]> 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] To unsubscribe send an email to [email protected]
