Bear Giles wrote: > > > What would you classify as "bad data" in this case? > > A fake root cert and HTTPS certs. Then you do a DNS attack, the victims > get the blackhat HTTPS site but when they check the public cert respository > it comes back with a full cert chain. > > Ditto bad object signing certs, bad S/MIME certs, etc. > > Prime example: the bogus Microsoft cert Verisign issued a while back. > That's precisely the type of thing I have in mind. (I doubt Verisign > would use my postgresql extensions and these plugins, but a university > or midsized company might. Want to get a quick A average, or sidestep > a difficult course?) >
So how would protection against such "bad data" be done at the database level? > > What I meant to say was that some checks are easier to perform outside > > the plugin and may be application specific. > > I agree that some checks are easier to perform outside the plugin, but > my point is that sometimes a plugin may be designed for a specific role > that requires it be more aggressive about checking the data for itself. > "Weakest link in the chain" and all that. > Yes I suppose so. For some applications either a simple file based or memory based database would be appropriate. Its not that appropriate for a big CA, though that hasn't stopped some people using the index.txt stuff for that purpose. > > Is there some specific reason why the API should return a "key" at all > > and not just the certificate (or whatever) it corresponds to? > > As I've mentioned elsewhere, Enterprise Jave Beans. I know this is C, > not java, but it isn't hard to write a JNI layer to bind the two.... and > a lot of routine chores are a lot easier in java than in C. > I'm not sure where that Java reference fits in, but I don't use Java much. > There's also the issue of memory requirements. If your plugin is > covering the cert store for, oh, a major state university you may have > 50,000+ certs in it. Do you really want the system to try to allocate > sufficient space to hold *that* response? Actually I wouldn't want the API to be designed such that it would have to return 50,000+ matches at all. PKCS#11 for example handles this by system where the first/next n matches can be retrieved and the search can be terminated without retrieving all matches. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Gemplus: http://www.gemplus.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PX-Mozilla-Status: 0009 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
