W3C home > Mailing lists > Public > public-identity@w3.org > June 2011

Re: [websec] re-call for IETF http-auth BoF

From: Nico Williams <nico@cryptonector.com>
Date: Wed, 15 Jun 2011 11:05:58 -0500
Message-ID: <BANLkTi=gQQUw17SemHQ2bCqqDOiJOa38KA@mail.gmail.com>
To: Anders Rundgren <anders.rundgren@telia.com>
Cc: Yutaka OIWA <y.oiwa@aist.go.jp>, "KIHARA, Boku" <bkihara.l@gmail.com>, public-identity@w3.org, pgut001@cs.auckland.ac.nz
On Wed, Jun 15, 2011 at 10:22 AM, Anders Rundgren
<anders.rundgren@telia.com> wrote:
> W3C's WebID is a novel use of PKI that IMO gives OpenID a run for its money.

User certificates (not necessarily PKI, since they might be rp-only
certs) can work for authenticating users to servers.  But PKI alone is
pretty poor for authenticating services to users.

One way to add mutual authentication based on the existing PKI would
be to have an out-of-band way to validate that a server's cert is what
it used to be, and to detect legitimate cert/key rollovers.  I'm
thinking of a service hosted by the browser or local TLS/PKI code
infrastructure, or an IdP-like remote service.  Basically, cert
pinning with a leap-of-faith cert learning method in the local case,
but also with a federated whitelist facility as well (in the IdP
case).

And user certs and private keys could even be obtained remotely (via
SACRED), ephemeral keys could get certified on a short-term basis
(short-lived certs) by an online CA with (similar to SACRED).

This approach retains all the downsides of doing user authentication
at such a low layer.  But it has the big advantage that the TLS bits
are already in place, and that the rest could be added piecemeal.

> Regarding mutual authentication, it would be piece of cake adding an X.509
> extension containing sites/domains that the issuer grants usage with.

AFAICT, adding extensions to PKIX is never a piece of cake.  And
anyways, there's already naming constraints for PKIX (if that's what
you meant).

Nico
--
Received on Wednesday, 15 June 2011 16:06:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 June 2011 16:06:23 GMT