What we were using public key authentication for

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

What we were using public key authentication for

Tim Berners-Lee
Virginie

You asked at the AC lunch for me to describe what it was that we had been using  public key authentication for.

This is the system we have been using for someone to be able to identify themselves as the owner of a web page, like a blog.

- A user of a web browser runs a web app A
- The web app uses data stored in various different web sites B (Like health data, bank data, calendar, etc)
- The user has a global ID which is an https: URI which points to public info about them (or a persona) like their blog
- The access control on the data stores is set to allow access referring to that ID string
- The user accesses the data from within the webapp by using a private key which is stored securely on the device (or hardware gadget)
- The user’s public key is accessible only though unfakable "browser chrome"
- The cert is NOT signed by anything — it can be self signed. (the trust is from the public key being on the web)
- The public web home page for the user lists the corresponding public key publicly
- The client cert does contain the global ID URL

The essential characteristics of the system which the browser architecture seems to fight against:

- The whole point is to be have a public identity (like your W3C or github id) which can be to show you are the same person on multiple sites
- It isn’t just about logging onto different we sites, it is about accessing the same data you own on many sites B from many different sites A
- The signature on the cert is not part of the system, so the keychain won’t recognize the cert as “trusted”.  This does NOT use the PKI

We have been doing this using client certs, but the UI was unloved, the  keygen API weird and had bugs, browsers have had a war against client certs.  But the system worked!   Until keygen got turned off in Chrome and Firefox  a few days ago.

So can we get this functionality using web crypto in the short term?

Suppose we
1) generate the keys in a web app using web crypo, store them in ephemal strage, and rejenerate them any time the use clears the key storage. Use them in a custom HTML form based auth session with the server in which we invent our own PK based authentication protocol.

2) genearte the keys using math, possibly web cryto with “exportable” keys, and download a .pem file to the user’s desktop.  Get the user to click on the .pem and go through the process of installing the cert on their site. Hope fingers crossed the browsers don’t just block the use of client certs at all!

3) Switch the while thing over to use openID-connect to connect people to some password-protected site?

If the Fido system will give us all we need by the end of this/next year, that will be great, but we need something now we can improvise say using  web crypto and JS.  

Best

Tim




Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Harry Halpin


On Wed, Mar 23, 2016 at 6:08 PM, Tim Berners-Lee <[hidden email]> wrote:
Virginie

You asked at the AC lunch for me to describe what it was that we had been using  public key authentication for.

This is the system we have been using for someone to be able to identify themselves as the owner of a web page, like a blog.

- A user of a web browser runs a web app A
- The web app uses data stored in various different web sites B (Like health data, bank data, calendar, etc)
- The user has a global ID which is an https: URI which points to public info about them (or a persona) like their blog
- The access control on the data stores is set to allow access referring to that ID string
- The user accesses the data from within the webapp by using a private key which is stored securely on the device (or hardware gadget)
- The user’s public key is accessible only though unfakable "browser chrome"
- The cert is NOT signed by anything — it can be self signed. (the trust is from the public key being on the web)
- The public web home page for the user lists the corresponding public key publicly
- The client cert does contain the global ID URL

The essential characteristics of the system which the browser architecture seems to fight against:

- The whole point is to be have a public identity (like your W3C or github id) which can be to show you are the same person on multiple sites
- It isn’t just about logging onto different we sites, it is about accessing the same data you own on many sites B from many different sites A
- The signature on the cert is not part of the system, so the keychain won’t recognize the cert as “trusted”.  This does NOT use the PKI

We have been doing this using client certs, but the UI was unloved, the  keygen API weird and had bugs, browsers have had a war against client certs.  But the system worked!   Until keygen got turned off in Chrome and Firefox  a few days ago.

So can we get this functionality using web crypto in the short term?


Here's my best guess!
 
Suppose we
1) generate the keys in a web app using web crypo, store them in ephemal strage, and rejenerate them any time the use clears the key storage. Use them in a custom HTML form based auth session with the server in which we invent our own PK based authentication protocol.

One way to prevent keys from destroyed if localStorage is cleared to 'wrap' long-term private keys with another per-session key and upload long-term (i.e. exportable) keys to your server and then download those keys from the server and unwrap when you need them. That long-term keypair could have a public key that you could then display on your URL w/i a WebID.

The main issue is you'd probably still want a keypair to wrap. To get per-session key, I'd use as a temporary measure like Secure Remote Password (SRP) and then upgrade to WebAuthn (FIDO 2.0) when it happens [1]. Another option is HOBA (no passwords) and it needs recoding in WebCrypto I think [2]


