3 ms·

I agree entirely, and this is one of my single greatest frustrations with the majority of the current popular IDLs/schema languages. ASN.1 is hilariously bad i

I agree entirely, and this is one of my single greatest frustrations with the majority of the current popular IDLs/schema languages. ASN.1 is hilariously bad in a lot of ways, but one thing it gets absolutely right is strong typing and being able to express constraints (ranges, values dependent on other values). That combined with a canonicalized encoding form (DER) goes a long way in making various error states unrepresentable.

debugnik 3y ago
Is there a reasonable subset of ASN.1 that could get traction nowadays if specified separately?
- woodruffw 3y ago
  There’s a wide set of best practices (use only DER for encoding, avoid legacy string types, etc.) that are widely applied in cryptographic applications, although I don’t know if anybody has written them down explicitly. More generally: this wasn’t intended to be an endorsement of ASN.1 per se! It was only to say that it got some things right, things that Cap’n Proto and Protobuf appear to have eschewed. I’m not sure it is the right IDL for modern purposes, but I think it’s a useful piece of reference material.
bsder 3y ago
Except that ASN.1 is egregiously terrible at being able to be checked for wonky values due to complex parsing. Exactly how many vulnerabilities have been exploited in LDAP, SNMP, etc. because ASN.1 is so terrible?
- woodruffw 3y ago
  ASN.1 isn’t an encoding; DER is. The problem with LDAP, etc. is that they all permit BER, which is a looser superset of DER. It includes (among other things) the ability to represent indefinite-length fields, which are the single biggest source of exploitable bugs in a typical application of ASN.1. Without that, the exploitable surface of DER is much smaller (and especially when implemented in a memory-safe language).
- jnwatson 3y ago
  I've written an ASN.1 parser. The problem isn't the specification (though it is definitely a kitchen sink spec). The problem is the majority of ASN.1 code was written before the year 2000. ASN.1 started in 1984. That means there are decades of shitty implementations, written well before adversarial input was considered a factor.
nly 3y ago
I had to use it at work in a C++ environment and ended up settling on patching a copy of https://github.com/vlm/asn1c https://github.com/vlm/asn1c Can't say I'd feel confident putting any of this stuff in a public service. Too complex and prone to bugs.

debugnik 3y ago

Is there a reasonable subset of ASN.1 that could get traction nowadays if specified separately?

woodruffw 3y ago
There’s a wide set of best practices (use only DER for encoding, avoid legacy string types, etc.) that are widely applied in cryptographic applications, although I don’t know if anybody has written them down explicitly. More generally: this wasn’t intended to be an endorsement of ASN.1 per se! It was only to say that it got some things right, things that Cap’n Proto and Protobuf appear to have eschewed. I’m not sure it is the right IDL for modern purposes, but I think it’s a useful piece of reference material.

bsder 3y ago

Except that ASN.1 is egregiously terrible at being able to be checked for wonky values due to complex parsing. Exactly how many vulnerabilities have been exploited in LDAP, SNMP, etc. because ASN.1 is so terrible?

woodruffw 3y ago
ASN.1 isn’t an encoding; DER is. The problem with LDAP, etc. is that they all permit BER, which is a looser superset of DER. It includes (among other things) the ability to represent indefinite-length fields, which are the single biggest source of exploitable bugs in a typical application of ASN.1. Without that, the exploitable surface of DER is much smaller (and especially when implemented in a memory-safe language).
jnwatson 3y ago
I've written an ASN.1 parser. The problem isn't the specification (though it is definitely a kitchen sink spec). The problem is the majority of ASN.1 code was written before the year 2000. ASN.1 started in 1984. That means there are decades of shitty implementations, written well before adversarial input was considered a factor.

nly 3y ago

I had to use it at work in a C++ environment and ended up settling on patching a copy of https://github.com/vlm/asn1c https://github.com/vlm/asn1c Can't say I'd feel confident putting any of this stuff in a public service. Too complex and prone to bugs.