RE: Web-PKI Keygen/Certreq Questions

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

"James Jing" <jjing@xxxxxxxxxxxxxxxx> 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.