Re: WebID equivalence

On 1/3/12 6:21 PM, Henry Story wrote:
> On 3 Jan 2012, at 23:28, Kingsley Idehen wrote:
>
>> On 1/3/12 4:37 PM, Mo McRoberts wrote:
>>> On 3 Jan 2012, at 14:36, Kingsley Idehen wrote:
>>>
>>>>> CN=www.freesoft.org is not a CN containing a URL, for a start. A CN is effectively arbitrary, will often be used for matching (cf. clients comparing SSL server hostnames).
>>>> And emailAddress is not an Address either right?
>>> An emailAddress is an email address. Sheesh.
>>>
>>>> What do you think www.freesoft.org is then?
>>> Broadly: a FQDN
>>>
>>> In a commonName RDN value: an arbitrary label, which in a client cert is used for nothing except advertising. In SSL servers, it's used as a match source against what the UA expects it to be (which by convention, for reasons which are now obvious, is the FQDN of the server or a wildcarded derivative). But, to date, it still is largely a comparator — the closest you get to triggered behaviour when a certificate is presented is querying a locally-configured directory service for an entity matching the DN.
>>>
>>>>> (You could add a URI as a DN attribute, though, if you know the signing entity will accept it — just pick or define an appropriate attribute OID).
>>>>>
>>>>> Whether *parts* of a DN should trigger special processing on the part of a receiver is a different matter. I can't recall what ITU recs have to say on the subject. I do know that a number of free personal certificate issuers mandate that the CN is a fixed string.
>>>> We are using a standard representation of an info card and its semantics, to construct a protocol with its own set of semantics i.e., the WebID verification protocol. Nothing that I've stated breaks anything re. X.509 or PKI. Neither does it break WebID. Its only issue is novelty.
>>> Of course it doesn't break anything re: X.509 or PKI. And it is a neat trick in novelty stakes, just like my terminal emulator turning URIs which appear in its window into hyperlinks is a neat (if imperfect) trick.
>>>
>>> What sprang to mind was whether what -other people- are doing with those RDNs (i.e., anything they like) would break what you were doing when you processed them.
>>>
>>> And, if you're overloading semantics of DNs, you're as well just defining a new attribute…
>> My system is the WebID protocol, I don't expect it to trip up others who are using the same infrastructure for something a little different :-)
> The WebID protocol ( http://webid.info/spec ) does not mention the DN, except as a place to put a human readable name in conformance with RFC 5280
>
>    http://tools.ietf.org/html/rfc5280
>
>   Standard sets of attributes have been defined in the X.500 series of
>     specifications [
> X.520
> ].  Implementations of this specification MUST
>     be prepared to receive the following standard attribute types in
>     issuer and subject (
> Section 4.1.2.6
> ) names:
>
>        * country,
>        * organization,
>        * organizational unit,
>        * distinguished name qualifier,
>        * state or province name,
>        * common name (e.g., "Susan Housley"), and
>        * serial number.
>
> That is pretty clear right?

You are quoting a spec that reflects your world view.

I am making a suggestion to broaden the scope of your world view based 
on the flexibility inherent in X.509.

Please digest the context of my comments. I am making a WebID 
suggestion. Thus, don't quote a spec that lacks said suggestions.


>
>   In addition, implementations of this specification MUST be prepared
>     to receive the domainComponent attribute, as defined in [
> RFC4519
> ].
>     The Domain Name System (DNS) provides a hierarchical resource
>     labeling system.  This attribute provides a convenient mechanism for
>     organizations that wish to use DNs that parallel their DNS names.
>     This is not a replacement for the dNSName component of the
>     alternative name extensions.
>
> So even the IETF people are pushing people to move DNS names to the SAN fields.

That's isn't the point. You are making a poor argument tainted with 
blatant bias.

I am talking about what's possible with tangible benefits.

Clearly you don't see the implicit problems that de-referencable names 
bring to all Linked Data endeavors. Again, as was the case with RDF/XML, 
I am pointing out problems with technologies I and my company have long 
mastered. I understand and exploit de-referencable HTTP URIs in manners 
that most have even though about, that doesn't mean I don't also 
appreciate the problems they introduce to Linked Data adoption and 
comprehension in general.

HTTP URI based Names are extremely powerful, but extremely unintuitive. 
The URI abstraction caters for URNs and URLs as subClasses. Refusal to 
accept this reality, when you have a broad audience in mind, is a major 
catalyst for the never ending httpRange-14 imbroglio.

Use a Name to do things that fit the Name Role. Don't use was many think 
is an Address as a Name, certainly not at first blush irrespective of 
deeper prowess. Use an Address for functionality folks intuitively 
associate with addresses e.g., data access. Use Names to Identity things.

You can still end up with the graph that describes a subject with an 
x.509 as the information source.

As much as you continue to ignore my references to the Hammer Stack and 
Webfinger, do note that this is something the pragmatists over there 
long figured out. And btw re. Linked Data, the same pattern applies re. 
host metadata discovery:

>
> We should be trying to be stick with the IETF specs and use them as required.

It seems that's only the case when it matches your preferences, 
unfortunately. Once there's deviation you end up distorting first. I 
still can't believe your interpretation of my suggestion re. Addresses 
in CN and Names in SAN.

Links:

1. id.myopenlink.net/.well-known/host-meta -- an example of the Hammer 
Stack pattern in play re. deductive discovery

2. 
http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=id.myopenlink.net%2F.well-known%2Fhost-meta&useragentheader=&acceptheader= 
-- URI debigger view

3. 
http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http%3A%2F%2Fid.myopenlink.net%2Fdataspace%2Fperson%2FKingsleyUyiIdehen&useragentheader=&acceptheader= 
-- how it comes together re. URIs that also serve as WebIDs

4. http://tools.ietf.org/html/draft-nottingham-site-meta-05 -- IETF spec.

Kingsley
>
> Henry
>
>>> M.
>>>
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> Founder&   CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Wednesday, 4 January 2012 00:57:25 UTC