Re: Armour

[Rodney Thayer <rodney@xxxxxxxxxxxxx>]

I don't think it is architecturally sound to assume MIME is present where
PGP is used.  I also don't think it is reasonable to assume people will
"just pipe it into their favorite un-mime/mime filter", as you can't assume
a command line environment.  I also don't think MIME is equivalent to
Armoring, as it involves multi-part processing which is more complex.

I think the armoring technique that OP inherits from PGP was useful, is
still usefull, and should not be dropped.  I don't think it's sound to
assume that "everone can do MIME", any more than it is sound to assume
"everyone can print PostScript".

>Date: Fri, 21 Nov 1997 09:27:53 +0000
>From: Ian Brown <I.Brown@xxxxxxxxxxxx>
>X-Mailer: Mozilla 4.02 [en] (WinNT; U)
>To: Jon Callas <jon@xxxxxxx>
>CC: IETF OpenPGP <ietf-open-pgp@xxxxxxx>
>Subject: Re: Armour
>Sender: owner-ietf-open-pgp@xxxxxxx
>
>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.
>
>