2) genearte the keys using math, possibly web cryto with “exportable” keys, and download a .pem file to the user’s desktop.  Get the user to click on the .pem and go through the process of installing the cert on their site. Hope fingers crossed the browsers don’t just block the use of client certs at all!


What would the self-signed cert get you that a key would not? It seems that localstorage vs. TLS keystore is the issue, where it's believed TLS keystore is much more secure? Would be a good thing for a security audit to investigate, such as iSec partners.

 

3) Switch the while thing over to use openID-connect to connect people to some password-protected site?

OAuth can be used to transfer information (such as data from your access-control). You would need to have your WebID hdata store be OAuth enabled as your 'identity provider.'

There's nothing preventing an OAuth provider (MIT CSAIL is also moving from certs to OpenID Connect) from working with a URI-based identifier (RDF) and shipping RDF-based data around. In fact, you could do all sorts of fancy stuff like encrypted the data by storing it in JSON-LD (I think you could do n3 as well likely if you normalized a bytestring via base64) in a JWT and signing using a JWS.
 

If the Fido system will give us all we need by the end of this/next year, that will be great, but we need something now we can improvise say using  web crypto and JS.



Best

Tim





Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Martin Thomson-3
In reply to this post by Tim Berners-Lee
On 24 March 2016 at 09:08, Tim Berners-Lee <[hidden email]> wrote:
> So can we get this functionality using web crypto in the short term?

The answer is yes, though it requires some work on the part of the
entity hosting the "user's public ID".  Other origins would have to
ask it for permission to read the identity (the public key), probably
using CORS, and they would also have to ask it (or a JS proxy it runs,
probably in a service worker, maybe with foreign fetch) to sign things
with that key to prove that the "user" really wants to authenticate.

UX here is the interesting part.  You could use notifications from the
SW to get users to interact with the ID-provider origin in order to
grant permission to authenticate and that sort of thing.  This looks a
like like OAuth, which isn't a coincidence.

And the browser is not involved.  Not fundamentally.  That the keys
are on the browser, and the browser only, is something between the
user and the ID-provider.  You might argue that's a bad thing, but
that's how I understand modern web identity to work.  Take away all
the fancy new stuff and fancy interfaces and you essentially have the
systems that all the big identity providers have been using for years.

Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Anders Rundgren-2
On 2016-03-24 06:58, Martin Thomson wrote:
> On 24 March 2016 at 09:08, Tim Berners-Lee <[hidden email]> wrote:
>> So can we get this functionality using web crypto in the short term?
>
> The answer is yes, though it requires some work on the part of the
> entity hosting the "user's public ID".  Other origins would have to
> ask it for permission to read the identity (the public key), probably
> using CORS, and they would also have to ask it (or a JS proxy it runs,
> probably in a service worker, maybe with foreign fetch) to sign things
> with that key to prove that the "user" really wants to authenticate.

Luckily for us users, both the payment industry and the eID networks have
found a faster a more user-friendly way to get things going which is using
mobile "Apps".


> UX here is the interesting part.  You could use notifications from the
> SW to get users to interact with the ID-provider origin in order to
> grant permission to authenticate and that sort of thing.  This looks a
> like like OAuth, which isn't a coincidence.
>
> And the browser is not involved.  Not fundamentally.  That the keys
> are on the browser, and the browser only, is something between the
> user and the ID-provider.  You might argue that's a bad thing, but
> that's how I understand modern web identity to work.  Take away all
> the fancy new stuff and fancy interfaces and you essentially have the
> systems that all the big identity providers have been using for years.

Yes, unfortunately this only works satisfactory if the number of IdPs for the
actual use case is very small which is not how things were envisioned during
the OpenID heydays.

Anyway, this is as I have written an already "solved" issue.  What's worse is
that there are new things on the W3C agenda that haven't been dealt with in a
constructive manner which most likely will cause major headaches in the future:
https://github.com/w3c/browser-payment-api/issues/50

Anders

Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Henry Story-4
In reply to this post by Harry Halpin

