[foaf-dev] [foaf-protocols] revisiting FOAF project goals
henry.story at bblfish.net
Mon Jun 22 13:16:25 CEST 2009
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
> 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.
> 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
Are you saying that people are using the Subject Alternative Names
already? How are they doing it currently? Does it clash with what we
> 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
> 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
> case demo for this scenario. Likewise, we should demonstrate other
> variations of policy based security driven by personal URI graph
> 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..
More information about the foaf-dev