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 library - it's designed to be the store that's published to the world as THE official repository for a CA. If it gets bad data stuffed into it, the security of an entire organization can be quickly compromised. In cases like this I don't think it's acceptable for the backend to depend on the good behavior of the application. There are many cases where you can use a trusting backend and keep all of the key logic in the application. But I don't think you can safely assume that the backend will always accept everything thrown its way. In such a case things like duplicate issuer and serial numbers may occur and should be protected against (at whatever level). I'm beginning to think that the plug-ins will just need to document such things and let the user decide. Even if this is a legitimate concern for an address book type application, many sites will only be concerned with their own certs and can guarantee the necessary uniqueness. I'd say that the actual plugin API should not concern itself with such details. I agree, but that doesn't mean there's no connection between the two. As a specific example, I think it's now clear that any key returned from a 'findByX' command must be considered opaque. Some backends may use hash-of-certificate, others hash-of-issuer-and-serial-number. This in turn restricts the type of caching that the application itself can do. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 by the application. It tries to store a cert, and if it gets an EEXISTS error (or the functional equivalent) then it's up to the application to decide what to do next. 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? BTW, this example also brings up the need for a replace operation. If you want to replace an existing CA cert, e.g., because someone tried to sneak through a time extension with the same SN, you would want an atomic operation since an intelligent backend may invalidate any certs signed by a deleted CA cert. Trust, BTW, could rather easily be handled by attaching internal attributes to certificates with extra information. Those attributes are not part of the certificate itself, of course. Was that approximately the way you saw this being done as well? What will this do to the whole-cert hash value? (I assume that the whole-cert hash is computed as the SHA-1 hash on the ASN.1 encoding of the cert... something that I can compute with ASN1_write_bio(), a mem BIO and a sha1 BIO. Or by another library crunching on an DER-encoded certificate in the underlying database.) I would rather see that applications can request indexes on a rather flexible set of basic types, and request searches according to basically whatever. The application can always make a request according to any criteria, the only issue is if the time required for the results. If it's on a hashed key, you get results in O(1). If you have to scan through all records in the database your results take O(n). That's why I want to use I+SN as the primary key - I can anticipate far more searches on that key than the whole-cert hash. If you're talking about fewer than a few hundred certs, the extra complexity required for secondary keys probably isn't worth the effort. If you have more than few thousand certs, you'll probably be looking at a RDBMS for other reasons anyway. In these cases you would want to create a secondary index on every searchable quantity anyway. Even if most sites fall into the middle, secondary indices (esp. of non-unique keys) are always a pain to get right. It's too easy to overlook a single error or race condition and get a flaky database. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 issuer+serial. It all depends on if you want to keep the history of a specific subject or not. This is of course taken from a X.500 directory perspective (where things were intended to be stored by subject, I believe (I'm sure Oscar will correct me if I'm wrong :-))). bear Trust, BTW, could rather easily be handled by attaching internal bear attributes to certificates with extra information. Those attributes bear are not part of the certificate itself, of course. Was that bear approximately the way you saw this being done as well? bear bear What will this do to the whole-cert hash value? Absolutely nothing. Those attributes would be part of the atabase record, not part of the certificate itself (which incidently can be viewed as another attribute of that record, if you generalise things a bit, and I think that's how things are done in, for example LDAP). bear (I assume that the whole-cert hash is computed as the SHA-1 hash on bear the ASN.1 encoding of the cert... something that I can compute with bear ASN1_write_bio(), a mem BIO and a sha1 BIO. Or by another library bear crunching on an DER-encoded certificate in the underlying database.) I assume the same. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 repository/JSP code in my postgresql library - it's designed to be the store that's published to the world as THE official repository for a CA. If it gets bad data stuffed into it, the security of an entire organization can be quickly compromised. What would you classify as bad data in this case? Actually I didn't word that comment too well. The database shouldn't accept everything thrown at it by any means. The API will to some extent restrict everything in that the data passed has to be in valid structure. What I meant to say was that some checks are easier to perform outside the plugin and may be application specific. For example a duplicate issuer an serial number in S/MIME may be the result of a broken certificate sent in a signed message or malicious intent and it should be possible to resolve this. A duplicate I+SN in a CA application is likely to be much more serious and may be a result of a fatal error in the serial number allocation. I'd say that the actual plugin API should not concern itself with such details. I agree, but that doesn't mean there's no connection between the two. As a specific example, I think it's now clear that any key returned from a 'findByX' command must be considered opaque. Some backends may use hash-of-certificate, others hash-of-issuer-and-serial-number. This in turn restricts the type of caching that the application itself can do. Is there some specific reason why the API should return a key at all and not just the certificate (or whatever) it corresponds to? 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] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 OpenSSL isn't just used by SSL and X.509 applications. I see this a little like hardware-protected keys, they are also just keys with no specific certificate tied to them. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-733-72 88 11 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, GemPlus: http://www.gemplus.com/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 doesn't do the '(a-b) + (ab)' stuff. Please provide example inputs where the results differ. A single a, b pair is enough. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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; /* Key/certificate mismatch doesn't imply ret==0 ... */
if (ret)
...
Isn't this a little strange to ignore the return code of the function
called and instead peek at the error stack?
The return code isn't exactly ignored, this is an alternative
condition that will be treated like a 0 return value.
There is certainly no
guarantee that any errors on the stack are from the call to
use_certificate
True. There are many places where OpenSSL should call
ERR_clear_error() before doing other things in order to avoid having
old error codes left in the queue and cause confusion. The theory is
that the application is responsible for clearing the error queue,
but in that case ERR_clear_error() wouldn't hurt either.
and even so, why check the stack rather than the return
code.
This looks like a hack to me. Is there a specific reason it is needed?
Yes: As the comment tries to explain, under certain conditions
SSL_CTX_use_certificate() will indicate an error on the error queue,
but still return 1.
Actually this appears to be a bug in SSL_CTX_use_certificate() (in
ssl_set_cert(), more precisely): It should call ERR_clear_error() if
it intentionally ignores an error returned by X509_check_private_key().
(Functions should not leave behind error codes without indicating
an error in their return value. Otherwise how is the application to
know that it should look at the error queue?)
But I can't make too much sense of the logic in ssl_set_cert() -- if
X509_check_private_key() fails the first time, does it ever make sense
to switch from SSL_PKEY_DH_RSA to SSL_PKEY_DH_DSA or the other way
around? Here's the strange part:
static int ssl_set_pkey(CERT *c, EVP_PKEY *pkey)
{
[...]
i=ssl_cert_type(NULL,pkey);
[...]
if (c-pkeys[i].x509 != NULL)
{
EVP_PKEY *pktmp;
pktmp = X509_get_pubkey(c-pkeys[i].x509);
EVP_PKEY_copy_parameters(pktmp,pkey);
EVP_PKEY_free(pktmp);
ERR_clear_error();
[...]
if (!X509_check_private_key(c-pkeys[i].x509,pkey))
{
if ((i == SSL_PKEY_DH_RSA) || (i == SSL_PKEY_DH_DSA))
{
i=(i == SSL_PKEY_DH_RSA)?
SSL_PKEY_DH_DSA:SSL_PKEY_DH_RSA;
if (c-pkeys[i].x509 == NULL)
ok=1;
else
{
if (!X509_check_private_key(
c-pkeys[i].x509,pkey))
bad=1;
else
ok=1;
}
}
else
bad=1;
}
else
ok=1;
}
[...]
}
No matter how this is resolved, the weird two lines in
SSL_CTX_use_certificate_chain_file() certainly can be omitted.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
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 more important. Since (as you might have seen) mul1 and mul2 do generate different results due to the fact that the idae_mul1 macro doesn't do the '(a-b) + (ab)' stuff. Please provide example inputs where the results differ. A single a, b pair is enough. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] -- ** Dr. Sebastian Kloska Head of Bioinformatics Scienion AG Volmerstr. 7a 12489 Berlin phone: +49-(30)-6392-1708 fax: +49-(30)-6392-1701 http://www.scienion.de ** __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 for different reasons. Let's remember that OpenSSL isn't just used by SSL and X.509 applications. I see this a little like hardware-protected keys, they are also just keys with no specific certificate tied to them. When I said key I didn't mean a private key. It would be a requirement of the API that private keys, certificates, CRLs and maybe other things like opaque data objects, attribute certificates etc could be stored. My comment was to a database key and that findbyX might return some kind of opaque reference to a database key. What I was saying was that some implementations might not have an equivalent to a database key and would have to fake one. Also if all you can do with the key is lookup the object it corresponds to then findbyX might as well return the object directly and have the key lookup in the plugin implementation and not at the API level. 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] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 bogus linebreaks added by you MUA, it surely would have been
simpler to just provide an example value (e.g. a = 0x8000, b = 0x0002) ...
Anyway, the problem is that your program does not use the macro
the way it is supposed to be used. Both the temporary variable
'ul' and the result variable 'r' must be 32 bit wide. (But only the
lower 16 bits of the result are valid, the other bits are to be
ignored.)
Note the r-=((r)16); in the idea_mul macro. This corresponds to
the +((ul0x) (ul16)) that you thought was omitteded:
After the first assignment to r, the value (r)16 is 0x or
0x. (There may be more bits on the left [64-bit architectures],
but they don't matter.)
#define idea_mul(r,a,b,ul) \
ul=(unsigned long)a*b; \
if (ul != 0) \
{ \
r=(ul0x)-(ul16); \
r-=((r)16); \
} \
else \
r=(-(int)a-b+1); /* assuming a or b is 0 and in range */ \
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
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 subject, others will say it's issuer+serial. It all depends on if you want to keep the history of a specific subject or not. This is of course taken from a X.500 directory perspective (where things were intended to be stored by subject, I believe (I'm sure Oscar will correct me if I'm wrong :-))). Consider me baited. :-) Two certificates sharing the same issuer||serial indeed pose a problem, and would need some additional form of dis-ambiguation without messing things -- revocation very notably -- up royally. Regarding certificates with identical subject names as duplicates wouldn't necessarily be a Good Thing though, for a couple of reasons: *) An entity can have different certificates with different purposes asserted: keyCertSign, cRLSign, keyEncipherment, digitalSignatures etc. *) An entity can receive certificates from any number of issuers. *) OTOH, I can't remember whether certificates are necessarily expected to be removed as soon as they are revoked, or only when they expire or even then. And what's to stop an entity from requesting an additional certificate even if they already posess a perfectly valid one. *) During CA certificate-rollover there might need to be at least as four separate certificates active for a given CA at once: self-signed about to expire, self-signed new one, self-issued old issues new and self-issued new issues old. Certificates were indeed intended to be stored by subject. After all, their raison d'être was to cryptographically authenticate said subjects to the Directory. The certificates stored in your subject entry would be those used to verify your authentication attempts. Without the Directory, or even a directory-like structure it's certainly tempting to defer to distinguished names as being little more than anachronisms. Maybe one could go so far as to wonder at the reasoning behind selecting X.509 Certificates for use as authentication mechanisms outside the realm of X.500, where the entities they are able to identify simply do not exist. I know Peter Gutman has outlined a means of using an RDBMS as a certificate store (1) and I think it ought to prove valuable insight into the types of keys that might be required/convenient. 1: http://www.cryptoengines.com/~peter/09a_cert_store.pdf //oscar __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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 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. 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. If an when OpenSSL verify permist trust explicit trust of an EE certificate without trusting the chain a similar criteria will need to be applied. 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] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
