[foaf-dev] [foaf-protocols] revisiting FOAF project goals

[Story Henry]

On 22 Jun 2009, at 03:29, Peter Williams wrote:

> Say more about what semantics you are attaching to URI naming fields  
> in a cert?

This is something we should look at more carefully, yes. I think we  
are currently working with the idea that the process of dereferencing  
the URI gives us information about what it is naming. A bit like  
dereferencing http://google.com/ lets you discover that it is a search  
engine.

> I'm the one who had ISO put URIs into the X.509 standard, way back  
> in 1996.

Yes, we should add that to the wiki. Thanks very much for the  
foresight of adding that to X509. Really cool :-)

> I had to argue hard to ensure they kept URI, rather than use URL.  
> However, URI has stood there for a decade, unused -  unlike most of  
> the other naming architecture options. Id be delighted if it now got  
> used... and folks defined it "comprehensively".
>
> First off:
>
> there are two distinct naming thingies to exploit in certs: URI  
> attached to the asserting party (issuer) field; URI attached to the  
> identified party (subject) field.

Both could be used. It would be quite interesting to look at what is  
possible when the asserting party being different from the CA itself  
has a WebId. This may make it possible to explore one's trust in  
asserting parties in a similar way as we are currently exploring the  
trust of the subject. A service could then discover that because it  
trusts the asserting party, it can trust the subject, even though it  
knows nothing ab out it.

So here is an example:

  Imagine Sun Microsystems, gives signs all of it's employees Certs  
and identifies itself with a WebId. Imagine I log into a system, that  
only trusts people certified by Nasdaq companies. Imagine furthermore  
that Nasdaq has a foaf file that lists all it's members. That company  
could crawl that every so often, and from that find out the WebId of  
the certifiers it trusts....


> The terms issuer/subject are just relics of "key" management command  
> and control theory, from which X.509 was derived. There is nothing  
> hierarchical about them, in reality.

I suppose the only limitation as opposed to PGP is that there can only  
be one direct signer, which is limits the signing to a tree.

>
> Second:
>
> you can have as many (alternative) issuer/subject names as you want  
> in a cert. Each can be a URI, furthermore. This notion of  
> multiplicity of (common name => domain-name) synonyms is already  
> used in https world, to enforce virtual hosting controls at https  
> clients.

Are you saying that people are using the Subject Alternative Names  
already? How are they doing it currently? Does it clash with what we  
are doing?
>
> If one wants, one URI can be an HXRI to an i-name; another might an  
> an HTTP URL that is a non-global (i.e. local) XRI resolvable only  
> given a third party naming context (such  as a FOAF URL); another  
> can be a FOAF file pointer itself; another can be a WebID, etc etc...

yes a number of URIs would be possible. Foaf+ssl might in fact work  
with other protocols too, if they have a dereferencing mechanism. It  
would be wise not to have too many, as each dereferencing process can  
take time.


>
>
>
> ________________________________________
> From: Kingsley Idehen [kidehen at openlinksw.com]
> Sent: Sunday, June 21, 2009 5:00 PM
> To: Peter Williams
> Cc: Hailton Sales; foaf-dev at lists.foaf-project.org
> Subject: Re: [foaf-dev] [foaf-protocols] revisiting FOAF project goals
>
> Peter Williams wrote:
>> there is strong evidence that mutual authentication is vitally  
>> important - addressing the social phenomenon of phishing for  
>> secrets. Impersonation of sites is rife - and SSL (and certs) is  
>> evidently not addressing the issue. The inability to detect  
>> impersonation is a vulnerability in the core web architecture  
>> model, and evidently the "universal browser concept" is as lacking  
>> this year on this topic as it was in 1992.
>>
>> Now, folks are using site (vs browser) mechanisms such as BankOf  
>> America's SiteKey scheme - to authenticate the site "visually" and  
>> personally. (If you dont see your personal image and caption shown  
>> on accessing a site via https, assume its impersonating your  
>> trusted website partner. Change your image and caption,  
>> periodically, to retain "personal control" of site authentication.).
>>
>> Given  the above, consider whether "WebID" needs to address more  
>> than the Person entity (in a PPD). Perhaps it should also address a  
>> WebSite entity (in a WPD)? Then consider whether the locator for a  
>> FOAF file needs to address more than a PPD, too.
>>
> In a nutshell, it has too :-)
>
> The social aspects of security should be expressed via data access
> policies that result in the location of items exposed via the URI
> embedded within an X.509 cert. For the interactive side of things we
> should be able to emulate the BankOf America scheme and use it as a  
> test
> case demo for this scenario. Likewise, we should demonstrate other
> variations of policy based security driven by personal URI graph  
> analysis.
>
> The emphasis has been on the authentication side of matters to date is
> more about a desire to get the basic idea uniformly understood and
> demonstrated by its various supporters.
>
> Next stop will certainly be policy based data access etc..
>
>
> Kingsley