H Jaroslav
Thanks for your comments. I was very eager to read your comments and had
my own thoughts about it. Please read below.
Am 03.06.2010 15:26, schrieb Jaroslav Imrich:
Hello Martin,
I am not OpenSSL developer so this message will contain only my own opinions.
Security provided by the default CSP in Windows (I think its name is
"Microsoft Enhanced Cryptographic Provider" or something like that) is
same as security provided encrypted PEM file. Default CSP stores your
private keys in your home folder - yes they are "transportable" - and
your password is used to protect them. If you don't believe me try
reseting, not changing, your password then use your key to sign data -
it will not work - then reset your password back to its original value
and sign data - it will work.
Yup - This works as long as you use the standard provider. However there
are more sensible providers professionally offered (eg. by entrust)
which do it better.
I am not sure if I understand you correctly but I think that you are
missing ONE standardized API that could be used by all or most of the
applications available for linux/unix platform.
Basically this is correct. I am not missing the API but the capability
to centralize to a certain extend certificates and I am not liking the
fact that certificates (as an identity) are transportable. In the
company I work certificates are widely used. While transportability on
the windows clients is only a minor issue (Due to entrust and the use of
smartcards) it is a mayor issue on the unix servers. Since smartcards
are not an option there I tried to transfer the CSP approach in such a
way that i would fit UNIX and LINUX.
There have been several attempts to create such API like QCA (Qt
Cryptographic Architecture) from KDE project -
http://api.kde.org/kdesupport-api/kdesupport-apidocs/qca/html/ - that
IMHO tries to achieve similar functionality like MS Crypto API on
Windows platform. There is also multi-platform JCA (Java Cryptography
Architecture) -
http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html -
but that is available only for Java applications. PKCS#11 -
http://www.rsa.com/rsalabs/node.asp?id=2133 - has to be also mentioned
when speaking of cryptographic API. It was designed as API for
accessing cryptographic hardware but there are also implementations
for pure software tokens. PKCS#11 is supported by Mozilla applications
(Firefox, Thunderbird, ...).
True - OpenSSL has one big advantage over those APIs. It is there and
commonly used (yes there are other libraries but you have to start
somewhere. If OpenSSL would be modified in the way I described it the
App is not aware that it deals with a CSP. It still passes a
"certificate" to OpenSSL and trys to get services (eg. encryption) with
the created objects not knowing that its "certificate" was in fact a
"config file for a CSP".
OpenSSL provides ENGINE API that allows developers to extend library
with support for cryptographic hardware and it also allows them to
leverage good things from other software implementations. For example
one can write engine that uses GnuTLS implementation of cryptographic
algorithms through standard OpenSSL calls. When speaking of CSP there
is already CAPI engine available (engines/e_capi.c) that can be used
to access objects in certificate store of MS Windows.
I am aware of that API which (to my knowledge) has been itroduced
recently (I think it was 0.9.8 or so). And it is very likely that some
of the modifications I am proposing are khooked in there. Most likely
this will be a myor part but not all of it.
As you can see there are many "crypto APIs" available and every
developer can choose his own path. So my question is: How would you
convince 3rd party developers to use your implementation with "CSP
server" ?
As said: I don't. I simply make them believe that they are still dealing
with OpenSSL and certificates exactly as they did in the past. All
changes should be transparent (meaning: no obvious change) to the API of
OpenSSL.
Regards
Martin
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
