Re: MIME Security with PGP

[Dave Darnell <dave_d@xxxxxxxxxxxxx>]

MORE GOOD INFO ON PGP/MIME:

(thanks to Raph Levien)



>Date: Wed, 01 May 1996 13:52:51 -0700
>From: Raph Levien <raph@cs.berkeley.edu>
>To: resolving-security@imc.org, id@cc.mcgill.ca
>Subject: Re: MIME Security with PGP
>Sender: owner-resolving-security@imc.org
>
>Iand Duncan wrote:
>> I think you've missed, just slightly, a reasonable option. There's a
>> variation on (2) which involves describing a set of semantically
>> reversible mappings between existing PGP structures and a PGP profile for
>> security multiparts.  This requires no change to PGP proper. A sloppy but
>> hopefully useful subtitle is "the MOSS-ultralite profile using existing
>> PGP tools". It isn't idle speculation on my part about the feasibility of
>> doing mapping. I spent a a lot of time about a year ago convincing myself
>> that it was possible. 
>
>   This proposal makes absolutely no sense to me at all. Since the
>existing PGP/MIME effort is a straightforward adaptation of MOSS's
>security multiparts structure to PGP, it is hard for me to see how your
>proposal would differ from it substantially.
>
>> It would require an additional bit of smart plumbing somewhere to 
>> support processing of a PGP-MIME message with existing the existing PGP
>> applications. If, in the future, the "PGP development team" decided
>> including PGP-MIME as a native mode of operation all the better. If we got
>> it done quickly it could be a feature of PGP 3.0. 
>
>   Have you taken a look at premail? Or at Michael's PGPMIME reference
>implementation? Or at Qualcomm's beta integration of PGP/MIME into the
>Mac version of Eudora?
>
>> So, given this option, I have to disagree with the conclusion that the
>> current proposal is the best we can do today. We need a solid foundation
>> for moving forward. MIME has won the structured e-mail format battle. PGP
>> is a very popular and highly functional security tool. Put the two
>> together correctly and I believe we'll finally have a winning combination.
>
>   I think you've stated the design goals of the PGP/MIME effort fairly
>well here.
>
>> An extra few months at this point isn't going to make a significant
>> difference, but rushing to get it wrong will successfully tank the
>> potential
>
>   Exactly what in the existing PGP/MIME proposal is "wrong?" I've
>implemented it, and it works. The standard is, of course, a compromise.
>However, I am quite satisfied that it is the best compromise we could do
>given our constraints.
>   The most controversial aspect of the spec is that it requires 7-bit
>encoding of all signed data. Thus, it's potentially a bit wasteful of
>bandwidth, etc., especially if you're using it over binary-safe
>transports. This was hotly debated on the PGP/MIME mailing list, and I
>personally feel that the proponents of a binary-signing format did not
>make a strong enough case.
>   I have to say that I considered a binary-signed format quite
>carefully before rejecting it. However, it has numerous technical
>problems, perhaps the most important of which is that you _cannot_
>translate syntactically between a PGP native signed message and a
>binary-signed message. The fact that such a translation works in
>Michael's PGP/MIME spec is a testament to how well it's crafted.
>   I've gone on about binary-signing here, but it seems unlikely that
>you intend to solve this problem, given that MOSS doesn't and you're
>describing your proposal as "MOSS-ultralite."
>
>   Ultimately, for your proposal to be taken seriously, just saying that
>you don't like the existing PGP/MIME spec isn't enough. You're going to
>have to convincingly explain how Michael's spec fails users, and how
>it's possible to correct those failings without abandoning the features
>and robustness of the existing spec.
>
>   I said above that the PGP/MIME spec is a compromise, and it is.
>However, I'd like to say a bit about just how good it is. In many ways,
>it's actually simpler than native PGP (one signature format rather than
>two, PGP's charset parameter has been eliminated). Further, it fixes a
>few serious technical flaws in PGP. Perhaps most importantly, it's now
>possible to both generate and verify signatures in a single pass. It
>maintains PGP's ability to decrypt in a single pass (although inability
>to do encryption in a single pass remains one of PGP's technical
>failings). It fixes the problem in PGP's clearsigned format that puts
>unsigned, unverified information inside the "begin pgp signed message"
>wrapper. Compatibility is good - MIME capability is _not_ needed for
>someone to usefully decrypt a PGP/MIME message. Signature verification
>is best done automatically, but _can_ be done by hand using PGP 2.6.x,
>just by saving the two parts as separate files and invoking PGP on them.
>As mentioned above, it is possible to rewrite a PGP native signed
>message as a PGP/MIME one, and vice versa. This capability is important,
>for example, in a mailer which decrypts messages before storing them in
>a mailbox (for speed and functionality, including searching), but leaves
>signatures intact so that they can be non-repudiably verified later. The
>spec is simple enough and clearly enough written that my implemenation
>and Qualcomm's were able to interoperate with each other the first time,
>right out of the box.
>   Beat that.
>
>Raph
>
>
======================================
|   David Darnell              
|   SysTrends, Inc.             
|   Arizona EC/EDI Roundtable   
|   1850 East Carver Road       
|   Tempe, AZ 85284             
|   Tel (602)838-5316           
|   Fax (602)897-8032           
|   mailto://dave_d@systrends.com        
======================================