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

[Yaron Sheffer <[e-mail]>]

> ----------------------------------------------------------------------
> 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