> On 24 Mar 2016, at 00:25, Harry Halpin <[hidden email]> wrote:
>
>
>
> On Wed, Mar 23, 2016 at 6:08 PM, Tim Berners-Lee <[hidden email]> wrote:
>
>> Virginie
>>
>> You asked at the AC lunch for me to describe what it was that we had been using  public key authentication for.
>>
>> This is the system we have been using for someone to be able to identify themselves as the owner of a web page, like a blog.
>>
>> - A user of a web browser runs a web app A
>> - The web app uses data stored in various different web sites B (Like health data, bank data, calendar, etc)
>> - The user has a global ID which is an https: URI which points to public info about them (or a persona) like their blog
>> - The access control on the data stores is set to allow access referring to that ID string
>> - The user accesses the data from within the webapp by using a private key which is stored securely on the device (or hardware gadget)
>> - The user’s public key is accessible only though unfakable "browser chrome"
>> - The cert is NOT signed by anything — it can be self signed. (the trust is from the public key being on the web)
>> - The public web home page for the user lists the corresponding public key publicly
>> - The client cert does contain the global ID URL
>>
>> The essential characteristics of the system which the browser architecture seems to fight against:
>>
>> - The whole point is to be have a public identity (like your W3C or github id) which can be to show you are the same person on multiple sites
>> - It isn’t just about logging onto different we sites, it is about accessing the same data you own on many sites B from many different sites A
>> - The signature on the cert is not part of the system, so the keychain won’t recognize the cert as “trusted”.  This does NOT use the PKI
>>
>> We have been doing this using client certs, but the UI was unloved, the  keygen API weird and had bugs, browsers have had a war against client certs.  But the system worked!   Until keygen got turned off in Chrome and Firefox  a few days ago.
>>
>> So can we get this functionality using web crypto in the short term?
>
> Here's my best guess!
>  
>
>> Suppose we
>> 1) generate the keys in a web app using web crypo, store them in ephemal strage, and rejenerate them any time the use clears the key storage. Use them in a custom HTML form based auth session with the server in which we invent our own PK based authentication protocol.
> One way to prevent keys from destroyed if localStorage is cleared to 'wrap' long-term private keys with another per-session key and upload long-term (i.e. exportable) keys to your server and then download those keys from the server and unwrap when you need them. That long-term keypair could have a public key that you could then display on your URL w/i a WebID.
>
> The main issue is you'd probably still want a keypair to wrap. To get per-session key, I'd use as a temporary measure like Secure Remote Password (SRP) and then upgrade to WebAuthn (FIDO 2.0) when it happens [1]. Another option is HOBA (no passwords) and it needs recoding in WebCrypto I think [2]

Tim forgot to mention another aspect of our use case, and that is that there will in the end be millions of applications hosted on many origins, that allow us to interact with various types of data, linked across the web. People would choose the application required for their task, tuned for their cultural background, designed for their accessbility needs, etc... Each of these apps come from a different origin, both because each app is built by different organisations, but also because app security is origin bound.

On your proposal a user would need to end up remembering a password for each application, in order to fetch the public/private key pair stored on each origin, which means that we are back to the useability problems of password maintenance and reliance on keychains. Also it seems like Hoba won't do as it relies itself on the WebCrypto API and so would suffer the same problem if the key storage were cleared.  The problem with symmetric keys (passwords) are well known, and that is why assymetric key crypto was such a groundbreaking invention.


>> 2) genearte the keys using math, possibly web cryto with “exportable” keys, and download a .pem file to the user’s desktop.  Get the user to click on the .pem and go through the process of installing the cert on their site. Hope fingers crossed the browsers don’t just block the use of client certs at all!
>
> What would the self-signed cert get you that a key would not? It seems that localstorage vs. TLS keystore is the issue, where it's believed TLS keystore is much more secure? Would be a good thing for a security audit to investigate, such as iSec partners.

The relevant difference is not one between TLS and non TLS stores, but rather between the ability to use public key cryptography across origins _with_ user consent.  Currently TLS client certificates as implemented in browsers enables public key cryptography authentication across origins with user consent supported by the browser chrome. And it is the only technology deployed in the browsers that does this.

The WebCrypto API:
 • does not have chrome support, and so the user has to trust the JS from an origin to correctly notify the user when authenticating across origins. So user consent is optional here. As a result the WebCrypto API actually allows applications to create super cookies, and authenticate the user across all origins without the user knowing about this. Still one cannot really fault the WebCrypto API for this, as it is easy for developers to roll their own crypto libraries, even without the WebCrypto API and do the same thing one way or another.
 • can only create a key per Application Origin, requiring therefore an extra method to tie identities together, so that an application that needs to view information generated by another application that should be visible to  the same user can do so. [Note 1]
   
[Note 1]: Even systems like FIDO which start with a philosophy of unlinkability have to acknowledge that even simple requirements of current web users requires linkability, and furthermore that they cannot stop this. See their documentation in the section "OpenID, SAML, and OAuth"
   https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-overview-v1.0-ps-20141208.html#relationship-to-other-technologies -

I actually think the WebCrypto API can be used in a good way to launch a more HTTP/2 friendly way to authenticate using HTTP Signatures
https://github.com/solid/solid-spec/issues/52

