Re: [TLS] TLS grammar checker?

["Kemp, David P." <[e-mail]>]

From: Nico Williams

> ASN.1's next biggest sin: its crappy initial encoding rules (BER, DER, and CER).

Beauty is in the eye of the beholder.  The self-describing properties of TLV encodings like BER are often useful, providing a middle ground between highly optimized binary encodings (PER) that cannot be parsed without the data definition and bulky ASCII encodings (JSON) that are readable with a text editor.



>> ASN.1 is squarely part of the problem space, not part of the solution space.

> Anything with tooling is in the solution space.  Today I prefer JSON (see above).

+1.  Anyone up for defining JER?  :-)


>> If you believe you can parse or encode X.509/PKIX just by using an
>> ASN.1 compiler tooling, then you probably have never even looked at 
>> X.509/PKIX.  The devil is in the comments sprinkeled all over the 
>> place where you have to tweak the compiler output in so many ways and 
>> so many places that writing everything by yourself becomes quite a 
>> viable alternative, and one that is free of hidden eastereggs.
>
> These are the results of ASN.1 having been non-free.  The same
> applies to Kerberos.

SNMP seems to have done ASN.1 the right way - adopting a simple subset of needed features and eschewing the esoteric.  I take the same approach with my Sony digital camera - it has zillions of ridiculous picture-taking features including, believe it or not, "food mode".  Yet I manage to get by with just the basic four: P, S, A, and M.

ASN.1's extensive feature set deserves at least as much blame as its non-freeness.  But spec writers (including myself) deserve the bulk of the criticism for not exercising craftsmanship and self-restraint.  Just because the features exist doesn't mean they have to be used.  TLS could be written in SNMP-ASN.1 without requiring compiler tweaking.


> Also: Amiga over Atari.

You're in the right processor family.  6502 >> 8080.