draft-ietf-openpgp-rfc2440bis-03.txt   draft-ietf-openpgp-rfc2440bis-04.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Wave Systems Corporation Category: INTERNET-DRAFT Wave Systems Corporation
draft-ietf-openpgp-rfc2440bis-03.txt draft-ietf-openpgp-rfc2440bis-04.txt
Expires Feb 2002 Lutz Donnerhacke Expires Oct 2002 Lutz Donnerhacke
August 2001 IN-Root-CA Individual Network e.V. April 2002 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-03.txt draft-ietf-openpgp-rfc2440bis-04.txt
Copyright 2001 by The Internet Society. All Rights Reserved. Copyright 2002 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 2, line 16 skipping to change at page 2, line 16
This document is maintained in order to publish all necessary This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions. network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid It does, however, discuss implementation issues necessary to avoid
security flaws. security flaws.
Open-PGP software uses a combination of strong public-key and OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic symmetric cryptography to provide security services for electronic
communications and data storage. These services include communications and data storage. These services include
confidentiality, key management, authentication, and digital confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in signatures. This document specifies the message formats used in
OpenPGP. OpenPGP.
Table of Contents Table of Contents
Status of this Memo 1 Status of this Memo 1
IESG Note 1 IESG Note 1
Abstract 2 Abstract 2
Table of Contents 3 Table of Contents 3
1. Introduction 6 1. Introduction 6
1.1. Terms 6 1.1. Terms 6
2. General functions 6 2. General functions 6
2.1. Confidentiality via Encryption 6 2.1. Confidentiality via Encryption 6
2.2. Authentication via Digital signature 7 2.2. Authentication via Digital signature 7
2.3. Compression 8 2.3. Compression 8
2.4. Conversion to Radix-64 8 2.4. Conversion to Radix-64 8
2.5. Signature-Only Applications 8 2.5. Signature-Only Applications 8
3. Data Element Formats 9 3. Data Element Formats 8
3.1. Scalar numbers 9 3.1. Scalar numbers 8
3.2. Multi-Precision Integers 9 3.2. Multi-Precision Integers 9
3.3. Key IDs 9 3.3. Key IDs 9
3.4. Text 9 3.4. Text 9
3.5. Time fields 10 3.5. Time fields 9
3.6. Keyrings 10 3.6. Keyrings 10
3.7. String-to-key (S2K) specifiers 10 3.7. String-to-key (S2K) specifiers 10
3.7.1. String-to-key (S2k) specifier types 10 3.7.1. String-to-key (S2k) specifier types 10
3.7.1.1. Simple S2K 10 3.7.1.1. Simple S2K 10
3.7.1.2. Salted S2K 11 3.7.1.2. Salted S2K 10
3.7.1.3. Iterated and Salted S2K 11 3.7.1.3. Iterated and Salted S2K 11
3.7.2. String-to-key usage 12 3.7.2. String-to-key usage 11
3.7.2.1. Secret key encryption 12 3.7.2.1. Secret key encryption 12
3.7.2.2. Symmetric-key message encryption 12 3.7.2.2. Symmetric-key message encryption 12
4. Packet Syntax 12 4. Packet Syntax 12
4.1. Overview 13 4.1. Overview 12
4.2. Packet Headers 13 4.2. Packet Headers 13
4.2.1. Old-Format Packet Lengths 13 4.2.1. Old-Format Packet Lengths 13
4.2.2. New-Format Packet Lengths 14 4.2.2. New-Format Packet Lengths 14
4.2.2.1. One-Octet Lengths 14 4.2.2.1. One-Octet Lengths 14
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 14
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 22 5.2.3. Version 4 Signature Packet Format 22
5.2.3.1. Signature Subpacket Specification 23 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 25 5.2.3.3. Notes on Self-Signatures 25
5.2.3.4. Signature creation time 25 5.2.3.4. Signature creation time 26
5.2.3.5. Issuer 26 5.2.3.5. Issuer 26
5.2.3.6. Key expiration time 26 5.2.3.6. Key expiration time 26
5.2.3.7. Preferred symmetric algorithms 26 5.2.3.7. Preferred symmetric algorithms 26
5.2.3.8. Preferred hash algorithms 26 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 27 5.2.3.10.Signature expiration time 27
5.2.3.11.Exportable Certification 27 5.2.3.11.Exportable Certification 27
5.2.3.12.Revocable 27 5.2.3.12.Revocable 27
5.2.3.13.Trust signature 27 5.2.3.13.Trust signature 28
5.2.3.14.Regular expression 28 5.2.3.14.Regular expression 28
5.2.3.15.Revocation key 28 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 29 5.2.3.17.Key server preferences 29
5.2.3.18.Preferred key server 30 5.2.3.18.Preferred key server 30
5.2.3.19.Primary user id 30 5.2.3.19.Primary user id 30
5.2.3.20.Policy URL 30 5.2.3.20.Policy URL 30
5.2.3.21.Key Flags 30 5.2.3.21.Key Flags 30
5.2.3.22.Signer's User ID 31 5.2.3.22.Signer's User ID 31
5.2.3.23.Reason for Revocation 31 5.2.3.23.Reason for Revocation 31
5.2.3.24.Features 32 5.2.3.24.Features 32
5.2.4. Computing Signatures 32 5.2.4. Computing Signatures 33
5.2.4.1. Subpacket Hints 33 5.2.4.1. Subpacket Hints 34
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 34 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 34
5.4. One-Pass Signature Packets (Tag 4) 35 5.4. One-Pass Signature Packets (Tag 4) 35
5.5. Key Material Packet 35 5.5. Key Material Packet 36
5.5.1. Key Packet Variants 35 5.5.1. Key Packet Variants 36
5.5.1.1. Public Key Packet (Tag 6) 35 5.5.1.1. Public Key Packet (Tag 6) 36
5.5.1.2. Public Subkey Packet (Tag 14) 36 5.5.1.2. Public Subkey Packet (Tag 14) 36
5.5.1.3. Secret Key Packet (Tag 5) 36 5.5.1.3. Secret Key Packet (Tag 5) 36
5.5.1.4. Secret Subkey Packet (Tag 7) 36 5.5.1.4. Secret Subkey Packet (Tag 7) 36
5.5.2. Public Key Packet Formats 36 5.5.2. Public Key Packet Formats 37
5.5.3. Secret Key Packet Formats 38 5.5.3. Secret Key Packet Formats 38
5.6. Compressed Data Packet (Tag 8) 39 5.6. Compressed Data Packet (Tag 8) 40
5.7. Symmetrically Encrypted Data Packet (Tag 9) 40 5.7. Symmetrically Encrypted Data Packet (Tag 9) 40
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 41 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 41
5.9. Literal Data Packet (Tag 11) 41 5.9. Literal Data Packet (Tag 11) 42
5.10. Trust Packet (Tag 12) 42 5.10. Trust Packet (Tag 12) 42
5.11. User ID Packet (Tag 13) 42 5.11. User ID Packet (Tag 13) 42
5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 42 5.12. User Attribute Packet (Tag 17) 43
5.13. Modification Detection Code Packet (Tag 19) 44 5.12.1. The Image Attribute Subpacket 43
6. Radix-64 Conversions 44 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 44
6.1. An Implementation of the CRC-24 in "C" 45 5.14. Modification Detection Code Packet (Tag 19) 45
6.2. Forming ASCII Armor 45 6. Radix-64 Conversions 46
6.3. Encoding Binary in Radix-64 47 6.1. An Implementation of the CRC-24 in "C" 47
6.4. Decoding Radix-64 49 6.2. Forming ASCII Armor 47
6.5. Examples of Radix-64 49 6.3. Encoding Binary in Radix-64 49
6.6. Example of an ASCII Armored Message 50 6.4. Decoding Radix-64 51
7. Cleartext signature framework 50 6.5. Examples of Radix-64 51
7.1. Dash-Escaped Text 50 6.6. Example of an ASCII Armored Message 51
8. Regular Expressions 51 7. Cleartext signature framework 52
9. Constants 51 7.1. Dash-Escaped Text 52
9.1. Public Key Algorithms 52 8. Regular Expressions 53
9.2. Symmetric Key Algorithms 52 9. Constants 53
9.3. Compression Algorithms 53 9.1. Public Key Algorithms 54
9.4. Hash Algorithms 53 9.2. Symmetric Key Algorithms 54
10. Packet Composition 53 9.3. Compression Algorithms 54
10.1. Transferable Public Keys 53 9.4. Hash Algorithms 55
10.2. OpenPGP Messages 54 10. Packet Composition 55
10.3. Detached Signatures 55 10.1. Transferable Public Keys 55
11. Enhanced Key Formats 55 10.2. OpenPGP Messages 57
11.1. Key Structures 55 10.3. Detached Signatures 57
11.2. Key IDs and Fingerprints 56 11. Enhanced Key Formats 57
12. Notes on Algorithms 57 11.1. Key Structures 57
12.1. Symmetric Algorithm Preferences 57 11.2. Key IDs and Fingerprints 58
12.2. Other Algorithm Preferences 58 12. Notes on Algorithms 59
12.2.1. Compression Preferences 58 12.1. Symmetric Algorithm Preferences 59
12.2.2. Hash Algorithm Preferences 59 12.2. Other Algorithm Preferences 60
12.3. Plaintext 59 12.2.1. Compression Preferences 60
12.4. RSA 59 12.2.2. Hash Algorithm Preferences 61
12.5. Elgamal 60 12.3. Plaintext 61
12.6. DSA 60 12.4. RSA 61
12.7. Reserved Algorithm Numbers 60 12.5. Elgamal 62
12.8. OpenPGP CFB mode 61 12.6. DSA 62
13. Security Considerations 62 12.7. Reserved Algorithm Numbers 63
14. Implementation Nits 63 12.8. OpenPGP CFB mode 63
15. Authors and Working Group Chair 65 13. Security Considerations 64
16. References 66 14. Implementation Nits 66
17. Full Copyright Statement 68 15. Authors and Working Group Chair 67
16. References 68
17. Full Copyright Statement 70
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 6, line 56 skipping to change at page 6, line 56
- compression - compression
- radix-64 conversion - radix-64 conversion
In addition, OpenPGP provides key management and certificate In addition, OpenPGP provides key management and certificate
services, but many of these are beyond the scope of this document. services, but many of these are beyond the scope of this document.
2.1. Confidentiality via Encryption 2.1. Confidentiality via Encryption
OpenPGP uses two encryption methods to provide confidentiality: OpenPGP combines symmetric-key encryption and public key encryption
to provide confidentiality. When made confidential, first the object
symmetric-key encryption and public key encryption. With public-key is encrypted using a symmetric encryption algorithm. Each symmetric
encryption, the object is encrypted using a symmetric encryption key is used only once, for a single object. A new "session key" is
algorithm. Each symmetric key is used only once. A new "session generated as a random number for each object (sometimes referred to
key" is generated as a random number for each message. Since it is as a session). Since it is used only once, the session key is bound
used only once, the session key is bound to the message and to the message and transmitted with it. To protect the key, it is
transmitted with it. To protect the key, it is encrypted with the encrypted with the receiver's public key. The sequence is as
receiver's public key. The sequence is as follows: follows:
1. The sender creates a message. 1. The sender creates a message.
2. The sending OpenPGP generates a random number to be used as a 2. The sending OpenPGP generates a random number to be used as a
session key for this message only. session key for this message only.
3. The session key is encrypted using each recipient's public key. 3. The session key is encrypted using each recipient's public key.
These "encrypted session keys" start the message. These "encrypted session keys" start the message.
4. The sending OpenPGP encrypts the message using the session key, 4. The sending OpenPGP encrypts the message using the session key,
skipping to change at page 8, line 41 skipping to change at page 8, line 41
Some systems only permit the use of blocks consisting of seven-bit, Some systems only permit the use of blocks consisting of seven-bit,
printable text. For transporting OpenPGP's native raw binary octets printable text. For transporting OpenPGP's native raw binary octets
through channels that are not safe to raw binary data, a printable through channels that are not safe to raw binary data, a printable
encoding of these binary octets is needed. OpenPGP provides the encoding of these binary octets is needed. OpenPGP provides the
service of converting the raw 8-bit binary octet stream to a stream service of converting the raw 8-bit binary octet stream to a stream
of printable ASCII characters, called Radix-64 encoding or ASCII of printable ASCII characters, called Radix-64 encoding or ASCII
Armor. Armor.
Implementations SHOULD provide Radix-64 conversions. Implementations SHOULD provide Radix-64 conversions.
Note that many applications, particularly messaging applications,
will want more advanced features as described in the OpenPGP-MIME
document, RFC2015. An application that implements OpenPGP for
messaging SHOULD implement OpenPGP-MIME.
2.5. Signature-Only Applications 2.5. Signature-Only Applications
OpenPGP is designed for applications that use both encryption and OpenPGP is designed for applications that use both encryption and
signatures, but there are a number of problems that are solved by a signatures, but there are a number of problems that are solved by a
signature-only implementation. Although this specification requires signature-only implementation. Although this specification requires
both encryption and signatures, it is reasonable for there to be both encryption and signatures, it is reasonable for there to be
subset implementations that are non-comformant only in that they subset implementations that are non-comformant only in that they
omit encryption. omit encryption.
3. Data Element Formats 3. Data Element Formats
skipping to change at page 10, line 41 skipping to change at page 10, line 36
This directly hashes the string to produce the key data. See below This directly hashes the string to produce the key data. See below
for how this hashing is done. for how this hashing is done.
Octet 0: 0x00 Octet 0: 0x00
Octet 1: hash algorithm Octet 1: hash algorithm
Simple S2K hashes the passphrase to produce the session key. The Simple S2K hashes the passphrase to produce the session key. The
manner in which this is done depends on the size of the session key manner in which this is done depends on the size of the session key
(which will depend on the cipher used) and the size of the hash (which will depend on the cipher used) and the size of the hash
algorithm's output. If the hash size is greater than or equal to the algorithm's output. If the hash size is greater than the session key
session key size, the high-order (leftmost) octets of the hash are size, the high-order (leftmost) octets of the hash are used as the
used as the key. key.
If the hash size is less than the key size, multiple instances of If the hash size is less than the key size, multiple instances of
the hash context are created -- enough to produce the required key the hash context are created -- enough to produce the required key
data. These instances are preloaded with 0, 1, 2, ... octets of data. These instances are preloaded with 0, 1, 2, ... octets of
zeros (that is to say, the first instance has no preloading, the zeros (that is to say, the first instance has no preloading, the
second gets preloaded with 1 octet of zero, the third is preloaded second gets preloaded with 1 octet of zero, the third is preloaded
with two octets of zeros, and so forth). with two octets of zeros, and so forth).
As the data is hashed, it is given independently to each hash As the data is hashed, it is given independently to each hash
context. Since the contexts have been initialized differently, they context. Since the contexts have been initialized differently, they
skipping to change at page 15, line 14 skipping to change at page 15, line 9
4.2.2.3. Five-Octet Lengths 4.2.2.3. Five-Octet Lengths
A five-octet Body Length header consists of a single octet holding A five-octet Body Length header consists of a single octet holding
the value 255, followed by a four-octet scalar. The body length is the value 255, followed by a four-octet scalar. The body length is
equal to: equal to:
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet (4th_octet << 8) | 5th_octet
This basic set of one, two, and five-octet lengths is also used
internally to some packets.
4.2.2.4. Partial Body Lengths 4.2.2.4. Partial Body Lengths
A Partial Body Length header is one octet long and encodes the A Partial Body Length header is one octet long and encodes the
length of only part of the data packet. This length is a power of 2, length of only part of the data packet. This length is a power of 2,
from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by
its one octet value that is greater than or equal to 224, and less its one octet value that is greater than or equal to 224, and less
than 255. The partial body length is equal to: than 255. The partial body length is equal to:
partialBodyLen = 1 << (1st_octet & 0x1f); partialBodyLen = 1 << (1st_octet & 0x1f);
skipping to change at page 16, line 36 skipping to change at page 16, line 32
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
18 -- Symmetrically Encrypted and Integrity Protected Data 17 -- User Attribute Packet
Packet 18 -- Sym. Encrypted and Integrity Protected Data Packet
19 -- 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
skipping to change at page 25, line 34 skipping to change at page 25, line 34
Implementing software should interpret a self-signature's preference Implementing software should interpret a self-signature's preference
subpackets as narrowly as possible. For example, suppose a key has subpackets as narrowly as possible. For example, suppose a key has
two usernames, Alice and Bob. Suppose that Alice prefers the two usernames, Alice and Bob. Suppose that Alice prefers the
symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If
the software locates this key via Alice's name, then the preferred the software locates this key via Alice's name, then the preferred
algorithm is CAST5, if software locates the key via Bob's name, then algorithm is CAST5, if software locates the key via Bob's name, then
the preferred algorithm is IDEA. If the key is located by key id, the preferred algorithm is IDEA. If the key is located by key id,
then algorithm of the default user id of the key provides the then algorithm of the default user id of the key provides the
default symmetric algorithm. default symmetric algorithm.
Revoking a self-signature has defined semantic meanings. Revoking Revoking a self-signature has a defined semantic meaning. Revoking
the self-signature on a certification effectively retires that user the self-signature on a user ID effectively retires that user name.
name. The self-signature is a statement, "My name X is tied to my The self-signature is a statement, "My name X is tied to my signing
signing key K" and is corroborated by other users' certifications. key K" and is corroborated by other users' certifications. If
If another user revokes their certification, they are effectively another user revokes their certification, they are effectively
saying that they no longer believe that name and that key are tied saying that they no longer believe that name and that key are tied
together. Similarly, if the user themselves revokes their together. Similarly, if the user themselves revokes their
self-signature, it means the user no longer goes by that name, no self-signature, it means the user no longer goes by that name, no
longer has that email address, etc. Revoking a binding signature longer has that email address, etc. Revoking a binding signature
effectively retires that subkey. Please see the "Reason for effectively retires that subkey. Please see the "Reason for
Revocation" subpacket below for more relevant detail. Revocation" subpacket below for more relevant detail.
Since a self-signatures contain important information about the Since a self-signature contains important information about the
key's use, an implementation SHOULD allow the user to rewrite the key's use, an implementation SHOULD allow the user to rewrite the
self-signature, and important information in it, such as preferences self-signature, and important information in it, such as preferences
and key expiration. and key expiration.
An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but it
is RECOMMENDED that priority be given to the most recent
self-signature.
5.2.3.4. Signature creation time 5.2.3.4. Signature creation time
(4 octet time field) (4 octet time field)
The time the signature was made. The time the signature was made.
MUST be present in the hashed area. MUST be present in the hashed area.
5.2.3.5. Issuer 5.2.3.5. Issuer
(8 octet key ID) (8 octet key ID)
The OpenPGP key ID of the key issuing the signature. The OpenPGP key ID of the key issuing the signature.
skipping to change at page 29, line 4 skipping to change at page 29, line 7
signature from that revoker. Note that it may be appropriate to signature from that revoker. Note that it may be appropriate to
isolate this subpacket within a separate signature so that it is not isolate this subpacket within a separate signature so that it is not
combined with other subpackets that need to be exported. combined with other subpackets that need to be exported.
5.2.3.16. Notation Data 5.2.3.16. Notation Data
(4 octets of flags, 2 octets of name length (M), (4 octets of flags, 2 octets of name length (M),
2 octets of value length (N), 2 octets of value length (N),
M octets of name data, M octets of name data,
N octets of value data) N octets of value data)
This subpacket describes a "notation" on the signature that the This subpacket describes a "notation" on the signature that the
issuer wishes to make. The notation has a name and a value, each of issuer wishes to make. The notation has a name and a value, each of
which are strings of octets. There may be more than one notation in which are strings of octets. There may be more than one notation in
a signature. Notations can be used for any extension the issuer of a signature. Notations can be used for any extension the issuer of
the signature cares to make. The "flags" field holds four octets of the signature cares to make. The "flags" field holds four octets of
flags. flags.
All undefined flags MUST be zero. Defined flags are: All undefined flags MUST be zero. Defined flags are:
First octet: 0x80 = human-readable. This note is text, a note First octet: 0x80 = human-readable. This note value is text, a
note
from one person to another, and has no from one person to another, and has no
meaning to software. meaning to software.
Other octets: none. Other octets: none.
Notation names are arbitrary strings encoded in UTF-8. They reside Notation names are arbitrary strings encoded in UTF-8. They reside
two name spaces: The IETF name space and the user name space. two name spaces: The IETF name space and the user name space.
The IETF name space is registered with IANA. These names MUST NOT The IETF name space is registered with IANA. These names MUST NOT
contain the "@" character (0x40) is this is a tag for the user name contain the "@" character (0x40) is this is a tag for the user name
space. space.
skipping to change at page 30, line 24 skipping to change at page 30, line 26
5.2.3.19. Primary user id 5.2.3.19. Primary user id
(1 octet, boolean) (1 octet, boolean)
This is a flag in a user id's self signature that states whether This is a flag in a user id's self signature that states whether
this user id is the main user id for this key. It is reasonable for this user id is the main user id for this key. It is reasonable for
an implementation to resolve ambiguities in preferences, etc. by an implementation to resolve ambiguities in preferences, etc. by
referring to the primary user id. If this flag is absent, its value referring to the primary user id. If this flag is absent, its value
is zero. If more than one user id in a key is marked as primary, the is zero. If more than one user id in a key is marked as primary, the
implementation may resolve the ambiguity in any way it sees fit. implementation may resolve the ambiguity in any way it sees fit, but
it is RECOMMENDED that priority be given to the user ID with the
most recent self-signature.
When appearing on a self-signature on a User ID packet, this
subpacket applies only to User ID packets. When appearing on a
self-signature on a User Attribute packet, this subpacket applies
only to User Attribute packets. That is to say, there are two
different and independent "primaries" - one for User IDs, and one
for User Attributes.
5.2.3.20. Policy URL 5.2.3.20. Policy URL
(String) (String)
This subpacket contains a URL of a document that describes the This subpacket contains a URL of a document that describes the
policy that the signature was issued under. policy that the signature was issued under.
5.2.3.21. Key Flags 5.2.3.21. Key Flags
(Octet string) (N octets of flags)
This subpacket contains a list of binary flags that hold information This subpacket contains a list of binary flags that hold information
about a key. It is a string of octets, and an implementation MUST about a key. It is a string of octets, and an implementation MUST
NOT assume a fixed size. This is so it can grow over time. If a list NOT assume a fixed size. This is so it can grow over time. If a list
is shorter than an implementation expects, the unstated flags are is shorter than an implementation expects, the unstated flags are
considered to be zero. The defined flags are: considered to be zero. The defined flags are:
First octet: First octet:
0x01 - This key may be used to certify other keys. 0x01 - This key may be used to certify other keys.
skipping to change at page 31, line 31 skipping to change at page 31, line 42
may change. may change.
The "split key" (0x10) and "group key" (0x80) flags are placed on a The "split key" (0x10) and "group key" (0x80) flags are placed on a
self-signature only; they are meaningless on a certification self-signature only; they are meaningless on a certification
signature. They SHOULD be placed only on a direct-key signature signature. They SHOULD be placed only on a direct-key signature
(type 0x1f) or a subkey signature (type 0x18), one that refers to (type 0x1f) or a subkey signature (type 0x18), one that refers to
the key the flag applies to. the key the flag applies to.
5.2.3.22. Signer's User ID 5.2.3.22. Signer's User ID
(String)
This subpacket allows a keyholder to state which user id is This subpacket allows a keyholder to state which user id is
responsible for the signing. Many keyholders use a single key for responsible for the signing. Many keyholders use a single key for
different purposes, such as business communications as well as different purposes, such as business communications as well as
personal communications. This subpacket allows such a keyholder to personal communications. This subpacket allows such a keyholder to
state which of their roles is making a signature. state which of their roles is making a signature.
This subpacket is not appropriate to use to refer to a User
Attribute packet.
5.2.3.23. Reason for Revocation 5.2.3.23. Reason for Revocation
(1 octet of revocation code, N octets of reason string) (1 octet of revocation code, N octets of reason string)
This subpacket is used only in key revocation and certification This subpacket is used only in key revocation and certification
revocation signatures. It describes the reason why the key or revocation signatures. It describes the reason why the key or
certificate was revoked. certificate was revoked.
The first octet contains a machine-readable code that denotes the The first octet contains a machine-readable code that denotes the
reason for the revocation: reason for the revocation:
0x00 - No reason specified (key revocations or cert revocations) 0x00 - No reason specified (key revocations or cert revocations)
0x01 - Key is superceded (key revocations) 0x01 - Key is superceded (key revocations)
0x02 - Key material has been compromised (key revocations) 0x02 - Key material has been compromised (key revocations)
skipping to change at page 32, line 26 skipping to change at page 32, line 42
revocation SHOULD include 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) (N octets of flags)
The features subpacket denotes which advanced OpenPGP features a The features subpacket denotes which advanced OpenPGP features a
user's implementation supports. This is so that as features are user's implementation supports. This is so that as features are
added to OpenPGP that cannot be backwards-compatible, a user can added to OpenPGP that cannot be backwards-compatible, a user can
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 18 and 19) First octet:
0x01 - 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
skipping to change at page 33, line 16 skipping to change at page 33, line 34
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 (also then hashes the subkey, using the same format as the main key (also
using 0x99 as the first octet). Key revocation signatures (types using 0x99 as the first octet). Key revocation signatures (types
0x20 and 0x28) hash only the key being 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 for
(which is an old-style packet header with the length-of-length set user ID certifications or the constant 0xd1 for User Attribute
to zero), a four-octet number giving the length of the username, and certifications (which are old-style packet headers with the
then the username data. length-of-length set to zero), followed by a four-octet number
giving the length of the user ID or User Attribute data, and then
the User ID or User Attribute 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
signature hashes five octets of the packet body, starting from the signature hashes five octets of the packet body, starting from the
signature type field. This data is the signature type, followed by signature type field. This data is the signature type, followed by
the four-octet signature time. A V4 signature hashes the packet body the four-octet signature time. A V4 signature hashes the packet body
starting from its first field, the version number, through the end starting from its first field, the version number, through the end
of the hashed subpacket data. Thus, the fields hashed are the of the hashed subpacket data. Thus, the fields hashed are the
signature version, the signature type, the public key algorithm, the signature version, the signature type, the public key algorithm, the
hash algorithm, the hashed subpacket length, and the hashed hash algorithm, the hashed subpacket length, and the hashed
subpacket body. subpacket body.
skipping to change at page 38, line 29 skipping to change at page 38, line 52
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:
- A Public Key or Public Subkey packet, as described above - A Public Key or Public Subkey packet, as described above
- One octet indicating string-to-key usage conventions. 0 - One octet indicating string-to-key usage conventions. 0
indicates that the secret key data is not encrypted. 255 indicates that the secret key data is not encrypted. 255 or 254
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 or 254, a
symmetric encryption algorithm. one-octet 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 or 254, a
specifier. The length of the string-to-key specifier is implied string-to-key specifier. The length of the string-to-key
by its type, as described above. specifier is implied 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 - If the string-to-key usage octet was 255, then a two-octet
portion (sum of all octets, mod 65536). This checksum is checksum of the plaintext of the algorithm-specific portion (sum
encrypted together with the algorithm- specific fields. of all octets, mod 65536). If the string-to-key usage octet was
254, then a 20-octet SHA-1 hash of the plaintext of the
algorithm-specific portion. This checksum or hash 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 39, line 43 skipping to change at page 40, line 14
CFB block boundary is aligned with the start of the MPI data. CFB block boundary is aligned with the start of the MPI data.
With V4 keys, a simpler method is used. All secret MPI values are With V4 keys, a simpler method is used. All secret MPI values are
encrypted in CFB mode, including the MPI bitcount prefix. encrypted in CFB mode, including the MPI bitcount prefix.
The 16-bit checksum that follows the algorithm-specific portion is The 16-bit checksum that follows the algorithm-specific portion is
the algebraic sum, mod 65536, of the plaintext of all the the algebraic sum, mod 65536, of the plaintext of all the
algorithm-specific octets (including MPI prefix and data). With V3 algorithm-specific octets (including MPI prefix and data). With V3
keys, the checksum is stored in the clear. With V4 keys, the keys, the checksum is stored in the clear. With V4 keys, the
checksum is encrypted like the algorithm-specific data. This value checksum is encrypted like the algorithm-specific data. This value
is used to check that the passphrase was correct. is used to check that the passphrase was correct. However, this
checksum is deprecated; an implementation SHOULD NOT use it, but
should rather use the SHA-1 hash denoted with a usage octet of 254.
The reason for this is that there are some attacks on the private
key that can undetectably modify the secret key. Using a SHA-1 hash
prevents this.
5.6. Compressed Data Packet (Tag 8) 5.6. Compressed Data Packet (Tag 8)
The Compressed Data packet contains compressed data. Typically, this The Compressed Data packet contains compressed data. Typically, this
packet is found as the contents of an encrypted packet, or following packet is found as the contents of an encrypted packet, or following
a Signature or One-Pass Signature packet, and contains literal data a Signature or One-Pass Signature packet, and contains literal data
packets. packets.
The body of this packet consists of: The body of this packet consists of:
skipping to change at page 42, line 29 skipping to change at page 43, line 6
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 18) 5.12. User Attribute Packet (Tag 17)
The User Attribute packet is a variation of the User ID packet. It
is capable of storing more types of data than the User ID packet
which is (by convention) limited to text. Like the User ID packet,
a User Attribute packet may be certified by the key owner
("self-signed") or any other key owner who cares to certify it.
Except as noted, a User Attribute packet may be used anywhere that a
User ID packet may be used.
While User Attribute packets are not a required part of the OpenPGP
standard, implementations SHOULD provide at least enough
compatibility to properly handle a certification signature on the
User Attribute packet. A simple way to do this is by treating the
User Attribute packet as a User ID packet with opaque contents, but
an implementation may use any method desired.
The User Attribute packet is made up of one or more attribute
subpackets. Each subpacket consists of a subpacket header and a
body. The header consists of:
- the subpacket length (1, 2, or 5 octets)
- the subpacket type (1 octet)
and is followed by the subpacket specific data.
The only currently defined subpacket type is 1, signifying an image.
An implementation SHOULD ignore any subpacket of a type that it does
not recognize. Subpacket types 100 through 110 are reserved for
private or experimental use.
5.12.1. The Image Attribute Subpacket
The image attribute subpacket is used to encode an image, presumably
(but not required to be) that of the key owner.
The image attribute subpacket begins with an image header. The
first two octets of the image header contain the length of the image
header. Note that unlike other multi-byte numerical values in this
document, due to an historical accident this value is encoded as a
little-endian number. The image header length is followed by a
single octet for the image header version. The only currently
defined version of the image header is 1, which is a 16 octet image
header. The first three octets of a version 1 image header are thus
0x10 0x00 0x01.
The fourth octet of a version 1 image header designates the encoding
format of the image. The only currently defined encoding format is
the value 1 to indicate JPEG. Image format types 100 through 110
are reserved for private or experimental use. The rest of the
version 1 image header is made up of 12 reserved octets, all of
which MUST be set to 0.
The rest of the image subpacket contains the image itself. As the
only currently defined image type is JPEG, the image is encoded in
the JPEG File Interchange Format (JFIF), a standard file format for
JPEG images. [JFIF]
An implementation MAY try and determine the type of an image by
examination of the image data if it is unable to handle a particular
version of the image header or if a specified encoding format value
is not recognized.
5.13. 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 44, line 11 skipping to change at page 45, line 54
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 19) 5.14. 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 50, line 22 skipping to change at page 52, line 19
=njUN =njUN
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
Note that this example is indented by two spaces. Note that this example is indented by two spaces.
7. Cleartext signature framework 7. Cleartext signature framework
It is desirable to sign a textual octet stream without ASCII It is desirable to sign a textual octet stream without ASCII
armoring the stream itself, so the signed text is still readable armoring the stream itself, so the signed text is still readable
without special software. In order to bind a signature to such a without special software. In order to bind a signature to such a
cleartext, this framework is used. (Note that RFC 2015 defines cleartext, this framework is used. (Note that RFC 3156 defines
another way to clear sign messages for environments that support another way to clear sign messages for environments that support
MIME.) MIME.)
The cleartext signed message consists of: The cleartext signed message consists of:
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
single line, single line,
- One or more "Hash" Armor Headers, - One or more "Hash" Armor Headers,
skipping to change at page 52, line 42 skipping to change at page 54, line 39
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, [SCHNEIER] - 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 [AES] 6 - Reserved for DES/SK
7 - AES with 128-bit key 7 - AES with 128-bit key [AES]
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 AES-128 and CAST5. Implementations that interoperate with implement AES-128 and CAST5. Implementations that interoperate with
PGP 2.6 or earlier need to support IDEA, as that is the only PGP 2.6 or earlier need to support IDEA, as that is the only
symmetric cipher those versions use. Implementations MAY implement symmetric cipher those versions use. Implementations MAY implement
any other algorithm. any other algorithm.
skipping to change at page 53, line 41 skipping to change at page 55, line 35
10 - SHA512 "SHA512" 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 section describes the rules for
packets should be placed into sequences. how packets should be placed into sequences.
10.1. Transferable Public Keys 10.1. Transferable Public Keys
OpenPGP users may transfer public keys. The essential elements of a OpenPGP users may transfer public keys. The essential elements of a
transferable public key are: transferable public key are:
- One Public Key packet - One Public Key packet
- Zero or more revocation signatures - Zero or more revocation signatures
skipping to change at page 54, line 4 skipping to change at page 55, line 48
10.1. Transferable Public Keys 10.1. Transferable Public Keys
OpenPGP users may transfer public keys. The essential elements of a OpenPGP users may transfer public keys. The essential elements of a
transferable public key are: transferable public key are:
- One Public Key packet - One Public Key packet
- Zero or more revocation signatures - Zero or more revocation signatures
- One or more User ID packets - One or more User ID packets
- After each User ID packet, zero or more signature packets - After each User ID packet, zero or more signature packets
(certifications) (certifications)
- Zero or more User Attribute packets
- After each User Attribute packet, zero or more signature packets
(certifications)
- Zero or more Subkey packets - Zero or more Subkey packets
- After each Subkey packet, one signature packet, optionally a - After each Subkey packet, one signature packet, optionally a
revocation. revocation.
The Public Key packet occurs first. Each of the following User ID The Public Key packet occurs first. Each of the following User ID
packets provides the identity of the owner of this public key. If packets provides the identity of the owner of this public key. If
there are multiple User ID packets, this corresponds to multiple there are multiple User ID packets, this corresponds to multiple
means of identifying the same unique individual user; for example, a means of identifying the same unique individual user; for example, a
user may have more than one email address, and construct a User ID user may have more than one email address, and construct a User ID
for each one. for each one.
Immediately following each User ID packet, there are zero or more Immediately following each User ID packet, there are zero or more
signature packets. Each signature packet is calculated on the signature packets. Each signature packet is calculated on the
immediately preceding User ID packet and the initial Public Key immediately preceding User ID packet and the initial Public Key
packet. The signature serves to certify the corresponding public key packet. The signature serves to certify the corresponding public key
and user ID. In effect, the signer is testifying to his or her and user ID. In effect, the signer is testifying to his or her
belief that this public key belongs to the user identified by this belief that this public key belongs to the user identified by this
user ID. user ID.
Within the same section as the User ID packets, there are zero or
more User Attribute packets. Like the User ID packets, a User
Attribute packet is followed by zero or more signature packets
calculated on the immediately preceding User Attribute packet and
the initial Public Key packet.
User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet.
After the User ID packets there may be one or more Subkey packets. After the User ID packets there may be one or more Subkey packets.
In general, subkeys are provided in cases where the top-level public In general, subkeys are provided in cases where the top-level public
key is a signature-only key. However, any V4 key may have subkeys, key is a signature-only key. However, any V4 key may have subkeys,
and the subkeys may be encryption-only keys, signature-only keys, or and the subkeys may be encryption-only keys, signature-only keys, or
general-purpose keys. general-purpose keys. V3 keys MAY NOT have subkeys.
Each Subkey packet must be followed by one Signature packet, which Each Subkey packet must be followed by one Signature packet, which
should be a subkey binding signature issued by the top level key. should be a subkey binding signature issued by the top level key.
Subkey and Key packets may each be followed by a revocation Subkey and Key packets may each be followed by a revocation
Signature packet to indicate that the key is revoked. Revocation Signature packet to indicate that the key is revoked. Revocation
signatures are only accepted if they are issued by the key itself, signatures are only accepted if they are issued by the key itself,
or by a key that is authorized to issue revocations via a revocation or by a key that is authorized to issue revocations via a revocation
key subpacket in a self-signature by the top level key. key subpacket in a self-signature by the top level key.
skipping to change at page 56, line 14 skipping to change at page 58, line 23
The format of an OpenPGP V4 key that uses two public keys is similar The format of an OpenPGP V4 key that uses two public keys is similar
except that the other keys are added to the end as 'subkeys' of the except that the other keys are added to the end as 'subkeys' of the
primary key. primary key.
Primary-Key Primary-Key
[Revocation Self Signature] [Revocation Self Signature]
[Direct Key Self Signature...] [Direct Key Self Signature...]
User ID [Signature ...] User ID [Signature ...]
[User ID [Signature ...] ...] [User ID [Signature ...] ...]
[User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation] [[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...] Primary-Key-Binding-Signature] ...]
A subkey always has a single signature after it that is issued using A subkey always has a single signature after it that is issued using
the primary key to tie the two keys together. This binding the primary key to tie the two keys together. This binding
signature may be in either V3 or V4 format, but V4 is preferred, of signature may be in either V3 or V4 format, but V4 is preferred, of
course. course.
In the above diagram, if the binding signature of a subkey has been In the above diagram, if the binding signature of a subkey has been
revoked, the revoked binding signature may be removed, leaving only revoked, the revoked key may be removed, leaving only one key.
one signature.
In a key that has a main key and subkeys, the primary key MUST be a In a key that has a main key and subkeys, the primary key MUST be a
key capable of signing. The subkeys may be keys of any other type. key capable of certification. The subkeys may be keys of any other
There may be other constructions of V4 keys, too. For example, there type. There may be other constructions of V4 keys, too. For example,
may be a single-key RSA key in V4 format, a DSA primary key with an there may be a single-key RSA key in V4 format, a DSA primary key
RSA encryption key, or RSA primary key with an Elgamal subkey, etc. with an RSA encryption key, or RSA primary key with an Elgamal
subkey, etc.
It is also possible to have a signature-only subkey. This permits a It is also possible to have a signature-only subkey. This permits a
primary key that collects certifications (key signatures) but is primary key that collects certifications (key signatures) but is
used only used for certifying subkeys that are used for encryption used only used for certifying subkeys that are used for encryption
and signatures. and signatures.
11.2. Key IDs and Fingerprints 11.2. Key IDs and Fingerprints
For a V3 key, the eight-octet key ID consists of the low 64 bits of For a V3 key, the eight-octet key ID consists of the low 64 bits of
the public modulus of the RSA key. the public modulus of the RSA key.
skipping to change at page 58, line 5 skipping to change at page 60, line 14
"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
be in a subkey's binding signature. be in a subkey's binding signature.
Since TripleDES is the MUST-implement algorithm, if it is not Since TripleDES is the MUST-implement algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly. Note also that if an good form to place it there explicitly. Note also that if an
implementation does not implement the preference, then it is implementation does not implement the preference, then it is
implicitly a TripleDES-only implementation. implicitly a TripleDES-only implementation.
An implementation MUST not use a symmetric algorithm that is not in An implementation MUST NOT use a symmetric algorithm that is not in
the recipient's preference list. When encrypting to more than one the recipient's preference list. When encrypting to more than one
recipient, the implementation finds a suitable algorithm by taking recipient, the implementation finds a suitable algorithm by taking
the intersection of the preferences of the recipients. Note that the the intersection of the preferences of the recipients. Note that the
MUST-implement algorithm, TripleDES, ensures that the intersection MUST-implement algorithm, TripleDES, ensures that the intersection
is not null. The implementation may use any mechanism to pick an is not null. The implementation may use any mechanism to pick an
algorithm in the intersection. algorithm in the intersection.
If an implementation can decrypt a message that a keyholder doesn't If an implementation can decrypt a message that a keyholder doesn't
have in their preferences, the implementation SHOULD decrypt the have in their preferences, the implementation SHOULD decrypt the
message anyway, but MUST warn the keyholder than protocol has been message anyway, but MUST warn the keyholder that the protocol has
violated. (For example, suppose that Alice, above, has software that been violated. (For example, suppose that Alice, above, has software
implements all algorithms in this specification. Nonetheless, she that implements all algorithms in this specification. Nonetheless,
prefers subsets for work or home. If she is sent a message encrypted she prefers subsets for work or home. If she is sent a message
with IDEA, which is not in her preferences, the software warns her encrypted with IDEA, which is not in her preferences, the software
that someone sent her an IDEA-encrypted message, but it would warns her that someone sent her an IDEA-encrypted message, but it
ideally decrypt it anyway.) would ideally decrypt it anyway.)
An implementation that is striving for backward compatibility MAY An implementation that is striving for backward compatibility MAY
consider a V3 key with a V3 self-signature to be an implicit consider a V3 key with a V3 self-signature to be an implicit
preference for IDEA, and no ability to do TripleDES. This is preference for IDEA, and no ability to do TripleDES. This is
technically non-compliant, but an implementation MAY violate the technically non-compliant, but an implementation MAY violate the
above rule in this case only and use IDEA to encrypt the message, above rule in this case only and use IDEA to encrypt the message,
provided that the message creator is warned. Ideally, though, the provided that the message creator is warned. Ideally, though, the
implementation would follow the rule by actually generating two implementation would follow the rule by actually generating two
messages, because it is possible that the OpenPGP user's messages, because it is possible that the OpenPGP user's
implementation does not have IDEA, and thus could not read the implementation does not have IDEA, and thus could not read the
skipping to change at page 65, line 8 skipping to change at page 67, line 15
* 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. These signatures are not OpenPGP compliant -- signatures. These signatures are not OpenPGP compliant --
OpenPGP requires trimming the whitespace. If you wish to OpenPGP requires trimming the whitespace. If you wish to
interoperate with PGP 2.6.X or PGP 5, you may wish to accept interoperate with PGP 2.6.X or PGP 5, you may wish to accept
these non-compliant signatures. these non-compliant 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 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
skipping to change at page 66, line 4 skipping to change at page 67, line 52
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
Email: rodney@tillerman.to
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
[AES] Advanced Encryption Standards Questions and Answers [AES] Advanced Encryption Standards Questions and Answers
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
skipping to change at page 66, line 54 skipping to change at page 68, line 52
[IDEA] Lai, X, "On the design and security of block [IDEA] Lai, X, "On the design and security of block
ciphers", ETH Series in Information Processing, ciphers", ETH Series in Information Processing,
J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag
Knostanz, Technische Hochschule (Zurich), 1992 Knostanz, Technische Hochschule (Zurich), 1992
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- [ISO10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture Coded Character Set (UCS) -- Part 1: Architecture
and Basic Multilingual Plane. and Basic Multilingual Plane.
[JFIF] JPEG File Interchange Format (Version 1.02).
Eric Hamilton, C-Cube Microsystems, Milpitas, CA,
September 1, 1992.
[MENEZES] Alfred Menezes, Paul van Oorschot, and Scott [MENEZES] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996. Press, 1996.
[RFC822] Crocker, D., "Standard for the format of ARPA [RFC822] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August Internet text messages", STD 11, RFC 822, August
1982. 1982.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet [RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and Electronic Mail: Part III: Algorithms, Modes, and
skipping to change at page 67, line 31 skipping to change at page 69, line 33
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3.", RFC 1951, May 1996. Specification version 1.3.", RFC 1951, May 1996.
[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC
1983, August 1996. 1983, August 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996. Message Exchange Formats", RFC 1991, August 1996.
[RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996.
[RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet [RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies.", RFC 2045, November 1996. Message Bodies.", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997. Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997. 2144, May 1997.
[RFC2279] Yergeau., F., "UTF-8, a transformation format of [RFC2279] Yergeau., F., "UTF-8, a transformation format of
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.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156,
August 2001.
[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 2001 by The Internet Society. All Rights Reserved. Copyright 2002 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/