Composite signatures are already through the LAMPS working group and have been submitted to IESG for publication. The final OIDs have been assigned by IANA so they are ready for production.
At the IETF hackathons we have had at least 7 different vendors implement composite signatures in many different programming languages. So I think the discussion on how to implement them has already been completed. Adopting this draft doesn't mean we are the first movers. See: https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/13/ I support the adoption of this draft. Cheers, John Gray ________________________________ From: Simo Sorce <[email protected]> Sent: Wednesday, January 7, 2026 3:13 PM To: [email protected] <[email protected]> Subject: [EXTERNAL] [jose] Re: Call for adoption: draft-prabel-jose-pq-composite-sigs-05 (Ends 2026-01-19) 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 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwP6dxa2d$ > [2] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwD4GshPY$ > [3] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwEfZS2eK$ > > The IETF datatracker status page for this Internet-Draft is: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-prabel-jose-pq-composite-sigs/__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwGl34b7z$ > > There is also an HTML version available at: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-prabel-jose-pq-composite-sigs-05.html__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwNOLmKRw$ > > A diff from the previous version is available at: > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-prabel-jose-pq-composite-sigs-05__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwJZZr8Qx$ > > _______________________________________________ > 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] Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
