[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