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

Re: comments on client auth

David P. Kemp wrote:
> 
> > 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.

Much as I hate the mud wars, I can't sit here, read this kind of stuff and say
nothing.

Firstly, it takes considerably more than 3 days to amass the information 
required to write a DER dump program, and a considerable amount of money.

Secondly, once you have your DER dump of a fully decorated X509v3 certificate
are you then able to read it? Not without the dreaded ASN.1. And a lot of
patience.

Thirdly, if it takes 3 days just to dump the stuff (in a still less-than-useful
format), how long does it take to write a program that can actually use it?

Fourthly, if it is ridiculously easy to deal with ASN.1 and DER, why are we
not inundated with (free) programs that do it? After all, every other vaguely
useful data format has widespread support.

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.
Follow-Ups: References: