Re: Developer repositories for Debian
Hi.
Sorry to be a bit late in the discussion.
Russ Allbery <rra@debian.org> writes:
>
> I'd never heard of WebID before this thread, but looking briefly at the
> spec, I share Daniel's concerns. I don't see how this eliminates reliance
> on the normal CAs. You still have to do certificate validation to be able
> to trust the link between URL and keypair, and the WebID protocol provides
> no way to do that certificate validation other than the normal CA process
> (and doesn't provide any alternative CA).
>
I'm not sure I understand all aspects of the recent evolutions of the
WebID auth protocols nor the big picture, but my understanding is that
to auth to a server using a WebID (i.e. a URI pointing to a RDF document
which declares a SSL cert public key), all that is required is that the
connecting client owns the corresponding private key.
This can be a locally generated cert, most likely in the user's browser
cert, that has not been signed by any CA.
It could also be a cert generated by a CA and imported in that browser's
store.
So there's in principle no need for CAs in WebID Auth.
But of course, when you need to trust that cert for granting
authorization after this authentication, there comes the need for
signatures, etc. and maybe CAs could come into play.
> If you're going to trust the normal CAs anyway, all that WebID is really
> giving you is the ability to add additional metadata to the user's public
> certificate by publishing it at a linked URL; you're still trusting the
> public CAs implicitly to verify that user's certificate.
I'd say that the benefit of the (FOAF) meta-data that can be loaded at
the URI pointed to by the WebID is that there can be many things there,
like mention of a GPG public key, elements of signature to "assert" that
the WebID document is indeed "owned" by the owner both of the SSL cert,
a certain GPG key, and maybe some endorsement by CAs and or peers (WoT
signatures, etc.)
So I'd say that CAs may or not participate in stating (through signature
of the user's cert, or his her FOAF document ?) whether the SSL client
cert is actually owned by whoever tries to auth.
My understanding is that it could be pretty easy to check that the FOAF
document of a WebID is actually signed by the GPG key of a Debian dev
(maybe as it has been submitted to our servers in attachment of a signed
mail) and then from that point on, we could trust the asociated SSL
cert, whatever signatures it may have... but maybe that's a flawed trust
chain ?
>
> Furthermore, you're not even using a direct CA signature, but rather are
> using the server certificate of the web server the user gives you in the
> URL to validate that their *client* certificate is owned by them. I
> haven't fully thought through the implications of that, but at first
> glance it strikes me as a repurposing of authentication data in a way that
> isn't theoretically sound.
>
I'm not sure I understand the issue you're mentioning here.
My understanding is that a FOAF document of a user's WebID may be
accessible anywhere, and that URL isn't necessarily tied to where the
SSL cert has been created.
In principle, I can have "bought" a client cert from any cartel CA
(actually, made it signed by them) and use it in association to any URL
on a server supposedly under my control.
> WebID is trying to solve both the authentication problem and the
> distributed identity management problem.
As was mentioned in later responses, there are actually several aspects
of WebID, and IDentification and Authentication are actually being
standardized in a more separated way, AFAIU.
> Do we actually need the identity
> management functionality? If not, then the FOAF data isn't needed, and an
> X.509 certificate from a Debian CA that issues certificates based on
> GnuPG-signed requests would be sufficient for us to bootstrap our own
> X.509 infrastructure without all the additional complexity of WebID.
> (With the caveat, as mentioned previously, that we'd have to do some
> thinking about expiration times and revocation.)
>
I think there's some benefits of using FOAF to describe our project
members, which was the point of my original mention of WebID on
debian-project [0]. See also my experiment with webid.debian.net which
provides FOAF documents for Debian participants [1], which I announced
on debian-project@.
But given that we're also thinking about auth mechanisms, and those
FOAFs may be tied to SSL certs (in turn tied to our GPG WoT ?), then
this seems quite compatible... and maybe more than other solutions that
were mentioned, like OpenID or BrowserID.
I hope this helps, and I've not responded to a too early
message... sorry, but couldn't take the time to dig in the thread
earlier.
Will add a few more bits later in the thread too, most probably.
Best regards,
[0] http://lists.debian.org/debian-project/2013/02/msg00048.html
[1] http://wiki.debian.org/WebIDDebianNet
--
Olivier BERGER
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
Reply to: