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]> 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]> wrote: > >> Thanks Filip, responses inline below. >> >> On 17 Jun 2026, at 08:03, Filip Skokan <[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]
