[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
Bill Sommerfeld wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> content-type: text/plain; charset=us-ascii
>
> > Given SDSI certs are AS COMPLEX an encoding as X.509 DER,
> > there is essentially no difference to implementors, here,
> > when faced with a scratch implementation effort.
> >
> > This is not at all clear. I enjoy programming in Lisp and Scheme,
> > while I find dealing with ASN.1 to be like pulling teeth. I find that
> > S-expressions are *much* easier to work with than ASN.1..
>
> Which is the false argument put forward for so long that
> X.509 is something to do with ASN.1 programming.
>
> I said X.509 DER, not ASN.1. But then, why dont we misrepresent;
> its makes argument easier to win.
>
> DER's design is tied closely to that of ASN.1. One cannot rationally
> discuss the design of DER without also discussing the design of ASN.1.
Rubbish. Though, this is a closely held pre-condition for
your argument to hold. There is no substantial design difference
between DER and SDSI S-expressions binary encoding,
judging from the SDSI presentation notation. They
are both just recursive, indefinite-length values. Should
I notate DER in Marshalls LISP notation, then any underlying
difference between SDSI presentation value and DER LISP value would be hard
to note!
yes, I agree there is difference between the mechanism
for faciliting strong-typing. SDSI uses tag-names, whereas
DER uses numbers. That they both have strong-typing
is what matters! Great to see the designs collide, here.
As I have said, we have been programming DER in LISP-like syntax
for some time. WE dont even necesarily use OSI encodings of
integers, reals, using local internet-tags to introduce more
conventional primitive encodings more familiar to
Internet, and cobol-based, implementors.
>
> X.509 is specified using a complex subset of ASN.1, using features
> like SET, CHOICE, OPTIONAL, context-dependant tags, etc.,
>
> Consequently, the X.509 DER must also be overly complex...
We dont always use them, for this very reason. We agree with you, here!
>
> The DER encoding rules are semantically equivalent to S-expression
> binary encoding,
>
> Are we talking about the same thing here? SDSI uses ASCII for its
> external representation. Even though it includes an escape into pure
> binary (verbatim-mode octet strings) for bulk data, all the structural
> framing is done using ASCII.
I have not been able to find the mentioned SDSI binary encoding
rules, I agree! However, based on the notation
system (the S-expr) these are just indefinite length
recursive typed-values. yes, one can sign the notation system,
rather than a binary encoding; one can do
this with DER LISP-notation also, as there is no structural difference
between the notation and the encoding, as I believe
to be true with SDSI.
a>
> 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).
These are not structural issues. DER is just
one value, wrapping together a typed-group of others. Just like
SDSI. how value lengths and tags are encoded is 1 hours programming.
Ive yet to see the Lampson binary encoding; so
I cant really compare programming ease.
It's
> got a complex two-level variable-length binary tagging scheme on
> *every* *single* *field*, and a variable-length length.
Its quite true. And, noone uses them. Almost all implementors profiles
reduce the set to max 2 byte tag, and max 3 byte length. QED.
> 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..
Then dont use them! define a simpler value which doesnt
have context tags! Then DER wont put them on! its your choice
as a designer; dont use the complex features, and DER wont
bite you! lets be professional!
>
> (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.
> In contrast, with SDSI it appears that, for the most part, you can
> find a field of interest in a structure just by dumping it in ASCII.
> Field tags are human-readable strings.
I think this is silly. Any fool can go get Marshalls program, and
convert the bytes into the ASCII DER-LISP syntax for debugging. Then
it looks just like SDSI! you look for the rag "name-id"; I look
for "APPL 34". Perhaps I can write a sed-script.... to convert
"APPL 34" into "name-id" if I was just intelligent enough...
As I say, Id like to see the SDSI binary encoding rules
so we could (both) make a real comparison
of this sophomoric debating point about
the notion of "simplicity" of values.
I really like SDSI. Im going to implement it
both in native Lamspon encodings, and in X.509 so
both communities are happy. Seems
the easiest way to go, and most harmonious.
The system ideas in SDSI are great fun,
and do seem indeed to be a simple
design suitable for some uses.
Im with you Bill, not against you! To
make economic-priced products, Im just
going to implement the identical SPKI systen
being designed here in both technologies, thats all.
Noone gets hurt but me; if noone uses the
X.509 version, I doubt we will continue to supprot
it for very long!
I an NOT suggesting we use DER or X.509 here
in the standards process!
Im just saying, VeriSign will make such
a class of product, as one of its
value-padded options over the vendor-common
SPKI standard. Any problem with this?
>
> - Bill
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBMcF6vVpj/0M1dMJ/AQHWeQP8C8Jjs73uTXFiEUJRaELKgOXnl/PgdWhU
> mr8qXnXGqDy/mLLKA4uGHR2vYxPjNHKWQ5NlAWzYqPyzACjgqz7TJAy19c3ZDlCb
> Tm30ky9NPq8EqjQL1tAVwLfq4QWvRccL3og1ybknYBy1ioXzhWp24MRHEbzIogyG
> aEFTDDQb3B4=
> =jHgF
> -----END PGP SIGNATURE-----
References: