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. Maybe I could try to write a patch to support $AUTH (or something more generic, see below) for this purpose? $PIN is ambiguous... > 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. > 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. BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