But I imagine TLS also has advantages otherwise why would Microsoft and Mozilla be working on TLS1.3 integration into HTTP/2
"Reactive Certificate-Based Client Authentication in HTTP/2"
https://tools.ietf.org/html/draft-thomson-http2-client-certs-01

My guess is that TLS allows one to proove point to point security, whereas HTTP-Signatures by itself, if it does not surface the TLS session in a header, does not allow one to guarantee that the packets were not viewed (and perhaps modified for chunked responses) by an
intermediary...

As they say in the WebCrypto API this is subtle. It needs to be discussed with care and in a cross disciplinary fashion, since we
are moving between cryptography, protocols, web architecture and user interface design.

>>  3) Switch the while thing over to use openID-connect to connect people to some password-protected site?

> OAuth can be used to transfer information (such as data from your access-control). You would need to have your WebID hdata store be OAuth enabled as your 'identity provider.'
>
> There's nothing preventing an OAuth provider (MIT CSAIL is also moving from certs to OpenID Connect) from working with a URI-based identifier (RDF) and shipping RDF-based data around. In fact, you could do all sorts of fancy stuff like encrypted the data by storing it in JSON-LD (I think you could do n3 as well likely if you normalized a bytestring via base64) in a JWT and signing using a JWS.

Can you describe your thinking in more detail. I am not sure what you mean by OAuth being used to transfer information. It seems to me that HTTP is much better suited to transfering linked data in whatever format.

We are of course quite aware that Web Access Control [note 2] can be used with different authentication schemes. Each resource could through a WWW-Authenticate header specify the types of authentication protocols they support, be it e-mail, one time password, OpenId, HTTP Signature or even with the proposed Reactive TLS-1.3 based authentication.  I have started looking into that with OAuth too [note 3].

What is needed then is to look at each of these protocols to analyse them in detail along a number of different dimensions.

Manu Sporny has actually started work on this:
  http://manu.sporny.org/2015/credentials-retrospective/

[Note 2] https://www.w3.org/wiki/WebAccessControl
[Note 3] https://github.com/solid/solid/issues/66

>  
>
> If the Fido system will give us all we need by the end of this/next year, that will be great, but we need something now we can improvise say using  web crypto and JS.
>
>
> [1] http://srp.stanford.edu/
> [2] https://hoba.ie/
>
>
>
> Best
>
> Tim
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Graham Leggett
In reply to this post by Tim Berners-Lee
On 24 Mar 2016, at 12:08 AM, Tim Berners-Lee <[hidden email]> wrote:

> This is the system we have been using for someone to be able to identify themselves as the owner of a web page, like a blog.

This is also the system used by my grandmother’s pension fund to secure systems internal to her pension fund. It is also the same system used by organisations such as the BBC across tens of thousands of people to secure their data in transit between layers in their systems. Keygen provides a secure vendor neutral and standards compliant way to get a digital certificate securely onto a machine.

Sure, my grandmother doesn’t know or care about certificates, but she sure cares about her pension fund.

> We have been doing this using client certs, but the UI was unloved, the  keygen API weird and had bugs, browsers have had a war against client certs.  But the system worked!   Until keygen got turned off in Chrome and Firefox  a few days ago.

Not only did the system work, the system of client certs is immune to man in the middle attacks.

With a certificate on both sides of the connection, if one side is compromised by a man in the middle (think hacked CA, mistrusted root, whatever), the security on the other side of the connection is still intact, and the connection will fail safe. Sure, Eve can pretend to be your bank, but Eve cannot pretend to be you, and so any attempt by Eve to try insert herself between you and your bank will fail.

Over at Apache httpd we care about existing users, and we go to significant lengths to ensure that none of our users are suddenly DoSed by changes made. If we want to change something we deprecate the old, and ensure that something new exists to replace the old before removing it so our users aren’t left suddenly in the lurch. In contrast, Firefox and Chrome have arbitrarily ripped the carpet out from users without warning in a systematic attempt to remove strong crypto from the browser ecosystem, which in contrast to the Apache approach represents a significant lack of project maturity and governance.

The browser is seeing the erosion of an important security feature, and we should be concerned by this.

> So can we get this functionality using web crypto in the short term?
>
> Suppose we
> 1) generate the keys in a web app using web crypo, store them in ephemal strage, and rejenerate them any time the use clears the key storage. Use them in a custom HTML form based auth session with the server in which we invent our own PK based authentication protocol.

