Armour

[Ian Brown <I.Brown@xxxxxxxxxxxx>]

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 >:)