[whatwg] The <keygen> element

[Ian Hickson]

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 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.

It seems like we should encourage people to use the existing feature you 
mention rather than adding more features to do effectively the same thing.


> 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 cards.

I'd rather we didn't specify this before it was ready to be a reality.


On Wed, 7 Jan 2009, Anders Rundgren wrote:
>
> I still maintain that <keygen> is too deficient to achieve standard 
> status. Microsoft has a better system and will never implement <keygen> 
> as it stands today.

That's possible, but I'm not sure what to do about it.



On Thu, 8 Jan 2009, Nelson B Bolyard wrote:
> 
> This is documented at
> https://developer.mozilla.org/En/HTML/HTML_Extensions/KEYGEN_Tag
> which (I have just noticed) has not been updated with the info for ECC
> key generation.  I will update that page soon.

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.


> However, having said that, there are a number of known shortcomings of 
> the keygen tag, which is why the Netscape and Mozilla browsers also 
> support the generateCRMFRequest() method on the crypto object.  See 
> https://developer.mozilla.org/En/JavaScript_crypto/GenerateCRMFRequest 
> for documentation on that method.

I haven't specified this method. I would recommend specifying the entire 
"crypto" object in a separate working group, since it is orthogonal to the 
rest of HTML (unlike <keygen>, which fits into the parser and form 
submission and so on).


> Among the shortcomings are:
> a) SPKAC is non-standard, but is openly specified and has become a
> de facto standard and is now supported in numerous packages.

It's not non-standard any more, I guess!


> b) The tag has no way to specify whether the key is to be used for
> signing-only, or whether it can also be used for data/key encryption.
> c) The SPKAC format requires that the key be usable for signing, not
> useful for generating encryption-only keys.
> d) The tag has no provision for key escrow.

I haven't addressed these; I'm not sure how to for <keygen>. I suppose the 
methods on the "crypto" object are a better long term solution for this, 
if there is interest in formally specifying them (e.g. in the W3C Web Apps 
working group).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'