How do I know my browser generated the key, and that the key wasn’t given to me by someone else? Without reverse engineering the javascript code I was given to run I can’t, and as such web crypto offers no security guarantees to the end user.

> 2) genearte the keys using math, possibly web cryto with “exportable” keys, and download a .pem file to the user’s desktop.  Get the user to click on the .pem and go through the process of installing the cert on their site. Hope fingers crossed the browsers don’t just block the use of client certs at all!

Again, if I don’t know for sure I generated the key, then there is no security for me.

> 3) Switch the while thing over to use openID-connect to connect people to some password-protected site?

This relies solely on trust of the PKI. If I compromise any CA you trust, I can help myself to your identity at will.

Regards,
Graham



Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Melvin Carvalho


On 24 March 2016 at 12:49, Graham Leggett <[hidden email]> wrote:
On 24 Mar 2016, at 12:08 AM, Tim Berners-Lee <[hidden email]> wrote:

> This is the system we have been using for someone to be able to identify themselves as the owner of a web page, like a blog.

This is also the system used by my grandmother’s pension fund to secure systems internal to her pension fund. It is also the same system used by organisations such as the BBC across tens of thousands of people to secure their data in transit between layers in their systems. Keygen provides a secure vendor neutral and standards compliant way to get a digital certificate securely onto a machine.

Sure, my grandmother doesn’t know or care about certificates, but she sure cares about her pension fund.

> We have been doing this using client certs, but the UI was unloved, the  keygen API weird and had bugs, browsers have had a war against client certs.  But the system worked!   Until keygen got turned off in Chrome and Firefox  a few days ago.

Not only did the system work, the system of client certs is immune to man in the middle attacks.

With a certificate on both sides of the connection, if one side is compromised by a man in the middle (think hacked CA, mistrusted root, whatever), the security on the other side of the connection is still intact, and the connection will fail safe. Sure, Eve can pretend to be your bank, but Eve cannot pretend to be you, and so any attempt by Eve to try insert herself between you and your bank will fail.

Over at Apache httpd we care about existing users, and we go to significant lengths to ensure that none of our users are suddenly DoSed by changes made. If we want to change something we deprecate the old, and ensure that something new exists to replace the old before removing it so our users aren’t left suddenly in the lurch. In contrast, Firefox and Chrome have arbitrarily ripped the carpet out from users without warning in a systematic attempt to remove strong crypto from the browser ecosystem, which in contrast to the Apache approach represents a significant lack of project maturity and governance.

The browser is seeing the erosion of an important security feature, and we should be concerned by this.

> So can we get this functionality using web crypto in the short term?
>
> Suppose we
> 1) generate the keys in a web app using web crypo, store them in ephemal strage, and rejenerate them any time the use clears the key storage. Use them in a custom HTML form based auth session with the server in which we invent our own PK based authentication protocol.

How do I know my browser generated the key, and that the key wasn’t given to me by someone else? Without reverse engineering the javascript code I was given to run I can’t, and as such web crypto offers no security guarantees to the end user.

> 2) genearte the keys using math, possibly web cryto with “exportable” keys, and download a .pem file to the user’s desktop.  Get the user to click on the .pem and go through the process of installing the cert on their site. Hope fingers crossed the browsers don’t just block the use of client certs at all!

Again, if I don’t know for sure I generated the key, then there is no security for me.

> 3) Switch the while thing over to use openID-connect to connect people to some password-protected site?

This relies solely on trust of the PKI. If I compromise any CA you trust, I can help myself to your identity at will.

Although CA's are used to provide claims about public keys, we ought not think of public keys in that way.  We should think of public keys as public.  Meaning they are widely publicized.  The exact method could vary from time to time, and place to place.  A public key may be publicized on a web page, it may be in a signed claim, it may be in a certificate, it may be published on usenet or freenet, or even published in an advert the new york times. 

We should think of the publication of a public key as orthogonal to the problems that it solves.  Namely it allows a secure conversation between two parties without having to go through a trusted third party, which is, among other things, a privacy leak.
 

Regards,
Graham




Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Dave Longley
 > 2) genearte the keys using math, possibly web cryto with “exportable”
keys, and download a .pem file to the user’s desktop.  Get the user to
click on the .pem and go through the process of installing the cert on
their site. Hope fingers crossed the browsers don’t just block the use
of client certs at all!

As a quick, temporary replacement for keygen, you should be able to use
forge (or forge + WebCrypto) to generate a keypair and wrap it in a
PKCS#12 container that can be downloaded via a link that, when clicked,
may bring up an import dialog in the user's browser. They may have to
save the file first before importing, I'm not sure.

forge: https://github.com/digitalbazaar/forge

