[Cryptography] Is ASN.1 still the thing?

[Nico Williams]

On Sat, Nov 25, 2017 at 09:49:19PM -0800, Christian Huitema wrote:
> On 11/25/2017 7:57 PM, Nico Williams wrote:
> > Are you referring to the EXPLICIT keyword?
> >
> > Explicit tagging -> TLV nesting.  I.e., TLV' where V' is the underlying
> > TLV, so: TLTLV.
> >
> > That's right: extra redundantly and ridiculously wasteful.
> The problem is the combination of EXPLICIT and DEFAULT. The spec:
> 
>         version [0] EXPLICIT Version DEFAULT v1
> 
> Normally encodes something like <T=[0], L=..., V = { T="version", L=...,
> V= NNN }>, but in the case where V=v1, you get three plausible encodings:

When the value is the DEFAULT then the field should be left out -- it's
really like OPTIONAL where absence denotes the DEFAULT value.

> 1) nothing
> 2) <T=[0], L=..., V = { T="version", L=..., V=v1 }>
> 3) <T=[0], L=0>

I believe the correct answer is (1): nothing.  Though I can see how one
might think (3) is sensible, and also how decoders should accept (2) if
DEFAULT values were allowed to change over time.

> Arguably, sensible IDL syntaxes should not have anything like the
> EXPLICIT clause. It is just overhead, and generates puzzling situations
> like the one above. [...]

Yes.

EXPLICIT and IMPLICIT exist only because of and for TLV encodings.

TLV -> bad idea.  Don't do it!

(Someone asked me off-list for an explanation of why TLV encodings are
bad.  It's all in this thread already, but maybe a single post collating
those reasons might be useful to some.)

>              [...]. But then, ASN.1 used to allow
> 
>         extension-1 [1] EXPLICIT ANY

That's right, ANY was removed (and replaced with the information object
system -- horrible name).

> Which make for powerful constructs. Or powerful foot guns, depending how
> you look at it.

Not much of a foot-gun.  One often needs extensibility, and either you
can do things like make the encoding extensible (e.g., see the ASN.1
extensibility marker and how that works in PER) or you can have "typed
holes" -- OCTET STRING wrappers of already-encoded values, along with a
type to identify the value.  Those are your basic choices.  Typed holes
work no matter what the encoding rules, so they're rather universal,
whereas an encoding need not provide any support for extensibility.

Nico
--