Le 28/04/2011 15:37, NdK a écrit : > Il 28/04/2011 14:24, Viktor TARASOV ha scritto: > >>> Why is it fixed? >> Let's say 'translated'. >> 'PIN', 'SOPIN' in human language are translated to CHV## in APDU language . > Well, I understand that it must be translated to what APDUs need. But > why "fix" it in the profile, since we already have CHVn notation? > >>>> If your card contains the User PIN authentication object >>>> with the reference 1, the $PIN is translated to CHV1. >>> And how should I say, in profile, "use the authentication object specified >>> by --auth" ? >> Use for what? > As $PIN :) > So, if I have CHV1 (ID 01) and CHV2 (ID 02) and an ACL saying > CRYPTO=$PIN, if I use -a 01 it will be translated to CRYPTO=CHV1 and if > I use -a 02 it becomes CRYPTO=CHV2.
Ok, it's going about PIN to protect the 'usage'. > Maybe I could try to write a patch to support $AUTH (or something more > generic, see below) for this purpose? Yes you can. You have a reason, probably we'll need to introduce a new auth method. The one that could be overwritten with '--auth-id' and used to define access for the operations with objects/object-data-files. I don't think that it can be more general. It has to be used only for the operations for which the access could be described in PKCS#15 xxDFs -- with authId, accessControlRules, ... We cannot replace $PIN macro with the one that can be modified by '--auth-id'. $PIN macro can be used to protect, for ex. the xxDF files itself, and pkcs15init can (in theory) address the card profile to find out the access condition for DFs or xxDF files. It will expect the $PIN value that has been used at the creation(initialization) time. Needs more reflexion. > $PIN is ambiguous... $PIN should be read as $USERPIN >> Language of pkcs15init tool's arguments is a poor language. It's difficult >> to specify all parameters for a new object: >> import with SOPIN, delete with PIN, PSO_DST with SignPIN, ... >> The details come from the card profiles. > That can be good, but even a source of ambiguity. At least it can be > useful for allowing override in a controlled (but not too strict) way. > >> Probably the '--auth' argument should overwrite the object's 'usage' ACLs >> from the profile . That would be reasonable and will answer your expectation. >> We will lost the fine granularity (PSO_DST with PIN, PSO_Auth none, ...) -- >> but I don't think we really need it . > No. I wouldn't do that. > IMHO there should be some way to override (part of) profile from command > line. Maybe simply defining more variables (like the proposed $AUTH) > that gets translated in a controlled way. > Even better, something like > CRYPTO=$AUTH:$SOPIN:NONE > meaning "for CRYPTO, use command line -a parameter, if not specified, > use $SOPIN, if even it is not defined, use NONE" (doesn't make too > sense, but it's only an example). It can be extended to support > arbitrary lists. As soon an object is defined, parsing stops and > translation happens. Yes, something like this. I went a little bit too far -- '--auth' argument should not overwrite any type of authentication mechanism, but only a new $AUTH . >> Now it's a certitude -- '-a' has to overwrite the object's usage ACLs from >> the profile. > Maybe it only needs better docs (even only a slightly different help > text). So the users don't expect the wrong behaviour. Actually, when using pkcs15-init, one needs to choose the '--auth-id' corresponding exactly to the ACLs settings in the profile . Otherwise the PKCS#15 description will not correspond to the real ACLs . It's not quite friendly . > BYtE, > Diego. Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
