RE: Web-PKI Keygen/Certreq Questions

["James Jing" <jjing@xxxxxxxxxxxxxxxx>]

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.

Are there any solutions addressing such a problem already?

This catch-22 can be broken, for example, if the PKCS#10 signature is unique to PKCS#10, such as allowing the card to add some salt, pad it to the digest and then re-digest it before signing. Something like that will ensure that the key in the initial state cannot be abused by any intermediary. 

James

-----Original Message-----
From: David P. Kemp [mailto:dpkemp@xxxxxxxxxxxxxx]
Sent: Thursday, 27 November 2003 3:59 AM
Cc: ietf-pkix@xxxxxxx
Subject: Re: Web-PKI Keygen/Certreq Questions




Hopefully the consortium is planning to construct its solution by 
profiling: a) attributes to be included in RFC 2797 messages and b) 
transport of those messages over http, rather than inventing something 
from scratch.

Dave



Anders Rundgren wrote:

> Just to set the record straight: Another consortium has indeed
> [also] found the existings keygen/certreq mechanisms largely
> inferior and will publish a draft solution in a couple of months
> or so.  I just talked to one of the architects, and he confirmed that
> it will support the kind of stuff that most of the proprietary solutions
> already do, such as key-container co-signing, passphrase policy
> control, and multi-key generation.
> 
> /a
>