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]> 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]> > wrote: > > I’ll ask more people to weigh in on this thread so we can resolve the > issue. Should we: > > 1. support only the seed private key representation for COSE and JOSE? > 2. 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]> > *Sent:* Wednesday, April 2, 2025 6:09 PM > *To:* Ilari Liusvaara <[email protected]> > *Cc:* [email protected]; [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]> > 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] > To unsubscribe send an email to [email protected] > > _______________________________________________ > 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]
