[foaf-protocols] Fwd: XAuth critiques

[Story Henry]

On 9 Jun 2010, at 16:06, Breno de Medeiros wrote:

> General comment:
> 
> Without implementing same-domain restrictions on certificates,
> certificate management without user interaction is a privacy problem.

Yes, IF the browser sends the certificate without asking the user
OR the user cannot see what certificate the user is using in connection to a site.

> Certificate management with explicit user authorization/management is
> too heavy a UX, no matter how refined the browser implementation.

YES. If every time the cert expires you have to be asked again, it will be a nuisance.
But if the browser showed you what certificate you were logged in as, then you would
be able to change identity after having logged in at a time of your choosing.

> Restricting certificate usage to a single site or pair of sites might
> sufficiently mitigate privacy issues to eliminate the need to interact
> with the user for installation/presentation/removal of certificates.

Yes, but that is useless. Much better have a few certificates that can be used
for every site, as one chooses to.

> 
> TPM stands for trusted hardware (some platforms attempt to detect
> certificate installation and give the users additional prompts for
> whether to install the certificate in tamper-proof chip).

Yes, USB keys with tampber proof chips containing the private key would make the
whole user experience as easy as opening your car.

Henry


> 
> On Wed, Jun 9, 2010 at 03:48, Story Henry <henry.story at bblfish.net> wrote:
>> Hi Breno,
>> 
>> I don't quite understand your SSL/TLS improvement suggestions.
>> (I am moving this over to the foaf-protocols list for the moment, as we are very interested in such improvements, and would be happy to support them somehow)
>> 
>> On 9 Jun 2010, at 00:23, Story Henry wrote:
>>> Begin forwarded message:
>>> 
>>>> From: Breno de Medeiros <breno at google.com>
>>>>> [snip]
>>>> 
>>>> 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')
>> 
>> What is this TLS same domain problem?
>> 
>>>> 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
>> 
>> Also I don't quite understand this.
>> 
>>>> 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.
>> 
>> As long as the user knows what he is logged in as.
>> Could you vote for the following bug report:
>> 
>>   http://code.google.com/p/chromium/issues/detail?id=29784
>> 
>> 
>>>> 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.
>> 
>> yes, one should have cookies tied to SSL session identity, so that one could log in
>> as one user then login as another, and not have the two identities be tied
>> together via cookies.
>> 
>> Note that this does not quite solve all problems. The URLs themselves
>> could give away identity, especially if someone bookmarks one that contains
>> an identifying string. (On the other hand they would not know if this was not
>> just some intermediary agent that was following up on something)
>> 
>>>> 5. Enable users to select that SDE-restricted certificates be removed
>>>> when they (or processes acting on their behalf) clear all cookies.
>> 
>> that makes sense.
>> 
>>>> 
>>>> This would make certificates viable as a single server authentication
>>>> mechanism, but not a distributed protocol such as OpenID.
>> 
>> Breno, here I think you should look at foaf+ssl. We don't have problems
>> when using foaf+ssl logging into multiple servers. That is indeed the whole
>> benefit of it.
>> 
>> Again you will see that in action in the video on http://webid.myxwiki.org/
>> 
>> 
>>>> 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.
>> 
>> Again, I am not sure this is needed, once you bend your mind round to the foaf+ssl way of doing things.
>> 
>>>> 
>>>> 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).
>> 
>> Not sure what TPM is.
>> 
>>>> 
>>>> 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.
>>>> 
>>>> Pop quiz:
>>>> The current UI/UX exposed by browsers for certificate management is
>>>> <fill in the blank>.
>> 
>> that depends on the browser. Some browsers are a lot better.
>> See the comparisons:
>>  http://esw.w3.org/Foaf%2Bssl/Clients/CertSelection
>> 
>> Mozilla sucks the most.
>> 
>> 
>>>> 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.
>> 
>>>> 
>>>> --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
>>>> 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)