Viktor TARASOV wrote: > Viktor TARASOV wrote: > >> Aktiv Co. Aleksey Samsonov wrote: >> >> >>> Pierre Ossman: >>> >>> >>> >>>> I think we might have a language barrier here as I'm not quite >>>> following what you're trying to say. >>>> >>>> >>>> >>> Sorry for inconvenience caused. >>> >>> >>> >>> >>>> The basic problem is that none of my PKCS#15 cards have an object for >>>> the PUK (and from what I can tell the PKCS#15 standard doesn't require >>>> them to). This means that we cannot do a C_Login with the PUK >>>> beforehand (as we cannot figure out the reference of the PUK for the >>>> VERIFY operation). >>>> >>>> >>>> >>> Then "alternative sheme" isn't correct in this case. But, I fear for >>> call sc_pkcs15_unblock_pin if we have a cached SO PIN (if SO PIN != PUK). >>> >>> >>> >> 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. >> >> > Even better, > for C_SetPIN(): > - in CKU_USER_PIN context -- change PIN; >
> - in CKU_SO_PIN context -- set PIN after SOPIN authentication; > Sorry, it's not good idea -- there should be possibility to change SOPIN. > - in CKU_SPECIFIC context -- 'one_step_unblock_PIN' or unblock PIN after > PUK (when PUK != SOPIN) authentication; > > >> >> >>> _______________________________________________ >>> opensc-devel mailing list >>> opensc-devel@lists.opensc-project.org >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>> >>> >>> >>> >> >> > > > -- 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
