- From: Story Henry <henry.story@bblfish.net>
- Date: Tue, 19 Jan 2010 19:23:24 +0000
On 19 Jan 2010, at 17:26, Bruno Harbulot wrote:
> Hello Henry,
>
>
> Story Henry wrote:
>>> Whilst I'm very supportive of having a key-generation mechanism in the browser, I'm now not entirely sure the <keygen> tag, at least as a legacy of the Netscape <keygen> tag, is the correct approach.
>> I think that part of the html5 goals is to describe how browsers actually work, without going into endless debates about how they SHOULD work. Given that Netscape, Firefox, Opera and Safari implement the <keygen> tag - and have done so for a very long time - it seems quite reasonable to describe that behaviour in html5.
>
> As far as I understand, <keygen> was, if not officially deprecated, at least not recommended in Firefox, since the introduction of generateCRMFRequest.
>
>
> I wouldn't say <keygen> is greatly implemented, even in Firefox.
> Consider the following HTML document:
>
> <html>
> <head>
> <script type="text/javascript">
> function writeTagName() {
> document.getElementById("title").appendChild(
> document.createTextNode(document.getElementById("keygen").tagName));
> }
> </script>
> </head>
> <body onload="writeTagName()">
> <h1 id="title"></h1><keygen id="keygen" />
> </body>
> </html>
>
>
> In Firefox, this prints "SELECT": <keygen> is transformed on the fly into <select>, which breaks DOM usage. This is something that Opera and Safari don't do.
(( should not <keygen> be inside a <form> ? ))
> Even across Firefox, Opera and Safari, the behaviour of keygen isn't uniform.
I think they rarely are. This is why the WhatWG is documenting these inconsistencies...
The trick is to find overlaps in the behaviour, the differences, and the work out from there what options for development exist.
> The choice of "High grade" and "Low grade" is left to the appreciation of Firefox, whereas a proper CA would certainly require a bit more precision. In contrast, Opera offers a much longer list of key sizes, defaulting somewhere around 1500 bits (I don't have Opera on this machine).
That is not a problem if the browser user interface is different. Perhaps the different browsers have different expectations on their users abilities. Perhaps keygen can be later extended to make it possible to be more precise. It seems to me that keygen is there to produce a key in a form, and send it with the form. How it gets the key is a lot less important.
> One of the other points (which I think I've seen mentioned on this mailing list) is that <keygen> doesn't really fit as a form element. There's a number of parameters that can be set to generate a pair of keys. Why assume that the keysize (and only the keysize) is to be chosen by the user while all the others are set within the page? It might make sense, in some circumstances to have it all fixed on the page (by the service provider) or to let the user also chose whether to use RSA or RSA for example. (Along the same argument, why assume 'md5WithRSAEncryption' and not SHA-1?)
> It just looks like it doesn't belong in a form this way.
But certainly that type of thing could be added to a <keygen> extension?
> I'd go even further that this in fact: why always *generate* a key-pair?
> Whether it's used for an PKIX CA or FOAF+SSL, why not let the option to use an existing pair of key available in whatever key store the browser has access to? (That would in fact be quite useful for FOAF+SSL applications.)
> If I send a CSR to a CA for signing, does it (even can it) know where those keys have been generated? Perhaps it might make more sense in some cases to re-use an existing pair of keys available in a smart-card or even some software key store.
Good idea. Since the private keys don't leave the store, the browser could ask the user to re-use a key. In fact I would say that if a browser vendor allowed a user to do this, he would not necessarily be going against the spirit of keygen.
>> Once this is described it is then possible to find ways either to extend on the current behaviour or to find ways to improve it. Until now this topic was only something a few people could discuss.
>>> More specifically:
>>>
>>> 1. The more modern APIs (generateCRMFRequest [1] on Firefox or CertEnroll/XEnroll on Internet Explorer [2]) appear to offer more options in general, for example, where to store the private key, is it exportable, etc. (I haven't looked in details, but I suspect it could be envisaged to use some existing key material from a software store or smartcard too, for example.)
>>> This raises the question as to whether a tag is sufficient or appropriate to express what's required for a CA, or if an API (and more programming) is required.
>> I think there should be a strong preference for declarative ways of doing things if possible, ie to use HTML tags. Moving over to javascript has always seemed to me to be breaking one foundational element of the web.
>
> The problem is that there's only so much one can do declaratively in this field, precisely because some of this involves the security architecture of the overall system in which the browser runs, which by essence will have parts that do not belong within the browser, or at least ought to be outside the direct reach of what HTML can do (Windows certificate store, Apple Keychain...).
Why would using the Apple Keychain be a problem? Firefox could ask the Apple Keychain for a list of public certificates, and yet reuse a public key from there as you suggested above. Or Firefox could add a key to such a keychain. One would hope that would be possible at least. Indeed the nice thing about the declarative tag, is that it could hide all these implementation issues.
>
>> As proof of the advantage of this way of working: the keygen tag has functioned across browser generations without change (I think).
>
> Well, I haven't followed the complete history of generateCRMFRequest, but there must be a reason why it was invented as a successor of <keygen>. I have no idea what the ratio of modern CAs that still use <keygen> vs. those that use generateCRMFRequest is. The one I use regularly seems to use generateCRMFRequest.
It would be interesting indeed to learn about the reason for this.
But it would not be surprising that generateCRMFRequest got adopted more recently, as it has been documented. Browser manufacturers seem to have a lot less problems with making special JavaScript functions and documenting those than they do creating new tag elements.
>
>
>> Microsoft's ActiveX component on the other hand (as I understand required the calling of a Windows specific binary technology! The naming of a dll. This meant that when they changed the dll code that was written for browsers also had to change!
>> http://msdn.microsoft.com/en-us/library/bb931379%28VS.85%29.aspx
>> [[
>> Prior to Windows Vista, the Certificate Enrollment Control was implemented in Xenroll.dll. The Xenroll.dll library has been removed from the operating system and replaced by CertEnroll..dll.]]
>> The web is described with no reference to CPU architecture. I am seriously against bringing such low level aspects into day to day web programming.
>
> As Adrian Bateman from Microsoft said in [5]: "We are prepared to consider creating common APIs that allow interoperability across browsers and also address customers' real needs either in a future version of the spec or as a separate work item."
>
> Perhaps that's the way to go, having a common API similar to what's done for XMLHttpRequest.
>
> While I must admit it took me a while to figure out how to write [6] for CertEnroll.dll, this wasn't infeasible. Perhaps a similar example on MSDN would have helped.
I am not flattering you Bruno, if I say that you are extremely knowledgeable in cryptography. Knowing cryptography, javascript, html and more is a lot to ask people. Much simple really would be if we could all have <keygen> work across browsers, and even better an improved keygen.
JavaScript is a problem just for one reason: it can be switched off.
> The change you're talking about isn't just a change of DLL, it's a more fundamental change in the handling of certificate in the overall infrastructure of the operating system. (Yes, a common API with sensible default values and what needs to be OS-specific customised there would help.)
>
> You could say that Safari handles both <keygen> and the OSX's Keychain infrastructure, but this seems to come at the expense of certificates being almost unusable in the current implementation [7].
yes, that's a tricky problem of how to get a lower level to make use of an upper level User Interface to get the user to make a choice. But that is a problem at the connection level, when the user has to choose which certificate he wishes to use for client side certificate connection.
This is not a problem at the certificate creation level which is what we are discussing here.
>>> 2. The SPKAC format seems to be a legacy format. It doesn't really allow to convey much information that CAs would expect, unlike other formats used by the more modern APIs [3][4]. Perhaps it would be better to use one of the newer formats instead. This might break the compatibility with the pre-HTML 5 use of <keygen> (maybe another name than <keygen> in HTML5 would be better?).
>> Perhaps extensions to keygen would be an interesting idea. At least it is document now.
>
> I think it probably shouldn't be. Having a separate effort along the lines of that for XMLHttpRequest, involving CA implementors and security experts sounds like a better plan, rather than crippling HTML 5 with something that not quite fit for purpose.
I am still not convinced you have made the case that it is not fit for purpose. The <keygen> tag is currently very basic. You would have to prove that no way of extending it could make it fit for purpose. That is much more difficult to prove. Also it took us one year to find the solution you have put together, and there are many more browsers coming out there on the market every day. I really would rather we all started working on simplifying life, so that we can deal with real problems (and there are an infinity of those waiting for us), rather than artificial problems such as these.
Furthermore you would need to show that the keygen tag with its current limitations is not at all fit for a very broad range of purposes. Seems to me that one can get a lot done with the current keygen and that it is very useful.
>
>>> Of course, the other big question is whether it's worth trying to standardise this <keygen> tag if there's no intent of support from major browser vendors (I have IE in mind here).
>> There are 3 browser vendors that have implemented it. That is enough of a precedent to standardise. If one browser vendor requires people to use binaries that tie people to their platform, it seems that it is quite clear what the reasons for that may be, and those reasons have in the past been deemed legally condemnable by both US and EU courts. Let us rather assume that that vendor decided to pursue that activity due to lack of standardisation in this space.
>
> I think you completely misunderstand the XEnroll vs. CertEnroll issue. This isn't about "binaries that tie people to their platform", this is about a change of API that reflects new capabilities offered by the platforms. The introduction of more flexibility in CertEnroll may reflect some actual user requirements, rather than an evil will to tie users to the platform. Again, according to [5], MS doesn't seem against a standardisation effort in that domain.
Well good.
But again if I look at [5] I don't see that this shows that one cannot enhance keygen to make it do all the things listed by it or by you. Those all seem to be requests for improvement which could easily be specified.
> (Talking about API evolution, as far as FOAF+SSL is concerned, if CertEnroll was able to generated a suitable key-pair produce a self-signed certificate with the attributes we want, that would be a more convenient way than the <keygen>/pseudo-CA approach.)
Yes, foaf+ssl can work with self signed certificates. So I am not defending keygen out of selfish reasons. On the other hand for foaf+ssl to work well, the public key needs to be published on a remote server in RDF. So the interaction with a server is necessary - even if the server is a local machine - for desktop machines with fixed ip addresses.
>
> Whilst, like many others, I have expressed frustration with Internet Explorer's own interpretation of various web standards, I can't really blame MS on this one. I mostly agree with Adrian Bateman's comments in [5], in fact.
> You had written down the ActiveX mechanism as a "hack" for MSIE on the ESW wiki page before I edited it, but frankly, I'd consider Netscape's <keygen> to be as much as a hack, just made by IE's competitor. I might get it wrong, but considering the earliest mention of PKCS#10 I've seen dates from 1993 [8] and the earliest mention of <keygen> seems to be in the 1998 Netscape doc [9], time by which PKCS#10 was in an RFC [10], perhaps Netscape could have followed that standard at the time too instead of using SPKAC.
yes, SPKAC seems a bit odd of a decision.
But at least it is a data format. ActiveX ties the browser to a CPU architecture. That is a different kind of bug.
> I'm not aware of the full history of these standards, but I find it hard to make a judgement on who's right and who's wrong here.
> If IE doesn't support <keygen>, it would just be too easy to be anti-MS and claim "they don't support standards as usual" once this <keygen> is in HTML 5.
Blaming Microsoft if they don't implement standards before they are standard won't convince anyone of independent judgement. But clearly it is not a good reason not to find good standard solutions because one is worried that they have not implemented that non existent standard in the past. For all I know M$ may be quite happy with a good solution in this space...
> I'm quite happy to have <keygen> now, since it helps demonstrate our FOAF+SSL work works across browsers, but I have reservations regarding its appropriateness as a general certificate request tool for the HTML of the future.
yes, certainly it can be improved. We should leave that magic up to the WhatWG who have extensive experience in the space of taking incompatible behaviours and writing specs that work with usage towards a better future.
Thanks for all these pointers,
I am sure this will be of great help to this group.
Henry
>
>
> Best wishes,
>
> Bruno.
>
>
>>> [1] https://developer.mozilla.org/en/GenerateCRMFRequest
>>> [2] http://msdn.microsoft.com/en-us/library/aa374863%28VS.85%29.aspx
>>> [3] http://tools.ietf.org/html/rfc2986
>>> [4] http://tools.ietf.org/html/rfc4211
>
> [5] http://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html
> [6] http://github.com/harbulot/keygenapp/blob/master/samplewebapp/src/main/webapp/crosskeygen.js
> [7] http://lists.apple.com/archives/apple-cdsa/2009/Apr/msg00041.html
> [8] http://www.rsa.com/rsalabs/node.asp?id=2132
> [9] http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503
> [10] http://tools.ietf.org/html/rfc2314
>
Received on Tuesday, 19 January 2010 11:23:24 UTC