Re: POP section for next Roadmap draft

[Juergen Walter <Juergen.Walter@xxxxxx>]

Denis,

thanks for the response. I stick on the issue why POP-CAs ensures key
uniqueness. The other issues remains open for the moment, I apologize.

To avoid misunderstandings POP by some means is ensured when the CA has
verified the binding between the private key and the public key, that
the entity wants to be certified. The concrete means are surely policy
matters and therefore outside the scope of PKIX.

More comments follow in line.

Denis Pinkas wrote:
> 
> Juergen,
> 
> Sorry for the delay. I have had difficulties to find some time available this week.
> 
> > Denis,
> >
> > I agree essentially with Al´s position. I would like to add some
> > comments.
> >
> > For non-repudiation key usage the CA must ensure that the public key is
> > UNIQUE.
> 
> I do not believe so.

I have to be more precise if I recommend public key uniqueness. More
precicely, I think that the risk of public key clashes should be
sufficiently small. This residual risk is again a policy matter and
outside the scope of PKIX work.
 
> Even if this would be the case, all the CAs of the world would
> not be bale to interconnect to verify this.

This is not necessary. But CAs can ensure public key uniqueness
implicitly. If they do POP then they ensure that no entity who does not
own the private key becomes certified (i. e. the CA issues a certificate
that contains the corresponding public key). CAs may recommend the usage
of a suitable key generator. Let me assume that this key generator works
correctly. Then the event of identical keys owned by two entities 
unlikely happens. An element of risk remains but this is certainly
small. Surely it is close to the risk of a brute force attack of the
signing key under the assumptions above. All public keys that are
distributed by CAs are (almost) unique. The distribution mechanism of
public keys is that a CA signs the entity´s certificate. All other
mechanisms like directory, repository or whatever are operational
issues.

If CAs do not POP by any means then this fact is no longer true. Then
there probably exist certified public keys that are not generated by a
suitable key generator, i. e. either the corresponding private key is
unknown or it is known to another entity. "knowledge" should be
interpreted as ability to apply the private key.

The first case leads to public key reservation that is really stupid.
(Is it analogously to the domain reservation?) 

In the second case the phenomena of public key hijacking appears, i. e.
an entity may retrieve a public key and manage the certification by a
non-POP-CA. It is not necessary that this non-POP-CA coincides with the
CA that issued the certificate for the hijacked public key.

Is public key hijacking possible when we consider non-POP-CAs? What is
about the public key distribution function of a non-POP-CA? It seems to
me there may be a lot of waste in its repository.

The possible consequences remain for further discussion if I find some
time.

[snip]

Juergen