opensc-devel — discussion of developement of OpenSC and related projects

Re: [Opensc-devel] CardOS 5.3 driver

[Jakub J. <jj...@re...>]

On 03/20/2017 06:08 PM, Douglas E Engert wrote:
> First of all, I can not do much until late next week.
>
> What I was pointing out is  sc_get_encoding_flags  takes the algorithm
> flags and breaks them apart into what the card is expected to do, and
> what OpenSC software will do. i.e. who adds/removes the padding. The
> card's senv routine can then tell the card what it needs to do. The
> algorithm flags should only indicate what the card (or the card driver)
> can do . I hope you would find the debugging messages useful  so you
> could set the algorithm flags to match what the card and card driver and
> its senv routine can do.
>
> There may be a difference is the term RAW. From the PKCS#11
> CKM_RSA_X_509 the input and output will both be the key size and the
> calling application will do all hashing and padding for both sign and
> decrypt, If the card(and driver) can not do this, then the CKM_RSA_X_509
> should not be registered.
>
> Actually PKCS#11 mechanisms also have a HW flag, indicating the
> mechanism is preformed in hardware, so claiming it is hardware, but
> doing parts in the driver can be misleading to an application.
>
> It sounds like the card has  SC_CARD_CAP_ONLY_RAW_HASH_STRIPPED
> and  SC_CARD_CAP_ONLY_RAW_HASH. These do not sound like CKM_RSA_X_509
> to me but more about does the card expect the hash to be stripped or not.

Thank you for your time. I played a bit more with the flags specified in 
the cardos_init() and managed to "turn off" the RSA_X_509 mechanism by 
specifying SC_ALGORITHM_RSA_PAD_PKCS1 (other mechanisms stays intact).

https://github.com/Jakuje/OpenSC/commit/489508cf

This has a "side effect" of disabling the RSA_X_509 mechanisms also for 
the signatures, but that should not be a big deal, because the signature 
routine has also some hacks to strip padding from data for signatures in 
case it fails sign data with padding.

I am not sure if this even worked in older CardOS cards. I will fill a 
pull request with the changes so far and try to ping people who 
contributed parts of CardOS drivers, if they can verify functionality 
with their cards (or if this can be changed in older versions too).

Thanks,
Jakub

Re: [Opensc-devel] Card missing, for a second

[Ludovic R. <lud...@gm...>]

2017-03-21 16:27 GMT+01:00 <Ken...@mi...>:

> Hi,
>
>
>
> Yes, I noticed the card removal in the scan log, eventhough the card was
> still in place...
>
> Tue Mar 21 15:37:09 2017
>
> Reader 0: #[35mGeneric Smart Card Reader Interface [Smart Card Reader
> Interface] (20070818000000000) 00 00#[0m
>
>   Card state: #[31mCard removed, #[0m
>
>
>
> Tue Mar 21 15:37:11 2017
>
> Reader 0: #[35mGeneric Smart Card Reader Interface [Smart Card Reader
> Interface] (20070818000000000) 00 00#[0m
>
>   Card state: #[31mCard inserted, #[0m
>
>
>
> I attach the full log with the device under-test (pluss-ID).
>
>
>
> With same software,  I ran identical test, same card, but with different
> reader
>
> For reference sake; I also attached the  working reference (scr3500) log
> from pcsc_scan
>

So the PC/SC layer is reporting a card removal event.

Next step is to get pcscd logs as described in [1] to know what is causing
the card removal event.

Do you have the same problem with this reader and a "normal" system (not a
compressed&read-only environment)? That would ease debug on your side.

Bye

[1] https://pcsclite.alioth.debian.org/ccid.html#support

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] Card missing, for a second

[Ludovic R. <lud...@gm...>]

2017-03-20 13:32 GMT+01:00 <J.W...@mi...>:

> Hi all,
>

Hello,


>
>
> Did anyone see such behavior before?
>
>
>
> With a card firm in the reader, firm in a laptop, PKCS11_eventmanager
> sometimes (erroneously) reports the card getting missing and found again.
>
> In my case, the consequences are bad, as the “card-out”-event causes my
> openvpn- connection to be closed.
>
>
>
> To make the situation more troublesome: it only happens with a new
> cardreader I received for evaluation. – not with others-
>
> Could this have anything to do with or not supporting supporting extended
> APDU’s ?
>

Do you see card or reader events using the pcsc_scan tool?

Bye

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] Card missing, for a second

[<J.W...@mi...>]

Hi all,

Did anyone see such behavior before?

With a card firm in the reader, firm in a laptop, PKCS11_eventmanager sometimes (erroneously) reports the card getting missing and found again.
In my case, the consequences are bad, as the "card-out"-event causes my openvpn- connection to be closed.

To make the situation more troublesome: it only happens with a new cardreader I received for evaluation. - not with others-
Could this have anything to do with or not supporting supporting extended APDU's ?

And getting even obscure: if I setup my VPN-connection, and only do constantly a PING, the tunnel stays stable for hours. However, when I run a Citrix-session through it, 9 out of 10 times, my smartcard gets immediately missing for a fraction of time. Bizarre!

For a moment I'd considered that USB-forwarding to be active, and stealing the reader from my linux-system, but I made sure that is not the case.

HtH, Hans

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Opensc-devel] CardOS 5.3 driver

[Jakub J. <jj...@re...>]

On 03/19/2017 10:30 PM, Douglas E Engert wrote:
> In regards to RSA_X_509, it may be the algorithm flags are wrong.
>
>  An RSA_X_509 operation to a card can be the same operation used to sign
> a padded block the size of the key, or to decrypt a key size block and
> return the results, without removing any padding, which allows for using
> other other padding mechanisms.

