Re: Split Implementations of PGP

[Jon Callas <[e-mail]>]

On 17 Mar 2005, at 3:42 AM, Ben Laurie wrote:

>> It's a small thing, but if message A has one attachment, 
>> "Attachment.pgp", and message B has two attachments, "Text.pgp" and 
>> "ZeSecretPlans.doc.pgp" -- which each decompose to the same mail 
>> message -- one could argue that message A is more secure than message 
>> B because it leaks less information about its internal structure.
>
> Are attachment names really not encrypted? If they are (as they should 
> be) then the only threat is that an attacker knows the number and 
> (compressed) size of the attachments. I find it hard to get excited 
> about that.
>

No, they're not encrypted. This is part of MIME. The MIME part has a 
file name, and that file name is in the clear. The PGP products do what 
I described in my previous note; we name them AttachmentN.pgp, and 
inside the literal packet is the actual name of the resultant file.

A number of systems do not encrypt the file names, even when they are 
using OpenPGP/MIME.

	Jon




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2I1cDsi002977; Thu, 17 Mar 2005 17:38:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2I1cDSl002976; Thu, 17 Mar 2005 17:38:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2I1cBFR002969 for <[e-mail]>; Thu, 17 Mar 2005 17:38:11 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 17 Mar 2005 17:38:08 -0800
Received: from [192.168.2.164] ([63.251.255.85]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Mar 2005 17:38:08 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 17 Mar 2005 17:38:08 -0800
In-Reply-To: <[e-mail]>
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: Ingo Luetkebohle <[e-mail]>, Cyrus Daboo <[e-mail]>, Eric Burger <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Split Implementations of PGP
Date: Thu, 17 Mar 2005 17:39:08 -0800
To: Ben Laurie <[e-mail]>, OpenPGP <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 17 Mar 2005, at 3:42 AM, Ben Laurie wrote:

>> It's a small thing, but if message A has one attachment, 
>> "Attachment.pgp", and message B has two attachments, "Text.pgp" and 
>> "ZeSecretPlans.doc.pgp" -- which each decompose to the same mail 
>> message -- one could argue that message A is more secure than message 
>> B because it leaks less information about its internal structure.
>
> Are attachment names really not encrypted? If they are (as they should 
> be) then the only threat is that an attacker knows the number and 
> (compressed) size of the attachments. I find it hard to get excited 
> about that.
>

No, they're not encrypted. This is part of MIME. The MIME part has a 
file name, and that file name is in the clear. The PGP products do what 
I described in my previous note; we name them AttachmentN.pgp, and 
inside the literal packet is the actual name of the resultant file.

A number of systems do not encrypt the file names, even when they are 
using OpenPGP/MIME.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2HCtWvK023123; Thu, 17 Mar 2005 04:55:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2HCtWdQ023122; Thu, 17 Mar 2005 04:55:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2HCtU4l023096 for <[e-mail]>; Thu, 17 Mar 2005 04:55:30 -0800 (PST) (envelope-from [e-mail])
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j2HDsMa07439; Thu, 17 Mar 2005 13:54:38 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <[e-mail]>
Date: Thu, 17 Mar 2005 12:58:39 +0000
From: Ian G <[e-mail]>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050219)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: Ben Laurie <[e-mail]>, [e-mail], Ingo Luetkebohle <[e-mail]>, Cyrus Daboo <[e-mail]>, Eric Burger <[e-mail]>
Subject: Re: Split Implementations of PGP
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:
> 
> On 15 Mar 2005, at 4:41 PM, Ben Laurie wrote:
> 
>> Jon Callas wrote:
>>
>>> On 12 Mar 2005, at 3:24 AM, Ingo Luetkebohle wrote:
>>>
>>>> Even better would be to have individually encrypted parts.  This is
>>>> possible with PGP/MIME but not current practice.  Trouble being, of
>>>> course, that the sender would have to know this is in advance.
>>>>
>>> Better for whom?
>>> One of the reasons that practice is to not have individually 
>>> encrypted parts is that that has not been considered as good, meaning 
>>> not as secure. It isn't as convenient for an entity who doesn't have 
>>> the keys to process such a message, and that's been considered a 
>>> feature rather than a bug.
>>
>>
>> I'm struggling to understand this - how does this make it any easier 
>> for an attacker? (Other than log_2(n), where n is the number of parts, 
>> for the brute force attack).
>>
> 
> 
> It's a small thing, but if message A has one attachment, 
> "Attachment.pgp", and message B has two attachments, "Text.pgp" and 
> "ZeSecretPlans.doc.pgp" -- which each decompose to the same mail message 
> -- one could argue that message A is more secure than message B because 
> it leaks less information about its internal structure.


Right.  But, given the mobile platform limitations,
Message A is unusable therefore its security argument
is null & void;  the user has to make *some compromise*
in order use the system, and that may well be "giving
up a little security."

I'm curious as to whether there is a hard proposal for
the group behind this?

iang
-- 
News and views on what matters in finance+crypto:
         http://financialcryptography.com/



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2HChjB4018950; Thu, 17 Mar 2005 04:43:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2HChjx2018949; Thu, 17 Mar 2005 04:43:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ethos.braverock.com (ethos.braverock.com [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2HChirS018939 for <[e-mail]>; Thu, 17 Mar 2005 04:43:45 -0800 (PST) (envelope-from [e-mail])
Received: from [10.23.1.102] (dsl017-021-008.chi1.dsl.speakeasy.net [69.17.21.8]) (authenticated bits=0) by ethos.braverock.com (8.13.3/8.13.1) with ESMTP id j2HCiEfE030347 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 17 Mar 2005 06:44:15 -0600
From: "Brian G. Peterson" <[e-mail]>
To: [e-mail]
Subject: Re: Split Implementations of PGP
Date: Thu, 17 Mar 2005 06:44:27 -0600
User-Agent: KMail/1.7.2
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thursday 17 March 2005 05:42 am, Ben Laurie wrote:
> > Jon Callas wrote:
> > It's a small thing, but if message A has one attachment,
> > "Attachment.pgp", and message B has two attachments, "Text.pgp" and
> > "ZeSecretPlans.doc.pgp" -- which each decompose to the same mail message
> > -- one could argue that message A is more secure than message B because
> > it leaks less information about its internal structure.
>
> Are attachment names really not encrypted? If they are (as they should
> be) then the only threat is that an attacker knows the number and
> (compressed) size of the attachments. I find it hard to get excited
> about that.

Implementations differ.  I've seen some implementations that split out the 
mime parts that obfuscate the attachment names and others that just add .pgp 
or .asc to the attachment names.

I think that one of the larger issues is that if the mime parts are separate, 
an attacker could remove a single attachment,  effectively changing part of 
the meaning of what the original sender wanted to say by removing part of the 
message.

Regards,

  - Brian 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2HBgXjb098635; Thu, 17 Mar 2005 03:42:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2HBgXUJ098634; Thu, 17 Mar 2005 03:42:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2HBgVLi098611 for <[e-mail]>; Thu, 17 Mar 2005 03:42:32 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 6672D33C33; Thu, 17 Mar 2005 11:42:30 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Thu, 17 Mar 2005 11:42:32 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
Cc: [e-mail], Ingo Luetkebohle <[e-mail]>, Cyrus Daboo <[e-mail]>, Eric Burger <[e-mail]>
Subject: Re: Split Implementations of PGP
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:
> On 15 Mar 2005, at 4:41 PM, Ben Laurie wrote:
> 
>> Jon Callas wrote:
>>
>>> On 12 Mar 2005, at 3:24 AM, Ingo Luetkebohle wrote:
>>>
>>>> Even better would be to have individually encrypted parts.  This is
>>>> possible with PGP/MIME but not current practice.  Trouble being, of
>>>> course, that the sender would have to know this is in advance.
>>>>
>>> Better for whom?
>>> One of the reasons that practice is to not have individually 
>>> encrypted parts is that that has not been considered as good, meaning 
>>> not as secure. It isn't as convenient for an entity who doesn't have 
>>> the keys to process such a message, and that's been considered a 
>>> feature rather than a bug.
>>
>>
>> I'm struggling to understand this - how does this make it any easier 
>> for an attacker? (Other than log_2(n), where n is the number of parts, 
>> for the brute force attack).
>>
> 
> 
> It's a small thing, but if message A has one attachment, 
> "Attachment.pgp", and message B has two attachments, "Text.pgp" and 
> "ZeSecretPlans.doc.pgp" -- which each decompose to the same mail message 
> -- one could argue that message A is more secure than message B because 
> it leaks less information about its internal structure.

Are attachment names really not encrypted? If they are (as they should 
be) then the only threat is that an attacker knows the number and 
(compressed) size of the attachments. I find it hard to get excited 
about that.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2H9fbw8056733; Thu, 17 Mar 2005 01:41:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2H9fbh9056732; Thu, 17 Mar 2005 01:41:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2H9facU056722 for <[e-mail]>; Thu, 17 Mar 2005 01:41:36 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 17 Mar 2005 01:41:32 -0800
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Mar 2005 01:41:32 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 17 Mar 2005 01:41:32 -0800
In-Reply-To: <[e-mail]>
References: <r02010400-1038-120DB24D92BE11D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: Ingo Luetkebohle <[e-mail]>, OpenPGP <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Split Implementations of PGP
Date: Thu, 17 Mar 2005 01:42:34 -0800
To: Lars Eilebrecht <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> I assume Jon is talking about on-the-fly decryption of incoming
> messages, i.e., when the decryption happens before the data hits
> the MUA?  A MUA usually includes the size of an 'object' in a
> request and only expect that many bytes in the response. However,
> the size after decryption is almost always different.
> IMHO, this is not directly an issue with IMAP, but with the
> actual implementation/interpretation of IMAP.
> The message size handling is just one of the issues with IMAP ...
> e.g., think about bodystructure requests and on-the-fly decryption.
>

That's precisely what I'm talking about.

However, it is an issue with IMAP itself. IMAP has a core assumption 
that a message has a size that is constant and knowable even when all 
you're getting is the headers. An IMAP server must reply accurately and 
precisely the message size when it first informs the client about the 
message.

If that message needs lots of transformations including decryption, 
this makes determining the precise message size an interesting problem.

> But I have to admit that I'm not sure what this has to do with
> the original topic of this thread? :-)
>

I'm giving a warning that simply passing session keys around may not 
give obvious solutions to the problem being solved. We've spent a lot 
of time with advanced IMAP features at PGP Corporation. Admittedly, in 
our case, we're building proxies and proxies don't have liberties that 
client-server systems do. If IMAP were less fussy about message size, 
then some of the difficult problems would have obvious solutions.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2H9WObL053642; Thu, 17 Mar 2005 01:32:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2H9WOMw053641; Thu, 17 Mar 2005 01:32:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2H9WNiP053627 for <[e-mail]>; Thu, 17 Mar 2005 01:32:23 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 17 Mar 2005 01:32:19 -0800
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Mar 2005 01:32:19 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 17 Mar 2005 01:32:19 -0800
In-Reply-To: <[e-mail]>
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail], Ingo Luetkebohle <[e-mail]>, Cyrus Daboo <[e-mail]>, Eric Burger <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Split Implementations of PGP
Date: Thu, 17 Mar 2005 01:33:10 -0800
To: Ben Laurie <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 15 Mar 2005, at 4:41 PM, Ben Laurie wrote:

