draft-ietf-openpgp-rfc2440bis-00.txt   draft-ietf-openpgp-rfc2440bis-01.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Counterpane Internet Security Category: INTERNET-DRAFT Counterpane Internet Security
draft-ietf-openpgp-rfc2440bis-00.txt draft-ietf-openpgp-rfc2440bis-01.txt
Expires Jun 2000 Lutz Donnerhacke Expires Apr 2001 Lutz Donnerhacke
December 1999 IN-Root-CA Individual Network e.V. October 2000 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
SSH Communications Security, Inc.
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-00.txt draft-ietf-openpgp-rfc2440bis-01.txt
Copyright 1999 by The Internet Society. All Rights Reserved. Copyright 2000 by The Internet Society. All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
14. Implementation Nits 59 14. Implementation Nits 59
15. Authors and Working Group Chair 60 15. Authors and Working Group Chair 60
16. References 61 16. References 61
17. Full Copyright Statement 63 17. Full Copyright Statement 63
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC2440, "OpenPGP and key management functions. It is a revision of RFC2440, "OpenPGP
Message Format", and replaces RFC 1991, "PGP Message Exchange Message Format", which itself replaces RFC 1991, "PGP Message
Formats." Exchange Formats."
1.1. Terms 1.1. Terms
* OpenPGP - This is a definition for security software that uses * OpenPGP - This is a definition for security software that uses
PGP 5.x as a basis, formalized in RFC 2440 and this document. PGP 5.x as a basis, formalized in RFC 2440 and this document.
* PGP - Pretty Good Privacy. PGP is a family of software systems * PGP - Pretty Good Privacy. PGP is a family of software systems
developed by Philip R. Zimmermann from which OpenPGP is based. developed by Philip R. Zimmermann from which OpenPGP is based.
* PGP 2.6.x - This version of PGP has many variants, hence the * PGP 2.6.x - This version of PGP has many variants, hence the
skipping to change at page 12, line 31 skipping to change at page 12, line 31
possibilities: possibilities:
0: secret data is unencrypted (no pass phrase) 0: secret data is unencrypted (no pass phrase)
255: followed by algorithm octet and S2K specifier 255: followed by algorithm octet and S2K specifier
Cipher alg: use Simple S2K algorithm using MD5 hash Cipher alg: use Simple S2K algorithm using MD5 hash
This last possibility, the cipher algorithm number with an implicit This last possibility, the cipher algorithm number with an implicit
use of MD5 and IDEA, is provided for backward compatibility; it MAY use of MD5 and IDEA, is provided for backward compatibility; it MAY
be understood, but SHOULD NOT be generated, and is deprecated. be understood, but SHOULD NOT be generated, and is deprecated.
These are followed by an 8-octet Initial Vector for the decryption These are followed by an Initial Vector of the same length as the
of the secret values, if they are encrypted, and then the secret key block size of the cipher for the decryption of the secret values, if
values themselves. they are encrypted, and then the secret key values themselves.
3.6.2.2. Symmetric-key message encryption 3.6.2.2. Symmetric-key message encryption
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) OpenPGP can create a Symmetric-key Encrypted Session Key (ESK)
packet at the front of a message. This is used to allow S2K packet at the front of a message. This is used to allow S2K
specifiers to be used for the passphrase conversion or to create specifiers to be used for the passphrase conversion or to create
messages with a mix of symmetric-key ESKs and public-key ESKs. This messages with a mix of symmetric-key ESKs and public-key ESKs. This
allows a message to be decrypted either with a passphrase or a allows a message to be decrypted either with a passphrase or a
public key. public key.
skipping to change at page 20, line 27 skipping to change at page 20, line 27
The data being signed is hashed, and then the signature type and The data being signed is hashed, and then the signature type and
creation time from the signature packet are hashed (5 additional creation time from the signature packet are hashed (5 additional
octets). The resulting hash value is used in the signature octets). The resulting hash value is used in the signature
algorithm. The high 16 bits (first two octets) of the hash are algorithm. The high 16 bits (first two octets) of the hash are
included in the signature packet to provide a quick test to reject included in the signature packet to provide a quick test to reject
some invalid signatures. some invalid signatures.
Algorithm Specific Fields for RSA 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: Algorithm Specific Fields for DSA signatures:
- MPI of DSA value r. - MPI of DSA value r.
- MPI of DSA value s. - MPI of DSA value s.
The signature calculation is based on a hash of the signed data, as The signature calculation is based on a hash of the signed data, as
described above. The details of the calculation are different for described above. The details of the calculation are different for
DSA signature than for RSA signatures. DSA signature than for RSA signatures.
skipping to change at page 21, line 52 skipping to change at page 21, line 52
- One-octet public key algorithm. - One-octet public key algorithm.
- One-octet hash algorithm. - One-octet hash algorithm.
- Two-octet scalar octet count for following hashed subpacket - Two-octet scalar octet count for following hashed subpacket
data. Note that this is the length in octets of all of the data. Note that this is the length in octets of all of the
hashed subpackets; a pointer incremented by this number will hashed subpackets; a pointer incremented by this number will
skip over the hashed subpackets. skip over the hashed subpackets.
- Hashed subpacket data. (zero or more subpackets) - Hashed subpacket data. (two or more subpackets)
- Two-octet scalar octet count for following unhashed subpacket - Two-octet scalar octet count for following unhashed subpacket
data. Note that this is the length in octets of all of the data. Note that this is the length in octets of all of the
unhashed subpackets; a pointer incremented by this number will unhashed subpackets; a pointer incremented by this number will
skip over the unhashed subpackets. skip over the unhashed subpackets.
- Unhashed subpacket data. (zero or more subpackets) - Unhashed subpacket data. (zero or more subpackets)
- Two-octet field holding left 16 bits of signed hash value. - Two-octet field holding left 16 bits of signed hash value.
- One or more multi-precision integers comprising the signature. - One or more multi-precision integers comprising the signature.
skipping to change at page 36, line 19 skipping to change at page 36, line 19
- MPI of RSA public encryption exponent e. - MPI of RSA public encryption exponent e.
Algorithm Specific Fields for DSA public keys: Algorithm Specific Fields for DSA public keys:
- MPI of DSA prime p; - MPI of DSA prime p;
- MPI of DSA group order q (q is a prime divisor of p-1); - MPI of DSA group order q (q is a prime divisor of p-1);
- MPI of DSA group generator g; - 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: Algorithm Specific Fields for Elgamal public keys:
- MPI of Elgamal prime p; - MPI of Elgamal prime p;
- MPI of Elgamal group generator g; - 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). secret).
5.5.3. Secret Key Packet Formats 5.5.3. Secret Key Packet Formats
The Secret Key and Secret Subkey packets contain all the data of the The Secret Key and Secret Subkey packets contain all the data of the
Public Key and Public Subkey packets, with additional Public Key and Public Subkey packets, with additional
algorithm-specific secret key data appended, in encrypted form. algorithm-specific secret key data appended, in encrypted form.
The packet contains: The packet contains:
skipping to change at page 36, line 52 skipping to change at page 36, line 53
indicates that a string-to-key specifier is being given. Any indicates that a string-to-key specifier is being given. Any
other value is a symmetric-key encryption algorithm specifier. other value is a symmetric-key encryption algorithm specifier.
- [Optional] If string-to-key usage octet was 255, a one-octet - [Optional] If string-to-key usage octet was 255, a one-octet
symmetric encryption algorithm. symmetric encryption algorithm.
- [Optional] If string-to-key usage octet was 255, a string-to-key - [Optional] If string-to-key usage octet was 255, a string-to-key
specifier. The length of the string-to-key specifier is implied specifier. The length of the string-to-key specifier is implied
by its type, as described above. by its type, as described above.
- [Optional] If secret data is encrypted, eight-octet Initial - [Optional] If secret data is encrypted, Initial Vector (IV) of
Vector (IV). the same length as the cipher's block size.
- Encrypted multi-precision integers comprising the secret key - Encrypted multi-precision integers comprising the secret key
data. These algorithm-specific fields are as described below. data. These algorithm-specific fields are as described below.
- Two-octet checksum of the plaintext of the algorithm-specific - Two-octet checksum of the plaintext of the algorithm-specific
portion (sum of all octets, mod 65536). portion (sum of all octets, mod 65536).
Algorithm Specific Fields for RSA secret keys: Algorithm Specific Fields for RSA secret keys:
- multiprecision integer (MPI) of RSA secret exponent d. - multiprecision integer (MPI) of RSA secret exponent d.
skipping to change at page 48, line 37 skipping to change at page 48, line 37
Implementations MUST implement DSA for signatures, and Elgamal for Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys. encryption. Implementations SHOULD implement RSA keys.
Implementations MAY implement any other algorithm. Implementations MAY implement any other algorithm.
9.2. Symmetric Key Algorithms 9.2. Symmetric Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Plaintext or unencrypted data 0 - Plaintext or unencrypted data
1 - IDEA [IDEA] 1 - IDEA [IDEA]
2 - Triple-DES (DES-EDE, as per spec - 2 - Triple-DES (DES-EDE, [SCHNEIER] -
168 bit key derived from 192) 168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC2144) 3 - CAST5 (128 bit key, as per RFC2144)
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - SAFER-SK128 (13 rounds) [SAFER] 5 - SAFER-SK128 (13 rounds) [SAFER]
6 - Reserved for DES/SK 6 - Reserved for DES/SK
7 - Reserved for AES with 128-bit key 7 - Reserved for AES with 128-bit key
8 - Reserved for AES with 192-bit key 8 - Reserved for AES with 192-bit key
9 - Reserved for AES with 256-bit key 9 - Reserved for AES with 256-bit key
10 - Twofish with 256-bit key [TWOFISH] 10 - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
skipping to change at page 53, line 11 skipping to change at page 53, line 11
e) Algorithm specific fields. e) Algorithm specific fields.
Algorithm Specific Fields for DSA keys (example): Algorithm Specific Fields for DSA keys (example):
e.1) MPI of DSA prime p; e.1) MPI of DSA prime p;
e.2) MPI of DSA group order q (q is a prime divisor of p-1); e.2) MPI of DSA group order q (q is a prime divisor of p-1);
e.3) MPI of DSA group generator g; 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 -- 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 two different keys with the same key ID. Note that there is a much
smaller, but still non-zero probability that two different keys have smaller, but still non-zero probability that two different keys have
the same fingerprint. the same fingerprint.
Also note that if V3 and V4 format keys share the same RSA key 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 material, they will have different key ids as well as different
fingerprints. fingerprints.
skipping to change at page 58, line 5 skipping to change at page 58, line 5
7. (The resync step) FR is loaded with C[3] through C[BS+2]. 7. (The resync step) FR is loaded with C[3] through C[BS+2].
8. FR is encrypted to produce FRE. 8. FR is encrypted to produce FRE.
9. FRE is xored with the first BS octets of the given plaintext, 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 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 data. This produces C[BS+3] through C[BS+(BS+2)], the next BS
octets of ciphertext. octets of ciphertext.
10. FR is loaded with C11-C18 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
for an 8-octet block).
11. FR is encrypted to produce FRE. 11. FR is encrypted to produce FRE.
12. FRE is xored with the next BS octets of plaintext, to produce 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 next BS octets of ciphertext. These are loaded into FR and
the process is repeated until the plaintext is used up. the process is repeated until the plaintext is used up.
13. Security Considerations 13. Security Considerations
As with any technology involving cryptography, you should check the As with any technology involving cryptography, you should check the
skipping to change at page 59, line 15 skipping to change at page 59, line 16
Some technologies mentioned here may be subject to government Some technologies mentioned here may be subject to government
control in some countries. control in some countries.
14. Implementation Nits 14. Implementation Nits
This section is a collection of comments to help an implementer, This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous particularly with an eye to backward compatibility. Previous
implementations of PGP are not OpenPGP-compliant. Often the implementations of PGP are not OpenPGP-compliant. Often the
differences are small, but small differences are frequently more differences are small, but small differences are frequently more
vexing than large differences. Thus, this list of potential problems vexing than large differences. Thus, this is a non-comprehensive
and gotchas for a developer who is trying to be backward-compatible. list of potential problems and gotchas for a developer who is trying
to be backward-compatible.
* PGP 5.x does not accept V4 signatures for anything other than * PGP 5.x does not accept V4 signatures for anything other than
key material. key material.
* PGP 5.x does not recognize the "five-octet" lengths in * PGP 5.x does not recognize the "five-octet" lengths in
new-format headers or in signature subpacket lengths. new-format headers or in signature subpacket lengths.
* PGP 5.0 rejects an encrypted session key if the keylength * PGP 5.0 rejects an encrypted session key if the keylength
differs from the S2K symmetric algorithm. This is a bug in its differs from the S2K symmetric algorithm. This is a bug in its
validation function. validation function.
skipping to change at page 60, line 14 skipping to change at page 60, line 18
V4 format, but since a V4 fingerprint is constructed by hashing V4 format, but since a V4 fingerprint is constructed by hashing
the key creation time along with other things, two V4 keys the key creation time along with other things, two V4 keys
created at different times, yet with the same key material will created at different times, yet with the same key material will
have different fingerprints. have different fingerprints.
* If an implementation is using zlib to interoperate with PGP 2.x, * If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
* PGP 2.6.X and 5.0 do not trim trailing whitespace from a * PGP 2.6.X and 5.0 do not trim trailing whitespace from a
"canonical text" signature. They only remove it from cleartext "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 non-compliant signatures.
* PGP 6.0 introduced a photographic user id and represents this id * PGP 6.0 introduced a photographic user id and represents this id
in packet number 17. The format of this packet is proprietary to in packet number 17. The format of this packet is proprietary to
its authors. Strictly speaking, an OpenPGP key that contains its authors. Strictly speaking, an OpenPGP key that contains
such a packet is not compliant to this document, and that packet such a packet is not compliant to this document, and that packet
number is reserved by this document for future use. However, if number is reserved by this document for future use. However, if
an implementation wishes to be compatible with such keys, the an implementation wishes to be compatible with such keys, the
packet may be considered to be a user id packet with opaque packet may be considered to be a user id packet with opaque
contents. contents.
15. Authors and Working Group Chair 15. Authors and Working Group Chair
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
John W. Noerenberg, II John W. Noerenberg, II
Qualcomm, Inc Qualcomm, Inc
6455 Lusk Blvd 6455 Lusk Blvd
San Diego, CA 92131 USA San Diego, CA 92131 USA
Email: jwn2@qualcomm.com Email: jwn2@qualcomm.com
Tel: +1 619-658-3510 Tel: +1 (619) 658-3510
The principal authors of this draft are: The principal authors of this draft are:
Jon Callas Jon Callas
Counterpane Internet Security, Inc. Counterpane Internet Security, Inc.
3031 Tisch Way, suite 100 East Plaza 3031 Tisch Way, suite 100 East Plaza
San Jose, CA 95128, USA San Jose, CA 95128, USA
Email: jon@callas.org, callas@counterpane.com Email: jon@callas.org, jon@counterpane.com
Tel: +1 408-556-0328 Tel: +1 (408) 556-2445
Lutz Donnerhacke Lutz Donnerhacke
IKS GmbH IKS GmbH
Wildenbruchstr. 15 Wildenbruchstr. 15
07745 Jena, Germany 07745 Jena, Germany
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Tel: +49-3641-675642 Tel: +49-3641-675642
Hal Finney Hal Finney
Network Associates, Inc. Network Associates, Inc.
3965 Freedom Circle 3965 Freedom Circle
Santa Clara, CA 95054, USA Santa Clara, CA 95054, USA
Email: hal@pgp.com Email: hal@pgp.com
Rodney Thayer 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 This memo also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto, authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and
Philip R. Zimmermann. Philip R. Zimmermann.
16. References 16. References
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
skipping to change at page 63, line 19 skipping to change at page 63, line 19
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996. protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999. Algorithm", John Wiley & Sons, 1999.
17. Full Copyright Statement 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 This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/