 1/draftietfopenpgprfc2440bis00.txt 20060205 00:55:29.000000000 +0100
+++ 2/draftietfopenpgprfc2440bis01.txt 20060205 00:55:29.000000000 +0100
@@ 1,26 +1,25 @@
Network Working Group Jon Callas
Category: INTERNETDRAFT Counterpane Internet Security
draftietfopenpgprfc2440bis00.txt
Expires Jun 2000 Lutz Donnerhacke
December 1999 INRootCA Individual Network e.V.
+draftietfopenpgprfc2440bis01.txt
+Expires Apr 2001 Lutz Donnerhacke
+October 2000 INRootCA Individual Network e.V.
Hal Finney
Network Associates
Rodney Thayer
 SSH Communications Security, Inc.
OpenPGP Message Format
 draftietfopenpgprfc2440bis00.txt
+ draftietfopenpgprfc2440bis01.txt
 Copyright 1999 by The Internet Society. All Rights Reserved.
+ Copyright 2000 by The Internet Society. All Rights Reserved.
Status of this Memo
This document is an InternetDraft and is in full conformance with
all provisions of Section 10 of RFC2026.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
InternetDrafts.
@@ 192,22 +191,22 @@
14. Implementation Nits 59
15. Authors and Working Group Chair 60
16. References 61
17. Full Copyright Statement 63
1. Introduction
This document provides information on the messageexchange packet
formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC2440, "OpenPGP
 Message Format", and replaces RFC 1991, "PGP Message Exchange
 Formats."
+ Message Format", which itself replaces RFC 1991, "PGP Message
+ Exchange Formats."
1.1. Terms
* OpenPGP  This is a definition for security software that uses
PGP 5.x as a basis, formalized in RFC 2440 and this document.
* PGP  Pretty Good Privacy. PGP is a family of software systems
developed by Philip R. Zimmermann from which OpenPGP is based.
* PGP 2.6.x  This version of PGP has many variants, hence the
@@ 523,23 +522,23 @@
possibilities:
0: secret data is unencrypted (no pass phrase)
255: followed by algorithm octet and S2K specifier
Cipher alg: use Simple S2K algorithm using MD5 hash
This last possibility, the cipher algorithm number with an implicit
use of MD5 and IDEA, is provided for backward compatibility; it MAY
be understood, but SHOULD NOT be generated, and is deprecated.
 These are followed by an 8octet Initial Vector for the decryption
 of the secret values, if they are encrypted, and then the secret key
 values themselves.
+ These are followed by an Initial Vector of the same length as the
+ block size of the cipher for the decryption of the secret values, if
+ they are encrypted, and then the secret key values themselves.
3.6.2.2. Symmetrickey message encryption
OpenPGP can create a Symmetrickey Encrypted Session Key (ESK)
packet at the front of a message. This is used to allow S2K
specifiers to be used for the passphrase conversion or to create
messages with a mix of symmetrickey ESKs and publickey ESKs. This
allows a message to be decrypted either with a passphrase or a
public key.
@@ 927,21 +926,21 @@
The data being signed is hashed, and then the signature type and
creation time from the signature packet are hashed (5 additional
octets). The resulting hash value is used in the signature
algorithm. The high 16 bits (first two octets) of the hash are
included in the signature packet to provide a quick test to reject
some invalid signatures.
Algorithm Specific Fields for RSA signatures:
  multiprecision integer (MPI) of RSA signature value m**d.
+  multiprecision integer (MPI) of RSA signature value m**d mod n.
Algorithm Specific Fields for DSA signatures:
 MPI of DSA value r.
 MPI of DSA value s.
The signature calculation is based on a hash of the signed data, as
described above. The details of the calculation are different for
DSA signature than for RSA signatures.
@@ 1002,21 +1001,21 @@
 Oneoctet public key algorithm.
 Oneoctet hash algorithm.
 Twooctet 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.
  Hashed subpacket data. (zero or more subpackets)
