[glue-wg] DN format anomaly

[Paul Millar]

Hi Stephen,

On 02/08/2013 06:05 PM, stephen.burke at stfc.ac.uk wrote:
> glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On
>> Behalf Of Paul Millar said: ... and you want to base a standard on
>> this?
>
> Apparently we already have - essentially all the middleware uses it,
> including dcache as far as I remember.

Up to a point; there are file formats that use OpenSSL-format for 
representing DNs, perhaps most notably the gridmap and signing_policy 
files.  Software, like dCache, that supports these files must support 
OpenSSL-format (or, more often, use libraries that do).

So the statement "all the middleware uses it" is probably correct, 
insofar as all middleware supports file formats (like signing_policy 
files) that use it.

Internally, it very much depends.  Support for any particular file 
format isn't necessarily a strong indicator that it supports that 
particular encoding internally.  Within dCache, we're in the process of 
moving away from Globus-specific representations in favour of 
standards-based ones.

Therefore it is spurious to conclude that, since all software supports 
particular file formats, they all use OpenSSL-format internally.

 > I don't see much point in GLUE doing something different when all it's
 > doing is publishing strings, if everything that actually *uses* DNs
 > for authn and authz uses the openssl format.

First off, and I can't emphasis this enough, it's not a standard!

How does one represent a RDN value with a '/' in it?  How are non-ASCII 
names handled (Chinese CNs, anyone)?  How are RDNs with multiple AVAs 
handled? ... etc ...

How can one write a validator for GLUE2 when so much is left 
unspecified.  How does this foster interoperability?

Second, this argument is that of vendor lock-in.

For a variety of reasons, WLCG grid software currently suffers from a 
vendor lock-in with Globus code, which uses OpenSSL-format.  Rather than 
use a vendor-neutral format, you advocate using a non-standard format.

Yes, it's always easier to follow the path of vendor lock-in; that's why 
it works.  Remaining neutral often involves putting in some extra 
effort; however, it pays off in the long run.

>> Adopt a standardised format, say, one published as an RFC.
>
> An RFC for LDAP, not X509!

Note that I didn't say we keep the same RFC, rather that it must be a 
published standard.

[aside, LDAP and X509 both use ASN.1 for encoding and have the same 
concept of "a DistingushedName", since they both derive from X500 
service model.  Using an LDAP RFC isn't *so* crazy.]

I would recommend we take advice from security experts about which 
standard/RFC we should use when defining the representation.

Cheers,

Paul.