Re: generation of private keys

[Juergen Walter <walter@xxxxxx>]

Peter,


> CRMF tells WHY POP is manadates. The reason is that at the time when
> the document was started, no applications existed that could live
> without POP. 

The second reason is still relevant, even though the application does
POP.
[CRMF]:
´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).´

The worst case scenario is the following. An attacker retrieves a public
key owned by another entity. The attacker then pretends the possession
of the corresponding private key and applies for a certificate. As a
result, the CA MUST resolve the subsequent dispute.   

>It MANADATES POP in order to support those applications
> that require it without change to application or to certs.
> Applications that don't require POP work in all circumstances, but
> the can also life with POP guaranteed by the cert. Applications that
> need are broken if they use certs for which not pop has been performed
> by the CA.
> 
> Of course one can always live with a policy based approach:
> The user always knows what kind of certs can be used with a
> particular application. Then, one might argue that all
> cert constraints are superfluous?
>
> PRETEND means pretend, and not more. The user who want
> that public key cert PRETENDS to have the corresponding secret.
> If the key generation is not done by the CA (in a large sense),
> then the user always first pretends to have a secret.

The CA then MAY issue a certificate with pending status. Then this
certificate SHOULD be added to the CRL with pending status. I think,
even though the certificate is sent to the applicant only the
certificate SHOULD be added to the CRL.
 
> The CA/RA then can use some mechanism to ensure POP.

After that the certificate status changes to valid, i. e. the
certificate is no longer present at the CRL.
 

> > >
> > > As a consequence, an application must always do that, for
> > > example when signing a challenge or document, the certificat
> > > (or something equivalent) must be included in the signature.
> > >
> > [Juergen] As a result, the application plays the role of the trusted
> > third party. I think this approach is different  from that one described
> > in the CRMF draft.
> Why does the application play the role of a trusted third party?

The application then validates the binding between the end entity`s
public key and the end entity`s identifier (e. g. common name). Firstly,
the application must validate proof of possession of private key.
Secondly, it must validate the congruence of the public key used in the
POP processing and the public key certified by the CA. As a consequence,
the application has a trusted position.

> 
> The difference betwwen a CA that performs POP and another that doesn't
> isn't that big. It is just that, it didn't perform POP. 

I disagree. There is a big difference between trusted CAs and trusted
applications.

>All the other
> guarantees, naming plan, identification etc. are still the same.


I resume that PKIX specification still
[CMP] ´MANDATES that CA/RA entities MUST do POP (by some means) as part
of the 
certification process.´ 

Therefore, an additional extension that the CA ensures POP is not
necessary at this time. I prefer to use the pending status until POP
processing is completed by the CA/RA.
-- 

Juergen