Bob Jueneman wrote:
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.
Yes same page so far :-)
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.
Indeed, that was why I proposed it. If you have hash of certificate it
gets bound to the whole thing including the issuers signature and thus
indirectly their public key.
If you just have issuer and serial number you are just duplicating
what's already there whereas IMHO this opportunity should be used to use
a more cryptograhically strong bind that covers more information.
It doesn't stop substitution of the other certificates e.g. the CA that
signed the issuers certificate nor does it protect against substitution
of the issuers certificate (or any other CA certificate) with an expired
version with the same public key. Though there have been other proposals
that can cover that (if it is deemed serious).
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.
Well I wasn't commenting on OCSP as such. Just on OCSP in the context of
S/MIME: namely that even if OCSP can't verify the hash of the
certificate the S/MIME implementation can and can also compile whatever
information OCSP requires.
Since the information wont be present in SigningCertificate (and the
attribute wont be there) in a v2 or sub-v2 implementation anything that
relies on this for OCSP will be unable to handle such messages. I don't
think they will vanish overnight as soon as OCSP and S/MIME v3 are
finalised so anything using OCSP would be well advised to handle older
messages: as mentioned in the specs if I recall.
Steve.
--
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)bigfoot(_dot_)com
PGP key: via homepage.