Re: What ASN.1 got right

[Nico Williams <[e-mail]>]

On Mon, Mar 01, 2021 at 11:09:31PM -0500, Keith Moore wrote:
> (wondering what brought up this subject... did someone decide that this is
> the week to rant about every past poor protocol design choice that we have
> to deal with?)

I had to deal with ugly things the TCG did, like creating non-string
directory attributes.  So I implemented automatic open type handling for
an ASN.1 compiler.  And now I can get beautiful JSON dumps of arbitrary
ASN.1 things.  And it wasn't very hard, and I wanted to thank Paul
Hoffman and Jim Schaad for RFC 5912.  And it made me think ASN.1 isn't
the awful think people make it out to be (but BER/DER/CER are).

> On 3/1/21 8:34 PM, Larry Masinter wrote:
> 
> > Rich formalisms and separation of syntax and "encoding rules" seem
> > counter-productive.
> <soapbox>
> 
> There's something I used to call "ASN.1 disease", but it applies equally to
> XDR, some uses of XML, and a lot of other systems used to define data
> structures used in communications.

Yes, well, and JSON too.  I got into jq precisely because I needed to
deal with overwrought structures in JSON.

And look, that TCG stuff I mentioned above?  Similar disease.  Yes, that
one involves ASN.1.

> The basic problem is that if you give people the ability to generate and
> require arbitrarily complex type-checked data structures, protocol designers
> will use that ability to create overly complex structures.   [...]

They have that ability regardless.

> And because it's difficult to extend such protocols when needed, there's
> pressure to get things "right" the first time, which is often interpreted as
> "let's make sure specify every feature that could possibly be needed".

Typically we try to bake in extensibility only.

> A related problem is setting up a tight binding between say an ASN.1
> structure and a C struct which imposes even more rigidity and subtle bugs.

Examples?  I don't think that's the case with any of the ASN.1-using
protocols I've ever had to implement any part of or which I'm familiar
with (e.g., PKIX, Kerberos, LDAP).  None of them are laid out with C in
mind, though all have C implementations, and all vary a fair bit in the
internal struct layouts.

I would think if you want nice alignment with C you'd want XDR, only
maybe an 8-octet alignment version nowadays.

> (Encodings are separate issues but I have yet to see an encoding of ASN.1
> that is really efficient to either encode or decode. Not saying it cannot be
> done, but there's sort of an expectation that marshaling has to be done one
> datum at a time, in the sequence that they appear on the wire, and that
> slows things down by itself. )

I've not implemented OER, but I suspect that OER is efficient in
run-time, and certainly in space needed.

> Nico WIlliams wrote:
> 
> > I've never heard a bad thing uttered about XDR.
>
> Besides being too rigid in the same way that ASN.1 is (for many
> applications), XDR is also grossly inefficient (in time more than space,
> though there's some space inefficiency) in both encoding and decoding,
> requiring extra memory copies and mallocs/frees to convert between
> on-the-wire and internal representations, and this slows things down
> tremendously.

Nah, that's just rpcgen -- one particular implementation.  Many JSON
implementations do that too.  You _can_ implement more flatbuffers-like
strategies for XDR.

Nico
--