Re: PGP Partitioned Encoding Format

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 

Re: Forward Secrecy

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 

Re: PGP Partitioned Encoding Format

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

Re: PGP Partitioned Encoding Format

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

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

Re: Tighter MPI spec

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. 
>
> (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

Re: [ISSUE] Minor language nits

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).
>

Draft Minutes of OpenPGP Meeting

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

-derek

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

Split Implementations of PGP

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.

Re: Split Implementations of PGP

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.

Re: Split Implementations of PGP

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