[Cryptography] Is ASN.1 still the thing?

Nico Williams nico at cryptonector.com
Mon Nov 27 13:57:39 EST 2017


On Mon, Nov 27, 2017 at 07:37:06PM +0100, Florian Weimer wrote:
> * 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?
> >> 
> >> [...]
> >
> > 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.  

Oh, good analysis.  That's probably right, though some spec and mailing
list archive deep diving might be necessary to find out for sure.

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

Well, we do interop, so, "yes".  We have a large variety of
implementations of PKIX, after all.  Some use ASN.1 compilers, and some
use hand-coded codecs.

Nico
-- 


More information about the cryptography mailing list