[OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT)

[Adam Roach via Datatracker <[e-mail]>]

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.