On 12/14/2010 5:29 AM, Martin Paljak wrote:
>
> On Dec 14, 2010, at 1:21 PM, Andre Zepezauer wrote:
>
>> On Tue, 2010-12-14 at 13:07 +0200, Martin Paljak wrote:
>>>
>>> Right now I guess that the stripping of input data, coming from an
>>> application (meaning that the calling application will expect the data to
>>> be exactly the same when verifying the signature) is wrong in pkcs15-sec.c
>>> [1].
>>> As there are no other fields that would control the absence (or addition in
>>> the card) of DigestInfo prefix, it does not make any sense to me. Thoughts
>>> anyone?
>>
If I am not mistaken, the prefix is not part of the hash, and should not be
signed.
So the question is why is the prefix being passed in here at all?
Is this code really used with any current cards?
Is this some issue with using OpenSSL for hashing, and the prefix was left on?
>> It really does make sense for cards, that will reattach the prefix
>> internally ;)
>
> Do you know such cards (other than D-trust CardOS cards)? How to signal such
> behavior to the card and inside libopensc?
Two cards, card-cardos.c and card-incrypto34.c also call the
sc_pkcs1_strip_digest_info_prefix. so may take care of this internally.
>
>
In the note from Stef [2] it says:
- While I think ISO's RSA SHA1 PKCS#1 means
ASN1-ENCODE + PKCS1-PAD + RSA
That does not make sense, as there is no hash being done, so why
would it have _SHA1_ in the name?
The nore is from 2002, so may have been fixed or addressed in some other way.
[2]
http://www.opensc-project.org/pipermail/opensc-devel/2002-December/000340.html
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
