Re: Matter of DN and what's possible

On 9 Jan 2012, at 13:06, Kingsley Idehen wrote:

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

Control over the certificate is provable by virtue of him HAVING THE PRIVATE KEY.

Control over the data space is provable by virtue of putting the public key data in material space which corresponds to that private key (which you’ve established by that point he controls).

If the identifier is not unambiguously de-referenceable to a resource providing that proof by a well-defined means, then control over that identifier is unproven.

If the identifier is merely a key used to select data from a *different* resource, then you’ve proved control over that resource, not over the identifier.

If I have:

sAN: http://billg.microsoft.com/#me

SAI: http://data.nevali.net/billg.ttl

And billg.ttl says:

<http://billg.microsoft.com/#me> a foaf:Person ; cert:key [ a cert:RSAPublicKey ; cert:modulus "...."^^xsd:hexBinary ; cert:exponent 65536; ] .

…then all I’ve proved is that I have control over <http://data.nevali.net/billg.ttl>; my claim to be <http://billg.microsoft.com/#me> remains unproven.

If you don’t care what URIs I might have control over, you can skip the whole “check whether there’s a cert:key relation” process and just use whatever data is in that space as though it were typed by them into a form (in fact, you could just not bother with the separate resource if you like — just use whatever claims are embedded in the certificate) — but that’s not WebID.

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


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



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Monday, 9 January 2012 14:11:53 UTC