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]
