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

[Juergen Walter <walter@xxxxxx>]

Peter,


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

Here I was not carefully enough. For clarity, I think that a public key
must be uniquely mapped to the entity who is the subject of the
certificate. There may be entities who have more than one keys. But one
public key that is certified for two entities who live in the same CA`s
domain is a critical implementation. Because, the relying party that
validates the corresponding signature may argue that he does not know
who has signed the data. Then  certificates in the PKI (where it is
allowed to have two entities owning the same key) end up being somewhat
less meaningful.
> 
> An entity that owns a key can already get this key certified under
> several identities. 

See above. I would argue that a PKI that does not detect the
certification of one key under several identities is weak. Weakness
means that the issued certificates are less meaningful for relying
parties. 

> What you do no longer have is a one-to-one
> relationship between an entity and a key. The entity still has
> to prove possession.
> 
> >
> > > 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.
> Yes, but not necessarily the CA.

I beg to differ. In order to meaningful certification services it should
be done by CA/RA. Who is responsible for POP in your model? 

> >
> > >
> > > A worse case is that I go to a CA/RA and try to get an cert
> > > with MY key and YOUR identity.
> BTW: This has successfully done with a least one well known CA provider.

As a result, the certificates issued by this CA provider are less
meaningful. Why should the relying party use such certificates? 
 
> If you have an end entity that uses a secret in order to sign something,
> there end entity has to invest something that is reasonable for that
> application. Performing a proof of possession does not cost more, since
> the needed security is identical.
> 
> CA activity has several area where different levels of security are needed.
> POP processing must operate at on the level as the usage of the secret key.
> For "general or multi purpose" certs the maximum level of any usage must be
> met.
> The certification itself, i.e. the usage of the CA secret must be protected
> at least in the same way.

Basicly, I agree. The nuances where we differ have been already stated
above.

 >
> > >
> > > 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.
> I don't understand. What attack? Getting a cert, or replacing a cert inside
> a signed structure?

Applying a certificate.
> 
> > 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 CA operates a repository. The CA would detect when someone apply for
a certificate who does not possess the private key on the one hand,
and/or who changes his identity for a key that has been already
certified, on the other hand. In addition, the CA uses well-recognized
procedures for the identity check of the applicant.

However, the CA I recommend would not issue a second certificate for the
same key under different identity. The replacement attack would never
appear.

> 
> > > 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.
> Example: Take a CMS SignedData object, define an signed attribute that
> just contains a cert in question, tell me where you need pop at the CA
> level.

For the integrity of the object itself surely not. But, if I wish a
strong authentication, then the underlying certificate comes in
question. This is exactly the point, where we differ. Before the CA I
advocate have issued the certificate, the CA had done POP by any means.
Not to consider the case that this CMS SignedData object is the
certification request itself (see [PKIX CMC]).
 
> 
> >
> > 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.
> Good.
> I would say: A PKIX compliant CA that doesn't perform pop, must
> indicate this in a critical extension. Whether one should define such
> a general extension in the actual pkix doc is another question.


-- 

with regards

Juergen