(un)linkability - Re: Agenda: <keygen> being destroyed when we need it

One key here unmentioned philosophical difference between <keygen> + client certificate authentication ( be it X509 or JOSE ) and FIDO has to do with (un)linkability. FIDO believes that unlinkeability is a basic principle [1][2]. This seems to be an unstated premise between a lot of the arguments going on here [3].

As a result it is against the basic principles of FIDO that the same client certificate should be used across more than one web site,  as this would allow tracking via the public key by different actors.  As a result I'd be surprised if FIDO supported <keygen> and client side certificates in any form.

On the other hand it seems that FIDO cannot either be against the use of the same public key used across web sites: It just won't have this property of unlinkeability FIDO cares about. It would fit a lot of the
other aims of FIDO too: passwordless experience, ease of use, etc... 

That there are cases where linkeability is useful is clear from the fact that all uses I have seen of OAuth, OpenID ( protocols which tie into FIDO ) have been ones where one authenticates to a relying partyby linking one's account to an Identity Provider such as Facebook, Twitter, Google+, etc... Mozilla Persona uses an e-mail address in the JSON certificate format as a global identifier. As the large social networks have proven: people actually want to connect. Creating isolated identities on micro silos each with a small number of actors reduces the network effect and so the value of any single identity, whilst also increasing the duplication of information and the work to maintain the sites. The value of connected identities being larger people will in most cases give away when they find it useful a little connecting global identifier such as a web page, email, etc... etc... 

So client side certificates do provide linkeability across web sites ( different web sites could exchange information about who came to visit ), by using at the minimum the public key as a global identifier.
BUT this is mitigated by:

1) The user being able to choose to authenticate to a web site with a certificate
2)  The web site may only have information about the user that this user wishes to divulge ( by for example making only specific information about himself available on his web site to that "relying party" )

For many applications linkeability is vital to ensure privacy: one can't put all one's information in one web
site, there are just too many different types of applications for that.

 It seems that with FIDO for each web site a client reaches, it will have to create a new public private key, and then later if it wishes to also use a global linkeable identifier it wil need to go through an additional protocol to tie this new public key to yet the same identifier. This seems like a waste. Would it not be more efficient then to use the same public key tied to one identity in that case?

This seems to suggest that there is place for both. There are keys that one wishes to use only for one
web site, but there are also keys that one may wish to use across origins. This is where the keygen functionality ( which could be expanded and improved ) comes in.

Henry

Notes
--------

[1] FIDO makes a big deal of unlinkability. We find in the FIDO UAF Architectural Overview 
     https://fidoalliance.org/wp-content/uploads/html/fido-uaf-overview-v1.0-ps-20141208.html <https://fidoalliance.org/wp-content/uploads/html/fido-uaf-overview-v1.0-ps-20141208.html>

• "The UAF protocol generates unique asymmetric cryptographic key pairs on a per-device, per-user account, and per-relying party basis. Cryptographic keys used with different relying parties will not allow any one party to link all the actions to the same user, hence the unlinkability property of UAF."
• "UAF authenticators can only be identified by their attestation certificates on a production batch-level or on manufacturer- and device model-level. They cannot be identified individually. The UAF specifications require implementers to ship UAF authenticators with the same attestation certificate and private key in batches of 100,000 or more in order to provide unlinkability.


[2] Brad Hill at the "Web Cryptography Next Steps" w3c workshop is reported as saying
    http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html <http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/report.html> 

• "Users and servers want hardware-bound keys but users also want unlinkability, and FIDO has ways outside the browser to approach these problems."

Here we see how public keys are related to linkeability.

It is felt by people coming from this perspective that certificate authentication across sites creates linkability. If only because two different sites can see that someone authenticated with the same public key, which can be seen to act as a global cookie.

[3] the JS Crypto API only allows the keys to be seen by the same origin as the JS which created them, meaning that certificates cannot go further than that web site


