Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-08.txt

From: [email-masked]
Date: Wed, 04 Jun 2003 07:56:54 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-08.txt
	Pages		: 71
	Date		: 2003-6-3
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Imad R. Faiad" <[email-masked]>
Date: Thu, 05 Jun 2003 02:18:31 +0200

Hello Mr. Callas,

And while we are hacking, by hacking, I mean
chopping with an axe.  Let us spruce the
compression algorithms.

The zlib compression algorithm seems to be only
implemented in the GnuPG variants, and
is causing a lot of inter-operability problems.
The compression function is breaking inter
operability, therefore, we ought to state what is a
"MUST" and what isn't, so that the issue may be resolved,
once and for all.  Especially so, when, forgive
my expression, some implementors, default to zilb,
while others seem to be unwilling to implement it.

my 2c,

Best Regards

Imad R. Faiad

On Wed, 04 Jun 2003 07:56:54 -0400, you wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the An Open Specification for
>Pretty Good Privacy Working Group of the IETF.  
>
>Internet-Drafts are also available by anonymous FTP. Login with the
>username "anonymous" and a password of your e-mail address. After logging
>in,

---

From: David Shaw <[email-masked]>
Date: Wed, 4 Jun 2003 20:53:03 -0400

On Thu, Jun 05, 2003 at 02:18:31AM +0200, Imad R. Faiad wrote:
> once and for all.

I think the text in the draft is pretty clear on this point.  To my
reading, it says:

* You MUST support uncompressed data.

* You SHOULD support ZIP.

* You MAY support ZLIB.

* If a key states compression preferences, they MUST be followed at
  least to the point of knowing when to send uncompressed.  An easy
  way to do this is to to always send uncompressed data since it is
  known to always be supported.

* If a key does not state compression preferences, they are assumed
  to be "ZIP, Uncompressed".

It all seems pretty clear-cut to me.

I have seen a few interoperability problems between GnuPG and PGP due
to ZLIB, but each and every one falls into one of two groups:

1) A GnuPG user who insists on forcing the use of ZLIB when
   communicating with a PGP user, and ignores the "forcing compression
   algorithm ZLIB violates recipient preferences" error message.  This
   is depressingly common, but still is not a problem that the OpenPGP
   design can solve.

2) A key is generated in GnuPG, then later the user switches over to
   using PGP.  Since the ZLIB preference still exists on the key,
   a correspondant using GnuPG will naturally use ZLIB when encrypting
   to that key.  This is a problem that OpenPGP addresses in section
   5.2.3.3 ("Notes on Self-Signatures"):

       Since a self-signature contains important information about the
       key's use, an implementation SHOULD allow the user to rewrite
       the self-signature, and important information in it, such as
       preferences and key expiration.

> Especially so, when, forgive

Which implementation is that?  Both GnuPG and PGP default to ZIP.

The problem here is actually wider than the ZIP/ZLIB issue.  The same
thing happens with any two OpenPGP programs that support any different
cipher or hash algorithms.  The answer is not to force all
implementations to have the exact same algorithms.  The answer is to
properly use the preference lists.  That's what they are there for.

David

---

From: David Shaw <[email-masked]>
Date: Wed, 4 Jun 2003 21:27:38 -0400

> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-08.txt

I'm quite pleased with this draft.  I'm going to give it a more
in-depth read, but I did notice a few very minor (mostly language)
nits:

***************

In section 5.2.1 ("Signature Types"): In the description of the 0x50
signature, there is a sentance that reads "such a a blind party that
only sees the signature, not the key nor source document".  That first
"a" was probably intended as an "as".

In the same section, "It is a notary seal on the signed data", could
probably be better as "It is analogous to a notary seal on the signed
data".  This should also help Ian Grigg's concerns about misuse of the
word "notary".

***************

In section 14 ("Implementation Nits") one of the items mentions:

     * PGP 2.0 through 2.5 generated V2 Public Key Packets. These are
       identical to the deprecated V3 keys except for the version
       number. An implementation may accept or reject them as it sees
       fit.

It might be good to change this a bit to:

     * PGP 2.0 through 2.5 generated V2 Public Key Packets and V2
       signatures. These are identical to the deprecated V3 keys and
       signatures except for the version number. An implementation may
       accept or reject them as it sees fit.

***************

I understood that the "keyserver preferences" and "features"
subpackets contain a collection of single-bit flags, but it isn't
completely clear from the text.  Maybe a sprinkling of the word "bit"
would help here.

***************

In section 5.2.4 ("Computing Signatures"), a sentance reads "A V3
certification hashes the contents of the name packet, without any
header."  Instead of "name packet", I suggest "user ID or attribute
packet".

***************

In section 10.1 ("Transferable Public Keys"), subkeys are followed by
"After each Subkey packet, one signature packet, optionally a
revocation."  I think the word "plus", as in "... plus optionally a
revocation" would be helpful here.  A revocation does not take the
place of the original binding signature.

***************

David