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

[Bill Burr <william.burr@xxxxxxxx>]

At 03:20 PM 3/4/98 -0700, you wrote:
>Bill, I've already done my mea culpa's for the "signed by a certificate"
>imprecise usage. Rather than reiterate the argument yet again, I
>would be interested in your reaction to my recent reply to
>Tony Bartoletti.
>
>Havin' fun stirring up the hornets,
>
>Bob
>
>
>>>> Bill Burr <william.burr@nist.gov> 03/04 2:27 PM >>>
>Bob,
>
>But do we sign with a certificate, or with a key?  I don't think that key
>and certificate are synonymous.  If the context of the certificate matters
>to the signature, then I should include the certificate in the signed
>message.
> [snip]
>
>

Bob,

Sorry that I hadn't read your response to Tony.  The moderation of this
list seems to induce some delay in the loop.

I think that you may be right to suggest that a signature should be
cryptographically bound to a particular certificate.  But I don't see how a
one certificate per key rule does that, because there isn't any strong way
to enforce that rule.

It seems to me that, if it's important when I sign a message, that I'm
signing as Bill Burr, of NIST, as opposed to Bill Burr, a member of the
garden club, that my message had probably better make that clear, possibly
by including the certificate in the signed part of the message.

If I don't do that, and I have many certificates for a key, then I probably
must accept that a relying party can reasonably choose any of those
certificates, with whatever consequences that brings.

Moreover NIST might well choose to insist that I not use a key it
certified, in any other certificate.

The most serious problem that multiple certificates per key brings, it
seems to me, is revocation, for the particular case of key compromise.
But, at the moment, I'm not sure that today we have an accepted general
answer to revocation.  I think that one model, which would more or less
work today, is for a CA to issue certificates with short validity periods
(hours or a few days), and dispense entirely with CRLs, OCSP, etc.  The CA
could, for example, sign a new certificate every day, with, say, a two day
validity period.  If I, or a relying party need my cert. today, we go get
it from the repository, perhaps for a small charge. I think that this means
more than one certificate per key.

This doesn't solve the key compromise problem, if I have a lot of different
certificates for that key, but it may be a reasonable way to avoid the
problems of CRLs or on-line status protocols, with their baggage.

I'm just reluctant to embrace the one key, one certificate principle, until
we have a little more experience with what actually works.
Regards,

Bill Burr