[foaf-protocols] Signing browser certificates with WebId

Reto Bachmann-Gmür me at farewellutopia.com
Wed Sep 8 14:12:16 CEST 2010


On Tue, Sep 7, 2010 at 5:45 PM, Henry Story <henry.story at bblfish.net> wrote:

>
> On 7 Sep 2010, at 16:08, Reto Bachmann-Gmür wrote:
>
> > If we want to enable Web-of-trust features based on WebId it is import
> that an identity is associated to a small and relatively stable set of keys.
>
> You need to phrase that differently. As it stands that is wrong, since one
> can build a web of trust with very unstable keys. The web is formed by
> linking the URLs in a linked data pattern using vocabularies such as foaf.
>
> See:
>
> http://esw.w3.org/Foaf%2Bssl/FAQ#How_does_this_improve_over_X.509_or_GPG_Certificates.3F

This seems to assume 100% trust in the dereferenciation of the WebId
profiles, in reality they might be served over plain http, used with
self-signed certificate and TOFU-trust or be based on hierarchical services
(ca signed https) with the known risks.


> > However, as creation of key is cheap it is likely that user create keys
> quite often, for different devices as well as short-term keys for temporary
> machines. In such a scenario a web-of-trust referencing to individual keys
> is hard to build and the possibilities to establish trust using mechanism
> such as  provided by Perspectives [1] are limited.
>
> So this is more an issue of re-inforcing trust.
>
not sure what you mean, accepting a webids is all about believing/trusting
the association between public key and WebId URI.


>
> > If the WebId would be associated to a long term certificate with which
> the individual browser certificates are signed. This would allow the
> creation of many short-term certificates for different clients while
> associating the WebId to a stable public-key.
>
> The idea sounds intriguing. But one would need a lot more detail to work
> out if this works.
>
> Some questions:
>
>  - what threat is this an answer to?
>
webid profiles are often served over insecure or not fully trustable
connections. we need thus other means such as perspectives, redundant
information or web-of-trust to establish trust in the key-id association.

>  - how does the long term public key answer that threat?
>
long term public keys can be shared over different meas, for instance we
could encourage people to do replicate the triples associating the webid of
their foaf:knows to the respective certs, this is only
realistically feasible if the key is reasonably stable.


>  - what changes to the protocol need to be made for this to work?
>
One approach would be to define that the identification agent goes up till
the topmost x509 certificate claiming the same WebId and from there back
down the chain till the first key that could be verified

Adding a relation for a long term public key is clearly not the problem.
>
I don't think that a new relation is needed, the identity proeprty can point
from a key to an agent disreagrding if the keypair is used for signing keys
of for other purposes.

>
> > I think the mechanism is relatively easy, the Identification agents would
> have to go up the chain of X509 certificate, at least as long as the cert
> claim the same WebId till the verification of one succeed. Not sure how much
> more complicated creation of certificate would get.
>
> Where would the private key of the long term public key be stored?

Most likely storage would be managed by the application providing/creating
the WebId profile. Which would also sign the browser certificates with it.


> Who would sign these certificates?
>
The long term keypair itself need not to be signed, trust in it is
established with the means as per the current spec and the possibilities of
web-of-trust and Perspectives.

Cheers,
reto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100908/db4ab192/attachment.htm 


More information about the foaf-protocols mailing list