Subject: [certid] Please explicitly disallow unvetted info in subject names

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 08 Jun 2010 10:48:27 -0700

There are a large number of CAs that follow the practice of vetting SOME
of the information they put into cert subject names, but not all, and in
fact deliberately making no attempt to vet certain attributes at all.

Examples known to me include:

OU names: typically not vetted at all

CNs other than the last (most specific) one, if it is a DNS name.

Maybe it's pointless to try, but can we write into this RFC that conforming
certs contain NO unvetted attributes in the subject name nor in any Subject
Alt Name attributes?

Since CAs seem to have such a strong desire to do so, maybe we should invent
a new extension: unvetted subject alt names, where they can put whatever
nonsense they want, and apps that care to use only vetted info
can ignore.  It MUST NOT be a critical extension.  On the other hand, the
correct processing of that extension should be defined to ignore it (:-)
so that all apps may claim to properly handle it, even if it is critical.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Jun 2010 12:01:51 -0700

>certs contain NO unvetted attributes in the subject name nor in any Subject

Their vetting practices are supposed to be listed in their CPSs, so a CA can always say "we do exactly what we say we do" because they know that no one reads (or can read) their CPS.

Having said that, including this practice as a warning in the document seems like a good idea.

---

From: Sean Turner <[email-masked]>
Date: Tue, 08 Jun 2010 15:42:59 -0400

> Having said that, including this practice as a warning in the document seems like a good idea.

+1

spt

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Jun 2010 16:34:04 +0200 (MEST)

> so that all apps may claim to properly handle it, even if it is critical.

This description of what some CAs are doing is completely bogus.

CAs vouch and are liable for every single bit in the ToBeSigned part
of a certificate, no matter what stupid things they claim in any weird
and ineffective "certificate practice statement" (CPS).

A CA that doesn't is not a CA, but instead a hackers foot in your door.

This applies equally to all components of the subject DName, and
all X.509v3 extensions, such as all subjectAltNames, all keyUsages,
all extendedKeyUsages, all BasicConstraints, AIA, CRL distribution points,
and whatever else there is.

Blindly copying without validation any data from the PKCS#10 request
into the certificate that they sign would be simply irresponsible and
an act of gross negligence.

-Martin

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 10 Jun 2010 10:40:01 -0700

> This description of what some CAs are doing is completely bogus.

I agree that "what some CAs are doing is completely bogus".  That's why
I'm calling for text in the RFC to ban it.  But the description of it is
accurate.  It has been actively exploited.  This all made headlines about
a year ago, you may recall.

See attack 2a, pages 1,8-14 in Kaminsky's paper
http://www.ioactive.com/pdfs/PKILayerCake.pdf.   This paper makes it
abundantly clear what
happens when different implementations check different CNs in names with
multiple CNs, and when CAs check different CNs than the libraries check.
We should need no further reason to make this crystal clear in a new RFC.
Library implementers should need no further reason to follow the standards
to the letter.

> and ineffective "certificate practice statement" (CPS).

I think you'll find that lots of lawyers disagree.  To the contrary, they
would claim that the expectation that CAs do anything other than what their
CPSes say is the stupid part.  In most jurisdictions, there's no law that
says what CAs must do, so CAs are bound by contract, and the contracts all
cite the CPSes.

> an act of gross negligence.

If you remove all the CAs that do that from your trusted list, it's get MUCH
smaller.

---

From: Bruno Harbulot <[email-masked]>
Date: Thu, 10 Jun 2010 18:38:56 +0100

Hi,

> an act of gross negligence.

Agreed, but there's only so much the vetting can achieve. Vetting a 
piece of information depends on what it entails. Without knowing how 
some information is going to be used, the concept of vetting can be a 
bit loose.

Vetting CN=the.host.name or subjectAltName=DNS:the.host.name is quite 
clear because CAs know more or less what it's going to be used for.
The DNS system is a rather well-defined global ID system. Beyond that, 
not much is guaranteed in terms of naming.
It starts to be a bit vague even for certificates for users. Should a CA 
vet "CN=Bill Gates", "CN=William Gates", "CN=William Henry Gates", etc? 
There are a people who share the same name, even if you include the 
middle names.

If you get something like "O=Apple", is it going to be Apple 
(computers), Apple (Beatles) or Apple (http://www.apple.co.uk/).

Definition of identity and name verification is doable with a 
hierarchical system like the DNS. Everything else will depend on the CAs 
policies as to how the do the initial verification of the identity.

I think vetting a piece of information really depends on its semantics, 
and that can be a very difficult problem.
Considering that O= or OU= aren't really used for things other than 
vaguely informative purposes, I'm not sure it would make sense to 
disallow using them to put some informative but only vaguely verified 
piece of information.

Best wishes,

Bruno.

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Jun 2010 19:45:49 +0200 (MEST)

> says what CAs must do, so CAs are bound by contract, and the contracts all

It is the CAs who asked the browser vendors to ship their certs
preconfigured as trusted!

How many "certificate practice statements" (CPS) have you had to click
through before your browser allowed you to establish a TLS-protected
communication?

For every user, where the count is "none", there is _no_ CPS in effect.

-Martin

---

From: "Scott Cantor" <[email-masked]>
Date: Thu, 10 Jun 2010 13:55:41 -0400

These are all good arguments (which I subscribe to) for why treating
commercial X.509 as a "successful" trust infrastructure that other identity
standards should be leveraging in place of new approaches is a really,
really stupid idea.

But I don't think they're relevant to a document describing how one should
verify server identity against X.509 certificate content, particularly with
respect to anything that isn't a CN RDN or a sAN.

By all means rail against the idiocy of this stuff, and I'll join in since
there are still people pushing it constantly and belittling those who
disagree, but I don't think it needs to be part of this draft.

-- Scott

---

From: Nelson B Bolyard <[email-masked]>
Date: Thu, 10 Jun 2010 12:50:51 -0700

> preconfigured as trusted!

Yes, the browser vendors review the CPSes and determine whether those CPSes
meet their minimum requirements or not.  Presently the browsers (well, some
of the browsers) do not display the values of the attributes that are known
not to be vetted by numerous CAs in the main site identity display.  (Those
attributes may be displayed if the user brings up a dialog that views the
entire certificate).

> For every user, where the count is "none", there is _no_ CPS in effect.

You're welcome to that opinion.

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Fri, 11 Jun 2010 01:46:30 +0300 (EEST)

> and whatever else there is.

I agree with the list above except keyUsage and extendedKeyUsage which are
somewhat identity neutral.

> an act of gross negligence.

100% agree.

M.D.
cell: +370-699-26662
>
>
> -Martin
>
>
>
>
>
>
>
>
>
> _______________________________________________
> certid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/certid
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 14:34:32 -0600

My apologies for the delay, I'm just catching up on list traffic here.

> disagree, but I don't think it needs to be part of this draft.

Agreed. Once again, this draft is not the sole repository for all wisdom
regarding certificates, TLS, Internet identifiers, and security
protocols in general. I'd love to see more general specifications
regarding those topics, but in this draft we're trying to boil just a
small harbor, not the entire ocean.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/