Re: [TLS] Verifying X.509 Certificate Chains out of order

[Yoav Nir <ynir at checkpoint.com>]

On Oct 16, 2008, at 8:18 AM, Peter Gutmann wrote:

> I have a followup question for the topic of client-auth UI issues:  
> In my
> initial response I made the standard geek mistake of leaping in to  
> address the
> technical problem ("ah, I see your problem, you need to oil the  
> guillotine and
> then the blade won't stick any more") without examining the underlying
> assumptions that it was based on.  The OP said:
>
>  For browsers, there arose a concern that automatic and silent  
> client cert
>  authentication allows a web site to request cert authentication  
> even when
>  the user has no business relationship with the site, and could be  
> used for
>  user tracking, defeating anonymity of browsing.  So the default  
> setting in
>  browsers was changed to manual selection to avoid silent user  
> tracking.
>
> So the tradeoff made was to significantly negatively impact  
> usability in
> exchange for addressing a perceived privacy threat, specifically the  
> fact that
> if I connect to a site that (for some reason) decides that it  
> doesn't want to
> use traditional browser cookies or cache cookies or web bugs or  
> Flash cookies
> or a million other ways of tracking users (including SSL session cache
> identifiers in the specific case of SSL) then they can now find out  
> that I'm
> /C=US/O=Verisign/OU=Class 1 CA/OU=No liability accepted/CN=The Jolly  
> Green
> Giant/email=qwertyuiop at hotmail.com.  Maybe I'm missing something  
> here, but
> this seems to be a case of doing something that significantly  
> negatively
> affects security usability (and therefore actual real security) in  
> order to
> address an imaginary issue that only a geek could dream up.  Is  
> there some
> other issue here that I'm missing?

There was a discussion on the PKIX list just a few days ago about what  
certificates are all about and what should go in them (yes, it's about  
time we've finally decided what certificates are all about)

Anyway, other than your DN a lot of other things can go in a cert. A  
certificate issued by Verisign is not very interesting, but a  
certificate issued by a bank or an employer may reveal your place of  
employment and some organizational structure. The Brazilian  
government, for example, includes the whole "chain of command" from  
the employee to the ministry for which they work. There is a privacy  
issue to sending all that information to a random SSL-enabled web  
server, and that is only the DN.  So you're not just "The Jolly Green  
Giant", you're the jolly green giant that works for the department of  
purchasing in the office of water works in the public works section of  
the ministry for national infrastructure (I'm making this up)

Other fields in the certificate can hold more interesting information:
- memberFrom - though PKIX actually rejected this, this field could  
say how long you've worked there
- clearance - that's what triggered the discussion on PKIX - so now  
you're the jolly green giant with "Top Secret" clearance
- mpeg of cat - now any random SSL server can know what your cat looks  
like.

I think one way of solving the silent tracking problem is to add a  
"presenting constraints" option to certificates that will instruct the  
browser to show the certificate only to servers and DNS addresses  
matched by a pattern, for example my bank can issue me a cert with  
PRESENTING_CONSTRAINTS=*.bankleumi.co.il so that only its own servers  
get this cert (when browsers support it in 10 years)

But I don't think selecting a certificate to present from a list  
(especially if the list has a "never present a certificate to this  
website" option) is all that onerous for a user.

_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls