Steve,
Just to be sure we are on the same page, the issue revolves
around the fact that if two certificates, potentially with different
attributes and hence (perhaps) legal implications, both have the same
public key, then it is cryptographically indeterminate which certificate
should be used to validate the signature.
The fact that you have "A" signature chain of the sender does not
necessarily mean that you have "THE" corrrect signature chain, unless
you have cryptographically bound into the document itself, (or within the
signature macro or signing process) an adequate identifier of the certificate
itself.
The identifier does not necessarily have to be the issuer and serial,
although that would be adequate. A hash of the certificate would also
suffice, and might even be better, if there is any chance that the CA might
reuse or otherwise screw up serial numbers. Assuming there are any other
differences, a hash of the certificate would also help to differentiate between
two CAs that had the same name, but for example different issuers, etc., etc.
We discussed on the PKIX list the need to tie an e-mail message to a
specifc certificate, in particular in the case where the same public key has
been
included in two certificates with different expriation dates, different
attributes,
etc. We agreed to move that discussion to the S/MIME group, since they were
working in that area.
If you want to "tie" an email message to a certificate (specific or
otherwise) you need to be able to verify the messages signature. This
usually necessitates the posession of the senders certificate chain.
At this point what you put in SigningCertificate is there solely to
verify the right certificate is being used.
The point of course is that "solely" is still very important.
If you can assume posession of the senders certificate chain then OCSP
should be happy: any information it wants is available.
The proposal of using simply the hash of the certificate does not work
... because of the minimum assumption we are making in the PKIX WG: the
OCSP has only access to the newest CRL but no access to the individual
certificates themselves. Under such assumption the OCSP is thus UNABLE
to verify the hash of the certificate and therefore to make sure it is
pointing to the right certificate. For solving the case Ambarish
proposed to replace the hash of the certificate by the hash of the
public key of the CA, which is a technically adequate solution.
I wasn't arguing pro or con OCSP. That was Denis. I do understand
the argument that IF OCSP only has the CRLs and not the
certificates, it cannot validate a hash of the ecetrtificate. Whether
that means the OCSP is braindead or the greatest thing since
sliced bread is another topic.
Bob