 |
 |
Not sure if this made it through or I just read the CC so here it is again. Steve ----- Forwarded message from "Jensen, J (Jens)" <[log in to unmask]> ----- From: "Jensen, J (Jens)" <[log in to unmask]> Subject: RE: [[log in to unmask]: String representation of a DN] Date: Tue, 9 Aug 2005 15:56:14 +0100 To: "Traylen, SM (Steve)" <[log in to unmask]> Cc: [log in to unmask] Thread-Topic: [[log in to unmask]: String representation of a DN] Hi Steve, I'll try posting to the list and see if it bounces... Basically X.509 did it the other way round from LDAP. Both are valid representations of the same DN. The one with the slashes is X.500 (certificates being X.509), and the other one LDAP. Comparing values is supposed to be case insensitive for many attributes but in practice usually isn't. If you don't get the case right in your gridmap file, then you won't get in. Worse yet, in ASN.1 which is a platform independent encoding of various things including certificates, there is more than one way to encode a string. printableString is the simplest encoding for the C, O, OU, L, CN fields, and has the most restricted character set. BMPString and T61String are both extended versions, allowing more characters, but obviously not the same ones. We are all supposed to move to UTF8Strings. The trouble with all the different encodings is that it is not always obvious how to compare strings in different encodings. Which is way the CA is being restrictive in the character set you can use in the CN - to ensure that everything can be encoded as printableString. The support in the toolkits for other encodings than printableStrings also varies a bit. Some browsers choke on BMPStrings. So best to stick to printableStrings. To make matters worse, sometimes you see also C=UK, O=eScience, OU=Oxford, L=OeSC, CN=ian stokes-rees and C=UK,O=eScience,OU=Oxford,L=OeSC,CN=ian stokes-rees Not to mention the fun we had with Email= vs emailAddress= vs E= we had some time ago. All are string representations of the same DN. The DN is supposed to be *encoded* in ASN.1 in the correct order regardless of what the representation looks like. --jens > -----Original Message----- > From: Steve Traylen [mailto:[log in to unmask]] > Sent: 09 August 2005 14:16 > To: Jensen, J (Jens) > Subject: [[log in to unmask]: String representation of a > DN] > > > Hi Jens, > > One for you. I can pass onto list if you can't post there. > > Steve > > ----- Forwarded message from Ian Stokes-Rees > <[log in to unmask]> ----- > > From: Ian Stokes-Rees <[log in to unmask]> > Subject: String representation of a DN > Date: Tue, 9 Aug 2005 14:09:46 +0100 > To: [log in to unmask] > Reply-To: Testbed Support for GridPP member institutes > <[log in to unmask]> > > 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? > > begin:vcard > fn:Ian Stokes-Rees > n:Stokes-Rees;Ian > org:University of Oxford;Particle Physics > adr:;;Keble Road;Oxford;;OX1 3RH;UK > email;internet:[log in to unmask] > tel;work:+44 1865 283 111 > tel;fax:+44 1865 273 418 > tel;cell:+44 7989 947 217 > x-mozilla-html:FALSE > url:http://grid.physics.ox.ac.uk/~stokes/ > version:2.1 > end:vcard > > > > ----- End forwarded message ----- > > -- > Steve Traylen > [log in to unmask] > http://www.gridpp.ac.uk/ > ----- End forwarded message ----- -- Steve Traylen [log in to unmask] http://www.gridpp.ac.uk/