Re-evaluate OCTET STRING equality

[JesusMcCloud]

Assigning you guys too, so we can discuss this here.

Currently, we have two kinds of octet strings, because octet strings are frequently used to encode structures:

• Asn1PrimitiveOctetString is a primitive, containing unstructured data
• Asn1EncapsulatingOctetString is an ASN.1 structure with SEQUENCE semantics

When parsing ASN.1 bytes, we try to recursively decode octet strings into structures. If this works, we have an encapsulating variant, if this fails, we have have a primitive octet string. Now it is really not that unusual for a small (<20 bytes) octet string containing supposedly unstructured data, to accidentally contain a valid ASN.1 structure. Another was to reliably trigger this, is to SEC1-encode and decode few hundred P521 private keys. At least one of them is bound to contain an encapsulating octet string and some other foo as private key.

This parsing logic is fine and there is no other way to do it. All ASN.1 parsers inherently have to behave like this. The issue is equality. In #202, I added a conversion function Asn1EncapsulatingOctetString.toPrimitive(), which will make an encapsulating octet string into a primitive one.

• Do we need more?
• Should the two kinds of octet strings be considered equal or not?

[JesusMcCloud]

@iaik-jheher this can be closed, right?!

[iaik-jheher]

should be fixed after #202, yeah