Subject: Re: generation of private keys

From: Peter Sylvester <[email-masked]>
Date: Mon, 7 Dec 1998 15:33:47 +0100

> 
> [Juergen] Why not? The CRMF draft MANDATES proof of possession. Can you
> point out to me what does it mean PRETEND. Everybody is able to retrieve
> someone else`s public key and PRETENDS to own the corresponding private
> key. I think that the strength of the mechanism is the point. But I
> would not tend to map this to a certificate extension. This is a concern
> of the certification policy. [Juergen]
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. 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/RA then can use some mechanism to ensure POP.

> > 
> > 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 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. All the other
guarantees, naming plan, identification etc. are still the same.

---

From: Juergen Walter <[email-masked]>
Date: Tue, 08 Dec 1998 12:43:34 +0100

Peter,

> 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

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.

> 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.

> 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

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