The cardos driver has its method to compute signature, which works with 
a little bit of guesswork [1] what method will be available and in case 
in the need of the others, it fixes the padding, if I read the comments 
and code right. This can not be used by the decryption, because you 
don't know what random bytes were added as a padding while encrypting.

> It could also be the senv is setting flags that tell the card to remove
> the padding whenit should not, or the card can not do RSA_X_509.
>
> It would be interesting to see an opensc-debug.log for
>  sc_pkcs15_decipher
> when it calls sc_get_encoding_flags in padding.c

Without the first commit in my branch it fails during setting up 
security environment [2].

After adding this commit, RSA_X_509 mechanism succeeds and RSA_PKCS 
fails (the logs also in the linked gist [2]). In the readme, there are 
also command I used to create the encrypted data using OpenSSL (in case 
there could go something wrong, though the tests were performed also 
with the same testsuite I use for other cards).

Let me know if you want the whole logs.

[1] 
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L888
[2] 
https://gist.github.com/Jakuje/5a993d2b2d8a9cac35203599e49e6831#file-opensc-master-log

Jakub

> On Fri, Mar 17, 2017 at 6:38 AM, Jakub Jelen <jj...@re...
> <mailto:jj...@re...>> wrote:
>
>     Hello all,
>     we got several CardOS 5.3 cards that I tried to implement support for in
>     OpenSC. The initial detection is already merged [1].
>
>     The approach used CardOS 5.0 was not working everywhere so before
>     submitting the pull request with all the changes, I would like to hear
>     some feedback on some questionable parts and preferable verify that the
>     changes are not breaking anything that worked with CardOS 5.0 as
>     originally implemented years ago (adding szikora, who implemented
>     initial CardOS 5.0 support in PR#170) or if some of the concepts in new
>     cards work also in the old ones.
>
>     All changes are in my branch [2] are in four commits
>
>     The first two make the signatures working:
>       * Separately detect 5.3 version and use p1 = 0x41 for security
>     environment -- will it work also in the old cards?
>       * Remove SC_ALGORITHM_NEED_USAGE which prevented using
>     cardos_compute_signature() with 5.3 cards. Does 5.0 or older cards need
>     that?
>
>     The last two changes are more hackish and used to make decipher
>     mechanisms working (it looks like the card strips all the padding). Or
>     is there any possibility to disable in OpenSC RSA_X_509 raw decipher
>     mechanisms for this driver?
>
>     Comments, thoughts?
>
>     [1] https://github.com/OpenSC/OpenSC/commit/ac96e73
>     <https://github.com/OpenSC/OpenSC/commit/ac96e73>
>     [2] https://github.com/Jakuje/OpenSC/commits/jjelen-cardos53
>     <https://github.com/Jakuje/OpenSC/commits/jjelen-cardos53>
>
>     Regards,
>     --
>     Jakub Jelen
>     Software Engineer
>     Security Technologies
>     Red Hat
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Opensc-devel mailing list
>     Ope...@li...
>     <mailto:Ope...@li...>
>     https://lists.sourceforge.net/lists/listinfo/opensc-devel
>     <https://lists.sourceforge.net/lists/listinfo/opensc-devel>
>
>


-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

[Opensc-devel] different key usage/access flags pkcs11-tool/pkcs15-init

[Peter P. <pop...@gm...>]

Hello,


pkcs11-tool seems to set wrong Access Flags on Private EC keys

pkcs15-init sets Access Flags to 0x1D, pkcs11-tool to 0x0, examples below.


Second question: Is there a switch to set key usage "derive" in pkcs15-init ?
$ pkcs15-init --generate-key ec-prime256v1  --auth-id 1 --pin 11111111
--id 14 --label pkcs15_key --key-usage sign,derive
Unknown X.509 key usage derive

pkcs11-tool can generate this usage:
$ pkcs11-tool  --login --pin 11111111 --keypairgen --key-type
EC:prime256v1 --id 14 --label pkcs11_key --usage-derive --usage-sign







Examples:



$ pkcs15-init --generate-key ec-prime256v1  --auth-id 1 --pin 11111111
--id 14 --label pkcs15_key --key-usage sign
$ pkcs15-tool --list-keys  --list-public-keys

Private EC Key [pkcs15_key]
        Object Flags   : [0x3], private, modifiable
        Usage          : [0xC], sign, signRecover
        Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
        FieldLength    : 256
        Key ref        : 1 (0x1)
        Native         : yes
        Path           : 3f0050154b01
        Auth ID        : 01
        ID             : 14
        MD:guid        : 0dbf2b61-22e1-9b48-d19d-c3ed217d60bc

Public EC Key [pkcs15_key]
        Object Flags   : [0x2], modifiable
        Usage          : [0xC0], verify, verifyRecover
        Access Flags   : [0x0]
        FieldLength    : 256
        Key ref        : 0 (0x0)
        Native         : no
        Path           : 3f0050155501
        ID             : 14



pkcs11-tool example:

$ pkcs11-tool  --login --pin 11111111 --keypairgen --key-type
EC:prime256v1 --id 14 --label pkcs11_key --usage-sign
Using slot 0 with a present token (0x0)
Key pair generated:
Private Key Object; EC
  label:      pkcs11_key
  ID:         14
  Usage:      sign
Public Key Object; EC  EC_POINT 256 bits
  EC_POINT:   044104f804f2b748d3edda96b667e9203feca943076df2aeaf23eb5b6971ffcd06c32cdb46c299e62fb5c05b6df6662d8757333403f2d0ac5d0361810c972ed7941fd3
  EC_PARAMS:  06082a8648ce3d030107
  label:      pkcs11_key
  ID:         14
  Usage:      verify

$ pkcs15-tool --list-keys  --list-public-keys
Private EC Key [pkcs11_key]
        Object Flags   : [0x3], private, modifiable
        Usage          : [0xC], sign, signRecover
        Access Flags   : [0x0]
        FieldLength    : 256
        Key ref        : 1 (0x1)
        Native         : yes
        Path           : 3f0050154b01
        Auth ID        : 01
        ID             : 14
        MD:guid        : 0dbf2b61-22e1-9b48-d19d-c3ed217d60bc

Public EC Key [pkcs11_key]
        Object Flags   : [0x2], modifiable
        Usage          : [0xC0], verify, verifyRecover
        Access Flags   : [0x0]
        FieldLength    : 256
        Key ref        : 0 (0x0)
        Native         : no
        Path           : 3f0050155501
        ID             : 14

Re: [Opensc-devel] CardOS 5.3 driver

[Douglas E E. <dee...@gm...>]

In regards to RSA_X_509, it may be the algorithm flags are wrong.

 An RSA_X_509 operation to a card can be the same operation used to sign a
padded block the size of the key, or to decrypt a key size block and return
the results, without removing any padding, which allows for using other
other padding mechanisms.

It could also be the senv is setting flags that tell the card to remove the
padding whenit should not, or the card can not do RSA_X_509.

It would be interesting to see an opensc-debug.log for     sc_pkcs15_decipher

when it calls sc_get_encoding_flags in padding.c



On Fri, Mar 17, 2017 at 6:38 AM, Jakub Jelen <jj...@re...> wrote:

> Hello all,
> we got several CardOS 5.3 cards that I tried to implement support for in
> OpenSC. The initial detection is already merged [1].
>
> The approach used CardOS 5.0 was not working everywhere so before
> submitting the pull request with all the changes, I would like to hear
> some feedback on some questionable parts and preferable verify that the
> changes are not breaking anything that worked with CardOS 5.0 as
> originally implemented years ago (adding szikora, who implemented
> initial CardOS 5.0 support in PR#170) or if some of the concepts in new
> cards work also in the old ones.
>
> All changes are in my branch [2] are in four commits
>
> The first two make the signatures working:
>   * Separately detect 5.3 version and use p1 = 0x41 for security
> environment -- will it work also in the old cards?
>   * Remove SC_ALGORITHM_NEED_USAGE which prevented using
> cardos_compute_signature() with 5.3 cards. Does 5.0 or older cards need
> that?
>
> The last two changes are more hackish and used to make decipher
> mechanisms working (it looks like the card strips all the padding). Or
> is there any possibility to disable in OpenSC RSA_X_509 raw decipher
> mechanisms for this driver?
>
> Comments, thoughts?
>
> [1] https://github.com/OpenSC/OpenSC/commit/ac96e73
> [2] https://github.com/Jakuje/OpenSC/commits/jjelen-cardos53
>
> Regards,
> --
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

[Opensc-devel] CardOS 5.3 driver

[Jakub J. <jj...@re...>]

Hello all,
we got several CardOS 5.3 cards that I tried to implement support for in 
OpenSC. The initial detection is already merged [1].

The approach used CardOS 5.0 was not working everywhere so before 
submitting the pull request with all the changes, I would like to hear 
some feedback on some questionable parts and preferable verify that the 
changes are not breaking anything that worked with CardOS 5.0 as 
originally implemented years ago (adding szikora, who implemented 
initial CardOS 5.0 support in PR#170) or if some of the concepts in new 
cards work also in the old ones.

All changes are in my branch [2] are in four commits

The first two make the signatures working:
  * Separately detect 5.3 version and use p1 = 0x41 for security 
environment -- will it work also in the old cards?
  * Remove SC_ALGORITHM_NEED_USAGE which prevented using 
cardos_compute_signature() with 5.3 cards. Does 5.0 or older cards need 
that?

The last two changes are more hackish and used to make decipher 
mechanisms working (it looks like the card strips all the padding). Or 
is there any possibility to disable in OpenSC RSA_X_509 raw decipher 
mechanisms for this driver?

Comments, thoughts?

[1] https://github.com/OpenSC/OpenSC/commit/ac96e73
[2] https://github.com/Jakuje/OpenSC/commits/jjelen-cardos53

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

Re: [Opensc-devel] License clarification

[Jakub J. <jj...@re...>]

On 03/06/2017 01:30 PM, Martin Paljak wrote:
> Maybe the tests/files that are quite arbitrary and not really used these
> days, can be just removed as noise?

Yes, the tests popped on me and there was obvious author so I tried at 
least. The other looked more "suspicious" as they are compiled into the 
main binaries.

For cross-reference, I submitted PR with these changes:

https://github.com/OpenSC/OpenSC/pull/988

Thanks for cooperation,
Jakub

Re: [Opensc-devel] License clarification

[Jakub J. <jj...@re...>]

On 03/06/2017 12:11 PM, Andreas Jellinghaus wrote:
> Hi Jakub,
>
> my assumption always was: one clear license statement for the whole
> software is good enough - only divergent files got marked as such.
> For the core files we might have the boilerplate in each file, but I
> felt that was "nice to have", and not essential.

Hello Andreas,
I am no expert on licenses, but there are automatic tools for checking 
the source files (for example in Fedora review tool) to make sure 
nothing "wrong" gets into releases and identify "the divergent files". 
Since I was in this process, I decided to clarify the missing bits so 
other people going through the similar processes will not have to 
struggle with similar problems.

The license are good and you are most probably right with your 
assumption. But having that written directly in the files makes it clean 
as it can be without any dispute.


> All files are good from my perspective, as they are opensc core files,
> only these two could be checked in detail:
>
> src/libopensc/internal-winscard.h
>
> ah, seems this was added in 2008 as part of some build system change?
> ludovic would know what license this would have, if it comes from pcsc.
>
> https://pcsclite.alioth.debian.org/api/winscard_8h_source.html
>
> indicates BSD license, but it is better to clarify this with ludovic.
>
> src/common/compat_strlcpy.h
>
> either this file is too trivial to be protected by copyright, or it is
> licensed under the same BSD clause as compat_strlcpy.c. Either way
> opensc is fine.

Thank you for details. I have got already a message from Ludovic so I 
will put that together,

Thanks,
Jakub

Re: [Opensc-devel] License clarification

[Ludovic R. <lud...@gm...>]

Hello,

2017-03-06 12:11 GMT+01:00 Andreas Jellinghaus <an...@io...>:
>
> Hi Jakub,
>
> my assumption always was: one clear license statement for the whole
software is good enough - only divergent files got marked as such.
> For the core files we might have the boilerplate in each file, but I felt
that was "nice to have", and not essential.
>
> All files are good from my perspective, as they are opensc core files,
only these two could be checked in detail:
>
> src/libopensc/internal-winscard.h
>
> ah, seems this was added in 2008 as part of some build system change?
ludovic would know what license this would have, if it comes from pcsc.
>
> https://pcsclite.alioth.debian.org/api/winscard_8h_source.html
>
> indicates BSD license, but it is better to clarify this with ludovic.

>From a file comment:
/* Mostly copied from pcsc-lite, this is the minimum required */

So the license should be the same as for pcsc-lite i.e. 3-clause BSD
license as in, the original,
https://github.com/LudovicRousseau/PCSC/blob/master/src/PCSC/winscard.h

> src/common/compat_strlcpy.h
>
> either this file is too trivial to be protected by copyright, or it is
licensed under the same BSD clause as compat_strlcpy.c. Either way opensc
is fine.

I wrote this file because the corresponding strlcpy.c has no .h file.
I added a license in the strlcpycat.h file for pcsc-lite. See
https://github.com/LudovicRousseau/PCSC/blob/master/src/strlcpycat.h

Bye

--
 Dr. Ludovic Rousseau

Re: [Opensc-devel] License clarification

[Martin P. <ma...@ma...>]

Maybe the tests/files that are quite arbitrary and not really used these
days, can be just removed as noise?

On Mon, 6 Mar 2017 at 13:40 Andreas Jellinghaus <an...@io...>
wrote:

> Hi Jakub,
>
> my assumption always was: one clear license statement for the whole
> software is good enough - only divergent files got marked as such.
> For the core files we might have the boilerplate in each file, but I felt
> that was "nice to have", and not essential.
>
> All files are good from my perspective, as they are opensc core files,
> only these two could be checked in detail:
>
> src/libopensc/internal-winscard.h
>
> ah, seems this was added in 2008 as part of some build system change?
> ludovic would know what license this would have, if it comes from pcsc.
>
> https://pcsclite.alioth.debian.org/api/winscard_8h_source.html
>
> indicates BSD license, but it is better to clarify this with ludovic.
>
> src/common/compat_strlcpy.h
>
> either this file is too trivial to be protected by copyright, or it is
> licensed under the same BSD clause as compat_strlcpy.c. Either way opensc
> is fine.
>
> Regards, Andreas
>
> 2017-03-06 10:57 GMT+01:00 Jakub Jelen <jj...@re...>:
>
> Hello,
> I was going through the files in the OpenSC repository and noticed
> several files with missing/unknown licenses.
>
> These files miss any open source license headers (adding Olaf Kirch if
> the email is still valid who is author):
>
> src/pkcs15init/pkcs15-init.h
> src/pkcs15init/profile.h
> src/libopensc/reader-openct.c
> src/common/libpkcs11.c
> src/pkcs11/mechanism.c
> src/pkcs11/openssl.c
>
>
> These files miss also header, but says about the source in pcsc-lite
> (adding Ludovic, who should be able to clarify the license):
>
> src/libopensc/internal-winscard.h
> src/common/compat_strlcpy.h
>
>
> Several more files without contact information:
>
> src/common/compat_report_rangecheckfailure.c
> src/common/compat_getopt_main.c
>
>
> And some more files from Juha Yrjölä (if the mail still works) without
> any open source license header:
>
> src/tests/lottery.c
> src/tests/p15dump.c
> src/tests/pintest.c
> src/tests/print.c
> src/tests/prngtest.c
>
> Can we get the clarification from the original authors, or is there
> somebody in the project who would be able to clarify the licenses and
> update the files to make sure the license is in align with the project?
>
> Thanks,
> --
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
-- 

typos expected due to mobile device

Re: [Opensc-devel] License clarification

[Andreas J. <an...@io...>]

Hi Jakub,

my assumption always was: one clear license statement for the whole
software is good enough - only divergent files got marked as such.
For the core files we might have the boilerplate in each file, but I felt
that was "nice to have", and not essential.

All files are good from my perspective, as they are opensc core files, only
these two could be checked in detail:

src/libopensc/internal-winscard.h

ah, seems this was added in 2008 as part of some build system change?
ludovic would know what license this would have, if it comes from pcsc.

https://pcsclite.alioth.debian.org/api/winscard_8h_source.html

indicates BSD license, but it is better to clarify this with ludovic.

src/common/compat_strlcpy.h

either this file is too trivial to be protected by copyright, or it is
licensed under the same BSD clause as compat_strlcpy.c. Either way opensc
is fine.

Regards, Andreas

2017-03-06 10:57 GMT+01:00 Jakub Jelen <jj...@re...>:

> Hello,
> I was going through the files in the OpenSC repository and noticed
> several files with missing/unknown licenses.
>
> These files miss any open source license headers (adding Olaf Kirch if
> the email is still valid who is author):
>
> src/pkcs15init/pkcs15-init.h
> src/pkcs15init/profile.h
> src/libopensc/reader-openct.c
> src/common/libpkcs11.c
> src/pkcs11/mechanism.c
> src/pkcs11/openssl.c
>
>
> These files miss also header, but says about the source in pcsc-lite
> (adding Ludovic, who should be able to clarify the license):
>
> src/libopensc/internal-winscard.h
> src/common/compat_strlcpy.h
>
>
> Several more files without contact information:
>
> src/common/compat_report_rangecheckfailure.c
> src/common/compat_getopt_main.c
>
>
> And some more files from Juha Yrjölä (if the mail still works) without
> any open source license header:
>
> src/tests/lottery.c
> src/tests/p15dump.c
> src/tests/pintest.c
> src/tests/print.c
> src/tests/prngtest.c
>
> Can we get the clarification from the original authors, or is there
> somebody in the project who would be able to clarify the licenses and
> update the files to make sure the license is in align with the project?
>
> Thanks,
> --
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] License clarification

[Jakub J. <jj...@re...>]

On 03/06/2017 11:13 AM, Olaf Kirch wrote:
>
> Hi Jakub,
>
> Please refresh my memory; what is the license of the other files in
> pkcs15init and the pkcs11 code that I authored? Any files missing
> license information should use the same.

The other files (for example src/pkcs15init/pkcs15-cardos.c) are LGPL 
2.1 or later if I read right (as the whole project).

Thank you for clarification. I will take care of the update in the 
upstrem repository with reference to this email.

Jakub

> On Mon, 2017-03-06 at 10:57 +0100, Jakub Jelen wrote:
>> Hello,
>> I was going through the files in the OpenSC repository and noticed
>> several files with missing/unknown licenses.
>>
>> These files miss any open source license headers (adding Olaf Kirch
>> if
>> the email is still valid who is author):
>>
>> src/pkcs15init/pkcs15-init.h
>> src/pkcs15init/profile.h
>> src/libopensc/reader-openct.c
>> src/common/libpkcs11.c
>> src/pkcs11/mechanism.c
>> src/pkcs11/openssl.c

Re: [Opensc-devel] License clarification

[Vincent Le T. <vin...@my...>]

Hi,

src/common/compat_report_rangecheckfailure.c => it is me
Do whatever you want with it ;-)

regards,
Vincent

2017-03-06 10:57 GMT+01:00 Jakub Jelen <jj...@re...>:

> Hello,
> I was going through the files in the OpenSC repository and noticed
> several files with missing/unknown licenses.
>
> These files miss any open source license headers (adding Olaf Kirch if
> the email is still valid who is author):
>
> src/pkcs15init/pkcs15-init.h
> src/pkcs15init/profile.h
> src/libopensc/reader-openct.c
> src/common/libpkcs11.c
> src/pkcs11/mechanism.c
> src/pkcs11/openssl.c
>
>
> These files miss also header, but says about the source in pcsc-lite
> (adding Ludovic, who should be able to clarify the license):
>
> src/libopensc/internal-winscard.h
> src/common/compat_strlcpy.h
>
>
> Several more files without contact information:
>
> src/common/compat_report_rangecheckfailure.c
> src/common/compat_getopt_main.c
>
>
> And some more files from Juha Yrjölä (if the mail still works) without
> any open source license header:
>
> src/tests/lottery.c
> src/tests/p15dump.c
> src/tests/pintest.c
> src/tests/print.c
> src/tests/prngtest.c
>
> Can we get the clarification from the original authors, or is there
> somebody in the project who would be able to clarify the licenses and
> update the files to make sure the license is in align with the project?
>
> Thanks,
> --
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>



-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com

[Opensc-devel] License clarification

[Jakub J. <jj...@re...>]

Hello,
I was going through the files in the OpenSC repository and noticed 
several files with missing/unknown licenses.

These files miss any open source license headers (adding Olaf Kirch if 
the email is still valid who is author):

src/pkcs15init/pkcs15-init.h
src/pkcs15init/profile.h
src/libopensc/reader-openct.c
src/common/libpkcs11.c
src/pkcs11/mechanism.c
src/pkcs11/openssl.c


These files miss also header, but says about the source in pcsc-lite 
(adding Ludovic, who should be able to clarify the license):

src/libopensc/internal-winscard.h
src/common/compat_strlcpy.h


Several more files without contact information:

src/common/compat_report_rangecheckfailure.c
src/common/compat_getopt_main.c


And some more files from Juha Yrjölä (if the mail still works) without 
any open source license header:

src/tests/lottery.c
src/tests/p15dump.c
src/tests/pintest.c
src/tests/print.c
src/tests/prngtest.c

Can we get the clarification from the original authors, or is there 
somebody in the project who would be able to clarify the licenses and 
update the files to make sure the license is in align with the project?

Thanks,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

Re: [Opensc-devel] MyEID and PIV

[Douglas E E. <dee...@gm...>]

On 1/4/2017 5:35 AM, Aventra Development wrote:
> Hi,
>
> Your interpretation of the sample command is correct.
>
> I will answer the questions that I can, and will have to check the rest with my colleague who has programmed the PIV emulation, when he returns from holidays.
>
>>> What version of NIST 800-73 is the card code based on?
>
> I think it's 800-73-3 (have to confirm this)
>
>>> All versions of 800-73 define the CHUID object. Do you?
> I have to check with my colleague.
>
>>> 800-73 requires the Signature key  to be "PIN Always" and the card enforces it.
>>> Does your card enforce it?
>
> In MyEID interface this can be optionally set for each key EF separately in CREATE FILE command, with "AC to be cleared after crypto operation" flag. If you set this flag for the key that is mapped as the signature key, the card enforces it also in PIV mode, but I am not sure if the PIV emulation does this automatically.
>
>>> 800-73 also says the Card Management key does not require the PIN. I only see one ACL in your command, how do you handle this?
>
> Will have to check with the developer.
>
>>> When in PIV mode, What is the ATR?  Most approved PIV cards put the AID in the historical bytes making it easy to identify.
> When in PIV mode, the ATR is normally the same as in normal MyEID card and the PIV support can be detected by selecting the PIV AID. It is possible to order MyEID cards with special ATR's but in the cards sold in our web shop it is the "standard" MyEID ATR.
>

That is OK the AID of the default application in the historical bytes is not a PIV requirement.

> We are not even trying to implement the PIV specification fully. The cards should be used with MyEID middleware where possible. The main reason for implementing the PIV emulation is to make it possible to use the card in situations where installing OpenSC or other middleware is not possible: for example thin clients. Our goal is of course to comply with the PIV spec as well as possible for the parts that we implement.
>

A good goal, but may lead to strange situations, where on application is using the card as MyEID, and an other is using it as PIV.
May make it hard to debug or identify conflicts if the AID is changed back and forth by both applications.


> Please send me your postal address and we will send you a couple of cards for testing.

Thanks, will send by separate e-mail.

>
> - Hannu
>
> -----Alkuperäinen viesti-----
> Lähettäjä: Douglas E Engert [mailto:dee...@gm...]
> Lähetetty: torstai 29. joulukuuta 2016 18.32
> Vastaanottaja: OpenSC-devel <Ope...@li...>
> Aihe: [Opensc-devel] MyEID and PIV
>
> This is a follow on question to that raised in
> https://github.com/OpenSC/OpenSC/pull/926
>
> As the MyEID and PIV compatibility are not related to the PR.
>
> If I read your command correctly:
> 00 DA 01 50  14     80  11 1F FF   4B 01   43 04   00 00   00 00   00 00   00 00   00 00   00 00 90 00
>
> 0x14 bytes
> 80 is flag
> 11 1F FF is ACL?
> 4B 01     is  PIV auth key FID
> 43 04     is  PIV auth cert FID
> No other keys or certs are mapped.
> 90 00 is status bytes
>
>
> The OpenSC PIV card driver is based on NIST 800-73-3 which defines more objects then
> 4 keys and 4 certs on the card. It only uses the APDU commands defined in NIST 800-73-3.
> There is no requirement that a PIV card support any other commands.
>
> Having experience with other PIV-want-to-be cards such as the NEO, being PIV compliant is not an easy task. (as the primary OpenSC PIV developer, I had to add code to card-piv.c and pkcs15-piv.c to handle NEO issues.
>
> Can you or will your documentation answer these questions:
>
> All versions of 800-73 define the CHUID object. Do you?
> Windows requires a CHUID (or used to require it). OpenSC uses the FASCN or GUID from the CHUID to derive a card serial number as NIST 800-73 does not define or require a serial number.  (For both Windows and OpenSC the CHUID does not need to be signed.) How would one write a CHUID and how is it mapped?
> Without a CHUID OpenSC uses 00000000 making using multiple cards on the same machine a problem.
>
> What version of NIST 800-73 is the card code based on?
>
> NIST 800-73-3 introduced the History object and retired keys and certs.
> Do you support these?
> How would these be mapped?
>
> 800-73 requires the Signature key  to be "PIN Always" and the card enforces it.
> Does your card enforce it?
> (This is equivalent to  PKCS#15 user_consent or PKCS#11 CKA_ALWAYS_AUTHENTICATE.)
>
> 800-73 also says the Card Management key does not require the PIN. I only see one ACL in your command, how do you handle this?
>
> When in PIV mode, What is the ATR?  Most approved PIV cards put the AID in the historical bytes making it easy to identify.
>
> Is there any other way to determine this is a MyEID running in PIV mode?
> The OpenSC card-piv.c does a SELECT of the PIV AID and then tries to determine if this is a true PIV or a PIV-want-to-be card that needs special handling.
>
> Look at the card-piv.c line 202:
>   /* card_issues - bugs in PIV implementations requires special handling */ and code starting at line 3006 or grep card_issues card-piv.c for other issues I have seen with PIV compatibility issues.
>
> Any way to get one of these card for testing?
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] MyEID and PIV

[Aventra D. <dev...@av...>]

Hi,

Your interpretation of the sample command is correct.

I will answer the questions that I can, and will have to check the rest with my colleague who has programmed the PIV emulation, when he returns from holidays.

>> What version of NIST 800-73 is the card code based on? 

I think it's 800-73-3 (have to confirm this)

>> All versions of 800-73 define the CHUID object. Do you?
I have to check with my colleague.

>> 800-73 requires the Signature key  to be "PIN Always" and the card enforces it. 
>> Does your card enforce it?

In MyEID interface this can be optionally set for each key EF separately in CREATE FILE command, with "AC to be cleared after crypto operation" flag. If you set this flag for the key that is mapped as the signature key, the card enforces it also in PIV mode, but I am not sure if the PIV emulation does this automatically. 

>>800-73 also says the Card Management key does not require the PIN. I only see one ACL in your command, how do you handle this?

Will have to check with the developer.

>>When in PIV mode, What is the ATR?  Most approved PIV cards put the AID in the historical bytes making it easy to identify.
When in PIV mode, the ATR is normally the same as in normal MyEID card and the PIV support can be detected by selecting the PIV AID. It is possible to order MyEID cards with special ATR's but in the cards sold in our web shop it is the "standard" MyEID ATR.

We are not even trying to implement the PIV specification fully. The cards should be used with MyEID middleware where possible. The main reason for implementing the PIV emulation is to make it possible to use the card in situations where installing OpenSC or other middleware is not possible: for example thin clients. Our goal is of course to comply with the PIV spec as well as possible for the parts that we implement. 

Please send me your postal address and we will send you a couple of cards for testing. 

- Hannu

-----Alkuperäinen viesti-----
Lähettäjä: Douglas E Engert [mailto:dee...@gm...] 
Lähetetty: torstai 29. joulukuuta 2016 18.32
Vastaanottaja: OpenSC-devel <Ope...@li...>
Aihe: [Opensc-devel] MyEID and PIV

This is a follow on question to that raised in
https://github.com/OpenSC/OpenSC/pull/926

As the MyEID and PIV compatibility are not related to the PR.

If I read your command correctly:
00 DA 01 50  14     80  11 1F FF   4B 01   43 04   00 00   00 00   00 00   00 00   00 00   00 00 90 00

0x14 bytes
80 is flag
11 1F FF is ACL?
4B 01     is  PIV auth key FID
43 04     is  PIV auth cert FID
No other keys or certs are mapped.
90 00 is status bytes


The OpenSC PIV card driver is based on NIST 800-73-3 which defines more objects then
4 keys and 4 certs on the card. It only uses the APDU commands defined in NIST 800-73-3.
There is no requirement that a PIV card support any other commands.

Having experience with other PIV-want-to-be cards such as the NEO, being PIV compliant is not an easy task. (as the primary OpenSC PIV developer, I had to add code to card-piv.c and pkcs15-piv.c to handle NEO issues.

Can you or will your documentation answer these questions:

All versions of 800-73 define the CHUID object. Do you?
Windows requires a CHUID (or used to require it). OpenSC uses the FASCN or GUID from the CHUID to derive a card serial number as NIST 800-73 does not define or require a serial number.  (For both Windows and OpenSC the CHUID does not need to be signed.) How would one write a CHUID and how is it mapped?
Without a CHUID OpenSC uses 00000000 making using multiple cards on the same machine a problem.

What version of NIST 800-73 is the card code based on?

NIST 800-73-3 introduced the History object and retired keys and certs.
Do you support these?
How would these be mapped?

800-73 requires the Signature key  to be "PIN Always" and the card enforces it.
Does your card enforce it?
(This is equivalent to  PKCS#15 user_consent or PKCS#11 CKA_ALWAYS_AUTHENTICATE.)

800-73 also says the Card Management key does not require the PIN. I only see one ACL in your command, how do you handle this?

When in PIV mode, What is the ATR?  Most approved PIV cards put the AID in the historical bytes making it easy to identify.

Is there any other way to determine this is a MyEID running in PIV mode?
The OpenSC card-piv.c does a SELECT of the PIV AID and then tries to determine if this is a true PIV or a PIV-want-to-be card that needs special handling.

Look at the card-piv.c line 202:
  /* card_issues - bugs in PIV implementations requires special handling */ and code starting at line 3006 or grep card_issues card-piv.c for other issues I have seen with PIV compatibility issues.

Any way to get one of these card for testing?

-- 

  Douglas E. Engert  <DEE...@gm...>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
Opensc-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Opensc-devel] https://github.com/OpenSC/OpenSC/issues/854 - release of a fix?

[Graham L. <mi...@sh...>]

Hi all,

Happy new year :)

I have just been bitten on MacOSX by the following fixed bug that causes Firefox to crash when attempting to use it with an uninitialised smartcard.

https://github.com/OpenSC/OpenSC/issues/854

Is there an imminent release that fixes this?

Regards,
Graham
—

Re: [Opensc-devel] HSM driver for REST API

[Frank M. <fra...@gm...>]

I don't know exactly what the benefit of a HSM with REST API is, but
regarding
the integration in OpenSC you have several options:

- Write a PC/SC driver that makes your HSM accessible for OpenSC (and most
  other smartcard applications). You could use this virtual driver
http://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html as
starting point.

- Write new reader driver within OpenSC (which naturally doesn't integrate
with
  other applications). You need to add a new implementation of
`sc_reader_t`,
look into reader-pcsc.c for guidance.

- Write a CT-API shared library, which OpenSC and some other smartcard
  applications can use.

And of course, you could write a completely new implementation of a PKCS#11
library and skip integration with OpenSC. Given your use case, this option
looks
like the most favourable one.

2016-12-25 22:05 GMT+01:00 Sven Anderson <sv...@an...>:

> Hi everyone!
>
> I wanna write a PKCS#11 for a network attached HSM that is accessed via a
> REST API. I would write the "backend" to the HSM with C++/boost/cpprestsdk.
> I'm thinking about which PKCS#11 project would be the best to base that
> work on. OpenSC seems to be purely focused on hardware-attached devices. so
> would it be a reasonable thing to use OpenSC for that? And how would I
> "hook in" such a non-USB attached device?
>
> Thanks in advance,
>
> Sven
>
> [sent from mobile device]
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

[Opensc-devel] MyEID and PIV

[Douglas E E. <dee...@gm...>]

This is a follow on question to that raised in
https://github.com/OpenSC/OpenSC/pull/926

As the MyEID and PIV compatibility are not related to the PR.

If I read your command correctly:
00 DA 01 50  14     80  11 1F FF   4B 01   43 04   00 00   00 00   00 00   00 00   00 00   00 00 90 00

0x14 bytes
80 is flag
11 1F FF is ACL?
4B 01     is  PIV auth key FID
43 04     is  PIV auth cert FID
No other keys or certs are mapped.
90 00 is status bytes


The OpenSC PIV card driver is based on NIST 800-73-3 which defines more objects then
4 keys and 4 certs on the card. It only uses the APDU commands defined in NIST 800-73-3.
There is no requirement that a PIV card support any other commands.

Having experience with other PIV-want-to-be cards such as the NEO, being PIV compliant
is not an easy task. (as the primary OpenSC PIV developer, I had to add code to
card-piv.c and pkcs15-piv.c to handle NEO issues.

Can you or will your documentation answer these questions:

All versions of 800-73 define the CHUID object. Do you?
Windows requires a CHUID (or used to require it). OpenSC uses the FASCN or GUID from
the CHUID to derive a card serial number as NIST 800-73 does not define or require a
serial number.  (For both Windows and OpenSC the CHUID does not need to be signed.)
How would one write a CHUID and how is it mapped?
Without a CHUID OpenSC uses 00000000 making using multiple cards on the same machine
a problem.

What version of NIST 800-73 is the card code based on?

NIST 800-73-3 introduced the History object and retired keys and certs.
Do you support these?
How would these be mapped?

800-73 requires the Signature key  to be "PIN Always" and the card enforces it.
Does your card enforce it?
(This is equivalent to  PKCS#15 user_consent or PKCS#11 CKA_ALWAYS_AUTHENTICATE.)

800-73 also says the Card Management key does not require the PIN. I only see one ACL in your command,
how do you handle this?

When in PIV mode, What is the ATR?  Most approved PIV cards put the AID in the
historical bytes making it easy to identify.

Is there any other way to determine this is a MyEID running in PIV mode?
The OpenSC card-piv.c does a SELECT of the PIV AID and then tries to determine if this
is a true PIV or a PIV-want-to-be card that needs special handling.

Look at the card-piv.c line 202:
  /* card_issues - bugs in PIV implementations requires special handling */
and code starting at line 3006 or grep card_issues card-piv.c
for other issues I have seen with PIV compatibility issues.

Any way to get one of these card for testing?

-- 

  Douglas E. Engert  <DEE...@gm...>

[Opensc-devel] HSM driver for REST API

[Sven A. <sv...@an...>]

Hi everyone!

I wanna write a PKCS#11 for a network attached HSM that is accessed via a REST API. I would write the "backend" to the HSM with C++/boost/cpprestsdk. I'm thinking about which PKCS#11 project would be the best to base that work on. OpenSC seems to be purely focused on hardware-attached devices. so would it be a reasonable thing to use OpenSC for that? And how would I "hook in" such a non-USB attached device?

Thanks in advance,

Sven

[sent from mobile device]

Re: [Opensc-devel] Cannot perform signing when multiple keys are present

[Douglas E E. <dee...@gm...>]

On 12/21/2016 9:14 AM, Michał Trojnara wrote:
> Hi Guys,
>
> What is the rationale for the current default to be so low?  Does it
> conserve a significant amount of memory or any other precious resource?

Not that I know.

 From what I can, in his machine there are some Windows drivers for:
(3) Aladdin IDF Handlers
(1) Microsoft Usbccid Smartcard Reader (WUDF)
(3) Rainbow iKey readers

This could be 7 readers?

If you were using RDC/rdesktop you might have even more.

OpenSC sees all the readers, but the PKCS#11 code has the limit. Could we make it dynamic?
Or at least set the default limit to a few more then the number of readers already found?



>
> Best regards,
> 	Mike
>
> On 12/21/2016 02:46 PM, Douglas E Engert wrote:
>> Your thank you note is more then enough. Glad I could help.
>>
>>
>> On 12/20/2016 3:25 PM, Marcin Okraszewski wrote:
>>> Douglas,
>>> That was it!!! I just uncommented the line "max_virtual_slots = 32;" and it works as charm!!! Everything - signing with openssl, listing tokens & objects by p11tool, the  pkcs11-tool -O -l. Everything
>>> just works! Christmas is coming!
>>>
>>> I would have never found it myself. I really don't know how to thank you! Any wish? Of course, beer when you come to Gdansk/Poland is on me.
>>>
>>> Thank you!
>>> Marcin Okraszewski
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> .
>

-- 

  Douglas E. Engert  <DEE...@gm...>

Re: [Opensc-devel] Cannot perform signing when multiple keys are present

[Martin P. <ma...@ma...>]

Most of endusers have one, two, maybe three devices.

If you populate all slots (as was once the case with static PKCS#11 
layout IIRC) it gets messy for some applications.

Martin


On 21/12/2016 17:14, Michał Trojnara wrote:
> Hi Guys,
>
> What is the rationale for the current default to be so low?  Does it
> conserve a significant amount of memory or any other precious resource?
>
> Best regards,
> 	Mike
>
> On 12/21/2016 02:46 PM, Douglas E Engert wrote:
>> Your thank you note is more then enough. Glad I could help.
>>
>>
>> On 12/20/2016 3:25 PM, Marcin Okraszewski wrote:
>>> Douglas,
>>> That was it!!! I just uncommented the line "max_virtual_slots = 32;" and it works as charm!!! Everything - signing with openssl, listing tokens & objects by p11tool, the  pkcs11-tool -O -l. Everything
>>> just works! Christmas is coming!
>>>
>>> I would have never found it myself. I really don't know how to thank you! Any wish? Of course, beer when you come to Gdansk/Poland is on me.
>>>
>>> Thank you!
>>> Marcin Okraszewski
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Cannot perform signing when multiple keys are present

[Michał T. <Mic...@st...>]

Hi Guys,

What is the rationale for the current default to be so low?  Does it
conserve a significant amount of memory or any other precious resource?

Best regards,
	Mike

On 12/21/2016 02:46 PM, Douglas E Engert wrote:
> Your thank you note is more then enough. Glad I could help.
> 
> 
> On 12/20/2016 3:25 PM, Marcin Okraszewski wrote:
>> Douglas,
>> That was it!!! I just uncommented the line "max_virtual_slots = 32;" and it works as charm!!! Everything - signing with openssl, listing tokens & objects by p11tool, the  pkcs11-tool -O -l. Everything
>> just works! Christmas is coming!
>>
>> I would have never found it myself. I really don't know how to thank you! Any wish? Of course, beer when you come to Gdansk/Poland is on me.
>>
>> Thank you!
>> Marcin Okraszewski