> Jon Callas wrote:
>> On 12 Mar 2005, at 3:24 AM, Ingo Luetkebohle wrote:
>>> Even better would be to have individually encrypted parts.  This is
>>> possible with PGP/MIME but not current practice.  Trouble being, of
>>> course, that the sender would have to know this is in advance.
>>>
>> Better for whom?
>> One of the reasons that practice is to not have individually 
>> encrypted parts is that that has not been considered as good, meaning 
>> not as secure. It isn't as convenient for an entity who doesn't have 
>> the keys to process such a message, and that's been considered a 
>> feature rather than a bug.
>
> I'm struggling to understand this - how does this make it any easier 
> for an attacker? (Other than log_2(n), where n is the number of parts, 
> for the brute force attack).
>


It's a small thing, but if message A has one attachment, 
"Attachment.pgp", and message B has two attachments, "Text.pgp" and 
"ZeSecretPlans.doc.pgp" -- which each decompose to the same mail 
message -- one could argue that message A is more secure than message B 
because it leaks less information about its internal structure.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GNgT9j026595; Wed, 16 Mar 2005 15:42:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GNgTh3026594; Wed, 16 Mar 2005 15:42:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-relay1.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GNgRBX026577 for <[e-mail]>; Wed, 16 Mar 2005 15:42:28 -0800 (PST) (envelope-from [e-mail])
Received: from pmxchannel-daemon.mail1.hrz.uni-bielefeld.de by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) id <[e-mail]> for [e-mail]; Thu, 17 Mar 2005 00:42:20 +0100 (MET)
Received: from pc-hans.dhcp.lcl.studentenwerk-bielefeld.de (pc-hans.dhcp.lcl.studentenwerk-bielefeld.de [10.128.53.36]) by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPS id <[e-mail]>; Thu, 17 Mar 2005 00:42:13 +0100 (MET)
Date: Thu, 17 Mar 2005 00:42:20 +0100
From: Ingo Luetkebohle <[e-mail]>
Subject: RE: Split Implementations of PGP
In-reply-to: <[e-mail]>
To: Eric Burger <[e-mail]>
Cc: OpenPGP <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Evolution 2.0.2
Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-O4oUR7Rf/6OxWJJ4kibX"
X-Spam-Level: 
X-UniBi-Spam-Level: , 7%
X-UniBi-Spam-Rules: __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __SANE_MSGID 0
X-UniBi-Deliver: Tag
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.16.16, vscan4.hrz.uni-bielefeld.de
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=-O4oUR7Rf/6OxWJJ4kibX
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Am Mittwoch, den 16.03.2005, 16:19 -0500 schrieb Eric Burger:
> Note that I *chose* to trust the server FOR THIS MESSAGE ONLY.  That is w=
hy
> we asked the question about split implementations.  It would be VERY BAD =
if
> we had to trust the server with our private key.

I like the selectivity and it appears that, given current PGP/MIME
practice, your suggestion is the best one can do.

I'd like to suggest something in addition to that:  Allow for
*replacement* of the session-key packet, instead of decryption.  Here's
how it would work:

The client receives the encrypted session key from the server, decrypts
it, *immediately recrypts* using the recipients public key and passes
the encrypted session-key back to the server.  The server then proceeds
to *replace* the encrypted session key in the message (without ever
decrypting it!) and forwards it to the intended recipient.  Because the
session key stays the same, the recipient can decrypt it.

When used with separately encrypted attachments, it would enable
forwarding something without ever downloading it, and without the server
ever seeing the decrypted content.  This wouldn't be terribly useful
right now, because all clients encrypt the whole message and I would
have trouble making a forwarding decision without looking at the
content, but when a client ever implements a different PGP/MIME usage,
the combination would be terrific, in my very humble opinion.

There's one possible gotcha:  I don't know about the security
implications of encrypting the same plaintext (here, the session key)
with two different public keys.  I can't think of any problems right
now, but wouldn't exclude the possibility of a leak to occur.  I hope
there's enough cryptographers here to shout in that event, though :)

Ingo

--=-O4oUR7Rf/6OxWJJ4kibX
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCOMRczZDBZDStzlsRAhl0AJ4qSKaMqHdUITazHywnE2i37P/tcACgoQ5i
0BrCSuRiotpGtNpovD9+F4A=
=DfKl
-----END PGP SIGNATURE-----