There's some somewhat messy X.509 cert creation and PKCS#12 code that
could be adapted from this issue:

https://github.com/digitalbazaar/forge/issues/211#issuecomment-85447100


--
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Graham Leggett
On 30 Mar 2016, at 6:00 PM, Dave Longley <[hidden email]> wrote:

> As a quick, temporary replacement for keygen, you should be able to use
> forge (or forge + WebCrypto) to generate a keypair and wrap it in a
> PKCS#12 container that can be downloaded via a link that, when clicked,
> may bring up an import dialog in the user's browser. They may have to
> save the file first before importing, I'm not sure.
>
> forge: https://github.com/digitalbazaar/forge
>
> There's some somewhat messy X.509 cert creation and PKCS#12 code that
> could be adapted from this issue:
>
> https://github.com/digitalbazaar/forge/issues/211#issuecomment-85447100

Does this guarantee that the key was a) generated on the client side only (and not anywhere else and injected into the conversation), and b) that this key cannot be subsequently exported and uploaded to some third party location under the control of third party server code?

If the answer is no to either, then this isn’t a replacement for keygen.

Regards,
Graham



Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Eric Rescorla-3


On Wed, Mar 30, 2016 at 9:09 AM, Graham Leggett <[hidden email]> wrote:
On 30 Mar 2016, at 6:00 PM, Dave Longley <[hidden email]> wrote:

> As a quick, temporary replacement for keygen, you should be able to use
> forge (or forge + WebCrypto) to generate a keypair and wrap it in a
> PKCS#12 container that can be downloaded via a link that, when clicked,
> may bring up an import dialog in the user's browser. They may have to
> save the file first before importing, I'm not sure.
>
> forge: https://github.com/digitalbazaar/forge
>
> There's some somewhat messy X.509 cert creation and PKCS#12 code that
> could be adapted from this issue:
>
> https://github.com/digitalbazaar/forge/issues/211#issuecomment-85447100

Does this guarantee that the key was a) generated on the client side only (and not anywhere else and injected into the conversation),

I do not believe you can do this with WebCrypto. Why do you believe that this is a requirement?


and b) that this key cannot be subsequently exported and uploaded to some third party location under the control of third party server code?

WebCrypto does support this.

However, note that it does not support taking WebCrypto keys and inserting them into the HTTPS stack

-Ekr

 

If the answer is no to either, then this isn’t a replacement for keygen.

Regards,
Graham




Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Dave Longley
In reply to this post by Graham Leggett
On 03/30/2016 12:09 PM, Graham Leggett wrote:

> On 30 Mar 2016, at 6:00 PM, Dave Longley <[hidden email]>
> wrote:
>
>> As a quick, temporary replacement for keygen, you should be able to
>> use forge (or forge + WebCrypto) to generate a keypair and wrap it
>> in a PKCS#12 container that can be downloaded via a link that, when
>> clicked, may bring up an import dialog in the user's browser. They
>> may have to save the file first before importing, I'm not sure.
>>
>> forge: https://github.com/digitalbazaar/forge
>>
>> There's some somewhat messy X.509 cert creation and PKCS#12 code
>> that could be adapted from this issue:
>>
>> https://github.com/digitalbazaar/forge/issues/211#issuecomment-85447100
>
>>
>>
> Does this guarantee that the key was a) generated on the client side
>  only (and not anywhere else and injected into the conversation), and
>  b) that this key cannot be subsequently exported and uploaded to
> some third party location under the control of third party server
> code?

The short answer is "No", as there is presently no direct replacement
for keygen. I was just offering a quick temporary fix. If it's true that
keygen has now been removed (not just deprecated), I would expect that
systems that relied upon it need *something* that they can throw
together quickly in the interim (meaning, until some other replacement
can solve their problem long term).

The longer answer is that the key pair is, in fact, generated
client-side, however, using code that is controlled by the website. That
site must be trusted not to do anything nefarious with the private key
while the site has access to it. Once the key pair has been exported to
a PKCS#12 and imported into the user's local key store, and the site has
been navigated away from, the website has no access to the private key,
should, for example, the site become compromised in the future.


--
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Melvin Carvalho


On 30 March 2016 at 18:23, Dave Longley <[hidden email]> wrote:
On 03/30/2016 12:09 PM, Graham Leggett wrote:
On 30 Mar 2016, at 6:00 PM, Dave Longley <[hidden email]>
wrote:

As a quick, temporary replacement for keygen, you should be able to
use forge (or forge + WebCrypto) to generate a keypair and wrap it
in a PKCS#12 container that can be downloaded via a link that, when
clicked, may bring up an import dialog in the user's browser. They
may have to save the file first before importing, I'm not sure.

