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,[email protected]
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,[email protected]
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
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
