At 02:37 PM 11/15/97 +0000, Ian Brown wrote:
Jon Callas wrote:
> From PRZ's first documents, he labeled
> armoring as an integral piece of PGP. It's too useful as a generalized
> mechanism for holding an object (data, keys, etc.) without having to
worry
> about what odd thing something will do to your binary.
I'm not sure what you mean. Do you mean safely holding an object while
it is transmitted by mail?
Armour was a very necessary part of PGP. But now we have MIME, which is
meant for the same purpose - safely transmitting binary data across
7-bit or less mail systems.
I mean safely holding an object in any system that can't handle raw binary.
PGP objects (messages, keys, files, etc.) are constructed so as to not have
a lot of known plaintext in them. Whatever your opinion is about this, it's
the way PGP was designed. Phil has explained this to me in detail. This is
also the rationale behind such things as that a V3 private key encrypts the
body of the MPIs but not their length -- the length is known plaintext. But
I digress.
There are a number of places where having an armored binary object is
useful. Mail is one. Network transport is another. Any place where the
receiving program is a C program is a third (anyone who is careless enough
to call strfoo intead of memfoo can hurt themselves, and this is a hard bug
to find -- I know, I've done it).
Most of the present key servers, from the HTTP ones to the LDAP ones
transport their keys in armored form. The idea that the key server has to
have a MIME handler in it seems silly.
PGP objects are not just mail messages. Any data-thingie that you want to
encrypt can be put into PGP format, and if you don't trust raw binary,
armor works. Let me say this again, OP is *NOT* an email-encryption
standard, it is a data-object encryption standard (I'm quoting our esteemed
area director here). Of course, the most obvious use of a data-object
encryption standard is to send secure mail, but that is among the uses of
OP, not the sole one.
There are people who want to put PGP, especially OP, especially a
minimalistic OP into a number of limited environments -- pagers, PDAs,
smart cards (which are still a few years off, as they are *really*
limited). These people need to have a minimal set of things to implement.
These are, of course, all the MUST features. This is also why other
features like the hash preference are there -- there's no other way an
encrypted pager system can advertise that it has only implemented SHA-1.
I think that it is wrong to make MIME a MUST feature. It is obvious to me
that it is a SHOULD feature, but it is wrong to cut out small developers by
adding complexity and code size.
I'll add as a related note that making MIME a requirement actually helps
PGP Inc. Our toolkit does all the MIME/armor/compression handling
transparently for the caller. We'll just shrug. I feel compelled myself,
though, as editor of this spec to argue for a simple format spec, and then
layer MIME handling on top of it for the benefit of the small developer.
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 4200 Bohannon Drive
Network Associates, Inc. Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)