forge: https://github.com/digitalbazaar/forge

There's some somewhat messy X.509 cert creation and PKCS#12 code
that could be adapted from this issue:

https://github.com/digitalbazaar/forge/issues/211#issuecomment-85447100



Does this guarantee that the key was a) generated on the client side
 only (and not anywhere else and injected into the conversation), and
 b) that this key cannot be subsequently exported and uploaded to
some third party location under the control of third party server
code?

The short answer is "No", as there is presently no direct replacement
for keygen. I was just offering a quick temporary fix. If it's true that
keygen has now been removed (not just deprecated), I would expect that
systems that relied upon it need *something* that they can throw
together quickly in the interim (meaning, until some other replacement
can solve their problem long term).

As I understand it keygen is NOT removed in firefox (or most versions of other browsers).  What I heard (perhaps someone will confirm) is that Mozilla will take the TAG advice, to remove existing functionality that is in use, only after it has been adequately replaced.
 

The longer answer is that the key pair is, in fact, generated
client-side, however, using code that is controlled by the website. That
site must be trusted not to do anything nefarious with the private key
while the site has access to it. Once the key pair has been exported to
a PKCS#12 and imported into the user's local key store, and the site has
been navigated away from, the website has no access to the private key,
should, for example, the site become compromised in the future.



--
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Eric Rescorla-3


On Wed, Mar 30, 2016 at 10:09 AM, Melvin Carvalho <[hidden email]> wrote:


On 30 March 2016 at 18:23, Dave Longley <[hidden email]> wrote:
On 03/30/2016 12:09 PM, Graham Leggett wrote:
On 30 Mar 2016, at 6:00 PM, Dave Longley <[hidden email]>
wrote:

As a quick, temporary replacement for keygen, you should be able to
use forge (or forge + WebCrypto) to generate a keypair and wrap it
in a PKCS#12 container that can be downloaded via a link that, when
clicked, may bring up an import dialog in the user's browser. They
may have to save the file first before importing, I'm not sure.

forge: https://github.com/digitalbazaar/forge

There's some somewhat messy X.509 cert creation and PKCS#12 code
that could be adapted from this issue:

https://github.com/digitalbazaar/forge/issues/211#issuecomment-85447100



Does this guarantee that the key was a) generated on the client side
 only (and not anywhere else and injected into the conversation), and
 b) that this key cannot be subsequently exported and uploaded to
some third party location under the control of third party server
code?

The short answer is "No", as there is presently no direct replacement
for keygen. I was just offering a quick temporary fix. If it's true that
keygen has now been removed (not just deprecated), I would expect that
systems that relied upon it need *something* that they can throw
together quickly in the interim (meaning, until some other replacement
can solve their problem long term).

As I understand it keygen is NOT removed in firefox (or most versions of other browsers).

Correct.

 
  What I heard (perhaps someone will confirm) is that Mozilla will take the TAG advice, to remove existing functionality that is in use, only after it has been adequately replaced.

I don't believe we've made any public statements to this effect. We still intend to remove <keygen> but we don't presently have a published schedule for it.

-Ekr

 

The longer answer is that the key pair is, in fact, generated
client-side, however, using code that is controlled by the website. That
site must be trusted not to do anything nefarious with the private key
while the site has access to it. Once the key pair has been exported to
a PKCS#12 and imported into the user's local key store, and the site has
been navigated away from, the website has no access to the private key,
should, for example, the site become compromised in the future.



--
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com


Reply | Threaded
Open this post in threaded view
|

Re: What we were using public key authentication for

Melvin Carvalho


On 30 March 2016 at 19:17, Eric Rescorla <[hidden email]> wrote:


On Wed, Mar 30, 2016 at 10:09 AM, Melvin Carvalho <[hidden email]> wrote:


On 30 March 2016 at 18:23, Dave Longley <[hidden email]> wrote:
On 03/30/2016 12:09 PM, Graham Leggett wrote:
On 30 Mar 2016, at 6:00 PM, Dave Longley <[hidden email]>
wrote:

As a quick, temporary replacement for keygen, you should be able to
use forge (or forge + WebCrypto) to generate a keypair and wrap it
in a PKCS#12 container that can be downloaded via a link that, when
clicked, may bring up an import dialog in the user's browser. They
may have to save the file first before importing, I'm not sure.

forge: https://github.com/digitalbazaar/forge

There's some somewhat messy X.509 cert creation and PKCS#12 code
that could be adapted from this issue:

