[foaf-protocols] Fwd: XAuth critiques

Wed Jun 9 11:54:36 CEST 2010

Hi Nathan

Nathan wrote:
> personal opinion:
> 
> standardisation of whether certificate storage is delegated by the 
> browser to the OS certificate store (like chrome and ie) or handled by 
> the browser (like all the others) - I'd like to see it one or the other.

as long as you have a standard API for accessing the certificate it does
not matter where it is stored, does it?

> 
> choice of which certificate to present should always be left up to the 
> user, unless they have specifically requested to always send X 
> certificate to Y domain (I don't want my webid and thus my foaf 
> (identity) details handed out without me knowing).

agreed. Also, even if you have set up an "always use this cert" rule,
you should be able to change it at any time.

> 
> regardless of any UI/UX synchronisation amongst vendors, standardisation 
> of which certificate details are presented to the user when selecting a 
> certificate would be brilliant.

I dont see how you can standardise this. The cert contents are already
standardised, but suppliers are free to display any info in any way they
want to. So I dont buy this one.

> 
> ideally, self signed personal certificates treated the same as personal 
> certificates with a trusted chain

this is a nonsense. You should never equate self asserted information
with information validated by a trusted third party.

However, Verisign Class 1 certs are almost equivalent to self asserted
certs since Verisign check nothing except the email address. So,
excluding the email address, these certs are self asserted ones.

So there is no escaping from the fact that relying party have to know
which CAs are trustworthy, and to what level.

regards

David

  - odds of this I don't know, on
> windows for instance that would mean an MS certificate store change 
> which even if implemented would take years to filter through.
> 
> just some thoughts,
> 
> Nathan
> 
> Story Henry wrote:
>> On the OpenId mailing lists a discussion as to their relation to 
>> oauth/xauth is
>> taking place. I have entered the conversation, and Dan Brickley 
>> cleverly put the question
>> below, regarding what needs to be improved with browser certificates. 
>> The answer
>> clearly does not take foaf+ssl into account, but it gives a good view 
>> of what the common understanding of the problems with client certs are.
>>
>> We should analyse these points in detail, and see which of these 
>> issues we agree do need improving.
>>
>> Henry
>>
>> Begin forwarded message:
>>
>>> From: Breno de Medeiros <breno at google.com>
>>> Date: 8 June 2010 23:15:21 CEST
>>> To: Dan Brickley <danbri at danbri.org>
>>> Cc: "openid-specs at lists.openid.net" <openid-specs at lists.openid.net>
>>> Subject: Re: XAuth critiques
>>>
>>> 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
>>> 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.
>>>
>>> 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.
>>>
>>> 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)
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>
>>
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************