Re: white paper of proposed architecture for NSTIC

On 20 Jul 2011, at 10:48, Mo McRoberts wrote:

> Hi Francisco,
> 
> Thanks for forwarding this paper to the list, it certainly made interesting reading.
> 
> I haven't given it a thorough reading yet, but a couple of thoughts sprang to mind while skipping through it.
> 
> 1. I absolutely agree that some means by which application-layer code can signal to a UA the end of a session is going to need to be high on the list of priorities — and I think this is increasingly going to apply irrespective of whether identity systems are PKI-based or otherwise. Certainly in SSL/TLS-land, it's very hit and miss.
> 
> 2. I'd be wary of building a system whereby authentication tokens (i.e., client certificates) are issued in a centralised fashion — I'm increasingly becoming convinced that conflating the “identification” and “assurance” functions of an identity system is a fool’s errand, and that it would be wise to decouple them — in other words, I can use _any_ valid X.509 certificate to identify myself, but assurance information (such as institutions that I belong to, for example) while separate, is cryptographically associated (e.g., by way of a signature and countersignature). Separating the identification from the assurance data might also remove the need to extend TLS itself?
> 
> 3. Broadly speaking, the reason that PKI-based identity systems haven't taken off to date, despite their ubiquity, has little to do with their inability to fulfil a technical purpose and more to do with the fact that the user experience of doing -anything- PKI-based outside of a corporate environment (and often inside one) is consistently confusing and unpleasant for ordinary users, and I'm including the problems of key management in amongst that.
> 
> My gut feeling (and please don’t take this as a criticism of the paper — it's a more general comment) is that if a PKI-based identification system can be shown to be workable by real people in ordinary contexts (e.g., with extensions to browsers to aid key management and transport, identity selection, and so forth), then it's very easy to envisage a world in which strong crypto is used as the basis for identity on the Web, and that would be a very very good thing indeed. Without solving those problems, proposals based upon PKI and the like do very much seem like building the Eiffel Tower on sand: it's a nice design, but the foundations are seriously problematic.

So in response to Mo here, more than to Francisco.

I disagree that the foundations are seriously problematic. Well at least not the technical foundations. It is the mental foundations of the people using the PKI technology. In the PKI world we are in pre-galilean times. People think the world is flat still. They think PKI has to be centralised or an oligopoly. In fact the world is round, and PKI can work in a centralised way - without changing the framework. (Galileo did not make the world round!) In fact that is what http://webid.info/ shows. The false dichotomies can all be overcome with a change of mindset:
 
- One can have both PKI and decentralisation. 
- One does not need to keep hold of ones keys forever
- It is easy to create keys - 1 click of a button
- It is easy to invalidate them - remove them from a profile
- It all works in the browser already

Really all the browser people need to do is work on the UI.

This does not mean that one can't improve the TLS stack which is I think what the NSTIC 
paper is aiming to do (and I look forward to reading that), and what DNSsec and IETF Dane will 
bring about indirectly too.

But the point is rather that you really can't base anything on the so called common "wisdom"
about PKI. We are in exactly the same position where we were before AJAX where the wisdom was
that web pages had to be static, even though all the tools were already there in the browser
to make it false - it just took some marketing and good demos to change things.

What is certain is that decentralisation is key. Kalya Hamlin (identity woman) told me a nice story in Berlin.
The internet she said was a cooperative work between the army, hippies and commerce. When all
those three communities are satisfied then things will work.

So Identity has to be secure (army) and social (hippy) and permit businesses (which are just special
forms of communities) to work together. It has to be decentralised so that

 - the army can be confident that there is no easy to destroy center of control
 - the hippies can work together towards a better in privacy world without the cold and often dull hand of government killing the baby, or the short termism of buisness selling it off to the highest bidder
 - business can work together whilst protecting the confidentiality of their clients, their partners and in order to keep a competitive advantage

  Now WebId does permits the secure TLS infrastructure - developed for commerce - to be decentralised, and so allow us hippies to be happy. Though it does not give one perfectly anonymous identity - which may just be because that is a logical contradiction - it is a lot better than what might happen if suddenly millions of people were to find themselves using one big centralised database of information showing all the relations between all the people...

  Henry


> 
> M.
> 
> -- 
> Mo McRoberts - Data Analyst - Digital Public Space,
> Zone 1.08, BBC Scotland, 40 Pacific Drive, Glasgow G51 1DA,
> Room 7066, BBC Television Centre, London W12 7RJ,
> 0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A
> 
> 
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> 					
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 20 July 2011 10:08:25 UTC