[foaf-protocols] FOAF+SSL Distinguished Name

[Peter Williams]

Failures in java's string encoder factories for DNs (Seq of RDNs) are not a
basis for rejecting the X.500 standard for structured names. (If the old
javasoft team's libraries were a crappy implementation, we call them such
and move on to something better.) 

Now, having said that, we don't want to use 25 year old structured names
conceptions - in the web. We want to use modern structured names. We want to
learn from X.500's mistakes and omissions - and do better. We (well I
anyways) don't deny the value of the X.500 stuff. I want to learn from what
didn't "quite" work.
 
When I read the very readable semweb book .. "yada yada for the working
ontologist", it had as nice section on web-friendly structured names. It
nicely moved way past the silly debates on string encoders of DNs (that seem
as bad now in the ldap world as they were in the Inria pilots of DNs in the
late 80s).

Part of the reason I spent 3 months teaching myself java factory- and ORM-
based programming last year was so I could add signed XRDs to the openXRI
open source project. Now I put up with that (which pushed my limited brain
way beyond where it was designed to go) not only because signed XRDs worth
having (in openid land) but XRIs are a structured name form - featuring some
excellent and specifically [sem]web engineering efforts. It allowed to me
learn (by doing) - java libs, java styles of thinking, java tool chains,
java factories, hiberate's ORM (and what java is no good for, if you come
from the bottom half of the programming class)

Ok. XRI structured names in java or any other implementation tool are going
nowhere in W3C land, for reasons not worth mentioning here. But, structured
names should not be ignored - since that is what X.500 taught us to do. They
have an important role to play in crypto - and thus foaf+ssl. Structured
names allow for renaming, enabling the infamous world of polyarchical
synonyms to better the web by allowing for naming resilience. 




-----Original Message-----
From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Bruno
Harbulot
Sent: Tuesday, February 16, 2010 10:13 AM
To: Story Henry
Cc: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] FOAF+SSL Distinguished Name

Although there are historical links between LDAP and the distinguished 
names in X.509 certificates, I don't think we should use LDAP URIs this way.

What we get from a Subject DN is an X.500 name. It's a sequence of 
AttributeType-AttributeValue pairs, where the name is an OID for one of 
the fields (e.g. CommonName or Organization) and the value can be 
anything (depending on what the attribute type is).

<http://tools.ietf.org/html/rfc3280#appendix-A>

DistinguishedName ::=   RDNSequence

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName  ::=
                     SET SIZE (1 .. MAX) OF AttributeTypeAndValue

AttributeType           ::=  OBJECT IDENTIFIER

AttributeValue          ::=  ANY

AttributeTypeAndValue           ::=     SEQUENCE {
         type    AttributeType,
         value   AttributeValue }



The serialisation of RDNSequence isn't that straightforward. Java has at 
least 3 ways of turning an X500Principal into a string, the default 
being RFC-2253 <http://tools.ietf.org/html/rfc2253>, see
<http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Princi
pal.html#getName%28%29>

Some applications will use a completely different string representation 
of a DN. In particular, what's quite common in the Apache/OpenSSL 
environment is to use '/' as a separator and have the fields ordered the 
other way around, for example:

  /O=FOAF+SSL/UID=http://esw.w3.org/topic/foaf+ssl/CN=FOAF+SSL Version 1

whereas Java (using the RFC2253 format) would show:

  CN=FOAF+SSL Version 1,UID=http://esw.w3.org/topic/foaf+ssl,O=FOAF+SSL

The obvious problem is the use of slash as a separator which conflict 
with the URI's slash.



If you really want to model DNs in RDF, I guess you need to model the 
sequence, perhaps with blank nodes and OIDs (considering that some of 
the values may be binary blobs).


Best wishes,

Bruno.


Story Henry wrote:
> On 16 Feb 2010, at 17:18, Story Henry wrote:
>> :we a foaf:Agent;
> 
> 
> I am not sure what the correct ldap URL would be for the DN we propose,
and indeed if it can be written out. 
> 
> From http://ftp.ics.uci.edu/pub/ietf/uri/rfc2255.txt
> and http://www.ietf.org/rfc/rfc1959.txt (which has some examples)
> I guess it could be something like (though the non compliant chars need to
be escaped with %
> 
> <ldap:///o=FOAF+SSL,uid=http://esw.w3.org/topic/foaf+ssl,cn=FOAF+SSL
Version 1>
> 
> If something like that is right, then we could write:
> 
> :we a foaf:Agent;
>     owl:sameAs
<ldap:///o=FOAF+SSL,uid=http://esw.w3.org/topic/foaf+ssl,cn=FOAF+SSL Version
1> .
> 
> Henry
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
_______________________________________________
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols