Re: SQL DB instead of index.txt
So how would protection against such bad data be done at the database level? If you know it's a CA cert repository, you can require that the issuer already be in the database. If this a deferrable constraint, you can still add root certs (e.g., to populate the database.) But if you remove the 'deferrable' attribute then you can't add new root certs at all! Of course a knowledgeable attacker with sufficient rights would just alter table certs drop constraint ca1; insert into certs values (bogo-root-cert); alter table certs add constraint ca1 check ( foreign key(issuer) references certs(subject)); but you can watch for that with a cronjob that periodically checks the database for root certs with unknown keyids. Since these should change so infrequently, the values can be hardcoded. (Or the truly paranoid could even put that into the database code itself - it would not be hard to modify my postgresql code so that it only accepts self-signed certs with keyids from another table and/or a hardcoded list.) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Another proposed DB API
I've been looking at the Java KeyStore API (which reflects the work of
a other bright people looking at the same problem) and have a revised
schema and proposed API.
SECOND PROPOSAL
---
The primary key is an opaque string henceforce known as the alias.
The plugin may treat this as a primary key, but must not attempt to
interpret it as a hash, email address, keyid, serial number, etc.
This means that all searches will be sequential scans unless a
secondary index has been explicitly created, even for hashed or
indexed storage mechanisms like Berkeley DB.
The attributes for each alias include:
- key (PKCS8?)
- certificate (X509)
- cert chain (stack of X509, PKCS7 or PKCS12 format?)
- creation date for entry
plus other attributes TBD, cached components, etc.
A KEY ENTRY may contain a key alone (secret key), or a key and
certificate (private key). In the latter case, the entry should also
contain the cert chain returned from the CA.
A CERTIFICATE ENTRY contains a certificate alone.
The required operations are:
int containsAlias(char *alias)
Check if specified alias exists in the keystore
void deleteEntry(char *alias)
Delete the specified entry. May fail if against plugin security policy
Enumeration getAliases()
List all aliases in the keystore
X509 * getCertificate(char *alias)
Retrieve the certificate associated with the specified alias
char * getCertificateAlias(X509 *cert)
Retrieve the alias of the first keystore entry whose certificate
matches the specified certificate.
?? * getCertificateChain(char *alias)
Retrieve the certificate chain associated with the specified alias
time_t getCreationDate(char *alias)
retrieve creation date for the entry. This is when the entry was
added to the keystore, not when the data itself was created.
PKCS8 *getKey(char *alias)
Retrieve the key associated with the specified alias
int getSize()
Retrieve the number of entries in the keystore
bool isCertificateEntry(char *alias)
return true if the entry is a CERTIFICATE ENTRY, false otherwise.
bool isKeyEntry(char *alias)
return true if the entry is a KEY ENTRY, false otherwise.
void load(BIO *)
copy BIO stream into keystore.
void setCertificateEntry(char *alias, X509 *cert)
associate the alias and certificate. May merge with existing KEY ENTRY
if the keys match. Will overwrite existing CERTIFICATE ENTRY.
void setKeyEntry(char *alias, PKCS8 *key, ?? *chain)
associate the alias, key and optional cert chain. The first cert in
the chain is treated as the 'certificate.' entry.
void store(BIO *)
copy keystore into BIO stream.
(Remember that java communicates errors through exceptions - we'll need
to change the return types on most functions.)
In addition, we would define additional functions including
Enumeration list(PATTERN *p)
list subset of aliases which satisfy some pattern. PATTERN would
be like we discussed earlier - something like
typedef struct {
enum {
SUBJECT, // X509_NAME
ISSUER, // X509_NAME
SERIAL, // ASN1_INTEGER
SHASH,// unsigned char[] (assuming SHA1 from Gutman paper)
IHASH,// unsigned char[]
IANDSHASH,// unsigned char[]
CERTHASH, // unsigned char[]
B64SHASH, // char *
B64IHASH, // char *
B64IANDSHASH, // char *
B64CERTHASH, // char *
COMMON_NAME, // char *
EMAIL,// char *
} type;
union {
type1 a;
type2 b;
...
} u;
};
and others TBD.
__
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: And from a pragmatic perspective, whole-cert hashes make a lot of sense. NB: I've only ever messed about with relational databases for a brief spell a few years back, so please excuse my struggling with the terminology. As primary keys go, I'm certain that whole-cert hashes would come in quite handy. They're trivial to compute, and for all practical intents and purposes guaranteed to be unique. As for lookups, I don't know in how many cases, apart from OCSPv2 apparently, a lookup on whole-cert-hash would actually be called for. You would definitely need to be able to do lookups by subject name though, in order to support path construction, and for convienence presumably on subject name||keyId as well. I guess these could then be used in supporting tables in order to look up foreign keys leading into the 'master table'. in order to avoid operational problems (e.g., with revocation), either (issuer,serial) can be treated as a unique identifier, or (issuer,serial,X) will be sufficient to uniquely identify each cert. The question is what is X? The issuer's key identifier? Authority key identifiers are MUSTs in both certificates and CRLs in accordance with the PKIX profile. I would be much more comfortable with treating issuer||serial duplicates as error conditions though. People should be much more careful with their trust management, and not just invite any old cert the browser brought home with it to stay. For building a CRL, an issuer needs to be able to retreive a list of all revoked certificates (serial numbers, revocation date, reasons etc.) given its name, or optionally its name||keyId if it partitions CRLs that way. There's bound to be loads and loads more use cases in there that need to be taken into account. Worse, it's easy to imagine a system where some uses will properly verify a cert, but less critical ones will just check the local cache. (Or the CRL information is unavailable, etc.) It's easy to imagine a situation where a cert is stored, then determined to be revoked, removed, then received again and stored again, I checked in X.509, and neither revocation nor expiry are necessarily grounds for removal from the Directory, as there might well be a need to verify old signatures etc. It's much better to keep an explicit status flag in the database. If a cert is revoked, the store may refuse to delete it until after it's expired to avoid such accidental reinsertion. Obviously some stores can't do this (smart cards, in particular, have limited storage), but it may be a recommended practice. I think this is very much up to the individual implementation. If you are working in a banking application you might conceivably be required by law to keep every issued certificate and CRL available for 10-20 years in order to be able to go back and prove/disprove the validity of old transactions. And yes, while they're quite handy for protecting and storing an end-entity's keys and certificates, a smart card certainly wouldn't be the ideal candidate for a PKI repository. I definitely think an RDBMS would be the way to go. Best regards, //oscar __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
As primary keys go, I'm certain that whole-cert hashes would come in quite handy. It's a mindset thing. A key should lead you to more information. Give me your name, I'll tell you your phone number and home address. Read off the tag on the back of the car and I'll tell you the make and model of the car it *should* be attached to and the name and address of the registered owner. A whole-cert hash, in contrast, is an attribute. It may be unique, but it tells me nothing about the rest of the data. It's like indexing books by the number of times they've been checked out. As for lookups, I don't know in how many cases, apart from OCSPv2 apparently, a lookup on whole-cert-hash would actually be called for. Once again, the issue is *not* lookups. EVERY plug-in will be required to suport EVERY lookup method defined at the time it's written. That's trivial to do with a boilerplate routine and some macros. The issue is existence is the choice of the key to be used for storage mechanisms that *require* a unique primary key. Berkeley DB, GDBM, hashed tables, etc. To date we've identified two candidates. issuer||serial (a legitimate search key) and whole-cert hashes (an attribute), and I'm about to propose a third. I guess these could then be used in supporting tables in order to look up foreign keys leading into the 'master table'. Secondary indexes, not foreign keys. The latter is when one (or more) attributes of a table is a primary key into another. E.g., if I have a table containing home addresses, the postal code attribute may be a foreign key into a table pcodes that contains the correct city and state, the timezone, etc. Secondary indexes (or indices) are a neat idea but they're a real pain in the butt to get right, especially once multithreading or concurrent access from multiple processes enters the picture. If somebody has enough data that they really need a secondary index, they should probably make the jump to a RDBMS backend. in order to avoid operational problems (e.g., with revocation), either (issuer,serial) can be treated as a unique identifier, or (issuer,serial,X) will be sufficient to uniquely identify each cert. The question is what is X? The issuer's key identifier? Authority key identifiers are MUSTs in both certificates and CRLs in accordance with the PKIX profile. Are we prepared to REQUIRE every cert comply with PKIX recommendations, without exception? And if we are, will this be adequate? I think this is very much up to the individual implementation. If you are working in a banking application you might conceivably be required by law to keep every issued certificate and CRL available for 10-20 years in order to be able to go back and prove/disprove the validity of old transactions. I wasn't clear - I was saying that we could recommend (not require) that the backend refuse requests to delete a revoked cert prior to its expiration, not that it should delete them when they expire. Even if unrevoked certs can be deleted at any time. The rationale is to avoid the race condition described earlier. And yes, while they're quite handy for protecting and storing an end-entity's keys and certificates, a smart card certainly wouldn't be the ideal candidate for a PKI repository. I definitely think an RDBMS would be the way to go. But a plug-in that transparently updated a smart card would be extremely handy. :-) That's what makes the design so hard - it needs to be able to handle everything from 8k smart cards holding a single veiled key and cert to RDBMS databases with 50,000+ entries. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Another proposed DB API
From: Bear Giles [EMAIL PROTECTED]
bear The primary key is an opaque string henceforce known as the alias.
bear The plugin may treat this as a primary key, but must not attempt to
bear interpret it as a hash, email address, keyid, serial number, etc.
I think I like the idea. Let's see what Dr Genson has to say.
bear The attributes for each alias include:
bear
bear - key (PKCS8?)
bear
bear - certificate (X509)
bear
bear - cert chain (stack of X509, PKCS7 or PKCS12 format?)
bear
bear - creation date for entry
About the certificate and the chain: the chain will add a lot of
redundant information, at least as I see it, since each component of
the chain will most obviously be in separate certificate entries. You
could of course have the chain as a stack of aliases. And also, if
the chain would be changed for any reason (that's absolutely possible,
as part of a cross-certification process, for example), that would
potentially be a LOT of entries to change. No, best leave chain
construction to run-time, wouldn't you say?
bear A KEY ENTRY may contain a key alone (secret key), or a key and
bear certificate (private key). In the latter case, the entry should also
bear contain the cert chain returned from the CA.
bear
bear A CERTIFICATE ENTRY contains a certificate alone.
Hmm, some of what you say is a little bit confusing. First of all,
most people use private key for what you call secret key (they use
secret key for it as well...). If you must do a separation, I'd do
it in three:
KEY ENTRY that contains a private/secret key only
PRIVATE CERTIFICATE ENTRY that contains cert and private key.
CERTIFICATE ENTRY that contains cert only.
But homestly, I can't quite see the puspose of those names unless it's
just to make description easier.
bear In addition, we would define additional functions including
bear
bear Enumeration list(PATTERN *p)
bear list subset of aliases which satisfy some pattern. PATTERN would
bear be like we discussed earlier - something like
bear
bear typedef struct {
bear enum {
bear SUBJECT, // X509_NAME
bear ISSUER, // X509_NAME
bear SERIAL, // ASN1_INTEGER
bear SHASH,// unsigned char[] (assuming SHA1 from Gutman paper)
bear IHASH,// unsigned char[]
bear IANDSHASH,// unsigned char[]
bear CERTHASH, // unsigned char[]
bear B64SHASH, // char *
bear B64IHASH, // char *
bear B64IANDSHASH, // char *
bear B64CERTHASH, // char *
bear COMMON_NAME, // char *
bear EMAIL,// char *
bear } type;
bear union {
bear type1 a;
bear type2 b;
bear ...
bear } u;
bear };
Hmm, I have a hard time to see this as working for anything but the
few easy examples it's meant for. I would prefer a much more flexible
interface which would allow me to do searches on more or less any
combinations of attributes, and the attributes available are at the
discretion of the application, not the bottom-level plug-in.
A search pattern could be a vector of tuples OID, value or
something like that, and the application could be given the
possibility to send down a callback to the plug-in, which could help
doing the selection given a certificate and a chunk of database
attributes.
--
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
Dr S N Henson wrote: Bear Giles wrote: 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. The self signed cert was only an example. There are other cases which could apply as well. An example would be explicit trust of an EE certificate. That isn't supported in OpenSSL yet but it will be at some point. It would however have a similar criteria: only an exact match would be acceptable. I believe this is supported (by writing appropriate callbacks) - I'm sure I remember doing it at some point. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Another proposed DB API
Richard Levitte - VMS Whacker wrote:
From: Bear Giles [EMAIL PROTECTED]
bear The primary key is an opaque string henceforce known as the alias.
bear The plugin may treat this as a primary key, but must not attempt to
bear interpret it as a hash, email address, keyid, serial number, etc.
I think I like the idea. Let's see what Dr Genson has to say.
Dr Genson, who he?
Well let me mention a variation on the API of the partial work I'd done
which avoids some of the problems I'd noticed with it. I'll stick to the
search details for now.
The stuff was called an object database OBJDB. An object would be a
certificate, CRL, private key or perhaps opaque data objects too.
Each object is a set of attributes. For certificates this would include
an alias (a human readable version of the object: e.g. Steve's
Certificate) key id (opaque binary data intended to allow the private
key to be looked up) subject name, issuer name, serial number, subject
key ID, email address and several others... Private keys would typically
have less info such as just an alias and key id.
In PKCS#11 the object type is also an attribute. Not sure whether we
need to do that or not. This would allow us for example to do a single
lookup by key id and get back a mixture of types (certificates and keys)
matching this.
Now a few structures. If we allow object types to be included then we
could use the existing X509_OBJECT to represent the matching structures,
it currently looks like this:
typedef struct x509_object_st
{
/* one of the above types */
int type;
union {
char *ptr;
X509 *x509;
X509_CRL *crl;
EVP_PKEY *pkey;
/* others */
} data;
} X509_OBJECT;
We could also have the attribute use a similar structure:
typedef struct objdb_attr_st
{
/* one of the above types */
int type;
union {
unsigned char *hash;
ASN1_INTEGER *serialNumber;
X509_NAME *subjectName;
X509_NAME *issuerName;
/* Lots more in here */
} data;
} OBJDB_ATTR;
[note: we could alternatively have a single attribute for issuer and
serial number PKCS7_ISSUER_AND_SERIAL_NUMBER]
Now the lookup mechanism. This is done by exact matches of attribute.
Whether we need to handle matches of multiple attributes is debatable.
PKCS#11 can do that though and it isn't too hard to handle. I'll stick
with the more complex multiple attribute stuff and multiple object types
for now...
Each object database would support a triple of lookup functions which
look like this:
int search_init(OBJDB_SEARCH *ctx, STACK_OF(OBJDB_ATTR) *search_attr);
int search_next(OBJDB_SEARCH *ctx, STACK_OF(X509_OBJECT)
**matching_objects, int *count);
int search_final(OBJDB_SEARCH *ctx);
This is effectively an OpenSSL friendly variant of the PKCS#11 API. In
outline this is how a search looks at the object database level (the
application would use a friendly API on top of this)...
search_init() is called to intialize a search context.
search_next() is called repeatedly to retrieve succesive matching
objects. count is an input/output parameter. The application will set
it to the maximum number of objects to retrieve and the object database
sets it to the number actually retrieved. The object database can return
less matching objects that requested (for example some database specific
imposed limit to avoid having to return a huge number of matching
objects). When count is zero the search is complete.
search_final() is called to terminate the search. This can be done at
any point and need not necessarily be done after retrieving all matching
objects.
This API makes not mention of how the objects are stored, how they are
retrieved and how the search mechanism works. The database can do this
in whatever way it finds convenient whether an in looking in an in
memory database, Berkeley db lookup or hand transribed by Tibetan monks.
Now *internally* the database could do lots of different things. The
OBJDB_SEARCH parameter will have (among other things) database specific
data stored in it.
An in memory database might store all the matching STACK_OF(X509_OBJECT)
structures directly in here and just pop them in search_next() until the
stack is empty.
A different database (to use the earlier API example) could store a
stack of matching keys in here and perform a pop+lookup when search_next
is called.
A huge database might store some kind of upto context to avoid having
to satisfy a huge request in one go.
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.
Re: SQL DB instead of index.txt
Bear Giles wrote: But a plug-in that transparently updated a smart card would be extremely handy. :-) That's what makes the design so hard - it needs to be able to handle everything from 8k smart cards holding a single veiled key and cert to RDBMS databases with 50,000+ entries. I think the design would be made needlessly complex by mandating this scalability. The use cases needed for your smart card API would be, say: encrypt this, decrypt this, sign this, verify this. This is what Cryptoki (PKCS#11) does, and does quite well, in my experience. The use cases for a full-blown PKI repository, which I honestly thought was what we were discussing, should probably include: find me the issuer of this, give me the status of this, enumerate all my revoked certificates. None of these would make much sense to the humble 8k card. Best regards, //oscar __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
It's easy for me to say, since I'm not doing the work, but I think Oscar's correct. /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SQL DB instead of index.txt
Oscar Jacobsson wrote: Bear Giles wrote: But a plug-in that transparently updated a smart card would be extremely handy. :-) That's what makes the design so hard - it needs to be able to handle everything from 8k smart cards holding a single veiled key and cert to RDBMS databases with 50,000+ entries. I think the design would be made needlessly complex by mandating this scalability. I'd be reluctant to have multiple APIs handling each case. What we could have is flags or profiles saying what a certain kind of database should support. The use cases needed for your smart card API would be, say: encrypt this, decrypt this, sign this, verify this. This is what Cryptoki (PKCS#11) does, and does quite well, in my experience. There are unfortunately some problems with PKCS#11. Its tantalisingly close to whats needed but falls down in some areas. The use cases for a full-blown PKI repository, which I honestly thought was what we were discussing, should probably include: find me the issuer of this, give me the status of this, enumerate all my revoked certificates. None of these would make much sense to the humble 8k card. Indeed it wouldn't, but full lookup need not be a complex task. The way I'm considering this would be a layered structure which could allow some things like smart cards to have a KISS approach. A standard database type would be an in memory database with full lookup. A smartcard could build on this by just stuffing all the card certificates in memory when its inserted and updating those on card as needed. That would remove most of the lookup burden. 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: Another proposed DB API
From: Dr S N Henson [EMAIL PROTECTED] stephen.henson Dr Genson, who he? Nothing more than a confused left finger for a split second, and my lack of attentione, apparently. :-9 -- 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
From: Oscar Jacobsson [EMAIL PROTECTED] oscar I think the design would be made needlessly complex by mandating this oscar scalability. oscar oscar The use cases needed for your smart card API would be, say: encrypt oscar this, decrypt this, sign this, verify this. This is what Cryptoki oscar (PKCS#11) does, and does quite well, in my experience. oscar oscar The use cases for a full-blown PKI repository, which I honestly thought oscar was what we were discussing, should probably include: find me the issuer oscar of this, give me the status of this, enumerate all my revoked oscar certificates. None of these would make much sense to the humble 8k card. Actually, wouldn't the availability of functionality be somewhat up to the plug-in as well? In the full-blown PKI, you will also have things like fetch me the cert corresponding to this name and fetch me the key (or a handle to the key) with this fingerprint. From a storage point of view, a smart card (or an nCipher box!) can very well be viewed as a limited database. That it also has functionality like symmetric ciphers, digests and pkc is beside the point and outside this discussion. The above means that in some cases, there may very well be a very close connection between our current hardware engines and whatever database plug-in framework we'll come up with, perhaps even to the point of having the latter simply be an extension of the current engine framework (I dunno if that's what everyone else has been thinking of, but I certainly have from the start). This may be confusing unless you keep your head straight and avoid mixing apples and pears. -- 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: Another proposed DB API
From: Bear Giles [EMAIL PROTECTED] bear I read the description as pointing out, with some validity, that a bear private key implies there's also a public key, and public keys are bear published in certs. So if you have a cert, you can use the key as a bear private key. bear bear But without a cert, you can't use the key as a private key. But it's bear still usable - it can even be used similiarly to any symmetric cipher bear key - so they just came up with a name for it. It might be your wording, but I honestly don't get it. If you have a private key, it's at least (I'll explain in a moment) usable as a private key. And also, if you look around a bit, what's often called a private key out there is most often the complete key pair. The PEM files call private keys in OpenSSL really holds all necessary parameters. The same applies to the hardware stuff I've played with (most notably, keys protected by an nCipher box). This is why I said at least. The public key from a pair is, as you say, stored in a certificate (as long as we stay in the X.509 world and don't venture into PGP land :-)), and are useful in themselves for encryption and signature verification. -- 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]
[STATUS] OpenSSL (Sun 3-Feb-2002)
OpenSSL STATUS Last modified at __ $Date: 2001/12/21 03:23:15 $ DEVELOPMENT STATE o OpenSSL 0.9.7: Under development... o OpenSSL 0.9.6c: Released on December 21st, 2001 o OpenSSL 0.9.6b: Released on July 9th, 2001 o OpenSSL 0.9.6a: Released on April 5th, 2001 o OpenSSL 0.9.6: Released on September 24th, 2000 o OpenSSL 0.9.5a: Released on April 1st, 2000 o OpenSSL 0.9.5: Released on February 28th, 2000 o OpenSSL 0.9.4: Released on August09th, 1999 o OpenSSL 0.9.3a: Released on May 29th, 1999 o OpenSSL 0.9.3: Released on May 25th, 1999 o OpenSSL 0.9.2b: Released on March 22th, 1999 o OpenSSL 0.9.1c: Released on December 23th, 1998 RELEASE SHOWSTOPPERS o BIGNUM library failures on 64-bit platforms (0.9.7-dev): - BN_mod_mul verificiation (bc) fails for solaris64-sparcv9-cc AVAILABLE PATCHES o IN PROGRESS o Steve is currently working on (in no particular order): ASN1 code redesign, butchery, replacement. OCSP EVP cipher enhancement. Enhanced certificate chain verification. Private key, certificate and CRL API and implementation. Developing and bugfixing PKCS#7 (S/MIME code). Various X509 issues: character sets, certificate request extensions. o Geoff and Richard are currently working on: ENGINE (the new code that gives hardware support among others). o Richard is currently working on: UI (User Interface) UTIL (a new set of library functions to support some higher level functionality that is currently missing). Shared library support for VMS. Kerberos 5 authentication Constification OCSP NEEDS PATCH o All 'openssl' subprograms taking '-des' and '-des3' options should include AES support (0.9.7-dev) o 'openssl speed' should include AES support (0.9.7-dev) o apps/ca.c: Sign the certificate? - n creates empty certificate file o OpenSSL_0_9_6-stable: #include openssl/e_os.h in exported header files is illegal since e_os.h is suitable only for library-internal use. o Whenever strncpy is used, make sure the resulting string is NULL-terminated or an error is reported o OpenSSL STATUS is never up-to-date. OPEN ISSUES o The Makefile hierarchy and build mechanism is still not a round thing: 1. The config vs. Configure scripts It's the same nasty situation as for Apache with APACI vs. src/Configure. It confuses. Suggestion: Merge Configure and config into a single configure script with a Autoconf style interface ;-) and remove Configure and config. Or even let us use GNU Autoconf itself. Then we can avoid a lot of those platform checks which are currently in Configure. o Support for Shared Libraries has to be added at least for the major Unix platforms. The details we can rip from the stuff Ralf has done for the Apache src/Configure script. Ben wants the solution to be really simple. Status: Ralf will look how we can easily incorporate the compiler PIC and linker DSO flags from Apache into the OpenSSL Configure script. Ulf: +1 for using GNU autoconf and libtool (but not automake, which apparently is not flexible enough to generate libcrypto) o The perl/ stuff needs a major overhaul. Currently it's totally obsolete. Either we clean it up and enhance it to be up-to-date with the C code or we also could replace it with the really nice Net::SSLeay package we can find under http://www.neuronio.pt/SSLeay.pm.html. Ralf uses this package for a longer time and it works fine and is a nice Perl module. Best would be to convince the author to work for the OpenSSL project and create a Net::OpenSSL or Crypt::OpenSSL package out of it and maintains it for us. Status: Ralf thinks we should both contact the author of Net::SSLeay and look how much effort it is to bring Eric's perl/ stuff up to date. Paul +1 WISHES o SRP in TLS. [wished by: Dj [EMAIL PROTECTED], Tom Wu [EMAIL PROTECTED], Tom Holroyd [EMAIL PROTECTED]] See http://search.ietf.org/internet-drafts/draft-ietf-tls-srp-00.txt as well as http://www-cs-students.stanford.edu/~tjw/srp/. Tom Holroyd tells us there is a SRP patch for OpenSSH at http://members.tripod.com/professor_tom/archives/, that could be useful. __ OpenSSL Project
[PATCH] Bug in ASN1_BIT_STRING_set_bit
I've found a bug in ASN1_BIT_STRING_set_bit. The problem is that when
the byte in which the bit is to be set is already allocated and the
value is 0, the bit will still be set to 1. This bug report refers to
the code in the 0.9.6c release. Attached example program and patch.
/Sam
--- openssl-0.9.6c/crypto/asn1/a_bitstr.c Sat Aug 5 20:35:03 2000
+++ openssl-0.9.6c-patched/crypto/asn1/a_bitstr.c Sun Feb 3 14:10:15 2002
@@ -228,9 +228,9 @@
a-flags= ~(ASN1_STRING_FLAG_BITS_LEFT|0x07); /* clear, set on write */
if (a == NULL) return(0);
+if (!value) return(1); /* Don't need to set */
if ((a-length (w+1)) || (a-data == NULL))
{
- if (!value) return(1); /* Don't need to set */
if (a-data == NULL)
c=(unsigned char *)OPENSSL_malloc(w+1);
else
/*
gcc -g -I$GLOBUS_LOCATION/include -I$GLOBUS_LOCATION/include/gcc32dbg
-L$GLOBUS_LOCATION/lib bit_string.c -lcrypto_gcc32dbg
*/
#include openssl/crypto.h
#include openssl/ssl.h
int main()
{
ASN1_BIT_STRING * bit_string = NULL;
bit_string = ASN1_BIT_STRING_new();
ASN1_BIT_STRING_set_bit(bit_string,1,1);
ASN1_BIT_STRING_set_bit(bit_string,2,0);
printf(Bit 7 has value %d\n,ASN1_BIT_STRING_get_bit(bit_string,2));
}
Re: [PATCH] Bug in ASN1_BIT_STRING_set_bit
From: Samuel Meder [EMAIL PROTECTED] meder I've found a bug in ASN1_BIT_STRING_set_bit. The problem is that when meder the byte in which the bit is to be set is already allocated and the meder value is 0, the bit will still be set to 1. This bug report refers to meder the code in the 0.9.6c release. Attached example program and patch. Well found bug, but incorrect correction, because your patch will still not clear a set bit (as one would expect if you gave the value 0 for a bit number that was early given the value 1). Thanks for noting this, I'll make the appropriate change. Also, since you send from an american government address, you have to cc: your patches to [EMAIL PROTECTED] for them to be included in the OpenSSL source. -- 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: [PATCH] Bug in ASN1_BIT_STRING_set_bit
From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] levitte Well found bug, but incorrect correction, because your patch will levitte still not clear a set bit (as one would expect if you gave the value 0 levitte for a bit number that was early given the value 1). While I looked at this, I noticed this function is quite inefficient when trying to figure out if more memory is needed. Not the allocation bit itself, but rather that it will count down length when the last bytes are 0, and thereby lose all info on how much memory it has really allocated, which means that there's a potential unneeded OPENSSL_realloc() happening in the next few calls if the next n is larger than the current length*8. -- 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: [PATCH] Bug in ASN1_BIT_STRING_set_bit
On Sun, 03 Feb 2002, Richard Levitte - VMS Whacker wrote: From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] levitte Well found bug, but incorrect correction, because your patch will levitte still not clear a set bit (as one would expect if you gave the value 0 levitte for a bit number that was early given the value 1). While I looked at this, I noticed this function is quite inefficient when trying to figure out if more memory is needed. Not the allocation bit itself, but rather that it will count down length when the last bytes are 0, and thereby lose all info on how much memory it has really allocated, which means that there's a potential unneeded OPENSSL_realloc() happening in the next few calls if the next n is larger than the current length*8. Saw that too. I realized my mistake btw and here is a updated patch. Is there any reason for doing a-data[w]=((a-data[w])iv)|v instead of a-data[w]=(a-data[w])|v /Sam --- openssl-0.9.6c/crypto/asn1/a_bitstr.c Sat Aug 5 20:35:03 2000 +++ openssl-0.9.6c-patched/crypto/asn1/a_bitstr.c Sun Feb 3 15:05:34 2002 @@ -240,7 +240,12 @@ a-data=c; a-length=w+1; } - a-data[w]=((a-data[w])iv)|v; + +if(value) +a-data[w]=((a-data[w])iv)|v; +else +a-data[w]=(a-data[w])iv; + while ((a-length 0) (a-data[a-length-1] == 0)) a-length--; return(1);
Re: [PATCH] Bug in ASN1_BIT_STRING_set_bit
From: Samuel Meder [EMAIL PROTECTED] meder Saw that too. I realized my mistake btw and here is a updated meder patch. Is there any reason for doing meder meder a-data[w]=((a-data[w])iv)|v meder meder instead of meder meder a-data[w]=(a-data[w])|v Sure there is. Consider the following and you'll understand: ASN1_BIT_STRING_set_bit(bstr, 1, 1); ASN1_BIT_STRING_set_bit(bstr, 1, 0); If the `iv' part was removed, do you think the bit in question will really be cleared? In any case, the proper patch was to insert the following line right after the assignment of iv: if (!value) v=0; I've commit that change. It should be visible in the snapshot and the next release. -- 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]
