POP profile in CRMF /Was Re: generation of private keys

[Juergen Walter <walter@xxxxxx>]

Peter,

Peter Sylvester wrote:
> 
> >
> >
> > > 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.
> 
> This text has to be read in the context of an application that does NOT
> perform POP. 

I suggest that this text is replaced by the proof of possession profile
contained in [CMP].
 
> Such applications must be sure not to use a certificate
> for which POP has not been done by the CA. That's all.
> 
> I do not see why a CA "MUST" solve a dispute.

As a result, the binding between end entity`s identity and its public
key may be no longer one-to-one.

> Anyone can do this.

If it is a strong binding between end entity`s identity and its public
key is desired, then someone should be responsible for this.

> 
> A worse case is that I go to a CA/RA and try to get an cert
> with MY key and YOUR identity.
> 
> > > 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.
> I am talking about the situation where a CA will never do a POP
> because all certs that it creates are made for a usage in
> applications that do not require 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 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.
> All applications that tell "yes, dear X, Y has done something."
> can be seen as "trusted third entity". Whether the application contains
> a pop logic or not doesn't change that.

I think this is the point. It is recommended to use trustworthy systems
for CA operations including POP under certain audit procedures and
security measures. This raises additional costs that end entities will
unlikely pay for it. In general, CA equipment has higher assurance level
than end entity`s equipment. If it has not, then I agree.

> 
> Example:
> Add an authenticated attribute to a CMS SignedData object,
> which contains a public key certificate for the secret key that
> is used to sign.
> 
> An attacker can always try to get another cert for the same key under
> another identity, but to replace the authenticated attribute is as difficult
> as falsifying the signature.

An attacker can try this. The PKI I advocate would detect this attack.
The reason is twofold. The attacker is not able to produce the POP token
unless he possesses the private key on the one hand, and the attacker is
not able to include the identity proof in its request unless he has this
identity on the other hand.

> 
> > > 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.
> Where do I talk about the difference between a trusted CAs and
> a trusted application? I talk about CAs that do not want to do pop.
> 
> >
> > >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.´
> Please read the sentences that follow this statement.
> 
> > 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.
> maybe I wasn't clear: I asked for the opposite.
> A critical extension that is present when POP has NOT been performed
> by the CA.

For clarity, I think that it is still MANDATED that the CA does POP by
any means. Hence, the case that POP has not been performed by the PKIX
compliant CA will not appear. As a consequence, no additional extension
is necessary.

In contrary, if there will be a PKIX compliant CA that will not perform
POP by any means, then the suggested extension would be fine. 

-- 

Juergen