> On 5 Sep 2015, at 02:43, Brad Hill <hillbrad@fb.com> wrote:
> 
> Optional features get marketed, but that doesn't make it any more accurate to claim that they are mandatory.
> 
> Many sites (and users) find it valuable to be able to connect to FIDO authenticator implementations outside the browser for a variety of reasons (key portability, hardware key protection, multi-factor authentication affordances) but it can be implemented completely inside the browser, just without these bells and whistles.  This is no different from say, the ability to implement client-certificates using a strictly browser-local certificate store vs. a government e-ID smart card with a device-class identifying OID and PIN.  And in that sense <keygen> is, in practice, no less dependent on software functions / entities outside the browser.  
> 
> If you want a universal solution for key management with no external dependencies, there is WebCrypto, which combines quite nicely with PKI.js for certificate issuance.  As soon as you need more than that, you're talking about "multiple entities".
> 
> From: "SULLIVAN, BRYAN L" <bs3131@att.com <mailto:bs3131@att.com>>
> Date: Friday, September 4, 2015 at 5:04 PM
> To: Bradley Hill <hillbrad@fb.com <mailto:hillbrad@fb.com>>, Harry Halpin <hhalpin@ibiblio.org <mailto:hhalpin@ibiblio.org>>, Tim Berners-Lee <timbl@w3.org <mailto:timbl@w3.org>>
> Cc: "www-tag@w3.org <mailto:www-tag@w3.org>" <www-tag@w3.org <mailto:www-tag@w3.org>>, daniel Appelquist <appelquist@gmail.com <mailto:appelquist@gmail.com>>, "Linss, Peter" <peter.linss@hp.com <mailto:peter.linss@hp.com>>, Wendy Setzer <wendy@seltzer.org <mailto:wendy@seltzer.org>>
> Subject: RE: Agenda: <keygen> being destroyed when we need it
> 
> By “multiple entities” I mean software functions outside the browser, not third parties (as in sites or OAuth providers etc), although those browser-external software functions are key AFAIK to the value proposition of FIDO’s UAF and U2F selling-points. Focusing only on the over-the-wire protocol, with device metadata (I guess this means fingerprinting source data), may provide some standalone value under FIDO but that is not (again, AFAICT) how the user experience of FIDO is primarily marketed.
>  
> Thanks,
> Bryan Sullivan | AT&T
>  
> From: Brad Hill [mailto:hillbrad@fb.com <mailto:hillbrad@fb.com>] 
> Sent: Friday, September 04, 2015 10:12 AM
> To: SULLIVAN, BRYAN L; Harry Halpin; Tim Berners-Lee
> Cc: www-tag@w3.org <mailto:www-tag@w3.org>; daniel Appelquist; Linss, Peter; Wendy Setzer
> Subject: Re: Agenda: <keygen> being destroyed when we need it
>  
> This is not true.  FIDO is origin-bound and point-to-point.  There are no third parties required – much less so than certificates in the general case.  I like to say that FIDO is "PKI without the I".
>  
> Biometrics, etc. are completely abstracted away from the on-the-wire protocol.  There is an ability with FIDO to provide device metadata, and to attest that metadata at key registration time with device-class certificates (shared among all devices of a given type to preserve anonymity) but those are strictly optional parts of the protocols.  
>  
> Browsers can very easily build a software-only, unattested FIDO authenticator to complement their password managers in just a few hundred lines of code, with absolutely no third parties involved.  I know because I've done it.
>  
> -Brad Hill
>  
> From: "SULLIVAN, BRYAN L"
> Date: Wednesday, September 2, 2015 at 4:03 PM
> To: Harry Halpin, Tim Berners-Lee
> Cc: "www-tag@w3.org <mailto:www-tag@w3.org>", daniel Appelquist, "Linss, Peter", Wendy Setzer
> Subject: RE: Agenda: <keygen> being destroyed when we need it
> Resent-From: <www-tag@w3.org <mailto:www-tag@w3.org>>
> Resent-Date: Wednesday, September 2, 2015 at 4:04 PM
>  
> Harry, <>
>  
> FIDO is not a replacement for keygen. It involves multiple entities including some device-native functions that perform key registration etc using biometrics and other options (even SIM-based trusted UIs). It’s a nice concept and is gaining traction, but does have dependencies on functions outside the browser, thus is not a universal solution for key management.
>  
> Keeping the keygen tag and functions fully supported by browsers (as a standalone capability) is a more broadly viable solution, and I would recommend it.
>  
> Thanks,
> Bryan Sullivan | AT&T
>  
> [snip a large thread]