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

From: [email-masked]
Date: Mon, 12 Aug 2002 07:20:37 -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-06.txt
	Pages		: 71
	Date		: 09-Aug-02
	
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-06.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-06.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-06.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: Florian Weimer <[email-masked]>
Date: Mon, 12 Aug 2002 16:07:27 +0200

|  Revoking a self-signature or allowing it to expire has a defined
|  semantic meaning.

IMHO, the draft does not specify the semantics of expiration in a way
which would warrant such statement.  I don't believe we can agree on a
specific set of expiration semantics even in the limited circle of
this WG.

BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html)
is definitely worth a read.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898

---

From: Jon Callas <[email-masked]>
Date: Mon, 12 Aug 2002 10:23:26 -0700

> is definitely worth a read.

That particular change was correcting a typo in the previous draft. It has
nothing to do with the new paper.

    Jon

---

From: Werner Koch <[email-masked]>
Date: Mon, 12 Aug 2002 10:26:10 -0700 (PDT)

> specific set of expiration semantics even in the limited circle of

PNX (PGP is not X.509) ;-)

> is definitely worth a read.

And the reason why Jon released the draft and sharped the MDC wording.

I see no more problem with the draft.  How lets try again to kick off
the the interop tests.

Salam-Shalom,

   Werner

---

From: Florian Weimer <[email-masked]>
Date: Mon, 12 Aug 2002 19:28:41 +0200

> nothing to do with the new paper.

Oh, I didn't want to imply *that* (hence "BTW").

I still think that the change is misleading.

---

From: David Shaw <[email-masked]>
Date: Mon, 12 Aug 2002 13:47:25 -0400

I noticed the "notary signature" specification was not present.  I
thought we had sufficiently specified how that would work?

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: Len Sassaman <[email-masked]>
Date: Mon, 12 Aug 2002 10:55:27 -0700 (PDT)

> I see no more problem with the draft.  How lets try again to kick off

I think that it would be nice to have the NAI X.509 packets documented.
Having quasi-offical data formats that implimentors need to deal with, but
are not documented, sounds like a bad idea to me. (Though, if it belongs
in a seperate Internet Draft, I have no problem with that. But there
should be some place to go other than the PGP source for this
information.)

--Len.

---

From: David Shaw <[email-masked]>
Date: Mon, 12 Aug 2002 14:35:08 -0400

> should be some place to go other than the PGP source for this

Speaking about the X.509 signatures, I wonder if they are strictly
compliant with this draft.  2440bis seems to say that v4 signatures
require (MUST) an issuer subpacket and a timestamp subpacket, and that
those subpackets are both hashed (as per the "two or more" language in
section 5.2.3, and section 5.2.4.1. Subpacket Hints).  The X.509 sigs
don't have an issuer subpacket at all.  If this reading is incorrect,
it may be good to clarify things a bit.  I suppose it could be argued
that since the X.509 sigs are made with an experimental public key
algorithm (100), the signature format does not necessarily follow.

Come to think, both PGP and GnuPG create v4 signatures with a hashed
timestamp, and an unhashed issuer.  Are they compliant? ;)

David

---

From: "Michael Young" <[email-masked]>
Date: Mon, 12 Aug 2002 16:10:48 -0400

From: "David Shaw" <[email-masked]>
> 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket 
...
> timestamp, and an unhashed issuer.  Are they compliant? ;)

I don't think that the specification should require either.  It would be
fair to note that many implementations will be unable (or unwilling) to
interpret a signature without these things.

But even if the issuer remains a MUST, it certainly doesn't need
to be in the hashed material.  As it stands, the specification doesn't
say so exactly -- it merely suggests that they should be the first two
subpackets, which is silly if the timestamp is hashed but the issuer
is not.  I would just excise the suggestion entirely.

---

From: David Shaw <[email-masked]>
Date: Mon, 12 Aug 2002 17:02:23 -0400

> is not.  I would just excise the suggestion entirely.

2440bis does say (well, imply) that they are both hashed.  In section
5.2.3. ("Version 4 Signature Packet Format"), it says that the hashed
section is made up of "two or more" subpackets, and the unhashed
section is made up of "zero or more" subpackets.  Given the language
elsewhere, I assume that these two hashed subpackets are the required
issuer and timestamp.

I agree with you though - I think that a signature should not require
any subpacket to be present (SHOULD perhaps, but not MUST).

David

---

From: Jon Callas <[email-masked]>
Date: Mon, 12 Aug 2002 23:14:49 -0700

> should be some place to go other than the PGP source for this

It would be nice, but we have to get the owners of that code base to be
willing to document it, or have someone else do it. I presume there's
consensus that this is a good idea, as there are no further comments?

I want to get soon a new RFC number, so let's look at what there is to
finish up.

* I've completely spaced on the notary signatures, apparently, so I'll get
those in soon. 

* I'll look at signature subpackets, and if the spec needs changes to jibe
with reality, I'll do it. MUSTs changed to SHOULDs, right?

Anything else?

    Jon

---

From: Werner Koch <[email-masked]>
Date: Tue, 13 Aug 2002 13:29:05 +0200

> consensus that this is a good idea, as there are no further comments?

I think it is far easier to allow PGP keys for TLS (there is a
specification and at least one implementation) than to intermix the
two protocol and raise the complexity even more.

Afaik, Peter Gutmann is working on a proposal on how to use X.509 keys
with PGP.

> with reality, I'll do it. MUSTs changed to SHOULDs, right?

Yes.

Salam-Shalom,

   Werner

---

From: David Shaw <[email-masked]>
Date: Tue, 13 Aug 2002 18:33:38 -0400

> consensus that this is a good idea, as there are no further comments?

To a certain extent these are already documented in the draft.  The
X.509 signature subpackets are in the "private or experimental" range
(they use 100), and the signatures are also issued using public key
algorithm 100, also experimental.

It would be nice to see the format fully documented, though if it were
widely adopted, it would result in one of the experimental values
effectively losing its experimental status.

> * I've completely spaced on the notary signatures, apparently, so I'll get

I've started roughing out some code for this (based on the discussion
a few weeks ago) so we can have some implementation experience for
this and the "revocation target" subpackets.  Could you post the
notary signature draft language when you put it together?

> with reality, I'll do it. MUSTs changed to SHOULDs, right?

Yes, and the "two or more" subpacket requirement for the hashed
section should probably be "zero or more".

David