>
> > I would appreciate someone else's comment/feedback on this patch. Personally
> > I have no clue about this.
>
> Ok, I studied the RFC2818 a bit and I found these interesting snippets:
>
> (RFC2818, section 3.1 "Server Identity"):
>
> If a subjectAltName extension of type dNSName is present, that MUST
> be used as the identity. Otherwise, the (most specific) Common Name
> field in the Subject field of the certificate MUST be used. Although
> the use of the Common Name is existing practice, it is deprecated and
> Certification Authorities are encouraged to use the dNSName instead.
>
> We do the subjectAltName checks already. But the following paragraph says
> this:
>
> ... If more than one identity of a given type is present in
> the certificate (e.g., more than one dNSName name, a match in any one
> of the set is considered acceptable.)
>
> My understanding of this, is that we should check all Common Names in the
> certificate, not just try to figure out which single one we should check.

I fail to read this like this. It says IMO:

First, check whether you can find a match in any of the subjectaltnames,
if NO MATCH is found, you take the LAST common name, i.e., the
most specific. Or, the most specific commonname is just used as if
it were a subjectAltname.

> Any comments on this Peter?
The RFC is a compromise, as usual, and may suffer from some unprecise text,
'field' is not 100% clear to me. Why is "(most specific)" written in
(), etc.

Another example:

   In some cases, the URI is specified as an IP address rather than a
   hostname. In this case, the iPAddress subjectAltName must be present
   in the certificate and must exactly match the IP in the URI.

Why the 'must's are not MUST. The RFC is 'informational'. :-)

One might have multi-values RDN, where one component is
a common name, this may happen, some people use a sequence number together
with a common name. in any case, if one takes all the relative distinguished
names with all its components, then they are sufficiently ordered in
order to determine what would be the most specific. I admit, unless in
the certificate used in curl, I have never seen a DN with multiple
occurences of a common name.

BTW: We may try also the possibility to have an IP address in a common name,
this is something that I have seen quite often.

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Received on 2004-01-19