> On 4 Sep 2015, at 22:43, Martin Thomson <[email protected]> wrote:
> Henry, I would rather you attempt to address Ryan's point 5, namely:
>
> 5) <keygen> just generates keys, and relies on
> application/x-x509-*-cert to install certificates. This MIME handling,
> unspecified but implemented by major browsers, represents
> yet-another-way for a website to make persistent modifications to the
> user system.
>
> The key generation capability exists today with webcrypto. I'm
> actually more interested in the consequences of the MIME-type handling
> and it's interaction with key stores on the browser. That is the more
> relevant piece of this whole issue. I know that it is at the core of
> the argument.
I asked for more details about this issue and it is not clear to me what the
issue actually is here. A certificate served by a server with the
application/x-x509-user-cert mime type as I do in my scala code [1] does not
contain a private key.
def generate = Action { implicit request =3D>
certForm.bindFromRequest.fold(
errors => BadRequest(html.webid.cert.genericCertCreator(errors)),
certreq => {
Result(
//
https://developer.mozilla.org/en-US/docs/NSS_Certificate_Download_Specification
header = ResponseHeader(200, Map("Content-Type" ->
"application/x-x509-user-cert")),
body = Enumerator(certreq.certificate.getEncoded)
)
}
)
}
As I understand, it will only on reception be inserted by the browser to the
keystore,
if the browser has generated the private key, which it would have kept
in its keystore during public/private key creation. [2] In any case a client =
certificate without a private key would not be useable for authentication,
signature, etc...
The WebCrypto APIs at present do not have access to the keystore , so they can
only store the data in Local Web Storage, which has the problems of making the
keys =
visible to all same origin JS and can also only be used by the same origin =
defeating the purpose of asymmetric public key crypt as a way to authenticate
across sites. ( mention has been made of potential avenues, but these are
still on the =
drawing board ).
So can you detail the problem? The certificate that is added to the browser
should only be allowed to be used when the user of the browser gives his
assent. So there is no privacy leakage.
> I honestly think that the best thing here - given the current state -
> is to treat this as an opportunity to ask for new work in the W3C. We
> can examine these needs on their own merits and determine if investing
> in new technology based on TLS client certificates is the right thing
> for the web.
That is exactly what Tim Berners Lee is asking for in his recent message to
the TAG
https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html
* Don't deprecate keygen until we are all certain that new technology
actually does replace the functionality that keygen usefully allows (
which is not necessarily the way it is most widely used ! )
* find out if keygen actually has something to offer that the other
techs cannot. If so
* Fix issues with keygen and client certificates where they exist and
research possible improvements there
* Consider improvements at the TLS and HTTP layer that would make this better
* Work in the open on clearly defined issues, make implicit assumptions
explicit and see if they hold up.
There are a lot of people from different areas involved in this discussion and
it is clear nobody can have a full overview of the subject. Most people here I
bet have little knowledge of what can be done with the semantic web ( but I am
sure there are many predudices about it ). Others are less knowledgeable about
UI design, others know a
lot less about cryptography, etc.. etc... There is movement in the HTTP2.0
group and in TLS3.0 which would make it possible to perhaps do much more
coherent things with client certificates - and perhaps we don't need to be
stuck with X509! And there is all the new stuff coming from JS Web Workers and
the FIDO alliance ( some of which may be good, but also perhaps some of which
may not be so good )
Henry
[1]
https://github.com/read-write-web/rww-play/blob/f587382935c85e9f8916d50654=
34f7525c328ab9/app/controllers/ClientCertificateApp.scala
[2] for details see the sequence diagram we wrote up on the WebID-TLS spec, and
which would clearly be helpful if it appeared in the html5 spec
http://www.w3.org/2005/Incubator/webid/spec/tls/#certificate-creation
Social Web Architect
http://bblfish.net/
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
