uday wrote:
Dear all,
I am trying to verify a PKCS#7 signature using NSS API. The API is
failing to verify the signature. The error message I got is "security
library: improperly formatted DER-encoded message". Looks like NSS ASN1
parser is unable to parse the signature. But, I am able to parse the
same signature using openssl.
Simple recursive descent parsers that don't do much error checking will
appear to parse this signature. NSS's derdump tool will also parse it.
But NSS's primary ASN.1 decoder (used in NSS's CMS decoder) do detailed
error checking, checking the data for conformance to the specifications.
I am attaching the signature file(signature.sig) and the CA certificates
with this mail. Can someone tell me if there is any problem with the
signature's format?
I looked at the signature file with Peter Gutmann's dumpasn1 tool and
quickly found at least 3 problems:
1. Incorrect PKCS#9 contentType attribute (in two places)
The SET following a PKCS#9 content type must contain an BJECT IDENTIFIER,
but in these two cases, it contains an CTET STRING. That's incorrect
encoding, and NSS detects it.
<30 12 06 09 2A 86 48 86 F7 0D 01 09 03 31 05 04 03 6D 79 31>
1563 18: SEQUENCE {
<06 09 2A 86 48 86 F7 0D 01 09 03>
1565 9: BJECT IDENTIFIER
: contentType (1 2 840 113549 1 9 3)
: (PKCS #9)
<31 05 04 03 6D 79 31>
1576 5: SET {
<04 03 6D 79 31>
1578 3: CTET STRING 'my1'
: }
: }
and
<30 12 06 09 2A 86 48 86 F7 0D 01 09 03 31 05 04 03 6D 79 31>
6358 18: SEQUENCE {
<06 09 2A 86 48 86 F7 0D 01 09 03>
6360 9: BJECT IDENTIFIER
: contentType (1 2 840 113549 1 9 3)
: (PKCS #9)
<31 05 04 03 6D 79 31>
6371 5: SET {
<04 03 6D 79 31>
6373 3: CTET STRING 'my1'
: }
: }
2. Improper encoding of BMPStrings. BMPStrings are always BER and DER
encoded in Big-Endian format (most significant byte first), not in
little-endian format (least significant byte first, native to x86 CPUs).
But in your signature file, two BMPStrings have been encoded in little-
endian format.
<30 22 06 0A 2B 06 01 04 01 A2 60 00 03 04 31 14 1E 12 6E 00 65 00 77 00>
6378 34: SEQUENCE {
<06 0A 2B 06 01 04 01 A2 60 00 03 04>
6380 10: BJECT IDENTIFIER '1 3 6 1 4 1 4448 0 3 4'
<31 14 1E 12 6E 00 65 00 77 00 20 00 64 00 65 00 6C 00 68 00 69 00>
6392 20: SET {
<1E 12 6E 00 65 00 77 00 20 00 64 00 65 00 6C 00 68 00 69 00>
6394 18: BMPString 'new delhi0'
Error: Inconsistent object length, 1 byte difference.
: }
and
<30 30 06 0A 2B 06 01 04 01 A2 60 00 03 00 31 22 1E 20 32 00 6E 00 64 00>
6491 48: SEQUENCE {
<06 0A 2B 06 01 04 01 A2 60 00 03 00>
6493 10: BJECT IDENTIFIER '1 3 6 1 4 1 4448 0 3 0'
<31 22 1E 20 32 00 6E 00 64 00 20 00 73 00 69 00 67 00 6E 00 20 00 54 00>
6505 34: SET {
<1E 20 32 00 6E 00 64 00 20 00 73 00 69 00 67 00 6E 00 20 00 54 00 43 00>
6507 32: BMPString '2nd sign TCS p120'
Error: Inconsistent object length, 1 byte difference.
: }
3. GeneralizedTime encoded incorrectly:
The .000 fractional time is improper encoding of a GeneralizedTime.
X.690 says "11.7.3 The fractional-seconds elements, if present, shall omit
all trailing zeros; if the elements correspond to 0, they shall be wholly
omitted, and the decimal point element also shall be omitted."
<30 26 06 09 2A 86 48 86 F7 0D 01 09 05 31 19 18 17 32 30 30 35 31 30 31>
1620 38: SEQUENCE {
<06 09 2A 86 48 86 F7 0D 01 09 05>
1622 9: BJECT IDENTIFIER
: signingTime (1 2 840 113549 1 9 5)
: (PKCS #9)
<31 19 18 17 32 30 30 35 31 30 31 30 31 35 34 35 30 37 2E 30 30 30 2B 30>
1633 25: SET {
<18 17 32 30 30 35 31 30 31 30 31 35 34 35 30 37 2E 30 30 30 2B 30 35 33>
1635 23: GeneralizedTime '20051010154507.000+0530'
: Error: Time is encoded incorrectly.
: }
: }