Subject: Re: [TLS] foaf+tls for distributed social networks - 2 questions

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 3 May 2009 19:26:07 +0300

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

By ignoring the rest I suppose that you don't sign the certificate,
and it is used merely as a container for the URI?

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

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

> There are two ways of verifying the certificate in FOAF+SSL, and the
> security offerings are significantly different: dereferencing and
> cryptographic web-of-trust.

So this is verification on whether the one sending the foaf url is the
one who claims to be?

> A. Dereferencing
>
> Dereferencing is the main method explained on Henry's blog [1][2]. (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
> successful.
> 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.

Ok, thus the whole security lies on the URI dereference by the server.
It's like having some central authorities to verify identities.

> This level of security is suitable for some applications, but probably not
> all.

What do you mean by level? Do you mean that this is of lower security level?

> B. Cryptographic web of trust
>
> I've talked a bit more about this on my own blog [3]. It's possible to sign
> sub-graphs asserting the links between an ID (the URI) and a public key.
> 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.

This really reminds me of openpgp. Why not use openpgp certificates
instead? As I see below that reason was to  able to work on current
infrastructure?

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

So I suppose that the security levels you are referring are the
openpgp web of trust verification parameters?

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

Clear.

> 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 [4].

I cannot help on that it is too browser specific and I don't think
there is a uniform way not even across different release versions of
the some client.

> 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 [5]. Of course, this wouldn't be compliant with RFC 5280 [6].

Why? Where does it contradict? I suppose that you mean to send a
common dummy CA DN name and all foaf certificates would be signed
using that DN. Sounds legal, since you are not deploying CA compliant
with PKIX.

> We would be interested in feedback regarding this approach, in particular
> whether this would break with further versions of TLS.

It is a hack, but since it plays with the rules it works and should
work in the future (TLS doesn't really care about the contents of the
certificates or how verification is being done).

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 3 May 2009 19:28:00 +0300

> Couldn't be just a cookie (if talking about http).

Please ignore this question. It is made clear by the text below that
you use the public key parameters. I just forgot to delete this part.

regards,
Nikos

---

From: Henry Story <[email-masked]>
Date: Sun, 03 May 2009 18:58:52 +0200

Hi Nikos,

   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:

http://bblfish.net/tmp/2009/05/spot2009_submission_15.pdf

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

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

Henry