Subject: Web-PKI Keygen/Certreq Questions

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 31 Oct 2003 16:21:23 +0100

Dear List,

After verifying that Web-signing is indeed both a much wanted
thing, as well as being in a miserable state standards-wise, I took
the liberty to check out another piece in the Web-PKI puzzle:

I cannot find any "compilation" of browser (on-line)-adapted mechanisms
for performing key generation or performing certificate requests.
This may be due to a limited effort on my part, but I suspect this
is just another "black hole" with respect to interoperability. 
Please tell me I'm wrong!

Looking at Microsoft's CertSrv for W2K, I found that IE and
Navigator are supplied with very different code.  IE seems to
only rely on MSFT's proprietary "Xenroll" stuff, while Navigator
uses a Netscape proprietary HTML tag called "KeyGen".

Any comments or information on this subject?

Sincerely
Anders Rundgren
Consultant, PKI & e-business

PS This is indeed off-topic for PKIX but not for the "PKI community"
     which to some extent is represented in PKIX  DS

---

From: Stephen Kent <[email-masked]>
Date: Fri, 31 Oct 2003 10:59:54 -0500

>Please tell me I'm wrong!

yes, you are wrong.

both browsers have had facilities for generating an RSA key pair for 
a user, and sending a cert request for years.

do some more homework.

Steve

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 31 Oct 2003 19:15:27 +0100

Stephen Kent wrote:

> both browsers have had facilities for generating an RSA key pair for a 
> user, and sending a cert request for years.

Facilities is one thing, interoperability is another.

IE does fully rely on the page interacting with the proprietary xenroll 
to generate request.
Some people that were unhappy with some aspect of the behaviours of 
xenroll have even developped their own solution.

Netscape was using a propretary, little documented HTML tag to generate 
a request in the 4.x browser, KEYGEN.

Newer Mozilla and Netscape continue to support this, but can also use a 
significantly less ugly javascript-based solution with a call to the 
*generateCRMFRequest*() function .

So, from the point of view of what should be put on a web page to get a 
browser to generate a certificate request, there is no standard.
This can be considered not to be a valable item of concern for pkix thought.

Even the format of the request, which is much more of concern to pkix, 
is not fully standardised, because if IE was generating pkcs#10, the 
KEYGEN would create a netscape specific SPKAC format.
As can be guessed from the name, newer Netscape can generate a CRMF 
format request.
But I don't know if the idea of sending it raw without any CMC/CMP 
envelop makes it a very compatible solution.
Newer xenroll can generate CMC format request.
But it's not as standard-based as it may seem, because xenroll will 
always put a pkcs#10 inside, and never ever a crmf.
This even if the request include functionnalities that require a CRMF 
based CMC request, like private key exportation for key recovery.
There's probably few people outside of Microsoft who understand how the 
key is exported in this case, the solution used does not conform to any 
standard and has some platform specific elements.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 31 Oct 2003 14:34:38 -0500

At 19:15 +0100 10/31/03, Jean-Marc Desperrier wrote:
>>both browsers have had facilities for generating an RSA key pair 
>>for a user, and sending a cert request for years.
>

I have not worked this problem recently, but in my  experience 
developing three different CA products a few years ago, all were able 
to accept enrollment requests from both browsers, and all major 
providers of CA software did so as well. it was a necessary 
prerequisite for selling CA software.

we now have 2 PKIX standards for enrollment protocols: CMP and CMC. 
if the browser vendors choose to support these, then we have 
interoperable solutions as well, but vendors must choose to make use 
of them.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 31 Oct 2003 22:51:40 +0100

>>Facilities is one thing, interoperability is another.

Thanx Jean Marc!

>prerequisite for selling CA software.

Sure, we all know that.  But with mobile internet we get a
set of new browsers and you must recognize them as well.

Also, I do no think that the key-gen facilities are indentical and
maybe, maybe these functions aren't even that fit for the purpose.
Otherwise I don't see why most new implementation of serious
Web-PKI bypass the whole thing.  One limitation I'm almost sure
of: You cannot generate multiple keys in one step.
Other likely limitations include CA-control of password
policy, and getting key container signatures (figuring out
its "quality" and tying it to a "device")

>interoperable solutions as well, but vendors must choose to make use 

But none of these define a browser interface beyond MIME type
which render these protocols incomplete (in this context nota bene).

As far as I can see Web-PKI (pretty much all aspects of it), is in
a really lousy shape and desperately needs a blood transfusion.
Particularly as it will have a couple of billion users within
five years or so.

Anders