> On 4 Sep 2015, at 22:43, Martin Thomson <m...@mozilla.com> 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 =>
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.
I think 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/f587382935c85e9f8916d5065434f7525c328ab9/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
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
