Re: [IETF-PKIX] Multiple certificates for same key?

[lars.gu.johansson@xxxxxxxxx]

Sorry for this late reaction but it's been quite a task
just to read all the contributions to this thread. I think
the discussion so far have been very biased to, let me say,
the "American soft-token" perspective. So, being a native
European, let me improve that situation slightly.

(I've noted that this thread actually has been split up in two.
Therefore I'll respond to the issue of "cryptographic binding
of certificates to signatures" in a separate mail.)

Some people have argued that there's too many security risks
involved when dealing with multiple certificates of the same
key that it should be prohibited (or at least not recommended :-).
I could give you many reasons why there shouldn't be any such
restrictions but let me just give you an alternative perspective.

In my point of view, multiple certificates of the same public key
is not the problem. I think this is entirely a policy issue. The
problem is instead storing of the private keys in software.

In the Swedish electronic ID-card project (www.seis.se) the
private keys are centrally generated by the CA and stored in
the key-holders smart card. The RSA operations are performed
on the chip so the private key never leaves the card. It is even
unknown to the key-holder. This is of course stated in the CA's
policy and CPS.

Now, if another CA would issue an alternative certificate to the
same key-holder and the same key (e.g. containing a different
email-address) this wouldn't normally cause any problems.

Either the other CA could require the key-holder to present his
"base" certificate in the certificate request before a new certificate
could be issued. In that case, the 2nd CA could check the original
CA's policy and CPS to see how the key was generated. It would
also be a way of prohibiting the key-holder from getting a certificate
in another persons name.

Or, in the other case, the 2nd CA doesn't do any such checking
against any base certificate in which case the relying party could
chose not to trust that CA's policy. Identification of key-holders and
key generation is perhaps the two most important issues within a
policy or CPS document.

What's needed is an option of sending an older certificate within a
certificate request to the CA.

Obviously, things gets more complicated when dealing with soft
tokens. That’s why we've chose not to do that (primarily) in the
Swedish SEIS project.

Kind regards,
/Lars Johansson
Sweden Post