Hello Martin,
On Tue, 2010-10-05 at 18:04 +0300, Martin Paljak wrote:
Hello
On Thu, Sep 30, 2010 at 18:07, Douglas E. Engert deeng...@anl.gov wrote:
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,3072}, keypairgen
Without
Hello,
Frank Morgner wrote:
What are the limitations in OpenSC?
1. There is no kind of abstraction in the current SM code. At the
moment every card driver implements its own version of secure
messaging.
SM is not implemented by card driver, but the separate SM procedures.
These
Hi!
On Tuesday, October 12 at 10:33AM, Viktor TARASOV wrote:
1. There is no kind of abstraction in the current SM code. At the
moment every card driver implements its own version of secure
messaging.
SM is not implemented by card driver, but the separate SM procedures.
These
Hello,
On Oct 10, 2010, at 10:07 PM, Frank Morgner wrote:
1. There is no kind of abstraction in the current SM code. At the
moment every card driver implements its own version of secure
messaging. This leads to duplicated code. For example, what I saw
at the first glance is that every card
( As Spanish authorities finally said No-no to allow re-licensing GPL'd
DNIe code for inclusion in OpenSC, me an some others have started a
written-from-scratch OpenSC DNIe module. We are next to start writing
sm code... )
At lun, 11-10-2010 a las 09:56 +0300, Martin Paljak wrote:
[]
There
Hi!
What are the limitations in OpenSC?
1. There is no kind of abstraction in the current SM code. At the
moment every card driver implements its own version of secure
messaging. This leads to duplicated code. For example, what I saw
at the first glance is that every card driver
Hello
On Thu, Sep 30, 2010 at 18:07, Douglas E. Engert deeng...@anl.gov wrote:
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,3072}, keypairgen
Without OPenSSL, pkc11-tool -M
RSA-PKCS, keySize={1024,3072}, sign, unwrap, decrypt
On 10/5/2010 10:04 AM, Martin Paljak wrote:
Hello
On Thu, Sep 30, 2010 at 18:07, Douglas E. Engertdeeng...@anl.gov wrote:
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,3072}, keypairgen
Without OPenSSL, pkc11-tool -M
On Thursday, September 30 at 12:02PM, Martin Paljak wrote:
The code (also needs a patched version of OpenSSL) is much more
extensive than other SM cards in opensc-sm.trunk, that's why I doubt
that there is a chance of integrating the nPA into OpenSC.
What are the limitations in OpenSC?
1.
On Tue, Oct 5, 2010 at 18:56, Douglas E. Engert deeng...@anl.gov wrote:
On 10/5/2010 10:04 AM, Martin Paljak wrote:
Hello
On Thu, Sep 30, 2010 at 18:07, Douglas E. Engertdeeng...@anl.gov wrote:
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN,
(Frank, you're not subscribed to opensc-devel mailing list, which is not a good
idea if you want to send mails here. I rescued the e-mail from moderation
because it is probably of interest to others as well (unlike the viagra and
your wife photos attached ones :) but you really should
Hi,
Andre Zepezauer wrote:
in my opinion the usage of OpenSSL in libopensc.so should be removed
altogether. If cryptography is needed by some cards (i.e. for
initialisation/personalisation), then this should be done by dedicated
tools. CardOS is a good example. It requires encrypted APDU:s
Hello,
On Sep 27, 2010, at 11:58 PM, Douglas E. Engert wrote:
There has been a effort to be able to build OpenSC without the use
of OpenSSL. Yet there is newer code that keeps creeping in to the
trunk that requires OpenSSL.
This has been discussed several times during past few years. There was
On 9/30/2010 3:56 AM, Martin Paljak wrote:
Hello,
On Sep 27, 2010, at 11:58 PM, Douglas E. Engert wrote:
There has been a effort to be able to build OpenSC without the use
of OpenSSL. Yet there is newer code that keeps creeping in to the
trunk that requires OpenSSL.
This has been
Douglas E. Engert wrote:
I have noticed that Debian (any maybe others) have started to convert
to using GnuTLS in some packages like OpenLDAP, for licening reasons.
(I spent two much time tracking down bugs and differences in nss and ldap
because of this change.) So I would not suggest it at
Hello Douglas,
in my opinion the usage of OpenSSL in libopensc.so should be removed
altogether. If cryptography is needed by some cards (i.e. for
initialisation/personalisation), then this should be done by dedicated
tools. CardOS is a good example. It requires encrypted APDU:s for the
delete_MF
On 9/29/2010 9:51 AM, Andre Zepezauer wrote:
Hello Douglas,
in my opinion the usage of OpenSSL in libopensc.so should be removed
altogether. If cryptography is needed by some cards (i.e. for
), then this should be done by dedicated
tools. CardOS is a good example. It requires encrypted
On Wed, 2010-09-29 at 13:35 -0500, Douglas E. Engert wrote:
On 9/29/2010 9:51 AM, Andre Zepezauer wrote:
Hello Douglas,
in my opinion the usage of OpenSSL in libopensc.so should be removed
altogether. If cryptography is needed by some cards (i.e. for
), then this should be done by
On 9/29/2010 3:05 PM, Andre Zepezauer wrote:
On Wed, 2010-09-29 at 13:35 -0500, Douglas E. Engert wrote:
On 9/29/2010 9:51 AM, Andre Zepezauer wrote:
Hello Douglas,
in my opinion the usage of OpenSSL in libopensc.so should be removed
altogether. If cryptography is needed by some cards
in my opinion the usage of OpenSSL in libopensc.so should be removed
altogether. If cryptography is needed by some cards (i.e. for
initialisation/personalisation), then this should be done by dedicated
tools. CardOS is a good example. It requires encrypted APDU:s for the
delete_MF and
There has been a effort to be able to build OpenSC without the use
of OpenSSL. Yet there is newer code that keeps creeping in to the
trunk that requires OpenSSL.
The OpenSSL dependent code can be divided into 3 areas:
(1) Code that tries to get some information from a certificate, such
as the
21 matches
Mail list logo
