Re: [opensc-devel] OpenSC with or without OpenSSL - What is the direction?
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
Note that verify is not listed without OpenSSL, as the
pkcs11/openssl.c adds the OpenSSL hash and verify functions.
Interesting. RSA-PKCS-KEY-PAIR-GEN should have nothing to do with
OpenSSL. Also, OpenSC (and most smart cards) currently only do
properly keys up to 2048 bits.
opensc.h has #define SC_CARD_CAP_RSA_2048, JavaCard 2.2.2 has only
KeyBuilder.LENGTH_RSA_2048
The suggested key sizes apparently only double over years, so 4096
seems more popular than 3072 for some reason :)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [RFC] Proposal For Restructuring 'struct sc_pkcs15_card'
Hello, On Tue, Sep 28, 2010 at 23:08, Andre Zepezauer andre.zepeza...@student.uni-halle.de wrote: Attached is the final patch. Naming of flags as mentioned above. All changes were trivial with the exception of pkcs15init/pkcs15-oberthur.c Thanks! Commited in r4788 [1] [1] http://www.opensc-project.org/opensc/changeset/4788 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC with or without OpenSSL - What is the direction?
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
RSA-PKCS, keySize={1024,3072}, sign, unwrap, decrypt
Note that verify is not listed without OpenSSL, as the
pkcs11/openssl.c adds the OpenSSL hash and verify functions.
Interesting. RSA-PKCS-KEY-PAIR-GEN should have nothing to do with
OpenSSL.
Looks like pkcs11/framework-pkcs15.c line 1348 has #ifdef ENABLE_OPENSSL
that will add this mech.
Also, OpenSC (and most smart cards) currently only do
properly keys up to 2048 bits.
The NIST 800-73-1 (March 2006) specs called for the PIV applet to
optionally support 3072 bit keys. So that is what the driver says
is available. Since the ordinary user can not generate a key on the
card, and the only keys that can be used are tied to certificates,
the actual size of the key is determined from the certificate.
opensc.h has #define SC_CARD_CAP_RSA_2048, JavaCard 2.2.2 has only
KeyBuilder.LENGTH_RSA_2048
The suggested key sizes apparently only double over years, so 4096
seems more popular than 3072 for some reason :)
NIST 800-78-2 February 2010, has a nice chart of required key sizes
and 1024 bit keys are to be gone by 12/31/2013, in all cases. There
is no mention of 3072 bit keys, and I don't think there are any
PIV cards that support them today, but i don't think it hurt to say
the card supports 3072.
But 800-78-2 is also pushing for ECDSA p-256 and p-384 for certificates,
and ECDH for Key Management. So the trend appears to be to use EC keys
rather then larger and larger RSA keys.
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4768] ias/ecc: simultaneous run of opensc tool that address different readers
Hello, On Sun, Sep 26, 2010 at 09:54, Viktor TARASOV viktor.tara...@opentrust.com wrote: Actually in 'reader-pcsc', when getting the reader's list, the SCardConnect(SCARD_SHARE_DIRECT) is called for every reader. So, when one process holds the first reader, the second process cannot access the second reader -- it stopped on the first reader's mutex. This should not be necessary with r4783 [1] [1] http://www.opensc-project.org/opensc/changeset/4783 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC with or without OpenSSL -???What???is?the?direction?
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. 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 implements bitpadding. In my implementation I am trying to separate encoding of a SM message (which is for the nPA defined by ISO 7816-4 section 6) and the actual cryptography. I described the process here for my SM wrapper, sm_transmit_apdu, https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace/sm.h Adopting my aproach on the other hand would mean a rewrite of all other card drivers with SM. 2. I suggested a change for handling SCardControl (ticket 235), because there are readers with special capabilities for the nPA. But even this simple suggestion (and simple patch) was not accepted. Currently the discussion is stuck at the argument that OpenSC is for PKCS#15, which the nPA doesn't support. So I suppose two things. First big patches are not welcome, or at least they are unlikely to be accepted. Second, support for the nPA is not very important since it lacks PKCS#15. Greets, Frank. pgpxo5JOmzQdD.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
Martin, Waiting for your decision. On Mon, Sep 27, 2010 at 1:34 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: On Mon, Sep 27, 2010 at 1:07 PM, Martin Paljak mar...@paljak.pri.ee wrote: But... the only dependency we require is xsltproc, so maybe we can rethink this... Provided you agree that building the package with --enable-doc or --enable-man requires xsltproc available on build machine, we can remove all this useless generation and hacks. I think it is not a huge problem to require xsltproc, it is quite common and small. What bothers me more is docbook-xsl. But the target audience of people who run make dist and who run make install is different. But maybe there's more in the autotools philosophy that I don't fully get. OK I will modify the build so that the file will be generated on builder. Much simpler! Will this get rid of the symlink magic, and allow: make dist: require xsltproc, docbook-xsl, don't require playing with symlinks (assumes/requires running from version control checkout) make dist *WILL NOT* require xsltproc, docbook-xsl. It will actually only distribute the sources, no generation of files. make, make install: don't require xsltproc and docbook-xsl, use the pre-generated man files. make *WILL* require xsltproc and docbook-xsl if and only if --enable-man and/or --enable-doc is specified at configure. If you want to avoid xsltproc dependency from make install, we back to square one (current trunk). As the only documentation other than man pages is tools.html (should that be placed on the website somewhere?) one of --enable-doc or --enable-man is redundant. I do not follow... Do you want to remove the tools.html from build? Or install both man and htmls using one option? I don't think that installing to mandir and htmldir should be enforced as single option. I did not notice that the tools.html is distributed (dist_html_DATA). But does it make sense to install two competing copies of tool usage options? If you use the tools, you use the command line, thus using man should be a known activity. If using a web browser, wiki has much more detailed information than in the htmlified man pages copy. Your call... :) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC with or without OpenSSL - What is the direction?
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, keySize={1024,3072}, keypairgen
Without OPenSSL, pkc11-tool -M
RSA-PKCS, keySize={1024,3072}, sign, unwrap, decrypt
Note that verify is not listed without OpenSSL, as the
pkcs11/openssl.c adds the OpenSSL hash and verify functions.
Interesting. RSA-PKCS-KEY-PAIR-GEN should have nothing to do with
OpenSSL.
Looks like pkcs11/framework-pkcs15.c line 1348 has #ifdef ENABLE_OPENSSL
that will add this mech.
That's something that needs to be looked into at some stage.
Also, OpenSC (and most smart cards) currently only do
properly keys up to 2048 bits.
The NIST 800-73-1 (March 2006) specs called for the PIV applet to
optionally support 3072 bit keys. So that is what the driver says
is available. Since the ordinary user can not generate a key on the
card, and the only keys that can be used are tied to certificates,
the actual size of the key is determined from the certificate.
It would be nice to support 3072b keys. I have a CryptoStick (OpenPGP)
that support such keys but I've not yet got around to trying to use it
with OpenSC.
NIST 800-78-2 February 2010, has a nice chart of required key sizes
and 1024 bit keys are to be gone by 12/31/2013, in all cases. There
is no mention of 3072 bit keys, and I don't think there are any
PIV cards that support them today, but i don't think it hurt to say
the card supports 3072.
But 800-78-2 is also pushing for ECDSA p-256 and p-384 for certificates,
and ECDH for Key Management. So the trend appears to be to use EC keys
rather then larger and larger RSA keys.
Correct. But I think it will take a few years before EC is as
widespread and available as RSA is today.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC with or without OpenSSL -???What???is?the?direction?
(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 subscribe.) Sorry for being slow on this, I was sick at home and mostly offline last week. On Oct 1, 2010, at 8:36 AM, Frank Morgner wrote: 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. 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 implements bitpadding. In my implementation I am trying to separate encoding of a SM message (which is for the nPA defined by ISO 7816-4 section 6) and the actual cryptography. I described the process here for my SM wrapper, sm_transmit_apdu, https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace/sm.h Adopting my aproach on the other hand would mean a rewrite of all other card drivers with SM. There are not many card drivers with SM support (yet) and generally SM support is a somewhat moving target. Do you have practical suggestions for improvement? 2. I suggested a change for handling SCardControl (ticket 235), because there are readers with special capabilities for the nPA. But even this simple suggestion (and simple patch) was not accepted. IMHO #236 does not make much sense, whereas #237 does. The patch in #237 makes perfect sense and will be included soon as it gets used by some piece of code in OpenSC, like one of the three tools. Until somebody finds the time to re-write those places to make use of it, it is not good to add a feature and then forget it and end up having dead code around. There's plenty of that already. Feel free to change some of those tools to make use of the new function to speed up the inclusion of your patch. Currently the discussion is stuck at the argument that OpenSC is for PKCS#15, which the nPA doesn't support. The thing with standards is that you can call anything a standard, but nobody cares unless it is actually used by more than a few vendors (remember the XML thing by Microsoft?). PKCS#15 has been the best option this far (and has been around for quite some time), but nevertheless, it is not perfect and certainly not the only one. But it helps to try to think like PKCS#15 when working with OpenSC. OpenSC aims for two targets: to provide tools for personalizing smart cards, and to provide tools and interfaces to use either those cards personalized by OpenSC or cards that get emulated to a PKCS#15-ish structure. OpenSC has settled on PKCS#15 for cards that it writes (but there's some code by Viktor that allows PKCS#15 initialization emulation-virtualization as well, don't know that so well yet), but it is not and should not be too hard to emulate a PKCS#15-like structure for read-only crypto cards on top of almost anything. If the internal PKCS#15 layer is not sufficient to represent the (crypto) objects on your card, please point out the deficiencies so that it could be improved. So I suppose two things. First big patches are not welcome, or at least they are unlikely to be accepted. I'm very sorry if you feel like this. I did not find the time to reply any sooner, nor could anyone else reply to your e-mail as it was in the moderation queue. If you are in doubt, I'd like to assure you that there is no discrimination nor acceptance barriers except for common sense and best practices in OpenSC. This has also been described in the OpenSC development policy [1], to keep it very transparent to anyone who wishes to improve and work with OpenSC. Second, support for the nPA is not very important since it lacks PKCS#15. If it has crypto capabilities, it is useful. It is hard if not impossible to objectively measure the importance of a card against others. As long as there's a developer and a maintainer and/or users for a card, the card becomes relevant. I think the best measure is the activity of users and developers for a given card. If you want to use nPA cards with/via OpenSC just let us know what needs to be improved or changed in OpenSC to make it happen. [1] http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Sourcecodeversioning Cheers, -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
Hello, On Oct 5, 2010, at 7:34 PM, Alon Bar-Lev wrote: Martin, Waiting for your decision. On Mon, Sep 27, 2010 at 1:34 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: make dist: require xsltproc, docbook-xsl, don't require playing with symlinks (assumes/requires running from version control checkout) make dist *WILL NOT* require xsltproc, docbook-xsl. It will actually only distribute the sources, no generation of files. make, make install: don't require xsltproc and docbook-xsl, use the pre-generated man files. make *WILL* require xsltproc and docbook-xsl if and only if --enable-man and/or --enable-doc is specified at configure. If you want to avoid xsltproc dependency from make install, we back to square one (current trunk). Current build files are OK as long as they work. I can't copy the relevant lines but I've seen some missing html.out required for XXX kind messages from make, but they usually magically disappear with make clean/make -j 8 (could it be some race condition?) Personally I don't mind simplicity in build files. 99% of people run binaries or packages, 99% of people who don't run binary packages on Linux know what they are doing. Or won't mind downloading an extra few packages or not having the man pages. Don't really have a preference. It's your call :) -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Tue, Oct 5, 2010 at 7:12 PM, Martin Paljak mar...@paljak.pri.ee wrote: Personally I don't mind simplicity in build files. 99% of people run binaries or packages, 99% of people who don't run binary packages on Linux know what they are doing. Or won't mind downloading an extra few packages or not having the man pages. Don't really have a preference. It's your call :) OK... So I prefer to remove all the hacks. Doing this now. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
