Re: SQL DB instead of index.txt

To avoid duplication of code I'd say such concerns should be addressed either at the application level or on top of whatever OpenSSL plugin API is adopted. I think that would be a serious mistake. I'm specifically thinking of something like the CA cert repository/JSP code in my postgresql

Re: SQL DB instead of index.txt

I can imagine that one might get the same certificate from several source, but I'm pretty sure it could be resolved but applying a little bit of automagic intelligence and tossing all duplicates except for the copy that has the highest trust attached to it. I was assuming this would be done

Re: SQL DB instead of index.txt

From: Bear Giles [EMAIL PROTECTED] bear Of course, this opens the whole can-o-worms of what constitutes bear a duplicate cert? Is it an exact match, or matching I+SN, or bear some other criteria? Depending on who you listen to, one could say it's the subject, others will say it's

Re: SQL DB instead of index.txt

Bear Giles wrote: To avoid duplication of code I'd say such concerns should be addressed either at the application level or on top of whatever OpenSSL plugin API is adopted. I think that would be a serious mistake. I'm specifically thinking of something like the CA cert

Re: SQL DB instead of index.txt

From: Dr S N Henson [EMAIL PROTECTED] stephen.henson Is there some specific reason why the API should stephen.henson return a key at all and not just the certificate (or stephen.henson whatever) it corresponds to? You might want to store keys alone for different reasons. Let's remember that

Re: idea_mul buggy ?

Anyway. That has not been the initial question. Is there anything wrong with the three different implementations of the mul procedure ? I think that's more important. Since (as you might have seen) mul1 and mul2 do generate different results due to the fact that the idae_mul1 macro

Re: Error Stack Question

Verdon Walker [EMAIL PROTECTED] in epsilon.openssl.bugs: We ran into a small piece of code in ssl_rsa.c that is confusing us. In SSL_CTX_use_certificate_chain_file(), the following code fragment exists: ret=SSL_CTX_use_certificate(ctx,x); if (ERR_peek_error() != 0) ret = 0; /*

Re: idea_mul buggy ?

The program iterates through all a's and and b's from 0-0x That should be sufficient Cheers Sebastian Bodo Moeller wrote: Anyway. That has not been the initial question. Is there anything wrong with the three different implementations of the mul procedure ? I think that's

Re: SQL DB instead of index.txt

Richard Levitte - VMS Whacker wrote: From: Dr S N Henson [EMAIL PROTECTED] stephen.henson Is there some specific reason why the API should stephen.henson return a key at all and not just the certificate (or stephen.henson whatever) it corresponds to? You might want to store keys alone

Re: idea_mul buggy ?

Sebastian Kloska [EMAIL PROTECTED]: Please provide example inputs where the results differ. A single a, b pair is enough. The program iterates through all a's and and b's from 0-0x That should be sufficient Given that you already ran the program and don't have to fight with the

Re: SQL DB instead of index.txt

Richard Levitte - VMS Whacker wrote: From: Bear Giles [EMAIL PROTECTED] bear Of course, this opens the whole can-o-worms of what constitutes bear a duplicate cert? Is it an exact match, or matching I+SN, or bear some other criteria? Depending on who you listen to, one could say it's the

Re: SQL DB instead of index.txt

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