[Cryptography] Is ASN.1 still the thing?

[Nico Williams]

On Wed, Nov 15, 2017 at 09:45:06PM +0100, Erwann ABALEA wrote:
> 2017-11-15 17:47 GMT+01:00 Nico Williams <nico at cryptonector.com>:
> 
> > On Wed, Nov 15, 2017 at 06:11:50PM +1000, James A. Donald wrote:
> > > On 11/14/2017 12:30 PM, Nico Williams wrote:
> >
> [...]
> 
> > > 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).
> 
> PER has 2 possible (cumulative) variants: unaligned, and canonical.
> There's not that much space left in PER for not being canonical. IIRC, SET
> ordering and padding are the only place where there's a difference.
> I haven't found a *commercial* compiler that generates the canonical
> variant.

I'll have to check the spec.

> > 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.
> 
> asn1c (https://github.com/vlm/asn1c) supports PER. It also supports 2008
> ASN.1 (while several compilers only support the 1988 dialect).

Good to know.

> Unfortunately, the support of information object sets isn't complete, and I
> think it doesn't support parameterized types.
> But apart from that, it does a good job.

You can always not use the IOS.  It's mostly just syntactic sugar that
allows you to automatically wrap/unwrap things in typed holes.  You can
just hand-write the code for that -- it's simple enough.

An ASN.1 compiler that only implements the base x.680 goes a long, long
way.

I bet PB doesn't have anything like the IOS...

Nico
--