Pierre Ossman wrote: > On Thu, 03 Dec 2009 14:57:34 +0100 > Viktor TARASOV <viktor.tara...@opentrust.com> wrote: > > >> Another possible, 'alternative to alternative' scheme is to use C_SetPin() >> in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). >> >> So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, >> in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. >> >> Afais, CKU_CONTEXT_SPECIFIC is not actually used. >> >> > > The problem here is that this is not something that's specified in the > standard, and it's not the system existing implementations use. > > I think that as far as the interface goes, C_Login(CKU_SO) followed by > C_InitPin() is set in stone as we want to be compatible with what's > already out there. >
That's right. Any way, with the existing standard we cannot cover all the variations of the PKCS15 contents and different card specifications. As for me, for the cards (rather 'pkcs15 contents') that do not have SOPIN or the only useful SOPIN function is 'unblock_user_pin' it's acceptable to use PUK as SOPIN and to use 'sc_pkcs15_unblock_pin' in C_InitPIN() . I'm not talking about the other possible situations with SOPIN!=PUK, number of PUKs, ... I guess that some option (use-puk-as-sopin) can be introduced into the 'pkcs11' section of opensc.conf. > Rgds > -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
