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

From: Peter Sylvester <[email-masked]>
Date: Wed, 9 Dec 1998 19:26:07 +0100

> 
> I suggest that this text is replaced by the proof of possession profile
> contained in [CMP].

Definetely not. 

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

An entity that owns a key can already get this key certified under
several identities. 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. 

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

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

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

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

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

---

From: Juergen Walter <[email-masked]>
Date: Thu, 10 Dec 1998 12:28:58 +0100

Peter,

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

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? 

> 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? 
 
> at least in the same way.

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

> I don't understand. What attack? Getting a cert, or replacing a cert inside

Applying a certificate.
> > 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.

> just contains a cert in question, tell me where you need pop at the CA

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

-- 

with regards

Juergen