Restrictions should go to Usage Locations, that's where having an algorithm defined for signing vs just for JWK representation is determined.
We have a few registrations for JWK only representations lined up in Web Cryptography https://github.com/WICG/webcrypto-modern-algos/pull/30 S pozdravem, *Filip Skokan* On Sun, 5 Oct 2025 at 03:08, David Waite <david= [email protected]> wrote: > As other bodies leverage the algorithm registry (such as Web > Authentication and WebCrypto in the W3C), I would suggest this be guidance > toward the "JOSE Implementation Requirements” registry value being > restricted, rather than forbidding them from registration outright. > > -DW > > On Oct 4, 2025, at 3:50 AM, John Mattsson <john.mattsson= > [email protected]> wrote: > > Thanks Neil, > > >From the other thread on this list, it seems that NIST is standardising > some PQ signature schemes that are only EUF-CMA, so I’m >not sure we can > commit to SUF-CMA as an absolute requirement. I agree that SUF-CMA is a > better bar for cryptographers to aim >for, but I don’t want to > potentially exclude useful algorithms. > > Agree, I think “only algorithms that are believed to meet the standard > security goal of existential unforgeability under a chosen message attack > (EUF-CMA) should be considered for approval” is very suitable for the > registry. I think it is good to make it relatively easy to register > specification required algorithms. I was likely thinking about Standard > Track RFCs and “Recommended” when commenting, but the text is for > specification required. > > Cheers, > John > > > *From: *John Mattsson <[email protected]> > *Date: *Friday, 3 October 2025 at 09:47 > *To: *[email protected] <[email protected]> > *Subject: *Re: [jose] I-D Action: > draft-ietf-jose-deprecate-none-rsa15-03.txt > Hi, > > I did a review of draft-ietf-jose-deprecate-none-rsa15-03 > > --- > > “that future algorithm registrations should meet” > > “shold meet” does not seem to match the text in 4.2 that says: > > “only algorithms that are believed to meet … should be considered for > approval” > > Suggestion to change to “are required to meet” that would match the text > in 4.2. > According to 4.2 algorithms not meeting the requirement will not even be > considered. > > --- > > “should be registered in future.” > > See comment above > > --- > > “NIST has disallowed the use of this encryption mode for federal use since > the end of 2023 [NIST.SP800-131Ar2] and a CFRG draft > [I-D.irtf-cfrg-rsa-guidance] also deprecates this encryption mode for IETF > protocols.” > > Should add that PKCS#1: RFC 8017, RFC 3447, and RFC 2437 (1998) states > that “RSAES-PKCS1-v1_5 is included only for compatibility with existing > applications.”, i.e., don’t use it in any new applications. That a > completely new application like JOSE (2015) took this PKCS#1 algorithm that > PKCS#1 deprecated in 1998 and made it “Recommended” sent the message that > IETF is not prioritizing security. Good that this is fixed. > > --- > > “only algorithms that are believed to meet the standard security goal of > existential unforgeability under a chosen message attack (EUF-CMA) should > be considered for approval” > > With my chair hat off, I think this should be changed to strong existential > unforgeability under a chosen message attack (SUF-CMA). EdDSA, ML-DSA, and > 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. JOSE is used in a wide > variety of use cases. And we know that many/most developers will assume > that all signatures are SUF-CMA. > > While JOSE has some EUF-CMA only signatures registered, I do not think we > should register any more. > > ---- > > Cheers, > John Preuß Mattsson > > > On 2025-09-19, 11:09, "[email protected]" <[email protected]> > wrote: > Internet-Draft draft-ietf-jose-deprecate-none-rsa15-03.txt is now > available. > It is a work item of the Javascript Object Signing and Encryption (JOSE) > WG of > the IETF. > > Title: JOSE: Deprecate 'none' and 'RSA1_5' > Author: Neil Madden > Name: draft-ietf-jose-deprecate-none-rsa15-03.txt > Pages: 7 > Dates: 2025-09-19 > > Abstract: > > This document updates [RFC7518] to deprecate the JWS algorithm "none" > and the JWE algorithm "RSA1_5". These algorithms have known security > weaknesses. It also updates the Review Instructions for Designated > Experts to establish baseline security requirements that future > algorithm registrations should meet. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-deprecate-none-rsa15/ > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-jose-deprecate-none-rsa15-03.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-jose-deprecate-none-rsa15-03 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > > _______________________________________________ > 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]
