Re: Matter of DN and what's possible

On 1/9/12 4:17 PM, Mo McRoberts wrote:
> On 9 Jan 2012, at 20:19, Kingsley Idehen wrote:
>
>>>> 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?
> The fact that you keep asking suggested that you believed it was.
>
>>>> 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 acknowledged that months ago…?
>
>>> 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.
> Not if a third party verification agent which doesn't have any reason to trust the issuer of the cert nor the URL in particular (i.e., all of them) wants to use the mailto: URI as an unambiguous identifier in an ACL. It can’t say “only allow<mailto:kidehen@openlinksw.com>  to update this document” without allowing ANYBODY able to make that claim (which is anybody able to mint a cert and publish a graph with the mailto: URI as the subject).

It isn't: <mailto:kidehen@openlinksw.com> that determines access. It's: 
<mailto:kidehen@openlinksw.com>, public key components. The key is a 
composite i.e, the combination of two unique identifiers .

>
>>>> 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?
> The draft you linked to earlier today expired years ago and wasn’t pushed to RFC status (it says as much at the top of the document). You’d have to read the IETF mailing list threads to find out why (could be for any number of reasons).

The link was posted since it focused entirely on sIA.

>
>>>>> 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.
> Because there’s no clear benefit to not using the SAN to hold it if it works fine?

There are benefits to using alternative slots if the usage patterns adds 
complexity re. stuffing many URIs in SAN.

Again, negated the stuffing everything in SAN because I anticipated 
predictable "knee jerk" pushback. Why do you think I told Peter to hold 
fire re. use of SPARQL construct and a URL shortener? Because, I knew 
stuffing that in SAN wouldn't work with most verifiers, and ultimately 
it would be deemed to complex.


>   What benefit does complicating the number of places a relying party needs to look when processing a certificate bring?

I can ask you the same question re. mutiple URIs in SAN when most don't 
still understand the Name/Address ambiguity problem associated with HTTP 
scheme URI based Names.


>
>>> 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.
> I don't strongly care whether it's the SAN or not, but the SAN to date appears to be the most appropriate place to put URIs, so a proposal to put it somewhere else would have to be at least a little bit compelling.

Yes, and it will get compelling once people really hone into multiple 
HTTP scheme URIs in SAN. Where one URI is a generic Name and the other 
an Address.

>
>> 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.
> No, I’m not. I don’t CARE whether the generator of the X.509 cert is able to verify that mailto: URI or not. If *I* am a relying party and going to use a URI in an ACL, I’m the one who needs to verify things.

Yes, so you can verify the <maito:URI-A> + public key components 
composite or you can issue your own certs.

> I’m assuming that the relying party has no way of knowing that the generator of the cert was able to do that, which will always be the case unless there’s a specific trust relationship between verifying parties and certificate generators — which there should not be.

But depending on the system such trust could be established. The key 
thing here is to have maximum flexiblity so the parts can be configured 
in line with solution requirements.

>
>>>>>   "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.
> Um, yes, _you_ believe your _own_ claims. I would hope so (unless you knew you were lying). The point is what relying parties are meant to do.

Verify identity by leveraging fusion of PKI and the semantics that drive 
Trust Web Logics. Which is what WebID achieves.


>
>>>> 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.
> Then why on earth did you not just SAY that? This whole thread could have consisted of two messages:
>
> Kingsley: “Can I use non-HTTP but still dereferenceable URIs as my WebID?”
> Everyone else: “Yes — it’s not in the spec, but there’s no reason why it wouldn’t work, and it could be added to the spec if there was a solid case for it”
>
>> 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.
> I have no idea what that sentence means.

I am looking a less confusing options. Stuffing HTTP URIS in SAN where 
the roles varying is confusing. I negated that route, but we've ended up 
there. Next stop is verifier implementors and their struggles with SANs 
with multiple HTTP scheme URIs with varied roles.

>
>> The only missing, is eventually seeing how we took different routes to the same destination.
> Nor that.
>
>> 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.
> Good grief.

Yes, good grief :-)

Watch how this all plays out...
>


-- 

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