XAuth critiques

[Breno de Medeiros]

On Wed, Jun 9, 2010 at 02:15, Ben Laurie <benl at google.com> wrote:
> On 8 June 2010 22:15, Breno de Medeiros <breno at google.com> wrote:
>> On Tue, Jun 8, 2010 at 12:09, Dan Brickley <danbri at danbri.org> wrote:
>>> On Tue, Jun 8, 2010 at 6:55 PM, Ben Laurie <benl at google.com> 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
>>> specs at lists.openid.net
>>> 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)