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!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] _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
