Il 29/04/2011 12:23, Toni Sjoblom - Aventra ha scritto:
>>> Agree, but not every card always returns all necessary information.
>>> The missing part can be looked for in the card profiles.
>> Uhm... Doesn't standards mandate that, for example, 3F00 must always be
>> readable, 4402 contains auth info, etc?
> Yes, see the PKCS#15 specification from RSA.
That's why I didn't expect Viktor's answer.
> AFAIU the profile is used only when creating new objects. Once the object
> (DF or EF) has been created the ACLs are read from the card. Everything
> describing the structure is on the card (or at least is should be, if it's
> not there's an error). This is what the PKCS#15 standard is for, it
> describes the structure and content of the card.
So I understood it correctly. But it seems Viktor is right, and profile
gets in the way even when just using the card. But changing that is
beyond my current competence on opensc :(
> PKCS#15 emulated cards are
> then another question, these are handled separately in OpenSC by emulators.
IMHO emulators should have their own "internal" (as "not end-user
tamperable") profiles, since they have to adhere (and emulate) a
standard, plus an "end-user editable" profile just like PKCS#15 cards.
> I thought you wanted to generate a key on the card and the use it without a
> PIN, so requiring PIN to create the key is no problem.
> Have I understood you correctly?
Yes. It's just that I moved a bit farther than that. If I can make
profile parser to support "user defined vars" (like its macros, but more
versatile and useable from the command line), then I can simply change
profile to have
acl = CRYPTO=$usepin, CREATE=$createpin, READ=NEVER, UPDATE=$updpin,
DELETE=$deletepin
and have a "vars" block where I define default values for these
variables to keep current behaviour:
option default {
macros { [...] };
vars {
usepin=$PIN;
createpin=$PIN;
updpin=$PIN;
deletepin=$SOPIN;
}
}
Then if I issue
$ pkcs15-init -G rsa/2048 -d usepin=NONE --insecure -l "Insecure key"
I get what I want: a key that doesn't require a PIN to be used (still
sub-optimal, since I have to use --insecure just to avoid an error...
but disabling -a and --insecure might be problematic for other
side-effects).
Too bad macros don't work this way (I'd have to define a macro for
CRYPTO=NONE, not just for NONE). Doable, but less intuitive for who
should need to change profile.
The second step will be to support "extended syntax" vars, simplifying
even more profile syntax: instead of a block of vars, I can simply have
acl = CRYPTO=$usepin:$PIN ...
meaning "if usepin is not defined, use $PIN as default".
ATM I'm trying to implement vars without a block but with basic syntax.
Extended syntax should go in a separate (quite trivial) patch.
>>>>> Actually, when using pkcs15-init, one needs to choose the '--auth-id'
>> corresponding exactly to the ACLs settings in the profile .
>> Forgot to ask: then why allow the user to specify it?
> This is where the profile settings should be overridden, i.e. if the user
> specifies "-G .. -a 2" the key should be generated using a pin with
> reference 2.
> Other ACL information is read from profile, and if the user does not specify
> any auth-id, the one specified in the profile is used.
> It is this feature that is currently missing from the MyEID driver, now it
> only reads the profile and ignores the command line parameter "-a X".
> I think other card drivers must have this feature, and it should be added to
> MyEID as well.
Should find one that have it to see how it's implemented... But if I can
make the "more general" syntax work, it becomes more or less useless.
BTW, I still couldn't understand *what* -a should override, since it
seems (from Viktor's comments) $PIN is not the right candidate.
PS: Is it correct to specify "CREATE" as an object's acl? IMHO it should
belong to container object... Or there's a different handling based on
the contained object type (I can create a binary data file w/o
restrictions, to create a keypair I have to authenticate with CHV1, to
create a DF I have to authenticate with CHV2, etc)?
BYtE,
Diego.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
