[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: propagation control

> > This is of course very ASN.1, I don't mind ASN.1 except for the DER
> > rules which are completely braindamaged. If it had been made an
> > absolute requirement that every structure should be capable of
> > being encoded and decoded using a simple linear descent the problem
> > would not occur.
> I noticed you were very careful to specify DER, as opposed to BER.
> The Basic Encoding Rules (BER), of course, allow you to specify length of
> an object explicitly at the beginning, or implicitly by sending an
> end token when the object is finished.

Absolutely, if I was to make a single change to X.509v3 I would remove
the statement about DER encodings and define a new BER subset.

> In summary, CER is linear-encode and recursive decode, whereas DER is
> recursive-encode and linear-decode.  BER allows it to be done either way.

I don't see why it should be recursive decode. The decoder could be recursive 
descent but I don't see why there sould be any difficulty. My generic
ANS.1 BER encoder was linear in both directions - i.e. it was linear
accepting fully generic certs.

> These properties are not specific to ASN.1 and BER; they are applicable
> to any transfer format - either the length must be known or filled in at
> the beginning, or it isn't known until the end.  I don't know how you
> could have a format that allows both encoding and decoding of arbitrary-
> length nested objects to be done linearly.

The problem is that the length of the length field is indeterminate in ASN.1.
That coupled with not being able to specify indefinite length structures
in DER is what causes the problem.

> I also think that in the case of certificates, it hardly matters.  Doing
> random access or recursive descent over an object that is 1/2 KB or 2KB
> or 5KB long is no problem.  It's only when you start dealing with objects
> that don't fit into RAM (such as streaming media) that the difference
> becomes important.

The isssue is re-use of the encoder/decoder module. If you want the damn 
thing to fit in a web-phone you better not needlessly multiply the number
of data formats.

This is of course way off topic but I wanted to point out that there is
only one very small part of the ASN.1 spec that is seriously braindamaged.
The problem is that there is no way of achieving a principled solution
to the problem except at disproportionate development cost.