Linkeability, SO & certificates Re: (Pre-)Intent to Deprecate: <keygen> element and application/x-x509-*-cert MIME handling

Thanks Ryan for bringing up below what I think are the three underlying reasons 
for the move to deprecate <keygen> in html by relating in a very strong way:

1. Same Origin Policy to Linkability, 
2. Linkability to loss of Privacy, 
3. certificates to loss of Privacy

These are high level Architectural  statements, that need to be made explicit, as they affect many other groups in the web, so I am also CCing this to the TAG, and to the SAAG at the IETF as they are working on both TLS 3 and a number of client side certificate technologies.

What would be nice would be if we could have actual documents from the W3C and SAAG  that
clarified where these concepts actually are applicable and what the limitations of them are.

As background for people new to this thread, this follows up on a request by the HTML5 WG to deprecate <keygen> https://github.com/whatwg/html/issues/67 . The main discussion actually seems to be occuring on the blink-dev chrome list for some reason and it was brought up by Tim Berners Lee for discussion on the W3C TAG.

> On 11 Sep 2015, at 01:32, 'Ryan Sleevi' via blink-dev <blink-dev@chromium.org> wrote in an
> e-mail that is archived https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/y5R4Ky9KAQAJ
> 
>> On Thu, Sep 10, 2015 at 11:30 AM, <helpcrypto@gmail.com> wrote:
>> WebCrypto Discovery API should be able to find keys there too. ie: Firefox has to give access to NSS/softoken/pkcs11 and Chrome/IE to windows  keystore/keychain on OSX
> IE does not grant such access - it's never implemented <keygen>. The ActiveX object it does provide allows for full system modification, so that's hardly a good model.

What you mean is that it can add client certificates to the keystore, as implementations of <keygen> can, and have, right? It can't also launch programs in user or root mode, edit files, etc.... Because that's a bit what it sounds like when you say "full system modification". ( many people in the web thought the ActiveX idea  was not a good idea as it bound the web to particular binary implementations, nevertheless I suppose no serious security leaks persist with this feature, or else it would have been removed a long time ago, especially as Microsoft is keeping it for enterprise customers ). 

The major difference betweent the ActiveX control and keygen, is that the ActiveX control
requires JS to be used. (more of that below)

> 
> And there are zero plans for WebCrypto to do this (it's deliberately out of scope of the charter), and I/royal we remain opposed to on numerous grounds (security and privacy being foremost). The Same Origin Policy is a critical piece of the Web.

The Same Origin Policy has always been used with respect to JavaScript especially when JS from one origin then connects to other origins to get information.  As JS is non declarative and a turing complete language it is quite clear why these restrictions apply: The JS can actually do things in place of the user. It is procedural code, meaning that an extra agency is added to the web page.

On the other hand the web itself is built on Linkeability between pages from different origins: that is what makes the web the web. This form of linkeability comes historically and conceptually before the non linkeability of JS. So linkeability is more essential to the web than JS non linkeability.

As a result non linkeability and same origin policy cannot be invoked without careful attention to the circumstances in which they apply.

What is the difference between the two? The declarative nature of the web-without-JS means that most of the actions in the web remain under the user control. What the User Agent (UA) does is on the whole very limited: it fetches and displays documents. It is up to the user to decide which link she clicks, what he bookmarks, what forms he submits, what document she saves to her local file system. When you add JS to the mix, you add the agency of the JS to the mix, which can now also now follow links, click form elements, etc... So instead of 2 agents ( the UA and the user ) you suddenly have n agents to deal with: the User, the UA,  the JS agent for each of n-2 origins ( and here it is clear that bunching all the JS on one origin together gives a really vague concept of code identity ).

As it happens the <keygen> element that is being put up for deprecation is part of the html-non-JS web, and works on clients that have JS disabled. 
Client certificate authentication as used by TLS is also declarative: the browser chrome gives the (human) user the ability to choose what certificate to use, and to cancel the authentication request if desired.
In none of these cases is the user out of control ( in a privacy respecting browser - and more can be done in many browsers to improve the user control ).

There is no reason that this TLS client certificate authentication feature can't be improved to work better with HTTP2.0 aka SPDY see the HTTP WG thread:
 • starting: https://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0558.html
 • most recent: https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0310.html

> 
> BTW: couple of questions about FIDO:
> 
> - If I create keys for foo.com using a U2F compliant USB device (yubikey) on my PC and then I want to login using my mobile...shall I generate another keypair? can't I use one for all? (reverse question may apply)
> 
> Yes. https://fidoalliance.org/wp-content/uploads/html/fido-appid-and-facets-v1.0-ps-20141208.html
> 
> - could a FIDO key be used for many domains (like eID, allowing me to auth/sign on different domains)
> 
> No. And it's the fact that it explicitly lacks that property that makes FIDO viable for the Web, without being a security (due to forgery of shared-key attacks) or privacy (due to linkability) nightmare. 

What is the forgery of shared-key attacks? ( a detailed pointer would be nice ) 
Is that due to the MD5 weakness in the  Signed Public Key and Challenge ( SPKAC ) format used by <keygen> at present, which allows the UA's keychain to sign the public key with the private key, allowing the server to verify  that the certificate request comes from an agent that is actually in possession of the private key? I tried to consider what could
be done with such an attack in the thread
  https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/dn_7RguGAAAJ
As far as we can see not that much can be done with it, especially if one considers how
certificates are actually used. 

But of course it is easy to imagine improving keygen so that this weakness does not arise, for example by extending it with 

<keygen keytype="rsa" signature="sha1 sha2" signedpk="jose">

JOSE is a format that is being developed by the IETF https://tools.ietf.org/wg/jose/
and so are X509 Certificates.

Given that it is so easy to see how keygen could be extended to allow for different certificate formats to be used, your argument cannot be that it is just X509 that is
problematic, but that any certificate format is a privacy problem.

If so this needs to be brought to the attention of the IETF SAAG, as they are investing
time working on this.

As you have been singing the praises of the FIDO alliance spec, I'd like to note that it is difficult to see how FIDO actually would work without certificates. It requires them for TLS verification of servers.

Also as OpenID, OAuth and SAML which are designed to fit on top of FIDO as seen here

https://fidoalliance.org/wp-content/uploads/html/fido-uaf-overview-v1.0-ps-20141208.html#relationship-to-other-technologies

require some form globally known relation between public key and global identifier to be available. Otherwise how would attribute exchange work? If the Relying Party has no way to
know who the Identity provider is, why should it even trust the Identity Provider? 

So Server Certificates are good, but client certificates are bad aparently. What is the principled argument that allows one to make this distinction?

Henry


Social Web Architect
http://bblfish.net/

Received on Friday, 11 September 2015 10:45:13 UTC