On 8 June 2010 22:15, Breno de Medeiros <[email protected]> wrote: > On Tue, Jun 8, 2010 at 12:09, Dan Brickley <[email protected]> wrote: >> On Tue, Jun 8, 2010 at 6:55 PM, Ben Laurie <[email protected]> wrote: >> >>> I would really like to see better support for client certificates in >>> browsers so that this became less clunky around the certificate management >>> aspects... >> >> What needs to happen to achieve this? >> >> Is the shape of the problem / solution broadly understood? Is this >> something that W3C could usefully act on, or just needs coding work >> from the browsers? How does it relate to the recent >> http://www.w3.org/TR/wsc-ui/ and http://www.w3.org/2006/WSC/ work at >> W3C? > > I don't think so. UI/UX requirements for certificates for wide > adoption in the web might include: > > 1. Allow TLS client certificates to be governed by same-domain > policies as cookies via some yet-to-be-defined certificate extension, > say SDE (for 'same domain extension') > 2. Support client certificates signed by a _unknown_ trust root to be > treated at the same level as PKI-signed client certificates when the > SDE restriction is present
I thought client certs in clients didn't care about trust roots (that's a server problem) > 3. Allow certificates to be set transparently and without user > interaction and be presented transparently and w/o user interaction > whenever a cookie would be allowed to do so _and_ the certificate is > restricted by SDE. > 4. Enforce that SDE-restricted certificates be installed for a single > browser session whenever browser policies (e.g., 'incognito' mode) map > persistent cookies to session cookies. > 5. Enable users to select that SDE-restricted certificates be removed > when they (or processes acting on their behalf) clear all cookies. > > This would make certificates viable as a single server authentication > mechanism, but not a distributed protocol such as OpenID. For this you > would additionally need support for a site to set a certificate > restricted to a pair of domains (the first would be that of the > issuing site, and an additional one), again transparently according to > rules 1-5 above. It would additionally be necessary to restrict that > behavior to only work when the second domain exposes some Flash-style > cross-domain-policy file. I'm not sure why - what harm would there be in presenting a client cert to a site that didn't want it? > > In addition, when OSes allow management of certificates using a TPM, > integration with the TPM should be transparent to the user as well > (according to rules 1-5 above). > > I believe Dan Boneh's security group at Stanford has made a proposal > for such an extension to Mozilla, but I am not aware of any > standardization effort in this area. Link? > > Pop quiz: > The current UI/UX exposed by browsers for certificate management is > <fill in the blank>. > > Hint: If you think you know the answer and if that answer you think > you know is not an offensive word, I suggest that you ask anyone in > charge of UX at a commercially successful consumer-traffic-driven > site. > >> >> Sorry for all the questions. I've heard "browser certificate support >> needs improving" countless times, maybe this is a good time to find >> out if the will is there to improve the situation... >> >> cheers, >> >> Dan >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
