[Cryptography] Is ASN.1 still the thing?

[Nico Williams]

On Mon, Nov 27, 2017 at 08:17:49PM +0100, Florian Weimer wrote:
> * Nico Williams:
> 
> >> This is not what puzzled me.  It is how to get from the ASN.1 syntax,
> >> with the [0], the EXPLICIT, the DEFAULT (or the [3] and the IMPLICIT
> >> further down) to the on-the-wire representation, with the
> >> CONTEXT_SPECIFIC wrapper around the actual version field and all that.
> >> 
> >> And I wonder if ASN.1 compilers actually ensure that the serialized
> >> data and be deserialized in an unambiguous fashion, and what the rules
> >> are for *that*.
> >
> > Well, we do interop, so, "yes".  We have a large variety of
> > implementations of PKIX, after all.  Some use ASN.1 compilers, and some
> > use hand-coded codecs.
> 
> You can only do interop testing with real data and a concrete ASN.1
> specification.  I'm more interested in the theory, i.e. how this is
> *supposed* to work at the design level.

Adding a DEFAULTed field anywhere but past an extensibility marker is
*not* supposed to work for any encoding rules other than TLV rules.  And
for TLV rules what's expected to happen is that older peers will produce
an error when the new field is present because they don't expect it.

That is, this technique of retroactively adding a version field in the
front (if that's what happened here) will NOT work with XDR, PER, OER,
and similar.  It can, of course, work for things like XML, and for JSON
when the structure is represented as an object (but not when it is
represented as an array).

> [...]
> 
> My hunch is that the criticism of ASN.1 (as opposed to direct wire
> format specification using ASCII diagrams or whatever) is that how you
> get from ASN.1 syntax, to the internal data model, via some specific
> encoding rules, to the actual bytes, is far from obvious, and the
> specifications do not really help unless you have been taught a
> particular mental framework for reading those specifications.  The XML
> stack (whether XML Schema or RelaxNG doesn't matter) is much clearer
> in this regard, for example, so I'm not sure if this issue of apparent
> disconnect is inherent to the problem domain.

I don't follow this.  ASN.1 and its encoding rules have specifications.
You follow the specs, and it should work.  Or use tools that follow the
specs, and it should work.  It's no different than XDR or any other IDL.

> The fact that fully-featured ASN.1 tools used to be proprietary, with

The spec itself used to be proprietary!

> closely guarded test suites, probably did not help, either, because it
> resulted in a proliferation of concrete, manually written parsers and
> substantial divergence even between automatically generated parsers.

Worse than that, the fact that the specs were proprietary meant that all
non-proprietary tools tended to use samizadata-style specs, riddled with
errors (e.g., the venerable, and broken, Layman's Guide to ASN.1).

Of course, that's long ago now, and now we do have open source tools and
public specs.

Nico
--