ietf-openpgp
[Top] [All Lists]

Re: Revising RFC 2015

1998-09-06 02:21:56
On Sat, Sep 05, 1998 at 11:25:13AM +0000, Lindsay
Mathieson wrote:

1.    Every existing MIME implementation has base64
encoding code (which is exactly the same as ASCII armour,
minus the CRC

correct.

2.    The MIME spec ban's nested encodings of MIME
objects

Correct, but irrelevant.

When signing messages and sending keys according to the
PGP/MIME RFC, no nested encoding of MIME objects occurs.
And, additionally, the "no nested encodings" stuff simply
doesn't apply if we are talking about _encrypting_ MIME
objects.

3.    Every PGP implementation to date may have ASCII
Armour, but they should also have a binary output option
- certainly PGP itself does. This works well with RFC
1847 & 2015 as the PGP binary object can be attached and
encoded with base64.

Pardon me?  RFC 2015 mandates ASCII armor, not MIME
encoding for PGP encrypted objects.

4.    Using ASCII Armour would break most MIME
implementations and *really* annoy the MIME team.

Is it remotely possible that you don't really understand
what this discussion is about?  ASCII armor is _only_
relevant for PGP objects which are fed into some PGP
backend unchanged.  These objects are handled as opaque by
MUAs, so using ASCII armor here just means that MUAs don't
need to care about MIME decoding at this point.

Additionally, it means that these folks who use non-MIME
MUAs may be able to process the PGP objects "manually"
(editor + pgp).

To make a long story short: Try reading RFC 2015.  Try
reading some code which implements it.  Try processing
messages which conform to 2015 with non-PGP enabled MIME
MUAs.  Try processing them manually.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

<Prev in Thread] Current Thread [Next in Thread>