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

[Tony Bartoletti <azb@xxxxxxxx>]

Dave,

At 08:57 AM 3/10/98 -0500, David Kemp wrote, in part:
>
>Tony's characterization is eloquent enough that it cannot be improved
>upon, but merely restated.  By following the "wallet and paper signature"
>model and having a single public key which announces "This Is Me!", users
>would be voluntarily adopting the very thing they refuse to have
>imposed upon them externally: a national ID.

Thank you for the generous characterization.

>My primary objection to multiple certification is the lack of handling
>flexibility, not usage tracking.  If certificates are analogous to the
>contents of a wallet, then I would like to be able to dynamically decide
>what to carry in my wallet depending on where I'm going.  Normally I'd
>carry everything, for convenience.  But if I'm going on a trip, I'd
>remove the cards I'm not expecting to need so that if the wallet is
>lost or stolen, I don't have to cancel everything.

[minor snip]

>I might normally want to keep my "AMEX Platinum" key on my smartcard,
>but if I were going to plug that smartcard into a mall kiosk or an IETF
>terminal room machine, I'd rather take the AMEX key off and leave just
>an S/MIME email key on the card.

Agreed.  This is another Very Good Reason for separate keys.

>The third objection to multiple certification is that it leads
>inexorably to a permanent key that cannot be updated.  Although it is
>impossible for a single CA to verify that a key has not been certified
>somewhere else, it is certainly possible and often desirable for that
>CA to ensure that the key is changed at renewal.  But if a single key
>is used for all certificates, and the validity dates for all CAs are
>not synchronized, then it is impossible for any CA to rekey it's own
>subjects' certificates, much less establish rekey periods that are
>appropriate for the purpose of the certificates.

This is the one point I don't quite follow.  If a CA feels that the time
has come to expire *its certification* of a key, and to require that the
owner have a new key certified, I don't quite see how independent
certifications that have not expired need to be factored in.

At least, not "in principle."  Of course, this assumes that the relying
party can demand the key possesses a valid certificate suitable for the
*purposes of the transaction*, and did so at the time of the signing.
This "missing linkage" of signature to certificate, and how to address it,
is being debated by Bob Jueneman and Denis Pinkas at present.

And as Dwight Arthur pointed out, "cross certification" cannot exist
without there being multiple certificates on a single key, and so the
protocol must deal with the situation.  If in particular, then perhaps
best in general.  Granted that in this case, the certificates may be
considered "equipotent" and so the issue of "which one" is less pressing.

Personally, I would avoid overloading any key, of course, for the other
reasons you have given.

I am curious that no one took me up on what might be another source of
key-overloading;  A "low-cost CA" willing to issue a narrow attribute,
role or authorization certificate, and relying upon the existence of a
"classy ID certificate" for its validity, the CA essentially riding
piggy-back upon the due diligence of the more reputable CA.
Good examples don't come to mind, but I just get a feeling...

___TONY___



Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL