[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.
Follow-Ups: