PQC migration is a massive, multi-year undertaking involving the update of trust anchors (Root and Intermediate CAs), coordination with third-party CAs, and the upgrading of cryptographic libraries, protocols, and HSM/TEE hardware. This effort has to begin now for several deployments. Furthermore, the arrival of a CRQC may not be publicly disclosed; much like a zero-day vulnerability, an adversary could privately exploit quantum capabilities to compromise traditional certificates without alerting the wider ecosystem.
I support adoption of this draft. Cheers, -Tiru On Thu, 8 Jan 2026 at 01:45, Simo Sorce <[email protected]> wrote: > If this is the reason I would say adoption is premature. > > The JOSE and COSE standards generally use signatures for authentication > purposes in online transactions, and breaking classical signature > algorithms is not going to happen so suddenly that you need a dual > composite signature protection, you will most probably have plenty of > time to simply change what key/signature you use before an online > attack becomes relevant, even after a Quantum Computer exists that can > break classical algorithms. > > The negatives for composite signature that bind both algorithms is that > you'll carry the cost (both computational and byte wise) of two schemes > in such a way you can't immediately drop the broken algorithm from the > implementation even though you have to assign zero security to it (this > has maintenance and security costs associated). > > This kind of signature make sense only for long lived documents and to > a lesser extent software signing, which are typically not domains where > JOSE/COSE play a role today. > > It would be wise to let others that deal in those areas move first and > then adopt what they do if good, or learn from their mistakes and come > up with something better. > > Being first movers is not always the right thing to do. > > Best, > Simo. > > On Wed, 2026-01-07 at 19:32 +0000, Michael Jones wrote: > > I support adoption of this draft. As John Bradley said during the > discussion of the draft in Montreal, if we don't do this, somebody else > will. Better that we do it. > > > > There are enough long-lived signature use cases for both COSE and JOSE > that it makes sense to have this in our toolbox. We don't know whether > Elliptic Curve algorithms or ML-DSA algorithms will be broken first. If > composite signatures are used, the signatures will still be valid no matter > which is broken first (until they are both broken). There are use cases > where that extra buffer of protection may be worth having. > > > > -- Mike > > > > From: Giuseppe De Marco <[email protected]> > > Sent: Wednesday, January 7, 2026 9:00 AM > > To: Karen O'Donoghue <[email protected]> > > Cc: [email protected]; [email protected]; > [email protected] > > Subject: [jose] Re: Call for adoption: > draft-prabel-jose-pq-composite-sigs-05 (Ends 2026-01-19) > > > > I support adoption, > > > > regards > > > > Il giorno mar 6 gen 2026 alle ore 06:13 Karen O'Donoghue via Datatracker > <[email protected]<mailto:[email protected]>> ha scritto: > > This message starts a jose WG Call for Adoption of: > > draft-prabel-jose-pq-composite-sigs-05 > > > > This Working Group Call for Adoption ends on 2026-01-19 > > > > Abstract: > > This document describes JSON Object Signing and Encryption (JOSE) and > > CBOR Object Signing and Encryption (COSE) serializations for PQ/T > > hybrid composite signatures. The composite algorithms described > > combine ML-DSA as the post-quantum component and either ECDSA or > > EdDSA as the traditional component. > > > > Please reply to this message and indicate whether or not you support > adoption > > of this Internet-Draft by the jose WG. Please provide some explanation > for > > your preference. Also, please reply to all recipients of this message and > > include this message in your response. > > > > Authors, and WG participants in general, are reminded of the Intellectual > > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > > Appropriate IPR disclosures required for full conformance with the > provisions > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > > Sanctions available for application to violators of IETF IPR Policy can > be > > found at [3]. > > > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > > [2] https://datatracker.ietf.org/doc/bcp79/ > > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-prabel-jose-pq-composite-sigs/ > > > > There is also an HTML version available at: > > > https://www.ietf.org/archive/id/draft-prabel-jose-pq-composite-sigs-05.html > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-prabel-jose-pq-composite-sigs-05 > > > > _______________________________________________ > > 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] > > -- > Simo Sorce > Distinguished Engineer > RHEL Crypto Team > Red Hat, Inc > > _______________________________________________ > 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]
