I'm an author of the draft, so for clarity, just want to say that I'm obviously in support of adoption!
I agree with Mike's points. Based on discussions with several contributors, I would also like to mention the following scenarii where this draft could be relevant: - Systems like OpenID Federation and the FIDO Metadata Service rely on long-lived trust anchors to verify JWS signatures, requiring the root of trust to remain secure for many years. - In many IoT and embedded systems, keys are often burned into hardware or integrated into firmware, making rotation difficult. - For compliance reasons with some regulatory requirements or recommendations. - Even for short-lived signatures, many deployments cannot upgrade their entire JOSE stack overnight, and thus a hybrid approach could prove to be useful during this transition. I hope this gives a few more points to the examples given by Mike. Best, Lucas -----Original Message----- From: Mike Ounsworth <[email protected]> Sent: 08 January 2026 03:06 To: John Gray <[email protected]> Cc: Simo Sorce <[email protected]>; [email protected] Subject: [jose] Re: [EXTERNAL] Re: Call for adoption: draft-prabel-jose-pq-composite-sigs-05 (Ends 2026-01-19) Simo, you said: > The JOSE and COSE standards generally use signatures for > authentication purposes in online transactions I am going to say that this is a case of common-case-blindness; ie considering only the most common usecase and ignoring the other valid usecases of a protocol. Off the top of my head, here are a list of things I know about that use either JWS or CWS as the underlying signature envelope: - SCITT -- a public ledger for software supply chain integrity. - C509 a port of X.509 using CBOR instead of DER - COSE-based firmware signing - The SPICE WG that creates all sorts of verifiable credentials - RATS WG that has both JWS and CWS formats for devices to produce attestations or manifests of their current configuration. and that's just uses of JOSE and COSE that I know about within other IETF WGs, let alone proprietary and non-IETF protocols and ecosystems. JOSE and COSE are fundamental cryptographic building blocks; to say that we can enumerate all the uses of JOSE / COSE, and that none of them require long-term signatures seems ... wrong. I support adoption of this draft :) On Wed, 7 Jan 2026 at 15:52, John Gray <[email protected]> wrote: > > 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!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46 > > m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwP6dxa2d$ > > [2] > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/_ > > _;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46 > > m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwD4GshPY$ > > [3] > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701 > > /__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S > > 46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvwEfZS2eK$ > > > > The IETF datatracker status page for this Internet-Draft is: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-p > > rabel-jose-pq-composite-sigs/__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrhwnUBu8 > > i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29RzVxnvw > > Gl34b7z$ > > > > There is also an HTML version available at: > > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-pr > > abel-jose-pq-composite-sigs-05.html__;!!FJ-Y8qCqXTj2!azJEhzK3gTbkKrh > > wnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXmqD29R > > zVxnvwNOLmKRw$ > > > > A diff from the previous version is available at: > > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url > > 2=draft-prabel-jose-pq-composite-sigs-05__;!!FJ-Y8qCqXTj2!azJEhzK3gT > > bkKrhwnUBu8i0RluhqTNAnuL9do9n5j8rnV9E8S46m0R1UM4bkJM1OUd6BOeeA-CKYXm > > qD29RzVxnvwJZZr8Qx$ > > > > _______________________________________________ > > 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] _______________________________________________ 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]
