Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hi Aleksey,
Aleksey Samsonov wrote:
Hello,
Jan Just Keijser wrote:
in opensc-0.11.13/src/pkcs11/openssl.c there's section
106 void
107 sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
108 {
109 #if OPENSSL_VERSION_NUMBER = 0x1000L
110 /* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.gost */
111 OPENSSL_config(NULL);
112 #endif
It needs for loading and using engine with GOST algorithms.
so the GOST algorithm engine *requires* that an openssl config is loaded
? that does not scale very well: any application can run
OPENSSL_config
or
CONF_modules_load
at any stage. The problem is that you can load and register an engine
only once.
I commented out the OPENSSL_config(NULL) and now it works ...
should this added as a patch? the FIXME seems to be to *remove* the
explicit call to OPENSSL_config; I can confirm that this works for
both openssl-1.0.0-beta4 and the official openssl-1.0.0 release
The FIXME means that call OPENSSL_config(NULL) may have problems and
needs more cleanup solution for loading GOST algorithms' implementation.
so either GOST algorithms work or openssl+opensc-pkcs11 works ? To me
that choice is simple : I'll comment out the OPENSSL_config part until
the GOST driver behaves.
Do you have information why the GOST driver needs this openssl config?
what needs to be loaded? Are there other ways to load the same
information? Is it a particular section of an openssl.cnf file that
needs to be loaded? what if the openssl.cnf file does not contain that
section?
cheers,
JJK
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Middleware-free USB PKI Tokens?
On Fri, 2010-04-16 at 09:38 +0200, Anders Rundgren wrote: If you wanted to provide a USB PKI token that would give the user maximum flexibility it seems that the device should support CCID. Exactly. Most token are supported by OpenCT, which means no security PIN code. Thus it is recommended to use a full PSCS+CCID compatible token if you would like to use mini SIMs. Read: http://www.gooze.eu/howto/smartcard-quickstarter-guide/hardware-prerequisites-smartcard-reader-and-cryptographic -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Middleware-free USB PKI Tokens?
2010/4/16 Anders Rundgren anders.rundg...@telia.com: If you wanted to provide a USB PKI token that would give the user maximum flexibility it seems that the device should support CCID. 1. As I understand,CCID only provides the basic communication and does not address higher level issues such as PKI, right? Yes, CCID is the best choice for USB level communication (as it is standard, other USB protocols would be proprietary). CCID is about exchanging APDU-s over USB and PKI is a whole different story. TCP is for HTTPS what CCID is for PKI. 2. Would a token that emulates FIPS201 and CCID be usable in most systems as is or is there another emulation that would be better? Depends. I don't know the exact relation of FIPS201 to other standards. 3. You would need to hijack somebody else ATR in order to emulate in a (for the user) hassle-free way? Not really. It would not be nice and usually operations depends on the card applet, not the ATR. 4. Other question: CCID allows you to exchange arbitrary data between the token and the host, right? Arbitrary APDU-s so basically yes. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Martin Paljak wrote: On Apr 16, 2010, at 09:51 , Aleksey Samsonov wrote: I commented out the OPENSSL_config(NULL) and now it works ... should this added as a patch? the FIXME seems to be to *remove* the explicit call to OPENSSL_config; I can confirm that this works for both openssl-1.0.0-beta4 and the official openssl-1.0.0 release The FIXME means that call OPENSSL_config(NULL) may have problems and needs more cleanup solution for loading GOST algorithms' implementation. Does this mean that a fix in OpenSC is not needed and the problem lies in OpenSSL land? the problem is not in openssl land but in the way the GOST engine is loaded by the pkcs11 software. The GOST engine requires a section in the openssl.cnf file to load the appropriate shared library. The problem (with openssl) is , is that you cannot register an engine twice. So when a program loads and parses an openssl.cnf file which contains engine definitions then the second attempt to register that enginte will cause a failure. I've built the GOST engine myself and did *NOT* specify an openssl.cnf file : the gost engine still loads, but I am not sure if it is functional. So the real question becomes: is this openssl.cnf section still necessary? is it still required to run OPENSSL_config() during opensc initialisation? Another solution might be to not call OPENSSL_config() but call OPENSSL_config( gost ) instead; this will cause the openssl library to only parse the GOST section (provided there is one) which should solve the problem as well. However, what happens if the gost section is missing? Finally, I also noticed that the behaviour of loading the engine_pkcs11+opensc-pkcs11 is different when a card is present or not: without a card the library initialized just fine (without patching opensc , that is) . If I insert a card and then try to run openssl engine -vvv -t -c then I get the error reported previously . The same is true for trying to sign a certificate request using a card. cheers, JJK ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] openssl-1.0.0 and engine_pkcs11
On Fri, 2010-04-16 at 16:07 +0100, Dimitrios Siganos wrote: Can someone shed some light into this? Good question, I would like to know the answer as well. -- Jean-Michel Pouré - Gooze - http://www.gooze.eu ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] openssl-1.0.0 and engine_pkcs11
Dimitrios Siganos wrote: Hi, I have use openssl-1.0.0 and engine_pkcs11 for storing an rsa private key in a smartcard (feitian epass 3000). I got openssl to access the rsa private key and used it to create a self-signed certificate like this: openssl OpenSSL engine dynamic \ -pre SO_PATH:/home/ds/local/lib/engines/engine_pkcs11.so \ -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD \ -pre MODULE_PATH:opensc-pkcs11.so (dynamic) Dynamic engine loading support [Success]: SO_PATH:/home/ds/local/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:opensc-pkcs11.so Loaded: (pkcs11) pkcs11 engine OpenSSL req -new -x509 -engine pkcs11 -keyform engine -text \ -key slot_1-id_6de677f53533e28254d5890e2d7a15a8135883ca \ engine pkcs11 set. PKCS#11 token PIN: Certificate related prompts... So far so good. Now, I would like this engine to install automatically i.e. without having to run the engine command. I tried adding the following to openssl.cnf ## openssl_conf = openssl_def [ openssl_def ] engines = engine_section [ engine_section ] pkcs11 = pkcs11_section [ pkcs11_section ] engine_id = pkcs11 dynamic_path = /home/ds/local/lib/engines/engine_pkcs11.so MODULE_PATH = opensc-pkcs11.so init = 0 ## but it doesn't work properly. Here's what I get: $ openssl engine -t (dynamic) Dynamic engine loading support [ unavailable ] (4758cca) IBM 4758 CCA hardware engine support [ unavailable ] (aep) Aep hardware engine support [ unavailable ] (atalla) Atalla hardware engine support [ unavailable ] (cswift) CryptoSwift hardware engine support [ unavailable ] (chil) CHIL hardware engine support [ unavailable ] (nuron) Nuron hardware engine support [ unavailable ] (sureware) SureWare hardware engine support [ unavailable ] (ubsec) UBSEC hardware engine support [ unavailable ] (padlock) VIA PadLock (no-RNG, no-ACE) [ unavailable ] (gost) Reference implementation of GOST engine [ available ] (pkcs11) pkcs11 engine Auto configuration failed 1116888:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:521: 1116888:error:260BC066:engine routines:INT_ENGINE_CONFIGURE:engine configuration error:eng_cnf.c:204:section=pkcs11_section, name=dynamic_path, value=/home/ds/local/lib/engines/engine_pkcs11.so 1116888:error:0E07606D:configuration file routines:MODULE_RUN:module initialization error:conf_mod.c:235:module=engines, value=engine_section, retcode=-1 Can someone shed some light into this? I have exactly the same issue (with etokens but also with the Feitian card); see http://www.opensc-project.org/pipermail/opensc-devel/2010-April/013956.html for a quickdirty fix (comment out one line of opensc code). It is still unclear if commenting out this line break the GOST openssl engine (I can't get it to break). cheers, JJK ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] openssl-1.0.0 and engine_pkcs11
Am Freitag 16 April 2010 17:07:49 schrieb Dimitrios Siganos: Hi, I have use openssl-1.0.0 and engine_pkcs11 for storing an rsa private key in a smartcard (feitian epass 3000). I got openssl to access the rsa private key and used it to create a self-signed certificate like this: ah, fine. several people tried that, but noone has analyzed the issue so far. openssl OpenSSL engine dynamic \ -pre SO_PATH:/home/ds/local/lib/engines/engine_pkcs11.so \ -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD \ -pre MODULE_PATH:opensc-pkcs11.so (dynamic) Dynamic engine loading support [Success]: SO_PATH:/home/ds/local/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:opensc-pkcs11.so Loaded: (pkcs11) pkcs11 engine OpenSSL req -new -x509 -engine pkcs11 -keyform engine -text \ -key slot_1-id_6de677f53533e28254d5890e2d7a15a8135883ca \ engine pkcs11 set. PKCS#11 token PIN: Certificate related prompts... So far so good. great. good to see it works for you, so I think the problem in the other bug reports was a mistake by the users (often called layer 8 :) ). Now, I would like this engine to install automatically i.e. without having to run the engine command. I tried adding the following to openssl.cnf ## openssl_conf = openssl_def [ openssl_def ] engines = engine_section [ engine_section ] pkcs11 = pkcs11_section [ pkcs11_section ] engine_id = pkcs11 dynamic_path = /home/ds/local/lib/engines/engine_pkcs11.so MODULE_PATH = opensc-pkcs11.so init = 0 ## but it doesn't work properly. hmm. it looks very much like the config file I use, and that worked for me very well for older versions of openssl. here is my file: --cut-- openssl_conf= openssl_def [openssl_def] engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /usr/lib/engines/engine_pkcs11.so MODULE_PATH = /home/aj/opentest/lib/opensc-pkcs11.so PIN = 1234 init = 0 [req] distinguished_name = req_distinguished_name [req_distinguished_name] --cut-- so the big changes I see: * the [req] section might be necessary for some reason * I specified the whole path to opensc-pkcs11.so. please try these changes with your openssl 1.0.0, and let us know if it fixes the problem. if not we need to debug this in detail and/or talk to the openssl developers to track down and fix this issue. Here's what I get: $ openssl engine -t uh, not sure if all these engines are compatible. maybe several of them try to use your smart card reader, and they fight over it, or something like that? if you could disable them for testing, that would help too. 1116888:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:521: but my best guess is this: the code couldn't find opensc-pkcs11.so, so you need to specify the full path. also - for testing only, or on very, very, very secure machines - you can keep the PIN = 1234 in the config file. but usualy it is best to remove that line, and the openssl/engine_pkcs11 combo will ask you for the pin. if you have a card with normal user pin/puk and a security officier pin/puk, you can also try opensc-pkcs11-onepin.so instead of opensc-pkcs11.so which hides the security officer pin (it causes trouble with some applications like firefox). Good luck, and please let us know if it works for you. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
maybe an strace (strace -o strace.log -f -s -tt openssl ... ) will show what is wrong. if possible put the file on a web page, as it could be huge, too big for this list. if that isn't possible, compress it and send it to me only (but no idea when I will be able to look at it). what you tried looks very good, so no idea. but I haven't found time to testing openssl 1.0.0 myself, same seems true for all developers. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Am Freitag 16 April 2010 01:16:47 schrieb Jan Just Keijser:
hi list,
I hate to answer my own question but I think I found it:
in opensc-0.11.13/src/pkcs11/openssl.c there's section
106 void
107 sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
108 {
109 #if OPENSSL_VERSION_NUMBER = 0x1000L
110 /* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.gost */
111 OPENSSL_config(NULL);
112 #endif
I commented out the OPENSSL_config(NULL) and now it works ...
should this added as a patch? the FIXME seems to be to *remove* the
explicit call to OPENSSL_config; I can confirm that this works for both
openssl-1.0.0-beta4 and the official openssl-1.0.0 release
ah, ouch. thats a brown paperbag bug. thanks for finding and
reporting.
I think this would be a very good reason for a new 0.11.* release.
any other patches that should be backported? (only tiny fixes please).
martin, if you decide to make a new release and need any help,
please let me know.
Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Am Freitag 16 April 2010 08:51:31 schrieb Aleksey Samsonov:
Hello,
Jan Just Keijser wrote:
in opensc-0.11.13/src/pkcs11/openssl.c there's section
106 void
107 sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
108 {
109 #if OPENSSL_VERSION_NUMBER = 0x1000L
110 /* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.gost */
111 OPENSSL_config(NULL);
112 #endif
It needs for loading and using engine with GOST algorithms.
I think we cannot break an existing and often used feature, for the sake
of a new feature, so there has to be a different way.
so its a regression and the natural way to handle this would be to revert
your change. but it breaks opensc for gost users. what can we do for them
to improve the situation, without breaking openssl/engine/opensc use?
Regards, Andreas
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] openssl-1.0.0 and engine_pkcs11
Hi *, Jean-Michel Pouré - GOOZE wrote: On Fri, 2010-04-16 at 18:31 +0200, Andreas Jellinghaus wrote: if not we need to debug this in detail and/or talk to the openssl developers to track down and fix this issue. Do not hesitate to propose them Free PKI developer card at this address: http://www.gooze.eu/feitian-pki-free-software-developer-card I'm still testing the Feitian card for both my work purposes (grid computing) and for OpenVPN ; this openssl issue was a major showstopper but there still quite a few things not working properly with the feitian card (driver) . When I'm done I'll report my findings here. Two biggest problems right now: - generating 2048 bit keys on the card does not work - I cannot sign a certificate request using 'openssl req -engine pkcs11 ...' for some reason (error -1200) Both operations work with Aladdin eTokens and the opensc-pkcs11/cardos driver, so it's most likely an issue with the 'entersafe' driver. Again, I'm not done yet but when I am I will give all details of my tests. Thanks Jean-Michel, for providing me with a free Feitian card and thanks , Andreas, for opensc ! cheers, JJK ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hello,
Andreas Jellinghaus wrote:
Am Freitag 16 April 2010 08:51:31 schrieb Aleksey Samsonov:
Hello,
Jan Just Keijser wrote:
in opensc-0.11.13/src/pkcs11/openssl.c there's section
106 void
107 sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
108 {
109 #if OPENSSL_VERSION_NUMBER = 0x1000L
110 /* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.gost */
111 OPENSSL_config(NULL);
112 #endif
It needs for loading and using engine with GOST algorithms.
I think we cannot break an existing and often used feature, for the sake
of a new feature, so there has to be a different way.
I'm absolutely agree with you.
so its a regression and the natural way to handle this would be to revert
your change. but it breaks opensc for gost users. what can we do for them
to improve the situation, without breaking openssl/engine/opensc use?
I started to looking for right solution. I can test if anyone has any
solutions.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hi Aleksey,
Aleksey Samsonov wrote:
Hello,
Andreas Jellinghaus wrote:
Am Freitag 16 April 2010 08:51:31 schrieb Aleksey Samsonov:
Hello,
Jan Just Keijser wrote:
in opensc-0.11.13/src/pkcs11/openssl.c there's section
106 void
107 sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
108 {
109 #if OPENSSL_VERSION_NUMBER = 0x1000L
110 /* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.gost */
111 OPENSSL_config(NULL);
112 #endif
It needs for loading and using engine with GOST algorithms.
I think we cannot break an existing and often used feature, for the sake
of a new feature, so there has to be a different way.
I'm absolutely agree with you.
so its a regression and the natural way to handle this would be to revert
your change. but it breaks opensc for gost users. what can we do for them
to improve the situation, without breaking openssl/engine/opensc use?
I started to looking for right solution. I can test if anyone has any
solutions.
I was not able to reproduce your original problem, i.e. the GOST engine
not working with openssl 1.0.0 and with the OPENSSL_config line
commented out. Can you test this combo:
- openssl 1.0.0 + GOST library
- opensc 0.11.13
- run
openssl engine -vvv -t -c
cheers,
JJK
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Middleware-free USB PKI Tokens?
Anders Rundgren wrote: your third question I did not understand. ATRs identify the card's type, right? Sort of, it has characteristics of the card. Google for: parsing an ATR. So if you don't want to write a card profile but have full freedom on the token side the token would need to use an ATR that belongs to some other vendor or community. Does all FIPS201 cards share an ATR or need middleware to recognize different vendors? FIPS PUB 201-1: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION Personal Identity Verification (PIV) of Federal Employees and Contractors The OpenSC PIV driver is for the FIPS201 cards. http://www.opensc-project.org/opensc/wiki/UnitedStatesPIV So I am not sure what your are tring to do. NIST 800-73 states that the different Application IDs. See the Opensc src/libopensc/card-piv.c and look for piv_aids[]. The card-piv will do a piv_select_aid to see if the card has the PIV application as the default. The various vendors have different ATRs (The application ID may be in the ATR too, for example: an Obether card has: 3b:db:96:00:81:b1:fe:45:1f:03:80:f9:a0:00:00:03:08:00:00:10:00:18 ^^ P.S. I am getting ready to update the driver to NIST 800-73-3. Assuming the above is not completely BS (may not be the case...), how about exchanging non-standard objects as well over the very same CCID+PCSC interface? Anders Jan Just Keijser wrote: Hi Anders, Anders Rundgren wrote: If you wanted to provide a USB PKI token that would give the user maximum flexibility it seems that the device should support CCID. 1. As I understand,CCID only provides the basic communication and does not address higher level issues such as PKI, right? 2. Would a token that emulates FIPS201 and CCID be usable in most systems as is or is there another emulation that would be better? 3. You would need to hijack somebody else ATR in order to emulate in a (for the user) hassle-free way? 4. Other question: CCID allows you to exchange arbitrary data between the token and the host, right? most of this information can easily be found using YourFavouriteSearchEngine, e.g. http://www.smartcardalliance.org/newsletter/february_2005/feature_0205.html CCID: The Chip Card Interface Device (CCID) specification is an approach to smart card reader communication that is gaining in popularity. The specification defines a standard communication protocol for smart card readers that connect to a computer via USB, allowing the same host-side driver to communicate with any CCID-compliant smart card reader. Microsoft provides a CCID driver through the Windows Update system. All new smart card reader deployments should seriously consider using CCID-compliant readers, both to reduce driver installation issues and to ensure that, in the future, the installed smart card readers can be easily and transparently replaced with any other CCID-compliant reader. PC/SC: The basic technology for communication between personal computers and smart cards is PC/SC, defined by the PC/SC Workgroup (www.pcscworkgroup.com). PC/SC defines an application program interface (API) that provides software developers with a standard set of tools for managing smart card readers and communicating with readers and cards. The PC/SC interface defines standard interfaces for a variety of smart card related-operations. The most common are: * Enumerating and describing attached smart card readers * Requesting information about card and reader states * Exchanging commands with cards Microsoft has implemented the PC/SC API as part of the Win32® API, which is the fundamental toolset for building Windows applications. Microsoft is also a member of the PC/SC Workgroup. your third question I did not understand. cheers, JJK ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- 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] openssl-1.0.0 and engine_pkcs11
Andreas Jellinghaus wrote: great. good to see it works for you, so I think the problem in the other bug reports was a mistake by the users (often called layer 8 :) ). In order to get it to work I had to do the following: 1) built opensc from svn, I used revision 4216 (the latest stable release didn't work) 2) use openct-0.6.20 3) libp11-0.2.7 4) engine_pkcs11-0.1.8 5) tell opensc to use openct reader_drivers = openct; 6) disabled pcsc, sudo service pcscd stop 7) plug the usb dongle first and then run /etc/init.d/openct start hmm. it looks very much like the config file I use, and that worked for me very well for older versions of openssl. here is my file: That's because it does! :-) I just tried openssl-0.9.8k and that works fine. I guess I have the same problem as the one described in this thread: http://www.opensc-project.org/pipermail/opensc-devel/2010-April/013953.html Thank you for your comments, Dimitrios Siganos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] smartcard key id too long
Hi, I am using a feitian epass 3000 usb smartcard and I have a problem with the length of the key id of the RSA private key on the smartcard. This is what pkcs15-tool reports: $ pkcs15-tool -k Using reader with a card: CCID Compatible Private RSA Key [Private Key] Com. Flags : 3 Usage : [0x4], sign Access Flags: [0x0] ModLength : 1024 Key ref : 1 Native : yes Path: 3f005015 Auth ID : 01 ID : 6de677f53533e28254d5890e2d7a15a8135883ca This is an example usage of the key: openssl req -new -x509 -engine pkcs11 -keyform engine -text \ -in slot_1-id_6de677f53533e28254d5890e2d7a15a8135883ca I have tried generating the key in the card and also generating it on the PC and copying into the smartcard. in both cases, I end up with a long id. My question is: can I change this id and make it smaller? Who allocates this id? Some apps, assume that the key id is small and don't allocate enough buffer space for my long key id. Regards, Dimitrios Siganos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
