ASN.1 parser doesn't support type in multiple octects

[myroch]

According to ASN.1 BER specification, type can be contained in multiple octets (typically used in CHOICE type): see https://en.wikipedia.org/wiki/X.690#Identifier_tags_greater_than_30

affects at least ASN1StreamReader and ASN1Element

[dirmgr]

It is correct that the LDAP SDK does not support multi-byte BER types. However, I am not aware of any case in which LDAP communication makes use of multi-byte types. The LDAP SDK's ASN.1 support is primarily intended for use in conjunction with LDAP and does not attempt to provide general-purpose ASN.1 support. Is there an LDAP-specific use case that requires multi-bye type support?

[myroch]

yes, that's true, I wanted to use your sdk for pure ASN.1 parsing. But LDAP RFC clearly specifies ASN.1 BER limitations in LDAP protocol - one byte types are not there :-)

[vdailly]

For sure this is rarely found :) But it can be found in the Microsoft LDAP world :) Especially on the LDAP_SERVER_GET_STATS_OID in the response to the control described, provided the server is at least 2008 or later and a specific flag is set in the request control.

The BER encoding of the following ASN.1 structure: StatsResponseValueV4 ::= SEQUENCE OF SEQUENCE { statisticName OCTET STRING CHOICE { intStatistic [0] INTEGER stringStatistic [1] OCTET STRING } }

For sure this is not a control used a lot. And even the .NET API does not provide any method to correctly decode this sequence. At least in the System.DirectoryServices.Protocols namespace.

[dirmgr]

There's nothing in the example that you've provided that would require a multi-byte BER type.

First, the simple elements: The outer SEQUENCE and each inner SEQUENCE will have a type of 0x30. The statisticName OCTET STRING will have a type of 0x04.

The CHOICE component is only slightly more complicated. The value can either be an integer or an octet string, and which one is actually used is indicated by the BER type of the element. In this case, the definition provides the tag number to use, and it's provided alone surrounded by square brackets, which means that it uses the context-specific class. Both of the options (INTEGER and OCTET STRING) are primitives, so this encoding is also pretty straightforward: you'd use 0x80 to denote an intStatistic and 0x81 to denote a stringStatistic.

The issue with a multi-byte type would only arise if you need to use a tag number that is greater than or equal to 31. The LDAP SDK doesn't currently support that, but I've never encountered a case in which it has been needed.