Re: [saag] ASN.1 vs. DER Encoding

[Nico Williams <[e-mail]>]

On Mon, Apr 22, 2019 at 04:47:24PM -0400, Phillip Hallam-Baker wrote:
> 3) Having six encoding rules is a defect, not a strength. The point of
> standards is to remove choices that don't really matter. Having six
> incompatible encodings makes it matter.

Six?  I believe there's more.  Ever heard of GSER?

BER, DER, CER, PER, OER, XER, JER(?), GSER, and who knows what else.

You could easily make encoding rules for ASN.1 out of XDR, NDR, CBOR,
and many others.

It's not a defect of the spec.  It's a defect of history.

In 1984 the ITU-T crowd loved themselfs some TLV encodings.

The IETF crowd did not.  Thus PER.  But PER never took off because the
specs weren't free at the time, and there was no tooling.  TLVs at least
looked easy.

Meanwhile the IETF loved itself some text-based protocols -- lots of
them.  And while neither XML nor JSON came from the IETF, they found a
home here.

It turns out there's a great deal of demand for both, a) "textual", and
b) binary encodings.  And for (b), TLV kinda sucks, but it's what we've
done for 30 years in many cases.  We also have "bits on the wire"
encodings.

That's why we have all the ASN.1 encoding rules, XDR, NDR, XML,
FastInfoSet, JSON, a whole bunch of "binary JSON" formats (including
ones not brought to the IETF, such as PostgreSQL's JSONB, which is
actually quite neat), and now all the *buffers rules (protocolbuffers,
flatbuffers), and who knows what else I might be missing.  Oh, and
things like MIME, which in fact are encoding rules.  And SSHv2, and TLS,
and...  And S-expressions, and Perl5 data dumper, and...

Easy, safe prediction: we'll have more encoding rules soon.

> 4) The DER encoding rules are botched. They require use of nested length
> delimited fields for a start which is inherently insecure unless the
> receiver checks every inner structure to make sure that it is correctly
> nested inside the outer.

Yes.  The decisions made in both DER and CER make both of them difficult
to use in actuality.  The ITU-T could have made better choices for a
canonical flavor of BER :(

> 5) The botched DER encoding is even worse because the nested lengths is the
> use of nested variable length length specifiers. This means that the only
> efficient strategy for encoding ASN.1 is to fill the buffer in the REVERSE
> order starting with the last item.

It's worse: you have to realloc as you go, or build a rope, or do one
pass to compute length and one to encode.  DER is truly awful.

> 7) To add insult to injury, the canonicalization that DER encoding purports
> to provide is of absolutely no value. If I am checking the signature of
> octet sequence X, absolutely harm should come from the possibility that
> there exist an octet sequence Y that has identical semantics which could
> have been signed instead. Yes, I can construct ludicrous scenarios in which
> that would be true but any system that relied on canonicalization is broken.

Agreed.  And yet even now we find people who want a canonical JSON :( :(

> 8) PKIX requires DER but does not provide a canonical form for a
> certificate. You cannot strip an X.509 certificate to its elements, put
> those elements into an X.500 directory and then reassemble the cert even if
> you want to because the extensions are specified as a list, not a set.
> Given that 1TB of SSD currently costs $125 and certificates are a few KB at
> most, this would be a very silly thing to want to try in any case even if
> there were any people still operating X.500 directories.

One thing we've learned is that we *don't* want directories or white
pages of any kind, not outside the corporate environment.

And x.400/x.500 naming is an awful disaster.

Another thing is that the specific form a certificate takes is not
terribly interesting, but the names and issuer are.  And even the issuer
wouldn't be that interesting in a properly hierarchical PKI, but we
never got one (except for DNSSEC).

Nico
--