Re: Matter of DN and what's possible

On 9 Jan 2012, at 18:42, Kingsley Idehen wrote:

> On 1/9/12 1:35 PM, Henry Story wrote:
>> Ok. So now you have two URLs where before we had one. That is why the previous talk about URIs being a luxury does not make sense. Your solution requires more of them.
>> 
>>>> >>  And if it is a URL then why is that not just the place of a WebID then?
>>> >  >  Because you will ultimately quibble about its complexity.
>> Why, I have always supported multiple SANs in the certificate. No issue there.
>> 
> One point re. the above. Imagine the following scenario:
> 
> I have a sparql construct URL as my address (and compacted using a shortener), and a HTTP URI based Name as the subject Name. Both URIs placed in SAN of my x.509 cert. Would your verifier work? Do you deem this acceptable re. WebID spec as it currently stands?
> 
> Note: the SPARQL URL resolves to a description graph. The other URI is the Subject described by said graph.

Unless you crafted your construct in a particular way, then no, it wouldn’t verify. In either case, assuming the HTTP URI based name wasn't dereferenceable itself (as you’ve said), it would simply be discarded. Put one in the DN the other in the sAI; put both in the SAN — it doesn’t change the processes behind it.

Let me put this as simply and straightforwardly as I can manage.

The thing which has made WebID novel is that it marries a certificate and a dereferenceable URI (which isn't necessarily an http: or https: URI) in order for a relying party to be able to definitively say “yes, that URI uniquely identifies the holder of the certificate”.

If you take that away, but still keep in the “URL of some data somewhere” aspect, then you’ve got a client certificates with stock attribute exchange — which is interesting, but isn’t the same thing, and doesn’t let you use the URI as a unique identifier for the holder (not necessarily a bad thing in itself; I posted about approaches to that back in April last year).

If the URI itself isn't de-referenceable, and the certificate has to bear *another* URL which is used as the location of the data about the URI, then you're eschewing the only mechanism which tells you whether that the holder of that URI is the same as the holder of the certificate. Looking at a different URL for that information amounts to taking the other URL’s word for it, which isn’t the same thing. This is why I posted the various examples which show exactly this.

Perhaps it's the case that you don’t care about being able to identify the certificate-holder globally using the URI carried by the certificate. That's fine. 

You can do all the semantic hoop-jumping in the world, but it’s simply impossible to achieve the following:

1. Certificate C contains identifier I and locator L.
2. Identifier I is not resolveable.
3. Locator L contains structured data with I as the subject.
4. Relying party A wishes to determine whether it can uniquely and definitively identify the subject as I solely by asking L.

This is quite simply because both L and I are of the user’s choosing. Neither are trusted to any extent, and the only relationship they have with one another is that that both are named by the certificate and by L. "I" could be a  UUID, a telephone number, an ISBN, an OID — it really doesn’t matter, the principle is the same. It’s pretty much like you asking for proof of my postal address, and me sitting down with a text editor and typing out “This document is proof that my address is 24 Sycamore Drive, Washington DC., USA”, attaching my photo, printing it out and handing it to you: unless you try to send me some mail there, or knock on the front door, or ask for more concrete proof, the information is of little use beyond forming part of a list of things I have claimed at some point or another.

Do you really want proof of my postal address? I don’t know — but WebID as it exists now is built on the concept that relying parties do so that they can do interesting things with it.

M.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

Received on Monday, 9 January 2012 19:23:31 UTC