draft-ietf-openpgp-rfc2440bis-02.txt   draft-ietf-openpgp-rfc2440bis-03.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Counterpane Internet Security Category: INTERNET-DRAFT Wave Systems Corporation
draft-ietf-openpgp-rfc2440bis-02.txt draft-ietf-openpgp-rfc2440bis-03.txt
Expires Apr 2001 Lutz Donnerhacke Expires Feb 2002 Lutz Donnerhacke
October 2000 IN-Root-CA Individual Network e.V. August 2001 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-02.txt draft-ietf-openpgp-rfc2440bis-03.txt
Copyright 2000 by The Internet Society. All Rights Reserved. Copyright 2001 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 3, line 50 skipping to change at page 3, line 50
4.2.2.2. Two-Octet Lengths 14 4.2.2.2. Two-Octet Lengths 14
4.2.2.3. Five-Octet Lengths 15 4.2.2.3. Five-Octet Lengths 15
4.2.2.4. Partial Body Lengths 15 4.2.2.4. Partial Body Lengths 15
4.2.3. Packet Length Examples 15 4.2.3. Packet Length Examples 15
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 16 5. Packet Types 16
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16
5.2. Signature Packet (Tag 2) 17 5.2. Signature Packet (Tag 2) 17
5.2.1. Signature Types 18 5.2.1. Signature Types 18
5.2.2. Version 3 Signature Packet Format 20 5.2.2. Version 3 Signature Packet Format 20
5.2.3. Version 4 Signature Packet Format 21 5.2.3. Version 4 Signature Packet Format 22
5.2.3.1. Signature Subpacket Specification 22 5.2.3.1. Signature Subpacket Specification 23
5.2.3.2. Signature Subpacket Types 24 5.2.3.2. Signature Subpacket Types 24
5.2.3.3. Notes on Self-Signatures 24 5.2.3.3. Notes on Self-Signatures 25
5.2.3.4. Signature creation time 25 5.2.3.4. Signature creation time 25
5.2.3.5. Issuer 25 5.2.3.5. Issuer 26
5.2.3.6. Key expiration time 25 5.2.3.6. Key expiration time 26
5.2.3.7. Preferred symmetric algorithms 25 5.2.3.7. Preferred symmetric algorithms 26
5.2.3.8. Preferred hash algorithms 25 5.2.3.8. Preferred hash algorithms 26
5.2.3.9. Preferred compression algorithms 26 5.2.3.9. Preferred compression algorithms 26
5.2.3.10.Signature expiration time 26 5.2.3.10.Signature expiration time 27
5.2.3.11.Exportable Certification 26 5.2.3.11.Exportable Certification 27
5.2.3.12.Revocable 26 5.2.3.12.Revocable 27
5.2.3.13.Trust signature 27 5.2.3.13.Trust signature 27
5.2.3.14.Regular expression 27 5.2.3.14.Regular expression 28
5.2.3.15.Revocation key 27 5.2.3.15.Revocation key 28
5.2.3.16.Notation Data 28 5.2.3.16.Notation Data 28
5.2.3.17.Key server preferences 28 5.2.3.17.Key server preferences 29
5.2.3.18.Preferred key server 29 5.2.3.18.Preferred key server 30
5.2.3.19.Primary user id 29 5.2.3.19.Primary user id 30
5.2.3.20.Policy URL 29 5.2.3.20.Policy URL 30
5.2.3.21.Key Flags 29 5.2.3.21.Key Flags 30
5.2.3.22.Signer's User ID 30 5.2.3.22.Signer's User ID 31
5.2.3.23.Reason for Revocation 30 5.2.3.23.Reason for Revocation 31
5.2.3.24.Features 31 5.2.3.24.Features 32
5.2.4. Computing Signatures 31 5.2.4. Computing Signatures 32
5.2.4.1. Subpacket Hints 32 5.2.4.1. Subpacket Hints 33
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 33 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 34
5.4. One-Pass Signature Packets (Tag 4) 34 5.4. One-Pass Signature Packets (Tag 4) 35
5.5. Key Material Packet 34 5.5. Key Material Packet 35
5.5.1. Key Packet Variants 35 5.5.1. Key Packet Variants 35
5.5.1.1. Public Key Packet (Tag 6) 35 5.5.1.1. Public Key Packet (Tag 6) 35
5.5.1.2. Public Subkey Packet (Tag 14) 35 5.5.1.2. Public Subkey Packet (Tag 14) 36
5.5.1.3. Secret Key Packet (Tag 5) 35 5.5.1.3. Secret Key Packet (Tag 5) 36
5.5.1.4. Secret Subkey Packet (Tag 7) 35 5.5.1.4. Secret Subkey Packet (Tag 7) 36
5.5.2. Public Key Packet Formats 35 5.5.2. Public Key Packet Formats 36
5.5.3. Secret Key Packet Formats 37 5.5.3. Secret Key Packet Formats 38
5.6. Compressed Data Packet (Tag 8) 38 5.6. Compressed Data Packet (Tag 8) 39
5.7. Symmetrically Encrypted Data Packet (Tag 9) 39 5.7. Symmetrically Encrypted Data Packet (Tag 9) 40
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 40 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 41
5.9. Literal Data Packet (Tag 11) 40 5.9. Literal Data Packet (Tag 11) 41
5.10. Trust Packet (Tag 12) 41 5.10. Trust Packet (Tag 12) 42
5.11. User ID Packet (Tag 13) 41 5.11. User ID Packet (Tag 13) 42
5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 15) 41 5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 42
5.13. Modification Detection Code Packet (Tag 16) 43 5.13. Modification Detection Code Packet (Tag 19) 44
6. Radix-64 Conversions 43 6. Radix-64 Conversions 44
6.1. An Implementation of the CRC-24 in "C" 44 6.1. An Implementation of the CRC-24 in "C" 45
6.2. Forming ASCII Armor 44 6.2. Forming ASCII Armor 45
6.3. Encoding Binary in Radix-64 47 6.3. Encoding Binary in Radix-64 47
6.4. Decoding Radix-64 48 6.4. Decoding Radix-64 49
6.5. Examples of Radix-64 48 6.5. Examples of Radix-64 49
6.6. Example of an ASCII Armored Message 49 6.6. Example of an ASCII Armored Message 50
7. Cleartext signature framework 49 7. Cleartext signature framework 50
7.1. Dash-Escaped Text 50 7.1. Dash-Escaped Text 50
8. Regular Expressions 50 8. Regular Expressions 51
9. Constants 51 9. Constants 51
9.1. Public Key Algorithms 51 9.1. Public Key Algorithms 52
9.2. Symmetric Key Algorithms 51 9.2. Symmetric Key Algorithms 52
9.3. Compression Algorithms 52 9.3. Compression Algorithms 53
9.4. Hash Algorithms 52 9.4. Hash Algorithms 53
10. Packet Composition 52 10. Packet Composition 53
10.1. Transferable Public Keys 52 10.1. Transferable Public Keys 53
10.2. OpenPGP Messages 53 10.2. OpenPGP Messages 54
10.3. Detached Signatures 54 10.3. Detached Signatures 55
11. Enhanced Key Formats 54 11. Enhanced Key Formats 55
11.1. Key Structures 54 11.1. Key Structures 55
11.2. Key IDs and Fingerprints 55 11.2. Key IDs and Fingerprints 56
12. Notes on Algorithms 56 12. Notes on Algorithms 57
12.1. Symmetric Algorithm Preferences 56 12.1. Symmetric Algorithm Preferences 57
12.2. Other Algorithm Preferences 57 12.2. Other Algorithm Preferences 58
12.2.1. Compression Preferences 57 12.2.1. Compression Preferences 58
12.2.2. Hash Algorithm Preferences 58 12.2.2. Hash Algorithm Preferences 59
12.3. Plaintext 58 12.3. Plaintext 59
12.4. RSA 58 12.4. RSA 59
12.5. Elgamal 58 12.5. Elgamal 60
12.6. DSA 59 12.6. DSA 60
12.7. Reserved Algorithm Numbers 59 12.7. Reserved Algorithm Numbers 60
12.8. OpenPGP CFB mode 60 12.8. OpenPGP CFB mode 61
13. Security Considerations 61 13. Security Considerations 62
14. Implementation Nits 62 14. Implementation Nits 63
15. Authors and Working Group Chair 63 15. Authors and Working Group Chair 65
16. References 64 16. References 66
17. Full Copyright Statement 66 17. Full Copyright Statement 68
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", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." Exchange Formats."
1.1. Terms 1.1. Terms
skipping to change at page 16, line 36 skipping to change at page 16, line 36
5 -- Secret Key Packet 5 -- Secret Key Packet
6 -- Public Key Packet 6 -- Public Key Packet
7 -- Secret Subkey Packet 7 -- Secret Subkey Packet
8 -- Compressed Data Packet 8 -- Compressed Data Packet
9 -- Symmetrically Encrypted Data Packet 9 -- Symmetrically Encrypted Data Packet
10 -- Marker Packet 10 -- Marker Packet
11 -- Literal Data Packet 11 -- Literal Data Packet
12 -- Trust Packet 12 -- Trust Packet
13 -- User ID Packet 13 -- User ID Packet
14 -- Public Subkey Packet 14 -- Public Subkey Packet
15 -- Symmetrically Encrypted and Integrity Protected Data 18 -- Symmetrically Encrypted and Integrity Protected Data
Packet Packet
16 -- Modification Detection Code Packet 19 -- Modification Detection Code Packet
60 to 63 -- Private or Experimental Values 60 to 63 -- Private or Experimental Values
5. Packet Types 5. Packet Types
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 5.1. Public-Key Encrypted Session Key Packets (Tag 1)
A Public-Key Encrypted Session Key packet holds the session key used A Public-Key Encrypted Session Key packet holds the session key used
to encrypt a message. Zero or more Encrypted Session Key packets to encrypt a message. Zero or more Encrypted Session Key packets
(either Public-Key or Symmetric-Key) may precede a Symmetrically (either Public-Key or Symmetric-Key) may precede a Symmetrically
Encrypted Data Packet, which holds an encrypted message. The Encrypted Data Packet, which holds an encrypted message. The
skipping to change at page 17, line 13 skipping to change at page 17, line 13
session key, and then uses the session key to decrypt the message. session key, and then uses the session key to decrypt the message.
The body of this packet consists of: The body of this packet consists of:
- A one-octet number giving the version number of the packet type. - A one-octet number giving the version number of the packet type.
The currently defined value for packet version is 3. An The currently defined value for packet version is 3. An
implementation should accept, but not generate a version of 2, implementation should accept, but not generate a version of 2,
which is equivalent to V3 in all other respects. which is equivalent to V3 in all other respects.
- An eight-octet number that gives the key ID of the public key - An eight-octet number that gives the key ID of the public key
that the session key is encrypted to. that the session key is encrypted to. If the session key is
encrypted to a subkey then the key ID of this subkey is used
here instead of the key ID of the primary key.
- A one-octet number giving the public key algorithm used. - A one-octet number giving the public key algorithm used.
- A string of octets that is the encrypted session key. This - A string of octets that is the encrypted session key. This
string takes up the remainder of the packet, and its contents string takes up the remainder of the packet, and its contents
are dependent on the public key algorithm used. are dependent on the public key algorithm used.
Algorithm Specific Fields for RSA encryption Algorithm Specific Fields for RSA encryption
- multiprecision integer (MPI) of RSA encrypted value m**e mod n. - multiprecision integer (MPI) of RSA encrypted value m**e mod n.
skipping to change at page 20, line 49 skipping to change at page 20, line 49
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.
Algorithm Specific Fields for ElGamal signatures:
- MPI of ElGamal value a = g**k mod p.
- MPI of ElGamal value b = (h-a*x)/k mod p-1.
The hash h is PKCS-1 padded exactly the same way as for the above
described RSA signatures.
With RSA signatures, the hash value is encoded as described in With RSA signatures, the hash value is encoded as described in
PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type
EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value
as an octet string into an ASN.1 structure. The object identifier as an octet string into an ASN.1 structure. The object identifier
for the type of hash being used is included in the structure. The for the type of hash being used is included in the structure. The
hexadecimal representations for the currently defined hash hexadecimal representations for the currently defined hash
algorithms are: algorithms are:
- MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 - MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
- SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
- SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
- SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
The ASN.1 OIDs are: The ASN.1 OIDs are:
- MD2: 1.2.840.113549.2.2 - MD2: 1.2.840.113549.2.2
- MD5: 1.2.840.113549.2.5 - MD5: 1.2.840.113549.2.5
- RIPEMD-160: 1.3.36.3.2.1 - RIPEMD-160: 1.3.36.3.2.1
- SHA-1: 1.3.14.3.2.26 - SHA-1: 1.3.14.3.2.26
- SHA256: 2.16.840.1.101.3.4.2.1
- SHA384: 2.16.840.1.101.3.4.2.2
- SHA512: 2.16.840.1.101.3.4.2.3
The full hash prefixes for these are: The full hash prefixes for these are:
MD2: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, MD2: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00,
0x04, 0x10 0x04, 0x10
MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
0x04, 0x10 0x04, 0x10
RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
0x00, 0x04, 0x20
SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
0x00, 0x04, 0x30
SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
0x00, 0x04, 0x40
DSA signatures MUST use hashes with a size of 160 bits, to match q, DSA signatures MUST use hashes with a size of 160 bits, to match q,
the size of the group generated by the DSA key's generator value. the size of the group generated by the DSA key's generator value.
The hash function result is treated as a 160 bit number and used The hash function result is treated as a 160 bit number and used
directly in the DSA signature algorithm. directly in the DSA signature algorithm.
5.2.3. Version 4 Signature Packet Format 5.2.3. Version 4 Signature Packet Format
The body of a version 4 Signature Packet contains: The body of a version 4 Signature Packet contains:
- One-octet version number (4). - One-octet version number (4).
skipping to change at page 28, line 45 skipping to change at page 29, line 34
Names in the user name space consist of a UTF-8 string tag followed Names in the user name space consist of a UTF-8 string tag followed
by "@" followed by a DNS domain name. Note that the tag MUST NOT by "@" followed by a DNS domain name. Note that the tag MUST NOT
contain an "@" character. For example, the "sample" tag used by contain an "@" character. For example, the "sample" tag used by
Example Corporation could be "sample@example.com". Example Corporation could be "sample@example.com".
Names in a user space are owned and controlled by the owners of that Names in a user space are owned and controlled by the owners of that
domain. Obviously, it's of bad form to create a new name in a DNS domain. Obviously, it's of bad form to create a new name in a DNS
space that you don't own. space that you don't own.
Since the user name space is in the form of an email address,
implementors MAY wish to arrange for that address to reach a person
who can be consulted about the use of the named tag. Note that due
to UTF-8 encoding, not all valid user space name tags are valid
email addresses.
5.2.3.17. Key server preferences 5.2.3.17. Key server preferences
(N octets of flags) (N octets of flags)
This is a list of flags that indicate preferences that the key This is a list of flags that indicate preferences that the key
holder has about how the key is handled on a key server. All holder has about how the key is handled on a key server. All
undefined flags MUST be zero. undefined flags MUST be zero.
First octet: 0x80 = No-modify First octet: 0x80 = No-modify
the key holder requests that this key only be modified or the key holder requests that this key only be modified or
skipping to change at page 31, line 19 skipping to change at page 32, line 16
An implementation SHOULD implement this subpacket, include it in all An implementation SHOULD implement this subpacket, include it in all
revocation signatures, and interpret revocations appropriately. revocation signatures, and interpret revocations appropriately.
There are important semantic differences between the reasons, and There are important semantic differences between the reasons, and
there are thus important reasons for revoking signatures. there are thus important reasons for revoking signatures.
If a key has been revoked because of a compromise, all signatures If a key has been revoked because of a compromise, all signatures
created by that key are suspect. However, if it was merely created by that key are suspect. However, if it was merely
superceded or retired, old signatures are still valid. If the superceded or retired, old signatures are still valid. If the
revoked signature is the self-signature for certifying a user id, a revoked signature is the self-signature for certifying a user id, a
revocation denotes that that user name is no longer in use. Such a revocation denotes that that user name is no longer in use. Such a
revocation SHOULD inclide an 0x20 subpacket. revocation SHOULD include an 0x20 subpacket.
Note that any signature may be revoked, including a certification on Note that any signature may be revoked, including a certification on
some other person's key. There are many good reasons for revoking a some other person's key. There are many good reasons for revoking a
certification signature, such as the case where the keyholder leaves certification signature, such as the case where the keyholder leaves
the employ of a business with an email address. A revoked the employ of a business with an email address. A revoked
certification no longer is a part of validity calculations. certification no longer is a part of validity calculations.
5.2.3.24. Features 5.2.3.24. Features
(array of one-octet values) (array of one-octet values)
skipping to change at page 31, line 44 skipping to change at page 32, line 41
state that they can use that feature. state that they can use that feature.
This subpacket is similar to a preferences subpacket, and only This subpacket is similar to a preferences subpacket, and only
appears in a self-signature. appears in a self-signature.
An implementation SHOULD NOT use a feature listed when sending to a An implementation SHOULD NOT use a feature listed when sending to a
user who does not state that they can use it. user who does not state that they can use it.
Defined features are: Defined features are:
1 - Modification Detection (packets 15 and 16) 1 - Modification Detection (packets 18 and 19)
If an implementation implements any of the defined features, it If an implementation implements any of the defined features, it
SHOULD implement the features subpacket, too. SHOULD implement the features subpacket, too.
5.2.4. Computing Signatures 5.2.4. Computing Signatures
All signatures are formed by producing a hash over the signature All signatures are formed by producing a hash over the signature
data, and then using the resulting hash in the signature algorithm. data, and then using the resulting hash in the signature algorithm.
The signature data is simple to compute for document signatures The signature data is simple to compute for document signatures
(types 0x00 and 0x01), for which the document itself is the data. (types 0x00 and 0x01), for which the document itself is the data.
For standalone signatures, this is a null string. For standalone signatures, this is a null string.
When a signature is made over a key, the hash data starts with the When a signature is made over a key, the hash data starts with the
octet 0x99, followed by a two-octet length of the key, and then body octet 0x99, followed by a two-octet length of the key, and then body
of the key packet. (Note that this is an old-style packet header for of the key packet. (Note that this is an old-style packet header for
a key packet with two-octet length.) A subkey signature (type 0x18) a key packet with two-octet length.) A subkey signature (type 0x18)
then hashes the subkey, using the same format as the main key. Key then hashes the subkey, using the same format as the main key (also
revocation signatures (types 0x20 and 0x28) hash only the key being using 0x99 as the first octet). Key revocation signatures (types
revoked. 0x20 and 0x28) hash only the key being revoked.
A certification signature (type 0x10 through 0x13) hashes the user A certification signature (type 0x10 through 0x13) hashes the user
id being bound to the key into the hash context after the above id being bound to the key into the hash context after the above
data. A V3 certification hashes the contents of the name packet, data. A V3 certification hashes the contents of the name packet,
without any header. A V4 certification hashes the constant 0xb4 without any header. A V4 certification hashes the constant 0xb4
(which is an old-style packet header with the length-of-length set (which is an old-style packet header with the length-of-length set
to zero), a four-octet number giving the length of the username, and to zero), a four-octet number giving the length of the username, and
then the username data. then the username data.
Once the data body is hashed, then a trailer is hashed. A V3 Once the data body is hashed, then a trailer is hashed. A V3
skipping to change at page 37, line 54 skipping to change at page 38, line 47
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, Initial Vector (IV) of - [Optional] If secret data is encrypted, Initial Vector (IV) of
the same length as the cipher's block size. 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). This checksum is
encrypted together with the algorithm- specific fields.
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.
- MPI of RSA secret prime value p. - MPI of RSA secret prime value p.
- MPI of RSA secret prime value q (p < q). - MPI of RSA secret prime value q (p < q).
- MPI of u, the multiplicative inverse of p, mod q. - MPI of u, the multiplicative inverse of p, mod q.
skipping to change at page 41, line 31 skipping to change at page 42, line 29
other than local keyring files. other than local keyring files.
5.11. User ID Packet (Tag 13) 5.11. User ID Packet (Tag 13)
A User ID packet consists of data that is intended to represent the A User ID packet consists of data that is intended to represent the
name and email address of the key holder. By convention, it name and email address of the key holder. By convention, it
includes an RFC822 mail name, but there are no restrictions on its includes an RFC822 mail name, but there are no restrictions on its
content. The packet length in the header specifies the length of content. The packet length in the header specifies the length of
the user id. If it is text, it is encoded in UTF-8. the user id. If it is text, it is encoded in UTF-8.
5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 15) 5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 18)
The Symmetrically Encrypted Integrity Protected Data Packet is a The Symmetrically Encrypted Integrity Protected Data Packet is a
variant of the Symmetrically Encrypted Data Packet. It is a new variant of the Symmetrically Encrypted Data Packet. It is a new
feature created for OpenPGP that addresses the problem of detecting feature created for OpenPGP that addresses the problem of detecting
a modification to encrypted data. It is used in combination with a a modification to encrypted data. It is used in combination with a
Modification Detection Code Packet. Modification Detection Code Packet.
There is a corresponding feature in the features signature subpacket There is a corresponding feature in the features signature subpacket
that denotes that an implementation can properly use this packet that denotes that an implementation can properly use this packet
type. An implementation SHOULD NOT use this packet when encrypting type. An implementation SHOULD NOT use this packet when encrypting
skipping to change at page 42, line 28 skipping to change at page 43, line 25
The data is encrypted in CFB mode, with a CFB shift size equal to The data is encrypted in CFB mode, with a CFB shift size equal to
the cipher's block size. The Initial Vector (IV) is specified as the cipher's block size. The Initial Vector (IV) is specified as
all zeros. Instead of using an IV, OpenPGP prefixes an octet string all zeros. Instead of using an IV, OpenPGP prefixes an octet string
to the data before it is encrypted. The length of the octet string to the data before it is encrypted. The length of the octet string
equals the block size of the cipher in octets, plus two. The first equals the block size of the cipher in octets, plus two. The first
octets in the group, of length equal to the block size of the octets in the group, of length equal to the block size of the
cipher, are random; the last two octets are each copies of their 2nd cipher, are random; the last two octets are each copies of their 2nd
preceding octet. For example, with a cipher whose block size is 128 preceding octet. For example, with a cipher whose block size is 128
bits or 16 octets, the prefix data will contain 16 random octets, bits or 16 octets, the prefix data will contain 16 random octets,
then two more octets, which are copies of the 15th and 16th octets, then two more octets, which are copies of the 15th and 16th octets,
respectivelly. Unlike the Symmetrically Encrypted Data Packet, no respectively. Unlike the Symmetrically Encrypted Data Packet, no
special CFB resynchronization is done after encrypting this prefix special CFB resynchronization is done after encrypting this prefix
data. data.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. incorrect.
The plaintext of the data to be encrypted is passed through the The plaintext of the data to be encrypted is passed through the
SHA-1 hash function, and the result of the hash is appended to the SHA-1 hash function, and the result of the hash is appended to the
plaintext in a Modification Detection Code packet. Specifically, plaintext in a Modification Detection Code packet. Specifically,
skipping to change at page 43, line 14 skipping to change at page 44, line 11
SHA-1 hash. Any difference in hash values is an indication that the SHA-1 hash. Any difference in hash values is an indication that the
message has been modified and SHOULD be reported to the user. message has been modified and SHOULD be reported to the user.
Likewise, the absence of an MDC packet, or an MDC packet in any Likewise, the absence of an MDC packet, or an MDC packet in any
position other than the end of the plaintext, also represent message position other than the end of the plaintext, also represent message
modifications and SHOULD also be reported. modifications and SHOULD also be reported.
Note: future designs of new versions of this packet should consider Note: future designs of new versions of this packet should consider
rollback attacks since it will be possible for an attacker to change rollback attacks since it will be possible for an attacker to change
the version back to 1. the version back to 1.
5.13. Modification Detection Code Packet (Tag 16) 5.13. Modification Detection Code Packet (Tag 19)
The Modification Detection Code packet contains a SHA-1 hash of The Modification Detection Code packet contains a SHA-1 hash of
plaintext data which is used to detect message modification. It is plaintext data which is used to detect message modification. It is
only used with a Symmetrically Encrypted Integrity Protected Data only used with a Symmetrically Encrypted Integrity Protected Data
packet. The Modification Detection Code packet MUST be the last packet. The Modification Detection Code packet MUST be the last
packet in the plaintext data which is encrypted in the Symmetrically packet in the plaintext data which is encrypted in the Symmetrically
Encrypted Integrity Protected Data packet, and MUST appear in no Encrypted Integrity Protected Data packet, and MUST appear in no
other place. other place.
A Modification Detection Code packet MUST have a length of 20 A Modification Detection Code packet MUST have a length of 20
skipping to change at page 51, line 54 skipping to change at page 52, line 50
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 [AES] 6 - Reserved for DES/SK [AES]
7 - AES with 128-bit key 7 - AES with 128-bit key
8 - AES with 192-bit key 8 - AES with 192-bit key
9 - AES with 256-bit key 9 - 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.
Implementations MUST implement Triple-DES. Implementations SHOULD Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.Implementations MAY implement any other implement AES-128 and CAST5. Implementations that interoperate with
algorithm. PGP 2.6 or earlier need to support IDEA, as that is the only
symmetric cipher those versions use. Implementations MAY implement
any other algorithm.
9.3. Compression Algorithms 9.3. Compression Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Uncompressed 0 - Uncompressed
1 - ZIP (RFC1951) 1 - ZIP (RFC1951)
2 - ZLIB (RFC1950) 2 - ZLIB (RFC1950)
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement uncompressed data. Implementations Implementations MUST implement uncompressed data. Implementations
SHOULD implement ZIP. Implementations MAY implement ZLIB. SHOULD implement ZIP. Implementations MAY implement ZLIB.
9.4. Hash Algorithms 9.4. Hash Algorithms
ID Algorithm Text Name ID Algorithm Text Name
-- --------- ---- ---- -- --------- ---- ----
1 - MD5 "MD5" 1 - MD5 "MD5"
2 - SHA-1 "SHA1" 2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160" 3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved for double-width SHA (experimental) 4 - Reserved for double-width SHA (experimental,
obviated)
5 - MD2 "MD2" 5 - MD2 "MD2"
6 - Reserved for TIGER/192 "TIGER192" 6 - Reserved for TIGER/192 "TIGER192"
7 - Reserved for HAVAL (5 pass, 160-bit) "HAVAL-5-160" 7 - Reserved for HAVAL (5 pass, 160-bit) "HAVAL-5-160"
8 - SHA256 "SHA256"
9 - SHA384 "SHA384"
10 - SHA512 "SHA512"
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations SHOULD Implementations MUST implement SHA-1. Implementations SHOULD
implement MD5. implement MD5.
10. Packet Composition 10. Packet Composition
OpenPGP packets are assembled into sequences in order to create OpenPGP packets are assembled into sequences in order to create
messages and to transfer keys. Not all possible packet sequences messages and to transfer keys. Not all possible packet sequences
are meaningful and correct. This describes the rules for how are meaningful and correct. This describes the rules for how
skipping to change at page 56, line 25 skipping to change at page 57, line 33
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.
Finally, the key ID and fingerprint of a subkey are calculated in
the same way as for a primary key, including the 0x99 as the first
byte (even though this is not a valid packet ID for a public
subkey).
12. Notes on Algorithms 12. Notes on Algorithms
12.1. Symmetric Algorithm Preferences 12.1. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature, that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have different preferences. For it is possible that a keyholder may have different preferences. For
example, Alice may have TripleDES only specified for example, Alice may have TripleDES only specified for
"alice@work.com" but CAST5, Blowfish, and TripleDES specified for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for
"alice@home.org". Note that it is also possible for preferences to "alice@home.org". Note that it is also possible for preferences to
skipping to change at page 58, line 44 skipping to change at page 60, line 7
It is permissible for an implementation to support RSA merely for It is permissible for an implementation to support RSA merely for
backward compatibility; for example, such an implementation would backward compatibility; for example, such an implementation would
support V3 keys with IDEA symmetric cryptography. Note that this is support V3 keys with IDEA symmetric cryptography. Note that this is
an exception to the other MUST-implement rules. An implementation an exception to the other MUST-implement rules. An implementation
that supports RSA in V4 keys MUST implement the MUST-implement that supports RSA in V4 keys MUST implement the MUST-implement
features. features.
12.5. Elgamal 12.5. Elgamal
If an Elgamal key is to be used for both signing and encryption, If an Elgamal key [ELGAMAL] is to be used for both signing and
extra care must be taken in creating the key. encryption, extra care must be taken in creating the key.
An ElGamal key consists of a generator g, a prime modulus p, a An Elgamal key consists of a generator g, a prime modulus p, a
secret exponent x, and a public value y = g^x mod p. secret exponent x, and a public value y = g^x mod p.
The generator and prime must be chosen so that solving the discrete The generator and prime must be chosen so that solving the discrete
log problem is intractable. The group g should generate the log problem is intractable. The group g should generate the
multiplicative group mod p-1 or a large subgroup of it, and the multiplicative group mod p-1 or a large subgroup of it, and the
order of g should have at least one large prime factor. A good order of g should have at least one large prime factor. A good
choice is to use a "strong" Sophie-Germain prime in choosing p, so choice is to use a "strong" Sophie-Germain prime in choosing p, so
that both p and (p-1)/2 are primes. In fact, this choice is so good that both p and (p-1)/2 are primes. In fact, this choice is so good
that implementers SHOULD do it, as it avoids a small subgroup that implementers SHOULD do it, as it avoids a small subgroup
attack. attack.
skipping to change at page 59, line 20 skipping to change at page 60, line 36
be even. On the other hand, a generator of 2 is a fine choice for an be even. On the other hand, a generator of 2 is a fine choice for an
encryption-only key, as this will make the encryption faster. encryption-only key, as this will make the encryption faster.
While verifying Elgamal signatures, note that it is important to While verifying Elgamal signatures, note that it is important to
test that r and s are less than p. If this test is not done then test that r and s are less than p. If this test is not done then
signatures can be trivially forged by using large r values of signatures can be trivially forged by using large r values of
approximately twice the length of p. This attack is also discussed approximately twice the length of p. This attack is also discussed
in the Bleichenbacher paper. in the Bleichenbacher paper.
Details on safe use of Elgamal signatures may be found in [MENEZES], Details on safe use of Elgamal signatures may be found in [MENEZES],
which discusses all the weaknesses described above. which discusses all the weaknesses described above. Please note that
Elgamal signatures are controversial; because of the care that must
be taken with Elgamal keys, many implementations forego them.
If an implementation allows Elgamal signatures, then it MUST use the If an implementation allows Elgamal signatures, then it MUST use the
algorithm identifier 20 for an Elgamal public key that can sign. algorithm identifier 20 for an Elgamal public key that can sign.
An implementation SHOULD NOT implement Elgamal keys of size less An implementation SHOULD NOT implement Elgamal keys of size less
than 768 bits. For long-term security, Elgamal keys should be 1024 than 768 bits. For long-term security, Elgamal keys should be 1024
bits or longer. bits or longer.
12.6. DSA 12.6. DSA
skipping to change at page 64, line 15 skipping to change at page 65, line 31
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. Wave Systems Corp.
3031 Tisch Way, suite 100 East Plaza 1601 S. DeAnza Blvd, Suite 200
San Jose, CA 95128, USA Cupertino, CA 95014, USA
Email: jon@callas.org, jon@counterpane.com Email: jon@callas.org, jcallas@wavesys.com
Tel: +1 (408) 556-2445 Tel: +1 (408) 448-6801
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
skipping to change at page 66, line 38 skipping to change at page 68, line 4
Unicode and ISO 10646", RFC 2279, January 1998. Unicode and ISO 10646", RFC 2279, January 1998.
[RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA [RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA
Cryptography Specifications Version 2.0", Cryptography Specifications Version 2.0",
RFC 2437, October 1998. RFC 2437, October 1998.
[SAFER] Massey, J.L. "SAFER K-64: One Year Later", B. [SAFER] Massey, J.L. "SAFER K-64: One Year Later", B.
Preneel, editor, Fast Software Encryption, Second Preneel, editor, Fast Software Encryption, Second
International Workshop (LNCS 1008) pp212-241, International Workshop (LNCS 1008) pp212-241,
Springer-Verlag 1995 Springer-Verlag 1995
[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 2000 by The Internet Society. All Rights Reserved. Copyright 2001 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/