+  Hashed subpacket data. (two or more subpackets)
 Twooctet scalar octet count for following unhashed subpacket
data. Note that this is the length in octets of all of the
unhashed subpackets; a pointer incremented by this number will
skip over the unhashed subpackets.
 Unhashed subpacket data. (zero or more subpackets)
 Twooctet field holding left 16 bits of signed hash value.
 One or more multiprecision integers comprising the signature.
@@ 1737,29 +1736,30 @@
 MPI of RSA public encryption exponent e.
Algorithm Specific Fields for DSA public keys:
 MPI of DSA prime p;
 MPI of DSA group order q (q is a prime divisor of p1);
 MPI of DSA group generator g;
  MPI of DSA public key value y (= g**x where x is secret).
+  MPI of DSA public key value y (= g**x mod p where x is
+ secret).
Algorithm Specific Fields for Elgamal public keys:
 MPI of Elgamal prime p;
 MPI of Elgamal group generator g;
  MPI of Elgamal public key value y (= g**x where x is
+  MPI of Elgamal public key value y (= g**x mod p where x is
secret).
5.5.3. Secret Key Packet Formats
The Secret Key and Secret Subkey packets contain all the data of the
Public Key and Public Subkey packets, with additional
algorithmspecific secret key data appended, in encrypted form.
The packet contains:
@@ 1770,22 +1770,22 @@
indicates that a stringtokey specifier is being given. Any
other value is a symmetrickey encryption algorithm specifier.
 [Optional] If stringtokey usage octet was 255, a oneoctet
symmetric encryption algorithm.
 [Optional] If stringtokey usage octet was 255, a stringtokey
specifier. The length of the stringtokey specifier is implied
by its type, as described above.
  [Optional] If secret data is encrypted, eightoctet Initial
 Vector (IV).
+  [Optional] If secret data is encrypted, Initial Vector (IV) of
+ the same length as the cipher's block size.
 Encrypted multiprecision integers comprising the secret key
data. These algorithmspecific fields are as described below.
 Twooctet checksum of the plaintext of the algorithmspecific
portion (sum of all octets, mod 65536).
Algorithm Specific Fields for RSA secret keys:
 multiprecision integer (MPI) of RSA secret exponent d.
@@ 2370,21 +2370,21 @@
Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys.
Implementations MAY implement any other algorithm.
9.2. Symmetric Key Algorithms
ID Algorithm
 
0  Plaintext or unencrypted data
1  IDEA [IDEA]
 2  TripleDES (DESEDE, as per spec 
+ 2  TripleDES (DESEDE, [SCHNEIER] 
168 bit key derived from 192)
3  CAST5 (128 bit key, as per RFC2144)
4  Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5  SAFERSK128 (13 rounds) [SAFER]
6  Reserved for DES/SK
7  Reserved for AES with 128bit key
8  Reserved for AES with 192bit key
9  Reserved for AES with 256bit key
10  Twofish with 256bit key [TWOFISH]
100 to 110  Private/Experimental algorithm.
@@ 2598,21 +2598,21 @@
e) Algorithm specific fields.
Algorithm Specific Fields for DSA keys (example):
e.1) MPI of DSA prime p;
e.2) MPI of DSA group order q (q is a prime divisor of p1);
e.3) MPI of DSA group generator g;
 e.4) MPI of DSA public key value y (= g**x where x is secret).
+ e.4) MPI of DSA public key value y (= g**x mod p where x is secret).
Note that it is possible for there to be collisions of key IDs 
two different keys with the same key ID. Note that there is a much
smaller, but still nonzero probability that two different keys have
the same fingerprint.
Also note that if V3 and V4 format keys share the same RSA key
material, they will have different key ids as well as different
fingerprints.
@@ 2853,21 +2853,22 @@
7. (The resync step) FR is loaded with C[3] through C[BS+2].
8. FR is encrypted to produce FRE.
9. FRE is xored with the first BS octets of the given plaintext,
now that we have finished encrypting the BS+2 octets of prefixed
data. This produces C[BS+3] through C[BS+(BS+2)], the next BS
octets of ciphertext.
 10. FR is loaded with C11C18
