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

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

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Wed, 15 Jun 2011 18:51:53 +0200
Message-ID: <4DF8E329.70108@telia.com>
To: Nico Williams <nico@cryptonector.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 2011-06-15 18:05, Nico Williams wrote:
> 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).

I meant something similar to what you outlined above but stuffed in
the *client* certificate.


> Nico
> --
Received on Wednesday, 15 June 2011 16:52:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:47 UTC