Martin Paljak wrote:
> Hello,
>
> Somme thoughts.
>
> On Thu, Dec 30, 2010 at 16:40, <[email protected]> wrote:
>
>> Log Message:
>> -----------
>> 'AuthentIC': basic support of Oberthur's 'COSMO.v7/AuthentIC.v3.2' ...
>> Added Paths:
>> -----------
>> trunk/src/libopensc/card-authentic.c
>>
>
> It contains a fair amount of commented out (#if 0) code, better not
> let that creep in.
>
It's a temporary (really temporary) measure.
This part needs more intervention into the common part, and so,
need to be more discussed.
I'll do it in a 'gradual' manner.
>> +struct authentic_ac_access_usage authentic_v3_rsa_map_attributes[7] = {
>> + {SC_AC_OP_PSO_DECRYPT, SC_PKCS15_ACCESS_RULE_MODE_PSO_DECRYPT,
>> + SC_PKCS15_PRKEY_USAGE_DECRYPT |
>> SC_PKCS15_PRKEY_USAGE_UNWRAP},
>>
>
> I think that the blind mapping of UNWRAP to decrypt operations is not correct.
>
> PKCS#15 v1.1 tells:
> """
> The usage field (encrypt, decrypt, sign, signRecover, wrap, unwrap,
> verify, verifyRecover, derive
> and nonRepudiation) signals the intended usage of the key as defined
> in PKCS #11.
> """
> and
> """
> The semantics of the accessFlags field’s sensitive, extractable,
> alwaysSensitive,
> neverExtractable and local identifiers is the same as in PKCS #11.
> """
>
> Wrapping and unwrapping are IMHO orthogonal to "sensitive" and
> "extractable", meaning that sensitive extractable keys can leave the
> security boundary of the module only in encrypted (wrapped) form. But
> OpenSC, as it is now, can not perform to my knowledge on-board
> wrapping (what should be the natural boundary for operations) or
> unwrapping of keys. So IMHO standard "decrypt" (where the outcome of
> the operation is the decrypted plaintext, returned to the host) should
> not deal at all with attributes that talk about unwrapping.
>
OK, thanks, I'll revisit it.
> Other than that,
> where can these cards be bought? :)
>
Probably you can try the local Oberthur's contacts:
http://www.oberthur.com/content/233/europe
> Best wishes,
> Martin
>
Kind wishes,
Viktor.
> _______________________________________________
> opensc-devel mailing list
> [email protected]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
Viktor Tarasov <[email protected]>
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
