At 3:40 PM 7/26/95, Harald(_dot_)T(_dot_)Alvestrand(_at_)uninett(_dot_)no wrote:
The unfortunate thing about text is that people will insist on treating
it as text, with the attendant effects of changing CRLFs into CRs,
tabifying spaces, spaceifying tabs, adding and deleting blank likes at
the end of messages, converting Ø into | and vice versa and so on
ad nauseam.
A damaged certificate is completely worthless; a binary-looking certificate
can be decoded.
If we believe that all who handle certificates, including mail transports,
can be convinced to refrain from their usual practices with regards to text,
text certificates may be able to fly.
Part -- but not all -- of the problems with X.500 is the use of ASN.1
We've found the of ASN.1 to be problematical. It solves the problem of
passing structured objects around the net at the expense of great
complexity, difficulty in debugging, and, most importantly, difficulty in
reaching closure on what the precise specifications are. (For example, I
have had to wade through lengthy discussions about why the order has to be
retained in the *presentation* of sets although the *searching* and
*matching* rules demand independence of order. Similar confusion applies
to the encoding rules and the "syntax" rules.)
There obviously has to be a means of sending a structure that survives the
perils of mail transport, but it's not really all that hard to do. The
main issue is the treatment of white space, and for text objects it's
arguable that one really doesn't *want* to distinguish "foo<tab>bar" from
"foo<sp><sp>bar". Thus, for signature purposes, these should be treated as
the same. Fairly simple rules suffice for mapping all whitespace into a
common format.
Using this approach, it's easy to treat certificates as text objects as
opposed to binary structures. Binary information such as keys and
signatures, can be encoded into a textual form easily and
straightforwardly. The computational cost of encoding binary objects into
text is not worse than the computational cost of packing and unpacking
ASN.1.
We used this approach in designing our messages for CyberCash, and it
drastically reduced the complexity of programming and debugging handling of
messages. It also promoted much more rapid convergence of a working
system.
Steve
--------------------
Steve Crocker
CyberCash, Inc., Suite 430 Work: +1 703 620 4200
2100 Reston Parkway Fax: +1 703 620 4215
Reston, VA 22091
crocker(_at_)cybercash(_dot_)com