[whatwg] The <keygen> element

[Nelson B Bolyard]

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

Yes, and I think FF UI has that.  It's a feature of the browser's UI, I
think, not of the keygen tag itself.

> 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 apologize for not finishing that sooner. (I had been waiting for a reply
from Ian.)  I have just updated that page with all the presently relevant
details (AFAIK).  I'm thinking about adding some examples of its use to that
page.

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

>> 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.  [...]
>> 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!

Have you really made it a standard?  Or is it now merely some kind of draft?

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

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.

Which is more likely to be adopted as a cross browser standard?
A new html tag? or a new JavaScript object/method?

If I knew the answer to that question, that would influence my suggestions
for a direction here.