I realize that we are in the dirty situation now, but that means we need to clean up. As the saying goes, the future is bigger than the past -- there will be new implementations and existing implementations will get upgraded. We should guide both of those toward a common solution.
I'm confused what point you're trying to make with this existing software implementation. There's no JOSE / COSE specification for JWKs of the type we're talking about here. Anything they do with a spec here will be new code, so they might as well do the right thing to start with. (To be blunt, I have basically zero sympathy for software implementations. If you can't upgrade, you can't fix security bugs, and you're not serious about security. If you can upgrade and refuse to, you're not interested in interop. And again: We're talking about net new code here; there is no existing JOSE / COSE code to upgrade!) With regard to common interfaces, I can agree that having interoperability across security modules is a positive thing. From that perspective the proliferation of LAMPS, COSE, and JOSE is already a problem, because you need the sender and receiver to support the same format. (As a side note, including TLS in your list doesn't make any sense, because TLS doesn't deal in private keys.) We shouldn't compound the problem by having each one support multiple options. To be clear, I'm not completely opposed to defining an expanded key form somewhere; I don't think we should completely screw over those unlucky early implementers. But we also shouldn't let their error and intransigence keep us from a more interoperable future. So if we do define something, it should be "in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard'." Or whatever the IETF equivalent of that is. --Richard On Wed, May 7, 2025 at 3:09 PM Russ Housley <[email protected]> wrote: > 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]> 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]
