Raj writes
Given that a principal with one DN may have had multiple certificates
each possibly containing different keys, there is a need for a way to
precisely identify the key that was used to construct a signature.
(Full message from Raj is below.)
This is a problem we've seen also. Cryptographically speaking, what's
important is which key is used to sign a message, not which person
(i.e. distinguished name), since one name may be associated with
multiple public keys over the life of that name.
Therefore, I suggest that the best way to identify a signing entity is
by public key, not by name. Instead of looking up a certificate by
subject name to get the public key, we should be looking up a
certificate by public key to find out the name (or names) which own
it. If you can find valid certificates which give different names for
one public key, it doesn't matter cryptographically. Any one of those
owners could have signed the message so you can't be sure which it is
anyway.
To avoid being burned at the stake for proposing a radical change to
PEM, let me suggest a simple change. Raj proposed clarifying the
issuer of a certificate by including "the serial number of the
signer's public key certificate". Since it's really the public key we
should use to find the issuer's certificate, not the serial number,
possibly the new unique ID field could be used to store a hash of the
right public key.
However it's done, it's the public key of senders of signed messages
(and recipients of encrypted messages) that should be used as
identifiers, not names. The public key is the only thing that
accurately describes which private key created the signature (or which
private key should be used to decrypt an encrypted message).
- Jeff
================================================
Included message:
Bob (Tongue-In-Cheek) Jueneman says:
we won't be able to implement this highly desirable feature correctly until
X.500 '96.
More seriously, does any one see a need for the following extension to
the SIGNED macro ?
A certificate signature needs to include the serial number of the signers
public key certificate that can be used to verify it, and (/or) the date
the signature was generated.
The rationale for this is that the certificate signer (parent CA) may
need to periodically change its key pair. This change could be planned
(policy driven) rather than unplanned (due to a compromise). I am assuming
now that the CA would not have to reissue all certificates and CRLs
with its new key. I am also assuming that the CAs old certificate, which
had expired naturally, is readily available in some archive.
Given that a principal with one DN may have had multiple certificates
each possibly containing different keys, there is a need for a way to
precisely identify the key that was used to construct a signature.
If the signature date was included, then with some work, the correct
certificate could be deduced. The validity period in the certificate
is inadequate because a certificate may be post dated.
Without such additional info, the verifier would have to iterate through
multiple certificates. If all certificates were not readily available,
the verifier would not be able to distinguish between the error conditions
"Invalid-Signature" and "Unable-to-Verify-Signature"; these two conditions
should be handled differently.
-raj