----------------------------------------------------------------------
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).
Resolved by Roman in a subsequent message.
----------------------------------------------------------------------
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..."
Yes. Fixed in the upcoming -07.
---------------------------------------------------------------------------
§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.
Yes this is confusing. For consistency, we will also reference PKCS1
v1.5 from RFC 8017 (which is the only recent, non-obsoleted RFC out of
this chain).
Thanks,
Yaron
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