https://github.com/digitalbazaar/forge/issues/211#issuecomment-85447100



Does this guarantee that the key was a) generated on the client side
 only (and not anywhere else and injected into the conversation), and
 b) that this key cannot be subsequently exported and uploaded to
some third party location under the control of third party server
code?

The short answer is "No", as there is presently no direct replacement
for keygen. I was just offering a quick temporary fix. If it's true that
keygen has now been removed (not just deprecated), I would expect that
systems that relied upon it need *something* that they can throw
together quickly in the interim (meaning, until some other replacement
can solve their problem long term).

As I understand it keygen is NOT removed in firefox (or most versions of other browsers).

Correct.

Great!
 

 
  What I heard (perhaps someone will confirm) is that Mozilla will take the TAG advice, to remove existing functionality that is in use, only after it has been adequately replaced.

I don't believe we've made any public statements to this effect. We still intend to remove <keygen> but we don't presently have a published schedule for it.

Thanks for the clarification.  As an independent developer (that currently uses this technology) I am happy to see Mozilla offer this functionality.
 

-Ekr

 

The longer answer is that the key pair is, in fact, generated
client-side, however, using code that is controlled by the website. That
site must be trusted not to do anything nefarious with the private key
while the site has access to it. Once the key pair has been exported to
a PKCS#12 and imported into the user's local key store, and the site has
been navigated away from, the website has no access to the private key,
should, for example, the site become compromised in the future.



--
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com



Reply | Threaded
Open this post in threaded view
|

RE: What we were using public key authentication for

POTONNIEE Olivier
In reply to this post by Tim Berners-Lee
Hello Tim
Virginie suggested me to answer to your request.
I would recommend 3)++
1. Setting up a central OpenID Connect IDP seems to be the good option for this use case (or even SAML2).
2. This IDP may use various methods to authenticate users:
  a) simple username/password
  b) after a successful a) auth, you may add a fancy protocol using webcrypto to skip password (your option 1) if I get it correctly)
  c) TLS client auth (using PKCS#11 + smart-card :) )
  d) FIDO U2F
  e) FIDO 2 in the longer term
  or any other auth method: OTP, SQRL https://www.grc.com/sqrl/sqrl.htm, Mobile ID...
Hope this helps
--
Olivier Potonniée

-----Original Message-----
From: Tim Berners-Lee [mailto:[hidden email]]
Sent: mercredi 23 mars 2016 23:08
To: GALINDO Virginie
Cc: Public TAG List
Subject: What we were using public key authentication for

Virginie

You asked at the AC lunch for me to describe what it was that we had been using  public key authentication for.

This is the system we have been using for someone to be able to identify themselves as the owner of a web page, like a blog.

- A user of a web browser runs a web app A
- The web app uses data stored in various different web sites B (Like health data, bank data, calendar, etc)
- The user has a global ID which is an https: URI which points to public info about them (or a persona) like their blog
- The access control on the data stores is set to allow access referring to that ID string
- The user accesses the data from within the webapp by using a private key which is stored securely on the device (or hardware gadget)
- The user’s public key is accessible only though unfakable "browser chrome"
- The cert is NOT signed by anything — it can be self signed. (the trust is from the public key being on the web)
- The public web home page for the user lists the corresponding public key publicly
- The client cert does contain the global ID URL

The essential characteristics of the system which the browser architecture seems to fight against:

- The whole point is to be have a public identity (like your W3C or github id) which can be to show you are the same person on multiple sites
- It isn’t just about logging onto different we sites, it is about accessing the same data you own on many sites B from many different sites A
- The signature on the cert is not part of the system, so the keychain won’t recognize the cert as “trusted”.  This does NOT use the PKI

We have been doing this using client certs, but the UI was unloved, the  keygen API weird and had bugs, browsers have had a war against client certs.  But the system worked!   Until keygen got turned off in Chrome and Firefox  a few days ago.

So can we get this functionality using web crypto in the short term?

Suppose we
1) generate the keys in a web app using web crypo, store them in ephemal strage, and rejenerate them any time the use clears the key storage. Use them in a custom HTML form based auth session with the server in which we invent our own PK based authentication protocol.

2) genearte the keys using math, possibly web cryto with “exportable” keys, and download a .pem file to the user’s desktop.  Get the user to click on the .pem and go through the process of installing the cert on their site. Hope fingers crossed the browsers don’t just block the use of client certs at all!

3) Switch the while thing over to use openID-connect to connect people to some password-protected site?

If the Fido system will give us all we need by the end of this/next year, that will be great, but we need something now we can improvise say using  web crypto and JS.

Best

Tim



________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.