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

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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

Again, if the PKI does not perform POP, then a signing application must
include some pop, and a verifier must be able to verify this. 

The certificates without pop do NOT indicate that an entity OWNS a key.
They only indicate that the entity is identifiable by the CA. 


> > 
> > 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. 
Well, I was unprecise: There are several possibilities: 

One single entity can get one key certified by several CAs, or for
different roles. That's only a problem for the user, if the key is
broken, all entity roles have to be revoked. Thus, an entity is
highly interested to have several roles.

If key generation is done by the end entity, then it *MAY* happen that
the same key is generated twice. If the CA refuses to certify, then ...


> 
> 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? 
As in real life: The two entities in question. How this actually done
depends on the application context. 

> 
> As a result, the certificates issued by this CA provider are less
> meaningful. Why should the relying party use such certificates? 
Why not? Why should a relying party should use a certificate at all. 


>  
> > 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.
ok, you mean applying for 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.
I don't care if a CA detects whether the the applicant possesses the secret.
I am in an application context where the application does that. 


> 
> However, the CA I recommend would not issue a second certificate for the
> same key under different identity. The replacement attack would never
> appear.
Assume key generation by the user, the CA refuses to create a certificate
because by chance (extremly rare) the user created the same key as another one.
... 

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

You get exactly the same authentication as with a pop procedure done by
the CA and the certificate in question not included in the data.

- The CA uses some operational environment to perform pop that must be at
  least as safe as the application context X. Thus you have a pop with 
  a safety degree X+delta. 
  The application context that creates and validates the usage of the
  secret (for exemple a signature on a document), has a safety degree
  of X. The combined safety is still X, the delta can be as high as you want.

- Or in other word, it is sufficient to have a safety of X during pop
  processing. you just have this safety degree in the application
  context, thus, include pop processing is in the application and you 
  are done.