the PIV driver no longer need to set the card max_*_size parameters
to get around emulating read_binary and write_binary. It can
now handle partial reads and writes.
The assumptions for write_binary are that the first chuck will
have idx = 0, and the last chunk will write the last byte.
The flags parameter will contain the total length.
The only write_binary operations are done when initializing
a card, and this is only done from piv-tool.c which was modified
to pass in the length and other flags.
Piv-tool continues to be a primative test tool for inializing test
cards. But it has been expanded to be able to write other objects
on test cards.
The serial number of a PIV card is obtained from the CHUID object
if present which has a FASC-N which is an ID number created by the
issuer. Normally PIV cards are issued the U.S. Federal government
But there are ways to use the same cards with a non government CA.
This is then be referred to as PIV Compatible. In this case,
the FASC-N should start with an agency code = 9999 and an RFC 4122
GUID should be present in the CHUID. If this is the case, the GUID
is used as the serial number.
Windows 7 comes with a PIV card card driver, but to get it use one of
these card the CHUID is required. (piv-tool can now write one.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3998 c6295689-39f2-0310-b995-f0e70906c6a9
On OS X, when you insert a card, securityd sequentially starts all found Tokend-s to see if a card can be handled with one.
If a non-tokend application waits for a card insertion with sc_wait_for_event and tries to connect to the card right after the system sees it, it will fail with "The reader is in use by another application" 95% of the time.
With this hack connecting to the card succeeds 95% of the time with the probable penalty of an extra second on initialization for non-tokend clients.
This should only affect applications that wait for card insertion events.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3991 c6295689-39f2-0310-b995-f0e70906c6a9
The implementation was based on the previous MSC build, each tool had its own
description in version resource.
This change sets a single version resource to all files, and produces much
simpler build.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3980 c6295689-39f2-0310-b995-f0e70906c6a9
Migrated without testing, but normally should work -- the pkcs15init part of MyEID and SetCOS are sufficiently close.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3976 c6295689-39f2-0310-b995-f0e70906c6a9
Migrated without testing, but normally should work -- the pkcs15init part of MyEID and SetCOS are sufficiently close.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3975 c6295689-39f2-0310-b995-f0e70906c6a9
When creating application DF ('PKCS15-AppDF'), User PIN is not yet created, and AC type 'SC_AC_SYMBOLIC' cannot be resolved.
So, in the card profile, the macro '$PIN' cannot be used to define the ACLs of the application DF.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3967 c6295689-39f2-0310-b995-f0e70906c6a9
thus we don't need to worry about if the pin/so-pin was passed
for the old structures (before erase) or the new ones (if used
with create).
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3966 c6295689-39f2-0310-b995-f0e70906c6a9
;when putting SOPIN into the global cache, use the path from the object info;
;sc_pkcs15init_create_pin() can be called to create PUK object;
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3964 c6295689-39f2-0310-b995-f0e70906c6a9
flc
aj
s
martin
viktor.tarasov
alonbl