[glue-wg] DN format anomaly

[JP Navarro]

Given that standards in support of interoperability is our mission and that it takes time for infrastructures to migrate from old (de-factor) DN representations to newer standards based ones, I would recommend an approach that gives GLUE2  users and infrastructures time to migrate by discussing and choosing a new standards based representation for DNs would adopt, introducing a new and separate set of optional GLUE2 attibributes that can be used to publish standards based representations, and discussing a GLUE2 publishing policy/profile that facilitates evolution away from non-standards toward standards.

That's my recommendation.

JP

On Feb 11, 2013, at 5:08 AM, Paul Millar <paul.millar at desy.de> wrote:

> 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.
> 
> 
> 
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg