-----BEGIN PGP SIGNED MESSAGE-----
Ian Brown writes:
As Dave said, I think this argument is just going round in circles now.
We seem to have clarified at least some points. I believe none of the
following is contentious:
Indeed, so I'll go 'round once more :-)
1. We should not MUST MIME *or* Armour. Both increase the amount of code
needed for a minimal implementation, which none of us want. As Dave
said, linearly increased code increases exponentially the potential for
We differ in opinion here, but so be it. I agree MIME should not be
a MUST, but I believe Armor should be a MUST.
2. We are not trying to eliminate Armour. It is entirely appropriate
that it should be in there as an option to provide backward
compatibility, if implementors so wish.
3. Both systems are for converting fully secure binary PGP data into a
form which can be safely stored in/sent across 7-bit systems. Mail is
such a system. Armour/MIME does nothing for security. As Dave and Jon
have both said, OP is NOT a mail standard. It is a security standard.
7-bit conversion should therefore not be a MUST. As Lindsay Mathieson
said, we can safely assume most file systems can cope with 8-bit
I'll disagree one last time with this. No, Armor doesn't effect the
security of PGP itself, but it does affect how OP products will or
can be used in the "real world" and therefore affects the "level of
security provided by" the PGP system. (if noone used PGP, PGP is still
secure, but the system is not because it isn't used).
7-bit conversion is fundamental to the viability of a tool like PGP,
and is therefore not external to defining OP.
Jeremey Barrett wrote:
As Jon pointed out, PGP is not email software, there are a host
of other applications for PGP, which might well benefit (and do)
from ASCII armor.
The only way these applications will benefit from armor is if they need
to send data across a 7-bit system. Everywhere else can store objects in
their original 8-bit format.
Agreed. I find myself doing this quite regularly.
My point is that _requiring_ MIME eliminates a set of users. That's
all. Eliminating users decreases the security of the system, because
less people have the necessary tools. If security is the goal (and
as I read the wg charter, "The whole purpose of Open-PGP is to provide
security services") then the elimination of ASCII armor is
contradictory to the goals of the wg, IMO. It should be a MUST.
If we follow this logic, RSA and IDEA should be a MUST. We eliminate far
more users by not specifying this than by not making armor
Perhaps true, but not in the same sense. It is reasonably easy to go
get a new version of PGP which doesn't use RSA or IDEA, or doesn't
default to them. You don't have to change the way you "do things" to
switch to ElGamal and CAST. MIME is different, because it is external
I thought we were discussing PGP, not email. Last time I checked noone
has implemented file encryption, or encrypted archiving tools, or
remailers, or keyservers, or nym servers, or anything other than
email (and on occasion news) using MIME. Nor should they.
That's right. Armor is used in systems that use 7-bit mail systems as
their transport mechanism. Therefore, Armor is only relevant if we are
discussing PGP as an e-mail standard. You are arguing against yourself
It is only relevant in the case of any 7-bit transport, yes. (be that
email or news or what-have-you). My point is that the capacity for
7-bit encoding is critical to PGP, and all OP-compliant products
should provide it regardless of what other 7-bit transport schemes
are supported. Relying on the existence of an external infrastructure
(MIME) for the simple ability to send OP messages over 7-bit transport
mechanisms is not sound, as Rodney said.
And since ASCII armor 1) already exists, 2) is widely used, and 3) is
quite trivial to implement, it is the logical choice for built-in
File encryption and archiving tools can support 8-bit data. They do not
require armor. Remailers are using mail transport. The main reason
keyservers use armor is that they originally used mail transport. It
would be just as appropriate, and faster, for the Web/LDAP-based systems
to transfer keys as binary data. See http://solo.dc3.com/pks/kfmts.html
for one that allows this.
The idea that we should reimplement all the existing PGP
infrastructure in the name of 'standards' is hogwash. I don't have
LDAP in my mail reader. Neither does anyone else, with the exception
of Netscape and Micro$oft users. Supporting all those things is great,
but removing the simple functionality of PGP in favor of increasingly
complex and difficult protocols and software is not a step in the
Anyway... the horse is dead.
Jeremey Barrett BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems http://www.bluemoney.com/
PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64
-----BEGIN PGP SIGNATURE-----
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
-----END PGP SIGNATURE-----