Date: Fri, 21 Nov 1997 09:27:53 +0000
From: Ian Brown <I(_dot_)Brown(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk>
X-Mailer: Mozilla 4.02 [en] (WinNT; U)
To: Jon Callas <jon(_at_)pgp(_dot_)com>
CC: IETF OpenPGP <ietf-open-pgp(_at_)imc(_dot_)org>
Subject: Re: Armour
Sender: owner-ietf-open-pgp(_at_)imc(_dot_)org
Jon Callas wrote:
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.
I cannot see the relevance of this to the Armour debate. All that armour
does is take some binary PGP data and put it in a format which can be
used in 7-bit systems. Anyone can trivially reverse the process. It
certainly has nothing to do with the security of the underlying data.
The binary data is fully secure before it ever sees armour. I'm
surprised you seem to be arguing otherwise.
Also, as much as I admire Phil, I thought we had agreed that "Phil has
spoken - it must be so" was not the attitude this group should take.
There are a number of places where having an armored binary object is
useful. Mail is one. Network transport is another.
Where MIME is also available, and does exactly the same job.
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).
So you're suggesting that programmers can't cope with handling binary
data, so we should convert everything to armour format first?
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.
Why is it any sillier than having an armour handler, apart from the fact
that you've already implemented one?
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.
What do you mean by 'trust'? The security of the underlying data?
Armouring it doesn't increase that. Or 'trust' the encrypted object will
be safely transported across a 7-bit system? Are you saying MIME won't
do that?
P 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.
Why are we arguing here? This is precisely the point several people have
made. Armour is only relevant to sending binary PGP objects across 7-bit
systems, of which mail is vastly the most common. Of course OP is not
just an e-mail standard. This is exactly why we shouldn't be making
systems largely used for mail transport an integral part of the
standard.
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.
Again, precisely the argument several people have made.
I think that it is wrong to make MIME a MUST feature.
I agree! Did anyone ever say this? I said in my "draft comments" post
that I liked the armour description in the draft, which is:
2.4 Conversion to Radix-64
OP's underlying native representation for encrypted messages, signature
certificates, and keys is a stream of arbitrary octets. Some systems
only permit the use of blocks consisting of seven-bit, printable text.
For transporting OP's native raw binary octets through email channels,
a printable encoding of these binary octets is needed. OP provides the
service of converting the raw 8-bit binary octet stream to a stream of
printable ASCII characters, called Radix-64 encoding or ASCII Armor.
In principle, any printable encoding scheme that met the requirements
of the email channel would suffice, since it would not change the
underlying binary bit streams of the native OP data structures. The OP
standard specifies one such printable encoding scheme to ensure
interoperability.
it is wrong to cut out small developers by
adding complexity and code size
Absolutely! This is why armor shouldn't be a MUST!
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.
I couldn't agree more! I'm delighted it helps PGP Inc.!
Ian.