draft-ietf-openpgp-rfc2440bis-12.txt   draft-ietf-openpgp-rfc2440bis-13.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-12.txt draft-ietf-openpgp-rfc2440bis-13.txt
Expires May 2005 Lutz Donnerhacke Expires November 2005 Lutz Donnerhacke
November 2004 May 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-12.txt draft-ietf-openpgp-rfc2440bis-13.txt
Copyright 2004 by The Internet Society. All Rights Reserved. Copyright (C) The Internet Society (2005).
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 IPR Claim Notice
By submitting this Internet-Draft, any applicable patent or other By submitting this Internet-Draft, each author represents that any
IPR claims of which we are aware have been disclosed in accordance applicable patent or other IPR claims of which he or she is aware
with RFC 3668. 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 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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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
5.2.3.16.Notation Data 29 5.2.3.16.Notation Data 29
5.2.3.17.Key server preferences 30 5.2.3.17.Key server preferences 30
5.2.3.18.Preferred key server 30 5.2.3.18.Preferred key server 30
5.2.3.19.Primary User ID 31 5.2.3.19.Primary User ID 31
5.2.3.20.Policy URL 31 5.2.3.20.Policy URI 31
5.2.3.21.Key Flags 31 5.2.3.21.Key Flags 31
5.2.3.22.Signer's User ID 32 5.2.3.22.Signer's User ID 32
5.2.3.23.Reason for Revocation 32 5.2.3.23.Reason for Revocation 32
5.2.3.24.Features 33 5.2.3.24.Features 33
5.2.3.25.Signature Target 34 5.2.3.25.Signature Target 34
5.2.3.26.Embedded Signature 34 5.2.3.26.Embedded Signature 34
5.2.4. Computing Signatures 34 5.2.4. Computing Signatures 34
5.2.4.1. Subpacket Hints 35 5.2.4.1. Subpacket Hints 35
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 36 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 36
5.4. One-Pass Signature Packets (Tag 4) 36 5.4. One-Pass Signature Packets (Tag 4) 37
5.5. Key Material Packet 37 5.5. Key Material Packet 37
5.5.1. Key Packet Variants 37 5.5.1. Key Packet Variants 37
5.5.1.1. Public Key Packet (Tag 6) 37 5.5.1.1. Public Key Packet (Tag 6) 37
5.5.1.2. Public Subkey Packet (Tag 14) 37 5.5.1.2. Public Subkey Packet (Tag 14) 38
5.5.1.3. Secret Key Packet (Tag 5) 38 5.5.1.3. Secret Key Packet (Tag 5) 38
5.5.1.4. Secret Subkey Packet (Tag 7) 38 5.5.1.4. Secret Subkey Packet (Tag 7) 38
5.5.2. Public Key Packet Formats 38 5.5.2. Public Key Packet Formats 38
5.5.3. Secret Key Packet Formats 39 5.5.3. Secret Key Packet Formats 40
5.6. Compressed Data Packet (Tag 8) 41 5.6. Compressed Data Packet (Tag 8) 41
5.7. Symmetrically Encrypted Data Packet (Tag 9) 42 5.7. Symmetrically Encrypted Data Packet (Tag 9) 42
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 43 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 43
5.9. Literal Data Packet (Tag 11) 43 5.9. Literal Data Packet (Tag 11) 43
5.10. Trust Packet (Tag 12) 44 5.10. Trust Packet (Tag 12) 44
5.11. User ID Packet (Tag 13) 44 5.11. User ID Packet (Tag 13) 44
5.12. User Attribute Packet (Tag 17) 44 5.12. User Attribute Packet (Tag 17) 44
5.12.1. The Image Attribute Subpacket 45 5.12.1. The Image Attribute Subpacket 45
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 46
5.14. Modification Detection Code Packet (Tag 19) 47 5.14. Modification Detection Code Packet (Tag 19) 47
6. Radix-64 Conversions 48 6. Radix-64 Conversions 48
6.1. An Implementation of the CRC-24 in "C" 48 6.1. An Implementation of the CRC-24 in "C" 49
6.2. Forming ASCII Armor 49 6.2. Forming ASCII Armor 49
6.3. Encoding Binary in Radix-64 51 6.3. Encoding Binary in Radix-64 51
6.4. Decoding Radix-64 52 6.4. Decoding Radix-64 52
6.5. Examples of Radix-64 53 6.5. Examples of Radix-64 53
6.6. Example of an ASCII Armored Message 53 6.6. Example of an ASCII Armored Message 53
7. Cleartext signature framework 53 7. Cleartext signature framework 54
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 56
9.2. Symmetric Key Algorithms 56 9.2. Symmetric Key Algorithms 56
9.3. Compression Algorithms 56 9.3. Compression Algorithms 57
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 59 10.2. OpenPGP Messages 59
10.3. Detached Signatures 59 10.3. Detached Signatures 59
11. Enhanced Key Formats 59 11. Enhanced Key Formats 60
11.1. Key Structures 59 11.1. Key Structures 60
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. DSA 63 12.5. DSA 63
12.6. Elgamal 63 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 67 14. Implementation Nits 68
15. Authors and Working Group Chair 68 15. Authors and Working Group Chair 69
16. References (Normative) 69 16. References (Normative) 70
17. References (Non-Normative) 71 17. References (Non-Normative) 71
18. Full Copyright Statement 71 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 RFC2440, "OpenPGP and key management functions. It is a revision of RFC2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." Exchange Formats."
1.1. Terms 1.1. Terms
skipping to change at page 6, line 27 skipping to change at page 6, line 27
* PGP - Pretty Good Privacy. PGP is a family of software systems * PGP - Pretty Good Privacy. PGP is a family of software systems
developed by Philip R. Zimmermann from which OpenPGP is based. developed by Philip R. Zimmermann from which OpenPGP is based.
* PGP 2.6.x - This version of PGP has many variants, hence the * PGP 2.6.x - This version of PGP has many variants, hence the
term PGP 2.6.x. It used only RSA, MD5, and IDEA for its term PGP 2.6.x. It used only RSA, MD5, and IDEA for its
cryptographic transforms. An informational RFC, RFC1991, was cryptographic transforms. An informational RFC, RFC1991, was
written describing this version of PGP. written describing this version of PGP.
* PGP 5.x - This version of PGP is formerly known as "PGP 3" in * PGP 5.x - This version of PGP is formerly known as "PGP 3" in
the community and also in the predecessor of this document, the community and also in the predecessor of this document, RFC
RFC1991. It has new formats and corrects a number of problems in 1991. It has new formats and corrects a number of problems in
the PGP 2.6.x design. It is referred to here as PGP 5.x because the PGP 2.6.x design. It is referred to here as PGP 5.x because
that software was the first release of the "PGP 3" code base. that software was the first release of the "PGP 3" code base.
* GPG - GNU Privacy Guard, also called GnuPG. GPG is an OpenPGP * GPG - GNU Privacy Guard, also called GnuPG. GPG is an OpenPGP
implementation that avoids all encumbered algorithms. implementation that avoids all encumbered algorithms.
Consequently, early versions of GPG did not include RSA public Consequently, early versions of GPG did not include RSA public
keys. GPG may or may not have (depending on version) support for keys. GPG may or may not have (depending on version) support for
IDEA or other encumbered algorithms. IDEA or other encumbered algorithms.
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of
skipping to change at page 8, line 27 skipping to change at page 8, line 27
received message and verifies it using the message's signature. received message and verifies it using the message's signature.
If the verification is successful, the message is accepted as If the verification is successful, the message is accepted as
authentic. authentic.
2.3. Compression 2.3. Compression
OpenPGP implementations SHOULD compress the message after applying OpenPGP implementations SHOULD compress the message after applying
the signature but before encryption. the signature but before encryption.
If an implementation does not implement compression, its authors If an implementation does not implement compression, its authors
should be aware that most PGP messages in the world are compressed. should be aware that most OpenPGP messages in the world are
Thus, it may even be wise for a space-constrained implementation to compressed. Thus, it may even be wise for a space-constrained
implement decompression, but not compression. implementation to implement decompression, but not compression.
Furthermore, compression has the added side-effect that some types Furthermore, compression has the added side-effect that some types
of attacks can be thwarted by the fact that slightly altered, of attacks can be thwarted by the fact that slightly altered,
compressed data rarely uncompresses without severe errors. This is compressed data rarely uncompresses without severe errors. This is
hardly rigorous, but it is operationally useful. These attacks can hardly rigorous, but it is operationally useful. These attacks can
be rigorously prevented by implementing and using Modification be rigorously prevented by implementing and using Modification
Detection Codes as described in sections following. Detection Codes as described in sections following.
2.4. Conversion to Radix-64 2.4. Conversion to Radix-64
skipping to change at page 9, line 48 skipping to change at page 9, line 48
string [00 09 01 FF] forms an MPI with the value of 511. string [00 09 01 FF] forms an MPI with the value of 511.
Additional rules: Additional rules:
The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.
The length field of an MPI describes the length starting from its The length field of an MPI describes the length starting from its
most significant non-zero bit. Thus, the MPI [00 02 01] is not most significant non-zero bit. Thus, the MPI [00 02 01] is not
formed correctly. It should be [00 01 01]. formed correctly. It should be [00 01 01].
Unused bits of an MPI MUST be zero.
Also note that when an MPI is encrypted, the length refers to the Also note that when an MPI is encrypted, the length refers to the
plaintext MPI. It may be ill-formed in its ciphertext. plaintext MPI. It may be ill-formed in its ciphertext.
3.3. Key IDs 3.3. Key IDs
A Key ID is an eight-octet scalar that identifies a key. A Key ID is an eight-octet scalar that identifies a key.
Implementations SHOULD NOT assume that Key IDs are unique. The Implementations SHOULD NOT assume that Key IDs are unique. The
section, "Enhanced Key Formats" below describes how Key IDs are section, "Enhanced Key Formats" below describes how Key IDs are
formed. formed.
3.4. Text 3.4. Text
Unless otherwise specified, the character set for text is the UTF-8 Unless otherwise specified, the character set for text is the UTF-8
[RFC2279] encoding of Unicode [ISO10646]. [RFC2279] encoding of Unicode [ISO10646].
3.5. Time fields 3.5. Time fields
skipping to change at page 14, line 7 skipping to change at page 14, line 7
7. A mask for this bit is 0x80 in hexadecimal. 7. A mask for this bit is 0x80 in hexadecimal.
+---------------+ +---------------+
PTag |7 6 5 4 3 2 1 0| PTag |7 6 5 4 3 2 1 0|
+---------------+ +---------------+
Bit 7 -- Always one Bit 7 -- Always one
Bit 6 -- New packet format if set Bit 6 -- New packet format if set
PGP 2.6.x only uses old format packets. Thus, software that PGP 2.6.x only uses old format packets. Thus, software that
interoperates with those versions of PGP must only use old format interoperates with those versions of PGP must only use old format
packets. If interoperability is not an issue, the new packet format packets. If interoperability is not an issue, the new packet format
is preferred. Note that old format packets have four bits of content is preferred. Note that old format packets have four bits of packet
tags, and new format packets have six; some features cannot be used tags, and new format packets have six; some features cannot be used
and still be backward-compatible. and still be backward-compatible.
Also note that packets with a tag greater than or equal to 16 MUST Also note that packets with a tag greater than or equal to 16 MUST
use new format packets. The old format packets can only express tags use new format packets. The old format packets can only express tags
less than or equal to 15. less than or equal to 15.
Old format packets contain: Old format packets contain:
Bits 5-2 -- content tag Bits 5-2 -- packet tag
Bits 1-0 - length-type Bits 1-0 - length-type
New format packets contain: New format packets contain:
Bits 5-0 -- content tag Bits 5-0 -- packet tag
4.2.1. Old-Format Packet Lengths 4.2.1. Old-Format Packet Lengths
The meaning of the length-type in old-format packets is: The meaning of the length-type in old-format packets is:
0 - The packet has a one-octet length. The header is 2 octets long. 0 - The packet has a one-octet length. The header is 2 octets long.
1 - The packet has a two-octet length. The header is 3 octets long. 1 - The packet has a two-octet length. The header is 3 octets long.
2 - The packet has a four-octet length. The header is 5 octets long. 2 - The packet has a four-octet length. The header is 5 octets long.
skipping to change at page 19, line 20 skipping to change at page 19, line 20
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
owner of the key is in fact the person described by the User ID. owner of the key is in fact the person described by the User ID.
Note that all PGP "key signatures" are this type of
certification.
0x11: Persona certification of a User ID and Public Key packet. 0x11: Persona certification of a User ID and Public Key packet.
The issuer of this certification has not done any verification The issuer of this certification has not done any verification
of the claim that the owner of this key is the User ID of the claim that the owner of this key is the User ID
specified. specified.
0x12: Casual certification of a User ID and Public Key packet. 0x12: Casual certification of a User ID and Public Key packet.
The issuer of this certification has done some casual The issuer of this certification has done some casual
verification of the claim of identity. verification of the claim of identity.
0x13: Positive certification of a User ID and Public Key packet. 0x13: Positive certification of a User ID and Public Key packet.
The issuer of this certification has done substantial The issuer of this certification has done substantial
verification of the claim of identity. verification of the claim of identity.
Please note that the vagueness of these certification claims is Please note that the vagueness of these certification claims is
not a flaw, but a feature of the system. Because PGP places not a flaw, but a feature of the system. Because OpenPGP places
final authority for validity upon the receiver of a final authority for validity upon the receiver of a
certification, it may be that one authority's casual certification, it may be that one authority's casual
certification might be more rigorous than some other authority's certification might be more rigorous than some other authority's
positive certification. These classifications allow a positive certification. These classifications allow a
certification authority to issue fine-grained claims. certification authority to issue fine-grained claims.
Most OpenPGP implementations make their "key signatures" as 0x10
certifications. Some implementations can issue 0x11-0x13
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 also has 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
skipping to change at page 21, line 22 skipping to change at page 21, line 24
- 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 multiprecision 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 concatenation of the data to be signed, the signature type and
creation time from the signature packet are hashed (5 additional creation time from the signature packet (5 additional octets) is
octets). The resulting hash value is used in the signature hashed. The resulting hash value is used in the signature algorithm.
algorithm. The high 16 bits (first two octets) of the hash are The high 16 bits (first two octets) of the hash are included in the
included in the signature packet to provide a quick test to reject signature packet to provide a quick test to reject some invalid
some invalid signatures. signatures.
Algorithm Specific Fields for RSA signatures: Algorithm Specific Fields for RSA signatures:
- multiprecision integer (MPI) of RSA signature value m**d mod n. - multiprecision integer (MPI) of RSA signature value m**d mod n.
Algorithm Specific Fields for DSA signatures: Algorithm Specific Fields for DSA signatures:
- MPI of DSA value r. - MPI of DSA value r.
- MPI of DSA value s. - MPI of DSA value s.
skipping to change at page 23, line 17 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 - Hashed subpacket data set. (zero or more subpackets)
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. (zero or more subpackets)
- Two-octet scalar octet count for following unhashed subpacket - Two-octet scalar octet count for the following unhashed
data. Note that this is the length in octets of all of the subpacket data. Note that this is the length in octets of all of
unhashed subpackets; a pointer incremented by this number will the unhashed subpackets; a pointer incremented by this number
skip over the unhashed subpackets. will skip over the unhashed subpackets.
- Unhashed subpacket data. (zero or more subpackets) - Unhashed subpacket data set. (zero or more subpackets)
- Two-octet field holding left 16 bits of signed hash value. - Two-octet field holding the left 16 bits of the signed hash
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 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.
skipping to change at page 23, line 53 skipping to change at page 23, line 53
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
The subpacket fields consist of zero or more signature subpackets. A subpacket data set consists of zero or more signature subpackets,
Each set of subpackets is preceded by a two-octet scalar count of preceded by a two-octet scalar count of the length in octets of all
the length of the set of subpackets. the 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 24, line 49 skipping to change at page 24, line 50
10 = placeholder for backward compatibility 10 = placeholder for backward compatibility
11 = preferred symmetric algorithms 11 = preferred symmetric algorithms
12 = revocation key 12 = revocation key
16 = issuer key ID 16 = issuer key ID
20 = notation data 20 = notation data
21 = preferred hash algorithms 21 = preferred hash algorithms
22 = preferred compression algorithms 22 = preferred compression algorithms
23 = key server preferences 23 = key server preferences
24 = preferred key server 24 = preferred key server
25 = primary User ID 25 = primary User ID
26 = policy URL 26 = policy URI
27 = key flags 27 = key flags
28 = signer's User ID 28 = signer's User ID
29 = reason for revocation 29 = reason for revocation
30 = features 30 = features
31 = signature target 31 = signature target
32 = embedded signature 32 = embedded signature
100 to 110 = internal or user-defined 100 to 110 = internal or user-defined
An implementation SHOULD ignore any subpacket of a type that it does An implementation SHOULD ignore any subpacket of a type that it does
not recognize. not recognize.
Bit 7 of the subpacket type is the "critical" bit. If set, it Bit 7 of the subpacket type is the "critical" bit. If set, it
denotes that the subpacket is one that is critical for the evaluator denotes that the subpacket is one that is critical for the evaluator
of the signature to recognize. If a subpacket is encountered that of the signature to recognize. If a subpacket is encountered that
is marked critical but is unknown to the evaluating software, the is marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error. evaluator SHOULD consider the signature to be in error.
skipping to change at page 27, line 17 skipping to change at page 27, line 17
(4 octet time field) (4 octet time field)
The validity period of the key. This is the number of seconds after The validity period of the key. This is the number of seconds after
the key creation time that the key expires. If this is not present the key creation time that the key expires. If this is not present
or has a value of zero, the key never expires. This is found only on or has a value of zero, the key never expires. This is found only on
a self-signature. a self-signature.
5.2.3.7. Preferred symmetric algorithms 5.2.3.7. Preferred symmetric algorithms
(sequence of one-octet values) (array of one-octet values)
Symmetric algorithm numbers that indicate which algorithms the key Symmetric algorithm numbers that indicate which algorithms the key
holder prefers to use. The subpacket body is an ordered list of holder prefers to use. The subpacket body is an ordered list of
octets with the most preferred listed first. It is assumed that only octets with the most preferred listed first. It is assumed that only
algorithms listed are supported by the recipient's software. algorithms listed are supported by the recipient's software.
Algorithm numbers in section 9. This is only found on a Algorithm numbers in section 9. This is only found on a
self-signature. self-signature.
5.2.3.8. Preferred hash algorithms 5.2.3.8. Preferred hash algorithms
(array of one-octet values) (array of one-octet values)
Message digest algorithm numbers that indicate which algorithms the Message digest algorithm numbers that indicate which algorithms the
key holder prefers to receive. Like the preferred symmetric key holder prefers to receive. Like the preferred symmetric
algorithms, the list is ordered. Algorithm numbers are in section 6. algorithms, the list is ordered. Algorithm numbers are in section 9.
This is only found on a self-signature. This is only found on a self-signature.
5.2.3.9. Preferred compression algorithms 5.2.3.9. Preferred compression algorithms
(array of one-octet values) (array of one-octet values)
Compression algorithm numbers that indicate which algorithms the key Compression algorithm numbers that indicate which algorithms the key
holder prefers to use. Like the preferred symmetric algorithms, the holder prefers to use. Like the preferred symmetric algorithms, the
list is ordered. Algorithm numbers are in section 6. If this list is ordered. Algorithm numbers are in section 9. If this
subpacket is not included, ZIP is preferred. A zero denotes that subpacket is not included, ZIP is preferred. A zero denotes that
uncompressed data is preferred; the key holder's software might have uncompressed data is preferred; the key holder's software might have
no compression software in that implementation. This is only found no compression software in that implementation. This is only found
on a self-signature. on a self-signature.
5.2.3.10. Signature expiration time 5.2.3.10. Signature expiration time
(4 octet time field) (4 octet time field)
The validity period of the signature. This is the number of seconds The validity period of the signature. This is the number of seconds
skipping to change at page 30, line 16 skipping to change at page 30, line 16
First octet: 0x80 = human-readable. This note value is text, a First octet: 0x80 = human-readable. This note value is text, a
note from one person to another, and need note from one person to another, and need
not have meaning to software. not have meaning to software.
Other octets: none. Other octets: none.
Notation names are arbitrary strings encoded in UTF-8. They reside Notation names are arbitrary strings encoded in UTF-8. They reside
two name spaces: The IETF name space and the user name space. two name spaces: The IETF name space and the user name space.
The IETF name space is registered with IANA. These names MUST NOT The IETF name space is registered with IANA. These names MUST NOT
contain the "@" character (0x40) is this is a tag for the user name contain the "@" character (0x40). This this is a tag for the user
space. name space.
Names in the user name space consist of a UTF-8 string tag followed Names in the user name space consist of a UTF-8 string tag followed
by "@" followed by a DNS domain name. Note that the tag MUST NOT by "@" followed by a DNS domain name. Note that the tag MUST NOT
contain an "@" character. For example, the "sample" tag used by contain an "@" character. For example, the "sample" tag used by
Example Corporation could be "sample@example.com". Example Corporation could be "sample@example.com".
Names in a user space are owned and controlled by the owners of that Names in a user space are owned and controlled by the owners of that
domain. Obviously, it's of bad form to create a new name in a DNS domain. Obviously, it's of bad form to create a new name in a DNS
space that you don't own. space that you don't own.
Since the user name space is in the form of an email address, Since the user name space is in the form of an email address,
implementers MAY wish to arrange for that address to reach a person implementers MAY wish to arrange for that address to reach a person
who can be consulted about the use of the named tag. Note that due who can be consulted about the use of the named tag. Note that due
to UTF-8 encoding, not all valid user space name tags are valid to UTF-8 encoding, not all valid user space name tags are valid
email addresses. email addresses.
If there is a critical notation, the criticality applies to that
specific notation and not to notations in general.
5.2.3.17. Key server preferences 5.2.3.17. Key server preferences
(N octets of flags) (N octets of flags)
This is a list of one-bit flags that indicate preferences that the This is a list of one-bit flags that indicate preferences that the
key holder has about how the key is handled on a key server. All key holder has about how the key is handled on a key server. All
undefined flags MUST be zero. undefined flags MUST be zero.
First octet: 0x80 = No-modify First octet: 0x80 = No-modify
the key holder requests that this key only be modified or the key holder requests that this key only be modified or
updated by the key holder or an administrator of the key server. updated by the key holder or an administrator of the key server.
This is found only on a self-signature. This is found only on a self-signature.
5.2.3.18. Preferred key server 5.2.3.18. Preferred key server
(String) (String)
This is a URI of a key server that the key holder prefers be used
This is a URL of a key server that the key holder prefers be used
for updates. Note that keys with multiple User IDs can have a for updates. Note that keys with multiple User IDs can have a
preferred key server for each User ID. Note also that since this is preferred key server for each User ID. Note also that since this is
a URL, the key server can actually be a copy of the key retrieved by a URI, the key server can actually be a copy of the key retrieved by
ftp, http, finger, etc. ftp, http, finger, etc.
5.2.3.19. Primary User ID 5.2.3.19. Primary User ID
(1 octet, Boolean) (1 octet, Boolean)
This is a flag in a User ID's self signature that states whether This is a flag in a User ID's self signature that states whether
this User ID is the main User ID for this key. It is reasonable for this User ID is the main User ID for this key. It is reasonable for
an implementation to resolve ambiguities in preferences, etc. by an implementation to resolve ambiguities in preferences, etc. by
referring to the primary User ID. If this flag is absent, its value referring to the primary User ID. If this flag is absent, its value
skipping to change at page 31, line 25 skipping to change at page 31, line 30
it is RECOMMENDED that priority be given to the User ID with the it is RECOMMENDED that priority be given to the User ID with the
most recent self-signature. most recent self-signature.
When appearing on a self-signature on a User ID packet, this When appearing on a self-signature on a User ID packet, this
subpacket applies only to User ID packets. When appearing on a subpacket applies only to User ID packets. When appearing on a
self-signature on a User Attribute packet, this subpacket applies self-signature on a User Attribute packet, this subpacket applies
only to User Attribute packets. That is to say, there are two only to User Attribute packets. That is to say, there are two
different and independent "primaries" - one for User IDs, and one different and independent "primaries" - one for User IDs, and one
for User Attributes. for User Attributes.
5.2.3.20. Policy URL 5.2.3.20. Policy URI
(String) (String)
This subpacket contains a URL of a document that describes the This subpacket contains a URI of a document that describes the
policy that the signature was issued under. policy that the signature was issued under.
5.2.3.21. Key Flags 5.2.3.21. Key Flags
(N octets of flags) (N octets of flags)
This subpacket contains a list of binary flags that hold information This subpacket contains a list of binary flags that hold information
about a key. It is a string of octets, and an implementation MUST about a key. It is a string of octets, and an implementation MUST
NOT assume a fixed size. This is so it can grow over time. If a list NOT assume a fixed size. This is so it can grow over time. If a list
is shorter than an implementation expects, the unstated flags are is shorter than an implementation expects, the unstated flags are
skipping to change at page 33, line 6 skipping to change at page 33, line 9
(1 octet of revocation code, N octets of reason string) (1 octet of revocation code, N octets of reason string)
This subpacket is used only in key revocation and certification This subpacket is used only in key revocation and certification
revocation signatures. It describes the reason why the key or revocation signatures. It describes the reason why the key or
certificate was revoked. certificate was revoked.
The first octet contains a machine-readable code that denotes the The first octet contains a machine-readable code that denotes the
reason for the revocation: reason for the revocation:
0x00 - No reason specified (key revocations or cert revocations) 0x00 - No reason specified (key revocations or cert revocations)
0x01 - Key is superceded (key revocations) 0x01 - Key is superseded (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.
If a key has been revoked because of a compromise, all signatures If a key has been revoked because of a compromise, all signatures
created by that key are suspect. However, if it was merely created by that key are suspect. However, if it was merely
superceded or retired, old signatures are still valid. If the superseded or retired, old signatures are still valid. If the
revoked signature is the self-signature for certifying a User ID, a revoked signature is the self-signature for certifying a User ID, a
revocation denotes that that user name is no longer in use. Such a revocation denotes that that user name is no longer in use. Such a
revocation SHOULD include an 0x20 subpacket. revocation SHOULD include an 0x20 subpacket.
Note that any signature may be revoked, including a certification on Note that any signature may be revoked, including a certification on
some other person's key. There are many good reasons for revoking a some other person's key. There are many good reasons for revoking a
certification signature, such as the case where the keyholder leaves certification signature, such as the case where the keyholder leaves
the employ of a business with an email address. A revoked the employ of a business with an email address. A revoked
certification is no longer a part of validity calculations. certification is no longer a part of validity calculations.
skipping to change at page 39, line 8 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
except for the version number. An implementation MUST NOT generate
them and may 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 24 skipping to change at page 42, line 37
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 literal data packets or compressed data
packets, but in theory other Symmetrically Encrypted Data Packets or packets, 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 PGP'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
algorithm octet is prefixed to the session key before it is algorithm octet is prefixed to the session key before it is
encrypted. If no packets of these types precede the encrypted data, encrypted. If no packets of these types precede the encrypted data,
the IDEA algorithm is used with the session key calculated as the the IDEA algorithm is used with the session key calculated as the
MD5 hash of the passphrase, though this use is deprecated. MD5 hash of the passphrase, though this use is deprecated.
The data is encrypted in CFB mode, with a CFB shift size equal to The data is encrypted in CFB mode, with a CFB shift size equal to
skipping to change at page 42, line 53 skipping to change at page 43, line 14
octet 15 and octet 18 is a repeat of octet 16. As a pedantic octet 15 and octet 18 is a repeat of octet 16. As a pedantic
clarification, in both these examples, we consider the first octet clarification, in both these examples, we consider the first octet
to be numbered 1. to be numbered 1.
After encrypting the first block-size-plus-two octets, the CFB state After encrypting the first block-size-plus-two octets, the CFB state
is resynchronized. The last block-size octets of ciphertext are is resynchronized. The last block-size octets of ciphertext are
passed through the cipher and the block boundary is reset. passed through the cipher and the block boundary is reset.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. incorrect. See the Security Considerations section for hints on the
proper use of this "quick check."
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10)
An experimental version of PGP used this packet as the Literal An experimental version of PGP used this packet as the Literal
packet, but no released version of PGP generated Literal packets packet, but no released version of PGP generated Literal packets
with this tag. With PGP 5.x, this packet has been re-assigned and is with this tag. With PGP 5.x, this packet has been re-assigned and is
reserved for use as the Marker packet. reserved for use as the Marker packet.
The body of this packet consists of: The body of this packet consists of:
skipping to change at page 43, line 41 skipping to change at page 43, line 53
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. The line ends converted to local form, or other text-mode changes. The
tag 'u' (0x75) means the same as 't', but also indicates that tag 'u' (0x75) means the same as 't', but also indicates that
implementation believes that the literal data contains UTF-8 text. 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 a file
if the encrypted data should be saved as a file. name). This may be a zero-length string. Commonly, if the source
of the encrypted data is a file, this will be the name of the
encrypted file. An implementation MAY consider the file name in
the literal packet to be a more authoritative name than the
actual file name.
If the special name "_CONSOLE" is used, the message is considered to If the special name "_CONSOLE" is used, the message is considered to
be "for your eyes only". This advises that the message data is be "for your eyes only". This advises that the message data is
unusually sensitive, and the receiving program should process it unusually sensitive, and the receiving program should process it
more carefully, perhaps avoiding storing the received data to disk, more carefully, perhaps avoiding storing the received data to disk,
for example. for example.
- A four-octet number that indicates the modification date of the - A four-octet number that indicates a date associated with the
file, or the creation time of the packet, or a zero that literal data. Commonly, the date might be the modification date
indicates the present time. of a file, or the time the packet was created, or a zero that
indicates no specific time.
- The remainder of the packet is literal data. - The remainder of the packet is literal data.
Text data is stored with <CR><LF> text endings (i.e. network-normal Text data is stored with <CR><LF> text endings (i.e. network-normal
line endings). These should be converted to native line endings by line endings). These should be converted to native line endings by
the receiving software. the receiving software.
5.10. Trust Packet (Tag 12) 5.10. Trust Packet (Tag 12)
The Trust packet is used only within keyrings and is not normally The Trust packet is used only within keyrings and is not normally
skipping to change at page 52, line 20 skipping to change at page 52, line 30
4 E 21 V 38 m 55 3 4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4 5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5 6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6 7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7 8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8 9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9 10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 + 11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 / 12 M 29 d 46 u 63 /
13 N 30 e 47 v 13 N 30 e 47 v
14 O 31 f 48 w (pad) = 14 O 31 f 48 w (pad) 15 P 32 g 49 x
15 P 32 g 49 x
16 Q 33 h 50 y 16 Q 33 h 50 y
The encoded output stream must be represented in lines of no more The encoded output stream must be represented in lines of no more
than 76 characters each. than 76 characters each.
Special processing is performed if fewer than 24 bits are available Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. There are three possibilities: at the end of the data being encoded. There are three possibilities:
1. The last data group has 24 bits (3 octets). No special 1. The last data group has 24 bits (3 octets). No special
processing is needed. processing is needed.
skipping to change at page 53, line 25 skipping to change at page 53, line 35
111110 111110
Decimal: 5 15 46 28 0 61 37 62 Decimal: 5 15 46 28 0 61 37 62
Output: F P u c A 9 l + Output: F P u c A 9 l +
Input data: 0x14fb9c03d9 Input data: 0x14fb9c03d9
Hex: 1 4 f b 9 c | 0 3 d 9 Hex: 1 4 f b 9 c | 0 3 d 9
8-bit: 00010100 11111011 10011100 | 00000011 11011001 8-bit: 00010100 11111011 10011100 | 00000011 11011001
pad with 00 pad with 00
6-bit: 000101 001111 101110 011100 | 000000 111101 100100 6-bit: 000101 001111 101110 011100 | 000000 111101 100100
Decimal: 5 15 46 28 0 61 36 Decimal: 5 15 46 28 0 61 36
pad with = pad with Output: F P u c A 9 k
Output: F P u c A 9 k =
Input data: 0x14fb9c03 Input data: 0x14fb9c03
Hex: 1 4 f b 9 c | 0 3 Hex: 1 4 f b 9 c | 0 3
8-bit: 00010100 11111011 10011100 | 00000011 8-bit: 00010100 11111011 10011100 | 00000011
pad with 0000 pad with 0000
6-bit: 000101 001111 101110 011100 | 000000 110000 6-bit: 000101 001111 101110 011100 | 000000 110000
Decimal: 5 15 46 28 0 48 Decimal: 5 15 46 28 0 48
pad with = = pad with = Output: F P u c A w =
Output: F P u c A w = =
6.6. Example of an ASCII Armored Message 6.6. Example of an ASCII Armored Message
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
Version: OpenPrivacy 0.99 Version: OpenPrivacy 0.99
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA== vBSFjNSiVHsuAA= =njUN
=njUN
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
Note that this example is indented by two spaces. Note that this example is indented by two spaces.
7. Cleartext signature framework 7. Cleartext signature framework
It is desirable to sign a textual octet stream without ASCII It is desirable to sign a textual octet stream without ASCII
armoring the stream itself, so the signed text is still readable armoring the stream itself, so the signed text is still readable
without special software. In order to bind a signature to such a without special software. In order to bind a signature to such a
cleartext, this framework is used. (Note that RFC 3156 defines cleartext, this framework is used. (Note that RFC 3156 defines
another way to sign cleartext messages for environments that support another way to sign cleartext messages for environments that support
MIME.) MIME.)
skipping to change at page 56, line 4 skipping to change at page 56, line 17
algorithm number(s) are chosen from the private or experimental algorithm number(s) are chosen from the private or experimental
algorithm range. algorithm range.
See the section "Notes on Algorithms" below for more discussion of See the section "Notes on Algorithms" below for more discussion of
the algorithms. the algorithms.
9.1. Public Key Algorithms 9.1. Public Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
1 - RSA (Encrypt or Sign) 1 - RSA (Encrypt or Sign) [HAC]
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] [HAC]
17 - DSA (Digital Signature Algorithm) [SCHNEIER] 17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18 - Reserved for Elliptic Curve 18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA 19 - Reserved for ECDSA
20 - Reserved (formerly 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 - TripleDES (DES-EDE, [SCHNEIER] - 2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
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.
skipping to change at page 57, line 14 skipping to change at page 57, line 24
Implementations MUST implement uncompressed data. Implementations Implementations MUST implement uncompressed data. Implementations
SHOULD implement ZIP. Implementations MAY implement any other SHOULD implement ZIP. Implementations MAY implement any other
algorithm. algorithm.
9.4. Hash Algorithms 9.4. Hash Algorithms
ID Algorithm Text Name ID Algorithm Text Name
-- --------- ---- ---- -- --------- ---- ----
1 - MD5 "MD5" 1 - MD5 "MD5"
2 - SHA-1 "SHA1" 2 - SHA-1 [FIPS180] "SHA1"
3 - RIPE-MD/160 "RIPEMD160" 3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved 4 - Reserved
5 - Reserved 5 - Reserved
6 - Reserved 6 - Reserved
7 - Reserved 7 - Reserved
8 - SHA256 "SHA256" 8 - SHA256 [FIPS180] "SHA256"
9 - SHA384 "SHA384" 9 - SHA384 [FIPS180] "SHA384"
10 - SHA512 "SHA512" 10 - SHA512 [FIPS180] "SHA512"
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations MAY implement Implementations MUST implement SHA-1. Implementations MAY implement
other algorithms. other algorithms.
10. Packet Composition 10. Packet Composition
OpenPGP packets are assembled into sequences in order to create OpenPGP packets are assembled into sequences in order to create
messages and to transfer keys. Not all possible packet sequences messages and to transfer keys. Not all possible packet sequences
are meaningful and correct. This section describes the rules for are meaningful and correct. This section describes the rules for
skipping to change at page 67, line 52 skipping to change at page 68, line 8
system that reports errors in padding differently from errors in system that reports errors in padding differently from errors in
decryption becomes a random oracle that can leak the private key decryption becomes a random oracle that can leak the private key
in mere millions of queries. Implementations must be aware of in mere millions of queries. Implementations must be aware of
this attack and prevent it from happening. The simplest solution this attack and prevent it from happening. The simplest solution
is report a single error code for all variants of decryption is report a single error code for all variants of decryption
errors so as not to leak information to an attacker. 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.
* In winter 2005, Serge Mister and Robert Zuccherato from Entrust
released a paper describing a way that the "quick check" in
OpenPGP CFB mode can be used with a random oracle to decrypt two
octets of every cipher block [MZ05]. They recommend as
prevention not using the quick check at all.
Many implementers have taken this advice to heart for any data
that is both symmetrically encrypted, but also the session key
is public-key encrypted. In this case, the quick check is not
needed as the public key encryption of the session key should
guarantee that it is the right session key. In other cases, the
implementation should use the quick check with care. On the one
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
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 another.
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 68, line 22 skipping to change at page 68, line 49
for a V3 key with a V3 self-signature (or no self-signature). for a V3 key with a V3 self-signature (or no self-signature).
* When exporting a private key, PGP 2.x generates the header * When exporting a private key, PGP 2.x generates the header
"BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY
BLOCK". All previous versions ignore the implied data type, and BLOCK". All previous versions ignore the implied data type, and
look directly at the packet data type. look directly at the packet data type.
* PGP 2.0 through 2.5 generated V2 Public Key Packets. These are * PGP 2.0 through 2.5 generated V2 Public Key Packets. These are
identical to the deprecated V3 keys except for the version identical to the deprecated V3 keys except for the version
number. An implementation MUST NOT generate them and may accept number. An implementation MUST NOT generate them and may accept
or reject them as it sees fit. Similarly, these versions or reject them as it sees fit. Some older PGP versions generated
generated V2 PKESK packets (Tag 1). An implementation may accept V2 PKESK packets (Tag 1) as well. An implementation may accept
or reject V2 PKESK packets as it sees fit, and MUST NOT generate or reject V2 PKESK packets as it sees fit, and MUST NOT generate
them. them.
* PGP 2.6.x will not accept key-material packets with versions * PGP 2.6.x will not accept key-material packets with versions
greater than 3. greater than 3.
* There are many ways possible for two keys to have the same key * There are many ways possible for two keys to have the same key
material, but different fingerprints (and thus key IDs). Perhaps material, but different fingerprints (and thus key IDs). Perhaps
the most interesting is an RSA key that has been "upgraded" to the most interesting is an RSA key that has been "upgraded" to
V4 format, but since a V4 fingerprint is constructed by hashing V4 format, but since a V4 fingerprint is constructed by hashing
skipping to change at page 70, line 4 skipping to change at page 70, line 28
aesfact.html> aesfact.html>
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
r2algs.html#Rijndael> r2algs.html#Rijndael>
[BLOWFISH] Schneier, B. "Description of a New Variable-Length [BLOWFISH] Schneier, B. "Description of a New Variable-Length
Key, 64-Bit Block Cipher (Blowfish)" Fast Software Key, 64-Bit Block Cipher (Blowfish)" Fast Software
Encryption, Cambridge Security Workshop Proceedings Encryption, Cambridge Security Workshop Proceedings
(December 1993), Springer-Verlag, 1994, pp191-204 (December 1993), Springer-Verlag, 1994, pp191-204
<http://www.counterpane.com/bfsverlag.html> <http://www.counterpane.com/bfsverlag.html>
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2 [BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page" home page"
<http://sources.redhat.com/bzip2/> <http://sources.redhat.com/bzip2/>
[ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a [ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a
Signature Scheme Based on Discrete Logarithms," Signature Scheme Based on Discrete Logarithms,"
IEEE Transactions on Information Theory, v. IT-31, IEEE Transactions on Information Theory, v. IT-31,
n. 4, 1985, pp. 469-472. n. 4, 1985, pp. 469-472.
[FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB
180-2).
<http://csrc.nist.gov/publications/fips/
fips180-2/fips180-2.pdf>
[FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2).
<http://csrc.nist.gov/publications/fips/
fips186-2/fips186-2.pdf>
[HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.
<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.
[MENEZES] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.
[RFC822] Crocker, D., "Standard for the format of ARPA [RFC822] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August Internet text messages", STD 11, RFC 822, August
1982. 1982.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet [RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and Electronic Mail: Part III: Algorithms, Modes, and
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
skipping to change at page 71, line 26 skipping to change at page 72, line 11
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps> /isc/ElGamal.ps>
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
international version of PGP", ftp://ftp.iks- international version of PGP", ftp://ftp.iks-
jena.de/mitarb/lutz/crypt/software/pgp/ jena.de/mitarb/lutz/crypt/software/pgp/
[JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier [JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier
"Implementation of Chosen-Ciphertext Attacks "Implementation of Chosen-Ciphertext Attacks
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
CFB Mode Encryption As Used By OpenPGP," IACR
ePrint Archive: Report 2005/033, 8 Feb 2005
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 2004 by The Internet Society. All Rights Reserved. Copyright 2005 by The Internet Society. All Rights Reserved.
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
 End of changes. 

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