Ian,
The slash representation is probably used because that's openssl's
default representation:
$ openssl x509 -in usercert.pem -subject -noout
subject= /C=UK/O=eScience/OU=Manchester/L=MC/CN=michael jones
whereas your format (2) can be obtained more-or-less by:
$ openssl x509 -in usercert.pem -nameopt RFC2253 -subject -noout
subject= CN=michael jones,L=MC,OU=Manchester,O=eScience,C=UK
Anyhow, for a more accurate view of a certificate try:
$ openssl x509 -in usercert.pem | openssl asn1parse -dump
As for LDAP case sensitivity, I know that the X.500 namespace talks about
upper and lowercase components, but have noticed using ldapsearch
commands that the pattern matching is often case insensitive.
eg:
$ ldapsearch -x -h ginfo.grid-support.ac.uk -p 2135 \
-b "Mds-vo-name=UK e-science,o=Grid"
results in the same as:
$ ldapsearch -x -h ginfo.grid-support.ac.uk -p 2135 \
-b "mds-vo-name=uk e-science,o=grid"
Mike
On Tue, 9 Aug 2005, Ian Stokes-Rees wrote:
> Hi, I'm trying to understand LDAP and DNs a bit better. I had always felt
> that:
>
> /C=UK/O=eScience/OU=Oxford/L=OeSC/CN=ian stokes-rees (1)
>
> was what a DN "should look like", but having just read "RFC 1779 - A String
> Representation of Distinguished Names" it seems that
>
> CN=ian stokes-rees,L=OeSC,OU=Oxford,O=eScience,C=UK (2)
>
> would be more accurate.
>
> Where does the first DN string format come from? I know this is what is used
> in Grid mapfiles, and certainly it is how one "normally" thinks of reading
> these hierarchical things (with DNS names being the exception), but RFC 1779
> seems to state they should look like (2) rather than (1).
>
> Cheers,
>
> Ian
>
> PS - Am I also right in understanding that attribute types (e.g. CN, L, OU,
> O) are case insensitive, while attribute values (e.g. OeSC, Oxford, UK) are
> case sensitive, or is this case insensitivity either explicitly aliased or
> specified in the attribute type definition?
>
--
http://www.sve.man.ac.uk/General/Staff/jonesM/
|