--=-O4oUR7Rf/6OxWJJ4kibX--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GLQ989013545; Wed, 16 Mar 2005 13:26:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GLQ9s4013544; Wed, 16 Mar 2005 13:26:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from salvelinus.brooktrout.com (salvelinus.brooktrout.com [204.176.205.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GLQ8Eb013533 for <[e-mail]>; Wed, 16 Mar 2005 13:26:08 -0800 (PST) (envelope-from [e-mail])
Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j2GLNJHD023172; Wed, 16 Mar 2005 16:23:19 -0500 (EST)
Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id <GZABLCSY>; Wed, 16 Mar 2005 16:19:18 -0500
Message-ID: <[e-mail]>
From: Eric Burger <[e-mail]>
To: Ingo Luetkebohle <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: RE: Split Implementations of PGP
Date: Wed, 16 Mar 2005 16:19:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Forward without download: I've got a 100MB document and a piece of text
saying, "here is the very important document you need to send to foo".  I
*chose* to trust the server, this time, to decrypt the message for me and
tell me the body structure (a big document and a piece of text).  I download
the text, and I decide to forward the document.  I tell the server to do the
forwarding for me on my behalf.

Note that I *chose* to trust the server FOR THIS MESSAGE ONLY.  That is why
we asked the question about split implementations.  It would be VERY BAD if
we had to trust the server with our private key.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Ingo Luetkebohle
> Sent: Wednesday, March 16, 2005 8:14 AM
> To: Jon Callas
> Cc: OpenPGP
> Subject: Re: Split Implementations of PGP
> 
> 
> 
> Am Mittwoch, den 16.03.2005, 01:46 -0800 schrieb Jon Callas:
> > Something that would help those of us doing crypto and IMAP 
> would be 
> > for IMAP to be less fussy about message size.
> 
> [...]
> 
> It would be very usefull, for me at least, if you could re-state your
> use-case here.  I'm getting the impression that I'm missing something
> fundamental.
> 
> I'm always reading about server-side decryption.  Some people seem to
> see it as a solution for the "one big chunk of ciphertext" 
> problem.  I'm
> not sure what else it would be good for.
> 
> For me, server-side decryption is a nightmare.  Pure and evil.  
> 
> It conflicts with my beliefs about how an end-to-end crypto solution
> should work.  Its not a solution, its a kludge and I'd much rather
> address the *real* problem.
> 
> The server is completely untrusted.  Much too much of my personal data
> is on other's servers already.  Organizations or people, who 
> might have
> different priorities in protecting it than I have.   Thats why I use
> end-to-end encryption when it matters.
> 
> If people say, adressing the real problem would require 
> influencing the
> senders behaviour, and we can't do that, and so we need a work-around
> now -- fine.  I can understand that.  But still, shouldn't that prompt
> us to think about wether we *need* to be able to influence the senders
> behaviour in more ways than we can now?
> 
> 
> P.S. Regarding IMAP and message sizes:  If I get an encrypted message,
> the size of the attachment *is* the message size.  That decryption
> yields a different size doesn't matter because it occurs on 
> the client,
> after download.
> 
> Regards
> 
> -- 
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GDu7te072374; Wed, 16 Mar 2005 05:56:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GDu7mU072373; Wed, 16 Mar 2005 05:56:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx1.ciphirelabs.net (mx1.ciphirelabs.net [217.72.114.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GDu5bO072349 for <[e-mail]>; Wed, 16 Mar 2005 05:56:07 -0800 (PST) (envelope-from [e-mail])
Received: from dejavu.usr.sek.int.muc.leogic.com (ciphirelabs.net [217.72.114.248]) by mx1.ciphirelabs.net (Postfix) with ESMTP id 37766CA4114; Wed, 16 Mar 2005 13:56:02 +0000 (UTC)
Received: by dejavu.ciphirelabs.com with esmtp (Exim 3.35 #1 (Debian)) id 1DBZ0B-0004sR-00; Wed, 16 Mar 2005 14:55:59 +0100
Date: Wed, 16 Mar 2005 14:55:59 +0100
From: Lars Eilebrecht <[e-mail]>
To: Ingo Luetkebohle <[e-mail]>
Cc: Jon Callas <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: Split Implementations of PGP
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <r02010400-1038-120DB24D92BE11D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

According to Ingo:

> P.S. Regarding IMAP and message sizes:  If I get an encrypted message,
> the size of the attachment *is* the message size.  That decryption
> yields a different size doesn't matter because it occurs on the client,
> after download.

I assume Jon is talking about on-the-fly decryption of incoming
messages, i.e., when the decryption happens before the data hits
the MUA?  A MUA usually includes the size of an 'object' in a
request and only expect that many bytes in the response. However,
the size after decryption is almost always different.
IMHO, this is not directly an issue with IMAP, but with the
actual implementation/interpretation of IMAP. 
The message size handling is just one of the issues with IMAP ...
e.g., think about bodystructure requests and on-the-fly decryption.

But I have to admit that I'm not sure what this has to do with
the original topic of this thread? :-)

ciao...
-- 
Lars Eilebrecht
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GDEklA065377; Wed, 16 Mar 2005 05:14:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2GDEkCh065376; Wed, 16 Mar 2005 05:14:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2GDEiRh065355 for <[e-mail]>; Wed, 16 Mar 2005 05:14:44 -0800 (PST) (envelope-from [e-mail])
Received: from chagall.TechFak.Uni-Bielefeld.DE (chagall.TechFak.Uni-Bielefeld.DE [129.70.139.44]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/03/01/sjaenick) with ESMTP id j2GDELpp018902 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 16 Mar 2005 14:14:23 +0100 (MET)
Subject: Re: Split Implementations of PGP
From: Ingo Luetkebohle <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
References: <r02010400-1038-120DB24D92BE11D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 16 Mar 2005 14:14:21 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.0 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Am Mittwoch, den 16.03.2005, 01:46 -0800 schrieb Jon Callas:
> Something that would help those of us doing crypto and IMAP would be 
> for IMAP to be less fussy about message size.

[...]

It would be very usefull, for me at least, if you could re-state your
use-case here.  I'm getting the impression that I'm missing something
fundamental.

I'm always reading about server-side decryption.  Some people seem to
see it as a solution for the "one big chunk of ciphertext" problem.  I'm
not sure what else it would be good for.

For me, server-side decryption is a nightmare.  Pure and evil.  

It conflicts with my beliefs about how an end-to-end crypto solution
should work.  Its not a solution, its a kludge and I'd much rather
address the *real* problem.

The server is completely untrusted.  Much too much of my personal data
is on other's servers already.  Organizations or people, who might have
different priorities in protecting it than I have.   Thats why I use
end-to-end encryption when it matters.

If people say, adressing the real problem would require influencing the
senders behaviour, and we can't do that, and so we need a work-around
now -- fine.  I can understand that.  But still, shouldn't that prompt
us to think about wether we *need* to be able to influence the senders
behaviour in more ways than we can now?


P.S. Regarding IMAP and message sizes:  If I get an encrypted message,
the size of the attachment *is* the message size.  That decryption
yields a different size doesn't matter because it occurs on the client,
after download.

Regards

-- 
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2G9jaBD092528; Wed, 16 Mar 2005 01:45:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2G9jaT3092527; Wed, 16 Mar 2005 01:45:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2G9jZ7k092513 for <[e-mail]>; Wed, 16 Mar 2005 01:45:35 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for <[e-mail]>; Wed, 16 Mar 2005 01:45:29 -0800
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Wed, 16 Mar 2005 01:45:29 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 16 Mar 2005 01:45:29 -0800
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <r02010400-1038-120DB24D92BE11D9AA730030658F0F64@[192.168.1.5]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: Split Implementations of PGP
Date: Wed, 16 Mar 2005 01:46:37 -0800
To: OpenPGP <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Something that would help those of us doing crypto and IMAP would be 
for IMAP to be less fussy about message size.

We have the problem that while SMTP and POP consider size information 
about a message to be advisory, IMAP considers it to be definitive. 
When you have a message that is compressed, encrypted, signed, base64 
encoded, put into quoted-printable, etc., it can be very hard to answer 
the question, "How big is that message?" definitively.

While POP, for example, will accept the answer "Um, around 15K" and 
copes just fine with the real answer being either 3K or 50K, IMAP does 
not. The IMAP client will expect the size reported to be accurate down 
to the byte. If there is more, the client will never ask for it, and if 
there's less, the client hyperventilates and breaks down sobbing.

If there is anything that further work on IMAP, be it Lemonade, or 
anything else does that could help security, it would be to break 
IMAP's prissiness about message length. The main advantage that this 
sesson-key decrypting protocol has is that it exposes the server to 
relatively little of the actual plaintext. However, while this is a 
theoretic benefit, the practical benefit is lessened by the length 
requirements.

Let's suppose I connect to my server and have ten new messages, all of 
which are encrypted, say five with OpenPGP and five with S/MIME. My 
client program is going to display the lengths of the messages, but 
that isn't knowable without decrypting them. So immediately with the 
headers, all ten of those messages have to be decrypted and processed 
so that the lengths will be accurate. This slows the system down, 
because it requires a complete round-trip of session key decryption for 
each message as well as preliminary processing of the message on the 
server. If that client program is a mobile device, this is especially 
bad because the heavy lifting (the public key crypto) is being done on 
the light device, and the easy lifting (the bulk crypto processing) is 
being done on the powerful device. What happens is that this 
architecture maximally slows the email processing down, with relatively 
low security gains, because the server has gotten the session key for 
all ten messages, even though I've read exactly zero of them.

I'd like to see a change to IMAP that allows for the message's length 
to be advisory until it's actually read. It's relatively easy to do -- 
you have to have a way to ask the server simply, "Is there more?" as 
well as the server to be able to return a short (even zero-length) glob 
of message text.

This gives a slightly counter-intuitive display on the client. I might 
look at a list of messages and see that one is 8K long, and when I read 
that message its length updates to 13K. But in return, we'd be able to 
defer the cryptography to when a message is actually read, rather than 
when it enters my inbox.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2G0f6Vb076139; Tue, 15 Mar 2005 16:41:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2G0f6vo076138; Tue, 15 Mar 2005 16:41:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2G0f5dM076131 for <[e-mail]>; Tue, 15 Mar 2005 16:41:05 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id E95FB33C45; Wed, 16 Mar 2005 00:41:03 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 16 Mar 2005 00:41:04 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
Cc: Ingo Luetkebohle <[e-mail]>, [e-mail], Cyrus Daboo <[e-mail]>, Eric Burger <[e-mail]>
Subject: Re: Split Implementations of PGP
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:
> 
> On 12 Mar 2005, at 3:24 AM, Ingo Luetkebohle wrote:
> 
>> Even better would be to have individually encrypted parts.  This is
>> possible with PGP/MIME but not current practice.  Trouble being, of
>> course, that the sender would have to know this is in advance.
>>
> 
> Better for whom?
> 
> One of the reasons that practice is to not have individually encrypted 
> parts is that that has not been considered as good, meaning not as 
> secure. It isn't as convenient for an entity who doesn't have the keys 
> to process such a message, and that's been considered a feature rather 
> than a bug.

I'm struggling to understand this - how does this make it any easier for 
an attacker? (Other than log_2(n), where n is the number of parts, for 
the brute force attack).

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2FNdNfo071071; Tue, 15 Mar 2005 15:39:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2FNdNDN071070; Tue, 15 Mar 2005 15:39:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-relay1.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2FNdL0a071062 for <[e-mail]>; Tue, 15 Mar 2005 15:39:21 -0800 (PST) (envelope-from [e-mail])
Received: from pmxchannel-daemon.mail1.hrz.uni-bielefeld.de by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) id <[e-mail]> for [e-mail]; Wed, 16 Mar 2005 00:39:20 +0100 (MET)
Received: from DINAFSC.dhcp.lcl.studentenwerk-bielefeld.de (DINAFSC.dhcp.lcl.studentenwerk-bielefeld.de [10.128.53.38]) by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPS id <[e-mail]>; Wed, 16 Mar 2005 00:39:19 +0100 (MET)
Date: Wed, 16 Mar 2005 00:39:37 +0100
From: Ingo Luetkebohle <[e-mail]>
Subject: Re: Split Implementations of PGP
In-reply-to: <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: [e-mail], Cyrus Daboo <[e-mail]>, Eric Burger <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Evolution 2.0.2
Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uY1zi1JcW4FR5eDTVwcZ"
X-Spam-Level: 
X-UniBi-Spam-Level: , 7%
X-UniBi-Spam-Rules: __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __SANE_MSGID 0
X-UniBi-Deliver: Tag
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.15.16, vscan4.hrz.uni-bielefeld.de
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=-uY1zi1JcW4FR5eDTVwcZ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Am Dienstag, den 15.03.2005, 12:12 -0800 schrieb Jon Callas:
> Better for whom?

Better for a recipient who, for whatever reasons, does not want to
transfer the whole for decryption.

> One of the reasons that practice is to not have individually encrypted=20
> parts is that that has not been considered as good, meaning not as=20
> secure. It isn't as convenient for an entity who doesn't have the keys=20
> to process such a message, and that's been considered a feature rather=20
> than a bug.

I concur -- for the usual case.  However, whats better in the case under
discussion:  Decrypting the full thing on a machine not under your
control and then transferring only what you can afford, or transfer it
(encrypted) and decrypt it on the local machine (mobile device)?  For
this case, I'd say the latter is preferable.  Maybe I'm paranoid about
server security but isn't that why we're using PGP-based end-to-end
encryption?

regards

Ingo

--=-uY1zi1JcW4FR5eDTVwcZ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCN3I5zZDBZDStzlsRAo2/AKCQVqRBqXMtnZ19c+Ny+4WZeOnbEQCeP3AG
1P7u0dq7GISTF/kb1jwx8CA=
=Cc26
-----END PGP SIGNATURE-----

--=-uY1zi1JcW4FR5eDTVwcZ--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2FKBeoD050690; Tue, 15 Mar 2005 12:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2FKBea2050688; Tue, 15 Mar 2005 12:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2FKBbH6050675 for <[e-mail]>; Tue, 15 Mar 2005 12:11:37 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Tue, 15 Mar 2005 12:11:35 -0800
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Tue, 15 Mar 2005 12:11:35 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 15 Mar 2005 12:11:35 -0800
In-Reply-To: <[e-mail]>
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail], Cyrus Daboo <[e-mail]>, Eric Burger <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Split Implementations of PGP
Date: Tue, 15 Mar 2005 12:12:33 -0800
To: Ingo Luetkebohle <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 12 Mar 2005, at 3:24 AM, Ingo Luetkebohle wrote:

> Even better would be to have individually encrypted parts.  This is
> possible with PGP/MIME but not current practice.  Trouble being, of
> course, that the sender would have to know this is in advance.
>

Better for whom?

One of the reasons that practice is to not have individually encrypted 
parts is that that has not been considered as good, meaning not as 
secure. It isn't as convenient for an entity who doesn't have the keys 
to process such a message, and that's been considered a feature rather 
than a bug.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2F8NmfE010022; Tue, 15 Mar 2005 00:23:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2F8Nm10010021; Tue, 15 Mar 2005 00:23:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2F8Ne0h009963 for <[e-mail]>; Tue, 15 Mar 2005 00:23:47 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 89FE5350A4; Tue, 15 Mar 2005 21:23:39 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26116-03; Tue, 15 Mar 2005 21:23:39 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id B095834C7C; Tue, 15 Mar 2005 21:23:37 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A79683774B; Tue, 15 Mar 2005 21:23:37 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DB7L6-0003PA-00; Tue, 15 Mar 2005 21:23:44 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Split Implementations of PGP
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 15 Mar 2005 21:23:44 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Eric Burger <[e-mail]> writes:

>The problem is that the client does not want to download the object at all,
>either because they only want to look at a particular body part and the
>entire message is encrypted (Cyrus' example) or they wish to forward the
>message without downloading it to their client.

You don't download it, the server sends out the RSA/Elgamal-encrypted message
encryption key (MEK) from the message (and nothing else) and the client
returns the MEK re-encrypted with the server's public key.  This works with
anything (including for example crypto hardware like smart cards that won't
reveal a key), has minimal messaging overhead, and doesn't require any
additional security measures to protect the MEK.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DMUceb076270; Sun, 13 Mar 2005 14:30:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2DMUcOg076269; Sun, 13 Mar 2005 14:30:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from salvelinus.brooktrout.com (salvelinus.brooktrout.com [204.176.205.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DMUX8X076228 for <[e-mail]>; Sun, 13 Mar 2005 14:30:33 -0800 (PST) (envelope-from [e-mail])
Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j2DMSHDL008690; Sun, 13 Mar 2005 17:28:17 -0500 (EST)
Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id <GZABLBC5>; Sun, 13 Mar 2005 17:24:18 -0500
Message-ID: <[e-mail]>
From: Eric Burger <[e-mail]>
To: Ingo Luetkebohle <[e-mail]>
Cc: [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>, "Stephane Maes (E-mail)" <[e-mail]>
Subject: RE: Split Implementations of PGP
Date: Sun, 13 Mar 2005 17:24:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

The problem is we cannot change sender behavior.  If we could, we would
simply say, "Send the message encrypted with both the client's and IMAP
server's key."  That way, the server already would be a recipient.

I do like the idea of being a model of good behavior.  We should put that
into the lemonade profile.

> -----Original Message-----
> From: Ingo Luetkebohle [mailto:[e-mail]]
> Sent: Saturday, March 12, 2005 6:25 AM
> To: Cyrus Daboo
> Cc: [e-mail]; Eric Burger
> Subject: Re: Split Implementations of PGP
> 
> 
> Am Freitag, den 11.03.2005, 22:08 -0500 schrieb Cyrus Daboo:
> > A better solution would be to have the message decrypted on 
> the server and 
> > stored in its unencrypted form with multiple parts - then 
> the client can 
> > fetch just the text.
> 
> Even better would be to have individually encrypted parts.  This is
> possible with PGP/MIME but not current practice.  Trouble being, of
> course, that the sender would have to know this is in advance.  
> 
> It is one more example of the sender having to know what the receiver
> requires without a good means of finding out.
> 
> So far, these things have been mere nuisances but the 
> suggested solution
> is clearly a big step down in security.  I do not know an 
> answer but it
> might be interesting to think about the bigger picture for 
> once and come
> up with something this simple, yet flexible enough.
> 
> In any case, I would suggest for implementors of the server-based
> decryption to re-format the message into multiple 
> individually encrypted
> parts instead of just storing decrypted messages -- smaller window of
> attack.
> 
> Ingo
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DMUPUq076203; Sun, 13 Mar 2005 14:30:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2DMUPQc076202; Sun, 13 Mar 2005 14:30:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from salvelinus.brooktrout.com (salvelinus.brooktrout.com [204.176.205.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2DMUOlZ076192 for <[e-mail]>; Sun, 13 Mar 2005 14:30:24 -0800 (PST) (envelope-from [e-mail])
Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j2DMSFDL008689; Sun, 13 Mar 2005 17:28:19 -0500 (EST)
Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id <GZABLBCZ>; Sun, 13 Mar 2005 17:24:16 -0500
Message-ID: <[e-mail]>
From: Eric Burger <[e-mail]>
To: pgut001 <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Split Implementations of PGP
Date: Sun, 13 Mar 2005 17:24:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

The problem is that the client does not want to download the object at all,
either because they only want to look at a particular body part and the
entire message is encrypted (Cyrus' example) or they wish to forward the
message without downloading it to their client.


> -----Original Message-----
> From: pgut001 [mailto:[e-mail]]
> Sent: Saturday, March 12, 2005 10:34 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: Split Implementations of PGP
> 
> 
> Eric Burger <[e-mail]> writes:
> 
> >So, the question is, are there implementations of PGP where one can:
> >1. Extract the encrypted session key from the PGP-encrypted object
> >2. An API for handing over the encrypted session key and the 
> client key,
> >returning the clear session key (this would run on the 
> remote client).
> >3. An API that takes the clear session key and the 
> PGP-encrypted object and
> >returns the cleartext object.
> 
> Why not have the client decrypt the session key, re-encrypt 
> it with the
> server's public key, and send it back?  Any version of PGP 
> supports this, and
> it solves the difficult problem of "an API for [...] the 
> client returning the
> session key".
> 
> Peter.
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2D3XwjC070987; Sat, 12 Mar 2005 19:33:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2D3Xwrl070986; Sat, 12 Mar 2005 19:33:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2D3XqdP070976 for <[e-mail]>; Sat, 12 Mar 2005 19:33:53 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 3558B34C13; Sun, 13 Mar 2005 16:33:50 +1300 (NZDT)
Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28301-17; Sun, 13 Mar 2005 16:33:50 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 4C148349A2; Sun, 13 Mar 2005 16:33:48 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 1143A37743; Sun, 13 Mar 2005 16:33:48 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DAJrU-0008W0-00; Sun, 13 Mar 2005 16:33:52 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Split Implementations of PGP
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Sun, 13 Mar 2005 16:33:52 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Eric Burger <[e-mail]> writes:

>So, the question is, are there implementations of PGP where one can:
>1. Extract the encrypted session key from the PGP-encrypted object
>2. An API for handing over the encrypted session key and the client key,
>returning the clear session key (this would run on the remote client).
>3. An API that takes the clear session key and the PGP-encrypted object and
>returns the cleartext object.

Why not have the client decrypt the session key, re-encrypt it with the
server's public key, and send it back?  Any version of PGP supports this, and
it solves the difficult problem of "an API for [...] the client returning the
session key".

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2CE8eim045475; Sat, 12 Mar 2005 06:08:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2CE8d52045474; Sat, 12 Mar 2005 06:08:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2CE8N4A045448 for <[e-mail]>; Sat, 12 Mar 2005 06:08:28 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2CDtI6g000710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Mar 2005 08:55:19 -0500
Date: Sat, 12 Mar 2005 09:08:11 -0500
From: Cyrus Daboo <[e-mail]>
To: Bill Frantz <[e-mail]>
cc: Eric Burger <[e-mail]>, [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
Subject: Re: Split Implementations of PGP
Message-ID: <[e-mail]>
In-Reply-To: <r02010400-1038-120DB24D92BE11D9AA730030658F0F64@[192.168.1.5]>
References:  <r02010400-1038-120DB24D92BE11D9AA730030658F0F64@[192.168.1.5]>
X-Mailer: Mulberry/3.2.0a1 (Linux/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi Bill,

--On Friday, March 11, 2005 10:15:01 PM -0800 Bill Frantz 
<[e-mail]> wrote:

> Thanks for the clear explanation.  While perhaps out of scope here, I
> certainly hope that the link between the client and the IMAP server is
> secured.  The idea of a message that the sender thought needed to be
> encrypted, being sent out in the clear, over a cell phone transmitter, is
> a bit disquieting.

Agreed, TLS or mobile equivalent would have to be used. In addition you 
also have to have more trust in your server (or more accurately your server 
admin or whoever has 'root' access to the server) as a clear-text version 
of the message will be stored there, even if only on a temporary basis.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2CBTdsI099153; Sat, 12 Mar 2005 03:29:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2CBTdFf099152; Sat, 12 Mar 2005 03:29:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-relay1.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2CBTPg9099048 for <[e-mail]>; Sat, 12 Mar 2005 03:29:30 -0800 (PST) (envelope-from [e-mail])
Received: from pmxchannel-daemon.mail1.hrz.uni-bielefeld.de by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) id <[e-mail]> for [e-mail]; Sat, 12 Mar 2005 12:24:26 +0100 (MET)
Received: from Laptop-udp4452615uds.dhcp.lcl.studentenwerk-bielefeld.de (Laptop-udp4452615uds.dhcp.lcl.studentenwerk-bielefeld.de [10.128.53.9]) by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPS id <[e-mail]>; Sat, 12 Mar 2005 12:24:26 +0100 (MET)
Date: Sat, 12 Mar 2005 12:24:50 +0100
From: Ingo Luetkebohle <[e-mail]>
Subject: Re: Split Implementations of PGP
In-reply-to: <[e-mail]>
To: Cyrus Daboo <[e-mail]>
Cc: [e-mail], Eric Burger <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Evolution 2.0.2
Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lwj993Gubp9qj1/CfkJO"
X-Spam-Level: 
X-UniBi-Spam-Level: , 7%
X-UniBi-Spam-Rules: __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __SANE_MSGID 0, __cbl.abuseat.org_TIMEOUT , __dnsbl.njabl.org_TIMEOUT , __query.bondedsender.org_TIMEOUT , __sbl.spamhaus.org_TIMEOUT
X-UniBi-Deliver: Tag
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.3.12.3, vscan2.hrz.uni-bielefeld.de
References: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=-lwj993Gubp9qj1/CfkJO
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Am Freitag, den 11.03.2005, 22:08 -0500 schrieb Cyrus Daboo:
> A better solution would be to have the message decrypted on the server an=
d=20
> stored in its unencrypted form with multiple parts - then the client can=20
> fetch just the text.

Even better would be to have individually encrypted parts.  This is
possible with PGP/MIME but not current practice.  Trouble being, of
course, that the sender would have to know this is in advance. =20

It is one more example of the sender having to know what the receiver
requires without a good means of finding out.

So far, these things have been mere nuisances but the suggested solution
is clearly a big step down in security.  I do not know an answer but it
might be interesting to think about the bigger picture for once and come
up with something this simple, yet flexible enough.

In any case, I would suggest for implementors of the server-based
decryption to re-format the message into multiple individually encrypted
parts instead of just storing decrypted messages -- smaller window of
attack.

Ingo

--=-lwj993Gubp9qj1/CfkJO
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCMtGCzZDBZDStzlsRAo+KAJ9xGRWn170t0tvgVrQjzk/ip11SsACdG98T
dwKWDBS8Ni6HTPfLcs37Tok=
=KHoK
-----END PGP SIGNATURE-----

--=-lwj993Gubp9qj1/CfkJO--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2C6FLnG076150; Fri, 11 Mar 2005 22:15:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2C6FLgx076149; Fri, 11 Mar 2005 22:15:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpauth04.mail.atl.earthlink.net (smtpauth04.mail.atl.earthlink.net [209.86.89.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2C6F5XI076014 for <[e-mail]>; Fri, 11 Mar 2005 22:15:10 -0800 (PST) (envelope-from [e-mail])
Received: from [68.164.80.103] (helo=[192.168.1.5]) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1D9ztw-00055x-CS; Sat, 12 Mar 2005 01:15:04 -0500
Date: Fri, 11 Mar 2005 22:15:01 -0800
From: Bill Frantz <[e-mail]>
Subject: Re: Split Implementations of PGP
To: Cyrus Daboo <[e-mail]>
cc: Eric Burger <[e-mail]>, [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
X-Priority: 3
In-Reply-To: <[e-mail]>
Message-ID: <r02010400-1038-120DB24D92BE11D9AA730030658F0F64@[192.168.1.5]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Mailer: Mailsmith 2.1.4 (Blindsider)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7965b52aa7ef358aea37a175cf150b07dc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.164.80.103
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2C6FAXI076055
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 3/11/05, [e-mail] (Cyrus Daboo) wrote:

>Consider the case of a message with a small text part and a large 
>attachment. On your mobile device you might want to only read the text 
>without paying the penalty of downloading the attachment. If the message 
>data is unencrypted the client can use the IMAP protocol to download only 
>the text part. However, if the message is encrypted in one single 
>multipart/encrypted part, then the client has to download all the data in 
>order to decrypt and extract only the text.
>
>...

Thanks for the clear explanation.  While perhaps out of scope here, I certainly hope that the link between the client and the IMAP server is secured.  The idea of a message that the sender thought needed to be encrypted, being sent out in the clear, over a cell phone transmitter, is a bit disquieting.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle 
[phone]      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2C38qq7054762; Fri, 11 Mar 2005 19:08:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2C38qK8054761; Fri, 11 Mar 2005 19:08:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2C38aZP054715 for <[e-mail]>; Fri, 11 Mar 2005 19:08:40 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j2C2tY6g022357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Mar 2005 21:55:35 -0500
Date: Fri, 11 Mar 2005 22:08:23 -0500
From: Cyrus Daboo <[e-mail]>
To: Bill Frantz <[e-mail]>, Eric Burger <[e-mail]>
cc: [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
Subject: Re: Split Implementations of PGP
Message-ID: <[e-mail]>
In-Reply-To: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]>
References:  <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]>
X-Mailer: Mulberry/3.2.0a1 (Linux/PPC)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=0.0 tests=none
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi Bill,

--On Friday, March 11, 2005 05:15:02 PM -0800 Bill Frantz 
<[e-mail]> wrote:

> I understand, from Derek's draft minutes of the OpenPGP meeting, that the
> problem is that the remote client is in a low-bandwidth environment, such
> as a cell phone.  I understand this statement to mean that the
> communication link is low bandwidth.  However, PGP encrypted messages are
> close to the size of the corrisponding plain text, so I don't see how
> having an IMAP server decrypt the message is going to help.
>
> If, on another hand, the remote client is limited in CPU power, this
> system seems to place the largest CPU load, the public key operation to
> extract the plain text key, on the client, and the relatively low CPU
> load of the private key operations to decrypt the message on the IMAP
> server.
>
> I conclude from this reasoning that I don't understand the problem.
> Could you please explain.

Consider the case of a message with a small text part and a large 
attachment. On your mobile device you might want to only read the text 
without paying the penalty of downloading the attachment. If the message 
data is unencrypted the client can use the IMAP protocol to download only 
the text part. However, if the message is encrypted in one single 
multipart/encrypted part, then the client has to download all the data in 
order to decrypt and extract only the text.

A better solution would be to have the message decrypted on the server and 
stored in its unencrypted form with multiple parts - then the client can 
fetch just the text.

Same principal applies for a message that is only signed, and the mobile 
device wants to read only the text part, but verify the signature.

There are similar considerations for the client when it wants to create a 
signed or encrypted message with parts that already reside on the server.

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2C1FFWK047418; Fri, 11 Mar 2005 17:15:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2C1FFvC047417; Fri, 11 Mar 2005 17:15:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpauth07.mail.atl.earthlink.net (smtpauth07.mail.atl.earthlink.net [209.86.89.67]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2C1F5rm047406 for <[e-mail]>; Fri, 11 Mar 2005 17:15:10 -0800 (PST) (envelope-from [e-mail])
Received: from [68.164.80.103] (helo=[192.168.1.5]) by smtpauth07.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1D9vDc-0000vN-W1; Fri, 11 Mar 2005 20:15:05 -0500
Date: Fri, 11 Mar 2005 17:15:02 -0800
From: Bill Frantz <[e-mail]>
Subject: Re: Split Implementations of PGP
To: Eric Burger <[e-mail]>
cc: [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
X-Priority: 3
In-Reply-To: <[e-mail]>
Message-ID: <r02010400-1038-29AD9710929411D9AA730030658F0F64@[192.168.1.5]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Mailer: Mailsmith 2.1.4 (Blindsider)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7951e3a6a0e794d4215a372228129949b6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.164.80.103
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j2C1FArm047408
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 3/11/05, [e-mail] (Eric Burger) wrote:

>
>Background:
>I am a co-chair of the lemonade work group in the IETF
><http://www.ietf.org/html.charters/lemonade-charter.html>.
>
>One thing we would like to do is enable a remote client to fetch the
>encrypted session key from an IMAP server, decrypt the key using the
>client's key, and then handing back the clear session key to the IMAP server
>to decrypt or verify a message or body part.

I understand, from Derek's draft minutes of the OpenPGP meeting, that the problem is that the remote client is in a low-bandwidth environment, such as a cell phone.  I understand this statement to mean that the communication link is low bandwidth.  However, PGP encrypted messages are close to the size of the corrisponding plain text, so I don't see how having an IMAP server decrypt the message is going to help.

If, on another hand, the remote client is limited in CPU power, this system seems to place the largest CPU load, the public key operation to extract the plain text key, on the client, and the relatively low CPU load of the private key operations to decrypt the message on the IMAP server.

I conclude from this reasoning that I don't understand the problem.  Could you please explain.

Thanks - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle 
[phone]      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2C05XMN040100; Fri, 11 Mar 2005 16:05:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2C05XSC040097; Fri, 11 Mar 2005 16:05:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2C05PM2040086 for <[e-mail]>; Fri, 11 Mar 2005 16:05:25 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Fri, 11 Mar 2005 16:05:20 -0800
Received: from [192.168.2.164] ([63.251.255.85]) by keys.merrymeet.com (PGP Universal service); Fri, 11 Mar 2005 16:05:19 -0800
X-PGP-Universal: processed
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Split Implementations of PGP
Date: Fri, 11 Mar 2005 16:06:21 -0800
To: Eric Burger <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

We can also do this at PGP Corporation, as well. Not a problem.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BIX76H016282; Fri, 11 Mar 2005 10:33:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2BIX7qU016281; Fri, 11 Mar 2005 10:33:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BIX6wE016271 for <[e-mail]>; Fri, 11 Mar 2005 10:33:06 -0800 (PST) (envelope-from [e-mail])
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005031118325901300okov5e>; Fri, 11 Mar 2005 18:32:59 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j2BIWxsh003314; Fri, 11 Mar 2005 13:32:59 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j2BIWupK024508; Fri, 11 Mar 2005 13:32:56 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j2BIWurh024507; Fri, 11 Mar 2005 13:32:56 -0500
Date: Fri, 11 Mar 2005 13:32:56 -0500
From: David Shaw <[e-mail]>
To: Eric Burger <[e-mail]>
Cc: [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
Subject: Re: Split Implementations of PGP
Message-ID: <[e-mail]>
Mail-Followup-To: Eric Burger <[e-mail]>, [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Mar 11, 2005 at 12:04:59PM -0500, Eric Burger wrote:
> 
> Background:
> I am a co-chair of the lemonade work group in the IETF
> <http://www.ietf.org/html.charters/lemonade-charter.html>.
> 
> One thing we would like to do is enable a remote client to fetch the
> encrypted session key from an IMAP server, decrypt the key using the
> client's key, and then handing back the clear session key to the IMAP server
> to decrypt or verify a message or body part.
> 
> So, the question is, are there implementations of PGP where one can:
> 1. Extract the encrypted session key from the PGP-encrypted object
> 2. An API for handing over the encrypted session key and the client key,
> returning the clear session key (this would run on the remote client).
> 3. An API that takes the clear session key and the PGP-encrypted object and
> returns the cleartext object.
> 
> Note that this is different from the normal case of an API that takes the
> client's key and the PGP-encrypted object and simply returns the cleartext
> object.

GnuPG can do this.  The feature was originally intended as a
workaround for places that have laws about compelled production of
keys, but it can be used for what you discuss.

David



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BIKW89015220; Fri, 11 Mar 2005 10:20:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2BIKWfD015219; Fri, 11 Mar 2005 10:20:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BIKQRS015181 for <[e-mail]>; Fri, 11 Mar 2005 10:20:31 -0800 (PST) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D9odA-0004KR-Lq for <[e-mail]>; Fri, 11 Mar 2005 19:13:00 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D9ogr-0001Gv-8J; Fri, 11 Mar 2005 19:16:49 +0100
To: Eric Burger <[e-mail]>
Cc: [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
Subject: Re: Split Implementations of PGP
References: <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Fri, 11 Mar 2005 19:16:49 +0100
In-Reply-To: <[e-mail]> (Eric Burger's message of "Fri, 11 Mar 2005 12:04:59 -0500")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, 11 Mar 2005 12:04:59 -0500, Eric Burger said:

> So, the question is, are there implementations of PGP where one can:
> 1. Extract the encrypted session key from the PGP-encrypted object
> 2. An API for handing over the encrypted session key and the client key,
> returning the clear session key (this would run on the remote client).
> 3. An API that takes the clear session key and the PGP-encrypted object and
> returns the cleartext object.

GnuPG provides this for many years.

    SESSION_KEY  <algo>:<hexdigits>
	The session key used to decrypt the message.  This message will
	only be emitted when the special option --show-session-key
	is used.  The format is suitable to be passed to the option
	--override-session-key

Use it together with --status-fd n.


Shalom-Salam,

   Werner



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BHuXGB013098; Fri, 11 Mar 2005 09:56:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2BHuXi9013097; Fri, 11 Mar 2005 09:56:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BHuSlB013062 for <[e-mail]>; Fri, 11 Mar 2005 09:56:28 -0800 (PST) (envelope-from [e-mail])
Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7A5C033C33; Fri, 11 Mar 2005 17:56:16 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Fri, 11 Mar 2005 16:55:53 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050106)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eric Burger <[e-mail]>
Cc: [e-mail], "Glenn Parsons (E-mail)" <[e-mail]>
Subject: Re: Split Implementations of PGP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Eric Burger wrote:
> Background:
> I am a co-chair of the lemonade work group in the IETF
> <http://www.ietf.org/html.charters/lemonade-charter.html>.
> 
> One thing we would like to do is enable a remote client to fetch the
> encrypted session key from an IMAP server, decrypt the key using the
> client's key, and then handing back the clear session key to the IMAP server
> to decrypt or verify a message or body part.
> 
> So, the question is, are there implementations of PGP where one can:
> 1. Extract the encrypted session key from the PGP-encrypted object
> 2. An API for handing over the encrypted session key and the client key,
> returning the clear session key (this would run on the remote client).
> 3. An API that takes the clear session key and the PGP-encrypted object and
> returns the cleartext object.
> 
> Note that this is different from the normal case of an API that takes the
> client's key and the PGP-encrypted object and simply returns the cleartext
> object.
> 
> We have heard from the S/MIME community that there are API's that allow this
> functionality over S/MIME.

I am currently working on an implementation that could easily include 
this functionality. Feel free to nag me about it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BHBJK3008298; Fri, 11 Mar 2005 09:11:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2BHBJE1008297; Fri, 11 Mar 2005 09:11:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from salvelinus.brooktrout.com (salvelinus.brooktrout.com [204.176.205.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2BHBIYj008288 for <[e-mail]>; Fri, 11 Mar 2005 09:11:18 -0800 (PST) (envelope-from [e-mail])
Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j2BH97H0012311; Fri, 11 Mar 2005 12:09:07 -0500 (EST)
Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id <FRSFG83M>; Fri, 11 Mar 2005 12:05:08 -0500
Message-ID: <[e-mail]>
From: Eric Burger <[e-mail]>
To: [e-mail]
Cc: "Glenn Parsons (E-mail)" <[e-mail]>
Subject: Split Implementations of PGP
Date: Fri, 11 Mar 2005 12:04:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Background:
I am a co-chair of the lemonade work group in the IETF
<http://www.ietf.org/html.charters/lemonade-charter.html>.

One thing we would like to do is enable a remote client to fetch the
encrypted session key from an IMAP server, decrypt the key using the
client's key, and then handing back the clear session key to the IMAP server
to decrypt or verify a message or body part.

So, the question is, are there implementations of PGP where one can:
1. Extract the encrypted session key from the PGP-encrypted object
2. An API for handing over the encrypted session key and the client key,
returning the clear session key (this would run on the remote client).
3. An API that takes the clear session key and the PGP-encrypted object and
returns the cleartext object.

Note that this is different from the normal case of an API that takes the
client's key and the PGP-encrypted object and simply returns the cleartext
object.

We have heard from the S/MIME community that there are API's that allow this
functionality over S/MIME.

Thanks.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2AHAXYn040895; Thu, 10 Mar 2005 09:10:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j2AHAXrc040894; Thu, 10 Mar 2005 09:10:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from dogbert.ihtfp.org ([e-mail] [130.129.134.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2AHAOKL040876 for <[e-mail]>; Thu, 10 Mar 2005 09:10:24 -0800 (PST) (envelope-from [e-mail])
Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id j2AHANBa003198; Thu, 10 Mar 2005 12:10:23 -0500
From: Derek Atkins <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Draft Minutes of OpenPGP Meeting
Date: Thu, 10 Mar 2005 12:10:23 -0500
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=-=-=

Here are the draft minutes of the (short) OpenPGP Meeting here in
Minneapolis.

-derek


--=-=-=
Content-Disposition: attachment; filename=ietf-62-minutes.txt
Content-Description: OpenPGP Minutes

Open PGP Minutes

- Chair Derek Atkins
- Tues March 8 2005

1.  Agenda Bashing - none

2.  AD - Sam Hartman - 

Sam requested time on the agenda to discuss a proposed new work item for this working group.  The Lemonade group is looking at doing e-mail type operations in some new service environments.  One type of environment that they are looking at is low bandwidth devices (such as cell phones) where different types of operations might be desirable.  Examples of such operations might be to distill or use incremental download of messages for display on the device. 

Currently the issues of end-to-end security have been avoided by the Lemonade group.  Open PGP and S/MIME are the two different secure messaging work groups in the IETF and the Lemonade group would like to get guidance and help from the two groups about different ways of providing end-to-end security within the lightweight receivers.

One possible method of dealing with the problem is to require that the server be a recipient on the message.  No desirable in some circumstances because the server cannot be trusted.  A second method is to require the device to deal with secure messages.  This is beyond the capabilities of some devices.  The current method under exploration would be to allow the server to extract a correct encrypted key blob, send it to the device for decryption, and then the server would decrypt the bulk message and process it for display.

Glen Parsons (co-chair of the Lemonade group) stated that in addition guidance was desired on some of the security issues the server would need to deal with.  An example would be how long should a server keep the decrypted message in a cache for processing, as oppose to decrypting the message each time a new section of the document was desired by the display device. 

One proposed method of dealing with this might be to look at the device as a cryptographic module and just implement normal PGP on the server.  This would need to be looked at further.

3.  Draft-ietf-openpgp-rfc2440bis status

The document editor did not provide a presentation for the meeting.  There has not been a recent update of the document, however there has been substantial activity on the list recently which has solve several open issues.  The following open issues still remain:

Editorial type changes that will probably just be accepted by the editor
    - V2 PKESK advice is not correct (Dave Shaw)
    - Call V4 V4 (Dave Shaw)

Two cryptographic issues that need to be looked at:

- CFB "Broken" 
  Researches have presented a break of CFB where about 25% of the message can be obtained using a fairly small work load under some circumstances.  Details of the attack can be found at:

- SHA-1 "Broken"
  There have been several recently announced attacks against SHA-1.  The biggest result was one of lowering the work of finding a duplicate hash from 2^80 to 2^69.  Still a substantial work factor.  Sam stood up and said that the issue will be discussed at the SAAG meeting on Thursday, but the current advice from the ADs is not to panic yet.  They are searching for a unified method of dealing with the problem along with the question of whether the new longer SHA algorithms are going to be affected as well.

3.  PFS - Presenter was not present in the room.


--=-=-=


-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant

--=-=-=--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j23Fwihh030000; Thu, 3 Mar 2005 07:58:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j23FweZa029992; Thu, 3 Mar 2005 07:58:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j23FwdCt029963 for <[e-mail]>; Thu, 3 Mar 2005 07:58:40 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for <[e-mail]>; Thu, 3 Mar 2005 07:58:31 -0800
Received: from [62.8.243.71] ([62.8.243.71]) by keys.merrymeet.com (PGP Universal service); Thu, 03 Mar 2005 07:58:31 -0800
X-PGP-Universal: processed
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
From: Jon Callas <[e-mail]>
Subject: Re: Tighter MPI spec
Date: Thu, 3 Mar 2005 07:59:28 -0800
To: OpenPGP <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 27 Feb 2005, at 2:21 PM, Florian Weimer wrote:

> * Jon Callas:
>
>> This language has been sitting in 2440 and followons since '97. No one
>> has ever had a problem implementing it, no one has had an
>> interoperability issue with bignums. Not PGP, nor GnuPG, nor Hushmail,
>> nor Cryptix, nor Forum, nor Bouncy Castle, nor anyone else.
>
> Not true.  GnuPG had a bug in MPI handling because it followed the
> language in RFC 2440 too verbatim. 8-)
>
> (You added a hint to 2440bis a few years ago, so others hopefully
> won't make the same mistake.)
>

Thanks. Mea culpa.

However, I think with the explicit note that unused bits must be zero, 
we're real clear on it.

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j23FvwdA029874; Thu, 3 Mar 2005 07:57:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j23FvwBw029873; Thu, 3 Mar 2005 07:57:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j23FvraV029839 for <[e-mail]>; Thu, 3 Mar 2005 07:57:53 -0800 (PST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 3 Mar 2005 07:57:41 -0800
Received: from [62.8.243.71] ([62.8.243.71]) by keys.merrymeet.com (PGP Universal service); Thu, 03 Mar 2005 07:57:41 -0800
X-PGP-Universal: processed
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: [ISSUE] Minor language nits
Date: Thu, 3 Mar 2005 07:58:32 -0800
To: David Shaw <[e-mail]>
X-Mailer: Apple Mail (2.619.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 25 Feb 2005, at 12:48 PM, David Shaw wrote:

>
> Three minor language nits:
>
> In section 5.2.3. Version 4 Signature Packet Format:
>
>      - Two-octet scalar octet count for following hashed subpacket
>        data. Note that this is the length in octets of all of the
>        hashed subpackets; a pointer incremented by this number will
>        skip over the hashed subpackets.
>
> There needs to be a "the" between "for" and "following".  Note also
> the same problem one paragraph later for the item discussing the
> unhashed subpacket data.
>

Got them.

> =============================
>
> Throughout the document, references to RFCs are written
> inconsistently.  For example, there are 3 references to "RFC 1991"
> (with the space), and 2 references to "RFC1991" (without the space).
> I like it with the space, though I really don't care which way things
> go so long as it is consistent.  (It's not just 1991 - all the RFC
> references in the draft are mixed between the two styles).
>

Okay, here's what I did. All text referring to an RFC is now "RFC xxxx" 
-- with a space. But a reference in brackets such as [RFCxxxx] has no 
space. That just seemed like the right thing.

> =============================
>
> There are a few spots in the draft where "PGP" is used when "OpenPGP"
> should have been used (when referring to the standard, rather than the
> product):
>
>   Section 2.3 (Compression) has one in the second paragraph.
>

Fixed.

>   Section 5.2.1 (Signature Types) has one in the discussion of the 0x13
>   signature class.
>

Also fixed. There was also one in the 0x10 signature types.

>   Section 5.7 (Symmetrically Encrypted Data Packet) has one when
>   discussing "PGP's variant of Cipher Feedback (CFB) mode".
>
>

I contemplated this for a bit. I finally concluded that both you and my 
lawyer (who is on a Proper Trademark Usage campaign) agree and 
therefore no further thought is needed. :-)

	Jon



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21IZasa028332; Tue, 1 Mar 2005 10:35:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j21IZapb028331; Tue, 1 Mar 2005 10:35:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-relay1.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.97]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21IZZ6O028323 for <[e-mail]>; Tue, 1 Mar 2005 10:35:36 -0800 (PST) (envelope-from [e-mail])
Received: from pmxchannel-daemon.mail1.hrz.uni-bielefeld.de by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) id <[e-mail]> for [e-mail]; Tue, 01 Mar 2005 19:35:25 +0100 (MET)
Received: from vm.dhcp.lcl.studentenwerk-bielefeld.de (vm.dhcp.lcl.studentenwerk-bielefeld.de [10.128.53.60]) by mail1.hrz.uni-bielefeld.de (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPS id <[e-mail]>; Tue, 01 Mar 2005 19:35:19 +0100 (MET)
Date: Tue, 01 Mar 2005 19:36:04 +0100
From: Ingo Luetkebohle <[e-mail]>
Subject: Re: PGP Partitioned Encoding Format
In-reply-to: <[e-mail]>
To: Werner Koch <[e-mail]>
Cc: "\"Hal Finney\"" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Evolution 2.0.2
Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DSG4wfAhWk6maiyAmLnZ"
X-Spam-Level: 
X-UniBi-Spam-Level: , 7%
X-UniBi-Spam-Rules: __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_VERSION 0, __SANE_MSGID 0, __cbl.abuseat.org_TIMEOUT , __dnsbl.njabl.org_TIMEOUT , __query.bondedsender.org_TIMEOUT , __sbl.spamhaus.org_TIMEOUT
X-UniBi-Deliver: Tag
X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.3.1.10
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--=-DSG4wfAhWk6maiyAmLnZ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Am Dienstag, den 01.03.2005, 17:18 +0100 schrieb Werner Koch:
> Won't work either with Outlook.=20

Sorry, I didn't mean to imply it would.  I know that all sorts of
work-arounds have to be done for Outlook.

The only thing I have an issue with is the implication that this sort of
encoding might actually be good for other purposes.   For the example
given (mobile devices), a different usage pattern for PGP/MIME should do
the trick just as well.

Ingo

--=-DSG4wfAhWk6maiyAmLnZ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCJLYTzZDBZDStzlsRAowJAJ4xcvSvtM8p1ntnKIB2KhlWRllNvQCgmjC5
ZYYdpNqj3axn4xLiR4RPx4E=
=SYkS
-----END PGP SIGNATURE-----

--=-DSG4wfAhWk6maiyAmLnZ--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21GKUgU018603; Tue, 1 Mar 2005 08:20:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j21GKUst018602; Tue, 1 Mar 2005 08:20:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21GKKpO018581 for <[e-mail]>; Tue, 1 Mar 2005 08:20:25 -0800 (PST) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D6A2L-0003Qg-Ie for <[e-mail]>; Tue, 01 Mar 2005 17:15:53 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D6A4x-0002rJ-KW; Tue, 01 Mar 2005 17:18:35 +0100
To: Ingo Luetkebohle <[e-mail]>
Cc: "\"Hal Finney\"" <[e-mail]>, [e-mail]
Subject: Re: PGP Partitioned Encoding Format
References: <[e-mail]> <[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Tue, 01 Mar 2005 17:18:35 +0100
In-Reply-To: <[e-mail]> (Ingo Luetkebohle's message of "Tue, 01 Mar 2005 12:17:21 +0100")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, 01 Mar 2005 12:17:21 +0100, Ingo Luetkebohle said:

> Instead of putting in a notation requesting "partitioned", you might
> request the "other way" of packaging a MIME-message just as well.

Won't work either with Outlook. You need at least a way to display
signed message even to users without the ability to check the
signature.  All PGP/MIME stuff does not work with that beast unless
someone figures out how their MAPI can be forced to do certain things.
It is really a pitty that for just one MUA one need to resort to such
pragmatic workarounds.


Shalom-Salam,

   Werner




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21Fd7gG015383; Tue, 1 Mar 2005 07:39:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j21Fd7HB015382; Tue, 1 Mar 2005 07:39:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21Fd5eP015357 for <[e-mail]>; Tue, 1 Mar 2005 07:39:06 -0800 (PST) (envelope-from [e-mail])
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 23CDB33C33; Tue,  1 Mar 2005 15:38:54 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Tue, 01 Mar 2005 15:36:56 +0000
From: Ben Laurie <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Hal Finney <[e-mail]>
Cc: [e-mail]
Subject: Re: Forward Secrecy
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hal Finney wrote:
> I think we had some discussion of this a few years ago, but I don't
> have my records handy.  I do like the idea of forward secrecy but I
> think there are a few problems with the proposals in the draft
> http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt.
> 
>    Using a series of encryption keys, each with a short lifetime,
>    reduces the information revealed by the compromise of any one private
>    key because each key protects less data.  If expired keys are
>    securely deleted, attackers will never be able to retrieve them to
>    decrypt captured ciphertext.  Therefore when a public encryption key
>    expires, an OpenPGP client MUST securely wipe the corresponding
>    private key [4].
> 
> I don't agree that OpenPGP clients MUST always securely wipe expired
> private keys.  In the context of a user who wants PFS, this makes sense.
> But for a user who wants to be sure he can decrypt his messages, this
> is a bad policy.  For example, some mail systems may store the messages
> in encrypted form, and he needs to keep the key around in order to read
> those messages in the future.
 >
> We would need to make the wording clear that this is only for clients
> operating in "PFS mode".

Agreed.

I have changed to this:

"Therefore when a public encryption key used for forward secrecy 
expires, an OpenPGP client MUST securely wipe the corresponding private 
key."

>    Deletion should take place once all messages that could have been
>    sent before expiry have been received and decrypted.  For example, as
>    a user logs on, their mail client SHOULD retrieve and decrypt all
>    messages from their mail server before deleting any newly-expired
>    private keys.  A "panic mode" MAY bypass this step.
> 
> I guess that "panic mode" means some command the user could give to
> immediately delete all expired decryption keys.
> 
> But this leads to a larger concern, which is that much of this draft
> specifies client behavior in a manner which has traditionally been out
> of scope for our working group.  We would not normally propose to give
> guidelines for UI such as the existence of a panic mode, and how clients
> should respond to it.  For example, we do not attempt to prescribe how
> client software should display signed messages, what information should
> be shown from a signature, or how to depict messages which are partially
> signed and partially unsigned.
> 
> The PFS draft is full of detailed recommendations about client behavior.
> Here, it describes how and when clients should access the mail server.
> Later, it talks about clients sending various warnings to each other,
> generating keys in the background, and revoking keys before exporting
> the private part.  The main thrust of the draft is towards specifying
> client behavior.

Since some client behaviour must be specified for PFS to work, I don't 
see that that is avoidable. However, I do agree that it should be kept 
to just that behaviour that is actually necessary. Secure deletion of 
private keys is necessary for PFS, and so that should remain. Retrieving 
(and decrypting) messages encrypted with that key before deleting is a 
good idea, but I agree is probably not something to be mandated by this 
draft.

> My principle concern is that since we have eschewed such specifications
> even for the more fundamental task of communicating securely via email,
> does it make sense to go into such detail for a rather more specialized
> sub-task, of achieving PFS in the process?  Here is another example:
> 
>    Clients receiving messages encrypted with a revoked key MUST warn the
>    sender that they should not use that public key again.  Any relevant
>    key revocation certificates MUST be included in the warning.
> 
> This is not really PFS specific, and it may be a good idea, but it is
> exactly the kind of thing which we have left out of the OpenPGP spec.
> There are too many issues involved in the design of a mail user agent
> for a secure email system, for us to try to capture them in a spec.

I agree.

> I won't try to go through the rest of the draft at this time.  As I said,
> I support the goal of PFS, but I am skeptical about whether it makes
> sense for our WG to promulgate such detailed advice on a relatively
> narrow aspect of security.

I am more interested in the parts of the draft that require 
standardisation (such as marking [and transmitting] one-time keys). I 
would be more-or-less happy to remove the "advice" parts of the draft 
and find another venue for them, if that's what the WG wants.

Cheers,

ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21BHo7R062365; Tue, 1 Mar 2005 03:17:50 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j21BHo7m062364; Tue, 1 Mar 2005 03:17:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21BHg8r062269 for <[e-mail]>; Tue, 1 Mar 2005 03:17:49 -0800 (PST) (envelope-from [e-mail])
Received: from chagall.TechFak.Uni-Bielefeld.DE (chagall.TechFak.Uni-Bielefeld.DE [129.70.139.44]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id j21BHLEU019487 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Mar 2005 12:17:26 +0100 (MET)
Subject: Re: PGP Partitioned Encoding Format
From: Ingo Luetkebohle <[e-mail]>
To: "\"Hal Finney\"" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Tue, 01 Mar 2005 12:17:21 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.0 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Am Montag, den 28.02.2005, 15:35 -0800 schrieb "Hal Finney":
> One other example where Partitioned Encoding is often the best encoding to
> use is when sending PGP email to mobile devices. Because the two primary
> standard formats for secure email, PGP/MIME and S/MIME, encrypt the entire
> body of an email including attachments as one part, a mobile device is
> prevented from downloading only specific segments of the message which
> can be very desirable in low-bandwidth scenarios.

Thats current practice but you make it sound as if its required by the
standard.  From my reading of RFC3156, it is not.  While the
"multipart/encrypted" part has to have exactly one encrypted subpart, it
may occur several times in any given message.

Both approaches have their drawbacks -- its certainly more telling to
have every attachment encrypted seperately and its also more work for
the handling application.  In any case, its hard to tell what will be
more appropriate for the recipient.  However, advocating a non-MIME
format because of assumptions about the recipient seems ill-advised to
me.  

Instead of putting in a notation requesting "partitioned", you might
request the "other way" of packaging a MIME-message just as well.
If, however, you want to document "partitioned" purely as a backwords-
compatibility thing, please don't put in language that makes it sound
like it might be a good idea for future use.

Sorry, but I've had one too many inline-PGP vs. PGP/MIME discussions to
stay calm here ;-)

regards

-- 
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff