ASN1 layer can't parse nested constructive octet strings

[HoneyryderChuck]

BouncyCastle ASN1 API parsers don't seem to be able to parse some complex constructed DERs. Here are two examples (in hexa notation):

• 24 80 04 01 01 04 01 02 00 00
• 24 80 24 80 04 01 01 00 00 24 80 04 01 02 00 00 04 01 03 00 00

Assuming that an ASN1InputStream is initialized with each, readObject() will return, an OctetString, in the first case with the 01 02 value, and in the second case with 01 02 03.

This parsing is wrong. In the first case, the encoded stream represents a "raw constructed" indefinite length (with UNIVERSAL tag 4) containing two octet strings (04 01 01 and 04 01 02). In the second case, it represents a "raw constructed" indefinite length (with UNIVERSAL tag 4) containing 2 "raw constructed" indefinite length (with UNIVERSAL tag 4) objects (each containing an octet string, 04 01 01 and 04 01 02) and an octetstring (04 01 03).

This seems to be an unsupported case, because BouncyCastle does not define the concept of a "raw constructed" object. While this seems to work well for Sequences and Sets, when it comes to OctetStrings (and maybe BitStrings?), internal data seems to be concatenated into a single OctetString object, ignoring relevant bits, I believe, due to the usage of this parser. But even assuming that a correct parser would exist, there is no defined class that could represent that, as the only constructed classes are around must map to ASN1Sequence or ASN1Set, i.e. a tagnumber of 4, which maps to a universal primitive, does not have a corresponding class around.

So this is essentially a feature request to create the concept of such a class, and support it in parsers.

[peterdettman]

The parsing is not wrong. Taking your first example (similar comments apply to the slightly more complicated second example), 24 80 04 01 01 04 01 02 00 00 is an encoding of a single octetstring value. In this case it is a constructed encoding, whose contents octets consist of two further encodings. Still only a single value being encoded (01 02), and it is the parser's job to return ASN.1 values.

As it happens, BEROctetString may store the original encoding structure in order to support re-encoding without changes. However the actual value is still the "concatenation".

Constructed relates only to encodings (particularly X.690 i.e. BER/CER/DER) and is not a property of actual values of ASN.1 types, though of course the X.690 encoding of SETs and SEQUENCEs is always constructed.

[HoneyryderChuck]

As it happens, BEROctetString may store the original encoding structure in order to support re-encoding without changes.

While I haven't verified this yet, how am I able to introspect the object in order to figure out it came from a constructed encoding? And similarly, in the more complicated example, how would I be able to infer the "nested" ber octet strings? More than reencoding, I'd need to infer this info on the fly.

[dghgit]

Just one minor quibble, DER does not allow for indefinite-length/definite-length constructed octet strings in any circumstance, for DER things always need to be definite-length. While it is legal in BER to nest indefinite length octet strings (I just checked...) it's a bit odd!

Curious to know why you would need to know it's constructed? Other than looking for possible side-channels, at the end of the day it's just a string of bytes to an application.

[dghgit]

Inactive. Believe to be a misunderstanding.