[Cryptography] Is ASN.1 still the thing?

[Florian Weimer]

* 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.

And that might be the reason for doing things exactly this way: I
think the version field was added retroactively.  There are definitely
certificates out there which lack it.  

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*.