[opensc-devel] Patch to let carmod working after multiple reader system removal.
De :
Martin Paljak mar...@paljak.pri.ee
A:
francois.lebl...@cev-sa.com
Cc :
opensc-devel@lists.opensc-project.org
Date:
23/09/2010 15:37
Objet :
Re: [opensc-devel] Patch to let carmod working after multiple reader
system removal.
Hello,
On Sep 23, 2010, at 3:37 PM, francois.lebl...@cev-sa.com wrote:
#ifdef ENABLE_PCSC
ctx-reader_driver = sc_get_pcsc_driver();
+#ifdef ENABLE_CARDMOD
+if(strcmp(ctx-app_name, cardmod) == 0) {
+ctx-reader_driver = sc_get_cardmod_driver();
+}
+#endif
#elif ENABLE_CTAPI
ctx-reader_driver = sc_get_ctapi_driver();
#elif ENABLE_OPENCT
it's quite ugly but let us use cardmod driver and continue to improve
it...
Please describe how the driver is used by the minidriver, how it differs
from normal OpenSC use, what are the biggest and most important
differences between the normal pcsc code and the cardmod code.
This has already been discuted summary windows process provide pcsc handle
and context and you need to use them
you can't open context, create handle and access to the card (it's the
goal to use opensc under windows)
When you insert card under windows, windows detect this insertion open
context and create handle with card and give you
this informations to your dll to manage card, so you can see that with
this process you can'ty create handle to your card since
the card is already connected ...
Minidriver code calls sc_create_context like other applications, with the
difference that a card handle is already present in the minidriver code
and does not need to be fetched via libopensc calls and connected to with
a sc_connect
So you decided you pass the handles around to the libopensc instance in
windows registry (not environment variables as was in another incarnation
of OpenSC + BaseCSP).
Could you provide working example of incarnation of OpenSC + BaseCSP ?
This means a single instance of an OpenSC based card and reader by
default. Why not use the context creation parameters to pass in
After start of process an another one with other hanlde can be started...
the necessary handles? There is no IPC present and necessary
modifications to the context creation functionality to accommodate
BaseCSP requirements is perfectly reasonable argument to change those
structures and add code. Especially now, when it is not exposed to
outside world.
I'm ok to pass pcsc handle and context with in the creation context
parameters, but these are needing under pcsc driver, so
I need a link between context creation parameters and reader-pcsc, this
need more modification that using registry, or I miss something...
Having a single reader driver greatly simplifies the architecture of
OpenSC. It also simplifies the proper modifications needed for the
cardmod driver. You are free to patch the libopensc instance at runtime
any way you want to get what you need. This means overloading the not
needed functions from pcsc driver with NULL. And adding necessary logic to
the rest of PC/SC functions to return early as needed.
As is the case with the rest of reader driver, the decision what to build
happens not at runtime, but at compile time. There are several
restrictions to what can be put inside a minidriver, so I would build it
as a single static dll instead.
I don't understand exactly what you mean, but I'm agree with the end
building in one static dll will be better, unfortunatly I don't known how
to process for now.
--
@MartinPaljak.net
+3725156495
François.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Question for the GURUs
Andre Zepezauer wrote: On Thu, 2010-09-23 at 15:50 +0200, Andre Zepezauer wrote: On Thu, 2010-09-23 at 14:19 +0200, Umberto Rustichelli aka Ubi wrote: Dear all, I have been digging a bit into the OpenSC and OpenSSL code because I have a doubt. Using keys on smart cards via the OpenSC engine, I am almost sure that by producing a PKCS7 the signature is of type sha1WithRSAEncryption (at least without any special options), that implies using specific kinds of padding for the digest before the RSA encryption, for instance. The signature in the PKCS7, though, is marked as an object of type rsaEncryption (can tell with the asn1parse command). Is it correct to say that they are are the same, or, better, that 1) rsaEncryption includes the sha1WithRSAEncryption type 2) sha1WithRSAEncryption is what the PKCS7 API does by default? (I know, this is rather an OpenSSL-related question) You can find the corresponding definitions in [1] section 11. My conclusion is, that both algorithms apply a pkcs1 padding before exponentiation. And sha1WithRSAEncryption hashes input data before padding but rsaEncryption doesn't do that. Signature algorithms are always used in conjunction with a one-way hash function. [2] Therefore it is an error when the algorithm identifier carried with a signature is rsaEncryption. Right? Ooops. Excerpt [2] only applies to X509 certificates and crls. What is required for pkcs7 signatures? I am specifically talking of PKCS#7 signedData, not detached, so it is, in brief: ORIGINAL CONTENT + SIGNER'S CERTIFICATE + SIGNER INFO that includes the signature. Signature is the RSA encryption of the hash of the content or, if authenticated attributes are present in signer info, of the hash of authenticated attributes. If they are present, they also contain the hash of the original content, so indirectly you're also signing the hash of the original content. This is the theory and also what OpenSSL does, at least according to my inspection of the code. You can use more than one hash type, so you are free to end with a rsaEncryption object (OpenSSL), but I know that other vendors produce sha1WithRSAEncryption and/or sha256WithRSAEncryption. I hope this answers your question. Back to your reply, you're signing a hash, but for what I understand you are telling me that such hash is re-hashed before padding... I'm going back to the code and to the documents you've sent me to understand things better, thank you very much. [1] http://tools.ietf.org/html/rfc2313 [2] http://tools.ietf.org/html/rfc3279#section-2.2 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to let carmod working after multiple reader system removal.
Hello François, Can you please configure you mail client to not send HTML messages to the list? On Sep 24, 2010, at 9:08 AM, francois.lebl...@cev-sa.com wrote: Please describe how the driver is used by the minidriver, how it differs from normal OpenSC use, what are the biggest and most important differences between the normal pcsc code and the cardmod code. This has already been discuted summary windows process provide pcsc handle and context and you need to use them you can't open context, create handle and access to the card (it's the goal to use opensc under windows) When you insert card under windows, windows detect this insertion open context and create handle with card and give you this informations to your dll to manage card, so you can see that with this process you can'ty create handle to your card since the card is already connected ... That's the description what BaseCSP does with PC/SC handles. It does not describe possible solutions how to accommodate the requirement in OpenSC. Nor how the rest of OpenSC should cope with it. Minidriver code calls sc_create_context like other applications, with the difference that a card handle is already present in the minidriver code and does not need to be fetched via libopensc calls and connected to with a sc_connect So you decided you pass the handles around to the libopensc instance in windows registry (not environment variables as was in another incarnation of OpenSC + BaseCSP). Could you provide working example of incarnation of OpenSC + BaseCSP ? I don't know how much the code @ [1] works or not, but I'm talking about passing in the context and card handle. This means a single instance of an OpenSC based card and reader by default. Why not use the context creation parameters to pass in After start of process an another one with other hanlde can be started... I'm not convinced in windows registry being the best medium for function parameter passing. the necessary handles? There is no IPC present and necessary modifications to the context creation functionality to accommodate BaseCSP requirements is perfectly reasonable argument to change those structures and add code. Especially now, when it is not exposed to outside world. I'm ok to pass pcsc handle and context with in the creation context parameters, but these are needing under pcsc driver, so I need a link between context creation parameters and reader-pcsc, this need more modification that using registry, or I miss something... (See below) Having a single reader driver greatly simplifies the architecture of OpenSC. It also simplifies the proper modifications needed for the cardmod driver. You are free to patch the libopensc instance at runtime any way you want to get what you need. This means overloading the not needed functions from pcsc driver with NULL. And adding necessary logic to the rest of PC/SC functions to return early as needed. As is the case with the rest of reader driver, the decision what to build happens not at runtime, but at compile time. There are several restrictions to what can be put inside a minidriver, so I would build it as a single static dll instead. I don't understand exactly what you mean, but I'm agree with the end building in one static dll will be better, unfortunatly I don't known how to process for now. Necessary modifications to context creation and the pcsc driver can be done with #ifdef ENABLE_CARDMOD. To be able to include the minidriver in the windows installer and to be able to develop it further, it would be nice to have: * the purpose, definition, and overall architecture described, so that something could be understood without digging through the code. * easily buildable and the build process repeatable, with enough instructions in the wiki to accomplish this * properly integrated with OpenSC, this means both pcsc requirements as necessary context handling requirements and whatever else is needed. [1] http://itacns.corp.it/hg/itacns/ -- @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] Patch to let carmod working after multiple reader system removal.
De : Martin Paljak mar...@paljak.pri.ee A: François Leblanc francois.lebl...@cev-sa.com Cc : opensc-devel@lists.opensc-project.org Date: 24/09/2010 10:14 Objet : Re: [opensc-devel] Patch to let carmod working after multiple reader system removal. Hello François, Can you please configure you mail client to not send HTML messages to the list? Ok Guillaume Jean give me tip to do it, hope this time it's working... On Sep 24, 2010, at 9:08 AM, francois.lebl...@cev-sa.com wrote: Please describe how the driver is used by the minidriver, how it differs from normal OpenSC use, what are the biggest and most important differences between the normal pcsc code and the cardmod code. This has already been discuted summary windows process provide pcsc handle and context and you need to use them you can't open context, create handle and access to the card (it's the goal to use opensc under windows) When you insert card under windows, windows detect this insertion open context and create handle with card and give you this informations to your dll to manage card, so you can see that with this process you can'ty create handle to your card since the card is already connected ... That's the description what BaseCSP does with PC/SC handles. It does not describe possible solutions how to accommodate the requirement in OpenSC. Nor how the rest of OpenSC should cope with it. Possible solution to accomodate the requirement have already be seen, I've choice one, you talk about another one with env varables (for me env or registry is quite the same and don't change really the trouble...) For the rest of opensc I don't see what you mean opensc should work like it do now... Minidriver code calls sc_create_context like other applications, with the difference that a card handle is already present in the minidriver code and does not need to be fetched via libopensc calls and connected to with a sc_connect So you decided you pass the handles around to the libopensc instance in windows registry (not environment variables as was in another incarnation of OpenSC + BaseCSP). Could you provide working example of incarnation of OpenSC + BaseCSP ? I don't know how much the code @ [1] works or not, but I'm talking about passing in the context and card handle. This means a single instance of an OpenSC based card and reader by default. Why not use the context creation parameters to pass in After start of process an another one with other hanlde can be started... I'm not convinced in windows registry being the best medium for function parameter passing. Ok, feel free to implement another one, doesn't mind for me, my goal is to provide something working and that we can improve... the necessary handles? There is no IPC present and necessary modifications to the context creation functionality to accommodate BaseCSP requirements is perfectly reasonable argument to change those structures and add code. Especially now, when it is not exposed to outside world. I'm ok to pass pcsc handle and context with in the creation context parameters, but these are needing under pcsc driver, so I need a link between context creation parameters and reader-pcsc, this need more modification that using registry, or I miss something... (See below) Ok, but you talk abourt a csp not a BaseCsp minidriver, is quite different. Having a single reader driver greatly simplifies the architecture of OpenSC. It also simplifies the proper modifications needed for the cardmod driver. You are free to patch the libopensc instance at runtime any way you want to get what you need. This means overloading the not needed functions from pcsc driver with NULL. And adding necessary logic to the rest of PC/SC functions to return early as needed. As is the case with the rest of reader driver, the decision what to build happens not at runtime, but at compile time. There are several restrictions to what can be put inside a minidriver, so I would build it as a single static dll instead. I don't understand exactly what you mean, but I'm agree with the end building in one static dll will be better, unfortunatly I don't known how to process for now. Necessary modifications to context creation and the pcsc driver can be done with #ifdef ENABLE_CARDMOD. To be able to include the minidriver in the windows installer and to be able to develop it further, it would be nice to have: * the purpose, definition, and overall architecture described, so that something could be understood without digging through the code. Ok added some link to wiki page, Microsoft will explain it better than me. * easily buildable and the build process repeatable, with enough instructions in the wiki to accomplish this The build process is already integrated. Instruction to build are provided. If one have trouble to build send list message and we will see how to improve process or complete documentation... * properly
[opensc-devel] Fwd: card-max_recv_size problem
(did not press reply all) Begin forwarded message: From: Martin Paljak mar...@paljak.pri.ee Date: September 24, 2010 2:43:32 PM GMT+03:00 To: Douglas E. Engert deeng...@anl.gov Subject: Re: [opensc-devel] card-max_recv_size problem Hello, On Sep 23, 2010, at 6:28 PM, Douglas E. Engert wrote: I two ran in to a problem with the card-piv.c because of this. It now appears that max_recv_size = 0 implies unlimited length, but should depend on if the card supports extened APDUs and an extended APDU is being requested, What I would think it should mean is 256 for short APDUs and 65536 for extened. max_recv_size=0 should imply that the card or its driver is not broken and can handle Lc=255 and Le=256 for short APDU-s If your card driver does not need it, do not use or set card_max_recv size at all in the driver. max_recv_size was introduced and is only set by cards to values 256, which can't handle the default short APDU default lengths for some reason. It should not be used by default, and should only be used to limit it values below 256. Code in card-piv.c which used to have: apdu.le = (card-max_recv_size = rbuflen)? card-max_recv_size : rbuflen; apdu.resplen = rbuflen; Was changed to: apdu.le = (card-max_recv_size 0 card-max_recv_size = rbuflen)? card-max_recv_size : rbuflen; apdu.resplen = rbuflen; But this would then set apdu.le = rbuflen even if 256. Remove the checks from card-piv.c. They should not be needed. Newer cards can support APDUs, (I don't have one to try) so the code will need to be changed again to use extened APDUs. I don't know a reliable cross-platform method for checking extended APDU support in the reader, so that libopensc could match SC_CARD_CAP_APDU_EXT against a similar flag in the reader. The setting should not affect extended APDU-s, if the logic is mistaken somewhere, it should be fixed. -- @MartinPaljak.net +3725156495 -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Don't dump wiki content into distribution package.
Hello, I tried to simplify the way documentation (that is, manpages) is built and removed the trickery that was used to dump the wiki content to the source tarball. Unfortunately make distcheck fails in doc directory and I can't figure out why. Could anyone with better autotools-fu skills have a look? The patch against current trunk is available online [1] at pastebin. [1] http://pastebin.com/iZLrBywD -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Visual Studio Integration
Hello, I just finished the first version of OpenSC integration in Visual Studio. This integration allows you to use debug breakpoints and view values of variables, so you can enjoy all the Visual Studio features. This it gives opportunity to more developers to help improve OpenSC and therefore improve development and distribution. I tried to setup an architecture that will allow everybody to use it without having to configure Visual Studio in its entirety. It includes a script which puts folders in the right place so that it works with Visual Studio. I made the ReadMe (English and French) for this folder, which gives explanation of the architecture and help to setup this architecture on the developer's computer. For my part I intend to maintain this solution so that it remains functional, of course within the limits of available time that my school gives me. I also intend to add all improvements that will be considered useful. E.g. port the architecture to Visual Studio 2005 and 2008 for a larger opening. Or even integrate other OpenSC projects. Let's talk about technique now. The architecture used is made in order to add the sources from the trunk as simply as possible so there is a folder named sources in which you can simply paste the contents of the src folder of the trunk. And visual studio is configured to fetch files in my architecture sources folder. I unfortunately have to abandon the use Makefiles because Visual Studio doesn't like to use them too much, and it prevents me to use debug mode for each generated dll or .exe. So I find myself with a project for each lib, dll, or executable generated. But it is mandatory with Visual Studio to have a project for each generated executable or dll. I would like to discuss with you whether it would be possible to have a place to continue this adventure with your community. Sincerely, Guillaume JEAN ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Patch to MyEID profile
Hi, Here is a small patch that modifies the MyEID profile. This profile now initializes the cards like we want them (users are of course free to modify the profile to get cards like they want, but we think this should be the default). I suppose the ACL for card initialization (clearing card) is not desired to be NONE and therefore we undefined the KEEP_AC_NONE_FOR_INIT_APPLET, and you can anyway set it to anything you like by configuring the profile. There is a downside with this configuration, pkcs15-init now asks many times (5 times I think) for the USER PIN when it initializes the MyEID card and creates the required files (it does not matter what you enter, because it wont be verified since the card is in creation state). Pkcs15-init creates the SO-PIN, but not the USER PIN. It would be nice if pkcs15-init would create both PINs, since it is built to support two PINs (User and SO). Currently we create the user pin after initialization and finalize the card after that. If somebody knows how to get rid of the unnecessary user PIN queries please apply fix or help us do it. Please apply this small patch, thanks! Kind regards, Toni opensc-0.12.0-aventra.patch Description: Binary data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Don't dump wiki content into distribution package.
2010/9/24 Martin Paljak mar...@paljak.pri.ee: Hello, I tried to simplify the way documentation (that is, manpages) is built and removed the trickery that was used to dump the wiki content to the source tarball. Unfortunately make distcheck fails in doc directory and I can't figure out why. Could anyone with better autotools-fu skills have a look? I also have a problem make[2]: *** Pas de règle pour fabriquer la cible « man/*.1 », nécessaire pour « distdir ». Arrêt. I guess it is because the man/*.1 files are generated by make but when this rule is used the files are not yet present (or not at the correct place). I will try to have a look. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Don't dump wiki content into distribution package.
Ludovic Rousseau wrote: make[2]: *** Pas de règle pour fabriquer la cible « man/*.1 », nécessaire pour « distdir ». Arrêt. I guess it is because the man/*.1 files are generated by make but when this rule is used the files are not yet present (or not at the correct place). I will try to have a look. It would be great to not have more than one level of make, and use includes for subdirectories. That way make can apply rules in the correct order. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fwd: card-max_recv_size problem
On 9/24/2010 6:46 AM, Martin Paljak wrote: (did not press reply all) Begin forwarded message: From: Martin Paljakmar...@paljak.pri.ee Date: September 24, 2010 2:43:32 PM GMT+03:00 To: Douglas E. Engertdeeng...@anl.gov Subject: Re: [opensc-devel] card-max_recv_size problem Hello, On Sep 23, 2010, at 6:28 PM, Douglas E. Engert wrote: I two ran in to a problem with the card-piv.c because of this. It now appears that max_recv_size = 0 implies unlimited length, but should depend on if the card supports extened APDUs and an extended APDU is being requested, What I would think it should mean is 256 for short APDUs and 65536 for extened. max_recv_size=0 should imply that the card or its driver is not broken and can handle Lc=255 and Le=256 for short APDU-s If your card driver does not need it, do not use or set card_max_recv size at all in the driver. max_recv_size was introduced and is only set by cards to values 256, which can't handle the default short APDU default lengths for some reason. It should not be used by default, and should only be used to limit it values below 256. Code in card-piv.c which used to have: apdu.le = (card-max_recv_size= rbuflen)? card-max_recv_size : rbuflen; apdu.resplen = rbuflen; Was changed to: apdu.le = (card-max_recv_size 0 card-max_recv_size= rbuflen)? card-max_recv_size : rbuflen; apdu.resplen = rbuflen; But this would then set apdu.le = rbuflen even if 256. Remove the checks from card-piv.c. They should not be needed. OK, removed the checks for max_recv_size. The code is now just: apdu.le = (rbuflen 256) ? 256 : rbuflen; When I start writing the driver, the opensc.conf set max_recv_size to 248 but the PIV cards required 256, and all the NIST approved reader could do 256. So the older PIV code used to set max_recv_size = 256; Now that max_recv_size can also have a value of 0, the checks where changed, then changed again. The change today not does not check the value of max_recv_size, as it is defaulted to 0 that means 256. Newer cards can support APDUs, (I don't have one to try) so the code will need to be changed again to use extened APDUs. I don't know a reliable cross-platform method for checking extended APDU support in the reader, so that libopensc could match SC_CARD_CAP_APDU_EXT against a similar flag in the reader. The setting should not affect extended APDU-s, if the logic is mistaken somewhere, it should be fixed. -- @MartinPaljak.net +3725156495 -- 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] Visual Studio Integration
Hello, On Fri, Sep 24, 2010 at 15:59, JEAN Guillaume guillaume.j...@supinfo.com wrote: Hello, I just finished the first version of OpenSC integration in Visual Studio. This integration allows you to use debug breakpoints and view values of variables, so you can enjoy all the Visual Studio features. This it gives opportunity to more developers to help improve OpenSC and therefore improve development and distribution. Cool! Where is the patch? How do you handle building dependencies (OpenSSL, iconv, zlib, libltdl) ? Does it support building for 64 bits? Can the build be automated from command line, without requiring modifications via GUI? For my part I intend to maintain this solution so that it remains functional, of course within the limits of available time that my school gives me. I also intend to add all improvements that will be considered useful. E.g. port the architecture to Visual Studio 2005 and 2008 for a larger opening. Or even integrate other OpenSC projects. I only have VS2005, which version are you targeting? I think the basic vs2005 project could also be used (or at least imported) with newer versions verbatim, as OpenSC does not use .NET or any of the windows frameworks that might require a newer version of VS. I don't think all developers (who are not fulltime Windows developers by profession or buy the latest MS developer tools as they are released) upgrade the OS that often. I know I don't :) I unfortunately have to abandon the use Makefiles because Visual Studio doesn't like to use them too much, and it prevents me to use debug mode for each generated dll or .exe. So I find myself with a project for each lib, dll, or executable generated. But it is mandatory with Visual Studio to have a project for each generated executable or dll. There are only a few DLL-s and as many .exe-s as there are tools. That's an OK number of targets (subprojects?). Providing alternatives to the Windows nmake files is good. I would like to discuss with you whether it would be possible to have a place to continue this adventure with your community. Good native windows building would be useful to OpenSC. What kind of place do you have in mind? Cheers, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Don't dump wiki content into distribution package.
2010/9/24 Peter Stuge pe...@stuge.se: Ludovic Rousseau wrote: make[2]: *** Pas de règle pour fabriquer la cible « man/*.1 », nécessaire pour « distdir ». Arrêt. I guess it is because the man/*.1 files are generated by make but when this rule is used the files are not yet present (or not at the correct place). I will try to have a look. It would be great to not have more than one level of make, and use includes for subdirectories. That way make can apply rules in the correct order. Have you noticed an compilation order problem? Do you have the bug number of this issue? Thanks -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] PIV support for NIST 800-73-3.
Updates were committed today (4767) for the PIV card driver to support the new features as defined in NIST 800-73-3 [1] These include the History Object that lists which older keys and/or certificates are on the card, and where to find off card certificates; and the Discovery object that specifies which PIN, global card PIN or the PIV application PIN should be used for login. Although I don't have one of these cards, a sample History object as well as the offline list of certificates provided by NIST was used to test the logic. The PIV driver only supports RSA, but NIST 800-73-3 and NIST 800-78-2 [1] also defines the use of ECC, with 2 specific curves, and the ECDSA using SHA-256 and SHA-384. These have not been implemented yet. The PIV driver can now be built without OpenSSL. OpenSSL is still needed for card administration with the piv-tool. #ifdef ENABLE_OPENSSL now only remove the admin code, and ctx.c was change to allow card-piv.c to be built without OpenSSL. cardctl.h was changed to add some PIV specific control codes as well as define a PIV structure. [1] http://csrc.nist.gov/publications/PubsSPs.html (800-73-3 is in 4 parts. 800-78-2 is one part) -- 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
