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

Re: comments on client auth

> Date: Fri, 14 Jun 1996 10:44:21 -0400
> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
>>    and strucutrally very very very similar. 
> DER is significantly more complex structurally.  It uses binary
> variable-length fields (including variable-length tags and
> variable-length-lengths, and a length-of-length-of-length bit).  It's
> got a complex two-level variable-length binary tagging scheme on
> *every* *single* *field*, and a variable-length length.
> Context-dependant tags, when present, are in binary; a field with a
> context-dependant tag is double-tagged, with two different lengths in
> the encoding..
> (e.g., <field-tag><outer-length><primitive-tag><inner-length><contents...>)
> When debugging, you either need special tools (how many debuggers have
> a DER-decode function?) or a hex dump, a lot of patience, and a copy
> of Kaliski's Layman's Guide *just to find* the field you want to look
> at.  

One of my hobbies is MIDI music - the standard midifile format is
binary and uses a variable-length encoding. And the target audience 
for that format isn't computer scientists or standards geeks.  The
software required to generate and decode V-L values is about 3 lines
of C each.  A midifile player (i.e. the code that accomplishes the
task at hand) makes the code to handle the incidental task of parsing
a specific file format insignificant in comparison.  It just isn't
credible to claim that "binary" and "variable-length" are esoteric
concepts that the average Joe can't handle.

A DER dump program (complete with structual indenting and decoding of
all 1993 universal types) is maybe two pages (the variable-length
stuff is perhaps 6 lines of that), and took a slow person all of a
3-day weekend to write from scratch.  Email me if you want a copy.

Let's just give it a break.  Peter claimed that SDSI and
DER are *structurally* similar, which is absolutely correct.  How
much conceptually simpler can one get (while maintaining generality)
than nested Tag-Length-Value, regardless of whether the data is
binary or ASCII.

One doesn't attempt to edit Java code with "a hex dump and a lot of
patience"; one edits an ASCII representation and then compiles to a
(binary) VM representation.  The security issues surrounding Java are not
related to the format of .class files, they are related to privilege
and trust.  I haven't heard anyone from Princeton or Oxford claim that
Java would have fewer security problems if only it used a different
class file format.

This list is much more constructive when discussing the real issues
of trust models, authorization, etc.  I hope it won't descend back
into the mud of data representation.