Note: This ballot was opened for revision 06 and is now closed.
= Section 1 = Many of the recommendations in this document will actually be about implementation and use of the cryptographic mechanisms underlying JWTs that are defined by JSON Web Signature (JWS) [RFC7515], JSON Web Encryption (JWE) [RFC7516], and JSON Web Algorithms (JWA) [RFC7518]. Others will be about use of the JWT claims themselves. s/will actually be/are/ s/will be/are/ = Section 3.12 = Are all of the recommended strategies listed targeted at application developers specifically? It might be useful to note that if so.
Thank you for addressing my Discuss (and Comment) points!
Nice work on this; thanks. -- Section 1 -- Readers are advised to seek out any errata or updates that apply to this document. Excellent. I note that this is a really nice opportunity to include, here, a URI to a page in the working group wiki or github that you can now create and that will be used to post updates (that might not qualify as errata) before they're incorporated into published updates. Other than that, I just have some editorial comments: -- Section 1.1 -- - Implementers of JWT libraries (and the JWS and JWE libraries used by them), Nit: Does "them" refer to the implementers or the libraries? Please re-phrase to clarify. -- Section 2.4 -- Nit: "and thus, the ciphertext, depends" should be "and, thus, the ciphertext depend" (note moved comma and plural verb). -- Section 2.6 -- Nit: "However older implementations" needs a comma: "However, older implementations" -- Section 2.7 -- I find the paragraph to be somewhat awkward, and suggest a slight rewording, thus: NEW There are attacks in which one recipient will be given a JWT that was intended for it, and will attempt to use it at a different recipient for which that JWT was not intended. For instance, if an OAuth 2.0 [RFC6749] access token is legitimately presented to an OAuth 2.0 protected resource which it is intended, that protected resource might then present that same access token to different protected resource for which the access token is not intended, in an attempt to gain access. If such situations are not caught, this can result in the attacker gaining access to resources that it is not entitled to access. END As to the title of this section, this doesn't seem to be a "substitution". I'm not sure what to call it (maybe it's a form of replay attack, but maybe not really), but "substitution" doesn't seem right. -- Section 2.9 -- Nit: In "operations, e.g. database and LDAP searches," you need a comma after "e.g." Or, better still, just change "e.g." to "such as", and avoid the Latin. -- Section 3.4 -- Nit: "(see e.g. [Valenta], Sec. 7.1)" needs commas: "(see, e.g., [Valenta], Sec. 7.1)" And in the next sentence, because of the "or both!" at the end I would remove the "Either" at the beginning. -- Section 3.6 -- It is RECOMMENDED to avoid any compression of data before encryption since such compression often reveals information about the plaintext. The passive voice doesn't work in this construct; "it is recommended to avoid" doesn't seem like proper English. Also, it's not the compression that reveals information, but the resultant compressed data, right? How about this?: NEW Compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext. END -- Section 3.11 -- Confusion of one kind of JWT for another can be prevented by having all the kinds of JWTs that could otherwise potentially be confused include an explicit JWT type value and include checking the type value in their validation rules. I find the sentence awkward, and suggest a slight rewrite: NEW Sometimes, one kind of JWT can be confused for another. If a particular kind of JWT is subject to such confusion, that JWP can include an explicit JWT type value, and the validation rules can specify checking the type. This mechanism can prevent such confusion. END
I'm by far no expert here but I don't really understand all attacks described. Maybe it's just me, however, especially 2.7 and 2.8 seem quite high level to me and I'm wondering if it is possible to be more concrete or provide an example or something. Anyway, the more important part is section 3, so no need to worry too much about this. I'm wondering if it would make sense for this document to update RFC7519. I know there is no direct change but it complements RFC7519 and using the update mechanism makes I easy/easier for readers of RFC7519 two find this doc.
§3.2: > That said, if a JWT is cryptographically protected by a transport > layer, such as TLS using cryptographically current algorithms, there > may be no need to apply another layer of cryptographic protections to > the JWT. It may be helpful to distinguish between end-to-end TLS encryption (such as that seen in HTTPS, even in the presence of proxies) and hop-by-hop TLS encryption (such as that seen in SIPS when proxies are present). In the latter case, intermediaries may perform attacks that would otherwise only be possible to mount by the endpoints. My concrete suggestion is to modify the above text to read "...protected end-to-end by a transport layer, such as..." --------------------------------------------------------------------------- §3.2: > - Avoid all RSA-PKCS1 v1.5 [RFC2313] encryption algorithms, > preferring RSA-OAEP ([RFC8017], Sec. 7.1). It's not clear to me what this recommendation intends to say regarding the algorithms in RFC 2437 and RFC 3447. One might infer that they're deprecated as well. If this is the intention, please be explicit.
Hello, thank you for this document. I wonder whether [nist-sp-800-56a-r3] should be a normative reference. Thanks -m
Thank you all for the work put into this document. I have only one NIT == NITS == -- Section 1.1 -- s/The targets of this document are/The intended audience of this document are/