Richard Levitte - VMS Whacker wrote: > 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.
Good. We seem to be in complete agreement here. The fact that some thing might be a Repository (that is, it implements getCert() and publishCert() etc.) as well as optionally being a KeyStore (that is, it implements generate(), encrypt(), decrypt() etc.) is completely independent of whether it also is a Database (that is, it implements store() and retreive() etc.). > 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. I think the easiest way of making sure apples and pears aren't mixed is to keep, and treat them separately. The Repository IS-NOT-A (to paraphrase Liskov) KeyStore, which in turn IS-NOT-A Database. A smart card or a piece of cryptographic hardware might implement all three of the above, but a directory server or RDBMS would most probably not. Best regards, //oscar ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
