On Wed, Jun 9, 2010 at 02:15, Ben Laurie <[email protected]> wrote: > 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)
I thought so too, just recording the fact here doesn't hurt. > >> 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? Feel a bit queasy about it. Possibly could be used to implement DoS? > >> >> 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? Personal communication is the only reference I have. > >> >> 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) >> > -- --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
