Re: Matter of DN and what's possible

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

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

Peter Williams does not prove anything. Peter is not mentioned on the Alice and Bob page. 
  http://en.wikipedia.org/wiki/Alice_and_Bob

Peter Williams is a new character there. Instead of breaking an existing protocol, Peter Williams inserts himself into a security protocol creation group and by flattery and pretending to be important makes sure the protocol becomes just complicated enough that he can then rely on it being badly implemented in enough places so that he can then break it. 

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

That's why we work with dereferenceable URIs. Those do exist.

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

So the question is can Peter Williams mint a cert that says he is the owner <idehen@openlinksw.com> and point to a service that he has set up for pirates? If he can then you're bank account will open to him anytime he feels like using it. 

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

Ok so lets look at the claims you have in your certificate. Let us say your cert with extension says something like 

-----------------
 <> a :Certificate;
    primaryTopic _:subj .

  _:subj distinguishiedName [ cn "Kingsley Idehen"; ... ];
      sia <http://pirates.org/makeSaomeCash/Kingsley> ;
      owl:sameAs <http://kingsley.idehen.name/dataspace/person/kidehen#this> .
-----------------

where sia is some inverse functional property .

Good, so now your bank looks at the certificate, verifies <http://pirates.org/makeSaomeCash/Kingsley> and of course it does verify (how the verification should be done would still need to be specified). What should they now conclude? That the owl:sameAs in the certificate is true and that they have to do with you?  Of course you won't agree with that.

All they can conclude is that they have to do with some _:💀 where

 _:💀 sia <http://pirates.org/makeSaomeCash/Kingsley> .

If the document at <http://pirates.org/makeSaomeCash/Kingsley> then had a primary topic declared owl:sameAs relation to http://kingsley.idehen.name/dataspace/person/kidehen#this and the document there also had a link to
 http://pirates.org/makeSaomeCash/Kingsley

then the bank could conclude that 
<http://kingsley.idehen.name/dataspace/person/kidehen#this> sia <http://pirates.org/makeSaomeCash/Kingsley>

But in that case there was no need to go through the indirection of <http://pirates.org/makeSaomeCash/Kingsley> .

QED.

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

Social Web Architect
http://bblfish.net/

Received on Monday, 9 January 2012 13:36:09 UTC