According to the BER encoding standard section 8.3.2, the zero padding of integer value is not allowed. Standard link: https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf Snip from the standard below: 8.3 Encoding of an integer value 8.3.1 The encoding of an integer value shall be primitive. The contents octets shall consist of one or more octets. 8.3.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of octets.
Taken from OSS asn1_runtime_error.pdf: D0022E Message format: D0022E: Integer or enumerated value needlessly long Message cause: The decoder was passed an encoding violating one more clause(s) of X.690, which mandates that values of type INTEGER be encoded in the fewest number of bytes possible. Possible solution(s): Ensure that the encoding rules that are in use actually correspond to the way the input data was encoded. You can use the ossGetEncodingRules() and ossSetEncodingRules() functions for this purpose3. To work around such invalid encodings try using the ossSetFlags() or ossSetDecodingFlags() function and specify the OSS_RELAXED flag. This may cause the decoder to silently accept such invalid encodings. Change in ASN.1 codec plugin added flag for relaxed decoding set VM arguments -Dcdgen.rt.relaxed-decoding=true * If set the decoding is relaxed we enabled OSS_RELAXED flag to the decoder. * The OSS_RELAXED flag also can disable the error checks for: * a) INTEGER encodings which contain unnecessary zero octets * b) REAL values with the mantissa or exponent encoded in a longer format than they should be. * c) an encoded object identifier with a zero length.