Re: What ASN.1 got right

[Phillip Hallam-Baker <[e-mail]>]

I agree ASN.1 got a lot of things right. And the problem is that if you are
baking a cake, its no longer a cake if there are too many rat droppings in
it.

I have written multiple serializers and deserializers for each of the
commonly used serialization formats, I have used a dozen schema languages
and written another dozen. I created another serialization scheme only last
week as it happens, needed something that works at the packet level that
worked really well with my crypto.

The problem I see with ASN.1 and XML is that the schema languages are
object description languages and thats a different thing from a
serialization format. I have stopped talking about 'objects' on the wire
and now refer to 'records' because I am not doing object broking, this is
message exchange on the wire but they are not events either as I use the
same format for stored data.

So the mistake I see in XML schema and also in most JSON schema proposals
is that they try to capture the full expressive power of the lexical syntax
and I am only interested in exchanging records and mapping them onto my
application data structures. I do not want to have the schema saying 'x is
an integer between 2 and 6'. I want 'x is an integer' and the only time I
want to have more information is if x won't fit into 64 bits. Similarly, I
don't want the schema to say '2 to 6 objects of type foo', the minimum
number of entries in a list is always either 0 or 1 and the maximum is
always 1 or infinity. Nothing else is needed at the schema layer. If you
have detailed data constraints you can always apply them later.



On Mon, Mar 1, 2021 at 8:08 PM Nico Williams <[e-mail]> wrote:

> As an ASN.1 implementor, I can tell you things I, like many of you, hate
> about ASN.1:
>
>  - ugly syntax (made uglier by having tags as optional lexical elements)
>
>  - ugly OIDs (should have been URNs or URN-like)
>
>  - BER/DER/CER and all TLV encodings in the world (protocol buffers, I'm
>    looking at you too) are awful
>
>  - the fact that the specs were, for a long time, non-free, which led to
>    a dearth of open source tooling that still persists somewhat (though
>    not as bad as it used to be)
>
>  - the fact that for years people hand-rolled their codecs due to the
>    previous item, and so created many bugs
>
>  - X.400/X.500, which are not part of ASN.1, of course, but closely
>    related -- especially X.500 style naming!
>
> Having recently implemented automatic open type decoding handling X.681/
> X.682/X.683 (see RFCs 6025 for some insight, and 5912 for real examples
> that I'm making use of), I can tell you that ASN.1 got some things
> right:
>
>  - rich formalisms ("constraints")
>
>  - separation of syntax and encoding rules
>
> The fact that there are many encoding rules for ASN.1, of almost every
> kind (binary TLV, binaray non-TLV, and textual, including XML- and
> JSON-based rules) proves the last point.  I can't help but see how XDR,
> NDR, and flatbuffers, among many other encodings out there, could easily
> be used with ASN.1.  (E.g., what XDR and NDR call "pointers" are just
> optional fields in ASN.1.)
>
> The fact that one can implement automatic open type decoding using ASN.1
> formalisms and those already published in, e.g., RFC 5912[*] proves the
> utility of those formalisms.  I now get to see certificates and many
> other things in all their "glorious" detail as JSON, including all
> extensions and what not, and that's made possible by these formalisms.
>
> I beg the next person to re-invent this darned wheel to please educate
> themselves as to what came before.  Among many lessons you should learn,
> learn that some things can't be monetized well enough, or at all, or can
> only be monetized in exchange for limiting their adoption, so figure out
> what your goals are, then align pricing and licensing with those.
>
> And since open types appear to be unavoidable, but also always a pain if
> you don't have the metaschema to express the metadata needed to automate
> their handling, don't forget to cover that.
>
> XML, of course, with namespaces and references, has a reasonable
> approach to open types as well.  It's not just ASN.1 that gets that
> right well enough.
>
> Nico
>
> [*] A big thank you to RFC 5912's authors, though sadly one of them has
>     passed.
>
>