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.
Bill Stewart wrote:
Understanding armour _isn't_ very hard; I'd prefer MUST,
especially since it's needed for backward compatibility with PGP 5.0
(in particular, the Encrypt Clipboard doesn't do MIME.)
I agree it isn't too difficult. But as Paul Hoffman said:
The advantage is that using standard MIME is more easily specified and
implemented than using ASCII armor. That is, a developer who has a MIME
toolkit must modify that toolkit in order to use ASCII armor. Forcing ASCII
armor when it shows no noticable value over standard MIME is one more
impediment to new developers adopting OpenPGP.
...
If the IETF Calendaring and Scheduling Working Group,
for example, wants to use OpenPGP for handing around scheduling events in
an automated environment (that is, without human intervention), there is
absolutely no reason why the must be able to process older PGP formats. If
our spec requires that they do so, it is that much harder for them to chose
it over competing specs.
OpenPGP can be useful for many types of applications other than humans
sending email to each other. Many other IETF messaging protocols can use
the privacy and authentication offered by OpenPGP. They would have
absolutely no use for backwards compatibility with earlier versions.
This isn't to say that we shouldn't try to get software to be able to
process and possibly even emit messages from earlier versions, but there is
no reason to *force* them to because what we specify will be complete and
secure by itself. We should make it as easy as possible for some who starts
with OpenPGP to add support for earlier versions without burdening them
with implementation issues that aren't relevant to OpenPGP.
Bill again:
Generating it is a matter of taste - will PGP 5.0 always accept MIME?
Even in applications like Decrypt/Verify Clipboard?
I agree it could be awkward with the current implementation (PGP 5).
Most mailers these days understand MIME, so even if they don't
understand PGP/MIME objects they can do the conversion from Base64 to
binary data - at which point PGP could take over. If we had a standard
content-type for the PGP data itself - rather than just using
application/octet-stream like PGP/MIME - *any* mailer that understood
MIME could be configured to launch a PGP program upon receipt of such a
body part.
I'm not arguing that we should totally do away with armour - just that I
don't think it should be a MUST, so that people who want to use OpenPGP
in their program or standard minimally, with no need for backwards
compatibility, can do it with as little problem as possible.
Ian >:)