Thank you Filip. To remaining jose working group members, please review and comment on this document by 30 June. I’m giving you one more short extension. The document is very short, and we adopted it as a working group document. Now that we are at this stage, we really should show consensus to publish it.
Thanks. Karen > On Jun 25, 2026, at 4:56 AM, Filip Skokan <[email protected]> wrote: > > With -05 out on the datatracker I support publication. > > S pozdravem, > Filip Skokan > > > On Wed, 17 Jun 2026 at 11:30, Filip Skokan <[email protected] > <mailto:[email protected]>> wrote: >> Thank you Neil, I've updated the PR to reflect your comments and included >> the offered changes. >> >> S pozdravem, >> Filip Skokan >> >> >> On Wed, 17 Jun 2026 at 11:17, Neil Madden <[email protected] >> <mailto:[email protected]>> wrote: >>> Thanks Filip, responses inline below. >>> >>>> On 17 Jun 2026, at 08:03, Filip Skokan <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> I believe some further work in due: >>>> >>>> This PR <https://github.com/NeilMadden/jose-deprecate-none-rsa1_5/pull/10> >>>> addresses the following minor finds: >>>> `The 'none' algorithm`, `The 'RSA1_5' algorithm`, and `Guidance on >>>> deprecation` promoted from H2 subsections of the Introduction to top-level >>>> (H1) sections >>>> anchored the `none` section (`{#none}`) and replaced `Sec. 1.1` in >>>> Security Considerations with `{{none}}` (auto-tracked section number) >>>> `{{RFC8017}} (section 7.2)` → `{{Section 7.2 of RFC8017}}`; `Section 7.1 >>>> of {{RFC7518}}` → `{{Section 7.1 of RFC7518}}` >>>> `[OpenID.Core]` → `{{OpenID.Core}}` (single brackets don't render) >>>> `applictions` → `applications` >>>> "currently lists 12" → "At the time of writing it lists 17" >>> These all look good, I will apply the PR later. Thank you. >>> >>>> Remaining finds: >>>> Inconsistent algorithm-name formatting: `"none"`/`"RSA1_5"` vs. `` `none` >>>> ``/`` `RSA1_5` ``. Pick one. >>>> `{{I-D.irtf-cfrg-rsa-guidance}}` is IRTF/CFRG (Informational, -08, in IRSG >>>> poll) and targets "any deployments or protocols", "for IETF protocols" is >>>> slightly off; "for new protocols and deployments" would be more accurate. >>>> Lowercase "should" with `bcp14-tagged` enabled is ambiguous; capitalize or >>>> rephrase per instance >>>> "MUST disable support for these algorithms by default" vs. "can continue >>>> to do so": make the opt-in allowance explicit; tie to RFC 7518 §3.6 "MUST >>>> NOT accept Unsecured JWSs by default" >>> >>> Will fix these ones, thanks. >>> >>>> IANA DE Instructions: IND-CCA2 scope too narrow; The `alg` category spans >>>> key encryption, key wrapping, ECDH-ES, key-agreement+wrap, and `dir`. >>>> IND-CCA2 fits PKE/KEMs, not all of the others. Scope the criterion to >>>> key-encryption/KEM `alg`s (and align with the PQ & PQ/T work >>>> <https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-pq-pqt/>). >>> >>> Thanks, this is a good point to raise. Most of the algorithms in those >>> categories can meet some definition of IND-CCA2. There are different game >>> definitions for some of them, but it’s not a notion that only applies to >>> PKE. For example, there is a well-known result that symmetric authenticated >>> encryption implies CCA2 security. >>> >>> ECDH-ES perhaps needs some thought, as it doesn’t fit easily and also has >>> “benign malleability”, which would technically make it non-CCA, but I think >>> a JWE as a whole would be - as the ephemeral key is in the protected >>> header. (There are IND-CCA2 proofs for variants of ECIES, which is what >>> ECDH-ES is, but they probably don’t directly apply here). >>> >>> I think probably the simplest fix here is to update the instructions to say >>> that the IND-CCA2 goal applies to the entire JWE encryption process, not to >>> just the key management algorithm on its own. >>> >>> On the other hand, the odd cases like ECDH-ES can be viewed as historical. >>> These days you’d register that as a KEM (DH-KEM) and meeting IND-CCA2 would >>> be unproblematic. As a minimum bar, it still seems the right choice to me. >>> >>>> IANA DE Instructions: There's subtlety in the EUF-CMA one. A MAC is not a >>>> digital signature, and JOSE is deliberate about that distinction. A >>>> Designated Expert reading the instruction literally could conclude the >>>> EUF-CMA bar doesn't apply when someone registers a new MAC. >>> Good catch - I will reword to “JWS signature and MAC algorithms”. >>> >>>> Furthermore, there are WICG documents being incubated that will do >>>> register a number of "JSON Web Signature and Encryption Algorithms" IANA >>>> Registry "alg" values for JWK Usage only (i.e. they don't define a JWS or >>>> JWE algorithm but allow key representation for Web Cryptography APIs >>>> needs) - those would not be possible with the proposed DE instructions. I >>>> recommend further scoping the updates by Usage Location and stating that >>>> JWK-only registrations stay governed by the general RFC 7518 §7.1 rule. >>> >>> The DE instructions are already scoped to “JWS algorithms”/“JWE key >>> management algorithms” etc. I don’t think they would prevent JWK-only >>> registrations. I’d be happy to add some additional text if you think it’s >>> not clear. >>> >>>> >>>> I offer to submit a PR for these too. >>> >>> Many thanks! >>> >>> Neil
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
