can be loaded at ADMINISTRATION life cycle phase to change
the behavior of the VERIFY command in regard to return codes.
When that package is loaded, the PIN can be created with this
"verifyRC" flag in cardos.profile if the return code must be
ISO7816-4 compliant (63Cx with x being the value of the remaining
retry counter when required verification has failed).
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5558 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
at the profile level the difference between EF and BSO is:
- BSO path is always the path of the host DF and do not indexated when template is instanciated;
- EF path is always ending with file-id that is always indexated when template is instanciated.
New non-static 'sc_profile_get_file_instance' procedure to instanciate non-template entries.
In profile.c get_uint() accepts hexadecimals.
In CardOS profile (I venture to) increase the xDF sizes
and change ACL to permit the key re-importing.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3919 c6295689-39f2-0310-b995-f0e70906c6a9
ACL settings, and check C_CreateObject parameter CKA_PRIVATE aka
pkcs15_create_data args.auth_id variable, aka sc_pkcs15init_new_object
object->flags & SC_PKCS15_CO_FLAG_PRIVATE to decide if "data" or "privdata"
profile needs to be used.
Tested with cryptoflex 32k and opensc-explorer, now I no longer can
"get" the data object file stored with "--private".
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3605 c6295689-39f2-0310-b995-f0e70906c6a9