Thanks Filip, responses inline below.
I believe some further work in due:
This PR 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.
- 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).
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 |
