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 OBJECT IDENTIFIER,
but in these two cases, it contains an OCTET 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: OBJECT 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: OCTET 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: OBJECT 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: OCTET 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: OBJECT 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: OBJECT 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: OBJECT 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.
> : }
> : }
--
Nelson B
_______________________________________________
mozilla-crypto mailing list
mozilla-crypto@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-crypto
