[foaf-protocols] foaf+tls for distributed social networks - 2 questions
Bruno.Harbulot at manchester.ac.uk
Fri Apr 24 16:16:23 CEST 2009
Nikos Mavrogiannopoulos wrote:
> Henry Story wrote:
>> Dear TLS experts,
>> We are working on a very simple protocol for distributed identity in a
>> web of trust that uses TLS in a novel way. The details of this are short
>> and can be found online . Here I'd first just like to ask two
>> questions, to get into the heart of the problem, then I'll explain why
>> these came up.
> After the explanation and seeing the protocol description I still do not
> understand why you need the client certificate for what you want to
> achieve. Why you don't send the information you need for foaf on the
> application layer (if it is http via a cookie etc)? Why send a dummy
> certificate and add some extensions on it? Also the security offerings
> are not clear to me. What will that protocol offer, security-wise?
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
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
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
Subject DN) and the public key (which matches the private key the client
actually has). Only the evaluation of trust in the client-certificate
changes. At this stage, whether the client certificate is self-signed or
signed by another party isn't particularly important, since it's not
what's used to verify its content.
There are two ways of verifying the certificate in FOAF+SSL, and the
security offerings are significantly different: dereferencing and
Dereferencing is the main method explained on Henry's blog . (I
should point out that Henry's use of "web of trust" is more about how
individuals link to each other in a social network and doesn't
necessarily involve signing those assertions, as in OpenPGP, which makes
it somewhat different from a "cryptographic" web of trust).
It works as follows:
1. The client presents a certificate (self-signed or not) that
contains a URI (such as <https://romeo.example/#me>, a foaf:Agent), and
a public key.
2. The server dereferences this URI (i.e. does an HTTP GET) and
processes the content of the document, which will contain a public key
associated to this URI.
3. If the public key in the dereferenced document for this URI and
the public key in the client certificate match, then the verification is
The security of this verification model depends on how much the
authenticating server can trust the authenticity of document that was
obtained by dereferencing the URI. In particular, it must trust the
server certificate of 'romeo.example' and the fact that no one tampered
with the file on that server.
This level of security is suitable for some applications, but probably
B. Cryptographic web of trust
I've talked a bit more about this on my own blog . It's possible to
sign sub-graphs asserting the links between an ID (the URI) and a public
This way, one could have a set of trust anchors under the form of a
local/trusted FOAF file (or something else) against which to evaluate a
certificate (à la OpenPGP). Similarly, a hierarchical model could be
built. The level of assurance here depends on how much you trust the
trust anchors and potential introducers; it's likely to be greater than
with the dereferencing method.
The security levels are quite flexible, and systems using FOAF+SSL for
authentication and authorisation ought to be configured according to the
requirements of the application (like any system, I suppose). When we
say that FOAF+SSL is a secure protocol, we really ought to qualify that
The advantage of the FOAF+SSL approach (putting the information in an
X.509 certificate as opposed to creating another type of certificate) is
that this works without modifying the implementation of SSL/TLS stacks.
The only changes required are in the customisation of the evaluation of
trust in a client certificate.
This requires some specific configuration in the application, but no
changes of the SSL-related libraries themselves if they have such hooks
(JSSE and OpenSSL work, at least). In fact, for development purposes,
we've accept any certificate during the handshake and do the
verification at the application level.
The original questions that Henry sent were related to the way the
browser chooses a certificate (or asks the user to choose). Because the
FOAF+SSL certificate is self-signed, the server has to be configured
with an empty list of CAs in the CertificateRequest. This is the same
problem as the one addressed in Section 3.4 of RFC 5081 .
To make the choice of certificate easier in the browser, we had thought
of having an "open CA", for which we would distribute the private key
openly, just for the sake of making the servers add that CA in the
CertificateRequest list. I've since realised that we don't really need
that, since only the name matters: we could just make the server ask for
a conventional name and the self-signed client certificate would have
that issuer name . Of course, this wouldn't be compliant with RFC
We would be interested in feedback regarding this approach, in
particular whether this would break with further versions of TLS.
More information about the foaf-protocols