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

[Bruno Harbulot <[e-mail]>]

Hi,

On 10/06/10 15:34, 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.
>
> 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.

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.