>All signatures standardized by NIST and IETF in the last 20 years > (EdDSA, LMS, XMSS, ML-DSA, SLH-DSA) are SUF-CMA (for very good reasons).
I could be wrong, but in my read of FIPS-205, they seem to state that SLH-DSA is EUF-CMA. Also, I think Falcon (future FN-DSA) is EUF-CMA and a number of the NIST signature on-ramp algorithms are EUF-CMA. So NIST still seems to be standardizing EUF-CMA algorithms. In regard to composites, they provide a hedge in case there is a cryptographic attack that breaks one of the underlying algorithms. If one of them is broken you still have time to move to another algorithm. If you have a choice to use EUF-CMS composites then that may be a better choice for you, but if you have constraints like FIPS that may limit your choice. As one of the composite authors, we tried to limit the number of combinations, but every time we did that more organizations kept coming forward saying they needed this combination or that combination (most of them being some flavor of RSA or ECDSA which are unfortunately NOT SUF-CMA). >EUF-CMA _can_ be used but it puts a lot of security requirements on the >application, which is always a bad idea if > it can be avoided. Application developers often do not understand complicated > cryptographic properties. If you > can easily make mistakes someone likely will. I agree, application developers (I am one of them), need to be very careful when using any algorithm. Protocols like CMS, or TLS or even signed X509Certifcates help mitigate a lot of the risk, but hopefully we have good standards for those things to guide developers and mitigate most issues (though implementation errors happen as well). Mostly it is when home-baked crypto schemes are devised where things get perilous. Anyway, that being said I support the adoption of draft-prabel-jose-pq-composite-sigs-04. Cheers, John Gray ________________________________ From: John Mattsson <[email protected]> Sent: Friday, October 3, 2025 6:41 AM To: Wang Guilin <[email protected]>; John Mattsson <[email protected]>; Orie <[email protected]> Cc: Lucas Prabel <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; cose <[email protected]>; Wang Guilin <[email protected]> Subject: [EXTERNAL] [jose] Re: Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 Hi Gullin, Here is a recent public example that resulted in a loss of 620 million USD https: //arxiv. org/abs/1403. 6676 I have also seen non-public examples where systems use H(message+signature) as a unique identifier instead of H(message). I Hi Gullin, Here is a recent public example that resulted in a loss of 620 million USD https://arxiv.org/abs/1403.6676<https://urldefense.com/v3/__https://arxiv.org/abs/1403.6676__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfGUt0R0c$> I have also seen non-public examples where systems use H(message+signature) as a unique identifier instead of H(message). I bet that if you put a bunch of random developers, which in general are not experts in crypto, many will incorrectly design systems that use H(message+signature) as a unique identifier. I would strongly agree with NIST that: “Cryptographic standards and guidelines should be chosen to minimize the demands on users and implementers as well as the adverse consequences of human mistakes and equipment failures.” https://nvlpubs.nist.gov/nistpubs/ir/2016/nist.ir.7977.pdf<https://urldefense.com/v3/__https://nvlpubs.nist.gov/nistpubs/ir/2016/nist.ir.7977.pdf__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfKksuTaM$> >Given that the composites only provide EUF-CMA against quantum attackers, >...." This is true but we may need to describe in more detail I think the best thing in 2025 is to not discuss anything else than quantum attackers (which included classic attacks). >3 ECDSA algorithms with P curves (ESP256, ESP384, ESP512 ) are currently >recommended as Yes in the COSE algorithm list, >https://www.iana.org/assignments/cose/cose.xhtml<https://urldefense.com/v3/__https://www.iana.org/assignments/cose/cose.xhtml__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfOlEqkWB$>. > So, it seems that COSE does not require that only SUF-CMA can be used for >COSE. Otherwise, all these EUF-CMA secure algorithms should be deprecated. COSE and JOSE clearly has EUF-CMA algorithms and that is fine. I am just sceptical to registering new ones. ESP256, ESP384, ESP512 will likely be deprecated in the future as they are quantum-vulnerable. NIST will not just deprecate them but _disallow_ them in 2035. >You mentioned "EUF-CMA can lead to significant vulnerabilities such as replay >of messages, double billing, double money transactions, double receipts, >double contracts, and log/transaction history poisoning." Could you please >elaborate for one particular example, say, double billing, why an EUF-CMA >secure signature cannot be used? I tried to imagine but did not see why only >SUF-CMA ones are needed in such a case. EUF-CMA _can_ be used but it puts a lot of security requirements on the application, which is always a bad idea if it can be avoided. Application developers often do not understand complicated cryptographic properties. If you can easily make mistakes someone likely will. ---------------------------- Here is a made up example: Alice signs a payment instruction: Message m: "Pay 100 USD from Alice to Merchant Bob" Signature σ1 Alice sends (m, σ1) to Merchant Bob. Merchant Bob is malicious. Because the signature scheme is only EUF-CMA, not SUF-CMA, the merchant can generate an alternative (or many alternatives) valid signature σ2 on the same message m. Merchant Bob now submits two billing requests to the payment processor: (m, σ1) (m, σ2) The backend sees two different signature blobs, and because the developer assumed that signatures are SUF-CMA, which is a very natural assumption, the backend with they assume they are distinct authorizations, and debits Alice twice. Cheers, John Preuss Mattsson (As an individual) From: Wang Guilin <[email protected]> Date: Friday, 3 October 2025 at 12:02 To: John Mattsson <[email protected]>, Orie <[email protected]> Cc: Lucas Prabel <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, cose <[email protected]>, Wang Guilin <[email protected]> Subject: RE: [jose] Re: Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 Hi, John and all, Have checked with several cryptographers for the necessity of SUF-CAM signatures. Up to now, no example has convinced me that there is any real application where only SUF-CAM signatures, but not EUF-CMA ones, must be used. However, it is indeed true that due to the stronger security of SUF-CAM signatures, the use and management for them in applications shall be simpler. Here are two specific comments on composite signatures. 1. "Given that the composites only provide EUF-CMA against quantum attackers, ...." This is true but we may need to describe in more detail. In fact, for T/PQ composite signatures, if both T and PQ signatures are SUF-CMA again traditional attackers, their composite will be SUF-CMA again traditional attackers, according to draft-ietf-lamps-pq-composite-sigs-09. For quantum attackers, any T signatures (either EUF-CMA or SUF-CMA against traditional attackers) will be broken, so the 1. 3 ECDSA algorithms with P curves (ESP256, ESP384, ESP512 ) are currently recommended as Yes in the COSE algorithm list, https://www.iana.org/assignments/cose/cose.xhtml<https://urldefense.com/v3/__https://www.iana.org/assignments/cose/cose.xhtml__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfOlEqkWB$>. So, it seems that COSE does not require that only SUF-CMA can be used for COSE. Otherwise, all these EUF-CMA secure algorithms should be deprecated. 1. You mentioned "EUF-CMA can lead to significant vulnerabilities such as replay of messages, double billing, double money transactions, double receipts, double contracts, and log/transaction history poisoning." Could you please elaborate for one particular example, say, double billing, why an EUF-CMA secure signature cannot be used? I tried to imagine but did not see why only SUF-CMA ones are needed in such a case. Cheers, Guilin From: John Mattsson <[email protected]> Sent: Thursday, 2 October 2025 10:40 pm To: Orie <[email protected]>; John Mattsson <[email protected]> Cc: Lucas Prabel <[email protected]>; [email protected]; [email protected]; cose <[email protected]> Subject: [COSE] Re: [jose] Re: Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 Hi, For long-lived devices that do not want to use lattice-based signatures, COSE already has registered the hash-based HSS-LMS https://www.rfc-editor.org/rfc/rfc8708.html<https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8708.html__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfFb1unQM$> https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf<https://urldefense.com/v3/__https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfFi0KYip$> And SLH-DSA has been WG adopted and algorithms like SLH-DSA-SHAKE-128s https://datatracker.ietf.org/doc/html/draft-ietf-cose-sphincs-plus-05<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-cose-sphincs-plus-05__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfHVCipul$> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf<https://urldefense.com/v3/__https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfOOG13VL$> are soon expected to be registered for COSE and JOSE. NIST is also actively working on SLH-DSA with smaller parameter sets https://csrc.nist.gov/csrc/media/presentations/2025/sphincs-smaller-parameter-sets/sphincs-dang_2.2.pdf<https://urldefense.com/v3/__https://csrc.nist.gov/csrc/media/presentations/2025/sphincs-smaller-parameter-sets/sphincs-dang_2.2.pdf__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfMLb8JWR$> Given that the composites only provide EUF-CMA against quantum attackers, which is the only type of attacker that should be considered today, I don't think COSE/JOSE should work on this. All signatures standardized by NIST and IETF in the last 20 years (EdDSA, LMS, XMSS, ML-DSA, SLH-DSA) are SUF-CMA (for very good reasons). EUF-CMA can lead to significant vulnerabilities such as replay of messages, double billing, double money transactions, double receipts, double contracts, and log/transaction history poisoning. SUF-CMA vs EUF-CMA is not a theoretic consideration; it is very much a real-world problem. COSE and JOSE are used in a wide variety of use cases. And we know that many/most developers will assume that all signatures are SUF-CMA. I think SLH-DSA, LMS, and XMSS are all better options than EUF-CMA composites. Cheers, John Preuss Mattsson (As an individual) From: Orie <[email protected]<mailto:[email protected]>> Date: Thursday, 2 October 2025 at 15:10 To: John Mattsson <[email protected]<mailto:[email protected]>> Cc: Lucas Prabel <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, cose <[email protected]<mailto:[email protected]>> Subject: Re: [jose] Re: Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 Hi, Adding COSE because of the draft title. I think composite signatures for JOSE & COSE do not make a lot of sense for the common cases of short lived access tokens. For longer lived identity credentials they might make sense, especially if you are shipping hardware with no ability to upgrade that is going to speak COSE, perhaps in long lived smart building IoT scenarios? I would tend to wait for TLS / LAMPs (to successfully adopt documents) and align with them. OS On Thu, Oct 2, 2025 at 5:17 AM John Mattsson <[email protected]<mailto:[email protected]>> wrote: Dear Lucas, My recollection is that the draft was presented at IETF 121 where several people stated that they did not think JOSE should work on composite signatures. At IETF 123 the draft almost did not get any time and there were no discussion. I am sorry that the chairs did not do their AP to "Chairs will send an email soliciting comments on whether we are ready to do a call for adoption." Good that you did. I notice that TLS WG at IETF 123 seems to have decided to not work on composites at this point in time. https://datatracker.ietf.org/meeting/123/materials/slides-123-tls-wg-status-00<https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/123/materials/slides-123-tls-wg-status-00__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfKUih5zr$> The chairs would like to hear the current opinion of the working group. Cheers, John From: Lucas Prabel <[email protected]<mailto:[email protected]>> Date: Thursday, 2 October 2025 at 10:06 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [jose] Call for Adoption request: draft-prabel-jose-pq-composite-sigs-04 Dear JOSE WG, I am one of the co-authors of the individual draft draft-prabel-jose-pq-composite-sigs-04 (draft-prabel-jose-pq-composite-sigs-04 - PQ/T Hybrid Composite Signatures for JOSE and COSE<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-prabel-jose-pq-composite-sigs/04/__;!!FJ-Y8qCqXTj2!bX-0xKcDyTN5mHQRcFMVvt4snQX03K3xcjrEJidvp3FGHnR3V_TnkrKpyOlpNChEh-uEiV0j6VVrp3tOINY-7M_tfBTc1BCF$>). The draft has been presented in two IETF meetings, including IETF 123 in July. We have addressed the feedback received both on the mailing list and onsite during the sessions. The draft is also aligned with related work in other groups, in particular the COSE draft on ML-DSA and the LAMPS draft on composite signatures. We believe the document is in a good state to serve as a starting point for further work within the JOSE WG. Therefore, we would like to ask the chairs to consider issuing a Call for Adoption. We also welcome further comments and feedback on the draft from the working group. Best regards, Lucas _______________________________________________ jose mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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]
