> Bear Giles wrote: > > > > Of course, this opens the whole can-o-worms of "what constitutes > > a duplicate cert?" Is it an exact match, or matching I+SN, or > > some other criteria? > > There are some cases where only an exact match is acceptable. An example > is how OpenSSL performs a verify operation on a single self-signed > certificate. It looks up the certificate from the trusted certificate > store and trusts it *only* if the certificate precisely matches the one > from the store: this is done by comparing the hashes of the whole > certificate.
This is the precisely the type of stuff that should be well documented in a "plugin implementor's guide." I've been going through the RSA documents, Gutman's papers, and implemented a cert store in java and this never occured to me. > If it only did an I+SN match then an attacker could readily generate a > self-signed certificate using its own key with matching I+SN. But a self-signed cert is easily identified and could be flagged for special handling. By removing them from the standard population we may be able to simplify rules for all other certs. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
