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

Hm, the actual code in curl was "almost" good.

- check, whether there is a match in any of the subjetaltnames,
- if no match found, check whether commonname, it happens just
  the the openssl routine to 'lookup' an entry does not give the
  most specific, but the least specific one.

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

After rechecking RFC 3280, there is a common usage of 'field',
I consider my previous remark as somewhat non-sense.
The only possible potential problem is the situation of a
'field', i.e. a relative distinguished name atht itself is
multivalued, i.e. may have other 'field' types like a
sequence number.

Anyway, the solution is openssl code is simple: All the attributes
are presented into a list, and one just hsa to find the last
entry:

    int j,i=-1 ;
    unsigned char * peer_CN=NULL;

    X509_NAME *name = X509_get_subject_name(server_cert) ;
    if (name)
      while ((j=X509_NAME_get_index_by_NID(name,NID_commonName,i))>=0)
        i=j;
    if (i>=0) ....

The 'little bit) more interesting case is to use
      j = ASN1_STRING_to_UTF8(&peer_CN,X509_NAME_ENTRY_get_data(X509_NAME_get_entry(name,i))) ;

to get the value, since it converts from all kinds of string representations, in
particular BMPstring (two octets). i have seen wild card common names with
BMPstrings.

>
> > 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.
SubjectAltname usage of IP addresses is explicitely defined in the RFC,
One really wants to deprecate the usage of common name, i;e. a textual
representation of an IP address, in order to avoid any conversion problem.
>
> > 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...

A string liek: "127.0.0.1", one would ned the same logic for parsing as
with ip addresses in URLs. I wouldn't really bother to implement this
now: For usage with curllib one can assume an infrastructure where
people can setup correctly a subjectAltname, and the other cases, well,
the percentage is still is LOOOOWW.

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