Re: [whatwg] The keygen element
On Wed, Jun 3, 2009 at 3:31 PM, Ian Hickson i...@hixie.ch wrote: Which is more likely to be adopted as a cross browser standard? A new html tag? or a new JavaScript object/method? It would presumably depend on how it is to be used. If it's for form submission, then an element would make more sense. If it's for applications, then an API would be better. As a browser developer I'd say that the likeliness something is implemented depends heavily on how useful it is perceived to be, and somewhat on how hard it is to implement. If a feature doesn't seem very useful, I wouldn't advocate adding it no matter how easy it is to implement. On the other hand, if a feature is hard enough to implement that we can implement two other features, that add up to more usefulness, then implementing those two features seem to serve the web more. All of this is very simplified of course, and highly subjective. But neither a new element or a new JS object is hard to implement in and of itself. So use the best solution for the task, that's the most likely to yield a useful feature. / Jonas
Re: [whatwg] The keygen element
On Sun, 12 Apr 2009, Nelson B Bolyard wrote: Yngve Nysaeter Pettersen wrote: The default format, introduced by Netscape, is the SPKAC format, see the above link, and includes the public key and the Keygen challenge attribute, and is signed by the private key. The actual standardized format is PKCS #10, in form a more advanced and flexible version of SPKAC (it is the format used to request certificates for webservers), and I am not sure if this is now used by default in some clients. In Opera this format can be selected by using a type=pkcs10 attribute in the keygen tag. That's an interesting idea. But PKCS#10 is like a self-signed certificate. It has a full-blown X.500 Directory Name in it, just like a certificate, and the KEYGEN tag doesn't provide the input for that. I guess the browser could prompt the user, perhaps using a form something like: http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/main.html But heaven help the user to fill that in! :-/ Also like a real certificate, a PKCS#10 certificate request may have extensions. This is the way that a cert requester requests that particular extensions be put into his cert. Again, the keygen tag has no way of specifying these. But the browser could use a form like: http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/stnd_ext_form.html There's one other problem with PKCS#10 (and SPKAC too) that I mentioned before: it only works with public keys that can be used for signing. If you have an encryption only key, you can't request a cert for it with PKCS#10 because doing so requires generating a signature with it. To solve these and other problems, an alternative protocol named CRMF (the Certificate Request Message Format) was created. Mozilla supports that with the crypto.generateCRMFRequest method. If we're really going to standardize something like a keygen tag, we should design it to be able to do the things that can be done with crypto.generateCRMFRequest, too. That should not be difficult. See https://developer.mozilla.org/En/JavaScript_crypto/GenerateCRMFRequest I agree that standardising this would be a good idea; I recommend approaching the public-webapps WG at the W3C to do this. I haven't added this, because right now the only browser I could find which supports more than one algorithm is Firefox, and it just has two (RSA and ECs, as far as I could tell). And DSA. The DSA code doesn't appear to be hooked up. I haven't added ECs to HTML5 since I couldn't find any documentation on it (the above isn't updated yet). Also, I omitted DSA support which is claimed to be supported on the above page, because as far as I can tell nobody actually supports it. It's not popular in the commercial world, but I think a certain government still likes it. :) I'm definitely not adding features to HTML5 for a single vendor, even if that vendor has an army. Which is more likely to be adopted as a cross browser standard? A new html tag? or a new JavaScript object/method? It would presumably depend on how it is to be used. If it's for form submission, then an element would make more sense. If it's for applications, then an API would be better. On Mon, 13 Apr 2009, Anders Rundgren wrote: On-line provisioning of PKI is rather little used because the big users of PKI (banks and governments), prefer using physical token distribution like for PIV/CAC/eID. What those large users have not bothered much with to date is how they are going to use PKI in the most popular IT-device there is, the mobile phone. IMHO the availability of trusted HW at a very small premium motivates a completely new key-generation scheme, presumably based on TPM 1.2 or enhanced TPM-schemes. Regarding the keygen tag itself, I personally don't see that such mechanisms need any explicit links to an HTML page, at least none of the alternatives including generateCRMFRequest and CertEnroll do, they are just APIs. To give you an indication of that key-generation standards is not an easy task, IETF's KEYPROV has been running for almost three years! My own contribution to this field, KeyGen2, requires not less than six message rounds compared to keygen's three. Take a peek at the [beta] XML Schema at: http://keycenter.webpki.org/resources in case you are interested Thanks for the info! On Fri, 17 Apr 2009, Anders Rundgren wrote: I understand what you are saying, but without a buy-in from Microsoft there is little point in elevating keygen to some kind of standard since it will fail in the majority of cases. Even if IE's market share stops dropping (which it shows no signs of doing), I believe that getting interop amongst three browser vendors is an important enough goal that it is still worth standardising even if Microsoft never implement keygen. Cheers, -- Ian Hickson U+1047E
Re: [whatwg] The keygen element
On Thu, Apr 16, 2009 at 9:22 PM, Anders Rundgren anders.rundg...@telia.com wrote: Nelson B Bolyard wrote [to the WHATWG list]: Based on WHATWG comments, this it is not really about standardization but about documenting the current practice for key generation in the HTML layer without comparing this to other ways of achieving the similar goals including generateCRMFRequest. JavaScript is thus outside of the scope AFAICT. The keygen discussion is not about creating a new standard, that is correct. It is about standardizing current practices that are required by *todays* browsers in order to be compatible with the web and thus considered by users. As for coming up with a new, better standard for accomplishing what keygen was originally envisioned to do, way back when, I think this would be a great idea. Nothing is out of scope for such a new standard. However the apropriate standards organization and working group should be used. So for example if the new solution is a pure javascript API, then either the webapps wg in w3c, or some security related standards org seems more apropriate than whatwg. If on the other hand a new HTML element is proposed, then this list seems like a fine place for such a discussion. Hope that makes sense? / Jonas
Re: [whatwg] The keygen element
I understand what you are saying, but without a buy-in from Microsoft there is little point in elevating keygen to some kind of standard since it will fail in the majority of cases. Anyway, it seems that the security people are uninterested in on-line key provisioning so you can go ahead without regrets :-) As a web-CA writer I know that I will have to check User-Agent etc. because this isn't going to be _the_ solution :-( When you have added the missing 5-10 attributes including repeated keys (!) to reach generateCRMFRequest level (easy according to Nelson...) https://developer.mozilla.org/en/GenerateCRMFRequest please give drop me a line :-) Anders - Original Message - From: Jonas Sicking jo...@sicking.cc To: Anders Rundgren anders.rundg...@telia.com Cc: whatwg@lists.whatwg.org; Nelson B Bolyard nel...@bolyard.me; dev-tech-cry...@lists.mozilla.org Sent: Friday, April 17, 2009 23:16 Subject: Re: [whatwg] The keygen element On Thu, Apr 16, 2009 at 9:22 PM, Anders Rundgren anders.rundg...@telia.com wrote: Nelson B Bolyard wrote [to the WHATWG list]: Based on WHATWG comments, this it is not really about standardization but about documenting the current practice for key generation in the HTML layer without comparing this to other ways of achieving the similar goals including generateCRMFRequest. JavaScript is thus outside of the scope AFAICT. The keygen discussion is not about creating a new standard, that is correct. It is about standardizing current practices that are required by *todays* browsers in order to be compatible with the web and thus considered by users. As for coming up with a new, better standard for accomplishing what keygen was originally envisioned to do, way back when, I think this would be a great idea. Nothing is out of scope for such a new standard. However the apropriate standards organization and working group should be used. So for example if the new solution is a pure javascript API, then either the webapps wg in w3c, or some security related standards org seems more apropriate than whatwg. If on the other hand a new HTML element is proposed, then this list seems like a fine place for such a discussion. Hope that makes sense? / Jonas
Re: [whatwg] The keygen element
Nelson B Bolyard wrote [to the WHATWG list]: snip I think that the KEYGEN tag's attributes could be extended to accept all the arguments that can be passed to crypto.generateCRMFRequest, quite easily. Yes, but the crypto.* functions could be extended to do things you would never be able to do in a page mark-up language like capability discovery. Which is more likely to be adopted as a cross browser standard? A new html tag? or a new JavaScript object/method? Probably none of these alternatives. All other efforts in this space (KEYPROV, KMIP, SKSML, XKMS, KeyGen2, etc.) builds on a protocol concept If I knew the answer to that question, that would influence my suggestions for a direction here. If Mozilla would like to contribute to progress, I think you should start in another end, and see how protocols could be invoked in FireFox in a generic fashion. Based on WHATWG comments, this it is not really about standardization but about documenting the current practice for key generation in the HTML layer without comparing this to other ways of achieving the similar goals including generateCRMFRequest. JavaScript is thus outside of the scope AFAICT. Anders
Re: [whatwg] The keygen element
This is a resend, since my first message, though a reply to Ian, apparently went into the bit bucket. Ian Hickson wrote, On 2009-04-06 20:37 PDT: I have now specified the keygen element in HTML5. http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element I would appreciate review by people who know what this stuff means, as I'll be the first to admit not having any idea what I'm doing here. I apologize for replying to this thread so late. Yngve Nysaeter Pettersen wrote: Submission formats: The default format, introduced by Netscape, is the SPKAC format, see the above link, and includes the public key and the Keygen challenge attribute, and is signed by the private key. The actual standardized format is PKCS #10, in form a more advanced and flexible version of SPKAC (it is the format used to request certificates for webservers), and I am not sure if this is now used by default in some clients. In Opera this format can be selected by using a type=pkcs10 attribute in the keygen tag. That's an interesting idea. But PKCS#10 is like a self-signed certificate. It has a full-blown X.500 Directory Name in it, just like a certificate, and the KEYGEN tag doesn't provide the input for that. I guess the browser could prompt the user, perhaps using a form something like: http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/main.html But heaven help the user to fill that in! :-/ Also like a real certificate, a PKCS#10 certificate request may have extensions. This is the way that a cert requester requests that particular extensions be put into his cert. Again, the keygen tag has no way of specifying these. (But the browser could use a form like: http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/stnd_ext_form.html There's one other problem with PKCS#10 (and SPKAC too) that I mentioned before: it only works with public keys that can be used for signing. If you have an encryption only key, you can't request a cert for it with PKCS#10 because doing so requires generating a signature with it. To solve these and other problems, an alternative protocol named CRMF (the Certificate Request Message Format) was created. Mozilla supports that with the crypto.generateCRMFRequest method. If we're really going to standardize something like a keygen tag, we should design it to be able to do the things that can be done with crypto.generateCRMFRequest, too. That should not be difficult. See https://developer.mozilla.org/En/JavaScript_crypto/GenerateCRMFRequest I haven't added support for PKCS10 since it doesn't seem to actually add anything to the feature set. Well, it potentially allows the user to request specific cert extensions, but this is generally handled by other means in the form that the user is filling in. - An algorithm preference list, specifiying the key algorithms preferred by the server, in order of preference. In this case a keyword registration process should also be defined. Initial keywords should cover RSA, DSA and Elliptic Curves. As some methods may require parameters to be transferred to the client the syntax should cover such extensions, e.g alg1;param1=x;param2=y,alg2, name of parameters should be selected by the specification for the algorithm, but two parameters should be defined: Minimum length (e.g. min-len) and Maximum Length (max-len) of the key that can be used to guide the client in what keylength it should selects (These should be suggestions, not absolute limits, at least for the maximum; the minimum should probably be considered a lower limit) Typically, a given CA only certifies certs with a single public key type. If the user wants to choose a different key type, he probably needs to choose a different CA (or at least a different CA page). I haven't added this, because right now the only browser I could find which supports more than one algorithm is Firefox, and it just has two (RSA and ECs, as far as I could tell). And DSA. It is also conceivable that the server should be able to specify which sites the certificate can be used for. A common usability problem with client certificates in SSL/TLS is selection of certificate, particularly when you have many certificates. A list of hostname:port pairs would probably be a good way to ease that (the SSL/TLS server can also specify which CAs it prefers to the certificate was issued by, but nobody is currently using that capability). A list of such sites provided at generation time might help the user in cases where the SSL/TLS server does not specify preferred CAs. Sure, but this doesn't seem relevant to the keygen tag. It's just more info that the CA can put into the page that contains the form that contains the keygen tag. In the future it is also conceivable that such requests is to be made for keys stored on smartcards, so a source selector might be an idea, perhaps also with the capability to specify specific
Re: [whatwg] The keygen element
Going forward maybe we should add this to the keytype= attribute, though, making it a space separated list instead of an enumerated attribute. For the parameters, maybe we can use different attributes for the different types? e.g. dsaparams= ecparams= etc? Netscape 4 used to have pqg= for DSA (PQG is what DSA's parameters are called) so there is some precedent there. Going one step further, if the keygen element does support multiple algorithms, would it be worthwhile to allow it to contain parameters, e.g. param name=dsa value=some-value? On one hand, the set of widely-implemented algorithms seems small and fixing attribute names like dsaparams= makes sense. But on the other, allowing params with arbitrary names seems like a more flexible approach. Regards, James
Re: [whatwg] The keygen element
On Tue, 7 Apr 2009, James Ide wrote: Going one step further, if the keygen element does support multiple algorithms, would it be worthwhile to allow it to contain parameters, e.g. param name=dsa value=some-value? On one hand, the set of widely-implemented algorithms seems small and fixing attribute names like dsaparams= makes sense. But on the other, allowing params with arbitrary names seems like a more flexible approach. Why would it be more flexible to use another element? Surely attributes are just as flexible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The keygen element
On Tue, 07 Apr 2009 09:34:44 +0200, Ian Hickson i...@hixie.ch wrote: On Tue, 7 Apr 2009, James Ide wrote: Going one step further, if the keygen element does support multiple algorithms, would it be worthwhile to allow it to contain parameters, e.g. param name=dsa value=some-value? On one hand, the set of widely-implemented algorithms seems small and fixing attribute names like dsaparams= makes sense. But on the other, allowing params with arbitrary names seems like a more flexible approach. Why would it be more flexible to use another element? Surely attributes are just as flexible. More importantly, we cannot use an element because keygen parses just like input and friends. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] The keygen element
Why would it be more flexible to use another element? Surely attributes are just as flexible. Attributes are flexible if they are named generically (e.g. just params=). But as soon as they are named dsaparams= or ecparams=, UAs are somewhat precluded from adding some new algorithm XYZ because of the lack of an xyzparams= attribute. In short, if it is likely that UAs will support more than just two or three popular signature algorithms, it may be worthwhile to allow authors to specify a name and parameters for any arbitrary algorithm. (It doesn't have to be with elements - that was just an initial suggestion.) Otherwise, if RSA, DSA, and perhaps ECs are the only prevalent algorithms (and will continue to be so), then adding rsaparams, dsaparams, and ecparams as attributes sounds good to me (and less verbose!). More importantly, we cannot use an element because keygen parses just like input and friends. Right - I'm not quite sure that it's worthwhile to bring on this change. - James
Re: [whatwg] The keygen element
On Tue, 7 Apr 2009, James Ide wrote: Attributes are flexible if they are named generically (e.g. just params=). But as soon as they are named dsaparams= or ecparams=, UAs are somewhat precluded from adding some new algorithm XYZ because of the lack of an xyzparams= attribute. I don't understand. Why can't we use xyzparams= if we introduce an XYZ algorithm? In short, if it is likely that UAs will support more than just two or three popular signature algorithms, it may be worthwhile to allow authors to specify a name and parameters for any arbitrary algorithm. As we add algorithms, we would presumably add the attributes if they are needed. Note that right now a browser isn't intended to just add more algorithms willy nilly; the list is theoretically limited to what's in the spec. If we were to make the list open-ended, we could just as easily allow the attributes to be open-ended as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The keygen element
As we add algorithms, we would presumably add the attributes if they are needed. This clarifies everything. Thanks, James
[whatwg] The keygen element
I have now specified the keygen element in HTML5. http://www.whatwg.org/specs/web-apps/current-work/#the-keygen-element I would appreciate review by people who know what this stuff means, as I'll be the first to admit not having any idea what I'm doing here. On Mon, 1 Sep 2008, Anders Rundgren wrote: Among glaring omissions I would include: - No support for PINs and associated policies - No support for TPMs - No support for key management I haven't added any new features to keygen at this time. I want to start by making sure the spec as written matches reality. On Tue, 6 Jan 2009, Bjoern Hoehrmann wrote: You don't say which documentation you read, but the original Netscape documentation was rather clear that the private component is stored in the local keystore, and from there you can of course use it when a site requests that you identify yourself with a certificate. Very clear is not the terminology I would use. Hopefully the text of the HTML5 spec now shows the level of detail I was looking for. (Hopefully it is correct, too.) On Tue, 6 Jan 2009, Yngve Nysaeter Pettersen wrote: The CA then uses the received data, along with other information, some possibly provided through other forms or Out-of-Band, and generates a X509 certificate. The certificate can, depending on CA infrastructure, be downloaded immediately as a result of the request, or later, with the content-type application/x-x509-user-cert (which can contain several certificate encapsulation formats, X509, Netscape Multicert, PKCS #7 Signed Data, or a PKCS #7 with an encapsulated Signed data message). The client acts on the downloaded certificate by opening a certificate installation dialog. It is also possible to import such certificate manually. The certificate is installed together with the previously stored private key. I haven't specified this bit, since it seems out of scope for HTML5. Submission formats: The default format, introduced by Netscape, is the SPKAC format, see the above link, and includes the public key and the Keygen challenge attribute, and is signed by the private key. The actual standardized format is PKCS #10, in form a more advanced and flexible version of SPKAC (it is the format used to request certificates for webservers), and I am not sure if this is now used by default in some clients. In Opera this format can be selected by using a type=pkcs10 attribute in the keygen tag. I haven't added support for PKCS10 since it doesn't seem to actually add anything to the feature set. My suggestion for the keygen tag is to add some functionality, such as the format selector: - A type attribute, or a better way to select the format. I think the specification should encourage PKCS10 as the default, but specifically require servers to accept SPKAC. Adding a format selector allows future enhancements with new formats in a backwards compatible fashion. I should think that a registration method should be defined for such formats (similar to IANA) I think we should wait until we have some future enhancements before adding new formats here. - An algorithm preference list, specifiying the key algorithms preferred by the server, in order of preference. In this case a keyword registration process should also be defined. Initial keywords should cover RSA, DSA and Elliptic Curves. As some methods may require parameters to be transferred to the client the syntax should cover such extensions, e.g alg1;param1=x;param2=y,alg2, name of parameters should be selected by the specification for the algorithm, but two parameters should be defined: Minimum length (e.g. min-len) and Maximum Length (max-len) of the key that can be used to guide the client in what keylength it should selects (These should be suggestions, not absolute limits, at least for the maximum; the minimum should probably be considered a lower limit) I haven't added this, because right now the only browser I could find which supports more than one algorithm is Firefox, and it just has two (RSA and ECs, as far as I could tell). Going forward maybe we should add this to the keytype= attribute, though, making it a space separated list instead of an enumerated attribute. For the parameters, maybe we can use different attributes for the different types? e.g. dsaparams= ecparams= etc? Netscape 4 used to have pqg= for DSA (PQG is what DSA's parameters are called) so there is some precedent there. It is also conceivable that the server should be able to specify which sites the certificate can be used for. A common usability problem with client certificates in SSL/TLS is selection of certificate, particularly when you have many certificates. A list of hostname:port pairs would probably be a good way to ease that (the SSL/TLS server can also specify which CAs it prefers to the certificate was issued by, but nobody is currently using that
