Not a stupid statement, but incorrect nonetheless ... :-)
Examples where I may reuse the key include:
I may choose to use my crypto token with it's key to register
for certificates from more than one CA. A certificate is
nothing more than a binding of an identity with a key. It
is the tuple that counts, not the key. The key as identity
is an SPKI hallucination. Further, I may choose to retain my
key after expiration of the first certificate validity period.
Note that as a practical matter, it is impossible for CAs to
search each other's key spaces to ensure global uniqueness ...
The difficulty is that we know that different CAs will have
different quality of practice and the application has potential
to become confused. Note that it is the application that has
the problem though.
I think this is an application issue and can be solved by binding
the signing certificate chain with the signed document.
This issue has been dealt with before although not widely
discussed. One might consider including the chain in the
hash calculation for the signature. Other methods could
also be derived.
Regards,
John Lowry
At 08:39 AM 2/25/98 -0500, Stephen Klump wrote:
Hello,
Stop me when I write something dumb.
One should never, never issue two (or more) certificates for a single
key.
If anyone allows this, they have forgotten the root word of
"certificate"
is "certify". A certificate that shares a key with other certificates
is
worthless because it does not certify anything. If your company assigns
any kind of legal or civil liability to a certificate, and then it goes
and
issues multiple certificates for a single key, your company is going to
get
bitten one day.
Having said that, it still can't hurt to put a SEQUENCE OF
IssuerAndSerialNumber
(one for each signer; gives capability if people want to implement
multiple signers)
in the authenticated attributes; we can just check them against the ones
in the signerInfos.
Cheers,
Stephen - Entrust Technologies
----------
From: Jim Schaad
(Exchange)[SMTP:jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com]
Sent: Wednesday, February 25, 1998 1:25 AM
To: Ietf-Smime (E-mail)
Subject: Inclusion of the issuer and serial number in authenticated
information
In discussions with other people here at Microsoft about the questions
of building certificate chains and what you sign with (a certificate or
a key), we came up with an interesting security hole from a legal
standpoint. If a person gets more than one certificate for a given key,
a person could switch certificates in the signed data object to the
other certificate thus potentially changing the legal liability of the
signature.
To address this problem, I strongly suggest we do the following:
1. In CMS we define an authenticated attribute which contains the
issuer and serial number of the certificate which was used to sign the
message.
2. We require this new attribute to be included in the
authenticatedAttributes section of the message if one exists. (We can't
do anything about the problem if it does not exists.)
If the list thinks this is a problem which needs to be addressed, I will
come up with a detailed proposal to fix this and submit it to the list.
jim schaad