Adam Roach has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for everyone who worked to get this document out the door. I found it to be well-organized and easy to read. --------------------------------------------------------------------------- This is a process discuss for Roman to handle, and I plan to clear it during the IESG formal telechat. This document is intended for BCP status. It has a normative reference to RFC 8017, which is an informational document. Checking the last call text (https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/edit/lastcalltext/), there is no mention of RFC 8017, nor does RFC 8017 appear in the downref registry (https://datatracker.ietf.org/doc/downref/). Thanks to RFC 8067, we are not required to run this document through IETF LC again (and, given that RFC 8017's predecessor, RFC 3447, is in the registry, we probably don't want to). However, we'll need to minute that the point was raised and addressed. There is also at least one additional requirement imposed by section 2 of RFC 8067 that needs to be satisfied (see the last sentence in that section). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- §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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
