POP (was: generation of private keys)

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

CRMF says the following:

> In order to prevent certain attacks and to allow a CA/RA to properly 
> check the validity of the binding between an end entity and a key pair, 
> the PKI management operations specified here make it possible for an end 
> entity to prove that it has possession of (i.e., is able to use) the 
> private key corresponding to the public key for which a certificate is 
> requested.  A given CA/RA is free to choose how to enforce POP (e.g., 
> out-of-band procedural means versus the CRMF in-band message) in its 
> certification exchanges (i.e., this may be a policy issue).  However, 
> it is MANDATED that CAs/RAs MUST enforce POP by some means because there 
> are currently many non-PKIX operational protocols in use (various 
> electronic mail protocols are one example) that do not explicitly check 
> the binding between the end entity and the private key.  Until 
> operational protocols that do verify the binding (for signature, 
> encryption, and key agreement key pairs) exist, and are ubiquitous, this 
> binding can only be assumed to have been verified by the CA/RA.  
> Therefore, if the binding is not verified by the CA/RA, certificates in 
> the Internet Public-Key Infrastructure end up being somewhat less 
> meaningful.


Thus it is explicitely considered useful not to have POP as soon as
operational protocols support this.

The important point is to avoid that applications that do not make POP
by itself can detect such certs.  A critical extension seems a
reasonabe way to do that.