On Mon, 19 Jan 2004, Peter Sylvester wrote:

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

Hm, ok. I don't know what the proper way of verifying this would be...

If this was the case (that only one name - the last one - is the one that
matters), what would be the point of having multiple Common Names in the
certificate in the first place? Always ignoring one or more names seem
pointless.

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

I agree that is weird and I don't understand that wording either.

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

Well, I can accept 'must' instead of 'MUST'... :-) We already support IP
addresses in the subjectAltName comparisions.

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

Is that IP address then stored as a string or as binary like the
subjectAltName field does it? If it is a plain string, we don't have do to
anything different...

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
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