Subject: RE: Web-PKI Keygen/Certreq Questions

From: [email-masked] (Peter Gutmann)
Date: Fri, 12 Dec 2003 20:28:13 +1300

"James Jing" <[email-masked]> writes:

>There is an interesting problem with proof-of-possesion in the key generation
>message which we came across lately. If someone is having another look at it,
>it would be nice if it can be addressed.
>
>The problem is if key-gen is performed on behalf of the end user, we need to
>ensure that nobody can use the private key thus generated. However, PKCS#10
>requires a signature using this newly generated key. The key container (smart
>card) is unable to know that this is for PKCS#10, since it only signs a
>digest. Therefore we are in a catch-22. If we disallow signing, then we
>cannot create the PKCS#10 message. If we do, we don't know that we signed a
>PKCS#10.

Yup, that's a problem with systems that enforce access/usage controls on
crypto keys, it makes it impossible to generate PKCS #10 requests if the
controls are in place.  For example cryptlib employs strict key usage/access
controls, so in theory you couldn't create a PKCS #10 request, or create one
for an encryption-only key.  The workaround was to add a dynamic ACL check
(that is, not a hardcoded rule in the kernel but a callback where object-type-
specific code can provide additional information to the kernel) that allowed
special-case use for PKCS #10:

/* PKCS #10 cert requests are special-case objects in that the key they 
   contain is usable only for signature checking of the self-signature 
   on the object (it can't be used for general-purpose usages, which 
   would make it equivalent to a trusted self-signed cert).  This is 
   problematic because the keyUsage may indicate that the key is valid 
   for other things as well, or not valid for signature checking.  To 
   get around this, we indicate that the key has a single trusted usage, 
   signature checking, and disallow any other usage regardless of what 
   the keyUsage says.  The actual keyUsage usage is only valid once the 
   request has been converted into a cert */

>Are there any solutions addressing such a problem already?

Most apps don't seem to enforce usage controls (for example there was one case
where a CA was using an encryption-only cert for signing messages, and in ~2
years of interop testing with PKI vendors no-one noticed; Windows allows
usage-X-only certs to be used for usage Y as well because it's less confusing
for the user to have a single cert that can do everything; a national smart
card project in Europe didn't realise that the keys they were putting on the
card weren't valid for encryption because nothing enforced the restrictions,
etc etc (there's a long list of these, those are off the top of my head)), so
it's not really a problem in general.

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 12 Dec 2003 11:59:03 +0100

>>Are there any solutions addressing such a problem already?
There is. Have a look at the way CRMF format key request generation are 
used inside Netscape 7/Mozilla.

The solution implemented enables in several different use case to 
authentify an encryption only key without ever requiring them to sign.
Not many PKI can interface with that the way it's required, but at least 
SUN or AOL's CMS can.
It's efficient and it's 100% standard compliant.
The only one dubious aspect is the use of raw CRMF requests in the 
exchange instead of encapsulating them inside CMP or CMC.

Dump PKCS#10. It wasn't designed to handle this, but CRMF was.
Well some vendor hasn't realized yet, still using only PKCS#10 inside 
it's CMC request in the 2003 version of it's tools.