This sounds like a great thing to add. That this draft should only be used by clients that have many (in the hundreds, if not thousands) "natural persons" associated with it, and if not, then you should use X instead.
On Thu, Nov 1, 2018 at 8:21 AM Nat Sakimura <sakim...@gmail.com> wrote: > > Adding to it, in OAuth MTLS setting, the client cert is that of the OAuth > client, which is typically a web server and not of a natural person. The > content of the certs should be well publicized so that the natural person and > the OAuth Authorization Server involved should become aware of what this > client is, so I am not sure if there is much privacy impact in this setting. > Yes, if the client is a dedicated client for the natural person, then there > is going to be additional privacy impact, but for something like that, we > were talking of token binding instead. > > On Thu, Nov 1, 2018 at 11:55 PM Neil Madden <neil.mad...@forgerock.com> wrote: >> >> I believe the standard approach to this is to only prompt for a client >> certificate in a renegotiation handshake rather than in the initial >> handshake. Renegotiations are encrypted under the existing TLS session. >> >> — Neil >> >> > On 1 Nov 2018, at 14:37, Brian Campbell >> > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: >> > >> > To be honest, I thought that was a relatively well known aspect of TLS 1.2 >> > (and prior) and a noted difference of the new features in TLS 1.3. Also, >> > I'd note that we're well past WGCL for this document. But, with that said, >> > I suppose adding some privacy considerations text on the subject is >> > worthwhile. Would you propose some text for the WG to consider, John-Mark? >> > Bearing in mind that the implications of a certificate presented by, and >> > representing, an OAuth client are somewhat different than for an end-user >> > doing client cert authentication. >> > >> > >> > >> > >> > On Wed, Oct 31, 2018 at 4:12 PM John-Mark Gurney >> > <jmg+oa...@newcontext.com> wrote: >> > I would suggest that the security considerations section of >> > draft-ietf-oauth-mtls-12 be expanded to include the privacy >> > implications of using this on versions of TLS before 1.3. On all >> > versions of TLS before 1.3, the client cert is not encrypted and can >> > be used by third parties to monitor and track users. I recently >> > posted a blog entry about this: >> > https://blog.funkthat.com/2018/10/tls-client-authentication-leaks-user.html >> > >> > Thanks. >> > >> > John-Mark Gurney >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged >> > material for the sole use of the intended recipient(s). Any review, use, >> > distribution or disclosure by others is strictly prohibited.. If you have >> > received this communication in error, please notify the sender immediately >> > by e-mail and delete the message and any file attachments from your >> > computer. Thank you._______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- John-Mark Gurney Principal Security Architect _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
