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

[Nelson B Bolyard <[e-mail]>]

On 2010-06-10 07:34 PDT, Martin Rex wrote:
> Nelson B Bolyard wrote:
>> 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.
> 
> 
> 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.

> 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).

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.

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

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

> -Martin