Subject: [TLS] Including Cert. Practice Statement in issued SSL certs

From: Nicholas Shanks <[email-masked]>
Date: Sun, 23 Dec 2007 15:56:36 +0000

Hello folks. I recently read Brian Pederson's comment on http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html 
  and wanted to send in a suggestion. Perhaps it is already present  
but I am not very knowledgeable on SSL.

I believe a a field should be added to SSL certificates, in a  
compatible and consistent place, containing the steps taken to verify  
that specific certificate before it was issued. These steps should be  
described by index into a list of possible steps, such that they can  
be displayed in translated forms and not as a potentially ambiguous  
English string chosen by a dodgy CA to confuse users.

As I understand it there's no way currently for the man in the street  
who knows nothing about computer security to distinguish between  
certificates issued after visiting the company and checking their  
records, and certificates issued by emailing a link to the WHOIS  
contact. By implementing something like the above, we could have  
'encryption only' grade certificates that protect against man‐in‐ 
the‐middle, these can remain free for anyone who wants encryption, a  
'shopping site' grade for sites that expect to take credit card  
numbers, and 'financial institution' grade, that verifies the site you  
are dealing with are a regulated bank or building society and not a  
shell company set up for phishing.

Once you are doing this, web browser vendors can display what level of  
checks were taken for each cert. and potentially grade the level of  
trust a certificate can infer.

To the browser vendors: I strongly believe your next security update  
should display a dialogue to this effect:
"The certificate issuing company ‘GeoTrust’ have been caught  
issuing certificates without Due Diligence, resulting in a  
sophisticated attack on Utah‐based credit union, ‘Mountain  
America’. Do you wish to revoke the trust currently placed in this  
company to issue SSL certificates?" with a link to "More About SSL and  
Default Trust Settings", and two buttons "Trust" and "Don't Trust".  
You should not set a default button.

This way users will be informed about what has happened (something  
most are undoubtedly unaware of, including me until today) and have  
the choice If enough decide to revoke their trust, websites will  
choose another CA, and CAs will be more careful next time!

— Nicholas

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 24 Dec 2007 19:06:33 +1300

Nicholas Shanks <[email-masked]> writes:

>I believe a a field should be added to SSL certificates, in a compatible and
>consistent place, containing the steps taken to verify that specific
>certificate before it was issued. These steps should be described by index
>into a list of possible steps, such that they can be displayed in translated
>forms and not as a potentially ambiguous English string chosen by a dodgy CA
>to confuse users.

This has been tried before in PKI-profile level efforts.  AFAIK none of them
ever caught on, it's easy enough to find a "compatible and consistent place"
to put something but (practically) impossible to find a "compatible and
consistent" way to denote it.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Dec 2007 10:28:06 -0500

This is the point of the certificate policies extension.  Certificate 
policies are just too complex for them to fulfill the use case that 
you have in mind.  Today, there are a few CAs that have a reputation 
that consumers recognize, so the issuer field seems to matter more.

There are examples where the certificate policy is helping, but not 
for the open Internet.  Showing conformance to  certificate policy is 
important in a business context where cross certification is desired.

Russ

>Hello folks. I recently read Brian Pederson's comment on 
>http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html 
>'encryption only' grade certificates that protect against 
>manâ€inâ€ theâ€middle, these can remain free for anyone who wants 
>encryption, a
>"The certificate issuing company â€˜GeoTrustâ€™ have been caught
>sophisticated attack on Utahâ€based credit union, â€˜Mountain
>Americaâ€™. Do you wish to revoke the trust currently placed in this
>— Nicholass

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Dec 2007 16:56:09 +0100 (MET)

Russ Housley wrote:
> 
> This is the point of the certificate policies extension. 

Certificate policies are close-to-useless complexity that do NOT work
at all here, certificate policies work ONLY within a single hierarchy
(they might sometimes work in a virtual single hierarchy,+
aka cross-certification), but not with Web Browsers that come
with a prepopulated list of > 100 entirely unrelated trust anchors.

>
> Today, there are a few CAs that have a reputation 

I would like to distinguish brand name from reputation.

I know one particular well known CA, that once issued
two perfectly real Microsoft Authenticode certificates to
someone who was not Microsoft--which is technically two magnitudes
worse than issuing a Web-Server cert inappropriately.

When they finally put these certs onto their CRL (a few weeks after issue),
it was realized that having it in the CRL didn't really change anything,
because the component that was vulnerable didn't ever look at their CRLs...

The primary difference among CAs in the price tag on their certs
and where the business is located in the world (i.e. jurisdiction
regulating data protection and gross negligence).  For businesses
from other countries than the CA itself, the available payment
options may influence the choice more than any kind of
brand name.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 28 Dec 2007 14:17:27 -0500

> From: Martin Rex [mailto:[email-masked]] 
> Russ Housley wrote:
> > 
> Certificate policies are close-to-useless complexity that do
> NOT work at all here, certificate policies work ONLY within
> a single hierarchy (they might sometimes work in a virtual
> single hierarchy,+ aka cross-certification), but not with
> Web Browsers that come with a prepopulated list of > 100
> entirely unrelated trust anchors.

The fact that policies are useless in general does not
contradict the fact that the point of the extension is to
convey useful information.  *IF* there were standardized
policies that 100+ trust anchors followed (e.g., Policy A =
in-person registration with 2 forms of ID and private key
on a hardware token, Policy B = software cert issued to
anyone with an email account), then the extension would
be useful.  If no SDO takes on adoption/development of a
few standard policies, then the extension will remain about
as useful as a Beta videotape.