Re:

Hi Francisco,

On 20 Jul 2011, at 20:21, Francisco Corella wrote:

> I think what you are describing is similar to attribute
> certificates (RFC 5755).  There is a TLS extension for
> sending attribute certificates along with a client
> certificate (RFC 5878).  (I'm afraid we forgot to explain
> how attribute certificates fit into our proposed
> architecture, we'll have to add at the first revision.)

Actually, attribute certificates look pretty ideal — I wasn't familiar with them.

> In other cases you want something else.  Suppose you keep
> personal data in a personal data site, for the convenience
> of maintaining it one place, and that site issues you a
> certificate that you use to convey personal data to a
> relying party.  Then you want to present two separate
> certificates to the relying party: the one from the personal
> data site, which may or may not uniquely identify you, plus
> another one from the relying party itself that uniquely
> identifies you to the relying party.  If the personal data
> site goes out business and their certificate expire, you can
> still access your account at the relying party with the
> relying party's own certificate.

In that example, it sounds a lot like it would be more appropriate for the personal data site to issue you with an AC which you can pass on (along with your own, self-issued, certificate which you use to identify yourself to both the personal data site and to the relying party).

> Yes.  One thing that's particularly confusing and cumbersome
> is certificate issuance.  We propose automating that process
> by using TLS to issue certificates, not just present them.
> I do realize that's a very big change, but I think it makes
> sense.

I don't think sites should be issuing certs at -all-, to be honest (outside perhaps of institutional environments where they're not already being delivered via managed desktops, for example).

What I'm envisaging is along the lines of…

* Everybody has a long term self-signed CA cert, looked after primarily by OS (or in some cases browser)-level tools — along the lines of a “Mac OS X Keychain or GNOME Keyring on steroids”

* The long term CA is used to issue shorter-lifetime browser and device certificates, which includes an attribute to indicate that the issuer pubkey is the “real” identity of the user

* Well-defined protocols (both “human” protocols and wire protocols) for shifting certificates between devices

* The shorter-life certificates could contain subjectAltName URIs (to be WebID-friendly) or tie in with BrowserID, or whatever

* The certificates are specifically _not_ assurance documents: information contained within them is no more trustworthy than anything a user types into a web form — for identification/authentication purposes, it's the key which matters; the DN of the cert is purely for the ease of user interfaces/cert selection.

* Attribute certs (of some description, be they X.509 ACs or something else) contain assurance assertions, taking the form of a blob of data in some form or another for the assertion itself, plus a timestamp and at least the pubkey of the user and along with the signature of the whole lot by the assurer — the ACs can range from simple confirmation that somebody belongs to an institution, or has achieved a particular qualification (formal or otherwise), holds a certain bank account or passport, or whatever.

* The assurers will typically use specific hierarchies for the certificates associated with the keys they use to sign the assurance documents; many of the assurers will be regulated or semi-regulated entities (such as academia, banks, government institutions), and RPs needing the assurance documents are today generally happy to accept proof documents from any entity who is licensed/approved/whatever to operate in that space — e.g., if I'm attempting to access something only available to academic users in the UK, the RP isn't likely to maintain a list of all of the academic institutions in the UK, although it has the opportunity to be more specific if needed.

* The ACs would of course contain something which identifies the class of document — be it an OID, a UUID, a URI, or whatever, which aids in selection interfaces (there's no point in me submitting a digital birth certificate where the RP needs a bank statement).

* RPs can apply whatever rules they need to when requesting assurance information, just as they do in the real world today, including (but not limited to) requiring assurance documents produced within a certain timeframe (e.g., last three months).

* The ACs could, of course, include a revocation URI

* Browsers would then be extended to:—

a) Have a notion of “current identity”, permanently displayed alongside, say, the address bar: this would would allow selection (via a drop-down, for example) of the short-lived cert that's included in requests. “None” would be an option here…

b) Support an <input type="assurance">, or something along those lines

Now, I'll readily admit that there are big gaps in this picture (such as how revocation of user certs can be distributed effectively), and although none of it is particularly earth-shattering it *does* require a lot of work and coordination in order for it to happen, and I'm not completely sure where to start beyond prototyping and attempting to show feasibility (more on that later on).

The key benefits to a scheme along these lines are:

* Provides a cryptographically strong identity for each user (i.e., the pubkey from the long-term cert)

* Allows a degree of transience between devices and browsers

* Minimises negative impact of inadvertently passing credentials to a rogue site (because the actual credentials don't reveal very much)

* Doesn't attempt to “solve” both the identification and assurance problems in a single step as classical ID schemes have tended to attempt, with all of the centralisation problems that arise — instead, maintains the current real-world assurance model, but supports others being developed in the future

* Moves client certificate loss to be a similar level of annoyance 

> Maybe now is the time to solve the problems :-)

I'm *hoping* that some of my colleagues in Research & Development will be able to spare some resource to prototype and evaluate the feasibility on some of what I'm suggesting above, but it'll be a few months before I know whether that will happen or not (as we set out in our submission to the identity-on-the-Web workshop, the BBC definitely has an interest in ensuring digital identity has a solid foundation moving forward).

All the best,

Mo.

-- 
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.

Received on Thursday, 21 July 2011 10:31:21 UTC