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

Yoav Nir <> Thu, 16 October 2008 09:16 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3A28C3A681C; Thu, 16 Oct 2008 02:16:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19F683A6855 for <>; Thu, 16 Oct 2008 02:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0qCthYSlUkE5 for <>; Thu, 16 Oct 2008 02:16:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BFF643A681C for <>; Thu, 16 Oct 2008 02:16:28 -0700 (PDT)
Received: by (Postfix, from userid 105) id 066B229C002; Thu, 16 Oct 2008 11:17:29 +0200 (IST)
Received: from ( []) by (Postfix) with ESMTP id 14D2229C001; Thu, 16 Oct 2008 11:17:28 +0200 (IST)
Received: from (localhost []) by (8.12.10+Sun/8.12.10) with ESMTP id m9G9HRke001557; Thu, 16 Oct 2008 11:17:27 +0200 (IST)
Message-Id: <>
From: Yoav Nir <>
To: Peter Gutmann <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 16 Oct 2008 11:17:27 +0200
References: <>
X-Mailer: Apple Mail (2.929.2)
Subject: Re: [TLS] Verifying X.509 Certificate Chains out of order
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

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

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