[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: encodings: do we need binary at all? -Reply
> At 02:06 PM 2/25/96 -0500, Ed_Reed@novell.com (Ed Reed) wrote:
> >I'd like to distinguish between representing things in binary, which I think
> >is a generally good thing for the purposes of on-the-wire efficiency and
> >server parsing performance, and the use of ASN.1, which is really just a
> >formal description of data structures, and BER, which is a particular
> >mechanism for encoding data.
> That's an important distinction. I think of this stuff in three layers:
> - an object layer (e.g. ASN.1) which describes entities and relationships
> - a mapping layer that translates objects into a bit or byte stream
> - an exchange layer, that translates the bit stream into an I/O format
> (e.g. bits on a wire or calls to an API). The layers can overlap.
> Issues like "Can you do Unicode?" are object questions - you _can_ do
> Unicode, but your exchange layer may use uuencode or MIME radix-64
> to represent it, or might use MIME quoted-printable if it's usually mostly
> Perry's example for keys uses a simple, fixed set of object types,
> and a simple mapping from those objects into a bit stream which
> fits into ASCII; numbers are mapped using ASCII decimal (or hex etc.).
> It's reminiscent of the nice clean MOSS formats. I don't remember if he
> addressed non-ASCII name fields. (Quoted-printable is cheating, but it's
> good enough for most applications and no loss for people with
> non-ASCII-character names that need to be squashed into ASCII for transmission.)
> For hashes, it probably makes sense to use the "real" form rather than
> the quoted-printable representation.
> ASN.1 uses a very general abstract framework for objects, but the BER/DER
> are a horrendous bit-twiddle that looks like its first priority is
> minimizing the number of bits in the output format, at the cost of
> excessive CPU decision-making and almost as many output bits as it saves.
> Either raw or mm/uuencoded, its exchange format isn't human-readable.
BER/DER don't try to minimize bits - that's what PER is for. BER gives a set
of encoding rules with some flexibility (making it easier to hand code ASN.1
to BER). DER makes it so there is only one correct encoding (so signed data
survives decoding/reencoding and the like).
> The big benefit of ASN.1 is the extensibility; BER/DER has minimal redeeming
> social value. I've heard that PER is far more tolerable.
Only in that PER uses less (far less) bits that BER/DER. Otherwise it is even
> A big drawback is that you _have_ to use ASN.1 parsing tools,
> rather than your favorite ASCII editors and databases.
> There are three main drawbacks to Perry's approach - size expansion,
> fixed contents, and the need for special-case code (as opposed to reusable
> Size expansion is pretty minor for most applications - at most 100% (for hex),
Size expansion would apply equally to BER/DER/PER if one assumes that the
need for armouring is provided by the envisaged transports. However, it seems
to me that the basic representation should be pure binary (even if it happens
to be mostly readable), and armouring should be treated as an external problem.
> and you can do better if you represent the key in base-64 or base-85.
> If you use a similar format for signatures, you still don't expand much,
> because you're signing hashes. And you start smaller because you're
> not spending lots of bits representing ASN.1 generality, which is pretty big.
> While the parsing code is single-purpose, rather than highly general like ASN.1,
> it's pretty simple, and you may be able to win by reusing non-ASN.1 tools.
> Having a fixed set of concrete things you can represent isn't that much worse
> than having a fixed set of objects that your standards committee has gotten
> around to defining; the big catch is what happens if you want to add fields
> to support new applications; in an ASN.1 world you may be able to expand better.
The benefits of ASN.1 in that respect can easily be captured without all the
overhead of the rest of ASN.1.
Anyway, I think the use or non-use of ASN.1 is not the central issue. What is
the issue is the production of a standard which fulfills the requirements
whilst still being widely implementable. X.509 fails dismally in this respect
not only through profligate use of obscure ASN.1 constructs, but through
monstrous cross-referencing, and worst, through actual _unavailability_ of
required information (such as X.509v3).
A good Internet standard should not require me to spend thousands of pounds on
other standards documents, nor weeks of my time reading them. In fact, in my
view, an Internet standard should be implemented using nothing but RFCs (or
at least draft standards). I realise this disqualifies SNMP ;-)
> # Thanks; Bill
> # Bill Stewart, firstname.lastname@example.org / email@example.com +1-415-442-2215
> # http://www.idiom.com/~wcs Pager +1-408-787-1281
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant and Fax: +44 (181) 994 6472
Technical Director Email: firstname.lastname@example.org
A.L. Digital Ltd, URL: http://www.algroup.co.uk