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

From: [email-masked]
Date: Wed, 22 Dec 1999 06:55:08 -0500

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-00.txt
	Pages		: 63
	Date		: 21-Dec-99
	
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.
Open-PGP 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-00.txt

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-00.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-00.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: Edwin Woudt <[email-masked]>
Date: Wed, 22 Dec 1999 23:23:02 +0100

>         Filename        : draft-ietf-openpgp-rfc2440bis-00.txt

For those who care: I've put an HTML-ified version of this draft 
online. It includes color coded differences between this draft and
RFC2440.

http://www.cryptix.org/docs/openpgp.html

Edwin

---

From: Jon Callas <[email-masked]>
Date: Wed, 22 Dec 1999 15:46:44 -0800

Thank you. I appreciate putting the diffs up. Thank you also for pointing
out some omissions. Please let me know if there is more that should be in
the next revision.

	Jon

---

From: Ulf Möller <[email-masked]>
Date: Thu, 23 Dec 1999 20:40:01 +0100

PKCS-1 block type 02 [RFC2437] (Was: [RFC2313]) to form the "m"
   value used in the formulas above.

You need to observe the changes in terminology if you refer to the new
PKCS #1.

The signature packet format is still specified as including "zero or
more subpackets", but the subpacket hints section mentions in passing
that two packets are mandatory.

The notes about backward compatibility don't mention that PGP 2
requires certain formats for some packet types.

I don't think the note
     * (Added:) PGP 2.6.X and 5.0 do not trim trailing whitespace from a
       "canonical text" signature. They only remove it from cleartext
       signatures.
is particularly clear on how to interoperate.

The security notes should mention that only v3 RSA signatures are bound to
the hash algorithm, so that v4/DSA signatures can be forged if any one of
the hash algorithms is broken, even if the signer doesn't use that algorithm.