draft-ietf-openpgp-rfc2440bis-14.txt   draft-ietf-openpgp-rfc2440bis-15.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-14.txt draft-ietf-openpgp-rfc2440bis-15.txt
Expires January 2006 Lutz Donnerhacke Expires April 2006 Lutz Donnerhacke
July 2005 October 2005
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
PGP Corporation PGP Corporation
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-14.txt draft-ietf-openpgp-rfc2440bis-15.txt
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Status of this Memo IPR Claim Notice
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC 2026. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Status of this Memo
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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 IANA Considerations
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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
define an extension procedure. Instead requests to define new tag define an extension procedure. Instead requests to define new tag
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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
IPR Claim Notice 1 IPR Claim Notice 1
IESG Note 1 Status of this Memo 1
IANA Considerations 2
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
skipping to change at page 3, line 50 skipping to change at page 3, line 50
4.2.2.1. One-Octet Lengths 15 4.2.2.1. One-Octet Lengths 15
4.2.2.2. Two-Octet Lengths 15 4.2.2.2. Two-Octet Lengths 15
4.2.2.3. Five-Octet Lengths 15 4.2.2.3. Five-Octet Lengths 15
4.2.2.4. Partial Body Lengths 15 4.2.2.4. Partial Body Lengths 15
4.2.3. Packet Length Examples 16 4.2.3. Packet Length Examples 16
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 17 5. Packet Types 17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17
5.2. Signature Packet (Tag 2) 18 5.2. Signature Packet (Tag 2) 18
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 21
5.2.3. Version 4 Signature Packet Format 23 5.2.3. Version 4 Signature Packet Format 23
5.2.3.1. Signature Subpacket Specification 23 5.2.3.1. Signature Subpacket Specification 24
5.2.3.2. Signature Subpacket Types 25 5.2.3.2. Signature Subpacket Types 25
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 26 5.2.3.4. Signature creation time 26
5.2.3.5. Issuer 26 5.2.3.5. Issuer 27
5.2.3.6. Key expiration time 27 5.2.3.6. Key expiration time 27
5.2.3.7. Preferred symmetric algorithms 27 5.2.3.7. Preferred symmetric algorithms 27
5.2.3.8. Preferred hash algorithms 27 5.2.3.8. Preferred hash algorithms 27
5.2.3.9. Preferred compression algorithms 27 5.2.3.9. Preferred compression algorithms 27
5.2.3.10.Signature expiration time 27 5.2.3.10.Signature expiration time 27
5.2.3.11.Exportable Certification 28 5.2.3.11.Exportable Certification 28
5.2.3.12.Revocable 28 5.2.3.12.Revocable 28
5.2.3.13.Trust signature 28 5.2.3.13.Trust signature 28
5.2.3.14.Regular expression 29 5.2.3.14.Regular expression 29
5.2.3.15.Revocation key 29 5.2.3.15.Revocation key 29
skipping to change at page 5, line 30 skipping to change at page 5, line 30
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. DSA 63 12.5. DSA 63
12.6. Elgamal 64 12.6. Elgamal 64
12.7. Reserved Algorithm Numbers 64 12.7. Reserved Algorithm Numbers 64
12.8. OpenPGP CFB mode 64 12.8. OpenPGP CFB mode 64
13. Security Considerations 65 13. Security Considerations 65
14. Implementation Nits 68 14. Implementation Nits 68
15. Authors and Working Group Chair 69 15. Authors' Addresses 69
16. References (Normative) 70 16. References (Normative) 70
17. References (Non-Normative) 71 17. References (Non-Normative) 72
18. Full Copyright Statement 72 18. Full Copyright Statement 72
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 RFC 2440, "OpenPGP and key management functions. It is a revision of RFC 2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." Exchange Formats."
skipping to change at page 18, line 48 skipping to change at page 18, line 48
Implementations SHOULD accept V3 signatures. Implementations SHOULD Implementations SHOULD accept V3 signatures. Implementations SHOULD
generate V4 signatures. generate V4 signatures.
Note that if an implementation is creating an encrypted and signed Note that if an implementation is creating an encrypted and signed
message that is encrypted to a V3 key, it is reasonable to create a message that is encrypted to a V3 key, it is reasonable to create a
V3 signature. V3 signature.
5.2.1. Signature Types 5.2.1. Signature Types
There are a number of possible meanings for a signature, which are There are a number of possible meanings for a signature, which are
specified in a signature type octet in any given signature. These specified in a signature type octet in any given signature. See
meanings are: section 5.2.4, "Computing Signatures," for detailed information on
how to compute and verify signatures of each type.
These 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>. text data with its line endings converted to <CR><LF>.
skipping to change at page 19, line 50 skipping to change at page 19, line 50
certification authority to issue fine-grained claims. certification authority to issue fine-grained claims.
Most OpenPGP implementations make their "key signatures" as 0x10 Most OpenPGP implementations make their "key signatures" as 0x10
certifications. Some implementations can issue 0x11-0x13 certifications. Some implementations can issue 0x11-0x13
certifications, but few differentiate between the types. certifications, but few differentiate between the types.
0x18: Subkey Binding Signature 0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key that This signature is a statement by the top-level signing key that
indicates that it owns the subkey. This signature is calculated indicates that it owns the subkey. This signature is calculated
directly on the subkey itself, not on any User ID or other directly on the subkey itself, not on any User ID or other
packets. A signature that binds a signing subkey also has an packets. A signature that binds a signing subkey SHOULD have an
embedded signature subpacket in this binding signature which embedded signature subpacket in this binding signature which
contains a 0x19 signature made by the signing subkey on the contains a 0x19 signature made by the signing subkey on the
primary key. primary key.
0x19 Primary Key Binding Signature 0x19 Primary Key Binding Signature
This signature is a statement by a signing subkey, indicating This signature is a statement by a signing subkey, indicating
that it is owned by the primary key. This signature is that it is owned by the primary key. This signature is
calculated directly on the primary key itself, and not on any calculated directly on the primary key itself, and not on any
User ID or other packets. User ID or other packets.
skipping to change at page 20, line 38 skipping to change at page 20, line 38
revoked. A revoked subkey is not to be used. Only revocation revoked. A revoked subkey is not to be used. Only revocation
signatures by the top-level signature key that is bound to this signatures by the top-level signature key that is bound to this
subkey, or by an authorized revocation key, should be considered subkey, or by an authorized revocation key, should be considered
valid revocation signatures. valid revocation signatures.
0x30: Certification revocation signature 0x30: Certification revocation signature
This signature revokes an earlier User ID certification This signature revokes an earlier User ID certification
signature (signature class 0x10 through 0x13) or direct-key signature (signature class 0x10 through 0x13) or direct-key
signature (0x1F). It should be issued by the same key that signature (0x1F). It should be issued by the same key that
issued the revoked signature or an authorized revocation key. issued the revoked signature or an authorized revocation key.
The signature should have a later creation date than the The signature is computed over the same data as the certificate
signature it revokes. that it revokes, and should have a later creation date than that
certificate.
0x40: Timestamp signature. 0x40: Timestamp signature.
This signature is only meaningful for the timestamp contained in This signature is only meaningful for the timestamp contained in
it. it.
0x50: Third-Party Confirmation signature. 0x50: Third-Party Confirmation signature.
This signature is a signature over some other OpenPGP signature This signature is a signature over some other OpenPGP signature
packet(s). It is analogous to a notary seal on the signed data. packet(s). It is analogous to a notary seal on the signed data.
A third-party signature SHOULD include Signature Target A third-party signature SHOULD include Signature Target
subpacket(s) to give easy identification. Note that we really do subpacket(s) to give easy identification. Note that we really do
skipping to change at page 23, line 21 skipping to change at page 23, line 21
The body of a version 4 Signature Packet contains: The body of a version 4 Signature Packet contains:
- One-octet version number (4). - One-octet version number (4).
- One-octet signature type. - One-octet signature type.
- One-octet public key algorithm. - One-octet public key algorithm.
- One-octet hash algorithm. - One-octet hash algorithm.
- Two-octet scalar octet count for following hashed subpacket
data. Note that this is the length in octets of all of the
hashed subpackets; a pointer incremented by this number will
skip over the hashed subpackets.
- Hashed subpacket data set. (zero or more subpackets) - Hashed subpacket data set. (zero or more subpackets)
- Two-octet scalar octet count for the following unhashed - Two-octet scalar octet count for the following unhashed
subpacket data. Note that this is the length in octets of all of subpacket data. Note that this is the length in octets of all of
the unhashed subpackets; a pointer incremented by this number the unhashed subpackets; a pointer incremented by this number
will skip over the unhashed subpackets. will skip over the unhashed subpackets.
- Unhashed subpacket data set. (zero or more subpackets) - Unhashed subpacket data set. (zero or more subpackets)
- Two-octet field holding the left 16 bits of the signed hash - Two-octet field holding the left 16 bits of the signed hash
value. value.
- One or more multiprecision 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 concatenation of the data being signed and the signature data
the version number through the hashed subpacket data (inclusive) is from the version number through the hashed subpacket data
hashed. The resulting hash value is what is signed. The left 16 (inclusive) is hashed. The resulting hash value is what is signed.
bits of the hash are included in the signature packet to provide a The left 16 bits of the hash are included in the signature packet to
quick test to reject some invalid signatures. provide a 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
second is unhashed. The second set of subpackets is not second is unhashed. The second set of subpackets is not
cryptographically protected by the signature and should include only cryptographically protected by the signature and should include only
advisory information. advisory information.
The algorithms for converting the hash function result to a The algorithms for converting the hash function result to a
signature are described in a section below. signature are described in a section below.
5.2.3.1. Signature Subpacket Specification 5.2.3.1. Signature Subpacket Specification
A subpacket data set consists of zero or more signature subpackets, A subpacket data set consists of zero or more signature subpackets.
preceded by a two-octet scalar count of the length in octets of all In signature packets the subpacket data set is preceded by a
the subpackets; a pointer incremented by this number will skip over two-octet scalar count of the length in octets of all the
the subpacket data set. subpackets. A pointer incremented by this number will skip over the
subpacket data set.
Each subpacket consists of a subpacket header and a body. The Each subpacket consists of a subpacket header and a body. The
header consists of: header consists of:
- the subpacket length (1, 2, or 5 octets) - the subpacket length (1, 2, or 5 octets)
- the subpacket type (1 octet) - the subpacket type (1 octet)
and is followed by the subpacket specific data. and is followed by the subpacket specific data.
skipping to change at page 34, line 43 skipping to change at page 34, line 43
This subpacket contains a complete signature packet body as This subpacket contains a complete signature packet body as
specified in section 5.2 above. It is useful when one signature specified in section 5.2 above. It is useful when one signature
needs to refer to, or be incorporated in, another signature. needs to refer to, or be incorporated in, another signature.
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 For binary document signatures (type 0x00), the document data is
(types 0x00 and 0x01), for which the document itself is the data. hashed directly. For text document signatures (type 0x01), the
For standalone signatures, this is a null string. document is canonicalized by converting line endings to <CR><LF>,
and the resulting data is hashed.
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 (type 0x19) then hashes (type 0x18) or primary key binding signature (type 0x19) then hashes
the subkey using the same format as the main key (also using 0x99 as the subkey using the same format as the main key (also using 0x99 as
the first octet). Key revocation signatures (types 0x20 and 0x28) the first octet). Key revocation signatures (types 0x20 and 0x28)
hash only the key being revoked. hash only the key being revoked.
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
signature, and then the body of the signature packet. The unhashed
subpacket data of the signature packet being hashed is not included
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
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
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 User ID or data. A V3 certification hashes the contents of the User ID or
attribute packet packet, without any header. A V4 certification attribute packet packet, without any header. A V4 certification
hashes the constant 0xb4 for User ID certifications or the constant hashes the constant 0xb4 for User ID certifications or the constant
0xd1 for User Attribute certifications, followed by a four-octet 0xd1 for User Attribute certifications, followed by a four-octet
number giving the length of the User ID or User Attribute data, and number giving the length of the User ID or User Attribute data, and
then the User ID or User Attribute data. then the User ID or User Attribute data.
When a signature is made over a signature packet (type 0x50), the
hash data starts with the octet 0x88, followed by the four-octet
length of the signature, and then the body of the signature packet.
(Note that this is an old-style packet header for a signature packet
with the length-of-length set to zero). The unhashed subpacket data
of the signature packet being hashed is not included in the hash and
the unhashed subpacket data length value is set to zero.
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 39, line 19 skipping to change at page 39, line 19
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, there is an increased hashes the key material, but not its length, there is an increased
opportunity for fingerprint collisions. Third, there are minor opportunity for fingerprint collisions. Third, there are minor
weaknesses in the MD5 hash algorithm that make developers prefer weaknesses in the MD5 hash algorithm that make developers prefer
other algorithms. See below for a fuller discussion of key IDs and other algorithms. See below for a fuller discussion of key IDs and
fingerprints. fingerprints.
V2 keys are identical to V3 keys except for the deprecated V3 keys V2 keys are identical to the deprecated V3 keys except for the
except for the version number. An implementation MUST NOT generate version number. An implementation MUST NOT generate them and may
them and may accept or reject them as it sees fit. accept or reject them as it sees fit.
The version 4 format is similar to the version 3 format except for The version 4 format is similar to the version 3 format except for
the absence of a validity period. This has been moved to the the absence of a validity period. This has been moved to the
signature packet. In addition, fingerprints of version 4 keys are signature packet. In addition, fingerprints of version 4 keys are
calculated differently from version 3 keys, as described in section calculated differently from version 3 keys, as described in section
"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).
skipping to change at page 42, line 5 skipping to change at page 42, line 5
checksum is deprecated; an implementation SHOULD NOT use it, but checksum is deprecated; an implementation SHOULD NOT use it, but
should rather use the SHA-1 hash denoted with a usage octet of 254. 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 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 key that can undetectably modify the secret key. Using a SHA-1 hash
prevents this. 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 a literal
packets. data packet.
The body of this packet consists of: The body of this packet consists of:
- One octet that gives the algorithm used to compress the packet. - One octet that gives the algorithm used to compress the packet.
- The remainder of the packet is compressed data. - The remainder of the packet is compressed data.
A Compressed Data Packet's body contains an block that compresses A Compressed Data Packet's body contains an block that compresses
some set of packets. See section "Packet Composition" for details on some set of packets. See section "Packet Composition" for details on
how messages are formed. how messages are formed.
skipping to change at page 42, line 30 skipping to change at page 42, line 30
implementation uses more bits of compression, PGP V2.6 cannot implementation uses more bits of compression, PGP V2.6 cannot
decompress it. decompress it.
ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style
blocks. blocks.
5.7. Symmetrically Encrypted Data Packet (Tag 9) 5.7. Symmetrically Encrypted Data Packet (Tag 9)
The Symmetrically Encrypted Data packet contains data encrypted with The Symmetrically Encrypted Data packet contains data encrypted with
a symmetric-key algorithm. When it has been decrypted, it contains a symmetric-key algorithm. When it has been decrypted, it contains
other packets (usually literal data packets or compressed data other packets (usually a literal data packet or compressed data
packets, but in theory other Symmetrically Encrypted Data Packets or packet, but in theory other Symmetrically Encrypted Data Packets or
sequences of packets that form whole OpenPGP messages). sequences of packets that form whole OpenPGP messages).
The body of this packet consists of: The body of this packet consists of:
- Encrypted data, the output of the selected symmetric-key cipher - Encrypted data, the output of the selected symmetric-key cipher
operating in OpenPGP's variant of Cipher Feedback (CFB) mode. operating in OpenPGP's variant of Cipher Feedback (CFB) mode.
The symmetric cipher used may be specified in an Public-Key or The symmetric cipher used may be specified in an Public-Key or
Symmetric-Key Encrypted Session Key packet that precedes the Symmetric-Key Encrypted Session Key packet that precedes the
Symmetrically Encrypted Data Packet. In that case, the cipher Symmetrically Encrypted Data Packet. In that case, the cipher
skipping to change at page 44, line 42 skipping to change at page 44, line 42
implementation. implementation.
Trust packets SHOULD NOT be emitted to output streams that are Trust packets SHOULD NOT be emitted to output streams that are
transferred to other users, and they SHOULD be ignored on any input transferred to other users, and they SHOULD be ignored on any input
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 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 RFC 822 mail name, but there are no convention, it includes an RFC 2822 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 limited to text. Like the User ID packet, a User Attribute which is limited to text. Like the User ID packet, a User Attribute
packet may be certified by the key owner ("self-signed") or any 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 other key owner who cares to certify it. Except as noted, a User
skipping to change at page 59, line 25 skipping to change at page 59, line 25
An OpenPGP message is a packet or sequence of packets that An OpenPGP message is a packet or sequence of packets that
corresponds to the following grammatical rules (comma represents corresponds to the following grammatical rules (comma represents
sequential composition, and vertical bar separates alternatives): sequential composition, and vertical bar separates alternatives):
OpenPGP Message :- Encrypted Message | Signed Message | OpenPGP Message :- Encrypted Message | Signed Message |
Compressed Message | Literal Message. Compressed Message | Literal Message.
Compressed Message :- Compressed Data Packet. Compressed Message :- Compressed Data Packet.
Literal Message :- Literal Data Packet | Literal Message :- Literal Data Packet.
Literal Message, Literal Data Packet.
ESK :- Public Key Encrypted Session Key Packet | ESK :- Public Key Encrypted Session Key Packet |
Symmetric-Key Encrypted Session Key Packet. Symmetric-Key Encrypted Session Key Packet.
ESK Sequence :- ESK | ESK Sequence, ESK. ESK Sequence :- ESK | ESK Sequence, ESK.
Encrypted Data :- Symmetrically Encrypted Data Packet | Encrypted Data :- Symmetrically Encrypted Data Packet |
Symmetrically Encrypted Integrity Protected Data Packet Symmetrically Encrypted Integrity Protected Data Packet
Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data. Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data.
skipping to change at page 68, line 15 skipping to change at page 68, line 15
* 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.
* In winter 2005, Serge Mister and Robert Zuccherato from Entrust * In winter 2005, Serge Mister and Robert Zuccherato from Entrust
released a paper describing a way that the "quick check" in released a paper describing a way that the "quick check" in
OpenPGP CFB mode can be used with a random oracle to decrypt two OpenPGP CFB mode can be used with a random oracle to decrypt two
octets of every cipher block [MZ05]. They recommend as octets of every cipher block [MZ05]. They recommend as
prevention not using the quick check at all. prevention not using the quick check at all.
Many implementers have taken this advice to heart for any data Many implementers have taken this advice to heart for any data
that is both symmetrically encrypted, but also the session key that is symmetrically encrypted and for which the session key is
is public-key encrypted. In this case, the quick check is not public-key encrypted. In this case, the quick check is not
needed as the public key encryption of the session key should needed as the public key encryption of the session key should
guarantee that it is the right session key. In other cases, the guarantee that it is the right session key. In other cases, the
implementation should use the quick check with care. On the one implementation should use the quick check with care.
hand, there is a danger to using it if there is a random oracle
that can leak information to an attacker. On the other hand, it On the one hand, there is a danger to using it if there is a
is inconvenient to the user to be informed that they typed in random oracle that can leak information to an attacker. In
the wrong passphrase only after a petabyte of data is decrypted. plainer language, there is a danger to using the quick check if
There are many cases in cryptographic engineering where the timing information about the check can be exposed to an
implementer must use care and wisdom, and this is another. attacker, particularly via an automated service that allows
rapidly repeated queries
On the other hand, it is inconvenient to the user to be informed
that they typed in the wrong passphrase only after a petabyte of
data is decrypted. There are many cases in cryptographic
engineering where the implementer must use care and wisdom, and
this is one.
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
list of potential problems and gotchas for a developer who is trying list of potential problems and gotchas for a developer who is trying
to be backward-compatible. to be backward-compatible.
skipping to change at page 69, line 23 skipping to change at page 69, line 29
* 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.
15. Authors and Working Group Chair 15. Authors' Addresses
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Derek Atkins Derek Atkins
IHTFP Consulting, Inc. IHTFP Consulting, Inc.
6 Farragut Ave 6 Farragut Ave
Somerville, MA 02144 USA Somerville, MA 02144 USA
Email: derek@ihtfp.com Email: derek@ihtfp.com
Tel: +1 617 623 3745 Tel: +1 617 623 3745
skipping to change at page 69, line 37 skipping to change at page 69, line 43
Derek Atkins Derek Atkins
IHTFP Consulting, Inc. IHTFP Consulting, Inc.
6 Farragut Ave 6 Farragut Ave
Somerville, MA 02144 USA Somerville, MA 02144 USA
Email: derek@ihtfp.com Email: derek@ihtfp.com
Tel: +1 617 623 3745 Tel: +1 617 623 3745
The principal authors of this draft are: The principal authors of this draft are:
Jon Callas Jon Callas
Email: jon@callas.org Email: jon@callas.org
Tel: +1 (408) 448-6801
Lutz Donnerhacke Lutz Donnerhacke
IKS GmbH IKS GmbH
Wildenbruchstr. 15 Wildenbruchstr. 15
07745 Jena, Germany 07745 Jena, Germany
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Tel: +49-3641-675642
Hal Finney Hal Finney
Network Associates, Inc.
3965 Freedom Circle
Santa Clara, CA 95054, USA
Email: hal@finney.org Email: hal@finney.org
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, David Shaw, William Stallings, Mark Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark
Weaver, and Philip R. Zimmermann. Weaver, and Philip R. Zimmermann.
16. References (Normative) 16. References (Normative)
skipping to change at page 70, line 50 skipping to change at page 70, line 50
fips180-2/fips180-2withchangenotice.pdf> fips180-2/fips180-2withchangenotice.pdf>
[FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2). [FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2).
<http://csrc.nist.gov/publications/fips/fips186-2/ <http://csrc.nist.gov/publications/fips/fips186-2/
fips186-2-change1.pdf> fips186-2-change1.pdf>
[HAC] Alfred Menezes, Paul van Oorschot, and Scott [HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996. Press, 1996.
<http://www.cacr.math.uwaterloo.ca/hac/> <http://www.cacr.math.uwaterloo.ca/hac/>
[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). [JFIF] JPEG File Interchange Format (Version 1.02).
Eric Hamilton, C-Cube Microsystems, Milpitas, CA, Eric Hamilton, C-Cube Microsystems, Milpitas, CA,
September 1, 1992. September 1, 1992.
[RFC822] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August
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
Identifiers", RFC 1423, October 1993. Identifiers", RFC 1423, October 1993.
[RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with [RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with
MIME", RFC 1641, July 1994. MIME", RFC 1641, July 1994.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, [RFC1750] Eastlake, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC "Randomness Recommendations for Security", RFC
1750, December 1994. 1750, December 1994.
[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.
[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.
[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.
[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.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
August 2001. August 2001.
[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. References (Non-Normative) 17. References (Non-Normative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key," signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is proceedings has an error. A revised version is
skipping to change at page 72, line 18 skipping to change at page 72, line 31
against PGP and GnuPG" against PGP and GnuPG"
http://www.counterpane.com/pgp-attack.html http://www.counterpane.com/pgp-attack.html
[MZ05] Serge Mister, Robert Zuccherato, "An Attack on [MZ05] Serge Mister, Robert Zuccherato, "An Attack on
CFB Mode Encryption As Used By OpenPGP," IACR CFB Mode Encryption As Used By OpenPGP," IACR
ePrint Archive: Report 2005/033, 8 Feb 2005 ePrint Archive: Report 2005/033, 8 Feb 2005
http://eprint.iacr.org/2005/033 http://eprint.iacr.org/2005/033
[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 2005 by The Internet Society. All Rights Reserved. Copyright (C) 2005 by The Internet Society.
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and the contributor, the organization he/she an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
represents or is sponsored by (if any), the internet society and the REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
internet engineering task force disclaim all warranties, express or INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
implied, including but not limited to any warranty that the use of IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
the information herein will not infringe any rights or any implied THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
warranties of merchantability or fitness for a particular purpose. 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
 End of changes. 51 change blocks. 
85 lines changed or deleted 126 lines changed or added

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