Re: Matter of DN and what's possible

On 9 Jan 2012, at 19:46, Kingsley Idehen wrote:

>> 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”.
> 
> And this novelty comes from sole use of a specific slot in the x.509 cert, right?

No, it doesn’t. Why do you keep saying that? It’s just a convenient place to put it. SAN isn’t magical for goodness' sake, it's just where the verifiers look for that information.

> You also contradict yourself when you say:  ".. (which isn't necessarily an http: or https: URI) .." because that's my fundamental point. It shouldn't have to be a de-referencable HTTP URI based Name, solely.

How, exactly, is that contradicting myself? I have never said otherwise, and I have quite explicitly made the point on a great many occasions that there’s nothing which prevents non-HTTP URIs from being used, provided they can be unambiguously dereferenced.

> It's why I make reference to Webfinger, Fingerpoint etc.. as mechanisms for making mailto: scheme URIs resolvable. Thus, you can have them in the SAN slot.
> 
> And if you don't want to take the Webfinger and Fingerpoint route, could achieve the same via:
> 
> 1. mailto: URI in SAN
> 2. HTTP scheme URL in SAN -- that resolves to a graph that has a mailto: scheme URI for the description subject.

No, you can't.

> As for SPARQL construct, you would make a HTTP scheme URL that returns a graph that describes a subject using another URI (be mailto: or any other scheme where resolver implementation is challenging) also in the SAN.

> 
> Trouble is, I didn't even bother with the above assuming the default response from Henry. Thus, I looked for even easier and less confusing solutions which leads to the Subject Information Access slot (sIA) .

Your definition of “less confusing” differs from mine. It certainly doesn’t include pulling in an expired I-D from 2004.

>> 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.
> 
> I can't decipher disambiguation of the Name and Address roles in your comment above.
> We are dealing with URIs that have different levels of indirection en route to resolving data. That's another way of understanding Name/Address role disambiguation re. HTTP URIs.

???

> 
>> 
>> 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.
> 
> No, that isn't my point. I care about unambiguous identifiers. I also care about unambiguous data location names (addresses). I also care about descriptor (information) resources accessible from unambiguous data locations names (addresses).  I also care about semantics that facilitates loose coupling of names and descriptor (information) resources which decouples identity claims from network infrastructure.

>> 
>> 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.
> 
> A user makes a certificate and stores it to their local keystore. That part one. The then make a claim in another place, the idp space, that's part two. Relation semantics connect both realms.

That’s what being able to dereference the URI in the SAN _does_. I very pointedly and explicitly asked you if your proposal was to add a _separate_ URL which refers to the identifier in the SAN (which isn't itself dereferenceable) and you said “Yep!” (to both parts of the question). Is that not true now?

If the URI in my SAN is <mailto:mo@nevali.net>, and I don't use WebFinger (or similar), then adding an additional URL pointing at a document describing <mailto:mo@nevali.net> gets you no closer to knowing whether that really is my e-mail address or not (and so you can’t reasonably use it in any ACLs). That is what you (appeared to) have proposed doing.

>>  "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.
> 
> Not if its placed in a box, at a location, that I possess unique privileges over. And the combination of claims, and carbon copy constitute proof.

Who is “I”? The relying party?

>> 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.
> 
> At some point we'll connect. At this juncture we are speaking past one another. Your comment about de-referencable HTTP scheme URIs not being the sole option is the crux of the matter.

I don’t understand how you’ve been still labouring under the impression that non-HTTP schemes aren’t possible. Threads on this subject have been unequivocal: the spec doesn’t cover it right now, but it’s not prohibited, and there’s nothing preventing anybody from doing it.

> If you agree with that then we agree. Our only minor challenge is how we ultimately find a way reconcile that we've different paths to the same destination :-)

There is no challenge. Provided there's a mechanism to dereference the URI and obtain a resource containing structured data, it can be made to work.

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 20:02:21 UTC