Re: Matter of DN and what's possible

On 1/9/12 2:59 PM, Mo McRoberts wrote:
> 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?

I am asking you that question. I am not saying that's my view.

>   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.

Again, when have I made that claim?

>
>> 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?

You acknowledge that HTTP URI based Names aren't the sole option re. 
WebID. That's the final destination of my point.

> 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.

Fine, so we are getting closer.

>
>> 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.

Yes, you can. The proof lies in relation semantics that drives the 
verification protocol.

>
>> 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.

Why would I being pulling in an expired anything?

Are you are saying that the sIA extension has expired?

>
>>> 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.
> ???

Ditto. I don't understand that paragraph if you agree that there is more 
to an HTTP scheme URI based Name than meets the eye.

>
>>> 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_.

Why just the SAN? Why not other slots if need be? That's where we disagree.

> 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?

I am saying, what about a mailto: scheme URI in SAN alongside an HTTP 
URL in SAN. The verifier dereferences the HTTP URL in SAN and arrives at 
a graph where <mailto:URI> is the description subject and its in a 
relation with the Public Key via cert:key .

If you go waaaaay back, that was the point I've been making about URIs 
being sacrosanct. Why WebID should be based on URIs.

Now, I am beginning to believe (I might be wrong) that your fundamental 
point is that irrespective of quantity or URI scheme type, the SAN 
should be the place where de-reference occurs en route to the 
description graph. If that is true, then once again, we seek the same 
thing albeit via different routes.

Now, if we are seeking the same thing via different routes, it means our 
divergence is a product of me opting not to push all of this into the 
SAN since I am wary of the complexity that Name/Address disambiguation 
introduces in its most basic form. I was also (based on behavior 
pattern) expecting knee jerk reaction from Henry.  Assuming said 
reaction lead me to looking at other options which lead to sIA which is 
ultimately a great solution to the problem.

>
> 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.

You are assuming the generator of the x.509 cert has no way of verifying 
the mailto: URI before making the certs. Of course not, our generator 
makes you prove ownership of an mailto: scheme URI. It even leverages 
BrowserID as an option for mailto: scheme URI ownership verification.

>>>   "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?

I make my cert. and save it locally.
I publish the public key and WebID relation (from the cert I created and 
saved locally) to an idp space where I have Create, Read, Update, Delete 
privileges.

>
>>> 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.

Again, where on earth has that come from. I am arguing about the 
complete opposite.

> 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.

On that we agree! That's my point.

Trouble is, this reality has its challenges, hence my pursuit of a less 
confusion option via sIA re. routes to a descriptor graph that is still 
*about* the identifiers in SAN which are alternative Names for the cert. 
Subject.

The only missing, is eventually seeing how we took different routes to 
the same destination.

Part of the detour boils down to my opting not to push a point expecting 
a gut response from Henry about complexity associated with URIs in 
general as opposed to HTTP scheme URI base Names that resolve descriptor 
(information) resources.


>
> 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