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

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

Steve,

I already agreed that I was not going to fall on my sword over the issue
of never, ever allowing two certificates to be issued for the same key,
at least in part because I don't know any possible mechanism for enforcing
such a rule if the user goes to two different CAs for the two certificates,
perhaps under two slightly different names or name forms. I suppose that
once we have established the principle, as the saying goes, all that
remains to be argued about is the price,

On the other hand, I am somewhat troubled by your example of deliberately
using a short validity interval to minimize the CRL problem, and re-certifing
the old key with a new certificate.  You may have minimized the CA's storage
space problem, and also minimized the bandwidth required to transmit the CRLs,
and in your new position as CTO for GTE CyberTrust (congratulations/ condolences :-)
I can understand that point of view, but rather than having eased the CRL management
problem I think you have compounded it, at least from the user's standpoint.

As Andreas Berger correctly pointed out, and I certainly should have, unless the
certificate is actually incoporated within the document which is being signed, it is not
deterministic which certificate was actually intended. Certainly in S/MIME (and PEM)
the certificate was carried in an unsigned attachment, and could therefore be
substituted or deleted, if indeed it was transmitted at all. it was this very possibility
that lead us to require proof of possision of the private key, so that someone
couldn't extract someone else's public key and include it in his own certificate,
and thereby claim authoriship for a signed document.

Certainly in the case of software-stored keys, there is no shortage of bits, and
there is very little reason I can think of to use such a re-certification mechanism
instead of a key update/replacement scheme.  Granted, in the case of a
centrally managed hardware token it may be slightly more difficult to
regenerate keys, especially in view of the power requirements for good hardware
key generation that was recently discussed on the cert-talk list in connection with a
Smart Disk, but I am not entirely convinced about that either.

I guess my recommendation would be for PKIX to officially deprecate recertification of a key
as generally undesirable without, as David Kemp says, A Very Good Reason, but not
to prohibit it entirely. Within that overall guidance, CAs and users (and relying parties!)
can make up their own mind what do to.

If as a CA you want a user's and potential relying party's point of view, I personally
wouldn't put a lot of faith in any CA who would countenance such actions, and I
would certainly want to see notice provided in a CA's CPS that would warn me of that
possibility. If a given CA issues multiple certificate for the same key _without_ informing
relying parties, I would be inclined to say that they were being derelict in their duty.

I'm going to bring this issue to the attention of the group within the ABA Information Security Committee that is drafting CA Accreditation Guidelines, so they can consider it further.


Bob



>>>> Stephen Kent <kent@bbn.com> 03/04 7:21 AM >>>
>Bob,
>
>Ignoring issues of non-repudiation (for which only some certs may be
>employed), it may be reasonable for two certs to hold the same public key.
>For example, A CA may choose to have a short validity interval to ease CRL
>management, but not require users to generate and transmit new key pairs to
>match the interval.  In that case, the CA can merely re-certify the old key
>and reissue a cert with a new serial number and the same name, and probably
>all the other attributes would be the same as well.
>
>Steve


Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."