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

On Thu, Sep 17, 2015 at 4:06 AM, Tim Berners-Lee <timbl@w3.org> wrote:

>
> Its good practice rather than rather blanket "what you say is irrelevant"
> to be instead constructive.
>

Except it is irrelevant, if, in the course of 200+ emails, those opposing
the removal of <keygen> have provided no new use cases or usages outside of
those documented on the original email.

If these arguments are restating the same arguments first captured - and
dismissed - then yes, the email is not only irrelevant, but contributing to
a growing stream of misinformed noise. That may seem harsh, but it is both
a fair and accurate statement.


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

I appreciate that you've divided this email in to "UI that the TAG
acknowledges is necessary" and "UI that the TAG would like to see". While
the role of the TAG in prescribing browser UI is fairly limited - working
to ensure specifications acknowledge the user's role in transactions - I
think we need to also acknowledge that the TAG has no role in designing
that UI.

It would seem a gross overstep of the TAG's remit to suggest that the TAG
must approve UI of browsers. While we've seen a questionable engagement of
that recently related to how user agents handle TLS, it's clear there's a
delicate line between acknowledging the UIs that exist in implementations
and dictating what UIs the TAG expects, with the latter being a sizable
overstep and not likely to be received well.


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

I'm pleased that TAG reached the same conclusion as implementers. It saves
us a lot of significantly more awkward discussions :)

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

I'm glad we've reached agreement on this basic mitigation.


The remainder of this request is questionably a TAG request, and seemingly
more of your personal request, given that the concepts and notions you're
proposing do not apply to the needs of client certificates in general, but
to specific use cases of WebID-TLS and the Semantic Web.

While this itself does not mean it's not a valid request, I do want to be
careful with how much of the TAG's imprimatur is given to the WebID use
cases for the remainder of this feature wishlist.


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

This is not a new feature request. While I cannot speak for other UAs, I
can say that the Chrome team has repeatedly evaluated this proposal,
believe it's only useful for one use case (WebID) and actively unnecessary
for the other use cases of <keygen>, and have no plans to implement these
suggestions, nor support others implementing them and contributing such
implementations to Chromium.


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

This is a reasonable request of UI, but it has been repeatedly decided that
we do not agree with the suggestions, nor are we supportive of that form of
interaction.

Unfortunately, there's nothing new in this request which has not been
endlessly debated on email with Henry and cohort and on the Chromium bug
tracker. Because there's no new information in here, this is why I feel
confident in decisively communicating that there is no intent to improve or
alter this UI, or, more importantly, alter the behaviour of our TLS client
certificate handling and session logic.


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

As I've explained to Henry numerous times, and captured on the bug, this is
based on an unsound technical foundation and misunderstanding of how both
the Web works and TLS works. Much like Graham's statements were based on an
unawareness of basic CSS and Javascript such as 'display:none' and
'form.submit()', and how they dramatically affect the conclusions,
suggestions for this feature are based on unawareness of how basic webpages
work from multi-origin requests, or on how TLS works with respect to
authentication.

I cannot emphasize enough that though this suggestion is being rejected
from a foundation of UI principles and whether or not it's reasonable to
request browsers to expose this UI surface, even if such a UI surface was
exposed, there is no consistent, meaningful technical way to implement what
you suggest, because the protocols and implementation conspire against you.

I'm not sure to the extent that it's meaningful to discuss the TLS protocol
bits. Alex Russell has already contributed to the understanding that there
are many resources in a page - iframes, images, script - and why such UI in
it's simplistic form is unimplementable, and it should hopefully be readily
apparent where in it's accurate phase, it's unworkable.

This conclusion is not meant to suggest that UI contributions are not
welcome. We're always welcoming feedback on the UI exposed to users and how
it fits to use cases. However, much of this e-mail is rehashing past
requests - indeed, this request goes nearly back 6 years, to
https://code.google.com/p/chromium/issues/detail?id=29784 . The lack of
traction of this bug alone should indicate the priority, but I've gone and
closed it to make sure it's clear the point of view is not just that "not
right now" but "no, we don't plan to change this". Hopefully you don't take
this as "What you say is irrelevant" on a blanket scope, but understand it
as an explanation for why this is nothing new that's requested, nor is it
any more viable. I also hope you can see from that long bug an honest
engagement to explore this space, but an ultimate rejection for the
conclusions on sound technical principles.

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

While I appreciate this contribution to the discussion, your conclusion is
not supported by any of the arguments made in the 200+ emails on this
topic. While I fully appreciate and acknowledge that user interaction
matters in considering the technical flow, it's equally important for
proponents of such interactions to realize the dynamics of user
interaction, and whether or not the user is empowered to make meaningful
choices. I hope you consider Brad Hill's contributions to this discussion
in public-webappsec in
https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0093.html ,
and the lessons learned from ActiveX.