Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4649
COMMENTS S 1.2. > 1.2. Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. You will want to cite 8174 here. S 2.6. > > 2.6. Substitution Attacks > > There are attacks in which one recipient will have a JWT intended for > it and attempt to use it at a different recipient that it was not > intended for. If not caught, these attacks can result in the I don't understand this attack. Can you go into more detail? S 3.2. > Therefore, applications MUST only allow the use of cryptographically > current algorithms that meet the security requirements of the > application. This set will vary over time as new algorithms are > introduced and existing algorithms are deprecated due to discovered > cryptographic weaknesses. Applications must therefore be designed to > enable cryptographic agility. Is this must normative? S 3.2. > may be no need to apply another layer of cryptographic protections to > the JWT. In such cases, the use of the "none" algorithm can be > perfectly acceptable. JWTs using "none" are often used in > application contexts in which the content is optionally signed; then > the URL-safe claims representation and processing can be the same in > both the signed and unsigned cases. I think you probably need to have a clearer "don't use none by default" statement here. S 3.4. > ECDH-ES ephemeral public key (epk) inputs should be validated > according to the recipient's chosen elliptic curve. For the NIST > prime-order curves P-256, P-384 and P-521, validation MUST be > performed according to Section 5.6.2.3.4 "ECC Partial Public-Key > Validation Routine" of NIST Special Publication 800-56A revision 3 > [nist-sp-800-56a-r3]. Is there an X25519 specification for JWE? If so, you should probably specify the appropriate checks. S 3.5. > 3.5. Ensure Cryptographic Keys have Sufficient Entropy > > The Key Entropy and Random Values advice in Section 10.1 of [RFC7515] > and the Password Considerations in Section 8.8 of [RFC7518] MUST be > followed. In particular, human-memorizable passwords MUST NOT be > directly used as the key to a keyed-MAC algorithm such as "HS256". If you can't use them "directly" than how should you use them? Do you want to say anything about password hashing (argon, etc.)? S 3.12. > of JWTs. > > Given the broad diversity of JWT usage and applications, the best > combination of types, required claims, values, header parameters, key > usages, and issuers to differentiate among different kinds of JWTs > will, in general, be application specific. I get that this is the state we find ourselves in, but it seems like it's unfortunate. This might be a good time to re-emphasize the recommendation for explicit types in 3.11.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
