> -----Original Message----- > From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Adam Roach via > Datatracker > Sent: Tuesday, June 25, 2019 1:05 AM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-oauth-jwt-...@ietf.org; hannes.tschofe...@arm.com; oauth- > cha...@ietf.org; oauth@ietf.org > Subject: Adam Roach's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS > and COMMENT) > > 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).
Good catch. This is my fault. The caution of the downref was in the shepherd write-up (thanks Hannes). I share your view that since RFC8017 (not in downref registry but referenced here) obsoletes RFC3447 (in the downref registry), we don't need to re-run the LC (per Section 2 of RFC8067). Is there concern with this course of action? Roman > > ---------------------------------------------------------------------- > 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
