I've been reading quite a bit about the virtues of MIME vs. ASCII Armor (AA)
for secure messages. Frankly - I don't understand the delima. AA was a great
tool to solve problems Secure Message Exchange (SME) imposed when AA was
envisioned and implemented. AA solved problem's that don't need solving in
today's message exchange standards (and.. most relevant.. pervasive
installation) for progressing SME as a "dial tone" service.
I don't see the fruits of this effort as only germane to SMTP {supporting
business to business information transactions (Inter/Intra/Xtra or whatever
the flavor of the day wants to call it)}. There is a clear need within my
organization's intranet (gee.. the terms we stoop to today....:-) for secure
heterogeneous message exchange. Folks.. CICS, IMS, MQ, HTTP, ODBC servers,
Notes, --and-- Exchange exchange message units. As the principle architect
for infrastructure systems in my organization I can emphatically state - AA
has no place, MIME with [ pretty good ] privacy services does. PGP/MIME is
an excellent candidate to date.... (MOSS is ..nice.. - but there's little to
no chance of pervasive deployment).
I have no problem with those that desire inclusion of AA as an option for
receiving... then let the market decide on sending. Clorox won't be in the
"buy" category for any "Must support send with AA" product....
Some grunt w/a budget....
[ psr ]
-----Original Message-----
From: Dave Crocker / IMC <dcrocker(_at_)imc(_dot_)org>
To: Jon Callas <jon(_at_)pgp(_dot_)com>
Cc: Gavan Schneider <gavan(_at_)magna(_dot_)com(_dot_)au>;
ietf-open-pgp(_at_)imc(_dot_)org
<ietf-open-pgp(_at_)imc(_dot_)org>
Date: Tuesday, November 25, 1997 6:52 PM
Subject: Re: The armour issue
At 06:01 PM 11/25/97 -0800, Jon Callas wrote:
or transmitted in any environment that may not be safe to raw binary data.
so does MIME.
For example, PGP key servers transmit keys both to and from the server in
so can MIME.
Armor is also useful for future applications.
so is MIME.
Lastly, there are systems that use (or would like to use) PGP over systems
that are not the internet.
Then they are not relevant to an Internet standards process.
Furthermore, I disagree with this strongly. MIME is a preferrered way (by
MIME is the standard way. As I try to make clear, that's not just a matter
of bureaucratic formaltiy, it is a matter of actual use. The purpose of a
standard is to achieve interoperability. The more choices there are, the
less interoperability there is.
Absent a strong claim as to the technical superiority of armour or
something else, the only reason to support an alternative mechanism which
does the same job is... well, nothing constructive.
text describing it was done by Paul Hoffman, who used MIME as a base. So
it's quite easy to do both.
The question remains: what functional basis is there for retaining
armouring in the standards-based specification. The argument of
compatibility with the pre-standards installed base has already been
countered for a number of different issues, not just armouring. The idea
of possible uses in the future is an argument for MIME, not a legacy
mechanism.
The compromise that I, as editor am working with (with thanks to Ian
Brown,
who came up with it) is as follows:
Jon, those who serve as working group chairs and document editors have a
difficult job. They are usually senior, talented folk. They get to work
hard and almost never are adequately appreciated.
Worst of all, they are often architects who do not see their own
preferences chosen.
The editor of an IETF working group document is required to be responsive
to the rough consensus of the working group. I hope no one has forgotten
this minor point.
(1) I'm going to remove anything in OP-FORMAT that requires the use of
ascii armor. Following my touchstone that any feature needed for backwards
compatibility is a SHOULD, it'll be a SHOULD.
Now if you just move it to an appendix and note that it has been the basis
for "packaging" PGP in pre-standards versions of the technology, then we'd
be in perfect shape. This would leave the document with one standard way
to do the packaging, but with full documentation about the prior
(non-standard) way of doing it.
d/
--------------------
Dave Crocker
dcrocker(_at_)imc(_dot_)org
Internet Mail Consortium +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 USA info(_at_)imc(_dot_)org ,
http://www.imc.org