Patrick Thanks for your comments. They were exactly as I expected them and I consider them as mostly right (yep ... I do not agree with you everywhere ... though world) and all togetehr as very valuable.
You might have seen that I raised quite a lot of your concerns (SPOF, dependency on other services such as network [if not a named socket], questionable gain of security in terms of "transportability") myself so I think we both agree on these topics. May I chalenge some of your comments? (I try to anyway ;-) ) > Not sure where you are going it - even on Windows "CSP", if you know where > to > look, the keys are always "transportable" - even if you set the private > key to > non-exportable, just backup the system, and restore it somewhere else ... > not > to mention the fact that there are several APIs that you can use to expose > the > private key. I think ANY software based key system that claims to make > claim > that it prevents private key transport is rather in the "snake oil" > category. > I think we both agree that the gain is weak. As soon as you have root rights no kind of local store (software supported) - no matter how sophisticated - is safe. So I agree that it is not even close to a good security but it is as close as someone could get with software. >> OpenSSL would have to be modified as follows: >> >> - Implement a "dual use" for certificates which allows to >> - Either use an "ordinary" certificate (to be used as of now) >> - or a CSP configuration which contains the configuration where and >> how to get the certificate services >> - Implement a certificate service provider daemon in OpenSSL which >> offers >> access thru named sockets or network sockets >> - Implement a CSP configuration generator in OpenSSL which creates CSP >> configuration files which can be distinguished from a certificate at any >> time. >> > OpenSSL is a toolkit... and quite a good one for doing the crypto bits... > a > fully featured "Crypto Service Provider" has two functions - storing keys, > and > validating other peoples keys. Now there we go - I would say you are right but there is an importannt part missing in your definition: A CSP able to hide a private key has (additionally) to offer all the signing/encryption/... functions which are only feasible by using the private key part. >Ideally, there is some key management > functions > in there as well, to handle rekey/revocation/renewal/what-have-you. That would be nice but I have not covered it as it would be two (big) notches more to implement and I have no use for it now (It definitely would make sense - but I fear endless discussions [with you?]). Furthermore the mail would have become absolutely unreadable and far too big (Is that a good excuse?). > > A couple of notes: > > 1: Hooking things like CRL retrieval, AIA chasing, OCSP checking, > CMS/XKMS/TAMP communication with the CA, etc., into OpenSSL, and having it > do > all of the network communications would mean that you'd have to have some > way > of hooking the applications main loop (if you blocked on a network access, > someone is liable to get VERY angry with you :). Even if you were to > implement > a client/server type scenario, you'd still have to be quite smart about > it, > and modify the application accordingly. > OK - The basic idea was that the app is "not knowing" that it is not dealing with OpenSSL directly. The API remains the same. However some calls *might* end up in subsequent communication with a daemon which might be either local (thru a named socket) or remote (thru network). Some calls might be handled locally (eg. signature/key verification) depending on what type of key is needed. Even a (to the app) transparent cache might improve speed and availability partially (of course you would be unable to get certificates into the client which are "private key protected" for obvious reasons). Some datastructures would get slight changes and exactly these changes will result in incompatibilities. As an example: Apps accessing private keys and doing their "own stuff" (eg. own cryptographic algorithm) will naturally fail. A network or daemon failure would most likely end up in angry users -- agreed -- just exactly as if a router would fail. It is up to the sysadmin to decide wether he wants to use the CSP feature or wants to work the "traditional way". > 2: You could do SOME of what you are thinking of using the engine > interface - > issue 1 still holds, but you could implement some of the functionality in > the > engine to handle access to the keystore, and validation. > Can you specify what in your opinion the "not SOME" part is? I would be intrested. > 3: Part of what you are thinking of, I think, is already done by > applications > such as Pathfinder (http://www.carillon.ca/tools/pathfinder.php). It does > full > RFC5280 PDVal, and can act as a central trust store and settings manager. > I did not know pathfinder so please correct me if I am writing anything wrong here: 1. Pathfinder does not offer a full CSP. It offers the certificate handling in terms of issuing/revocation/removal/distribution and so on. 2. Pathfinder requires that the app in question supports it. My attempt was/is to make a bottom up approach by making all apps using OpenSSL capable of dealing with a CSP (attempt to define it see above :-) ). Others *might* follow if it turns out to be a success. > 4: OpenSSL is used in many server side applications, but very few client > apps. > Servers tend to be protected physically (in data centers with restrictive > access), and logically (login capability is generally restricted to a > select > few people, and MOSTLY done right..). hopefully :-P > Linux Client side certificate > management, on the other hand, is a mess. KDE/Kontact/Konqueror uses > KSSL/Kleopatra, Firefox/Thunderbird/Evolution/OpenOfficeOrg use libnss, > and > each have their own keystores (or at least, most of the time, they don't > share > them). I know that the attempt would not cure the world in one shot but - hey - some parts are better than nothing -- no? Servers are the most important bits. If done carefully other libraries (eg. libnss) could maybe (partially) share the protocol thus unifying the world (The last sentence is said without doing any research -- so it might be foolish/rubish). > Adobe uses goodness knows what. Java uses it's own keystore unless > you > tell it not to, etc. Most of the applications that actual users will > touch on > a daily basis use something other than OpenSSL. And even of those that do > use > OpenSSL, most don't do it right (very few obey settings such as Engine > configs > for keys out of the central "main" openssl.cnf, and few still allow you to > specify a different openssl.cnf.) What I can see is needed is for these > projects to come together and make a few decisions regarding a common user > key > store, a common machine key store, and a central trust anchor store. That > would be a HUGE start in usability. ... and this CSP feature *could* be a big leap forward in exactly offering that (depending how it is working). But this is only a side effect. > >> This modification of the OpenSSL library would allow to make the >> certificates more secure and allow applications without (!) any code >> modification (just by linking against the CSP capable OpenSSL library) >> to >> support the CSP. >> > Again - just wrapping something in a box doesn't make it any more secure - > security comes from many more methods than that. > agreed - see notes above. Security is never absolute and only good if handled with care. Each and every feature in a product which has been written to add security might turn against it depeding on the case. There is one thing missing in your statements which I would have been very keen to hear. I explicitely asked for challenging the design and this is what you did but how would you react if someone would start implementing this into OpenSSL. Would you consider it as: a. useful with flaws b. partially useful c. not useful to you -- but you do not mind d. total rubish as it would make OpenSSL broken/unsecure Regards Martin ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
