draft-ietf-openpgp-rfc2440bis-04.txt   draft-ietf-openpgp-rfc2440bis-05.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Wave Systems Corporation Category: INTERNET-DRAFT Wave Systems Corporation
draft-ietf-openpgp-rfc2440bis-04.txt draft-ietf-openpgp-rfc2440bis-05.txt
Expires Oct 2002 Lutz Donnerhacke Expires Oct 2002 Lutz Donnerhacke
April 2002 IN-Root-CA Individual Network e.V. April 2002 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-04.txt draft-ietf-openpgp-rfc2440bis-05.txt
Copyright 2002 by The Internet Society. All Rights Reserved. Copyright 2002 by The Internet Society. All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
Status of this Memo 1 Status of this Memo 1
IESG Note 1 IESG Note 1
Abstract 2 Abstract 2
Table of Contents 3 Table of Contents 3
1. Introduction 6 1. Introduction 6
1.1. Terms 6 1.1. Terms 6
2. General functions 6 2. General functions 6
2.1. Confidentiality via Encryption 6 2.1. Confidentiality via Encryption 7
2.2. Authentication via Digital signature 7 2.2. Authentication via Digital signature 7
2.3. Compression 8 2.3. Compression 8
2.4. Conversion to Radix-64 8 2.4. Conversion to Radix-64 8
2.5. Signature-Only Applications 8 2.5. Signature-Only Applications 8
3. Data Element Formats 8 3. Data Element Formats 9
3.1. Scalar numbers 8 3.1. Scalar numbers 9
3.2. Multi-Precision Integers 9 3.2. Multi-Precision Integers 9
3.3. Key IDs 9 3.3. Key IDs 9
3.4. Text 9 3.4. Text 10
3.5. Time fields 9 3.5. Time fields 10
3.6. Keyrings 10 3.6. Keyrings 10
3.7. String-to-key (S2K) specifiers 10 3.7. String-to-key (S2K) specifiers 10
3.7.1. String-to-key (S2k) specifier types 10 3.7.1. String-to-key (S2k) specifier types 10
3.7.1.1. Simple S2K 10 3.7.1.1. Simple S2K 10
3.7.1.2. Salted S2K 10 3.7.1.2. Salted S2K 11
3.7.1.3. Iterated and Salted S2K 11 3.7.1.3. Iterated and Salted S2K 11
3.7.2. String-to-key usage 11 3.7.2. String-to-key usage 12
3.7.2.1. Secret key encryption 12 3.7.2.1. Secret key encryption 12
3.7.2.2. Symmetric-key message encryption 12 3.7.2.2. Symmetric-key message encryption 12
4. Packet Syntax 12 4. Packet Syntax 13
4.1. Overview 12 4.1. Overview 13
4.2. Packet Headers 13 4.2. Packet Headers 13
4.2.1. Old-Format Packet Lengths 13 4.2.1. Old-Format Packet Lengths 14
4.2.2. New-Format Packet Lengths 14 4.2.2. New-Format Packet Lengths 14
4.2.2.1. One-Octet Lengths 14 4.2.2.1. One-Octet Lengths 14
4.2.2.2. Two-Octet Lengths 14 4.2.2.2. Two-Octet Lengths 15
4.2.2.3. Five-Octet Lengths 14 4.2.2.3. Five-Octet Lengths 15
4.2.2.4. Partial Body Lengths 15 4.2.2.4. Partial Body Lengths 15
4.2.3. Packet Length Examples 15 4.2.3. Packet Length Examples 15
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 16 5. Packet Types 16
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16
5.2. Signature Packet (Tag 2) 17 5.2. Signature Packet (Tag 2) 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 20
5.2.3. Version 4 Signature Packet Format 22 5.2.3. Version 4 Signature Packet Format 22
5.2.3.1. Signature Subpacket Specification 23 5.2.3.1. Signature Subpacket Specification 23
5.2.3.2. Signature Subpacket Types 24 5.2.3.2. Signature Subpacket Types 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 26
5.2.3.6. Key expiration time 26 5.2.3.6. Key expiration time 26
5.2.3.7. Preferred symmetric algorithms 26 5.2.3.7. Preferred symmetric algorithms 26
5.2.3.8. Preferred hash algorithms 26 5.2.3.8. Preferred hash algorithms 26
5.2.3.9. Preferred compression algorithms 26 5.2.3.9. Preferred compression algorithms 27
5.2.3.10.Signature expiration time 27 5.2.3.10.Signature expiration time 27
5.2.3.11.Exportable Certification 27 5.2.3.11.Exportable Certification 27
5.2.3.12.Revocable 27 5.2.3.12.Revocable 28
5.2.3.13.Trust signature 28 5.2.3.13.Trust signature 28
5.2.3.14.Regular expression 28 5.2.3.14.Regular expression 28
5.2.3.15.Revocation key 28 5.2.3.15.Revocation key 28
5.2.3.16.Notation Data 28 5.2.3.16.Notation Data 29
5.2.3.17.Key server preferences 29 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 30 5.2.3.19.Primary user id 30
5.2.3.20.Policy URL 30 5.2.3.20.Policy URL 30
5.2.3.21.Key Flags 30 5.2.3.21.Key Flags 31
5.2.3.22.Signer's User ID 31 5.2.3.22.Signer's User ID 31
5.2.3.23.Reason for Revocation 31 5.2.3.23.Reason for Revocation 32
5.2.3.24.Features 32 5.2.3.24.Features 32
5.2.3.25.Revocation Target 33
5.2.4. Computing Signatures 33 5.2.4. Computing Signatures 33
5.2.4.1. Subpacket Hints 34 5.2.4.1. Subpacket Hints 34
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 34 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 35
5.4. One-Pass Signature Packets (Tag 4) 35 5.4. One-Pass Signature Packets (Tag 4) 35
5.5. Key Material Packet 36 5.5. Key Material Packet 36
5.5.1. Key Packet Variants 36 5.5.1. Key Packet Variants 36
5.5.1.1. Public Key Packet (Tag 6) 36 5.5.1.1. Public Key Packet (Tag 6) 36
5.5.1.2. Public Subkey Packet (Tag 14) 36 5.5.1.2. Public Subkey Packet (Tag 14) 36
5.5.1.3. Secret Key Packet (Tag 5) 36 5.5.1.3. Secret Key Packet (Tag 5) 37
5.5.1.4. Secret Subkey Packet (Tag 7) 36 5.5.1.4. Secret Subkey Packet (Tag 7) 37
5.5.2. Public Key Packet Formats 37 5.5.2. Public Key Packet Formats 37
5.5.3. Secret Key Packet Formats 38 5.5.3. Secret Key Packet Formats 39
5.6. Compressed Data Packet (Tag 8) 40 5.6. Compressed Data Packet (Tag 8) 40
5.7. Symmetrically Encrypted Data Packet (Tag 9) 40 5.7. Symmetrically Encrypted Data Packet (Tag 9) 41
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 41 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 42
5.9. Literal Data Packet (Tag 11) 42 5.9. Literal Data Packet (Tag 11) 42
5.10. Trust Packet (Tag 12) 42 5.10. Trust Packet (Tag 12) 43
5.11. User ID Packet (Tag 13) 42 5.11. User ID Packet (Tag 13) 43
5.12. User Attribute Packet (Tag 17) 43 5.12. User Attribute Packet (Tag 17) 43
5.12.1. The Image Attribute Subpacket 43 5.12.1. The Image Attribute Subpacket 44
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 44 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 44
5.14. Modification Detection Code Packet (Tag 19) 45 5.14. Modification Detection Code Packet (Tag 19) 46
6. Radix-64 Conversions 46 6. Radix-64 Conversions 47
6.1. An Implementation of the CRC-24 in "C" 47 6.1. An Implementation of the CRC-24 in "C" 47
6.2. Forming ASCII Armor 47 6.2. Forming ASCII Armor 48
6.3. Encoding Binary in Radix-64 49 6.3. Encoding Binary in Radix-64 50
6.4. Decoding Radix-64 51 6.4. Decoding Radix-64 51
6.5. Examples of Radix-64 51 6.5. Examples of Radix-64 51
6.6. Example of an ASCII Armored Message 51 6.6. Example of an ASCII Armored Message 52
7. Cleartext signature framework 52 7. Cleartext signature framework 52
7.1. Dash-Escaped Text 52 7.1. Dash-Escaped Text 53
8. Regular Expressions 53 8. Regular Expressions 53
9. Constants 53 9. Constants 54
9.1. Public Key Algorithms 54 9.1. Public Key Algorithms 54
9.2. Symmetric Key Algorithms 54 9.2. Symmetric Key Algorithms 55
9.3. Compression Algorithms 54 9.3. Compression Algorithms 55
9.4. Hash Algorithms 55 9.4. Hash Algorithms 55
10. Packet Composition 55 10. Packet Composition 56
10.1. Transferable Public Keys 55 10.1. Transferable Public Keys 56
10.2. OpenPGP Messages 57 10.2. OpenPGP Messages 57
10.3. Detached Signatures 57 10.3. Detached Signatures 58
11. Enhanced Key Formats 57 11. Enhanced Key Formats 58
11.1. Key Structures 57 11.1. Key Structures 58
11.2. Key IDs and Fingerprints 58 11.2. Key IDs and Fingerprints 59
12. Notes on Algorithms 59 12. Notes on Algorithms 60
12.1. Symmetric Algorithm Preferences 59 12.1. Symmetric Algorithm Preferences 60
12.2. Other Algorithm Preferences 60 12.2. Other Algorithm Preferences 61
12.2.1. Compression Preferences 60 12.2.1. Compression Preferences 61
12.2.2. Hash Algorithm Preferences 61 12.2.2. Hash Algorithm Preferences 61
12.3. Plaintext 61 12.3. Plaintext 62
12.4. RSA 61 12.4. RSA 62
12.5. Elgamal 62 12.5. Elgamal 62
12.6. DSA 62 12.6. DSA 63
12.7. Reserved Algorithm Numbers 63 12.7. Reserved Algorithm Numbers 63
12.8. OpenPGP CFB mode 63 12.8. OpenPGP CFB mode 63
13. Security Considerations 64 13. Security Considerations 65
14. Implementation Nits 66 14. Implementation Nits 66
15. Authors and Working Group Chair 67 15. Authors and Working Group Chair 67
16. References 68 16. References 68
17. Full Copyright Statement 70 17. Full Copyright Statement 70
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC2440, "OpenPGP and key management functions. It is a revision of RFC2440, "OpenPGP
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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,
RFC1991. It has new formats and corrects a number of problems in RFC1991. 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
implementation that avoids all encumbered algorithms.
Consequently, early versions of GPG did not include RSA public
keys. GPG may or may not have (depending on version) support for
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
Network Associates, Inc. and are used with permission. Network Associates, Inc. and are used with permission.
This document uses the terms "MUST", "SHOULD", and "MAY" as defined This document uses the terms "MUST", "SHOULD", and "MAY" as defined
in RFC2119, along with the negated forms of those terms. in RFC2119, along with the negated forms of those terms.
2. General functions 2. General functions
OpenPGP provides data integrity services for messages and data files OpenPGP provides data integrity services for messages and data files
by using these core technologies: by using these core technologies:
skipping to change at page 9, line 37 skipping to change at page 9, line 45
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].
Also note that when an MPI is encrypted, the length refers to the
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
The default character set for text is the UTF-8 [RFC2279] encoding Unless otherwise specified, the character set for text is the UTF-8
of Unicode [ISO10646]. [RFC2279] encoding of Unicode [ISO10646].
3.5. Time fields 3.5. Time fields
A time field is an unsigned four-octet number containing the number A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC. of seconds elapsed since midnight, 1 January 1970 UTC.
3.6. Keyrings 3.6. Keyrings
A keyring is a collection of one or more keys in a file or database. A keyring is a collection of one or more keys in a file or database.
Traditionally, a keyring is simply a sequential list of keys, but Traditionally, a keyring is simply a sequential list of keys, but
skipping to change at page 23, line 36 skipping to change at page 23, line 47
Each set of subpackets is preceded by a two-octet scalar count of Each set of subpackets is preceded by a two-octet scalar count of
the length of the set of subpackets. the length of the set of subpackets.
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. Note that this is
the same encoding used for signature subpackets
The length includes the type octet but not this length. Its format The length includes the type octet but not this length. Its format
is similar to the "new" format packet header lengths, but cannot is similar to the "new" format packet header lengths, but cannot
have partial body lengths. That is: have partial body lengths. That is:
if the 1st octet < 192, then if the 1st octet < 192, then
lengthOfLength = 1 lengthOfLength = 1
subpacketLen = 1st_octet subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then if the 1st octet >= 192 and < 255, then
lengthOfLength = 2 lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then if the 1st octet = 255, then
lengthOfLength = 5 lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet] subpacket length = [four-octet scalar starting at 2nd_octet]
The value of the subpacket type octet may be: The value of the subpacket type octet may be:
skipping to change at page 24, line 27 skipping to change at page 24, line 36
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 URL
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 = revocation identification
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 21 skipping to change at page 27, line 35
The validity period of the signature. This is the number of seconds The validity period of the signature. This is the number of seconds
after the signature creation time that the signature expires. If after the signature creation time that the signature expires. If
this is not present or has a value of zero, it never expires. this is not present or has a value of zero, it never expires.
5.2.3.11. Exportable Certification 5.2.3.11. Exportable Certification
(1 octet of exportability, 0 for not, 1 for exportable) (1 octet of exportability, 0 for not, 1 for exportable)
This subpacket denotes whether a certification signature is This subpacket denotes whether a certification signature is
"exportable," to be used by other users than the signature's issuer. "exportable," to be used by other users than the signature's issuer.
The packet body contains a boolean flag indicating whether the The packet body contains a Boolean flag indicating whether the
signature is exportable. If this packet is not present, the signature is exportable. If this packet is not present, the
certification is exportable; it is equivalent to a flag containing a certification is exportable; it is equivalent to a flag containing a
1. 1.
Non-exportable, or "local," certifications are signatures made by a Non-exportable, or "local," certifications are signatures made by a
user to mark a key as valid within that user's implementation only. user to mark a key as valid within that user's implementation only.
Thus, when an implementation prepares a user's copy of a key for Thus, when an implementation prepares a user's copy of a key for
transport to another user (this is the process of "exporting" the transport to another user (this is the process of "exporting" the
key), any local certification signatures are deleted from the key. key), any local certification signatures are deleted from the key.
skipping to change at page 27, line 47 skipping to change at page 28, line 9
addition to an exported key, then this situation can arise. addition to an exported key, then this situation can arise.
Some implementations do not represent the interest of a single user Some implementations do not represent the interest of a single user
(for example, a key server). Such implementations always trim local (for example, a key server). Such implementations always trim local
certifications from any key they handle. certifications from any key they handle.
5.2.3.12. Revocable 5.2.3.12. Revocable
(1 octet of revocability, 0 for not, 1 for revocable) (1 octet of revocability, 0 for not, 1 for revocable)
Signature's revocability status. Packet body contains a boolean Signature's revocability status. Packet body contains a Boolean
flag indicating whether the signature is revocable. Signatures that flag indicating whether the signature is revocable. Signatures that
are not revocable have any later revocation signatures ignored. are not revocable have any later revocation signatures ignored.
They represent a commitment by the signer that he cannot revoke his They represent a commitment by the signer that he cannot revoke his
signature for the life of his key. If this packet is not present, signature for the life of his key. If this packet is not present,
the signature is revocable. the signature is revocable.
5.2.3.13. Trust signature 5.2.3.13. Trust signature
(1 octet "level" (depth), 1 octet of trust amount) (1 octet "level" (depth), 1 octet of trust amount)
skipping to change at page 29, line 18 skipping to change at page 29, line 32
This subpacket describes a "notation" on the signature that the This subpacket describes a "notation" on the signature that the
issuer wishes to make. The notation has a name and a value, each of issuer wishes to make. The notation has a name and a value, each of
which are strings of octets. There may be more than one notation in which are strings of octets. There may be more than one notation in
a signature. Notations can be used for any extension the issuer of a signature. Notations can be used for any extension the issuer of
the signature cares to make. The "flags" field holds four octets of the signature cares to make. The "flags" field holds four octets of
flags. flags.
All undefined flags MUST be zero. Defined flags are: All undefined flags MUST be zero. Defined flags are:
First octet: 0x80 = human-readable. This note value is text, a First octet: 0x80 = human-readable. This note value is text, a
note note from one person to another, and need
from one person to another, and has no not have meaning to software.
meaning to software.
Other octets: none. Other octets: none.
Notation names are arbitrary strings encoded in UTF-8. They reside Notation names are arbitrary strings encoded in UTF-8. They reside
two name spaces: The IETF name space and the user name space. two name spaces: The IETF name space and the user name space.
The IETF name space is registered with IANA. These names MUST NOT The IETF name space is registered with IANA. These names MUST NOT
contain the "@" character (0x40) is this is a tag for the user name contain the "@" character (0x40) is this is a tag for the user name
space. space.
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,
implementors 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.
5.2.3.17. Key server preferences 5.2.3.17. Key server preferences
(N octets of flags) (N octets of flags)
This is a list of flags that indicate preferences that the key This is a list of flags that indicate preferences that the key
holder has about how the key is handled on a key server. All holder has about how the key is handled on a key server. All
skipping to change at page 30, line 19 skipping to change at page 30, line 31
(String) (String)
This is a URL 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 URL, 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
is zero. If more than one user id in a key is marked as primary, the is zero. If more than one user id in a key is marked as primary, the
implementation may resolve the ambiguity in any way it sees fit, but implementation may resolve the ambiguity in any way it sees fit, but
it is RECOMMENDED that priority be given to the user ID with the it is RECOMMENDED that priority be given to the user ID with the
most recent self-signature. most recent self-signature.
skipping to change at page 33, line 14 skipping to change at page 33, line 24
Defined features are: Defined features are:
First octet: First octet:
0x01 - Modification Detection (packets 18 and 19) 0x01 - Modification Detection (packets 18 and 19)
If an implementation implements any of the defined features, it If an implementation implements any of the defined features, it
SHOULD implement the features subpacket, too. SHOULD implement the features subpacket, too.
5.2.3.25. Revocation Target
(1 octet PK algorithm, 1 octet hash algorithm, N octets hash)
This subpacket identifies a specific target signature that a
revocation signature revokes. This provides explicit designation of
a revocation. All arguments are an identifier of that signature.
The N octets of hash data MUST be the size of the hash of the
signature. For example, a target signature with a SHA-1 hash MUST
have 20 octets of hash data.
5.2.4. Computing Signatures 5.2.4. Computing Signatures
All signatures are formed by producing a hash over the signature All signatures are formed by producing a hash over the signature
data, and then using the resulting hash in the signature algorithm. data, and then using the resulting hash in the signature algorithm.
The signature data is simple to compute for document signatures The signature data is simple to compute for document signatures
(types 0x00 and 0x01), for which the document itself is the data. (types 0x00 and 0x01), for which the document itself is the data.
For standalone signatures, this is a null string. For standalone signatures, this is a null string.
When a signature is made over a key, the hash data starts with the When a signature is made over a key, the hash data starts with the
skipping to change at page 42, line 16 skipping to change at page 42, line 40
A Literal Data packet contains the body of a message; data that is A Literal Data packet contains the body of a message; data that is
not to be further interpreted. not to be further interpreted.
The body of this packet consists of: The body of this packet consists of:
- A one-octet field that describes how the data is formatted. - A one-octet field that describes how the data is formatted.
If it is a 'b' (0x62), then the literal packet contains binary data. If it is a 'b' (0x62), then the literal packet contains binary data.
If it is a 't' (0x74), then it contains text data, and thus may need If it is a 't' (0x74), then it contains text data, and thus may need
line ends converted to local form, or other text-mode changes. RFC line ends converted to local form, or other text-mode changes.
1991 also defined a value of 'l' as a 'local' mode for machine-local
conversions. This use is now deprecated. Early versions of PGP also defined a value of 'l' as a 'local' mode
for machine-local conversions. RFC 1991 incorrectly stated this
local mode flag as '1' (ASCII numeral one). Both of these local
modes are deprecated.
- File name as a string (one-octet length, followed by file name), - File name as a string (one-octet length, followed by file name),
if the encrypted data should be saved as a file. if the encrypted data should be saved as a file.
If the special name "_CONSOLE" is used, the message is considered to If the special name "_CONSOLE" is used, the message is considered to
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.
skipping to change at page 49, line 10 skipping to change at page 49, line 33
(':' 0x38) and a single space (0x20) separate the key and value. (':' 0x38) and a single space (0x20) separate the key and value.
OpenPGP should consider improperly formatted Armor Headers to be OpenPGP should consider improperly formatted Armor Headers to be
corruption of the ASCII Armor. Unknown keys should be reported to corruption of the ASCII Armor. Unknown keys should be reported to
the user, but OpenPGP should continue to process the message. the user, but OpenPGP should continue to process the message.
Currently defined Armor Header Keys are: Currently defined Armor Header Keys are:
- "Version", that states the OpenPGP Version used to encode the - "Version", that states the OpenPGP Version used to encode the
message. message.
- "Comment", a user-defined comment. - "Comment", a user-defined comment. OpenPGP defines all text to
be in UTF-8. A comment may be any UTF-8 string. However, the
whole point of armoring is to provide seven-bit-clean data.
Consquently, if a comment has character that are outside the
US-ASCII range of UTF, they may very well not survive transport.
- "MessageID", a 32-character string of printable characters. The - "MessageID", a 32-character string of printable characters. The
string must be the same for all parts of a multi-part message string must be the same for all parts of a multi-part message
that uses the "PART X" Armor Header. MessageID strings should that uses the "PART X" Armor Header. MessageID strings should
be unique enough that the recipient of the mail can associate be unique enough that the recipient of the mail can associate
all the parts of a message with each other. A good checksum or all the parts of a message with each other. A good checksum or
cryptographic hash function is sufficient. cryptographic hash function is sufficient.
The MessageID SHOULD NOT appear unless it is in a multi-part The MessageID SHOULD NOT appear unless it is in a multi-part
message. If it appears at all, it MUST be computed from the message. If it appears at all, it MUST be computed from the
finished (encrypted, signed, etc.) message in a deterministic finished (encrypted, signed, etc.) message in a deterministic
fashion, rather than contain a purely random value. This is to fashion, rather than contain a purely random value. This is to
allow the legitimate recipient to determine that the MessageID allow the legitimate recipient to determine that the MessageID
cannot serve as a covert means of leaking cryptographic key cannot serve as a covert means of leaking cryptographic key
information. information.
- "Hash", a comma-separated list of hash algorithms used in this - "Hash", a comma-separated list of hash algorithms used in this
message. This is used only in clear-signed messages. message. This is used only in clear-signed messages.
- "Charset", a description of the character set that the plaintext - "Charset", a description of the character set that the plaintext
is in. Please note that OpenPGP defines text to be in UTF-8 by is in. Please note that OpenPGP defines text to be in UTF-8. An
default. An implementation will get best results by translating implementation will get best results by translating into and out
into and out of UTF-8. However, there are many instances where of UTF-8. However, there are many instances where this is easier
this is easier said than done. Also, there are communities of said than done. Also, there are communities of users who have no
users who have no need for UTF-8 because they are all happy with need for UTF-8 because they are all happy with a character set
a character set like ISO Latin-5 or a Japanese character set. In like ISO Latin-5 or a Japanese character set. In such instances,
such instances, an implementation MAY override the UTF-8 default an implementation MAY override the UTF-8 default by using this
by using this header key. An implementation MAY implement this header key. An implementation MAY implement this key and any
key and any translations it cares to; an implementation MAY translations it cares to; an implementation MAY ignore it and
ignore it and assume all text is UTF-8. assume all text is UTF-8.
The Armor Tail Line is composed in the same manner as the Armor The Armor Tail Line is composed in the same manner as the Armor
Header Line, except the string "BEGIN" is replaced by the string Header Line, except the string "BEGIN" is replaced by the string
"END." "END."
6.3. Encoding Binary in Radix-64 6.3. Encoding Binary in Radix-64
The encoding process represents 24-bit groups of input bits as The encoding process represents 24-bit groups of input bits as
output strings of 4 encoded characters. Proceeding from left to output strings of 4 encoded characters. Proceeding from left to
right, a 24-bit input group is formed by concatenating three 8-bit right, a 24-bit input group is formed by concatenating three 8-bit
skipping to change at page 56, line 41 skipping to change at page 57, line 15
the initial Public Key packet. the initial Public Key packet.
User Attribute packets and User ID packets may be freely intermixed User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet. maintained on the proper User Attribute or User ID packet.
After the User ID packets there may be one or more Subkey packets. After the User ID packets there may be one or more Subkey packets.
In general, subkeys are provided in cases where the top-level public In general, subkeys are provided in cases where the top-level public
key is a signature-only key. However, any V4 key may have subkeys, key is a signature-only key. However, any V4 key may have subkeys,
and the subkeys may be encryption-only keys, signature-only keys, or and the subkeys may be encryption-only keys, signature-only keys, or
general-purpose keys. V3 keys MAY NOT have subkeys. general-purpose keys. V3 keys MUST NOT have subkeys.
Each Subkey packet must be followed by one Signature packet, which Each Subkey packet must be followed by one Signature packet, which
should be a subkey binding signature issued by the top level key. should be a subkey binding signature issued by the top level key.
Subkey and Key packets may each be followed by a revocation Subkey and Key packets may each be followed by a revocation
Signature packet to indicate that the key is revoked. Revocation Signature packet to indicate that the key is revoked. Revocation
signatures are only accepted if they are issued by the key itself, signatures are only accepted if they are issued by the key itself,
or by a key that is authorized to issue revocations via a revocation or by a key that is authorized to issue revocations via a revocation
key subpacket in a self-signature by the top level key. key subpacket in a self-signature by the top level key.
skipping to change at page 61, line 4 skipping to change at page 61, line 30
Other algorithm preferences work similarly to the symmetric Other algorithm preferences work similarly to the symmetric
algorithm preference, in that they specify which algorithms the algorithm preference, in that they specify which algorithms the
keyholder accepts. There are two interesting cases that other keyholder accepts. There are two interesting cases that other
comments need to be made about, though, the compression preferences comments need to be made about, though, the compression preferences
and the hash preferences. and the hash preferences.
12.2.1. Compression Preferences 12.2.1. Compression Preferences
Compression has been an integral part of PGP since its first days. Compression has been an integral part of PGP since its first days.
OpenPGP and all previous versions of PGP have offered compression. OpenPGP and all previous versions of PGP have offered compression.
In this specification, the default is for messages to be compressed,
And in this specification, the default is for messages to be although an implementation is not required to do so. Consequently,
compressed, although an implementation is not required to do so. the compression preference gives a way for a keyholder to request
Consequently, the compression preference gives a way for a keyholder that messages not be compressed, presumably because they are using a
to request that messages not be compressed, presumably because they minimal implementation that does not include compression.
are using a minimal implementation that does not include Additionally, this gives a keyholder a way to state that it can
compression. Additionally, this gives a keyholder a way to state support alternate algorithms.
that it can support alternate algorithms.
Like the algorithm preferences, an implementation MUST NOT use an Like the algorithm preferences, an implementation MUST NOT use an
algorithm that is not in the preference vector. If the preferences algorithm that is not in the preference vector. If the preferences
are not present, then they are assumed to be [ZIP(1), are not present, then they are assumed to be [ZIP(1),
UNCOMPRESSED(0)]. UNCOMPRESSED(0)].
Additionally, an implementation MUST implement this preference to Additionally, an implementation MUST implement this preference to
the degree of recognizing when to send an uncompressed message. A the degree of recognizing when to send an uncompressed message. A
robust implementation would satisfy this requirement by looking at robust implementation would satisfy this requirement by looking at
the recipient's preference and acting accordingly. A minimal the recipient's preference and acting accordingly. A minimal
skipping to change at page 68, line 4 skipping to change at page 68, line 25
Hal Finney Hal Finney
Network Associates, Inc. Network Associates, Inc.
3965 Freedom Circle 3965 Freedom Circle
Santa Clara, CA 95054, USA Santa Clara, CA 95054, USA
Email: hal@pgp.com Email: hal@pgp.com
Rodney Thayer Rodney Thayer
Email: rodney@tillerman.to Email: rodney@tillerman.to
This memo also draws on much previous work from a number of other This memo also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto, authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark
Philip R. Zimmermann. Weaver, and Philip R. Zimmermann.
16. References 16. References
[AES] Advanced Encryption Standards Questions and Answers [AES] Advanced Encryption Standards Questions and Answers
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
aesfact.html> aesfact.html>
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
r2algs.html#Rijndael> r2algs.html#Rijndael>
 End of changes. 

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