Re: Matter of DN and what's possible

On 1/9/12 7:20 AM, Mo McRoberts wrote:
> Kingsley,
>
> The point of mirroring the claim in a resource which can be retrieved by de-referencing the URI the holder assigns themselves is so that you can be sure they have a reasonable degree of authority over that URI, and so can use it as an identifier for them.

That assurance doesn't come solely from the SAN. It comes from the 
certificate. The SAN simply offers a slot to hold Name(s). The fact that 
said Names are de-referencable is a Web scale luxury that most 
publishers simply cannot afford, as already demonstrated by Peter.

>   It doesn't matter whether that's an http: or https: URI, or some other kind (acct:, ldap:, whatever) — provided there’s an unambiguous function which can be handed that URI and will de-reference it to a resource which contains the mirrored claims.

It does, since not all URIs are de-referencable. Thus, what you need is 
a slot in the certificate that holds the address of a descriptor 
(information) resource that describes the cert. subject using the 
Name(s) in SAN.

>
> If the resource you’re fetching isn’t de-referenced from the that identifier — i.e., it comes from somewhere else entirely, as you suggested would be the case (see quote below), then the claim over the URI isn’t mirrored any more.

The cert. is making a relation between the SAN and the descriptor 
(information) resource address.

>
>>> If I'm understanding correctly, you're saying (for example), that sIA might contain a URL,
>> Yep!
>>
>> This reference (an Address) resolves to a profile resource bearing claims mirror.
>>> while the sAN contains the URI of the certificate holder which appears within the document published at the sIA URL?
>> Yep!
>
> Thus, Peter might have:
>
> sIA:<http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3>
>
> sAN:<http://yorkpc2.blogspot.com/#me>
>
> (And the data at yorkpc2.blogspot.com might be in some random format, or might not even be published there at all — it’s just used as a key by rdf-translator.appspot.com).
>
> There’s nothing wrong with this *per se* but you’re changing the landscape somewhat: it reduces the scope of everything in the the resource to 'untrusted, unverified input' — it’s just a self-asserted attribute exchange document, at which point there’s no point in verifying that the key matches any more, because it doesn’t make a jot of difference to anything if it does. What you *can’t* do any more is use the self-asserted identifier of the holder as any sort of confirmed identifier, because the claim isn't mirrored there — it’s mirrored somewhere else entirely.

You have a claim in a certificate. Another in a descriptor (information) 
resource at an Address.

You can achieve this via de-referencable Names i.e., > 1 level of 
indirection (a luxury to a majority of claim publishers).
You can achieve this via a de-referencable Address with 1 level of 
indirection via an URL in sIA.

The existence of the following in his x.509 cert is a claim. Control 
over the cert is provable by virtue of him placing the modulus, 
exponent, and even other splices of the local cert. in an idp space over 
which he has CRUD privileges e.g. a blog post in a space offered to him 
by Blogspot.com. The same proof applies to email addresses as long 
exploited by S/MIME .

>
> In the above example, Peter has no confirmed claim over<http://yorkpc2.blogspot.com/#me>  because the data which would otherwise mirror that claim and confirm it is retrieved from<http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3>  without ever touching the resources retrieved when de-referencing the sAN URI.
> At this point, the only piece of actual confirmed information you have (and so the only thing you can use as an identifier) is the public key itself, the content of the profile document is no different from presenting a form and asking the user to fill it in.

You are signing and exchanging the claims in the cert when you perform a 
SSL/TLS handshake. WebID proof is not about what's in the SAN. It's 
about the relations inferred from the Cert. with the de-referencable URI 
in the SAN serving as the conduit to the idp space that holds the mirror 
of claims in the cert.

As you'll eventually realize, we could just as well lookup the entire 
cert blob in the idp space. In that case you are looking up a complete 
carbon copy across the local cert. and what's been placed by the 
certificate subject in an idp space. Again, this is also an old point 
made by Peter and others in the early days of this endeavor. There's 
nothing that special about the public key per se. It the fact that we 
have claims in two places that matters, ultimately.

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