Viktor TARASOV wrote: > actually pkcs15init takes into account the possibility of multiple ACLs for > one operation. > Is it really used? > > Multiple ACLs appear as linked list associated to operation, for example, > when loading generic profile 'pkcs15' and then the card specific one. > More attentive examination shows that the common ACLs settings from the 'pkcs15.profile' can be completely overwritten by the card's profile, if the first ACL pair in the card's profile uses the 'wildcard'. For example: ACL = *=NEVER,READ=NONE,UPDATE=$PIN;
> Authentication of an operation in pkcs15init requests to validate all the PINs > from the associated list (if there are no 'NONE' or ''NEVER' in the same > list). > > As for me, the expected behavior in this situation has to be > 'overwrite the generic settings with the card specific one'. > > Multiple ACLs concern only the files instantiated from profile. > In libopensc all(?) card specific FCP encoders use only the first acl from > the list. > It appears that this common mechanism is implemented for the 'gpk' and 'cflex' drivers: the first one can encode two PIN references in one byte of ACL, in the second one it's used for the 'CHV & AUT' protection mode. > So, I propose to abandon multiple ACLs, because it complicates > the creation of a new objects for the OpenSC PKCS#11 module. > For a while, I retrieve my suggestion. Probably in future the 'multiple ACLs' will need re-implementation -- when other then 'and' logical operation with the ACL authentication factors will be asked for. The actual problem with Aventra card can be solved by changing of some ACLs and using of 'wildcard' in its card profile. Kind wishes, Viktor. -- 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
