[foaf-protocols] foaf+tls for distributed social networks - 2 questions
Henry.Story at Sun.COM
Sun May 3 18:58:52 CEST 2009
the paper has now been finalised and should be available http://spot2009.semanticweb.org/papers
soon. In the mean time I have made it available here:
On 3 May 2009, at 18:26, Nikos Mavrogiannopoulos wrote:
> Hello and sorry for the very late reply,
> I have some questions and comments made by me to make sure I
> understand well (inline). Correct me if anything is not ok.
>> As an authentication mechanism, the main goal of FOAF+SSL is to
>> bind the
>> client to the URI (of a foaf:Agent), in the same way as the client
>> would be
>> bound to a Subject DN in a PKI.
>> In short, FOAF+SSL certificates are X.509 certificates that contain
>> a public
>> key and foaf:Agent URI in its subject alternative name extension;
>> more or
>> less all the rest is ignored. (For people not familiar with FOAF,
>> foaf:Person is a subclass of foaf:Agent that models a person, for
> By ignoring the rest I suppose that you don't sign the certificate,
> and it is used merely as a container for the URI?
I am not sure if it is possible in TLS have non signed certificates...
What is sure is that the User's public key published in the
certificate has to be
able to verify the TLS communication sent by the user when he signs
stuff with his
private key. This is what ties the user to the public key.
>> To compare FOAF+SSL and PKI: what binds the client to a Subject DN
>> is both
>> (a) the TLS handshake (which links the client the holder of the
>> private key
>> matching the public key in the client cert) and (b) the
>> verification of the
>> actual certificate (certification path to trust anchor, etc.)
> So this part was for X.509 PKI that the client certificate is signed
> and verified...
>> FOAF+SSL also uses the fact that the client presents both an
>> identity claim
>> (its foaf:Agent URI in the client certificate instead of an X.500
>> DN) and the public key (which matches the private key the client
>> has). Only the evaluation of trust in the client-certificate
>> changes. At
>> this stage, whether the client certificate is self-signed or signed
>> another party isn't particularly important, since it's not what's
>> used to
>> verify its content.
> So as far as I understand the certificate is just an identity claim.
> What is the reason for this to be sent using a TLS client certificate?
> Couldn't be just a cookie (if talking about http).
Well it is an identity claim, that comes with both an Identity, and a
statement of a public key.
The two together do the work of identifying the end user.
The paper goes into the reasoning a server will follow in order to
come to accept the
More information about the foaf-protocols