Adding COSE for visibility. I don't oppose adoption.
However, I have some fear that while this is straightforward to specify, and could be relevant to adjacent WGs, it may not actually ever be used. It would be nice to know if there are planned deployments of this in JOSE + COSE. Regards, OS On Thu, Jan 8, 2026 at 9:16 AM Simo Sorce <[email protected]> wrote: > Thanks, > with this broader justification I am not opposed. > > On Wed, 2026-01-07 at 20:05 -0600, Mike Ounsworth wrote: > > 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] > > -- > 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]
