> 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.
I tend to agree, but wanted to start close to any model API first. Makes it easier to explain why we diverged later. Consider the cert chain gone. > bear> A "KEY ENTRY" may contain a key alone (secret key), or a key and > bear> certificate (private key). > > 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...). (Remember, a lot of those descriptions were from the javadoc, not my own words.) I read the description as pointing out, with some validity, that a "private" key implies there's also a public key, and public keys are published in certs. So if you have a cert, you can use the key as a private key. But without a cert, you can't use the key as a private key. But it's still usable - it can even be used similiarly to any symmetric cipher key - so they just came up with a name for it. > 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. Okay, that makes sense. Spend too much time deep in SQL and Berkeley databases and you tend forget about things like callbacks. :-) ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
