Actually, I was not completly mistaken... Only RSA PKCS#1 signs the digestInfo along with the hash. ECDSA only uses the hash value. (I don't know what GOST does.)
This has been verified using NSS-3.12.7 with Thunderbird to create smime signed e-mail. The message can be verified by NSS, OpenSSL smime and Entrust. RFC 2313 [1] PKCS #1: RSA Encryption Version 1.5 in section 10.1.2 describes the DigestInfo, and in Note 1 describes why the algorithm identifier is included. Although I can not not find a statement that says the algorithm identifier is not included with the hash when using ECDSA, many of these documents imply it is not based on how a long hash is truncated if used with a short key. FIPS-186-3 [2] June 2009 defines DSA and EDCSA. RFC 5758 [3] defines sha-2 usage with ECDSA and updated RFC 3279 RFC 3279 [4] defines original EDCSA and hashes. x9.62 (I don't have a copy) [1] http://tools.ietf.org/html/rfc2313 [2] http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf [3] http://tools.ietf.org/html/rfc5758 [4] http://tools.ietf.org/html/rfc3279 On 12/14/2010 1:41 PM, Douglas E. Engert wrote: > Oops, I was mistaken in my previous note, the prefix is sent to be signed. > > > Thunderbird with NSS calling opensc-pkcs11 for RSA 2048 bit key: > > 1322: C_Sign > [in] hSession = 0xf1a2d160 > [in] pData[ulDataLen] f24f9010 / 35 > 30213009 06052B0E 03021A05 0004145C 1362A567 70C3E95E 0B5881B8 5AA257BC > 081B20 > > debug output of the chained sign operation: > > Outgoing APDU data [ 260 bytes] ===================================== > 10 87 07 9C FF 7C 82 01 06 82 00 81 82 01 00 00 .....|.......... > 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ > FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 ............0!0. > 06 05 2B 0E 03 02 1A 05 00 04 14 5C 13 62 A5 67 ..+........\.b.g > 70 C3 E9 5E p..^ > ====================================================================== > Outgoing APDU data [ 17 bytes] ===================================== > 00 87 07 9C 0B 0B 58 81 B8 5A A2 57 BC 08 1B 20 ......X..Z.W... > 00 . > ====================================================================== > > This is verified on another system. > > > On 12/14/2010 10:54 AM, Douglas E. Engert wrote: >> >> >> 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
