[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rules for SPKI <auth> field comparisons
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Carl" == Carl Ellison <cme@cybercash.com> writes:
Carl> Not that I want to discourage volunteers, but the ASCII
Carl> format you sent out before struck me as hard enough to read
Carl> (for lack of spaces) that I'd imagine writing a custom
Well, you can add spaces, but then it becomes a bigger problem
making sure that they are correct.
Carl> editor to manipulate it - in which case it might as well be
Carl> binary. I'd like to hear from others on this.
What are the advantages of a text-like format:
o easy to debug. I can do it by inspection. Didn't we learn
this already with the success of SMTP, FTP, NNTP, etc?
o trivially searchable. Not that grep is the be all and
end all of search tools!
o no byte order issues.
o Easy to process in almost any language. Just because the
signature verification requires non-trivial calculations, doesn't
mean that all *interpreters* of certificates need do RSA. They
can be given the certificate by a trusted source.
Disadvantage of RFC822-style format:
o requires some kind of quoting rules to allow UTF-8 characters.
White space can get lost if you use the continuation line rules.
o you have no idea how much space to allocate until you have
read the whole thing (or stat'ed the file).
My feeling is that once you make a binary format more complicated than
a single struct, i.e. you make it have optional fields, and make it
easily extendible, you might as well go ascii-like.
I just now wrote an ISAKMP like Type/Value/Length binary format for
communication between a kernel and user level processes. We used
binary "types" and "lengths" but all I've done in my proposal is to
make the types and lengths ascii.
So, this isn't really an ascii proposal. It is a editor friendly
binary proposal.
] Temporarily located in balmy Helsinki, Finland, at SSH | one quark [
] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBMyq7hsmxxiPyUBAxAQHGcAL+JrkhOGiF5xwEfgyhyXljU15HiPNZilqZ
W00kcyOjnK9oTghtxx8r8wUMMZccC+INdlEJYYSDQxqXC7ERmfxs6pRkaEd5XNAL
kX/CTRFZHgyt12X2ShFDaf/DkNwF05Jc
=GXr8
-----END PGP SIGNATURE-----
References: