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

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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