Client Cert operationstions and UI Was: Same Origin Policy - Re: Agenda: <keygen>

On 2015-09 -16, at 12:20, Ryan Sleevi <sleevi@google.com> wrote:

> 
> 
> On Wed, Sep 16, 2015 at 3:08 AM, Graham Leggett <minfrin@sharp.fm> wrote:
> On 15 Sep 2015, at 11:29 AM, Ryan Sleevi <sleevi@google.com> wrote:
> > Go to a site with a <keygen> tag in Safari or Chrome. See that it inserts a key in your (OS) key store.
> 
> That’s not how keygen works. The keygen tag has to be part of a form, and renders a visible indication of the key size.
> 
> https://drafts.csswg.org/css2/visuren.html#display-prop
>  
> The end user has to actively click on something before the key is generated.
> 
> https://html.spec.whatwg.org/multipage/forms.html#dom-form-submit
>  
> At the very least (Firefox) you have to explicit submit a form to generate a key. At the most (Safari) you are explicitly prompted to choose a certificate before using that certificate to connect to a site.
> 
> You're mixing apples and oranges, and calling them steaks. What you describe in Firefox is <keygen> What you describe in Safari is irrelevant to <keygen> (no prompt) or application/x-x509-user-cert (no handling), but instead TLS client auth - which is not the topic either Kingsley and I are talking about. It's as relevant as the price of tea in China to the issues at hand.

Its good practice rather than rather blanket "what you say is irrelevant" to be instead constructive. 
You mean, perhaps that there are two phases in keygen and then other phases in selecting and canceling certs. Let me just elaborate the phases below.  I've changed the subject line.

1) Deciding to mint a key.  The TAG felt that browser IO would be good at this point to let the user know and go along with the start of the process

2) Getting the signed cert back to inclusion into the user's keys store.  The TAG felt it is critical at this point the user i asked whether it wanst to store it.  The user could also chose where to store the private key from (1) and the public key from (2).   Might be useful for the user to be able to chose a nickname for the key and have a link to "manage my keys".  You need a nickname for (3).   Storing the user cert should not be confused with storing a trusted server cert. Different language.  Talk about a "key", as the user has the private key to this one

3) When the key is used, the user is prompted (in Chrome, Safari, Firefox) for which client cert to use, even if they only have one.  That;s reasonable so long as the
- A current bug is that often the cert menu has a list of certs by name of the person, which is the same for all of them!   Like "Chose a cert: "Ryan Sleevi", "Ryan Sleevi", "Ryan Sleevi", "R. Sleevi", "Ryan Sleevi"?    The list should be bigger, take up much more real estate on the screen, and include the issuer, when it was minted in small letters, and ideally a user nickname to make it really easy.
- Once the user is using the key, in a TLS session, the short name (nickname, issuer, etc) of the cert should be shown in the URL bar at the right just as the iD of the server is shown at the left.   t is important to be able to check who you are authenticating as.
- The choice should be remembered.  Chrome and FF remember it for the session but not long term as they should.
- There must be UI in preferences to edit the list of sites which use each cert.

4) The rarer but important operation is to "logout" from the use of the cert.   An "x" to the right of the "your current ID" field in the URI above would do nicely and a check "Are you sure"?   Breaks the TLS session and will prompt for a cert choice when next the user connects. (Connects explicitly or using XHR from the current page, etc).

When specifying protocols like this, protocol engineers have traditionally felt that it was not their job to specify the UI, that that that was the job of the UI guys.    While the color may be left to the UI guys, some things about the UI process are actually crucial to the protocol.  like the fact that the ability to create and use a key pair is browser UI which cannot be faked by Javascript.      

Tim