Re: [certid] DC should be MUST NOT

[Bruno Harbulot <[e-mail]>]

On 12/06/2010 01:12, Paul Hoffman wrote:
>>    6.  The certificate SHOULD NOT represent the server's fully-qualified
>>        DNS domain name by means of a DC-ID, i.e., a series of Domain
>>        Component (DC) attributes in the certificate subject, with one
>>        RDN per domain label and one DC in each RDN.  Although (for
>>        example)<dc=www,dc=example,dc=com>  could be used to represent
>>        the DNS domain name "www.example.com", given the fact that the
>>        DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED.
>
> This should be a MUST NOT. And the reason for the prohibition is not "DNS-ID can be used instead", but rather "this is insecure because you can interpret the series of RDNs incorrectly".
>

On this topic in 2.2.5 and 2.2.6, as Peter Sylvester and I said earlier 
in [1] and [2], I don't think using the word 'represent' is right here.

Currently, certificates that have been emitted with the aim that tools 
will verify them according to RFC 2818 and that have a subject 
alternative name, what's in the subject distinguished name (including 
CN) is more or less decorative (with respect to the validation of the 
identity of the server).

In this case, CN=host.name is still quite convenient to have, for humans 
to be able to sort their certificates. Maybe it's just me, but I keep my 
backups of my server certificates in tools such as OSX keychains, 
security stores in the browser or PKCS#12 files. The tools associated 
with them tend not to display anything about the subject alternative 
name in their listings (in terms of user interface) and I guess that's 
not going to change any time soon. (I guess larger systems could also 
use some sort of LDAP browser for example, in a similar way.)
CN=host.name there is convenient, and it doesn't really get in the way 
of checking the identity of the remote server by an actual client when 
there's a subject alt. name (so long as the rules specify to ignore CN 
when there is an alt. name).

For this reason, I'm not sure why you'd want to forbid CN=host.name 
(whatever its RDN position is) in such a certificate.

The problem with the way I understand 'represent' in this context, is 
that you don't really know whether the CA put the CN in the subject DN 
as an indication (after all, it's a "common name") or with the intent it 
would be used by clients for verification.


Which one of these would be OK?

1. Subject DN    :  C=UK,CN=the host name is host.name,E=[e-mail]
    SubjectAltName:  DNS:host.name

    Here, the certificate doesn't "represent" the host name in the CN 
(it's another string instead)


2. Subject DN    :  C=UK,CN=host.name,E=[e-mail]
    SubjectAltName:  DNS:host.name

    Here, the certificate "represents" the host name. Does it really, or 
is it just an indication as above?



The structure of the subject DNs tend to follow some nomenclature 
internal to the CA. I'm not sure this specification should interfere 
with that when the subject DN is made somehow irrelevant by the presence 
of a subject alternative name.


Best wishes,

Bruno.


[1] http://www.ietf.org/mail-archive/web/certid/current/msg00091.html
[2] http://www.ietf.org/mail-archive/web/certid/current/msg00052.html