>On Thu, Feb 11, 2016 at 12:47 AM, Stephen Henson via RT <r...@openssl.org> >wrote: >>On Wed Feb 10 21:59:12 2016, bcri...@gmail.com wrote: >>As the error is suggesting it doesn't like the serialNumber in the >>certificate. >> If you check it with asn1parse it says "BAD INTEGER". Using dumpasn1 you >> get: >> >> 13 20: INTEGER 00 59 DF E1 E2 94 81 88 77 C5 3E E2 D3 2F 2B A2 BB 5F EB >>DA >> : Error: Integer '00 59 ...' has non-DER encoding. ^^^^^ Probably correct IN THIS ONE CASE, because Most Significant Bit is zero even without the leading zero byte. See below.
>>The problem is that is an invalid encoding. An ASN.1 INTEGER cannot >>contain >> leading zeroes. I’m pretty sure this is not correct. It’s been a while since I touched ASN.1, but I had quite a bit of experience with it back when. SO first of all, could you please cite your (authoritative) sources stating that an ASN.1 DER_encoded INTEGER cannot have leading zero. Here’s what others <http://stackoverflow.com/questions/5974633/asn-1-der-formatted-private-key > had to say about this: The private key values are encoded as ASN.1 INTEGERs, which are signed values in two's complement format. The leading zero byte is necessary when the MSB of the (unsigned) RSA key value is set. Having the MSB set without a leading zero byte would mean a negative value. The ASN.1 specs are free and are linked from Wikipedia <http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One>. The relevant section here is in X.690, "8.3 Encoding of an integer value”. In short, the problem is that without that leading zero there is no way to tell a negative integer from a positive integer. Here’s how the *current* OSS Nokalva ASN.1 compiler <http://asn1-playground.oss.com/> DER-encodes integers. First, the ASN.1 spec (had to wrap in a sequence to avoid jostling with the compiler, as I don’t remember how to write definitions of single primitive types) World-Schema DEFINITIONS AUTOMATIC TAGS ::= BEGIN Tst ::= SEQUENCE { value INTEGER (-256..257) } END And playing with different integer values in the given range: my-tst Tst ::= { value 127 } Encodes to 3003 02017F (relevant parts: tag 02, len 01, value 7f) However this: my-tst Tst ::= { value 128 } Encodes to 3004 02020080 (integer tag 02, len *02*, and value 00 80) and for a VERY good reason! If you try to decode the following 3003020180 (what you seem to suggest - the number without the leading zero) you get: ASN1STEP: Decoding PDU #1 : Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 3 value INTEGER: tag = [UNIVERSAL 2] primitive; length = 1 -128 Successfully decoded 5 bytes. rec1value Tst ::= { value -128 } Notice that minus. >>OpenSSL 1.0.2 and earlier tolerated this but 1.1.0 is stricter. I say OpenSSL-1.1 got this wrong, and needs to be fixed. P.S. Sticking the value of the integer provided provided by Cristian into OSS ASN.1 DER decoder gave: OSS ASN-1Step Version 7.1 Copyright (C) 2014 OSS Nokalva, Inc. All rights reserved. This product is licensed for use by "OSS Nokalva, Inc." C0043I: 0 error messages, 0 warning messages and 0 informatory messages issued. ASN1STEP: Decoding PDU #1 : Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 22 D0022E: Integer or enumerated value needlessly long; check field 'value' (type: INTEGER) of PDU #1 'Tst'. D0023E: Integer or enumerated value too long: 19; check field 'value' (type: INTEGER) of PDU #1 'Tst'. value INTEGER: tag = [UNIVERSAL 2] primitive; length = 20 2147483647 S0012E: Decoding of PDU #1 failed with the return code '5'. Trimming the leading zero from the value (as for *this* particular integer value that zero is not needed to disambiguate between + and -): OSS ASN-1Step Version 7.1 Copyright (C) 2014 OSS Nokalva, Inc. All rights reserved. This product is licensed for use by "OSS Nokalva, Inc." C0043I: 0 error messages, 0 warning messages and 0 informatory messages issued. ASN1STEP: Decoding PDU #1 : Tst SEQUENCE: tag = [UNIVERSAL 16] constructed; length = 21 D0023E: Integer or enumerated value too long: 19; check field 'value' (type: INTEGER) of PDU #1 'Tst'. value INTEGER: tag = [UNIVERSAL 2] primitive; length = 19 2147483647 S0012E: Decoding of PDU #1 failed with the return code '10'. The following might also be useful (attempting to encode/decode integer value 128). Schema World-Schema DEFINITIONS AUTOMATIC TAGS ::= BEGIN Human ::= INTEGER (0..257) END Data: 020180 Decoding: OSS ASN-1Step Version 7.1 Copyright (C) 2014 OSS Nokalva, Inc. All rights reserved. This product is licensed for use by "OSS Nokalva, Inc." C0043I: 0 error messages, 0 warning messages and 0 informatory messages issued. ASN1STEP: Decoding PDU #1 : D0076S: A negative unsigned integer encountered; check PDU #1 'Human'. S0012E: Decoding of PDU #1 failed with the return code '2'. The error is correct: decoded value by the rules of decoding is negative, but the type restriction said it had to be unsigned, aka non-negative.
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev