draft-ietf-openpgp-rfc2440bis-18.txt   draft-ietf-openpgp-rfc2440bis-19.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT PGP Corporation Internet-Draft PGP Corporation
draft-ietf-openpgp-rfc2440bis-18.txt Intended status: Standards Track
Expires November 2006 Lutz Donnerhacke Expires September 2007 Lutz Donnerhacke
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
PGP Corporation PGP Corporation
David Shaw David Shaw
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-18.txt draft-ietf-openpgp-rfc2440bis-19
Copyright (C) The Internet Society (2006).
IPR Claim Notice Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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/1id-abstracts.html
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
IANA Considerations Copyright Notice
This document defines many tag values, yet it doesn't describe a Copyright (C) The IETF Trust (2007).
mechanism for adding new tags (for new features). Traditionally the
Internet Assigned Numbers Authority (IANA) handles the allocation of
new values for future expansion and RFCs usually define the
procedure to be used by the IANA. However there are subtle (and not
so subtle) interactions that may occur in this protocol between new
features and existing features which result in a significant
reduction in over all security. Therefore this document does not
define an extension procedure. Instead requests to define new tag
values (say for new encryption algorithms for example) should be
forwarded to the IESG Security Area Directors for consideration or
forwarding to the appropriate IETF Working Group for consideration.
Abstract Abstract
This document is maintained in order to publish all necessary This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions. network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid It does, however, discuss implementation issues necessary to avoid
skipping to change at page 3, line 7 skipping to change at page 3, line 7
OpenPGP software uses a combination of strong public-key and OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic symmetric cryptography to provide security services for electronic
communications and data storage. These services include communications and data storage. These services include
confidentiality, key management, authentication, and digital confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in signatures. This document specifies the message formats used in
OpenPGP. OpenPGP.
Table of Contents Table of Contents
IPR Claim Notice 1
Status of this Memo 1 Status of this Memo 1
IANA Considerations 2 Copyright Notice 1
Abstract 2 Abstract 1
Table of Contents 3 Table of Contents 3
1. Introduction 6 1. Introduction 7
1.1. Terms 6 1.1. Terms 7
2. General functions 6 2. General functions 7
2.1. Confidentiality via Encryption 7 2.1. Confidentiality via Encryption 8
2.2. Authentication via Digital signature 7 2.2. Authentication via Digital signature 9
2.3. Compression 8 2.3. Compression 9
2.4. Conversion to Radix-64 8 2.4. Conversion to Radix-64 9
2.5. Signature-Only Applications 8 2.5. Signature-Only Applications 10
3. Data Element Formats 9 3. Data Element Formats 10
3.1. Scalar numbers 9 3.1. Scalar numbers 10
3.2. Multiprecision Integers 9 3.2. Multiprecision Integers 10
3.3. Key IDs 9 3.3. Key IDs 11
3.4. Text 10 3.4. Text 11
3.5. Time fields 10 3.5. Time fields 11
3.6. Keyrings 10 3.6. Keyrings 11
3.7. String-to-key (S2K) specifiers 10 3.7. String-to-key (S2K) specifiers 11
3.7.1. String-to-key (S2K) specifier types 10 3.7.1. String-to-key (S2K) specifier types 11
3.7.1.1. Simple S2K 10 3.7.1.1. Simple S2K 12
3.7.1.2. Salted S2K 11 3.7.1.2. Salted S2K 12
3.7.1.3. Iterated and Salted S2K 11 3.7.1.3. Iterated and Salted S2K 12
3.7.2. String-to-key usage 12 3.7.2. String-to-key usage 13
3.7.2.1. Secret key encryption 12 3.7.2.1. Secret key encryption 13
3.7.2.2. Symmetric-key message encryption 13 3.7.2.2. Symmetric-key message encryption 14
4. Packet Syntax 13 4. Packet Syntax 14
4.1. Overview 13 4.1. Overview 14
4.2. Packet Headers 13 4.2. Packet Headers 14
4.2.1. Old-Format Packet Lengths 14 4.2.1. Old-Format Packet Lengths 15
4.2.2. New-Format Packet Lengths 14 4.2.2. New-Format Packet Lengths 15
4.2.2.1. One-Octet Lengths 15 4.2.2.1. One-Octet Lengths 16
4.2.2.2. Two-Octet Lengths 15 4.2.2.2. Two-Octet Lengths 16
4.2.2.3. Five-Octet Lengths 15 4.2.2.3. Five-Octet Lengths 16
4.2.2.4. Partial Body Lengths 15 4.2.2.4. Partial Body Lengths 16
4.2.3. Packet Length Examples 16 4.2.3. Packet Length Examples 17
4.3. Packet Tags 16 4.3. Packet Tags 17
5. Packet Types 17 5. Packet Types 18
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 18
5.2. Signature Packet (Tag 2) 18 5.2. Signature Packet (Tag 2) 19
5.2.1. Signature Types 18 5.2.1. Signature Types 19
5.2.2. Version 3 Signature Packet Format 21 5.2.2. Version 3 Signature Packet Format 22
5.2.3. Version 4 Signature Packet Format 23 5.2.3. Version 4 Signature Packet Format 24
5.2.3.1. Signature Subpacket Specification 24 5.2.3.1. Signature Subpacket Specification 25
5.2.3.2. Signature Subpacket Types 25 5.2.3.2. Signature Subpacket Types 26
5.2.3.3. Notes on Self-Signatures 26 5.2.3.3. Notes on Self-Signatures 27
5.2.3.4. Signature creation time 27 5.2.3.4. Signature creation time 28
5.2.3.5. Issuer 27 5.2.3.5. Issuer 28
5.2.3.6. Key expiration time 27 5.2.3.6. Key expiration time 28
5.2.3.7. Preferred symmetric algorithms 27 5.2.3.7. Preferred symmetric algorithms 28
5.2.3.8. Preferred hash algorithms 27 5.2.3.8. Preferred hash algorithms 28
5.2.3.9. Preferred compression algorithms 27 5.2.3.9. Preferred compression algorithms 28
5.2.3.10.Signature expiration time 28 5.2.3.10.Signature expiration time 29
5.2.3.11.Exportable Certification 28 5.2.3.11.Exportable Certification 29
5.2.3.12.Revocable 28 5.2.3.12.Revocable 29
5.2.3.13.Trust signature 29 5.2.3.13.Trust signature 30
5.2.3.14.Regular expression 29 5.2.3.14.Regular expression 30
5.2.3.15.Revocation key 29 5.2.3.15.Revocation key 30
5.2.3.16.Notation Data 30 5.2.3.16.Notation Data 31
5.2.3.17.Key server preferences 30 5.2.3.17.Key server preferences 31
5.2.3.18.Preferred key server 31 5.2.3.18.Preferred key server 32
5.2.3.19.Primary User ID 31 5.2.3.19.Primary User ID 32
5.2.3.20.Policy URI 31 5.2.3.20.Policy URI 32
5.2.3.21.Key Flags 31 5.2.3.21.Key Flags 32
5.2.3.22.Signer's User ID 32 5.2.3.22.Signer's User ID 33
5.2.3.23.Reason for Revocation 33 5.2.3.23.Reason for Revocation 34
5.2.3.24.Features 33 5.2.3.24.Features 34
5.2.3.25.Signature Target 34 5.2.3.25.Signature Target 35
5.2.3.26.Embedded Signature 34 5.2.3.26.Embedded Signature 35
5.2.4. Computing Signatures 34 5.2.4. Computing Signatures 35
5.2.4.1. Subpacket Hints 35 5.2.4.1. Subpacket Hints 36
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 36 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 37
5.4. One-Pass Signature Packets (Tag 4) 37 5.4. One-Pass Signature Packets (Tag 4) 38
5.5. Key Material Packet 37 5.5. Key Material Packet 38
5.5.1. Key Packet Variants 38 5.5.1. Key Packet Variants 39
5.5.1.1. Public Key Packet (Tag 6) 38 5.5.1.1. Public Key Packet (Tag 6) 39
5.5.1.2. Public Subkey Packet (Tag 14) 38 5.5.1.2. Public Subkey Packet (Tag 14) 39
5.5.1.3. Secret Key Packet (Tag 5) 38 5.5.1.3. Secret Key Packet (Tag 5) 39
5.5.1.4. Secret Subkey Packet (Tag 7) 38 5.5.1.4. Secret Subkey Packet (Tag 7) 39
5.5.2. Public Key Packet Formats 38 5.5.2. Public Key Packet Formats 39
5.5.3. Secret Key Packet Formats 40 5.5.3. Secret Key Packet Formats 41
5.6. Compressed Data Packet (Tag 8) 42 5.6. Compressed Data Packet (Tag 8) 43
5.7. Symmetrically Encrypted Data Packet (Tag 9) 42 5.7. Symmetrically Encrypted Data Packet (Tag 9) 43
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 43 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 44
5.9. Literal Data Packet (Tag 11) 43 5.9. Literal Data Packet (Tag 11) 44
5.10. Trust Packet (Tag 12) 44 5.10. Trust Packet (Tag 12) 45
5.11. User ID Packet (Tag 13) 44 5.11. User ID Packet (Tag 13) 45
5.12. User Attribute Packet (Tag 17) 45 5.12. User Attribute Packet (Tag 17) 46
5.12.1. The Image Attribute Subpacket 45 5.12.1. The Image Attribute Subpacket 46
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 46 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 47
5.14. Modification Detection Code Packet (Tag 19) 48 5.14. Modification Detection Code Packet (Tag 19) 50
6. Radix-64 Conversions 48 6. Radix-64 Conversions 50
6.1. An Implementation of the CRC-24 in "C" 49 6.1. An Implementation of the CRC-24 in "C" 51
6.2. Forming ASCII Armor 49 6.2. Forming ASCII Armor 51
6.3. Encoding Binary in Radix-64 52 6.3. Encoding Binary in Radix-64 54
6.4. Decoding Radix-64 53 6.4. Decoding Radix-64 55
6.5. Examples of Radix-64 53 6.5. Examples of Radix-64 55
6.6. Example of an ASCII Armored Message 54 6.6. Example of an ASCII Armored Message 56
7. Cleartext signature framework 54 7. Cleartext signature framework 56
7.1. Dash-Escaped Text 55 7.1. Dash-Escaped Text 57
8. Regular Expressions 55 8. Regular Expressions 57
9. Constants 56 9. Constants 58
9.1. Public Key Algorithms 56 9.1. Public Key Algorithms 58
9.2. Symmetric Key Algorithms 56 9.2. Symmetric Key Algorithms 59
9.3. Compression Algorithms 57 9.3. Compression Algorithms 59
9.4. Hash Algorithms 57 9.4. Hash Algorithms 59
10. Packet Composition 58 10. IANA Considerations 60
10.1. Transferable Public Keys 58 10.1. New String-to-Key specifier types 60
10.2. Transferable Secret Keys 59 10.2. New Packets 60
10.3. OpenPGP Messages 59 10.2.1. User Attribute Types 60
10.4. Detached Signatures 60 10.2.1.1.Image Format Subpacket Types 60
11. Enhanced Key Formats 60 10.2.2. New Signature Subpackets 61
11.1. Key Structures 60 10.2.2.1.Signature Notation Data Subpackets 61
11.2. Key IDs and Fingerprints 61 10.2.2.2.Key Server Preference Extensions 61
12. Notes on Algorithms 62 10.2.2.3.Key Flags Extensions 61
12.1. PKCS#1 Encoding In OpenPGP 62 10.2.2.4.Reason For Revocation Extensions 61
12.1.1. EME-PKCS1-v1_5-ENCODE 63 10.2.2.5.Implementation Features 62
12.1.2. EME-PKCS1-v1_5-DECODE 63 10.2.3. New Packet Versions 62
12.1.3. EMSA-PKCS1-v1_5 64 10.3. New Algorithms 62
12.2. Symmetric Algorithm Preferences 65 10.3.1. Public Key Algorithms 62
12.3. Other Algorithm Preferences 65 10.3.2. Symmetric Key Algorithms 63
12.3.1. Compression Preferences 65 10.3.3. Hash Algorithms 63
12.3.2. Hash Algorithm Preferences 66 10.3.4. Compression Algorithms 63
12.4. Plaintext 66 10.4. Private or Experimental Parameters 63
12.5. RSA 66 10.5. Extension of the MDC System 63
12.6. DSA 67 10.6. Meta-Considerations 64
12.7. Elgamal 67 11. Packet Composition 64
12.8. Reserved Algorithm Numbers 67 11.1. Transferable Public Keys 65
12.9. OpenPGP CFB mode 68 11.2. Transferable Secret Keys 66
13. Security Considerations 69 11.3. OpenPGP Messages 66
14. Implementation Nits 72 11.4. Detached Signatures 67
15. Authors' Addresses 73 12. Enhanced Key Formats 67
16. References (Normative) 74 12.1. Key Structures 67
17. References (Informative) 76 12.2. Key IDs and Fingerprints 68
18. Full Copyright Statement 76 13. Notes on Algorithms 69
13.1. PKCS#1 Encoding In OpenPGP 69
13.1.1. EME-PKCS1-v1_5-ENCODE 69
13.1.2. EME-PKCS1-v1_5-DECODE 70
13.1.3. EMSA-PKCS1-v1_5 70
13.2. Symmetric Algorithm Preferences 71
13.3. Other Algorithm Preferences 72
13.3.1. Compression Preferences 72
13.3.2. Hash Algorithm Preferences 73
13.4. Plaintext 73
13.5. RSA 73
13.6. DSA 73
13.7. Elgamal 74
13.8. Reserved Algorithm Numbers 74
13.9. OpenPGP CFB mode 74
14. Security Considerations 76
15. Implementation Nits 79
16. Authors' Addresses 80
17. References (Normative) 80
18. References (Informative) 82
19. Full Copyright Statement 83
20. Intellectual Property 84
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC 2440, "OpenPGP and key management functions. It is a revision of RFC 2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." Exchange Formats."
1.1. Terms 1.1. Terms
skipping to change at page 6, line 32 skipping to change at page 7, 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, RFC 1991, was cryptographic transforms. An informational RFC, RFC 1991, 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, RFC the community and also in the predecessor of this document, RFC
1991. 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 * GnuPG - GNU Privacy Guard, also called GPG. GnuPG 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 GnuPG did not include RSA public
keys. GPG may or may not have (depending on version) support for keys. GnuPG may or may not have (depending on version) support
IDEA or other encumbered algorithms. 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
PGP Corporation and are used with permission. PGP Corporation and are used with permission. The term "OpenPGP"
refers to the protocol described in this and related documents.
This document uses the terms "MUST", "SHOULD", and "MAY" as defined The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
in RFC 2119, along with the negated forms of those terms. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
this document when used to describe namespace allocation are to be
interpreted as described in RFC 2434.
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:
- digital signatures - digital signatures
- encryption - encryption
skipping to change at page 16, line 47 skipping to change at page 18, line 5
the packet is the length of the header(s) plus the length of the the packet is the length of the header(s) plus the length of the
body. body.
4.3. Packet Tags 4.3. Packet Tags
The packet tag denotes what type of packet the body holds. Note that The packet tag denotes what type of packet the body holds. Note that
old format headers can only have tags less than 16, whereas new old format headers can only have tags less than 16, whereas new
format headers can have tags as great as 63. The defined tags (in format headers can have tags as great as 63. The defined tags (in
decimal) are: decimal) are:
0 -- Reserved - a packet tag must not have this value 0 -- Reserved - a packet tag MUST NOT have this value
1 -- Public-Key Encrypted Session Key Packet 1 -- Public-Key Encrypted Session Key Packet
2 -- Signature Packet 2 -- Signature Packet
3 -- Symmetric-Key Encrypted Session Key Packet 3 -- Symmetric-Key Encrypted Session Key Packet
4 -- One-Pass Signature Packet 4 -- One-Pass Signature Packet
5 -- Secret Key Packet 5 -- Secret Key Packet
6 -- Public Key Packet 6 -- Public Key Packet
7 -- Secret Subkey Packet 7 -- Secret Subkey Packet
8 -- Compressed Data Packet 8 -- Compressed Data Packet
9 -- Symmetrically Encrypted Data Packet 9 -- Symmetrically Encrypted Data Packet
10 -- Marker Packet 10 -- Marker Packet
skipping to change at page 18, line 56 skipping to change at page 20, line 9
V3 signature. V3 signature.
5.2.1. Signature Types 5.2.1. Signature Types
There are a number of possible meanings for a signature, which are There are a number of possible meanings for a signature, which are
indicated in a signature type octet in any given signature. Please indicated in a signature type octet in any given signature. Please
note that the vagueness of these meanings is not a flaw, but a note that the vagueness of these meanings is not a flaw, but a
feature of the system. Because OpenPGP places final authority for feature of the system. Because OpenPGP places final authority for
validity upon the receiver of a signature, it may be that one validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other signer's casual act might be more rigorous than some other
authority's positive act. See section 5.2.4, "Computing authority's positive act. See section 5.2.4, "Computing Signatures,"
Signatures," for detailed information on how to compute and verify for detailed information on how to compute and verify signatures of
signatures of each type. each type.
These meanings are: These meanings are:
0x00: Signature of a binary document. 0x00: Signature of a binary document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. has not been modified.
0x01: Signature of a canonical text document. 0x01: Signature of a canonical text document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. The signature is calculated over the text has not been modified. The signature is calculated over the text
skipping to change at page 25, line 23 skipping to change at page 26, line 23
24 = preferred key server 24 = preferred key server
25 = primary User ID 25 = primary User ID
26 = policy URI 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 = private or experimental
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 is of the signature to recognize. If a subpacket is encountered that is
marked critical but is unknown to the evaluating software, the 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 48, line 9 skipping to change at page 49, line 9
Any failure of the MDC indicates that the message has been modified Any failure of the MDC indicates that the message has been modified
and MUST be treated as a security problem. Failures include a and MUST be treated as a security problem. Failures include a
difference in the hash values, but also the absence of an MDC difference in the hash values, but also the absence of an MDC
packet, or an MDC packet in any position other than the end of the packet, or an MDC packet in any position other than the end of the
plaintext. Any failure SHOULD be reported to the user. plaintext. Any failure SHOULD be reported to the user.
Note: future designs of new versions of this packet should consider Note: future designs of new versions of this packet should consider
rollback attacks since it will be possible for an attacker to change rollback attacks since it will be possible for an attacker to change
the version back to 1. the version back to 1.
NON-NORMATIVE EXPLANATION
The MDC system, as packets 18 and 19 are called, were created to
provide an integrity mechanism that is less strong than a
signature, yet stronger than bare CFB encryption.
It is a limitation of CFB encryption that damage to the
ciphertext will corrupt the affected cipher blocks and the block
following. Additionally, if data is removed from the end of a
CFB-encrypted block, that removal is undetectable. (Note also
that CBC mode has a similar limitation, but data removed from
the front of the block is undetectable.)
The obvious way to protect or authenticate an encrypted block is
to digitally sign it. However, many people do not wish to
habitually sign data, for a large number of reasons beyond the
scope of this document. Suffice it to say that many people
consider properties such as deniability to be as valuable as
integrity.
OpenPGP addresses this desire to have more security than raw
encryption and yet preserve deniability with the MDC system. An
MDC is intentionally not a MAC. Its name was not selected by
accident. It is analogous to a checksum.
Despite the fact that it is a relatively modest system, it has
proved itself in the real world. It is an effective defense to
several attacks that have surfaced since it has been created. It
has met its modest goals admirably.
Consequently, because it is a modest security system, it has
modest requirements on the hash function(s) it employs. It does
not rely on a hash function being collision-free, it relies on a
hash function being one-way. If a forger, Frank, wishes to send
Alice a (digitally) unsigned message that says, "I've always
secretly loved you, signed Bob" it is far easier for him to
construct a new message than it is to modify anything
intercepted from Bob. (Note also that if Bob wishes to
communicate secretly with Alice, but without authentication nor
identification and with a threat model that includes forgers, he
has a problem that transcends mere cryptography.)
Note also that unlike nearly every other OpenPGP subsystem,
there are no parameters in the MDC system. It hard-defines SHA-1
as its hash function. This is not an accident. It is an
intentional choice to avoid downgrade and cross-grade attacks
while making a simple, fast system. (A downgrade attack would be
an attack that replaced SHA-256 with SHA-1, for example. A
cross-grade attack would replace SHA-1 with another 160-bit
hash, such as RIPE-MD/160, for example.)
However, given the present state of hash function cryptanalysis
and cryptography, it may be desirable to upgrade the MDC system
to a new hash function. See section 10.5 in the IANA
considerations for guidance.
5.14. Modification Detection Code Packet (Tag 19) 5.14. Modification Detection Code Packet (Tag 19)
The Modification Detection Code packet contains a SHA-1 hash of The Modification Detection Code packet contains a SHA-1 hash of
plaintext data which is used to detect message modification. It is plaintext data which is used to detect message modification. It is
only used with a Symmetrically Encrypted Integrity Protected Data only used with a Symmetrically Encrypted Integrity Protected Data
packet. The Modification Detection Code packet MUST be the last packet. The Modification Detection Code packet MUST be the last
packet in the plaintext data which is encrypted in the Symmetrically packet in the plaintext data which is encrypted in the Symmetrically
Encrypted Integrity Protected Data packet, and MUST appear in no Encrypted Integrity Protected Data packet, and MUST appear in no
other place. other place.
skipping to change at page 58, line 8 skipping to change at page 60, line 10
7 - Reserved 7 - Reserved
8 - SHA256 [FIPS180] "SHA256" 8 - SHA256 [FIPS180] "SHA256"
9 - SHA384 [FIPS180] "SHA384" 9 - SHA384 [FIPS180] "SHA384"
10 - SHA512 [FIPS180] "SHA512" 10 - SHA512 [FIPS180] "SHA512"
11 - SHA224 [FIPS180] "SHA224" 11 - SHA224 [FIPS180] "SHA224"
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. MD5 is deprecated. other algorithms. MD5 is deprecated.
10. Packet Composition 10. IANA Considerations
OpenPGP is highly parameterized and consequently there are a number
of considerations for allocating parameters for extensions. This
section describes how IANA should look at extensions to the protocol
as described in this document.
10.1. New String-to-Key specifier types
OpenPGP S2K specifiers contain a mechanism for new algorithms to
turn a string into a key. This specification creates a registry of
S2K specifier types. The registry includes the S2K type, the name of
the S2K and a reference to the defining specification. The initial
values for this registry can be found in 3.7.1. Adding a new S2K
specifier MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].
10.2. New Packets
Major new features of OpenPGP are defined though new packet types.
This specification creates a registry of packet types. The registry
includes the packet type, the name of the packet and a reference to
the defining specification. The initial values for this registry can
be found in 4.3. Adding a new packet type MUST be done through the
IETF CONSENSUS method, as described in [RFC2434].
10.2.1. User Attribute Types
The User Attribute packet permits an extensible mechanism for other
types of certificate identification. This specification creates a
registry of User Attribute types. The registry includes the User
Attribute type, the name of the User Attribute and a reference to
the defining specification. The initial values for this registry can
be found in 5.12. Adding a new User Attribute type MUST be done
through the IETF CONSENSUS method, as described in [RFC2434].
10.2.1.1. Image Format Subpacket Types
Within User Attribute packets, there is an extensible mechanism for
other types of image-based user attributes. This specification
creates a registry of Image Attribute subpacket types. The registry
includes the Image Attribute subpacket type, the name of the Image
Attribute subpacket and a reference to the defining specification.
The initial values for this registry can be found in 5.12.1. Adding
a new Image Attribute subpacket type MUST be done through the IETF
CONSENSUS method, as described in [RFC2434].
10.2.2. New Signature Subpackets
OpenPGP signatures contain a mechanism for signed (or unsigned) data
to be added to them for a variety of purposes in the signature
subpackets as discussed in section 5.2.3.1. This specification
creates a registry of signature subpacket types. The registry
includes the signature subpacket type, the name of the subpacket and
a reference to the defining specification. The initial values for
this registry can be found in 5.2.3.1. Adding a new signature
subpacket MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].
10.2.2.1. Signature Notation Data Subpackets
OpenPGP signatures further contain a mechanism for extensions in
signatures. These are the Notation Data subpackets, which contain a
key/value pair. Notations contain a user space which is completely
unmanaged and an IETF space.
This specification creates a registry of Signature Notation Data
types. The registry includes the Signature Notation Data type, the
name of the Signature Notation Data, its allowed values, and a
reference to the defining specification. The initial values for this
registry can be found in 5.2.3.16. Adding a new Signature Notation
Data subpacket MUST be done through the EXPERT REVIEW method, as
described in [RFC2434].
10.2.2.2. Key Server Preference Extensions
OpenPGP signatures contain a mechanism for preferences to be
specified about key servers. This specification creates a registry
of key server preferences. The registry includes the key server
preference, the name of the preference and a reference to the
defining specification. The initial values for this registry can be
found in 5.2.3.17. Adding a new key server preference MUST be done
through the IETF CONSENSUS method, as described in [RFC2434].
10.2.2.3. Key Flags Extensions
OpenPGP signatures contain a mechanism for flags to be specified
about key usage. This specification creates a registry of key usage
flags. The registry includes the key flags value, the name of the
flag and a reference to the defining specification. The initial
values for this registry can be found in 5.2.3.21. Adding a new key
usage flag MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].
10.2.2.4. Reason For Revocation Extensions
OpenPGP signatures contain a mechanism for flags to be specified
about why a key was revoked. This specification creates a registry
of reason-for-revocation flags. The registry includes the
reason-for-revocation flags value, the name of the flag and a
reference to the defining specification. The initial values for this
registry can be found in 5.2.3.23. Adding a new feature flag MUST be
done through the IETF CONSENSUS method, as described in [RFC2434].
10.2.2.5. Implementation Features
OpenPGP signatures contain a mechanism for flags to be specified
stating which optional features an implementation supports. This
specification creates a registry of feature-implementation flags.
The registry includes the feature-implementation flags value, the
name of the flag and a reference to the defining specification. The
initial values for this registry can be found in 5.2.3.24. Adding a
new feature-implementation flag MUST be done through the IETF
CONSENSUS method, as described in [RFC2434].
Also see section 10.6 for more information about when feature flags
are needed.
10.2.3. New Packet Versions
The core OpenPGP packets all have version numbers, and can be
revised by introducing a new version of an existing packet. This
specification creates a registry of packet types. The registry
includes the packet type, the number of the version and a reference
to the defining specification. The initial values for this registry
can be found in 5. Adding a new packet version MUST be done through
the IETF CONSENSUS method, as described in [RFC2434].
10.3. New Algorithms
Chapter 9 lists the core algorithms that OpenPGP uses. Adding in a
new algorithm is usually simple. For example, adding in a new
symmetric cipher usually would not need anything more than
allocating a constant for that cipher. If that cipher had other than
a 64-bit or 128-bit block size, there might need to be additional
documentation describing how OpenPGP-CFB mode would be adjusted.
Similarly, when DSA was expanded from a maximum of 1024-bit public
keys to 3072-bit public keys, the revision of FIPS 186 contained
enough information itself to allow implementation. Changes to this
document were emphasis more than required.
10.3.1. Public Key Algorithms
OpenPGP specifies a number of public key algorithms. This
specification creates a registry of public key algorithm
identifiers. The registry includes the algorithm name, its key sizes
and parameters, and a reference to the defining specification. The
initial values for this registry can be found in section 9. Adding a
new public key algorithm MUST be done through the IETF CONSENSUS
method, as described in [RFC2434].
10.3.2. Symmetric Key Algorithms
OpenPGP specifies a number of symmetric key algorithms. This
specification creates a registry of symmetric key algorithm
identifiers. The registry includes the algorithm name, its key sizes
and block size, and a reference to the defining specification. The
initial values for this registry can be found in section 9. Adding a
new symmetric key algorithm MUST be done through the IETF CONSENSUS
method, as described in [RFC2434].
10.3.3. Hash Algorithms
OpenPGP specifies a number of hash algorithms. This specification
creates a registry of hash algorithm identifiers. The registry
includes the algorithm name, a text representation of that name, its
block size, an OID hash prefix, and a reference to the defining
specification. The initial values for this registry can be found in
section 9 for the algorithm identifiers and text names, and section
5.2.2 for the OIDs and expanded signature prefixes. Adding a new
hash algorithm MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].
10.3.4. Compression Algorithms
OpenPGP specifies a number of compression algorithms. This
specification creates a registry of compression algorithm
identifiers. The registry includes the algorithm name, and a
reference to the defining specification. The initial values for this
registry can be found in section 9. Adding a new compression key
algorithm MUST be done through the IETF CONSENSUS method, as
described in [RFC2434].
10.4. Private or Experimental Parameters
S2K specifiers, Signature subpacket types, user attribute types,
image format types, and algorithms described in Section 9 all
reserve the range 100 to 110 for private and experimental use.
Packet types reserve the range 60 to 63 for private and experimental
use. These are intentionally managed with the PRIVATE USE method, as
described in [RFC2434].
However, implementations need to be careful with these and promote
them to full IANA-managed parameters when they grow beyond the
original, limited system.
10.5. Extension of the MDC System
As described in the non-normative explanation in section 5.13, the
MDC system is uniquely unparameterized in OpenPGP, and that this was
an intentional decision to avoid cross-grade attacks. If the MDC
system is extended to a stronger hash function, there must be care
given to avoiding downgrade and cross-grade attacks.
One simple way to do this is to create new packets for a new MDC.
For example, instead of the MDC system using packets 18 and 19, a
new MDC could use 20 and 21. This has obvious drawbacks (it uses two
packet numbers for each new hash function in a space that is limited
to a maximum of 60).
Another simple way to extend the MDC system is to create new
versions of packet 18, and reflect this in packet 19. For example,
suppose that V2 of packet 18 implicitly used SHA-256. This would
require packet 19 to have a length of 32 octets. The change in the
version in packet 18 and the size of packet 19 prevent a downgrade
attack.
There are two drawbacks to this latter approach. The first is that
using the version number of a packet to carry algorithm information
is not tidy from a protocol-design standpoint. it is possible that
there might be several versions of the MDC system in common use, but
this untidiness would reflect untidiness in cryptographic consensus
about hash function security. The second is that different versions
of packet 19 would have to have unique sizes. If there were two
versions each with 256-bit hashes, they could not both have 32-octet
packet 19s without admitting the chance of a cross-grade attack.
Yet another, complex approach to extend the MDC system would be a
hybrid of the two above -- create a new pair of MDC packets that are
fully parameterized, and yet protected from downgrade and
cross-grade.
Any change to the MDC system MUST be done through the IETF CONSENSUS
method, as described in [RFC2434].
10.6. Meta-Considerations
If OpenPGP is extended in a way that is not upwards-compatible,
meaning that old implementations will not gracefully handle their
absence of a new feature, the extension proposal can be declared in
the key holder's self-signature as part of the Features signature
subpacket.
We cannot state definitively what extensions will not be
upwards-compatible, but typically new algorithms are
upwards-compatible, but new packets are not.
If an extension proposal does not update the Features system, it
SHOULD include an explanation of why this is unnecessary. If the
proposal contains neither an extension to the Features system nor an
explanation of why such an extension is unnecessary, the proposal
SHOULD be rejected.
11. 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 are messages and to transfer keys. Not all possible packet sequences are
meaningful and correct. This section describes the rules for how meaningful and correct. This section describes the rules for how
packets should be placed into sequences. packets should be placed into sequences.
10.1. Transferable Public Keys 11.1. Transferable Public Keys
OpenPGP users may transfer public keys. The essential elements of a OpenPGP users may transfer public keys. The essential elements of a
transferable public key are: transferable public key are:
- One Public Key packet - One Public Key packet
- Zero or more revocation signatures - Zero or more revocation signatures
- One or more User ID packets - One or more User ID packets
skipping to change at page 59, line 33 skipping to change at page 66, line 27
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.
Transferable public key packet sequences may be concatenated to Transferable public key packet sequences may be concatenated to
allow transferring multiple public keys in one operation. allow transferring multiple public keys in one operation.
10.2. Transferable Secret Keys 11.2. Transferable Secret Keys
OpenPGP users may transfer secret keys. The format of a transferable OpenPGP users may transfer secret keys. The format of a transferable
secret key is the same as a transferable public key except that secret key is the same as a transferable public key except that
secret key and secret subkey packets are used instead of the public secret key and secret subkey packets are used instead of the public
key and public subkey packets. Implementations SHOULD include key and public subkey packets. Implementations SHOULD include
self-signatures on any user IDs and subkeys, as this allows for a self-signatures on any user IDs and subkeys, as this allows for a
complete public key to be automatically extracted from the complete public key to be automatically extracted from the
transferable secret key. Implementations MAY choose to omit the transferable secret key. Implementations MAY choose to omit the
self-signatures, especially if a transferable public key accompanies self-signatures, especially if a transferable public key accompanies
the transferable secret key. the transferable secret key.
10.3. OpenPGP Messages 11.3. OpenPGP Messages
An OpenPGP message is a packet or sequence of packets that An OpenPGP message is a packet or sequence of packets that
corresponds to the following grammatical rules (comma represents corresponds to the following grammatical rules (comma represents
sequential composition, and vertical bar separates alternatives): sequential composition, and vertical bar separates alternatives):
OpenPGP Message :- Encrypted Message | Signed Message | OpenPGP Message :- Encrypted Message | Signed Message |
Compressed Message | Literal Message. Compressed Message | Literal Message.
Compressed Message :- Compressed Data Packet. Compressed Message :- Compressed Data Packet.
skipping to change at page 60, line 30 skipping to change at page 67, line 23
OpenPGP Message, Corresponding Signature Packet. OpenPGP Message, Corresponding Signature Packet.
Signed Message :- Signature Packet, OpenPGP Message | Signed Message :- Signature Packet, OpenPGP Message |
One-Pass Signed Message. One-Pass Signed Message.
In addition, decrypting a Symmetrically Encrypted Data Packet or a In addition, decrypting a Symmetrically Encrypted Data Packet or a
Symmetrically Encrypted Integrity Protected Data Packet as well as Symmetrically Encrypted Integrity Protected Data Packet as well as
decompressing a Compressed Data packet must yield a valid OpenPGP decompressing a Compressed Data packet must yield a valid OpenPGP
Message. Message.
10.4. Detached Signatures 11.4. Detached Signatures
Some OpenPGP applications use so-called "detached signatures." For Some OpenPGP applications use so-called "detached signatures." For
example, a program bundle may contain a file, and with it a second example, a program bundle may contain a file, and with it a second
file that is a detached signature of the first file. These detached file that is a detached signature of the first file. These detached
signatures are simply a signature packet stored separately from the signatures are simply a signature packet stored separately from the
data that they are a signature of. data that they are a signature of.
11. Enhanced Key Formats 12. Enhanced Key Formats
11.1. Key Structures 12.1. Key Structures
The format of an OpenPGP V3 key is as follows. Entries in square The format of an OpenPGP V3 key is as follows. Entries in square
brackets are optional and ellipses indicate repetition. brackets are optional and ellipses indicate repetition.
RSA Public Key RSA Public Key
[Revocation Self Signature] [Revocation Self Signature]
User ID [Signature ...] User ID [Signature ...]
[User ID [Signature ...] ...] [User ID [Signature ...] ...]
Each signature certifies the RSA public key and the preceding User Each signature certifies the RSA public key and the preceding User
skipping to change at page 61, line 38 skipping to change at page 68, line 28
The subkeys may be keys of any other type. There may be other The subkeys may be keys of any other type. There may be other
constructions of V4 keys, too. For example, there may be a constructions of V4 keys, too. For example, there may be a
single-key RSA key in V4 format, a DSA primary key with an RSA single-key RSA key in V4 format, a DSA primary key with an RSA
encryption key, or RSA primary key with an Elgamal subkey, etc. encryption key, or RSA primary key with an Elgamal subkey, etc.
It is also possible to have a signature-only subkey. This permits a It is also possible to have a signature-only subkey. This permits a
primary key that collects certifications (key signatures) but is primary key that collects certifications (key signatures) but is
used only used for certifying subkeys that are used for encryption used only used for certifying subkeys that are used for encryption
and signatures. and signatures.
11.2. Key IDs and Fingerprints 12.2. Key IDs and Fingerprints
For a V3 key, the eight-octet key ID consists of the low 64 bits of For a V3 key, the eight-octet key ID consists of the low 64 bits of
the public modulus of the RSA key. the public modulus of the RSA key.
The fingerprint of a V3 key is formed by hashing the body (but not The fingerprint of a V3 key is formed by hashing the body (but not
the two-octet length) of the MPIs that form the key material (public the two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5. Note that both V3 keys modulus n, followed by exponent e) with MD5. Note that both V3 keys
and MD5 are deprecated. and MD5 are deprecated.
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
skipping to change at page 62, line 40 skipping to change at page 69, line 32
Also note that if V3 and V4 format keys share the same RSA key Also note that if V3 and V4 format keys share the same RSA key
material, they will have different key IDs as well as different material, they will have different key IDs as well as different
fingerprints. fingerprints.
Finally, the key ID and fingerprint of a subkey are calculated in Finally, the key ID and fingerprint of a subkey are calculated in
the same way as for a primary key, including the 0x99 as the first the same way as for a primary key, including the 0x99 as the first
octet (even though this is not a valid packet ID for a public octet (even though this is not a valid packet ID for a public
subkey). subkey).
12. Notes on Algorithms 13. Notes on Algorithms
12.1. PKCS#1 Encoding In OpenPGP 13.1. PKCS#1 Encoding In OpenPGP
This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and
EMSA-PKCS1-v1_5. However, the calling conventions of these EMSA-PKCS1-v1_5. However, the calling conventions of these functions
functions has changed in the past. To avoid potential confusion and has changed in the past. To avoid potential confusion and
interoperability problems, we are including local copies in this interoperability problems, we are including local copies in this
document, adapted from those in PKCS#1 v2.1 [RFC3447]. RFC-3447 document, adapted from those in PKCS#1 v2.1 [RFC3447]. RFC-3447
should be treated as the ultimate authority on PKCS#1 for OpenPGP. should be treated as the ultimate authority on PKCS#1 for OpenPGP.
Nonetheless, we believe that there is value in having a Nonetheless, we believe that there is value in having a
self-contained document that avoids problems in the future with self-contained document that avoids problems in the future with
needed changes in the conventions. needed changes in the conventions.
12.1.1. EME-PKCS1-v1_5-ENCODE 13.1.1. EME-PKCS1-v1_5-ENCODE
Input: Input:
k = the length in octets of the key modulus k = the length in octets of the key modulus
M = message to be encoded, an octet string of length mLen, where M = message to be encoded, an octet string of length mLen, where
mLen <= k - 11 mLen <= k - 11
Output: Output:
EM = encoded message, an octet string of length k EM = encoded message, an octet string of length k
Error: "message too long" Error: "message too long"
1. Length checking: If mLen > k - 11, output "message too long" and 1. Length checking: If mLen > k - 11, output "message too long" and
stop. stop.
2. Generate an octet string PS of length k - mLen - 3 consisting of 2. Generate an octet string PS of length k - mLen - 3 consisting of
skipping to change at page 63, line 34 skipping to change at page 70, line 24
pseudo-randomly generated nonzero octets. The length of PS will pseudo-randomly generated nonzero octets. The length of PS will
be at least eight octets. be at least eight octets.
3. Concatenate PS, the message M, and other padding to form an 3. Concatenate PS, the message M, and other padding to form an
encoded message EM of length k octets as encoded message EM of length k octets as
EM = 0x00 || 0x02 || PS || 0x00 || M. EM = 0x00 || 0x02 || PS || 0x00 || M.
4. Output EM. 4. Output EM.
12.1.2. EME-PKCS1-v1_5-DECODE 13.1.2. EME-PKCS1-v1_5-DECODE
Input: Input:
EM = encoded message, an octet string EM = encoded message, an octet string
Output: Output:
M = message, an octet string M = message, an octet string
Error: "decryption error" Error: "decryption error"
skipping to change at page 64, line 7 skipping to change at page 70, line 50
EM = 0x00 || 0x02 || PS || 0x00 || M. EM = 0x00 || 0x02 || PS || 0x00 || M.
If the first octet of EM does not have hexadecimal value 0x00, if If the first octet of EM does not have hexadecimal value 0x00, if
the second octet of EM does not have hexadecimal value 0x02, if the second octet of EM does not have hexadecimal value 0x02, if
there is no octet with hexadecimal value 0x00 to separate PS from M, there is no octet with hexadecimal value 0x00 to separate PS from M,
or if the length of PS is less than 8 octets, output "decryption or if the length of PS is less than 8 octets, output "decryption
error" and stop. See also the security note in section 13 regarding error" and stop. See also the security note in section 13 regarding
differences in reporting between a decryption error and a padding differences in reporting between a decryption error and a padding
error. error.
12.1.3. EMSA-PKCS1-v1_5 13.1.3. EMSA-PKCS1-v1_5
This encoding method is deterministic and only has an encoding This encoding method is deterministic and only has an encoding
operation. operation.
Option: Option:
Hash hash function (hLen denotes the length in octets of the hash Hash hash function (hLen denotes the length in octets of the hash
function output) function output)
Input: Input:
skipping to change at page 65, line 4 skipping to change at page 71, line 48
3. If emLen < tLen + 11, output "intended encoded message length 3. If emLen < tLen + 11, output "intended encoded message length
too short" and stop. too short" and stop.
4. Generate an octet string PS consisting of emLen - tLen - 3 4. Generate an octet string PS consisting of emLen - tLen - 3
octets with hexadecimal value 0xff. The length of PS will be at octets with hexadecimal value 0xff. The length of PS will be at
least 8 octets. least 8 octets.
5. Concatenate PS, the hash prefix T, and other padding to form the 5. Concatenate PS, the hash prefix T, and other padding to form the
encoded message EM as encoded message EM as
EM = 0x00 || 0x01 || PS || 0x00 || T. EM = 0x00 || 0x01 || PS || 0x00 || T.
6. Output EM. 6. Output EM.
12.2. Symmetric Algorithm Preferences 13.2. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature, that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have multiple, different it is possible that a keyholder may have multiple, different
preferences. For example, Alice may have TripleDES only specified preferences. For example, Alice may have TripleDES only specified
for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for "alice@work.com" but CAST5, Blowfish, and TripleDES specified
for "alice@home.org". Note that it is also possible for preferences for "alice@home.org". Note that it is also possible for preferences
to be in a subkey's binding signature. to be in a subkey's binding signature.
Since TripleDES is the MUST-implement algorithm, if it is not Since TripleDES is the MUST-implement algorithm, if it is not
skipping to change at page 65, line 42 skipping to change at page 72, line 34
If an implementation can decrypt a message that a keyholder doesn't If an implementation can decrypt a message that a keyholder doesn't
have in their preferences, the implementation SHOULD decrypt the have in their preferences, the implementation SHOULD decrypt the
message anyway, but MUST warn the keyholder that the protocol has message anyway, but MUST warn the keyholder that the protocol has
been violated. For example, suppose that Alice, above, has software been violated. For example, suppose that Alice, above, has software
that implements all algorithms in this specification. Nonetheless, that implements all algorithms in this specification. Nonetheless,
she prefers subsets for work or home. If she is sent a message she prefers subsets for work or home. If she is sent a message
encrypted with IDEA, which is not in her preferences, the software encrypted with IDEA, which is not in her preferences, the software
warns her that someone sent her an IDEA-encrypted message, but it warns her that someone sent her an IDEA-encrypted message, but it
would ideally decrypt it anyway. would ideally decrypt it anyway.
12.3. Other Algorithm Preferences 13.3. Other Algorithm Preferences
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.3.1. Compression Preferences 13.3.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, In this specification, the default is for messages to be compressed,
although an implementation is not required to do so. Consequently, although an implementation is not required to do so. Consequently,
the compression preference gives a way for a keyholder to request the compression preference gives a way for a keyholder to request
that messages not be compressed, presumably because they are using a that messages not be compressed, presumably because they are using a
minimal implementation that does not include compression. minimal implementation that does not include compression.
Additionally, this gives a keyholder a way to state that it can Additionally, this gives a keyholder a way to state that it can
support alternate algorithms. support alternate algorithms.
skipping to change at page 66, line 23 skipping to change at page 73, line 18
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
implementation can satisfy this requirement by never generating a implementation can satisfy this requirement by never generating a
compressed message, since all implementations can handle messages compressed message, since all implementations can handle messages
that have not been compressed. that have not been compressed.
12.3.2. Hash Algorithm Preferences 13.3.2. Hash Algorithm Preferences
Typically, the choice of a hash algorithm is something the signer Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer rarely knows who is does, rather than the verifier, because a signer rarely knows who is
going to be verifying the signature. This preference, though, allows going to be verifying the signature. This preference, though, allows
a protocol based upon digital signatures ease in negotiation. a protocol based upon digital signatures ease in negotiation.
Thus, if Alice is authenticating herself to Bob with a signature, it Thus, if Alice is authenticating herself to Bob with a signature, it
makes sense for her to use a hash algorithm that Bob's software makes sense for her to use a hash algorithm that Bob's software
uses. This preference allows Bob to state in his key which uses. This preference allows Bob to state in his key which
algorithms Alice may use. algorithms Alice may use.
Since SHA1 is the MUST-implement hash algorithm, if it is not Since SHA1 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly. good form to place it there explicitly.
12.4. Plaintext 13.4. Plaintext
Algorithm 0, "plaintext," may only be used to denote secret keys Algorithm 0, "plaintext," may only be used to denote secret keys
that are stored in the clear. Implementations MUST NOT use plaintext that are stored in the clear. Implementations MUST NOT use plaintext
in Symmetrically Encrypted Data Packets; they must use Literal Data in Symmetrically Encrypted Data Packets; they must use Literal Data
Packets to encode unencrypted or literal data. Packets to encode unencrypted or literal data.
12.5. RSA 13.5. RSA
There are algorithm types for RSA-signature-only, and There are algorithm types for RSA-signature-only, and
RSA-encrypt-only keys. These types are deprecated. The "key flags" RSA-encrypt-only keys. These types are deprecated. The "key flags"
subpacket in a signature is a much better way to express the same subpacket in a signature is a much better way to express the same
idea, and generalizes it to all algorithms. An implementation SHOULD idea, and generalizes it to all algorithms. An implementation SHOULD
NOT create such a key, but MAY interpret it. NOT create such a key, but MAY interpret it.
An implementation SHOULD NOT implement RSA keys of size less than An implementation SHOULD NOT implement RSA keys of size less than
1024 bits. 1024 bits.
12.6. DSA 13.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
1024 bits. It MUST NOT implement a DSA key with a q size of less 1024 bits. It MUST NOT implement a DSA key with a q size of less
than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the
q size MUST be a multiple of 8 bits. The Digital Signature Standard q size MUST be a multiple of 8 bits. The Digital Signature Standard
(DSS) [FIPS186] specifies that DSA be used in one of the following (DSS) [FIPS186] specifies that DSA be used in one of the following
ways: ways:
* 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or
SHA-512 hash SHA-512 hash
skipping to change at page 67, line 39 skipping to change at page 74, line 30
SHOULD use one of the above key and q size pairs when generating DSA SHOULD use one of the above key and q size pairs when generating DSA
keys. If DSS compliance is desired, one of the specified SHA hashes keys. If DSS compliance is desired, one of the specified SHA hashes
must be used as well. [FIPS186] is the ultimate authority on DSS, must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance. and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160-bit q Note that earlier versions of this standard only allowed a 160-bit q
with no truncation allowed, so earlier implementations may not be with no truncation allowed, so earlier implementations may not be
able to handle signatures with a different q size or a truncated able to handle signatures with a different q size or a truncated
hash. hash.
12.7. Elgamal 13.7. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less An implementation SHOULD NOT implement Elgamal keys of size less
than 1024 bits. than 1024 bits.
12.8. Reserved Algorithm Numbers 13.8. Reserved Algorithm Numbers
A number of algorithm IDs have been reserved for algorithms that A number of algorithm IDs have been reserved for algorithms that
would be useful to use in an OpenPGP implementation, yet there are would be useful to use in an OpenPGP implementation, yet there are
issues that prevent an implementer from actually implementing the issues that prevent an implementer from actually implementing the
algorithm. These are marked in the Public Algorithms section as algorithm. These are marked in the Public Algorithms section as
"(reserved for)". "(reserved for)".
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
and X9.42 (21) do not have the necessary parameters, parameter and X9.42 (21) do not have the necessary parameters, parameter
order, or semantics defined. order, or semantics defined.
Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
with a public key identifier of 20. These are no longer permitted. with a public key identifier of 20. These are no longer permitted.
An implementation MUST NOT generate such keys. An implementation An implementation MUST NOT generate such keys. An implementation
MUST NOT generate Elgamal signatures. MUST NOT generate Elgamal signatures.
12.9. OpenPGP CFB mode 13.9. OpenPGP CFB mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback OpenPGP does symmetric encryption using a variant of Cipher Feedback
Mode (CFB mode). This section describes the procedure it uses in Mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Encrypted Data detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret key material is Packets; the mechanism used for encrypting secret key material is
similar, but described in those sections above. similar, but described in those sections above.
In the description below, the value BS is the block size in octets In the description below, the value BS is the block size in octets
of the cipher. Most ciphers have a block size of 8 octets. The AES of the cipher. Most ciphers have a block size of 8 octets. The AES
and Twofish have a block size of 16 octets. Also note that the and Twofish have a block size of 16 octets. Also note that the
skipping to change at page 69, line 24 skipping to change at page 76, line 14
10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
for an 8-octet block). for an 8-octet block).
11. FR is encrypted to produce FRE. 11. FR is encrypted to produce FRE.
12. FRE is xored with the next BS octets of plaintext, to produce 12. FRE is xored with the next BS octets of plaintext, to produce
the next BS octets of ciphertext. These are loaded into FR and the next BS octets of ciphertext. These are loaded into FR and
the process is repeated until the plaintext is used up. the process is repeated until the plaintext is used up.
13. Security Considerations 14. Security Considerations
* As with any technology involving cryptography, you should check * As with any technology involving cryptography, you should check
the current literature to determine if any algorithms used here the current literature to determine if any algorithms used here
have been found to be vulnerable to attack. have been found to be vulnerable to attack.
* This specification uses Public Key Cryptography technologies. It * This specification uses Public Key Cryptography technologies. It
is assumed that the private key portion of a public-private key is assumed that the private key portion of a public-private key
pair is controlled and secured by the proper party or parties. pair is controlled and secured by the proper party or parties.
* Certain operations in this specification involve the use of * Certain operations in this specification involve the use of
skipping to change at page 72, line 31 skipping to change at page 79, line 18
timing information about the check can be exposed to an timing information about the check can be exposed to an
attacker, particularly via an automated service that allows attacker, particularly via an automated service that allows
rapidly repeated queries. rapidly repeated queries.
On the other hand, it is inconvenient to the user to be informed 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 that they typed in the wrong passphrase only after a petabyte of
data is decrypted. There are many cases in cryptographic data is decrypted. There are many cases in cryptographic
engineering where the implementer must use care and wisdom, and engineering where the implementer must use care and wisdom, and
this is one. this is one.
14. Implementation Nits 15. 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.
* The IDEA algorithm is patented, and yet it is required for PGP * The IDEA algorithm is patented, and yet it is required for PGP
2.x interoperability. It is also the defacto preferred algorithm 2.x interoperability. It is also the de-facto preferred
for a V3 key with a V3 self-signature (or no self-signature). algorithm 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. Some older PGP versions generated or reject them as it sees fit. Some older PGP versions generated
skipping to change at page 73, line 24 skipping to change at page 80, line 13
have different fingerprints. have different fingerprints.
* If an implementation is using zlib to interoperate with PGP 2.x, * If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
* The 0x19 back signatures were not required for signing subkeys * The 0x19 back signatures were not required for signing subkeys
until relatively recently. Consquently, there may be keys in the until relatively recently. Consquently, there may be keys in the
wild that do not have these back signatures. Implementing wild that do not have these back signatures. Implementing
software may handle these keys as it sees fit. software may handle these keys as it sees fit.
15. Authors' Addresses 16. Authors' Addresses
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Derek Atkins Derek Atkins
IHTFP Consulting, Inc. IHTFP Consulting, Inc.
6 Farragut Ave 6 Farragut Ave
Somerville, MA 02144 USA Somerville, MA 02144 USA
Email: derek@ihtfp.com Email: derek@ihtfp.com
Tel: +1 617 623 3745 Tel: +1 617 623 3745
skipping to change at page 74, line 4 skipping to change at page 80, line 44
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Hal Finney Hal Finney
Email: hal@finney.org Email: hal@finney.org
David Shaw David Shaw
Email: dshaw@jabberwocky.com Email: dshaw@jabberwocky.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, Ben Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben
Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William
Stallings, Mark Weaver, and Philip R. Zimmermann. Stallings, Mark Weaver, and Philip R. Zimmermann.
16. References (Normative) 17. References (Normative)
[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>
[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
skipping to change at page 76, line 5 skipping to change at page 82, line 45
Cryptography Specifications Version 2.1", Cryptography Specifications Version 2.1",
RFC 3447, February 2003. RFC 3447, February 2003.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996. protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999. Algorithm", John Wiley & Sons, 1999.
17. References (Informative) 18. References (Informative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key," signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is proceedings has an error. A revised version is
available at the time of writing from available at the time of writing from
<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
[MAURER] Ueli Maurer, "Modelling a Public-Key
Infrastructure", Proc. 1996 European Symposium on
Research in Computer Security (ESORICS' 96),
Lecture Notes in Computer Science, Springer-Verlag,
vol. 1146, pp. 325-350, Sep 1996.
[MZ05] Serge Mister, Robert Zuccherato, "An Attack on [MZ05] Serge Mister, Robert Zuccherato, "An Attack on
CFB Mode Encryption As Used By OpenPGP," IACR CFB Mode Encryption As Used By OpenPGP," IACR
http://eprint.iacr.org/2005/033 http://eprint.iacr.org/2005/033
[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC
1983, August 1996. 1983, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997. Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[SP800-57] NIST Special Publication 800-57, Recommendation on [SP800-57] NIST Special Publication 800-57, Recommendation on
Key Management Key Management
<http://csrc.nist.gov/publications/nistpubs/ <http://csrc.nist.gov/publications/nistpubs/
800-57/SP800-57-Part1.pdf> 800-57/SP800-57-Part1.pdf>
<http://csrc.nist.gov/publications/nistpubs/ <http://csrc.nist.gov/publications/nistpubs/
800-57/SP800-57-Part2.pdf> 800-57/SP800-57-Part2.pdf>
18. Full Copyright Statement 19. Full Copyright Statement
Copyright (C) 2006 by The Internet Society. Copyright (C) 2007 by The IETF Trust.
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, THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
20. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 60 change blocks. 
235 lines changed or deleted 545 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/