draft-ietf-openpgp-rfc2440bis-10.txt   draft-ietf-openpgp-rfc2440bis-11.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT PGP Corporation Category: INTERNET-DRAFT PGP Corporation
draft-ietf-openpgp-rfc2440bis-10.txt draft-ietf-openpgp-rfc2440bis-11.txt
Expires Sep 2004 Lutz Donnerhacke Expires Apr 2004 Lutz Donnerhacke
March 2004 October 2005
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-10.txt draft-ietf-openpgp-rfc2440bis-11.txt
Copyright 2004 by The Internet Society. All Rights Reserved. Copyright 2004 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
skipping to change at page 1, line 40 skipping to change at page 1, line 39
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
IPR Claim Notice
By submitting this Internet-Draft, any applicable patent or other
IPR claims of which we are aware have been disclosed in accordance
with RFC 3668.
IESG Note IESG Note
This document defines many tag values, yet it doesn't describe a This document defines many tag values, yet it doesn't describe a
mechanism for adding new tags (for new features). Traditionally the mechanism for adding new tags (for new features). Traditionally the
Internet Assigned Numbers Authority (IANA) handles the allocation of Internet Assigned Numbers Authority (IANA) handles the allocation of
new values for future expansion and RFCs usually define the new values for future expansion and RFCs usually define the
procedure to be used by the IANA. However there are subtle (and not procedure to be used by the IANA. However there are subtle (and not
so subtle) interactions that may occur in this protocol between new so subtle) interactions that may occur in this protocol between new
features and existing features which result in a significant features and existing features which result in a significant
reduction in over all security. Therefore this document does not reduction in over all security. Therefore this document does not
skipping to change at page 3, line 8 skipping to change at page 3, line 8
OpenPGP 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
IPR Claim Notice 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 7 2.1. Confidentiality via Encryption 7
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 9
3.1. Scalar numbers 9 3.1. Scalar numbers 9
3.2. Multi-Precision Integers 9 3.2. Multiprecision Integers 9
3.3. Key IDs 9 3.3. Key IDs 9
3.4. Text 10 3.4. Text 10
3.5. Time fields 10 3.5. Time fields 10
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 11
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 12
skipping to change at page 5, line 11 skipping to change at page 5, line 12
7. Cleartext signature framework 53 7. Cleartext signature framework 53
7.1. Dash-Escaped Text 54 7.1. Dash-Escaped Text 54
8. Regular Expressions 55 8. Regular Expressions 55
9. Constants 55 9. Constants 55
9.1. Public Key Algorithms 55 9.1. Public Key Algorithms 55
9.2. Symmetric Key Algorithms 56 9.2. Symmetric Key Algorithms 56
9.3. Compression Algorithms 56 9.3. Compression Algorithms 56
9.4. Hash Algorithms 57 9.4. Hash Algorithms 57
10. Packet Composition 57 10. Packet Composition 57
10.1. Transferable Public Keys 57 10.1. Transferable Public Keys 57
10.2. OpenPGP Messages 58 10.2. OpenPGP Messages 59
10.3. Detached Signatures 59 10.3. Detached Signatures 59
11. Enhanced Key Formats 59 11. Enhanced Key Formats 59
11.1. Key Structures 59 11.1. Key Structures 59
11.2. Key IDs and Fingerprints 60 11.2. Key IDs and Fingerprints 60
12. Notes on Algorithms 61 12. Notes on Algorithms 61
12.1. Symmetric Algorithm Preferences 61 12.1. Symmetric Algorithm Preferences 61
12.2. Other Algorithm Preferences 62 12.2. Other Algorithm Preferences 62
12.2.1. Compression Preferences 62 12.2.1. Compression Preferences 62
12.2.2. Hash Algorithm Preferences 63 12.2.2. Hash Algorithm Preferences 63
12.3. Plaintext 63 12.3. Plaintext 63
12.4. RSA 63 12.4. RSA 63
12.5. Elgamal 64 12.5. DSA 64
12.6. DSA 64 12.6. Reserved Algorithm Numbers 64
12.7. Reserved Algorithm Numbers 65 12.7. OpenPGP CFB mode 64
12.8. OpenPGP CFB mode 65 13. Security Considerations 65
13. Security Considerations 66
14. Implementation Nits 68 14. Implementation Nits 68
15. Authors and Working Group Chair 69 15. Authors and Working Group Chair 69
16. References (Normative) 70 16. References (Normative) 70
17. References (Non-Normative) 72 17. References (Non-Normative) 71
18. Full Copyright Statement 72 18. Full Copyright Statement 71
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 9, line 5 skipping to change at page 9, line 5
Armor. Armor.
Implementations SHOULD provide Radix-64 conversions. Implementations SHOULD provide Radix-64 conversions.
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-conformant only in that they
omit encryption. omit encryption.
3. Data Element Formats 3. Data Element Formats
This section describes the data elements used by OpenPGP. This section describes the data elements used by OpenPGP.
3.1. Scalar numbers 3.1. Scalar numbers
Scalar numbers are unsigned, and are always stored in big-endian Scalar numbers are unsigned, and are always stored in big-endian
format. Using n[k] to refer to the kth octet being interpreted, the format. Using n[k] to refer to the kth octet being interpreted, the
value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a
four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) +
n[3]). n[3]).
3.2. Multi-Precision Integers 3.2. Multiprecision Integers
Multi-Precision Integers (also called MPIs) are unsigned integers Multiprecision Integers (also called MPIs) are unsigned integers
used to hold large integers such as the ones used in cryptographic used to hold large integers such as the ones used in cryptographic
calculations. calculations.
An MPI consists of two pieces: a two-octet scalar that is the length An MPI consists of two pieces: a two-octet scalar that is the length
of the MPI in bits followed by a string of octets that contain the of the MPI in bits followed by a string of octets that contain the
actual integer. actual integer.
These octets form a big-endian number; a big-endian number can be These octets form a big-endian number; a big-endian number can be
made into an MPI by prefixing it with the appropriate length. made into an MPI by prefixing it with the appropriate length.
skipping to change at page 16, line 17 skipping to change at page 16, line 17
32768 octets of data; 0xE1, next two octets of data; 0xE0, next one 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last
1693 octets of data. This is just one possible encoding, and many 1693 octets of data. This is just one possible encoding, and many
variations are possible on the size of the Partial Body Length variations are possible on the size of the Partial Body Length
headers, as long as a regular Body Length header encodes the last headers, as long as a regular Body Length header encodes the last
portion of the data. portion of the data.
Note also that the last Body Length header can be a zero-length Note also that the last Body Length header can be a zero-length
header. header.
An implementation MAY use Partial Body Lengths for data packets, be
they literal, compressed, or encrypted. The first partial length
MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
used for any other packet types.
4.2.3. Packet Length Examples 4.2.3. Packet Length Examples
These examples show ways that new-format packets might encode the These examples show ways that new-format packets might encode the
packet lengths. packet lengths.
A packet with length 100 may have its length encoded in one octet: A packet with length 100 may have its length encoded in one octet:
0x64. This is followed by 100 octets of data. 0x64. This is followed by 100 octets of data.
A packet with length 1723 may have its length coded in two octets: A packet with length 1723 may have its length coded in two octets:
0xC5, 0xFB. This header is followed by the 1723 octets of data. 0xC5, 0xFB. This header is followed by the 1723 octets of data.
A packet with length 100000 may have its length encoded in five A packet with length 100000 may have its length encoded in five
octets: 0xFF, 0x00, 0x01, 0x86, 0xA0. octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.
An implementation MAY use Partial Body Lengths for data packets, be
they literal, compressed, or encrypted. The first partial length
MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
used for any other packet types.
Please note that in all of these explanations, the total length of Please note that in all of these explanations, the total length of
the packet is the length of the header(s) plus the length of the the packet is the length of the header(s) plus the length of the
body. body.
4.3. Packet Tags 4.3. Packet Tags
The packet tag denotes what type of packet the body holds. Note that The packet tag denotes what type of packet the body holds. Note that
old format headers can only have tags less than 16, whereas new old format headers can only have tags less than 16, whereas new
format headers can have tags as great as 63. The defined tags (in format headers can have tags as great as 63. The defined tags (in
decimal) are: decimal) are:
skipping to change at page 19, line 9 skipping to change at page 19, line 9
meanings are: meanings are:
0x00: Signature of a binary document. 0x00: Signature of a binary document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. has not been modified.
0x01: Signature of a canonical text document. 0x01: Signature of a canonical text document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. The signature is calculated over the has not been modified. The signature is calculated over the
text data with its line endings converted to <CR><LF> and text data with its line endings converted to <CR><LF> and
trailing blanks removed. trailing spaces (0x020) and tabs (0x09) removed.
0x02: Standalone signature. 0x02: Standalone signature.
This signature is a signature of only its own subpacket This signature is a signature of only its own subpacket
contents. It is calculated identically to a signature over a contents. It is calculated identically to a signature over a
zero-length binary document. Note that it doesn't make sense to zero-length binary document. Note that it doesn't make sense to
have a V3 standalone signature. have a V3 standalone signature.
0x10: Generic certification of a User ID and Public Key packet. 0x10: Generic certification of a User ID and Public Key packet.
The issuer of this certification does not make any particular The issuer of this certification does not make any particular
assertion as to how well the certifier has checked that the assertion as to how well the certifier has checked that the
skipping to change at page 21, line 21 skipping to change at page 21, line 21
- Four-octet creation time. - Four-octet creation time.
- Eight-octet key ID of signer. - Eight-octet key ID of signer.
- One-octet public key algorithm. - One-octet public key algorithm.
- One-octet hash algorithm. - One-octet hash algorithm.
- Two-octet field holding left 16 bits of signed hash value. - Two-octet field holding left 16 bits of signed hash value.
- One or more multi-precision integers comprising the signature. - One or more multiprecision integers comprising the signature.
This portion is algorithm specific, as described below. This portion is algorithm specific, as described below.
The data being signed is hashed, and then the signature type and The data being signed is hashed, and then the signature type and
creation time from the signature packet are hashed (5 additional creation time from the signature packet are hashed (5 additional
octets). The resulting hash value is used in the signature octets). The resulting hash value is used in the signature
algorithm. The high 16 bits (first two octets) of the hash are algorithm. The high 16 bits (first two octets) of the hash are
included in the signature packet to provide a quick test to reject included in the signature packet to provide a quick test to reject
some invalid signatures. some invalid signatures.
Algorithm Specific Fields for RSA signatures: Algorithm Specific Fields for RSA signatures:
skipping to change at page 21, line 45 skipping to change at page 21, line 45
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 The hash h is PKCS-1 padded exactly the same way as for the above
described RSA signatures. 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:
skipping to change at page 23, line 41 skipping to change at page 23, line 37
- Two-octet scalar octet count for following unhashed subpacket - Two-octet scalar octet count for following unhashed subpacket
data. Note that this is the length in octets of all of the data. Note that this is the length in octets of all of the
unhashed subpackets; a pointer incremented by this number will unhashed subpackets; a pointer incremented by this number will
skip over the unhashed subpackets. skip over the unhashed subpackets.
- Unhashed subpacket data. (zero or more subpackets) - Unhashed subpacket data. (zero or more subpackets)
- Two-octet field holding left 16 bits of signed hash value. - Two-octet field holding left 16 bits of signed hash value.
- One or more multi-precision integers comprising the signature. - One or more multiprecision integers comprising the signature.
This portion is algorithm specific, as described above. This portion is algorithm specific, as described above.
The data being signed is hashed, and then the signature data from The data being signed is hashed, and then the signature data from
the version number through the hashed subpacket data (inclusive) is the version number through the hashed subpacket data (inclusive) is
hashed. The resulting hash value is what is signed. The left 16 hashed. The resulting hash value is what is signed. The left 16
bits of the hash are included in the signature packet to provide a bits of the hash are included in the signature packet to provide a
quick test to reject some invalid signatures. quick test to reject some invalid signatures.
There are two fields consisting of signature subpackets. The first There are two fields consisting of signature subpackets. The first
field is hashed with the rest of the signature data, while the field is hashed with the rest of the signature data, while the
skipping to change at page 26, line 14 skipping to change at page 26, line 11
self-signature, and thus different subpackets in those self-signature, and thus different subpackets in those
self-signatures. For subkey binding signatures, each subkey in fact self-signatures. For subkey binding signatures, each subkey in fact
has a self-signature. Subpackets that appear in a certification has a self-signature. Subpackets that appear in a certification
self-signature apply to the username, and subpackets that appear in self-signature apply to the username, and subpackets that appear in
the subkey self-signature apply to the subkey. Lastly, subpackets on the subkey self-signature apply to the subkey. Lastly, subpackets on
the direct-key signature apply to the entire key. the direct-key signature apply to the entire key.
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 TripleDES. If the
the software locates this key via Alice's name, then the preferred 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,
the algorithm of the primary User ID of the key provides the default the algorithm of the primary User ID of the key provides the default
symmetric algorithm. symmetric algorithm.
Revoking a self-signature or allowing it to expire has a semantic Revoking a self-signature or allowing it to expire has a semantic
meaning that varies with the signature type. Revoking the meaning that varies with the signature type. Revoking the
self-signature on a User ID effectively retires that user name. The self-signature on a User ID effectively retires that user name. The
self-signature is a statement, "My name X is tied to my signing key self-signature is a statement, "My name X is tied to my signing key
K" and is corroborated by other users' certifications. If another K" and is corroborated by other users' certifications. If another
skipping to change at page 33, line 12 skipping to change at page 33, line 12
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)
0x03 - Key is retired and no longer used (key revocations) 0x03 - Key is retired and no longer used (key revocations)
0x20 - User id information is no longer valid (cert revocations) 0x20 - User Id information is no longer valid (cert revocations)
Following the revocation code is a string of octets which gives Following the revocation code is a string of octets which gives
information about the reason for revocation in human-readable form information about the reason for revocation in human-readable form
(UTF-8). The string may be null, that is, of zero length. The length (UTF-8). The string may be null, that is, of zero length. The length
of the subpacket is the length of the reason string plus one. of the subpacket is the length of the reason string plus one.
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.
skipping to change at page 34, line 12 skipping to change at page 34, line 12
Defined features are: Defined features are:
First octet: First octet:
0x01 - Modification Detection (packets 18 and 19) 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.
In the case of Modification Detection, an implementation may freely An implementation may freely infer features from other suitable
infer this feature from other suitable implementation-dependent implementation-dependent mechanisms.
mechanisms.
5.2.3.25. Signature Target 5.2.3.25. Signature Target
(1 octet PK algorithm, 1 octet hash algorithm, N octets hash) (1 octet PK algorithm, 1 octet hash algorithm, N octets hash)
This subpacket identifies a specific target signature that a This subpacket identifies a specific target signature that a
signature refers to. For revocation signatures, this subpacket signature refers to. For revocation signatures, this subpacket
provides explicit designation of which signature is being revoked. provides explicit designation of which signature is being revoked.
For a third-party or timestamp signature, this designates what For a third-party or timestamp signature, this designates what
signature is signed. All arguments are an identifier of that target signature is signed. All arguments are an identifier of that target
skipping to change at page 34, line 52 skipping to change at page 34, line 51
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 binding signature a key packet with two-octet length.) A subkey binding signature
(type 0x18) or primary key binding signature (0x19) then hashes the (type 0x18) or primary key binding signature (type 0x19) then hashes
subkey using the same format as the main key (also using 0x99 as the the subkey using the same format as the main key (also using 0x99 as
first octet). Key revocation signatures (types 0x20 and 0x28) hash the first octet). Key revocation signatures (types 0x20 and 0x28)
only the key being revoked. hash only the key being revoked.
When a signature is made over a signature packet, the hash data When a signature is made over a signature packet, the hash data
starts with the octet 0x88, followed by the four-octet length of the starts with the octet 0x88, followed by the four-octet length of the
signature, and then the body of the signature packet. The unhashed signature, and then the body of the signature packet. The unhashed
subpacket data of the signature packet being hashed is not included subpacket data of the signature packet being hashed is not included
in the hash and the unhashed subpacket data length value is set to in the hash and the unhashed subpacket data length value is set to
zero. (Note that this is an old-style packet header for a signature zero. (Note that this is an old-style packet header for a signature
packet with the length-of-length set to zero). packet with the length-of-length set to zero).
A certification signature (type 0x10 through 0x13) hashes the User A certification signature (type 0x10 through 0x13) hashes the User
skipping to change at page 38, line 53 skipping to change at page 38, line 53
- A one-octet version number (3). - A one-octet version number (3).
- A four-octet number denoting the time that the key was created. - A four-octet number denoting the time that the key was created.
- A two-octet number denoting the time in days that this key is - A two-octet number denoting the time in days that this key is
valid. If this number is zero, then it does not expire. valid. If this number is zero, then it does not expire.
- A one-octet number denoting the public key algorithm of this key - A one-octet number denoting the public key algorithm of this key
- A series of multi-precision integers comprising the key - A series of multiprecision integers comprising the key material:
material:
- a multiprecision integer (MPI) of RSA public modulus n; - a multiprecision integer (MPI) of RSA public modulus n;
- an MPI of RSA public encryption exponent e. - an MPI of RSA public encryption exponent e.
V3 keys are deprecated. They contain three weaknesses in them. V3 keys are deprecated. They contain three weaknesses in them.
First, it is relatively easy to construct a V3 key that has the same First, it is relatively easy to construct a V3 key that has the same
key ID as any other key because the key ID is simply the low 64 bits key ID as any other key because the key ID is simply the low 64 bits
of the public modulus. Secondly, because the fingerprint of a V3 key of the public modulus. Secondly, because the fingerprint of a V3 key
hashes the key material, but not its length, which increases the hashes the key material, but not its length, which increases the
skipping to change at page 39, line 33 skipping to change at page 39, line 33
"Enhanced Key Formats." "Enhanced Key Formats."
A version 4 packet contains: A version 4 packet contains:
- A one-octet version number (4). - A one-octet version number (4).
- A four-octet number denoting the time that the key was created. - A four-octet number denoting the time that the key was created.
- A one-octet number denoting the public key algorithm of this key - A one-octet number denoting the public key algorithm of this key
- A series of multi-precision integers comprising the key - A series of multiprecision integers comprising the key material.
material. This algorithm-specific portion is: This algorithm-specific portion is:
Algorithm Specific Fields for RSA public keys: Algorithm Specific Fields for RSA public keys:
- multiprecision integer (MPI) of RSA public modulus n; - multiprecision integer (MPI) of RSA public modulus n;
- MPI of RSA public encryption exponent e. - MPI of RSA public encryption exponent e.
Algorithm Specific Fields for DSA public keys: Algorithm Specific Fields for DSA public keys:
- MPI of DSA prime p; - MPI of DSA prime p;
skipping to change at page 40, line 36 skipping to change at page 40, line 36
other value is a symmetric-key encryption algorithm identifier. other value is a symmetric-key encryption algorithm identifier.
- [Optional] If string-to-key usage octet was 255 or 254, a - [Optional] If string-to-key usage octet was 255 or 254, a
one-octet symmetric encryption algorithm. one-octet symmetric encryption algorithm.
- [Optional] If string-to-key usage octet was 255 or 254, a - [Optional] If string-to-key usage octet was 255 or 254, a
string-to-key specifier. The length of the string-to-key string-to-key specifier. The length of the string-to-key
specifier is implied by its type, as described above. specifier is implied by its type, as described above.
- [Optional] If secret data is encrypted (string-to-key usage - [Optional] If secret data is encrypted (string-to-key usage
octet not zero), Initial Vector (IV) of the same length as the octet not zero), an Initial Vector (IV) of the same length as
cipher's block size. the cipher's block size.
- Plain or encrypted multi-precision integers comprising the - Plain or encrypted multiprecision integers comprising the secret
secret key data. These algorithm-specific fields are as key data. These algorithm-specific fields are as described
described below. below.
- If the string-to-key usage octet is zero or 255, then a - If the string-to-key usage octet is zero or 255, then a
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). If the string-to-key portion (sum of all octets, mod 65536). If the string-to-key
usage octet was 254, then a 20-octet SHA-1 hash of the plaintext usage octet was 254, then a 20-octet SHA-1 hash of the plaintext
of the algorithm-specific portion. This checksum or hash is of the algorithm-specific portion. This checksum or hash is
encrypted together with the algorithm-specific fields (if encrypted together with the algorithm-specific fields (if
string-to-key usage octet is not zero). Note that for all other string-to-key usage octet is not zero). Note that for all other
values, a two-octet checksum is required. values, a two-octet checksum is required.
skipping to change at page 43, line 40 skipping to change at page 43, line 40
A Literal Data packet contains the body of a message; data that is A Literal Data packet contains the body of a message; data that is
not to be further interpreted. not to be further interpreted.
The body of this packet consists of: The body of this packet consists of:
- A one-octet field that describes how the data is formatted. - A one-octet field that describes how the data is formatted.
If it is a 'b' (0x62), then the literal packet contains binary data. If it is a 'b' (0x62), then the literal packet contains binary data.
If it is a 't' (0x74), then it contains text data, and thus may need If it is a 't' (0x74), then it contains text data, and thus may need
line ends converted to local form, or other text-mode changes. line ends converted to local form, or other text-mode changes. The
tag 'u' (0x75) means the same as 't', but also indicates that
implementation believes that the literal data contains UTF-8 text.
Early versions of PGP also defined a value of 'l' as a 'local' mode Early versions of PGP also defined a value of 'l' as a 'local' mode
for machine-local conversions. RFC 1991 incorrectly stated this for machine-local conversions. RFC 1991 incorrectly stated this
local mode flag as '1' (ASCII numeral one). Both of these local local mode flag as '1' (ASCII numeral one). Both of these local
modes are deprecated. modes are deprecated.
- File name as a string (one-octet length, followed by file name), - File name as a string (one-octet length, followed by file name),
if the encrypted data should be saved as a file. if the encrypted data should be saved as a file.
If the special name "_CONSOLE" is used, the message is considered to If the special name "_CONSOLE" is used, the message is considered to
skipping to change at page 44, line 40 skipping to change at page 44, line 40
A User ID packet consists of UTF-8 text that is intended to A User ID packet consists of UTF-8 text that is intended to
represent the name and email address of the key holder. By represent the name and email address of the key holder. By
convention, it includes an RFC822 mail name, but there are no convention, it includes an RFC822 mail name, but there are no
restrictions on its content. The packet length in the header restrictions on its content. The packet length in the header
specifies the length of the User ID. specifies the length of the User ID.
5.12. User Attribute Packet (Tag 17) 5.12. User Attribute Packet (Tag 17)
The User Attribute packet is a variation of the User ID packet. It 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 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, which is limited to text. Like the User ID packet, a User Attribute
a User Attribute packet may be certified by the key owner packet may be certified by the key owner ("self-signed") or any
("self-signed") or any other key owner who cares to certify it. other key owner who cares to certify it. Except as noted, a User
Except as noted, a User Attribute packet may be used anywhere that a Attribute packet may be used anywhere that a User ID packet may be
User ID packet may be used. used.
While User Attribute packets are not a required part of the OpenPGP While User Attribute packets are not a required part of the OpenPGP
standard, implementations SHOULD provide at least enough standard, implementations SHOULD provide at least enough
compatibility to properly handle a certification signature on the 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. A simple way to do this is by treating the
User Attribute packet as a User ID packet with opaque contents, but User Attribute packet as a User ID packet with opaque contents, but
an implementation may use any method desired. an implementation may use any method desired.
The User Attribute packet is made up of one or more attribute The User Attribute packet is made up of one or more attribute
subpackets. Each subpacket consists of a subpacket header and a subpackets. Each subpacket consists of a subpacket header and a
skipping to change at page 50, line 12 skipping to change at page 50, line 12
Used for multi-part messages, where the armor is split amongst Y Used for multi-part messages, where the armor is split amongst Y
parts, and this is the Xth part out of Y. parts, and this is the Xth part out of Y.
BEGIN PGP MESSAGE, PART X BEGIN PGP MESSAGE, PART X
Used for multi-part messages, where this is the Xth part of an Used for multi-part messages, where this is the Xth part of an
unspecified number of parts. Requires the MESSAGE-ID Armor unspecified number of parts. Requires the MESSAGE-ID Armor
Header to be used. Header to be used.
BEGIN PGP SIGNATURE BEGIN PGP SIGNATURE
Used for detached signatures, OpenPGP/MIME signatures, and Used for detached signatures, OpenPGP/MIME signatures, and
signatures following clearsigned messages. Note that PGP 2.x cleartext signatures. Note that PGP 2.x uses BEGIN PGP MESSAGE
uses BEGIN PGP MESSAGE for detached signatures. for detached signatures.
Note that all these Armor Header Lines are to consist of a complete Note that all these Armor Header Lines are to consist of a complete
line. That is to say, there is always a line ending preceding the line. That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text following them on the same line. These line MUST NOT have text following them on the same line. These line
endings are considered a part of the Armor Header Line for the endings are considered a part of the Armor Header Line for the
purposes of determining the content they delimit. This is purposes of determining the content they delimit. This is
particularly important when computing a cleartext signature (see particularly important when computing a cleartext signature (see
below). below).
skipping to change at page 51, line 14 skipping to change at page 51, line 14
The MessageID SHOULD NOT appear unless it is in a multi-part The MessageID SHOULD NOT appear unless it is in a multi-part
message. If it appears at all, it MUST be computed from the message. If it appears at all, it MUST be computed from the
finished (encrypted, signed, etc.) message in a deterministic finished (encrypted, signed, etc.) message in a deterministic
fashion, rather than contain a purely random value. This is to fashion, rather than contain a purely random value. This is to
allow the legitimate recipient to determine that the MessageID allow the legitimate recipient to determine that the MessageID
cannot serve as a covert means of leaking cryptographic key cannot serve as a covert means of leaking cryptographic key
information. information.
- "Hash", a comma-separated list of hash algorithms used in this - "Hash", a comma-separated list of hash algorithms used in this
message. This is used only in clear-signed messages. message. This is used only in cleartext signed messages.
- "Charset", a description of the character set that the plaintext - "Charset", a description of the character set that the plaintext
is in. Please note that OpenPGP defines text to be in UTF-8. An is in. Please note that OpenPGP defines text to be in UTF-8. An
implementation will get best results by translating into and out implementation will get best results by translating into and out
of UTF-8. However, there are many instances where this is easier of UTF-8. However, there are many instances where this is easier
said than done. Also, there are communities of users who have no said than done. Also, there are communities of users who have no
need for UTF-8 because they are all happy with a character set need for UTF-8 because they are all happy with a character set
like ISO Latin-5 or a Japanese character set. In such instances, like ISO Latin-5 or a Japanese character set. In such instances,
an implementation MAY override the UTF-8 default by using this an implementation MAY override the UTF-8 default by using this
header key. An implementation MAY implement this key and any header key. An implementation MAY implement this key and any
skipping to change at page 53, line 54 skipping to change at page 53, line 54
-----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 3156 defines cleartext, this framework is used. (Note that RFC 3156 defines
another way to clear sign messages for environments that support another way to sign cleartext 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,
- Exactly one empty line not included into the message digest, - Exactly one empty line not included into the message digest,
skipping to change at page 55, line 5 skipping to change at page 55, line 5
is calculated on the text using canonical <CR><LF> line endings. is calculated on the text using canonical <CR><LF> line endings.
The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text. considered part of the signed text.
When reversing dash-escaping, an implementation MUST strip the When reversing dash-escaping, an implementation MUST strip the
string "- " if it occurs at the beginning of a line, and SHOULD warn string "- " if it occurs at the beginning of a line, and SHOULD warn
on "-" and any character other than a space at the beginning of a on "-" and any character other than a space at the beginning of a
line. line.
Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of Also, any trailing whitespace -- spaces (0x020) and tabs (0x09) --
any line is ignored when the cleartext signature is calculated. at the end of any line is removed when the cleartext signature is
generated.
8. Regular Expressions 8. Regular Expressions
A regular expression is zero or more branches, separated by '|'. It A regular expression is zero or more branches, separated by '|'. It
matches anything that matches one of the branches. matches anything that matches one of the branches.
A branch is zero or more pieces, concatenated. It matches a match A branch is zero or more pieces, concatenated. It matches a match
for the first, followed by a match for the second, etc. for the first, followed by a match for the second, etc.
A piece is an atom possibly followed by '*', '+', or '?'. An atom A piece is an atom possibly followed by '*', '+', or '?'. An atom
skipping to change at page 56, line 10 skipping to change at page 56, line 11
ID Algorithm ID Algorithm
-- --------- -- ---------
1 - RSA (Encrypt or Sign) 1 - RSA (Encrypt or Sign)
2 - RSA Encrypt-Only 2 - RSA Encrypt-Only
3 - RSA Sign-Only 3 - RSA Sign-Only
16 - Elgamal (Encrypt-Only), see [ELGAMAL] 16 - Elgamal (Encrypt-Only), see [ELGAMAL]
17 - DSA (Digital Signature Algorithm) [SCHNEIER] 17 - DSA (Digital Signature Algorithm) [SCHNEIER]
18 - Reserved for Elliptic Curve 18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA 19 - Reserved for ECDSA
20 - Elgamal (Encrypt or Sign) 20 - Reserved (formerly Elgamal Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42, 21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME) as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement DSA for signatures, and Elgamal for Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys. encryption. Implementations SHOULD implement RSA keys.
Implementations MAY implement any other algorithm. Implementations MAY implement any other algorithm.
9.2. Symmetric Key Algorithms 9.2. Symmetric Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Plaintext or unencrypted data 0 - Plaintext or unencrypted data
1 - IDEA [IDEA] 1 - IDEA [IDEA]
2 - Triple-DES (DES-EDE, [SCHNEIER] - 2 - TripleDES (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 - Reserved 5 - Reserved
6 - Reserved 6 - Reserved
7 - AES with 128-bit key [AES] 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 TripleDES. 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.
9.3. Compression Algorithms 9.3. Compression Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Uncompressed 0 - Uncompressed
skipping to change at page 64, line 12 skipping to change at page 64, line 15
An implementation SHOULD NOT implement RSA keys of size less than An implementation SHOULD NOT implement RSA keys of size less than
768 bits. 768 bits.
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. DSA
If an Elgamal key [ELGAMAL] is to be used for both signing and
encryption, extra care must be taken in creating the key.
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.
The generator and prime must be chosen so that solving the discrete
log problem is intractable. The group g should generate 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
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 implementers SHOULD do it, as it avoids a small subgroup
attack.
In addition, a result of Bleichenbacher [BLEICHENBACHER] shows that
if the generator g has only small prime factors, and if g divides
the order of the group it generates, then signatures can be forged.
In particular, choosing g=2 is a bad choice if the group order may
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.
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
signatures can be trivially forged by using large r values of
approximately twice the length of p. This attack is also discussed
in the Bleichenbacher paper.
Details on safe use of Elgamal signatures may be found in [MENEZES],
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
algorithm identifier 20 for an Elgamal public key that can sign.
An implementation SHOULD NOT implement Elgamal keys of size less
than 768 bits. For long-term security, Elgamal keys should be 1024
bits or longer.
12.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
768 bits. Note that present DSA is limited to a maximum of 1024 bit 768 bits. Note that present DSA is limited to a maximum of 1024 bit
keys, which are recommended for long-term use. Also, DSA keys MUST keys, which are recommended for long-term use. Also, DSA keys MUST
be an even multiple of 64 bits long. be an even multiple of 64 bits long.
12.7. Reserved Algorithm Numbers 12.6. Reserved Algorithm Numbers
A number of algorithm IDs have been reserved for algorithms that A number of algorithm IDs have been reserved for algorithms that
would be useful to use in an OpenPGP implementation, yet there are would be useful to use in an OpenPGP implementation, yet there are
issues that prevent an implementer from actually implementing the issues that prevent an implementer from actually implementing the
algorithm. These are marked in the Public Algorithms section as algorithm. These are marked in the Public Algorithms section as
"(reserved for)". "(reserved for)".
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
and X9.42 (21) do not have the necessary parameters, parameter and X9.42 (21) do not have the necessary parameters, parameter
order, or semantics defined. order, or semantics defined.
The reserved symmetric key algorithm, DES/SK (6), does not have Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
semantics defined. with a public key identifier of 20. These are no longer permitted.
An implementation MUST NOT generate such keys. An implementation
MUST NOT generate Elgamal signatures.
12.8. OpenPGP CFB mode 12.7. OpenPGP CFB mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback OpenPGP does symmetric encryption using a variant of Cipher Feedback
Mode (CFB mode). This section describes the procedure it uses in Mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Encrypted Data detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret key material is Packets; the mechanism used for encrypting secret key material is
similar, but described in those sections above. similar, but described in those sections above.
In the description below, the value BS is the block size in octets In the description below, the value BS is the block size in octets
of the cipher. Most ciphers have a block size of 8 octets. The AES of the cipher. Most ciphers have a block size of 8 octets. The AES
and Twofish have a block size of 16 octets. Also note that the and Twofish have a block size of 16 octets. Also note that the
skipping to change at page 67, line 49 skipping to change at page 67, line 9
be made to this document to revise the allowed hash algorithms. be made to this document to revise the allowed hash algorithms.
* If you are building an authentication system, the recipient may * If you are building an authentication system, the recipient may
specify a preferred signing algorithm. However, the signer would specify a preferred signing algorithm. However, the signer would
be foolish to use a weak algorithm simply because the recipient be foolish to use a weak algorithm simply because the recipient
requests it. requests it.
* Some of the encryption algorithms mentioned in this document * Some of the encryption algorithms mentioned in this document
have been analyzed less than others. For example, although have been analyzed less than others. For example, although
CAST5 is presently considered strong, it has been analyzed less CAST5 is presently considered strong, it has been analyzed less
than Triple-DES. Other algorithms may have other controversies than TripleDES. Other algorithms may have other controversies
surrounding them. surrounding them.
* In late summer 2002, Jallad, Katz, and Schneier published an * In late summer 2002, Jallad, Katz, and Schneier published an
interesting attack on the OpenPGP protocol and some of its interesting attack on the OpenPGP protocol and some of its
implementations [JKS02]. In this attack, the attacker modifies a implementations [JKS02]. In this attack, the attacker modifies a
message and sends it to a user who then returns the erroneously message and sends it to a user who then returns the erroneously
decrypted message to the attacker. The attacker is thus using decrypted message to the attacker. The attacker is thus using
the user as a random oracle, and can often decrypt the message. the user as a random oracle, and can often decrypt the message.
Compressing data can ameliorate this attack. The incorrectly Compressing data can ameliorate this attack. The incorrectly
skipping to change at page 68, line 41 skipping to change at page 68, line 5
1. Implementers treat MDC errors and decompression failures as 1. Implementers treat MDC errors and decompression failures as
security problems. security problems.
2. Implementers implement Modification Detection with all due 2. Implementers implement Modification Detection with all due
speed and encourage its spread. speed and encourage its spread.
3. Users migrate to implementations that support Modification 3. Users migrate to implementations that support Modification
Detection with all due speed. Detection with all due speed.
* PKCS1 has been found to be vulnerable to attacks in which a
system reports that errors in padding differently from errors in
decryption becomes a random oracle that can leak the private key
in mere millions of queries. Implementations must be aware of
this attack and prevent it from happening. The simplest solution
is report a single error code for all variants of decryption
errors so as not to leak information to an attacker.
* Some technologies mentioned here may be subject to government * Some technologies mentioned here may be subject to government
control in some countries. control in some countries.
14. Implementation Nits 14. Implementation Nits
This section is a collection of comments to help an implementer, This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous particularly with an eye to backward compatibility. Previous
implementations of PGP are not OpenPGP-compliant. Often the implementations of PGP are not OpenPGP-compliant. Often the
differences are small, but small differences are frequently more differences are small, but small differences are frequently more
vexing than large differences. Thus, this is a non-comprehensive vexing than large differences. Thus, this is a non-comprehensive
skipping to change at page 72, line 31 skipping to change at page 71, line 50
[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC
1983, August 1996. 1983, August 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.
18. Full Copyright Statement 18. Full Copyright Statement
Copyright 2004 by The Internet Society. All Rights Reserved. Copyright 2004 by The Internet Society. All Rights Reserved.
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and the contributor, the organization he/she
represents or is sponsored by (if any), the internet society and the
internet engineering task force disclaim all warranties, express or
implied, including but not limited to any warranty that the use of
the information herein will not infringe any rights or any implied
warranties of merchantability or fitness for a particular purpose.
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
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
 End of changes. 

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