[Cryptography] Is ASN.1 still the thing?

[Nico Williams]

On Wed, Nov 15, 2017 at 06:11:50PM +1000, James A. Donald wrote:
> On 11/14/2017 12:30 PM, Nico Williams wrote:
> >In any case, we've learned not to depend on canonical encodings, so
> >canonical encodings are neither here nor there.  We just don't build
> >protocols/applications that require repeatable canonical encodings.
> 
> I rather think we do depend on repeatable canonical encoding - I want
> separate code bases on separate machines to generate the equivalent checksum
> for the same transaction, so that they will know it is the same transaction,
> and the only value that I derive from ASN.1 is canonical per, so that I can
> define a canonical checksum for a data structure that is likely to be
> internally different on different machines with different compilers.

I don't know of any cases where one does this, but I can imagine one:
replicating a logical stream of operations on a Merkle hash tree DB,
with a hash/MAC/signature of the final Merkle hash tree root.  The
logical stream being a compression of the block-level stream, this is
worthwhile just on account of that when the goal is to replicate the
same Merkle hash tree on the recipient side.  (Of course, one should
also integrity-protect the logical stream in this case.)  This would,
indeed, be a legitimate application of canonical encodings.

(I can't think of any such DBs or filesystems.  And in a distributed,
highly concurrent DB/FS world, a single Merkle hash tree root is
basically unobtainium.  In centralized systems it could be done.  If
ZFS, for example, were more of a CAS FS, meaning that physical locations
did not affect its Merkle hash tree, then the ZFS root hashes would be
more meaningful and reproduceable, as in git, and thus replication of
the ZFS intent log (ZIL) rather than computing deltas as in "zfs send"
would be interesting indeed!)

In security protocols, however, we do not need canonical encodings
because in the common case you have an input message and its hash/MAC/
signature and you just verify that rather than reconstructing the input
message from other data.

> I can get that trivially from XRD, but getting it from ASN.1 seems to
> require proprietary tools with arcane licensing requirements that need a
> room full of lawyers.

DER *only* gets you a canonical encoding.  Every time.  There's no
licensing requirements.  There are free compilers and libraries.  If you
meant PER:

> I cannot find an open source tool that generates canonical per.

I don't recall whether PER produces canonical encodings.  I imagine it
could, since it's very similar to XDR as I've explained -- there aren't
a lot of choices to make, and if there are any, one could standardize a
variant that leaves no choices (just as DER is such a variant of BER).

It's true that there aren't many (any?) open source implementations of
PER.  It's a chicken-egg situation: not much uses PER, so not many tools
support PER.  We should fix this not by creating a replacement for PER
but by creating the tools as we need them.

If I had the time I'd teach Heimdal's ASN.1 compiler support for PER,
XDR, GSER (ugh), XER, and maybe even some JSON encoding rules (mostly so
I can decode BER/DER, reencode in JSON, then use jq(1) to deal with the
content :)

Nico
--