+ 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11C18
+ for an 8octet block).
11. FR is encrypted to produce FRE.
12. FRE is xored with the next BS octets of plaintext, to produce
the next BS octets of ciphertext. These are loaded into FR and
the process is repeated until the plaintext is used up.
13. Security Considerations
As with any technology involving cryptography, you should check the
@@ 2916,22 +2917,23 @@
Some technologies mentioned here may be subject to government
control in some countries.
14. Implementation Nits
This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous
implementations of PGP are not OpenPGPcompliant. Often the
differences are small, but small differences are frequently more
 vexing than large differences. Thus, this list of potential problems
 and gotchas for a developer who is trying to be backwardcompatible.
+ vexing than large differences. Thus, this is a noncomprehensive
+ list of potential problems and gotchas for a developer who is trying
+ to be backwardcompatible.
* PGP 5.x does not accept V4 signatures for anything other than
key material.
* PGP 5.x does not recognize the "fiveoctet" lengths in
newformat headers or in signature subpacket lengths.
* PGP 5.0 rejects an encrypted session key if the keylength
differs from the S2K symmetric algorithm. This is a bug in its
validation function.
@@ 2967,72 +2969,72 @@
V4 format, but since a V4 fingerprint is constructed by hashing
the key creation time along with other things, two V4 keys
created at different times, yet with the same key material will
have different fingerprints.
* If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to 13.
* PGP 2.6.X and 5.0 do not trim trailing whitespace from a
"canonical text" signature. They only remove it from cleartext
 signatures.
+ signatures. These signatures are not OpenPGP compliant 
+ OpenPGP requires trimming the whitespace. If you wish to
+ interoperate with PGP 2.6.X or PGP 5, you may wish to accept
+ these noncompliant signatures.
* PGP 6.0 introduced a photographic user id and represents this id
in packet number 17. The format of this packet is proprietary to
its authors. Strictly speaking, an OpenPGP key that contains
such a packet is not compliant to this document, and that packet
number is reserved by this document for future use. However, if
an implementation wishes to be compatible with such keys, the
packet may be considered to be a user id packet with opaque
contents.
15. Authors and Working Group Chair
The working group can be contacted via the current chair:
John W. Noerenberg, II
Qualcomm, Inc
6455 Lusk Blvd
San Diego, CA 92131 USA
Email: jwn2@qualcomm.com
 Tel: +1 6196583510
+ Tel: +1 (619) 6583510
The principal authors of this draft are:
Jon Callas
Counterpane Internet Security, Inc.
3031 Tisch Way, suite 100 East Plaza
San Jose, CA 95128, USA
 Email: jon@callas.org, callas@counterpane.com
 Tel: +1 4085560328
+ Email: jon@callas.org, jon@counterpane.com
+ Tel: +1 (408) 5562445
Lutz Donnerhacke
IKS GmbH
Wildenbruchstr. 15
07745 Jena, Germany

EMail: lutz@iksjena.de
Tel: +493641675642
+
Hal Finney
Network Associates, Inc.
3965 Freedom Circle
Santa Clara, CA 95054, USA
Email: hal@pgp.com
Rodney Thayer
 SSH Communications Security, Inc.
 650 Castro Street Suite 220
 Mountain View, CA 94041, USA
 Email: rodney@ipsec.com
+ Email: rodney@tillerman.to
This memo also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and
Philip R. Zimmermann.
16. References
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
@@ 3123,21 +3125,21 @@
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999.
17. Full Copyright Statement
 Copyright 1999 by The Internet Society. All Rights Reserved.
+ Copyright 2000 by The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of