As promised at the Bangkok session, here goes. Despite my comments below, I am supportive of progressing the draft to WGLC, hopefully after these are addressed. - Apologies for opening an issue that's only marginally in scope for this draft, but: the IANA registration for "none" specifies that it appears in the "alg" header parameter. However "alg" is defined for JWS (of course) but also for JWE. So - and correct me if I'm wrong - an implementer would still be compliant if they interpreted "none" as "do not encrypt" within JWE. Yes, the description in the IANA registry says "No digital signature or MAC performed" but I think a stronger separation is called for. In fact I don't understand why we have a single registry for both "key management" and integrity protection algorithms, where we don't say which can be used in which situation. (Sec. 7.1.1 of RFC 7518 does not require that a registration of an "alg" should include an indication whether it's legal for JWS, JWE or both, despite the fact that this RFC itself is actually quite clear about the usage of algorithms that it defines itself).
- Personally I am skeptical of the utility of formally deprecating None. I think libraries that still accept it are unlikely to change as a result of this RFC. But apparently I'm in the rough on that, plus the deprecation of RSA1_5 actually is important, IMHO.
- When first referencing RFC 8017, please include the exact section (7.2, as far as I can tell), because there's a lot of stuff there that's still secure.
- And to my first point about "alg" confusion, Sec. 4.2 defines RSA1_5 only for "encrypting a JWE CEK" while your draft in Sec. 1.3 says that both "none" and "RSA1_5" are deprecated for both JWE and JWS.
- I think the core sentence of this draft is "Application developers SHOULD disable support for these algorithms by default." And IMO it only has a chance of being effective if you change it to a MUST.
- Going one sentence earlier, "JOSE library developers SHOULD deprecate support for these algorithms and commit to a timeline for removal." I think this sentence is meaningless because the word "deprecate" is not well defined by itself, and because nobody is going to send a timeline to the Protocol Police [RFC8962].
- As a secdir reviewer I would have screamed at the current Security Considerations: "No security issues are introduced by this specification." If we need boilerplate text here - and we do - how about "this entire document is concerned with security, since the security of JOSE implementations directly affects the security of systems that include them (see for example the long list of CVEs in Sec. 1.1)."
- "standard security goal of authenticated encryption with associated data (AEAD)" - can you provide a reference? Otherwise this is too informal.
Thanks, Yaron |
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
