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]
