Network Working Group J. Callas
Request for Comments: 4880 PGP Corporation
Obsoletes: 1991, 2440 L. Donnerhacke
Category: Standards Track IKS GmbH
H. Finney
PGP Corporation
D. Shaw
R. Thayer
November 2007
Network Working Group J. Callas
Request for Comments: 4880 PGP Corporation
Obsoletes: 1991, 2440 L. Donnerhacke
Category: Standards Track IKS GmbH
H. Finney
PGP Corporation
D. Shaw
R. Thayer
November 2007
OpenPGP Message Format
OpenPGP消息格式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.
维护本文档是为了发布开发基于OpenPGP格式的可互操作应用程序所需的所有必要信息。它不是编写应用程序的一本循序渐进的食谱。它仅描述读取、检查、生成和写入跨任何网络的一致性数据包所需的格式和方法。它不处理存储和实现问题。然而，它确实讨论了避免安全缺陷所必需的实现问题。
OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP.
OpenPGP软件结合使用强公钥和对称加密技术，为电子通信和数据存储提供安全服务。这些服务包括保密性、密钥管理、身份验证和数字签名。本文档指定了OpenPGP中使用的消息格式。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Terms ......................................................5
2. General functions ...............................................6
2.1. Confidentiality via Encryption .............................6
2.2. Authentication via Digital Signature .......................7
2.3. Compression ................................................7
2.4. Conversion to Radix-64 .....................................8
2.5. Signature-Only Applications ................................8
3. Data Element Formats ............................................8
3.1. Scalar Numbers .............................................8
3.2. Multiprecision Integers ....................................9
3.3. Key IDs ....................................................9
3.4. Text .......................................................9
3.5. Time Fields ...............................................10
3.6. Keyrings ..................................................10
3.7. String-to-Key (S2K) Specifiers ............................10
3.7.1. String-to-Key (S2K) Specifier Types ................10
3.7.1.1. Simple S2K ................................10
3.7.1.2. Salted S2K ................................11
3.7.1.3. Iterated and Salted S2K ...................11
3.7.2. String-to-Key Usage ................................12
3.7.2.1. Secret-Key Encryption .....................12
3.7.2.2. Symmetric-Key Message Encryption ..........13
4. Packet Syntax ..................................................13
4.1. Overview ..................................................13
4.2. Packet Headers ............................................13
4.2.1. Old Format Packet Lengths ..........................14
4.2.2. New Format Packet Lengths ..........................15
4.2.2.1. One-Octet Lengths .........................15
4.2.2.2. Two-Octet Lengths .........................15
4.2.2.3. Five-Octet Lengths ........................15
4.2.2.4. Partial Body Lengths ......................16
4.2.3. Packet Length Examples .............................16
4.3. Packet Tags ...............................................17
5. Packet Types ...................................................17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) ..........17
5.2. Signature Packet (Tag 2) ..................................19
5.2.1. Signature Types ....................................19
5.2.2. Version 3 Signature Packet Format ..................21
5.2.3. Version 4 Signature Packet Format ..................24
5.2.3.1. Signature Subpacket Specification .........25
5.2.3.2. Signature Subpacket Types .................27
5.2.3.3. Notes on Self-Signatures ..................27
5.2.3.4. Signature Creation Time ...................28
5.2.3.5. Issuer ....................................28
5.2.3.6. Key Expiration Time .......................28
1. Introduction ....................................................5
1.1. Terms ......................................................5
2. General functions ...............................................6
2.1. Confidentiality via Encryption .............................6
2.2. Authentication via Digital Signature .......................7
2.3. Compression ................................................7
2.4. Conversion to Radix-64 .....................................8
2.5. Signature-Only Applications ................................8
3. Data Element Formats ............................................8
3.1. Scalar Numbers .............................................8
3.2. Multiprecision Integers ....................................9
3.3. Key IDs ....................................................9
3.4. Text .......................................................9
3.5. Time Fields ...............................................10
3.6. Keyrings ..................................................10
3.7. String-to-Key (S2K) Specifiers ............................10
3.7.1. String-to-Key (S2K) Specifier Types ................10
3.7.1.1. Simple S2K ................................10
3.7.1.2. Salted S2K ................................11
3.7.1.3. Iterated and Salted S2K ...................11
3.7.2. String-to-Key Usage ................................12
3.7.2.1. Secret-Key Encryption .....................12
3.7.2.2. Symmetric-Key Message Encryption ..........13
4. Packet Syntax ..................................................13
4.1. Overview ..................................................13
4.2. Packet Headers ............................................13
4.2.1. Old Format Packet Lengths ..........................14
4.2.2. New Format Packet Lengths ..........................15
4.2.2.1. One-Octet Lengths .........................15
4.2.2.2. Two-Octet Lengths .........................15
4.2.2.3. Five-Octet Lengths ........................15
4.2.2.4. Partial Body Lengths ......................16
4.2.3. Packet Length Examples .............................16
4.3. Packet Tags ...............................................17
5. Packet Types ...................................................17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) ..........17
5.2. Signature Packet (Tag 2) ..................................19
5.2.1. Signature Types ....................................19
5.2.2. Version 3 Signature Packet Format ..................21
5.2.3. Version 4 Signature Packet Format ..................24
5.2.3.1. Signature Subpacket Specification .........25
5.2.3.2. Signature Subpacket Types .................27
5.2.3.3. Notes on Self-Signatures ..................27
5.2.3.4. Signature Creation Time ...................28
5.2.3.5. Issuer ....................................28
5.2.3.6. Key Expiration Time .......................28
5.2.3.7. Preferred Symmetric Algorithms ............28
5.2.3.8. Preferred Hash Algorithms .................29
5.2.3.9. Preferred Compression Algorithms ..........29
5.2.3.10. Signature Expiration Time ................29
5.2.3.11. Exportable Certification .................29
5.2.3.12. Revocable ................................30
5.2.3.13. Trust Signature ..........................30
5.2.3.14. Regular Expression .......................31
5.2.3.15. Revocation Key ...........................31
5.2.3.16. Notation Data ............................31
5.2.3.17. Key Server Preferences ...................32
5.2.3.18. Preferred Key Server .....................33
5.2.3.19. Primary User ID ..........................33
5.2.3.20. Policy URI ...............................33
5.2.3.21. Key Flags ................................33
5.2.3.22. Signer's User ID .........................34
5.2.3.23. Reason for Revocation ....................35
5.2.3.24. Features .................................36
5.2.3.25. Signature Target .........................36
5.2.3.26. Embedded Signature .......................37
5.2.4. Computing Signatures ...............................37
5.2.4.1. Subpacket Hints ...........................38
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) .......38
5.4. One-Pass Signature Packets (Tag 4) ........................39
5.5. Key Material Packet .......................................40
5.5.1. Key Packet Variants ................................40
5.5.1.1. Public-Key Packet (Tag 6) .................40
5.5.1.2. Public-Subkey Packet (Tag 14) .............40
5.5.1.3. Secret-Key Packet (Tag 5) .................41
5.5.1.4. Secret-Subkey Packet (Tag 7) ..............41
5.5.2. Public-Key Packet Formats ..........................41
5.5.3. Secret-Key Packet Formats ..........................43
5.6. Compressed Data Packet (Tag 8) ............................45
5.7. Symmetrically Encrypted Data Packet (Tag 9) ...............45
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) ..........46
5.9. Literal Data Packet (Tag 11) ..............................46
5.10. Trust Packet (Tag 12) ....................................47
5.11. User ID Packet (Tag 13) ..................................48
5.12. User Attribute Packet (Tag 17) ...........................48
5.12.1. The Image Attribute Subpacket .....................48
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) ..49
5.14. Modification Detection Code Packet (Tag 19) ..............52
6. Radix-64 Conversions ...........................................53
6.1. An Implementation of the CRC-24 in "C" ....................54
6.2. Forming ASCII Armor .......................................54
6.3. Encoding Binary in Radix-64 ...............................57
6.4. Decoding Radix-64 .........................................58
6.5. Examples of Radix-64 ......................................59
5.2.3.7. Preferred Symmetric Algorithms ............28
5.2.3.8. Preferred Hash Algorithms .................29
5.2.3.9. Preferred Compression Algorithms ..........29
5.2.3.10. Signature Expiration Time ................29
5.2.3.11. Exportable Certification .................29
5.2.3.12. Revocable ................................30
5.2.3.13. Trust Signature ..........................30
5.2.3.14. Regular Expression .......................31
5.2.3.15. Revocation Key ...........................31
5.2.3.16. Notation Data ............................31
5.2.3.17. Key Server Preferences ...................32
5.2.3.18. Preferred Key Server .....................33
5.2.3.19. Primary User ID ..........................33
5.2.3.20. Policy URI ...............................33
5.2.3.21. Key Flags ................................33
5.2.3.22. Signer's User ID .........................34
5.2.3.23. Reason for Revocation ....................35
5.2.3.24. Features .................................36
5.2.3.25. Signature Target .........................36
5.2.3.26. Embedded Signature .......................37
5.2.4. Computing Signatures ...............................37
5.2.4.1. Subpacket Hints ...........................38
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) .......38
5.4. One-Pass Signature Packets (Tag 4) ........................39
5.5. Key Material Packet .......................................40
5.5.1. Key Packet Variants ................................40
5.5.1.1. Public-Key Packet (Tag 6) .................40
5.5.1.2. Public-Subkey Packet (Tag 14) .............40
5.5.1.3. Secret-Key Packet (Tag 5) .................41
5.5.1.4. Secret-Subkey Packet (Tag 7) ..............41
5.5.2. Public-Key Packet Formats ..........................41
5.5.3. Secret-Key Packet Formats ..........................43
5.6. Compressed Data Packet (Tag 8) ............................45
5.7. Symmetrically Encrypted Data Packet (Tag 9) ...............45
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) ..........46
5.9. Literal Data Packet (Tag 11) ..............................46
5.10. Trust Packet (Tag 12) ....................................47
5.11. User ID Packet (Tag 13) ..................................48
5.12. User Attribute Packet (Tag 17) ...........................48
5.12.1. The Image Attribute Subpacket .....................48
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) ..49
5.14. Modification Detection Code Packet (Tag 19) ..............52
6. Radix-64 Conversions ...........................................53
6.1. An Implementation of the CRC-24 in "C" ....................54
6.2. Forming ASCII Armor .......................................54
6.3. Encoding Binary in Radix-64 ...............................57
6.4. Decoding Radix-64 .........................................58
6.5. Examples of Radix-64 ......................................59
6.6. Example of an ASCII Armored Message .......................59
7. Cleartext Signature Framework ..................................59
7.1. Dash-Escaped Text .........................................60
8. Regular Expressions ............................................61
9. Constants ......................................................61
9.1. Public-Key Algorithms .....................................62
9.2. Symmetric-Key Algorithms ..................................62
9.3. Compression Algorithms ....................................63
9.4. Hash Algorithms ...........................................63
10. IANA Considerations ...........................................63
10.1. New String-to-Key Specifier Types ........................64
10.2. New Packets ..............................................64
10.2.1. User Attribute Types ..............................64
10.2.1.1. Image Format Subpacket Types .............64
10.2.2. New Signature Subpackets ..........................64
10.2.2.1. Signature Notation Data Subpackets .......65
10.2.2.2. Key Server Preference Extensions .........65
10.2.2.3. Key Flags Extensions .....................65
10.2.2.4. Reason For Revocation Extensions .........65
10.2.2.5. Implementation Features ..................66
10.2.3. New Packet Versions ...............................66
10.3. New Algorithms ...........................................66
10.3.1. Public-Key Algorithms .............................66
10.3.2. Symmetric-Key Algorithms ..........................67
10.3.3. Hash Algorithms ...................................67
10.3.4. Compression Algorithms ............................67
11. Packet Composition ............................................67
11.1. Transferable Public Keys .................................67
11.2. Transferable Secret Keys .................................69
11.3. OpenPGP Messages .........................................69
11.4. Detached Signatures ......................................70
12. Enhanced Key Formats ..........................................70
12.1. Key Structures ...........................................70
12.2. Key IDs and Fingerprints .................................71
13. Notes on Algorithms ...........................................72
13.1. PKCS#1 Encoding in OpenPGP ...............................72
13.1.1. EME-PKCS1-v1_5-ENCODE .............................73
13.1.2. EME-PKCS1-v1_5-DECODE .............................73
13.1.3. EMSA-PKCS1-v1_5 ...................................74
13.2. Symmetric Algorithm Preferences ..........................75
13.3. Other Algorithm Preferences ..............................76
13.3.1. Compression Preferences ...........................76
13.3.2. Hash Algorithm Preferences ........................76
13.4. Plaintext ................................................77
13.5. RSA ......................................................77
13.6. DSA ......................................................77
13.7. Elgamal ..................................................78
13.8. Reserved Algorithm Numbers ...............................78
6.6. Example of an ASCII Armored Message .......................59
7. Cleartext Signature Framework ..................................59
7.1. Dash-Escaped Text .........................................60
8. Regular Expressions ............................................61
9. Constants ......................................................61
9.1. Public-Key Algorithms .....................................62
9.2. Symmetric-Key Algorithms ..................................62
9.3. Compression Algorithms ....................................63
9.4. Hash Algorithms ...........................................63
10. IANA Considerations ...........................................63
10.1. New String-to-Key Specifier Types ........................64
10.2. New Packets ..............................................64
10.2.1. User Attribute Types ..............................64
10.2.1.1. Image Format Subpacket Types .............64
10.2.2. New Signature Subpackets ..........................64
10.2.2.1. Signature Notation Data Subpackets .......65
10.2.2.2. Key Server Preference Extensions .........65
10.2.2.3. Key Flags Extensions .....................65
10.2.2.4. Reason For Revocation Extensions .........65
10.2.2.5. Implementation Features ..................66
10.2.3. New Packet Versions ...............................66
10.3. New Algorithms ...........................................66
10.3.1. Public-Key Algorithms .............................66
10.3.2. Symmetric-Key Algorithms ..........................67
10.3.3. Hash Algorithms ...................................67
10.3.4. Compression Algorithms ............................67
11. Packet Composition ............................................67
11.1. Transferable Public Keys .................................67
11.2. Transferable Secret Keys .................................69
11.3. OpenPGP Messages .........................................69
11.4. Detached Signatures ......................................70
12. Enhanced Key Formats ..........................................70
12.1. Key Structures ...........................................70
12.2. Key IDs and Fingerprints .................................71
13. Notes on Algorithms ...........................................72
13.1. PKCS#1 Encoding in OpenPGP ...............................72
13.1.1. EME-PKCS1-v1_5-ENCODE .............................73
13.1.2. EME-PKCS1-v1_5-DECODE .............................73
13.1.3. EMSA-PKCS1-v1_5 ...................................74
13.2. Symmetric Algorithm Preferences ..........................75
13.3. Other Algorithm Preferences ..............................76
13.3.1. Compression Preferences ...........................76
13.3.2. Hash Algorithm Preferences ........................76
13.4. Plaintext ................................................77
13.5. RSA ......................................................77
13.6. DSA ......................................................77
13.7. Elgamal ..................................................78
13.8. Reserved Algorithm Numbers ...............................78
13.9. OpenPGP CFB Mode .........................................78
13.10. Private or Experimental Parameters ......................79
13.11. Extension of the MDC System .............................80
13.12. Meta-Considerations for Expansion .......................80
14. Security Considerations .......................................81
15. Implementation Nits ...........................................84
16. References ....................................................86
16.1. Normative References .....................................86
16.2. Informative References ...................................88
13.9. OpenPGP CFB Mode .........................................78
13.10. Private or Experimental Parameters ......................79
13.11. Extension of the MDC System .............................80
13.12. Meta-Considerations for Expansion .......................80
14. Security Considerations .......................................81
15. Implementation Nits ...........................................84
16. References ....................................................86
16.1. Normative References .....................................86
16.2. Informative References ...................................88
This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, and key management functions. It is a revision of RFC 2440, "OpenPGP Message Format", which itself replaces RFC 1991, "PGP Message Exchange Formats" [RFC1991] [RFC2440].
本文档提供有关OpenPGP用于提供加密、解密、签名和密钥管理功能的消息交换数据包格式的信息。它是RFC 2440“OpenPGP消息格式”的修订版，其本身取代了RFC 1991“PGP消息交换格式”[RFC1991][RFC2440]。
* OpenPGP - This is a term for security software that uses PGP 5.x as a basis, formalized in RFC 2440 and this document.
* OpenPGP-这是一个安全软件的术语，使用PGP5.x作为基础，在RFC2440和本文档中正式定义。
* PGP - Pretty Good Privacy. PGP is a family of software systems developed by Philip R. Zimmermann from which OpenPGP is based.
* PGP-相当好的隐私。PGP是由Philip R.Zimmermann开发的一系列软件系统，OpenPGP就是基于这些系统开发的。
* PGP 2.6.x - This version of PGP has many variants, hence the term PGP 2.6.x. It used only RSA, MD5, and IDEA for its cryptographic transforms. An informational RFC, RFC 1991, was written describing this version of PGP.
* PGP2.6.x-此版本的PGP有许多变体，因此称为PGP2.6.x。它只使用RSA、MD5和IDEA进行加密转换。一份信息RFC，RFC1991，描述了PGP的这个版本。
* 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 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 that software was the first release of the "PGP 3" code base.
* PGP 5.x-该版本的PGP在社区中以前称为“PGP 3”，也是本文件的前身RFC 1991。它有新的格式，并纠正了PGP2.6.x设计中的一些问题。这里称之为PGP5.x，因为该软件是“PGP3”代码库的第一个版本。
* GnuPG - GNU Privacy Guard, also called GPG. GnuPG is an OpenPGP implementation that avoids all encumbered algorithms. Consequently, early versions of GnuPG did not include RSA public keys. GnuPG may or may not have (depending on version) support for IDEA or other encumbered algorithms.
* GnuPG-GNU隐私保护，也称为GPG。GnuPG是一个OpenPGP实现，它避免了所有阻塞的算法。因此，早期版本的GnuPG不包括RSA公钥。GnuPG可能支持IDEA或其他受阻碍的算法，也可能不支持（取决于版本）。
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP Corporation and are used with permission. The term "OpenPGP" refers to the protocol described in this and related documents.
“PGP”、“相当好”和“相当好的隐私”是PGP公司的商标，在获得许可后使用。术语“OpenPGP”指本文件和相关文件中描述的协议。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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 [RFC2434].
当用于描述命名空间分配时，本文件中出现的关键词“私人使用”、“分层分配”、“先到先得”、“专家评审”、“需要规范”、“IESG批准”、“IETF共识”和“标准行动”应按照[RFC2434]中的描述进行解释。
OpenPGP provides data integrity services for messages and data files by using these core technologies:
OpenPGP使用以下核心技术为消息和数据文件提供数据完整性服务：
- digital signatures
- 数字签名
- encryption
- 加密
- compression
- 压缩
- Radix-64 conversion
- 基数-64转换
In addition, OpenPGP provides key management and certificate services, but many of these are beyond the scope of this document.
此外，OpenPGP提供了密钥管理和证书服务，但其中许多服务超出了本文的范围。
OpenPGP combines symmetric-key encryption and public-key encryption to provide confidentiality. When made confidential, first the object is encrypted using a symmetric encryption algorithm. Each symmetric key is used only once, for a single object. A new "session key" is generated as a random number for each object (sometimes referred to as a session). Since it is used only once, the session key is bound to the message and transmitted with it. To protect the key, it is encrypted with the receiver's public key. The sequence is as follows:
OpenPGP结合了对称密钥加密和公钥加密来提供机密性。保密时，首先使用对称加密算法对对象进行加密。对于单个对象，每个对称密钥仅使用一次。为每个对象（有时称为会话）生成一个新的“会话密钥”，作为一个随机数。由于只使用一次，会话密钥被绑定到消息并随消息一起传输。为了保护密钥，使用接收方的公钥对其进行加密。顺序如下：
1. The sender creates a message.
1. 发送者创建一条消息。
2. The sending OpenPGP generates a random number to be used as a session key for this message only.
2. 发送OpenPGP生成一个随机数，仅用作此消息的会话密钥。
3. The session key is encrypted using each recipient's public key. These "encrypted session keys" start the message.
3. 会话密钥使用每个收件人的公钥加密。这些“加密会话密钥”启动消息。
4. The sending OpenPGP encrypts the message using the session key, which forms the remainder of the message. Note that the message is also usually compressed.
4. 发送OpenPGP使用会话密钥加密消息，会话密钥构成消息的其余部分。请注意，消息通常也是压缩的。
5. The receiving OpenPGP decrypts the session key using the recipient's private key.
5. 接收OpenPGP使用接收方的私钥解密会话密钥。
6. The receiving OpenPGP decrypts the message using the session key. If the message was compressed, it will be decompressed.
6. 接收OpenPGP使用会话密钥对消息进行解密。如果消息被压缩，它将被解压缩。
With symmetric-key encryption, an object may be encrypted with a symmetric key derived from a passphrase (or other shared secret), or a two-stage mechanism similar to the public-key method described above in which a session key is itself encrypted with a symmetric algorithm keyed from a shared secret.
使用对称密钥加密，可以使用源自密码短语（或其他共享密钥）的对称密钥或类似于上述公钥方法的两阶段机制对对象进行加密，其中会话密钥本身使用来自共享密钥的对称算法进行加密。
Both digital signature and confidentiality services may be applied to the same message. First, a signature is generated for the message and attached to the message. Then the message plus signature is encrypted using a symmetric session key. Finally, the session key is encrypted using public-key encryption and prefixed to the encrypted block.
数字签名和保密服务均可应用于同一电文。首先，为消息生成签名并附加到消息。然后使用对称会话密钥对消息加签名进行加密。最后，使用公钥加密对会话密钥进行加密，并将其作为加密块的前缀。
The digital signature uses a hash code or message digest algorithm, and a public-key signature algorithm. The sequence is as follows:
数字签名使用散列码或消息摘要算法以及公钥签名算法。顺序如下：
1. The sender creates a message.
1. 发送者创建一条消息。
2. The sending software generates a hash code of the message.
2. 发送软件生成消息的哈希代码。
3. The sending software generates a signature from the hash code using the sender's private key.
3. 发送软件使用发送方的私钥从散列码生成签名。
4. The binary signature is attached to the message.
4. 二进制签名附加到消息。
5. The receiving software keeps a copy of the message signature.
5. 接收软件保留消息签名的副本。
6. The receiving software generates a new hash code for the received message and verifies it using the message's signature. If the verification is successful, the message is accepted as authentic.
6. 接收软件为接收到的消息生成一个新的哈希代码，并使用消息的签名对其进行验证。如果验证成功，则消息将被视为真实消息。
OpenPGP implementations SHOULD compress the message after applying the signature but before encryption.
OpenPGP实现应该在应用签名后但在加密之前压缩消息。
If an implementation does not implement compression, its authors should be aware that most OpenPGP messages in the world are compressed. Thus, it may even be wise for a space-constrained implementation to implement decompression, but not compression.
如果一个实现没有实现压缩，那么它的作者应该知道世界上大多数OpenPGP消息都是压缩的。因此，空间受限的实现实现解压而不是压缩可能是明智的。
Furthermore, compression has the added side effect that some types of attacks can be thwarted by the fact that slightly altered, compressed data rarely uncompresses without severe errors. This is hardly rigorous, but it is operationally useful. These attacks can be rigorously prevented by implementing and using Modification Detection Codes as described in sections following.
此外，压缩还有一个附加的副作用，即某些类型的攻击可以通过稍微修改、压缩的数据很少在没有严重错误的情况下解压而被阻止。这很难严格，但在操作上是有用的。通过实施和使用修改检测代码，可以严格防止这些攻击，如以下各节所述。
OpenPGP's underlying native representation for encrypted messages, signature certificates, and keys is a stream of arbitrary octets. Some systems only permit the use of blocks consisting of seven-bit, printable text. For transporting OpenPGP's native raw binary octets through channels that are not safe to raw binary data, a printable encoding of these binary octets is needed. OpenPGP provides the service of converting the raw 8-bit binary octet stream to a stream of printable ASCII characters, called Radix-64 encoding or ASCII Armor.
OpenPGP对加密消息、签名证书和密钥的底层本机表示是任意八位字节流。有些系统只允许使用由七位可打印文本组成的块。为了通过对原始二进制数据不安全的通道传输OpenPGP的原生原始二进制八位字节，需要对这些二进制八位字节进行可打印的编码。OpenPGP提供将原始8位二进制八位字节流转换为可打印ASCII字符流的服务，称为基数64编码或ASCII码。
Implementations SHOULD provide Radix-64 conversions.
实现应该提供基数-64转换。
OpenPGP is designed for applications that use both encryption and signatures, but there are a number of problems that are solved by a signature-only implementation. Although this specification requires both encryption and signatures, it is reasonable for there to be subset implementations that are non-conformant only in that they omit encryption.
OpenPGP是为同时使用加密和签名的应用程序而设计的，但是有许多问题可以通过只使用签名的实现来解决。尽管该规范要求加密和签名，但存在不一致的子集实现是合理的，因为它们省略了加密。
This section describes the data elements used by OpenPGP.
本节介绍OpenPGP使用的数据元素。
Scalar numbers are unsigned and are always stored in big-endian format. Using n[k] to refer to the kth octet being interpreted, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]).
标量数是无符号的，并且始终以大端格式存储。使用n[k]表示被解释的第k个八位元，两个八位元标量的值为（（n[0]<<8）+n[1]）。四个八位组标量的值是（（n[0]<<24）+（n[1]<<16）+（n[2]<<8）+n[3]）。
Multiprecision integers (also called MPIs) are unsigned integers used to hold large integers such as the ones used in cryptographic calculations.
多精度整数（也称为MPI）是无符号整数，用于保存大整数，如加密计算中使用的整数。
An MPI consists of two pieces: a two-octet scalar that is the length of the MPI in bits followed by a string of octets that contain the actual integer.
MPI由两部分组成：两个八位元标量，即MPI的长度（以位为单位），后跟一个包含实际整数的八位元字符串。
These octets form a big-endian number; a big-endian number can be made into an MPI by prefixing it with the appropriate length.
这些八位元组成一个大端数；大端数字可以通过在其前面加上适当长度的前缀而成为MPI。
Examples:
示例：
(all numbers are in hexadecimal)
（所有数字均为十六进制）
The string of octets [00 01 01] forms an MPI with the value 1. The string [00 09 01 FF] forms an MPI with the value of 511.
八位字节字符串[00 01 01]形成值为1的MPI。字符串[00 09 01 FF]形成一个值为511的MPI。
Additional rules:
其他规则：
The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.
MPI的大小为（（MPI.length+7）/8）+2个八位字节。
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 formed correctly. It should be [00 01 01].
MPI的长度字段描述从其最高有效非零位开始的长度。因此，MPI[00 02 01]没有正确形成。它应该是[00 01]。
Unused bits of an MPI MUST be zero.
MPI的未使用位必须为零。
Also note that when an MPI is encrypted, the length refers to the plaintext MPI. It may be ill-formed in its ciphertext.
还请注意，加密MPI时，长度指的是明文MPI。它的密文可能格式不正确。
A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique. The section "Enhanced Key Formats" below describes how Key IDs are formed.
密钥ID是标识密钥的八个八位字节标量。实现不应假定密钥ID是唯一的。下面的“增强型密钥格式”部分描述了密钥ID的形成方式。
Unless otherwise specified, the character set for text is the UTF-8 [RFC3629] encoding of Unicode [ISO10646].
除非另有规定，否则文本的字符集是Unicode[ISO10646]的UTF-8[RFC3629]编码。
A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.
时间字段是一个无符号的四个八位数字，包含自UTC 1970年1月1日午夜以来经过的秒数。
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 may be any suitable database. It is beyond the scope of this standard to discuss the details of keyrings or other databases.
密钥环是文件或数据库中一个或多个密钥的集合。传统上，keyring只是一个连续的密钥列表，但也可以是任何合适的数据库。讨论钥匙圈或其他数据库的细节超出了本标准的范围。
String-to-key (S2K) specifiers are used to convert passphrase strings into symmetric-key encryption/decryption keys. They are used in two places, currently: to encrypt the secret part of private keys in the private keyring, and to convert passphrases to encryption keys for symmetrically encrypted messages.
字符串到密钥（S2K）说明符用于将密码短语字符串转换为对称密钥加密/解密密钥。它们目前用于两个地方：加密私钥环中私钥的秘密部分，以及将密码短语转换为对称加密消息的加密密钥。
There are three types of S2K specifiers currently supported, and some reserved values:
目前支持三种类型的S2K说明符和一些保留值：
ID S2K Type
-- --------
0 Simple S2K
1 Salted S2K
2 Reserved value
3 Iterated and Salted S2K
100 to 110 Private/Experimental S2K
ID S2K Type
-- --------
0 Simple S2K
1 Salted S2K
2 Reserved value
3 Iterated and Salted S2K
100 to 110 Private/Experimental S2K
These are described in Sections 3.7.1.1 - 3.7.1.3.
第3.7.1.1节至第3.7.1.3节对此进行了说明。
This directly hashes the string to produce the key data. See below for how this hashing is done.
这将直接散列字符串以生成密钥数据。请参阅下面的内容，了解如何进行哈希。
Octet 0: 0x00 Octet 1: hash algorithm
八位组0:0x00八位组1:哈希算法
Simple S2K hashes the passphrase to produce the session key. The manner in which this is done depends on the size of the session key (which will depend on the cipher used) and the size of the hash
简单S2K对密码短语进行散列以生成会话密钥。执行此操作的方式取决于会话密钥的大小（这将取决于使用的密码）和散列的大小
algorithm's output. If the hash size is greater than the session key size, the high-order (leftmost) octets of the hash are used as the key.
算法的输出。如果哈希大小大于会话密钥大小，则哈希的高阶（最左侧）八位字节将用作密钥。
If the hash size is less than the key size, multiple instances of the hash context are created -- enough to produce the required key data. These instances are preloaded with 0, 1, 2, ... octets of zeros (that is to say, the first instance has no preloading, the second gets preloaded with 1 octet of zero, the third is preloaded with two octets of zeros, and so forth).
如果哈希大小小于密钥大小，则会创建哈希上下文的多个实例——足以生成所需的密钥数据。用0预加载，这些实例是1。。。八位字节的零（也就是说，第一个实例没有预加载，第二个实例预加载了一个八位字节的零，第三个实例预加载了两个八位字节的零，依此类推）。
As the data is hashed, it is given independently to each hash context. Since the contexts have been initialized differently, they will each produce different hash output. Once the passphrase is hashed, the output data from the multiple hashes is concatenated, first hash leftmost, to produce the key data, with any excess octets on the right discarded.
当数据被散列时，它被独立地提供给每个散列上下文。由于上下文的初始化方式不同，它们将各自生成不同的哈希输出。对密码短语进行散列后，将多个散列的输出数据连接起来，首先是最左边的散列，以生成密钥数据，并丢弃右边多余的八位字节。
This includes a "salt" value in the S2K specifier -- some arbitrary data -- that gets hashed along with the passphrase string, to help prevent dictionary attacks.
这包括S2K说明符中的一个“salt”值——一些任意数据——与密码短语字符串一起散列，以帮助防止字典攻击。
Octet 0: 0x01 Octet 1: hash algorithm Octets 2-9: 8-octet salt value
八位字节0:0x01八位字节1:哈希算法八位字节2-9:8-八位字节盐值
Salted S2K is exactly like Simple S2K, except that the input to the hash function(s) consists of the 8 octets of salt from the S2K specifier, followed by the passphrase.
salteds2k与简单的S2K完全相同，只是散列函数的输入由来自S2K说明符的8个八位组salt组成，后跟密码短语。
This includes both a salt and an octet count. The salt is combined with the passphrase and the resulting value is hashed repeatedly. This further increases the amount of work an attacker must do to try dictionary attacks.
这包括salt和octet计数。salt与密码短语组合，结果值反复散列。这进一步增加了攻击者尝试字典攻击的工作量。
Octet 0: 0x03 Octet 1: hash algorithm Octets 2-9: 8-octet salt value Octet 10: count, a one-octet, coded value
八位字节0:0x03八位字节1:哈希算法八位字节2-9:8-八位字节盐值八位字节10:计数，一个八位字节，编码值
The count is coded into a one-octet number using the following formula:
使用以下公式将计数编码为一个八位字节数：
#define EXPBIAS 6
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
#define EXPBIAS 6
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
The above formula is in C, where "Int32" is a type for a 32-bit integer, and the variable "c" is the coded count, Octet 10.
上面的公式是用C表示的，其中“Int32”是32位整数的类型，变量“C”是编码计数，八位组10。
Iterated-Salted S2K hashes the passphrase and salt data multiple times. The total number of octets to be hashed is specified in the encoded count in the S2K specifier. Note that the resulting count value is an octet count of how many octets will be hashed, not an iteration count.
迭代salteds2k多次散列密码短语和salt数据。要散列的八位字节总数在S2K说明符中的编码计数中指定。请注意，结果计数值是将散列多少个八位字节的八位字节计数，而不是迭代计数。
Initially, one or more hash contexts are set up as with the other S2K algorithms, depending on how many octets of key data are needed. Then the salt, followed by the passphrase data, is repeatedly hashed until the number of octets specified by the octet count has been hashed. The one exception is that if the octet count is less than the size of the salt plus passphrase, the full salt plus passphrase will be hashed even though that is greater than the octet count. After the hashing is done, the data is unloaded from the hash context(s) as with the other S2K algorithms.
最初，与其他S2K算法一样设置一个或多个哈希上下文，具体取决于需要多少个八位字节的关键数据。然后重复散列salt，后跟密码短语数据，直到八位字节计数指定的八位字节数被散列。一个例外是，如果八位字节数小于salt plus密码短语的大小，则将散列完整的salt plus密码短语，即使该值大于八位字节数。散列完成后，与其他S2K算法一样，从散列上下文卸载数据。
Implementations SHOULD use salted or iterated-and-salted S2K specifiers, as simple S2K specifiers are more vulnerable to dictionary attacks.
实现应该使用salted或迭代salted S2K说明符，因为简单的S2K说明符更容易受到字典攻击。
An S2K specifier can be stored in the secret keyring to specify how to convert the passphrase to a key that unlocks the secret data. Older versions of PGP just stored a cipher algorithm octet preceding the secret data or a zero to indicate that the secret data was unencrypted. The MD5 hash function was always used to convert the passphrase to a key for the specified cipher algorithm.
可以在密钥环中存储S2K说明符，以指定如何将密码短语转换为解锁机密数据的密钥。较旧版本的PGP只在机密数据之前存储一个密码算法八位字节，或存储一个零以指示机密数据未加密。MD5哈希函数始终用于将密码短语转换为指定密码算法的密钥。
For compatibility, when an S2K specifier is used, the special value 254 or 255 is stored in the position where the hash algorithm octet would have been in the old data structure. This is then followed immediately by a one-octet algorithm identifier, and then by the S2K specifier as encoded above.
为了兼容性，当使用S2K说明符时，将特殊值254或255存储在哈希算法八位组在旧数据结构中的位置。然后紧接着是一个八位字节算法标识符，然后是如上编码的S2K说明符。
Therefore, preceding the secret data there will be one of these possibilities:
因此，在机密数据之前将存在以下可能性之一：
0: secret data is unencrypted (no passphrase) 255 or 254: followed by algorithm octet and S2K specifier Cipher alg: use Simple S2K algorithm using MD5 hash
0：机密数据未加密（无密码短语）255或254：后跟算法八位字节和S2K说明符密码alg：使用使用MD5哈希的简单S2K算法
This last possibility, the cipher algorithm number with an implicit use of MD5 and IDEA, is provided for backward compatibility; it MAY be understood, but SHOULD NOT be generated, and is deprecated.
最后一种可能性，即隐式使用MD5和IDEA的密码算法编号，用于向后兼容；它可以理解，但不应生成，因此不推荐使用。
These are followed by an Initial Vector of the same length as the block size of the cipher for the decryption of the secret values, if they are encrypted, and then the secret-key values themselves.
然后是一个初始向量，该初始向量的长度与用于解密秘密值（如果加密）的密码的块大小相同，然后是秘密密钥值本身。
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet at the front of a message. This is used to allow S2K specifiers to be used for the passphrase conversion or to create messages with a mix of symmetric-key ESKs and public-key ESKs. This allows a message to be decrypted either with a passphrase or a public-key pair.
OpenPGP可以在消息前面创建对称密钥加密会话密钥（ESK）数据包。这用于允许S2K说明符用于密码短语转换或创建混合使用对称密钥ESK和公钥ESK的消息。这允许使用密码短语或公钥对对消息进行解密。
PGP 2.X always used IDEA with Simple string-to-key conversion when encrypting a message with a symmetric algorithm. This is deprecated, but MAY be used for backward-compatibility.
在使用对称算法加密消息时，PGP2.X始终使用IDEA进行简单的字符串到密钥转换。这已被弃用，但可用于向后兼容。
This section describes the packets used by OpenPGP.
本节介绍OpenPGP使用的数据包。
An OpenPGP message is constructed from a number of records that are traditionally called packets. A packet is a chunk of data that has a tag specifying its meaning. An OpenPGP message, keyring, certificate, and so forth consists of a number of packets. Some of those packets may contain other OpenPGP packets (for example, a compressed data packet, when uncompressed, contains OpenPGP packets).
OpenPGP消息由许多传统上称为数据包的记录构成。数据包是一块数据，它有一个指定其含义的标记。OpenPGP消息、密钥环、证书等由许多数据包组成。其中一些包可能包含其他OpenPGP包（例如，压缩数据包在未压缩时包含OpenPGP包）。
Each packet consists of a packet header, followed by the packet body. The packet header is of variable length.
每个数据包由数据包头和数据包体组成。数据包头的长度可变。
The first octet of the packet header is called the "Packet Tag". It determines the format of the header and denotes the packet contents. The remainder of the packet header is the length of the packet.
包头的第一个八位组称为“包标签”。它确定报头的格式并表示数据包内容。包头的剩余部分是包的长度。
Note that the most significant bit is the leftmost bit, called bit 7. A mask for this bit is 0x80 in hexadecimal.
请注意，最高有效位是最左边的位，称为位7。此位的掩码是十六进制的0x80。
+---------------+
PTag |7 6 5 4 3 2 1 0|
+---------------+
Bit 7 -- Always one
Bit 6 -- New packet format if set
+---------------+
PTag |7 6 5 4 3 2 1 0|
+---------------+
Bit 7 -- Always one
Bit 6 -- New packet format if set
PGP 2.6.x only uses old format packets. Thus, software that interoperates with those versions of PGP must only use old format packets. If interoperability is not an issue, the new packet format is RECOMMENDED. Note that old format packets have four bits of packet tags, and new format packets have six; some features cannot be used and still be backward-compatible.
PGP2.6.x仅使用旧格式数据包。因此，与这些版本的PGP交互的软件必须只使用旧格式的数据包。如果互操作性不是问题，建议使用新的数据包格式。注意，旧格式数据包有四位数据包标签，而新格式数据包有六位标签；某些功能无法使用，并且仍然向后兼容。
Also note that packets with a tag greater than or equal to 16 MUST use new format packets. The old format packets can only express tags less than or equal to 15.
还要注意，标签大于或等于16的数据包必须使用新格式的数据包。旧格式的数据包只能表示小于或等于15的标签。
Old format packets contain:
旧格式数据包包含：
Bits 5-2 -- packet tag Bits 1-0 -- length-type
位5-2——数据包标签位1-0——长度类型
New format packets contain:
新格式数据包包含：
Bits 5-0 -- packet tag
位5-0——数据包标签
The meaning of the length-type in old format packets is:
旧格式数据包中长度类型的含义为：
0 - The packet has a one-octet length. The header is 2 octets long.
0-数据包的长度为一个八位字节。报头有2个八位字节长。
1 - The packet has a two-octet length. The header is 3 octets long.
1-数据包有两个八位组长度。报头有3个八位字节长。
2 - The packet has a four-octet length. The header is 5 octets long.
2-数据包的长度为四个八位组。标题长度为5个八位字节。
3 - The packet is of indeterminate length. The header is 1 octet long, and the implementation must determine how long the packet is. If the packet is in a file, this means that the packet extends until the end of the file. In general, an implementation SHOULD NOT use indeterminate-length packets except where the end of the data will be clear from the context, and even then it is better to use a definite length, or a new format header. The new format headers described below have a mechanism for precisely encoding data of indeterminate length.
3-数据包的长度不确定。报头长度为1个八位字节，实现必须确定数据包的长度。如果数据包在文件中，这意味着数据包将一直扩展到文件的末尾。一般来说，一个实现不应该使用不确定长度的数据包，除非数据的结尾可以从上下文中清除，甚至最好使用一个确定的长度或一个新的格式头。下面描述的新格式头具有精确编码不确定长度数据的机制。
New format packets have four possible ways of encoding length:
新格式数据包有四种可能的长度编码方式：
1. A one-octet Body Length header encodes packet lengths of up to 191 octets.
1. 一个八位字节体长的报头编码最多191个八位字节的数据包长度。
2. A two-octet Body Length header encodes packet lengths of 192 to 8383 octets.
2. 两个八位字节的正文长度报头编码192到8383个八位字节的数据包长度。
3. A five-octet Body Length header encodes packet lengths of up to 4,294,967,295 (0xFFFFFFFF) octets in length. (This actually encodes a four-octet scalar number.)
3. 五个八位字节的正文长度报头编码的数据包长度最多为4294967295（0xFFFFFF）个八位字节。（这实际上编码了一个四个八位组的标量数。）
4. When the length of the packet body is not known in advance by the issuer, Partial Body Length headers encode a packet of indeterminate length, effectively making it a stream.
4. 当发卡机构事先不知道包体的长度时，部分包体长度报头对长度不确定的包进行编码，有效地使其成为流。
A one-octet Body Length header encodes a length of 0 to 191 octets. This type of length header is recognized because the one octet value is less than 192. The body length is equal to:
一个八位字节体长报头编码0到191个八位字节的长度。由于一个八位字节的值小于192，因此可以识别这种类型的长度标头。主体长度等于：
bodyLen = 1st_octet;
bodyLen=第一个八位组；
A two-octet Body Length header encodes a length of 192 to 8383 octets. It is recognized because its first octet is in the range 192 to 223. The body length is equal to:
两个八位字节的正文长度报头编码192到8383个八位字节的长度。它被识别是因为它的第一个八位组在192到223之间。主体长度等于：
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
A five-octet Body Length header consists of a single octet holding the value 255, followed by a four-octet scalar. The body length is equal to:
五个八位字节的正文长度标头由一个包含值255的八位字节组成，后跟一个四个八位字节的标量。主体长度等于：
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet
This basic set of one, two, and five-octet lengths is also used internally to some packets.
这个包含一个、两个和五个八位组长度的基本集合也在某些数据包内部使用。
A Partial Body Length header is one octet long and encodes the length of only part of the data packet. This length is a power of 2, from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by its one octet value that is greater than or equal to 224, and less than 255. The Partial Body Length is equal to:
部分正文长度报头是一个八位字节长，只编码数据包的一部分长度。该长度是2的幂，从1到1073741824（2到30次方）。它通过大于或等于224且小于255的一个八位组值来识别。部分主体长度等于：
partialBodyLen = 1 << (1st_octet & 0x1F);
partialBodyLen = 1 << (1st_octet & 0x1F);
Each Partial Body Length header is followed by a portion of the packet body data. The Partial Body Length header specifies this portion's length. Another length header (one octet, two-octet, five-octet, or partial) follows that portion. The last length header in the packet MUST NOT be a Partial Body Length header. Partial Body Length headers may only be used for the non-final parts of the packet.
每个部分正文长度报头后面跟着一部分包正文数据。“部分正文长度”标题指定此部分的长度。另一个长度头（一个八位组、两个八位组、五个八位组或部分）跟随该部分。数据包中的最后一个长度头不能是部分正文长度头。部分正文长度标头只能用于数据包的非最终部分。
Note also that the last Body Length header can be a zero-length header.
还请注意，最后一个正文长度标头可以是零长度标头。
An implementation MAY use Partial Body Lengths for data packets, be they literal, compressed, or encrypted. The first partial length MUST be at least 512 octets long. Partial Body Lengths MUST NOT be used for any other packet types.
一个实现可以对数据包使用部分正文长度，无论是文字、压缩还是加密。第一部分长度必须至少为512个八位字节。部分正文长度不得用于任何其他数据包类型。
These examples show ways that new format packets might encode the packet lengths.
这些示例显示了新格式数据包可能对数据包长度进行编码的方式。
A packet with length 100 may have its length encoded in one octet: 0x64. This is followed by 100 octets of data.
长度为100的数据包可以将其长度编码为一个八位字节：0x64。然后是100个八位字节的数据。
A packet with length 1723 may have its length encoded in two octets: 0xC5, 0xFB. This header is followed by the 1723 octets of data.
长度为1723的数据包可以将其长度编码为两个八位字节：0xC5、0xFB。此标头后面是1723个八位字节的数据。
A packet with length 100000 may have its length encoded in five octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.
长度为100000的数据包可以将其长度编码为五个八位字节：0xFF、0x00、0x01、0x86、0xA0。
It might also be encoded in the following octet stream: 0xEF, first 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693 octets of data. This is just one possible encoding, and many variations are possible on the size of the Partial Body Length headers, as long as a regular Body Length header encodes the last portion of the data.
它也可能被编码在以下八位字节流中：0xEF，数据的前32768个八位字节；0xE1，下两个八位字节的数据；0xE0，数据的下一个八位字节；0xF0，下一个65536个八位字节的数据；0xC5，0xDD，最后1693个八位字节的数据。这只是一种可能的编码，部分正文长度头的大小可能有许多变化，只要常规正文长度头编码数据的最后一部分。
Please note that in all of these explanations, the total length of the packet is the length of the header(s) plus the length of the body.
请注意，在所有这些解释中，数据包的总长度是报头的长度加上正文的长度。
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 format headers can have tags as great as 63. The defined tags (in decimal) are as follows:
packet标签表示主体持有的数据包类型。请注意，旧格式标头只能包含小于16的标记，而新格式标头可以包含多达63的标记。定义的标记（十进制）如下所示：
0 -- Reserved - a packet tag MUST NOT have this value 1 -- Public-Key Encrypted Session Key Packet 2 -- Signature Packet 3 -- Symmetric-Key Encrypted Session Key Packet 4 -- One-Pass Signature Packet 5 -- Secret-Key Packet 6 -- Public-Key Packet 7 -- Secret-Subkey Packet 8 -- Compressed Data Packet 9 -- Symmetrically Encrypted Data Packet 10 -- Marker Packet 11 -- Literal Data Packet 12 -- Trust Packet 13 -- User ID Packet 14 -- Public-Subkey Packet 17 -- User Attribute Packet 18 -- Sym. Encrypted and Integrity Protected Data Packet 19 -- Modification Detection Code Packet 60 to 63 -- Private or Experimental Values
0—保留—数据包标签不得具有此值1—公钥加密会话密钥数据包2—签名数据包3—对称密钥加密会话密钥数据包4—一次性签名数据包5—密钥数据包6—公钥数据包7—秘密子密钥数据包8—压缩数据包9—对称加密数据包10--标记包11——文字数据包12——信任包13——用户ID包14——公钥包17——用户属性包18——Sym。加密和完整性保护数据包19——修改检测代码包60至63——私有值或实验值
A Public-Key Encrypted Session Key packet holds the session key used to encrypt a message. Zero or more Public-Key Encrypted Session Key packets and/or Symmetric-Key Encrypted Session Key packets may precede a Symmetrically Encrypted Data Packet, which holds an encrypted message. The message is encrypted with the session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s). The Symmetrically Encrypted Data Packet is preceded by one Public-Key Encrypted Session Key packet for each OpenPGP key to which the message is encrypted. The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message.
公钥加密的会话密钥包包含用于加密消息的会话密钥。零个或多个公钥加密的会话密钥分组和/或对称密钥加密的会话密钥分组可以位于对称加密的数据分组之前，该数据分组保存加密消息。消息使用会话密钥加密，会话密钥本身加密并存储在加密的会话密钥包中。对称加密的数据包前面是一个公钥加密的会话密钥包，用于加密消息的每个OpenPGP密钥。消息的接收者找到一个会话密钥，该密钥加密为其公钥，解密会话密钥，然后使用会话密钥解密消息。
The body of this packet consists of:
本文件包正文包括：
- A one-octet number giving the version number of the packet type. The currently defined value for packet version is 3.
- 给出数据包类型版本号的一个八位字节数。数据包版本的当前定义值为3。
- An eight-octet number that gives the Key ID of the public key to which the session key is encrypted. If the session key is encrypted to a subkey, then the Key ID of this subkey is used here instead of the Key ID of the primary key.
- 一个八位字节的数字，给出会话密钥加密到的公钥的密钥ID。如果会话密钥加密为子密钥，则此处使用该子密钥的密钥ID，而不是主键的密钥ID。
- A one-octet number giving the public-key algorithm used.
- 给出所用公钥算法的一个八位组数。
- A string of octets that is the encrypted session key. This string takes up the remainder of the packet, and its contents are dependent on the public-key algorithm used.
- 作为加密会话密钥的八位字节字符串。此字符串占用数据包的其余部分，其内容取决于所使用的公钥算法。
Algorithm Specific Fields for RSA encryption
RSA加密的算法特定字段
- multiprecision integer (MPI) of RSA encrypted value m**e mod n.
- RSA加密值m**e mod n的多精度整数（MPI）。
Algorithm Specific Fields for Elgamal encryption:
Elgamal加密的算法特定字段：
- MPI of Elgamal (Diffie-Hellman) value g**k mod p.
- Elgamal（Diffie-Hellman）值g**k mod p的MPI。
- MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
- Elgamal（Diffie Hellman）值m*y**k mod p的MPI。
The value "m" in the above formulas is derived from the session key as follows. First, the session key is prefixed with a one-octet algorithm identifier that specifies the symmetric encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet. Then a two-octet checksum is appended, which is equal to the sum of the preceding session key octets, not including the algorithm identifier, modulo 65536. This value is then encoded as described in PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to form the "m" value used in the formulas above. See Section 13.1 of this document for notes on OpenPGP's use of PKCS#1.
上述公式中的值“m”是从会话密钥中导出的，如下所示。首先，会话密钥以一个八位组算法标识符作为前缀，该标识符指定用于加密以下对称加密数据包的对称加密算法。然后附加两个八位校验和，其等于前面会话密钥八位校验和，不包括算法标识符，模65536。然后按照[RFC3447]第7.2.1节PKCS#1块编码EME-PKCS1-v1_5中的说明对该值进行编码，以形成上述公式中使用的“m”值。有关OpenPGP使用PKCS#1的说明，请参见本文档第13.1节。
Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation MUST make a new PKCS#1 encoding for each key.
请注意，当一个实现使用一个会话密钥形成多个PKESK，形成一条可由多个密钥解密的消息时，该实现必须为每个密钥进行新的PKCS#1编码。
An implementation MAY accept or use a Key ID of zero as a "wild card" or "speculative" Key ID. In this case, the receiving implementation would try all available private keys, checking for a valid decrypted session key. This format helps reduce traffic analysis of messages.
实现可以接受或使用零的密钥ID作为“通配符”或“推测性”密钥ID。在这种情况下，接收实现将尝试所有可用的私钥，检查有效的解密会话密钥。这种格式有助于减少对消息的流量分析。
A Signature packet describes a binding between some public key and some data. The most common signatures are a signature of a file or a block of text, and a signature that is a certification of a User ID.
签名包描述某些公钥和某些数据之间的绑定。最常见的签名是文件或文本块的签名，以及用户ID的认证签名。
Two versions of Signature packets are defined. Version 3 provides basic signature information, while version 4 provides an expandable format with subpackets that can specify more information about the signature. PGP 2.6.x only accepts version 3 signatures.
定义了两个版本的签名包。版本3提供了基本的签名信息，而版本4提供了一种可扩展的格式，其子包可以指定有关签名的更多信息。PGP2.6.x仅接受版本3签名。
Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures.
实现应该接受V3签名。实现应该生成V4签名。
Note that if an implementation is creating an encrypted and signed message that is encrypted to a V3 key, it is reasonable to create a V3 signature.
请注意，如果一个实现正在创建加密并签名为V3密钥的消息，那么创建V3签名是合理的。
There are a number of possible meanings for a signature, which are indicated in a signature type octet in any given signature. Please note that the vagueness of these meanings is not a flaw, but a feature of the system. Because OpenPGP places final authority for validity upon the receiver of a signature, it may be that one signer's casual act might be more rigorous than some other authority's positive act. See Section 5.2.4, "Computing Signatures", for detailed information on how to compute and verify signatures of each type.
签名有许多可能的含义，这些含义在任何给定签名的签名类型八位字节中表示。请注意，这些含义的模糊不是一个缺陷，而是系统的一个特征。由于OpenPGP将有效性的最终授权放在签名接收者身上，因此一个签名者的随意行为可能比其他权威的积极行为更为严格。有关如何计算和验证每种类型的签名的详细信息，请参见第5.2.4节“计算签名”。
These meanings are as follows:
这些含义如下：
0x00: Signature of a binary document. This means the signer owns it, created it, or certifies that it has not been modified.
0x00：二进制文档的签名。这意味着签名者拥有、创建或证明其未被修改。
0x01: Signature of a canonical text document. This means the signer owns it, created it, or certifies that it has not been modified. The signature is calculated over the text data with its line endings converted to <CR><LF>.
0x01:规范文本文档的签名。这意味着签名者拥有、创建或证明其未被修改。签名在文本数据上计算，其行尾转换为<CR><LF>。
0x02: Standalone signature. This signature is a signature of only its own subpacket contents. It is calculated identically to a signature over a zero-length binary document. Note that it doesn't make sense to have a V3 standalone signature.
0x02：独立签名。此签名仅是其自身子包内容的签名。它的计算方法与零长度二进制文档上的签名相同。请注意，使用V3独立签名是没有意义的。
0x10: Generic certification of a User ID and Public-Key packet. The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the User ID.
0x10：用户ID和公钥数据包的通用认证。本证书的颁发者未就认证者检查密钥所有者是否为用户ID所描述的人的情况做出任何特定断言。
0x11: Persona certification of a User ID and Public-Key packet. The issuer of this certification has not done any verification of the claim that the owner of this key is the User ID specified.
0x11：用户ID和公钥数据包的角色认证。此证书的颁发者尚未对该密钥的所有者是指定用户ID的声明进行任何验证。
0x12: Casual certification of a User ID and Public-Key packet. The issuer of this certification has done some casual verification of the claim of identity.
0x12：用户ID和公钥数据包的临时认证。本证书的颁发者对身份声明进行了一些偶然的验证。
0x13: Positive certification of a User ID and Public-Key packet. The issuer of this certification has done substantial verification of the claim of identity.
0x13：用户ID和公钥数据包的肯定认证。本证书的颁发者已对身份声明进行了实质性验证。
Most OpenPGP implementations make their "key signatures" as 0x10 certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types.
大多数OpenPGP实现将其“密钥签名”作为0x10认证。一些实现可以发布0x11-0x13证书，但很少区分这些类型。
0x18: Subkey Binding Signature This signature is a statement by the top-level signing key that indicates that it owns the subkey. This signature is calculated directly on the primary key and subkey, and not on any User ID or other packets. A signature that binds a signing subkey MUST have an Embedded Signature subpacket in this binding signature that contains a 0x19 signature made by the signing subkey on the primary key and subkey.
0x18:子密钥绑定签名此签名是顶级签名密钥的语句，表示它拥有子密钥。此签名直接在主键和子键上计算，而不是在任何用户ID或其他数据包上计算。绑定签名子项的签名必须在此绑定签名中具有嵌入的签名子包，该签名包含签名子项在主键和子键上生成的0x19签名。
0x19: Primary Key Binding Signature This signature is a statement by a signing subkey, indicating that it is owned by the primary key and subkey. This signature is calculated the same way as a 0x18 signature: directly on the primary key and subkey, and not on any User ID or other packets.
0x19:主键绑定签名此签名是由签名子键生成的语句，表示它属于主键和子键。此签名的计算方式与0x18签名相同：直接在主键和子键上，而不是在任何用户ID或其他数据包上。
0x1F: Signature directly on a key This signature is calculated directly on a key. It binds the information in the Signature subpackets to the key, and is appropriate to be used for subpackets that provide information about the key, such as the Revocation Key subpacket. It is also appropriate for statements that non-self certifiers want to make about the key itself, rather than the binding between a key and a name.
0x1F:直接在密钥上签名此签名直接在密钥上计算。它将签名子包中的信息绑定到密钥，并且适合用于提供密钥信息的子包，例如吊销密钥子包。它也适用于非自证明者希望对密钥本身而不是密钥和名称之间的绑定做出的声明。
0x20: Key revocation signature The signature is calculated directly on the key being revoked. A revoked key is not to be used. Only revocation signatures by the key being revoked, or by an authorized revocation key, should be considered valid revocation signatures.
0x20：密钥撤销签名签名直接在被撤销的密钥上计算签名。不能使用已吊销的密钥。只有被撤销密钥或授权撤销密钥的撤销签名才应被视为有效的撤销签名。
0x28: Subkey revocation signature The signature is calculated directly on the subkey being revoked. A revoked subkey is not to be used. Only revocation signatures by the top-level signature key that is bound to this subkey, or by an authorized revocation key, should be considered valid revocation signatures.
0x28：子密钥撤销签名签名直接在被撤销的子密钥上计算签名。不能使用已撤销的子项。只有由绑定到此子密钥的顶级签名密钥或由授权的吊销密钥生成的吊销签名才应被视为有效的吊销签名。
0x30: Certification revocation signature This signature revokes an earlier User ID certification signature (signature class 0x10 through 0x13) or direct-key signature (0x1F). It should be issued by the same key that issued the revoked signature or an authorized revocation key. The signature is computed over the same data as the certificate that it revokes, and should have a later creation date than that certificate.
0x30：证书撤销签名此签名撤销早期用户ID证书签名（签名类0x10到0x13）或直接密钥签名（0x1F）。它应该由发布已撤销签名的同一密钥或授权的撤销密钥发布。签名是在与其撤销的证书相同的数据上计算的，其创建日期应晚于该证书。
0x40: Timestamp signature. This signature is only meaningful for the timestamp contained in it.
0x40：时间戳签名。此签名仅对其中包含的时间戳有意义。
0x50: Third-Party Confirmation signature. This signature is a signature over some other OpenPGP Signature packet(s). It is analogous to a notary seal on the signed data. A third-party signature SHOULD include Signature Target subpacket(s) to give easy identification. Note that we really do mean SHOULD. There are plausible uses for this (such as a blind party that only sees the signature, not the key or source document) that cannot include a target subpacket.
0x50：第三方确认签名。此签名是一些其他OpenPGP签名包上的签名。它类似于签名数据上的公证印章。第三方签名应包括签名目标子包，以便于识别。请注意，我们的真正意思是应该。这有一些看似合理的用途（例如盲方只看到签名，而不看到密钥或源文档），但不能包括目标子包。
The body of a version 3 Signature Packet contains:
版本3签名包的正文包含：
- One-octet version number (3).
- 一个八位组版本号（3）。
- One-octet length of following hashed material. MUST be 5.
- 以下哈希材料的一个八位字节长度。必须是5岁。
- One-octet signature type.
- 一个八位组签名类型。
- Four-octet creation time.
- 四个八位组的创建时间。
- Eight-octet Key ID of signer.
- 签名者的八个八位组密钥ID。
- One-octet public-key algorithm.
- 一个八位组公钥算法。
- One-octet hash algorithm.
- 一个八位组哈希算法。
- Two-octet field holding left 16 bits of signed hash value.
- 两个八位字节字段，保存有符号哈希值的左16位。
- One or more multiprecision integers comprising the signature. This portion is algorithm specific, as described below.
- 包含签名的一个或多个多精度整数。这一部分是特定于算法的，如下所述。
The concatenation of the data to be signed, the signature type, and creation time from the Signature packet (5 additional octets) is hashed. The resulting hash value is used in the signature algorithm. The high 16 bits (first two octets) of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures.
将要签名的数据、签名类型和来自签名包的创建时间（5个额外的八位字节）的串联进行散列。生成的哈希值用于签名算法。哈希的高16位（前两个八位字节）包含在签名包中，以提供拒绝某些无效签名的快速测试。
Algorithm-Specific Fields for RSA signatures:
RSA签名的算法特定字段：
- multiprecision integer (MPI) of RSA signature value m**d mod n.
- RSA签名值m**d mod n的多精度整数（MPI）。
Algorithm-Specific Fields for DSA signatures:
DSA签名的算法特定字段：
- MPI of DSA value r.
- DSA值r的MPI。
- MPI of DSA value s.
- DSA值的MPI。
The signature calculation is based on a hash of the signed data, as described above. The details of the calculation are different for DSA signatures than for RSA signatures.
如上所述，签名计算基于签名数据的散列。DSA签名的计算细节与RSA签名的计算细节不同。
With RSA signatures, the hash value is encoded using PKCS#1 encoding type EMSA-PKCS1-v1_5 as described in Section 9.2 of RFC 3447. This requires inserting the hash value as an octet string into an ASN.1 structure. The object identifier for the type of hash being used is included in the structure. The hexadecimal representations for the currently defined hash algorithms are as follows:
对于RSA签名，哈希值使用PKCS#1编码类型EMSA-PKCS1-v1_5进行编码，如RFC 3447第9.2节所述。这需要将哈希值作为八位字节字符串插入ASN.1结构中。正在使用的哈希类型的对象标识符包含在结构中。当前定义的哈希算法的十六进制表示如下：
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- MD5:0x2A、0x86、0x48、0x86、0xF7、0x0D、0x02、0x05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- RIPEMD-160:0x2B、0x24、0x03、0x02、0x01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
- SHA-1:0x2B、0x0E、0x03、0x02、0x1A
- SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04
- SHA224:0x60、0x86、0x48、0x01、0x65、0x03、0x04、0x02、0x04
- SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
- SHA256:0x60、0x86、0x48、0x01、0x65、0x03、0x04、0x02、0x01
- SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
- SHA384:0x60、0x86、0x48、0x01、0x65、0x03、0x04、0x02、0x02
- SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
- SHA512:0x60、0x86、0x48、0x01、0x65、0x03、0x04、0x02、0x03
The ASN.1 Object Identifiers (OIDs) are as follows:
ASN.1对象标识符（OID）如下所示：
- MD5: 1.2.840.113549.2.5
- MD5:1.2.840.113549.2.5
- RIPEMD-160: 1.3.36.3.2.1
- RIPEMD-160:1.3.36.3.2.1
- SHA-1: 1.3.14.3.2.26
- SHA-1:1.3.14.3.2.26
- SHA224: 2.16.840.1.101.3.4.2.4
- SHA224:2.16.840.1.101.3.4.2.4
- SHA256: 2.16.840.1.101.3.4.2.1
- SHA256:2.16.840.1.101.3.4.2.1
- SHA384: 2.16.840.1.101.3.4.2.2
- SHA384:2.16.840.1.101.3.4.2.2
- SHA512: 2.16.840.1.101.3.4.2.3
- SHA512:2.16.840.1.101.3.4.2.3
The full hash prefixes for these are as follows:
这些文件的完整哈希前缀如下所示：
MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x04, 0x10
MD5:0x30、0x20、0x30、0x0C、0x06、0x08、0x2A、0x86、0x48、0x86、0xF7、0x0D、0x02、0x05、0x05、0x00、0x04、0x10
RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
RIPEMD-160:0x30、0x21、0x30、0x09、0x06、0x05、0x2B、0x24、0x03、0x02、0x01、0x05、0x00、0x04、0x14
SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
SHA-1:0x30、0x21、0x30、0x09、0x06、0x05、0x2b、0x0E、0x03、0x02、0x1A、0x05、0x00、0x04、0x14
SHA224: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C
SHA224:0x30、0x31、0x30、0x0d、0x06、0x09、0x60、0x86、0x48、0x01、0x65、0x03、0x04、0x02、0x04、0x05、0x00、0x04、0x1C
SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20
SHA256:0x30、0x31、0x30、0x0d、0x06、0x09、0x60、0x86、0x48、0x01、0x65、0x03、0x04、0x02、0x01、0x05、0x00、0x04、0x20
SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30
SHA384:0x30、0x41、0x30、0x0d、0x06、0x09、0x60、0x86、0x48、0x01、0x65、0x03、0x04、0x02、0x02、0x05、0x00、0x04、0x30
SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40
SHA512:0x30、0x51、0x30、0x0d、0x06、0x09、0x60、0x86、0x48、0x01、0x65、0x03、0x04、0x02、0x03、0x05、0x00、0x04、0x40
DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value.
DSA签名必须使用大小等于q（由DSA密钥的生成器值生成的组）位数的散列。
If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm.
如果所选散列的输出大小大于q的位数，则通过将最左边的位数等于q的位数来截断散列结果。这个（可能被截断的）散列函数结果被视为一个数字，并直接用于DSA签名算法。
The body of a version 4 Signature packet contains:
版本4签名包的正文包含：
- One-octet version number (4).
- 一个八位组版本号（4）。
- One-octet signature type.
- 一个八位组签名类型。
- One-octet public-key algorithm.
- 一个八位组公钥算法。
- One-octet hash algorithm.
- 一个八位组哈希算法。
- Two-octet scalar octet count for following hashed subpacket data. Note that this is the length in octets of all of the hashed subpackets; a pointer incremented by this number will skip over the hashed subpackets.
- 以下散列子包数据的两个八位字节标量八位字节计数。注意，这是所有散列子包的长度（以八位字节为单位）；按此数字递增的指针将跳过散列子包。
- Hashed subpacket data set (zero or more subpackets).
- 散列子包数据集（零个或多个子包）。
- Two-octet scalar octet count for the following unhashed subpacket data. Note that this is the length in octets of all of the unhashed subpackets; a pointer incremented by this number will skip over the unhashed subpackets.
- 以下未清除的子包数据的两个八位字节标量八位字节计数。请注意，这是所有未删除子包的长度（以八位字节为单位）；按此数字递增的指针将跳过未删除的子包。
- Unhashed subpacket data set (zero or more subpackets).
- 未删除的子包数据集（零个或多个子包）。
- Two-octet field holding the left 16 bits of the signed hash value.
- 两个八位组字段，保存有符号散列值的左16位。
- One or more multiprecision integers comprising the signature. This portion is algorithm specific, as described above.
- 包含签名的一个或多个多精度整数。如上所述，这一部分是特定于算法的。
The concatenation of the data being signed and the signature data from the version number through the hashed subpacket data (inclusive) is hashed. The resulting hash value is what is signed. The left 16 bits of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures.
将要签名的数据与版本号中的签名数据通过散列子包数据（包括）的连接进行散列。得到的哈希值是有符号的。散列的左16位包含在签名包中，以提供拒绝某些无效签名的快速测试。
There are two fields consisting of Signature subpackets. The first field is hashed with the rest of the signature data, while the second is unhashed. The second set of subpackets is not cryptographically
有两个字段由签名子包组成。第一个字段与其余签名数据进行散列，而第二个字段不进行散列。第二组子包不是加密的
protected by the signature and should include only advisory information.
受签名保护，仅应包括咨询信息。
The algorithms for converting the hash function result to a signature are described in a section below.
将哈希函数结果转换为签名的算法在下面的一节中描述。
A subpacket data set consists of zero or more Signature subpackets. In Signature packets, the subpacket data set is preceded by a two-octet scalar count of the length in octets of all the subpackets. A pointer incremented by this number will skip over the subpacket data set.
子包数据集由零个或多个签名子包组成。在签名包中，子包数据集前面是所有子包的长度（以八位字节为单位）的两个八位字节标量计数。按此数字递增的指针将跳过子包数据集。
Each subpacket consists of a subpacket header and a body. The header consists of:
每个子包由一个子包头和一个子包体组成。标题包括：
- the subpacket length (1, 2, or 5 octets),
- 子包长度（1、2或5个八位字节），
- the subpacket type (1 octet),
- 子包类型（1个八位组），
and is followed by the subpacket-specific data.
然后是子包特定的数据。
The length includes the type octet but not this length. Its format is similar to the "new" format packet header lengths, but cannot have Partial Body Lengths. That is:
长度包括八位字节类型，但不包括此长度。其格式类似于“新”格式的数据包头长度，但不能有部分正文长度。即:
if the 1st octet < 192, then lengthOfLength = 1 subpacketLen = 1st_octet
如果第一个八位组<192，则LengthFlength=1子包长度=第一个八位组
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then
lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet]
if the 1st octet = 255, then
lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet]
The value of the subpacket type octet may be:
子包类型八位字节的值可以是：
0 = Reserved 1 = Reserved 2 = Signature Creation Time 3 = Signature Expiration Time 4 = Exportable Certification 5 = Trust Signature 6 = Regular Expression
0=保留1=保留2=签名创建时间3=签名过期时间4=可导出证书5=信任签名6=正则表达式
7 = Revocable 8 = Reserved 9 = Key Expiration Time 10 = Placeholder for backward compatibility 11 = Preferred Symmetric Algorithms 12 = Revocation Key 13 = Reserved 14 = Reserved 15 = Reserved 16 = Issuer 17 = Reserved 18 = Reserved 19 = Reserved 20 = Notation Data 21 = Preferred Hash Algorithms 22 = Preferred Compression Algorithms 23 = Key Server Preferences 24 = Preferred Key Server 25 = Primary User ID 26 = Policy URI 27 = Key Flags 28 = Signer's User ID 29 = Reason for Revocation 30 = Features 31 = Signature Target 32 = Embedded Signature 100 To 110 = Private or experimental
7=可撤销8=保留9=密钥过期时间10=向后兼容性占位符11=首选对称算法12=撤销密钥13=保留14=保留15=保留16=颁发者17=保留18=保留19=保留20=表示法数据21=首选哈希算法22=首选压缩算法23=密钥服务器首选项24=首选密钥服务器25=主用户ID 26=策略URI 27=密钥标志28=签名者的用户ID 29=撤销原因30=功能31=签名目标32=嵌入签名100到110=私有或实验
An implementation SHOULD ignore any subpacket of a type that it does not recognize.
实现应该忽略它无法识别的任何类型的子包。
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 of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error.
子包类型的第7位为“关键”位。如果设置，则表示子包对于签名的计算器识别至关重要。如果遇到一个被标记为关键但对评估软件未知的子分组，则评估者应考虑签名错误。
An evaluator may "recognize" a subpacket, but not implement it. The purpose of the critical bit is to allow the signer to tell an evaluator that it would prefer a new, unknown feature to generate an error than be ignored.
评估者可以“识别”子包，但不能实现它。关键位的目的是允许签名者告诉评估者，它更希望一个新的未知特征生成错误，而不是被忽略。
Implementations SHOULD implement the three preferred algorithm subpackets (11, 21, and 22), as well as the "Reason for Revocation" subpacket. Note, however, that if an implementation chooses not to implement some of the preferences, it is required to behave in a polite manner to respect the wishes of those users who do implement these preferences.
实现应该实现三个首选算法子包（11、21和22），以及“撤销原因”子包。但是，请注意，如果实现选择不实现某些首选项，则需要以礼貌的方式行事，以尊重实现这些首选项的用户的意愿。
A number of subpackets are currently defined. Some subpackets apply to the signature itself and some are attributes of the key. Subpackets that are found on a self-signature are placed on a certification made by the key itself. Note that a key may have more than one User ID, and thus may have more than one self-signature, and differing subpackets.
目前定义了许多子包。有些子包应用于签名本身，有些是密钥的属性。在自签名上找到的子包被放置在由密钥本身生成的证书上。请注意，密钥可能有多个用户ID，因此可能有多个自签名和不同的子包。
A subpacket may be found either in the hashed or unhashed subpacket sections of a signature. If a subpacket is not hashed, then the information in it cannot be considered definitive because it is not part of the signature proper.
可以在签名的哈希或未哈希子包部分中找到子包。如果子包没有散列，那么其中的信息就不能被认为是确定的，因为它不是签名本身的一部分。
A self-signature is a binding signature made by the key to which the signature refers. There are three types of self-signatures, the certification signatures (types 0x10-0x13), the direct-key signature (type 0x1F), and the subkey binding signature (type 0x18). For certification self-signatures, each User ID may have a self-signature, and thus different subpackets in those self-signatures. For subkey binding signatures, each subkey in fact has a self-signature. Subpackets that appear in a certification self-signature apply to the user name, and subpackets that appear in the subkey self-signature apply to the subkey. Lastly, subpackets on the direct-key signature apply to the entire key.
自签名是由签名所引用的密钥生成的具有约束力的签名。有三种类型的自签名：证书签名（类型0x10-0x13）、直接密钥签名（类型0x1F）和子密钥绑定签名（类型0x18）。对于认证自签名，每个用户ID可能有一个自签名，因此这些自签名中有不同的子包。对于子密钥绑定签名，每个子密钥实际上都有一个自签名。出现在证书自签名中的子包应用于用户名，而出现在子密钥自签名中的子包应用于子密钥。最后，直接密钥签名上的子包应用于整个密钥。
Implementing software should interpret a self-signature's preference subpackets as narrowly as possible. For example, suppose a key has two user names, Alice and Bob. Suppose that Alice prefers the symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the software locates this key via Alice's name, then the preferred algorithm is CAST5; if software locates the key via Bob's name, then the preferred algorithm is IDEA. If the key is located by Key ID, the algorithm of the primary User ID of the key provides the preferred symmetric algorithm.
实现软件应该尽可能狭隘地解释自签名的偏好子包。例如，假设一个键有两个用户名，Alice和Bob。假设Alice更喜欢对称算法CAST5，Bob更喜欢IDEA或TripleDES。如果软件通过Alice的名字找到该密钥，则首选算法为CAST5；如果软件通过Bob的名字来定位密钥，那么首选的算法是IDEA。如果密钥由密钥ID定位，则密钥的主用户ID的算法提供首选对称算法。
Revoking a self-signature or allowing it to expire has a semantic meaning that varies with the signature type. Revoking the self-signature on a User ID effectively retires that user name. The self-signature is a statement, "My name X is tied to my signing key K" and is corroborated by other users' certifications. If another user revokes their certification, they are effectively saying that they no longer believe that name and that key are tied together. Similarly, if the users themselves revoke their self-signature, then the users no longer go by that name, no longer have that email address, etc. Revoking a binding signature effectively retires that
撤销自签名或允许其过期具有随签名类型而变化的语义含义。撤销用户ID上的自签名实际上会使该用户名失效。自我签名是一种声明，“我的名字X与我的签名密钥K相关联”，并由其他用户的认证予以证实。如果另一个用户撤销了他们的认证，他们实际上是在说他们不再相信该名称和该密钥是绑定在一起的。类似地，如果用户自己撤销自己的签名，那么用户就不再使用该名称，不再拥有该电子邮件地址等。撤销绑定签名实际上会使其失效
subkey. Revoking a direct-key signature cancels that signature. Please see the "Reason for Revocation" subpacket (Section 5.2.3.23) for more relevant detail.
子键。撤销直接密钥签名将取消该签名。请参阅“撤销原因”子包（第5.2.3.23节）了解更多相关详情。
Since a self-signature contains important information about the key's use, an implementation SHOULD allow the user to rewrite the self-signature, and important information in it, such as preferences and key expiration.
由于自签名包含有关密钥使用的重要信息，因此实现应允许用户重写自签名以及其中的重要信息，如首选项和密钥过期。
It is good practice to verify that a self-signature imported into an implementation doesn't advertise features that the implementation doesn't support, rewriting the signature as appropriate.
验证导入到实现中的自签名不会公布该实现不支持的特性是一种很好的做法，并根据需要重写签名。
An implementation that encounters multiple self-signatures on the same object may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the most recent self-signature.
在同一对象上遇到多个自签名的实现可能以其认为合适的任何方式解决歧义，但建议优先考虑最近的自签名。
(4-octet time field)
（4-八位组时间域）
The time the signature was made.
签字的时间。
MUST be present in the hashed area.
必须存在于散列区域中。
(8-octet Key ID)
（8-八位字节密钥ID）
The OpenPGP Key ID of the key issuing the signature.
发出签名的密钥的OpenPGP密钥ID。
(4-octet time field)
（4-八位组时间域）
The validity period of the key. This is the number of seconds after the key creation time that the key expires. If this is not present or has a value of zero, the key never expires. This is found only on a self-signature.
密钥的有效期。这是密钥创建时间后密钥过期的秒数。如果该键不存在或值为零，则该键永远不会过期。这只能在自签名上找到。
(array of one-octet values)
（一个八位组值的数组）
Symmetric algorithm numbers that indicate which algorithms the key holder prefers to use. The subpacket body is an ordered list of octets with the most preferred listed first. It is assumed that only
对称算法编号，指示密钥持有者更喜欢使用哪些算法。子包正文是一个有序的八位字节列表，最优先的列在前面。假设只有
algorithms listed are supported by the recipient's software. Algorithm numbers are in Section 9. This is only found on a self-signature.
收件人的软件支持列出的算法。算法编号见第9节。这只能在自我签名上找到。
(array of one-octet values)
（一个八位组值的数组）
Message digest algorithm numbers that indicate which algorithms the key holder prefers to receive. Like the preferred symmetric algorithms, the list is ordered. Algorithm numbers are in Section 9. This is only found on a self-signature.
消息摘要算法编号，指示密钥持有者希望接收的算法。与首选的对称算法一样，列表也是有序的。算法编号见第9节。这只能在自我签名上找到。
(array of one-octet values)
（一个八位组值的数组）
Compression algorithm numbers that indicate which algorithms the key holder prefers to use. Like the preferred symmetric algorithms, the list is ordered. Algorithm numbers are in Section 9. If this subpacket is not included, ZIP is preferred. A zero denotes that uncompressed data is preferred; the key holder's software might have no compression software in that implementation. This is only found on a self-signature.
压缩算法编号，指示密钥持有者更喜欢使用哪些算法。与首选的对称算法一样，列表也是有序的。算法编号见第9节。如果不包括此子包，则首选ZIP。零表示首选未压缩的数据；密钥持有者的软件在该实现中可能没有压缩软件。这只能在自我签名上找到。
(4-octet time field)
（4-八位组时间域）
The validity period of the signature. This is the number of seconds after the signature creation time that the signature expires. If this is not present or has a value of zero, it never expires.
签名的有效期。这是签名创建时间后签名过期的秒数。如果不存在或其值为零，则它永远不会过期。
(1 octet of exportability, 0 for not, 1 for exportable)
（1个可导出八位字节，0表示不可导出，1表示可导出）
This subpacket denotes whether a certification signature is "exportable", to be used by other users than the signature's issuer. The packet body contains a Boolean flag indicating whether the signature is exportable. If this packet is not present, the certification is exportable; it is equivalent to a flag containing a 1.
此子包表示认证签名是否“可导出”，供签名颁发者以外的其他用户使用。包体包含一个布尔标志，指示签名是否可导出。如果此数据包不存在，则证书可导出；它相当于包含1的标志。
Non-exportable, or "local", certifications are signatures made by a 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 transport to another user (this is the process of "exporting" the key), any local certification signatures are deleted from the key.
因此，当实现准备将用户的密钥副本传输给另一用户（这是“导出”密钥的过程）时，将从密钥中删除任何本地认证签名。
The receiver of a transported key "imports" it, and likewise trims any local certifications. In normal operation, there won't be any, assuming the import is performed on an exported key. However, there are instances where this can reasonably happen. For example, if an implementation allows keys to be imported from a key database in addition to an exported key, then this situation can arise.
传输密钥的接收者“导入”密钥，并同样修剪任何本地证书。在正常操作中，假设导入是在导出的密钥上执行的，则不会出现任何错误。然而，在某些情况下，这是可以合理发生的。例如，如果实现允许在导出密钥的基础上从密钥数据库导入密钥，则可能出现这种情况。
Some implementations do not represent the interest of a single user (for example, a key server). Such implementations always trim local certifications from any key they handle.
有些实现并不代表单个用户的兴趣（例如，密钥服务器）。这种实现总是从它们处理的任何密钥中删除本地证书。
(1 octet of revocability, 0 for not, 1 for revocable)
（1个可撤销八位字节，0表示不可撤销，1表示可撤销）
Signature's revocability status. The packet body contains a Boolean flag indicating whether the signature is revocable. Signatures that are not revocable have any later revocation signatures ignored. 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, the signature is revocable.
签名的可撤销性状态。包体包含一个布尔标志，指示签名是否可撤销。不可撤销的签名会忽略任何以后的撤销签名。它们代表了签名人的承诺，即在其密钥的生命周期内，他不能撤销其签名。如果此数据包不存在，则签名是可撤销的。
(1 octet "level" (depth), 1 octet of trust amount)
（1个八位字节的“级别”（深度），1个八位字节的信任金额）
Signer asserts that the key is not only valid but also trustworthy at the specified level. Level 0 has the same meaning as an ordinary validity signature. Level 1 means that the signed key is asserted to be a valid trusted introducer, with the 2nd octet of the body specifying the degree of trust. Level 2 means that the signed key is asserted to be trusted to issue level 1 trust signatures, i.e., that it is a "meta introducer". Generally, a level n trust signature asserts that a key is trusted to issue level n-1 trust signatures. The trust amount is in a range from 0-255, interpreted such that values less than 120 indicate partial trust and values of 120 or greater indicate complete trust. Implementations SHOULD emit values of 60 for partial trust and 120 for complete trust.
签名者声明密钥在指定级别上不仅有效，而且值得信任。级别0与普通有效性签名具有相同的含义。级别1表示签名密钥被断言为有效的受信任介绍人，正文的第二个八位组指定信任度。级别2表示签名密钥被断言为可信的，以发布级别1信任签名，即它是“元介绍人”。通常，n级信任签名声明密钥被信任以发布n-1级信任签名。信任金额在0-255之间，解释为小于120表示部分信任，大于等于120表示完全信任。实现应该为部分信任发出60的值，为完全信任发出120的值。
(null-terminated regular expression)
（以null结尾的正则表达式）
Used in conjunction with trust Signature packets (of level > 0) to limit the scope of trust that is extended. Only signatures by the target key on User IDs that match the regular expression in the body of this packet have trust extended by the trust Signature subpacket. The regular expression uses the same syntax as the Henry Spencer's "almost public domain" regular expression [REGEX] package. A description of the syntax is found in Section 8 below.
与信任签名包（级别>0）结合使用，以限制扩展的信任范围。只有与此数据包主体中的正则表达式匹配的用户ID上的目标密钥的签名才具有由信任签名子数据包扩展的信任。正则表达式使用与Henry Spencer的“几乎公共域”正则表达式[REGEX]包相同的语法。下文第8节对语法进行了说明。
(1 octet of class, 1 octet of public-key algorithm ID, 20 octets of fingerprint)
（类的1个八位字节，公钥算法ID的1个八位字节，指纹的20个八位字节）
Authorizes the specified key to issue revocation signatures for this key. Class octet must have bit 0x80 set. If the bit 0x40 is set, then this means that the revocation information is sensitive. Other bits are for future expansion to other kinds of authorizations. This is found on a self-signature.
授权指定的密钥为此密钥颁发吊销签名。类八位字节必须设置位0x80。如果设置了位0x40，则表示吊销信息是敏感的。其他位用于将来扩展到其他类型的授权。这可以在自我签名上找到。
If the "sensitive" flag is set, the keyholder feels this subpacket contains private trust information that describes a real-world sensitive relationship. If this flag is set, implementations SHOULD NOT export this signature to other users except in cases where the data needs to be available: when the signature is being sent to the designated revoker, or when it is accompanied by a revocation signature from that revoker. Note that it may be appropriate to isolate this subpacket within a separate signature so that it is not combined with other subpackets that need to be exported.
如果设置了“敏感”标志，则密钥持有者认为此子包包含描述真实敏感关系的私人信任信息。如果设置了此标志，则实现不应将此签名导出给其他用户，除非数据需要可用：当签名被发送到指定的撤销机时，或者当签名附带来自该撤销机的撤销签名时。请注意，在单独的签名中隔离此子包可能是合适的，这样它就不会与需要导出的其他子包组合。
(4 octets of flags, 2 octets of name length (M), 2 octets of value length (N), M octets of name data, N octets of value data)
（4个八位字节的标志，2个八位字节的名称长度（M），2个八位字节的值长度（N），M个八位字节的名称数据，N个八位字节的值数据）
This subpacket describes a "notation" on the signature that the 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 a signature. Notations can be used for any extension the issuer of the signature cares to make. The "flags" field holds four octets of flags.
本子包描述了发行人希望在签名上做的“标记”。符号有一个名称和一个值，每个值都是八位字节的字符串。签名中可能有多个符号。标记可用于签名发行人希望进行的任何扩展。“flags”字段包含四个八位字节的标志。
All undefined flags MUST be zero. Defined flags are as follows:
所有未定义的标志必须为零。定义的标志如下：
First octet: 0x80 = human-readable. This note value is text. Other octets: none.
第一个八位组：0x80=人类可读。此注释值为文本。其他八位字节：无。
Notation names are arbitrary strings encoded in UTF-8. They reside in two namespaces: The IETF namespace and the user namespace.
符号名称是以UTF-8编码的任意字符串。它们驻留在两个名称空间中：IETF名称空间和用户名称空间。
The IETF namespace is registered with IANA. These names MUST NOT contain the "@" character (0x40). This is a tag for the user namespace.
IETF命名空间已向IANA注册。这些名称不得包含“@”字符（0x40）。这是用户名称空间的标记。
Names in the user namespace consist of a UTF-8 string tag followed by "@" followed by a DNS domain name. Note that the tag MUST NOT contain an "@" character. For example, the "sample" tag used by Example Corporation could be "sample@example.com".
用户名称空间中的名称由UTF-8字符串标记、“@”和DNS域名组成。请注意，标记不能包含“@”字符。例如，example Corporation使用的“sample”标记可以是“sample@example.com".
Names in a user space are owned and controlled by the owners of that domain. Obviously, it's bad form to create a new name in a DNS space that you don't own.
用户空间中的名称由该域的所有者拥有和控制。显然，在您不拥有的DNS空间中创建新名称是不好的。
Since the user namespace is in the form of an email address, 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 to UTF-8 encoding, not all valid user space name tags are valid email addresses.
由于用户名称空间是电子邮件地址的形式，所以实现者可能希望将该地址发送给可以就命名标记的使用进行咨询的人。请注意，由于UTF-8编码，并非所有有效的用户空间名称标记都是有效的电子邮件地址。
If there is a critical notation, the criticality applies to that specific notation and not to notations in general.
如果存在临界符号，临界性适用于该特定符号，而不适用于一般符号。
(N octets of flags)
（N个八位组的旗帜）
This is a list of one-bit flags that indicate preferences that the key holder has about how the key is handled on a key server. All undefined flags MUST be zero.
这是一个一位标志的列表，指示密钥持有者关于密钥服务器上如何处理密钥的首选项。所有未定义的标志必须为零。
First octet: 0x80 = No-modify the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server.
第一个八位组：0x80=否修改密钥持有者请求仅由密钥持有者或密钥服务器管理员修改或更新此密钥。
This is found only on a self-signature.
这只能在自签名上找到。
(String)
（字符串）
This is a URI of a key server that the key holder prefers be used 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 a URI, the key server can actually be a copy of the key retrieved by ftp, http, finger, etc.
这是密钥持有者希望用于更新的密钥服务器的URI。请注意，具有多个用户ID的密钥可以为每个用户ID指定一个首选密钥服务器。还请注意，由于这是一个URI，密钥服务器实际上可以是ftp、http、finger等检索到的密钥的副本。
(1 octet, Boolean)
（1个八位字节，布尔值）
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 an implementation to resolve ambiguities in preferences, etc. by 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 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 most recent self-signature.
这是用户ID自签名中的一个标志，用于说明此用户ID是否是此密钥的主用户ID。实现通过引用主用户ID来解决首选项等中的歧义是合理的。如果没有此标志，则其值为零。如果一个密钥中有多个用户标识被标记为主用户标识，则实现可以以其认为合适的任何方式解决歧义，但建议优先考虑具有最新自签名的用户标识。
When appearing on a self-signature on a User ID packet, this subpacket applies only to User ID packets. When appearing on a self-signature on a User Attribute packet, this subpacket applies only to User Attribute packets. That is to say, there are two different and independent "primaries" -- one for User IDs, and one for User Attributes.
当出现在用户ID数据包的自签名上时，此子数据包仅适用于用户ID数据包。当出现在用户属性数据包的自签名上时，此子数据包仅适用于用户属性数据包。也就是说，有两个不同的独立“原色”——一个用于用户ID，另一个用于用户属性。
(String)
（字符串）
This subpacket contains a URI of a document that describes the policy under which the signature was issued.
此子包包含一个文档的URI，该文档描述签发签名所依据的策略。
(N octets of flags)
（N个八位组的旗帜）
This subpacket contains a list of binary flags that hold information about a key. It is a string of octets, and an implementation MUST NOT assume a fixed size. This is so it can grow over time. If a list is shorter than an implementation expects, the unstated flags are considered to be zero. The defined flags are as follows:
此子包包含一个二进制标志列表，其中包含有关密钥的信息。它是一个八位字节字符串，实现不能采用固定大小。这是因为它可以随时间增长。如果列表比实现预期的短，则未声明的标志将被视为零。定义的标志如下所示：
First octet:
第一个八位组：
0x01 - This key may be used to certify other keys.
0x01-此密钥可用于验证其他密钥。
0x02 - This key may be used to sign data.
0x02-此密钥可用于对数据进行签名。
0x04 - This key may be used to encrypt communications.
0x04-此密钥可用于加密通信。
0x08 - This key may be used to encrypt storage.
0x08-此密钥可用于加密存储。
0x10 - The private component of this key may have been split by a secret-sharing mechanism.
0x10-此密钥的私有组件可能已被秘密共享机制拆分。
0x20 - This key may be used for authentication.
0x20-此密钥可用于身份验证。
0x80 - The private component of this key may be in the possession of more than one person.
0x80-此密钥的私有组件可能由多人拥有。
Usage notes:
使用说明：
The flags in this packet may appear in self-signatures or in certification signatures. They mean different things depending on who is making the statement -- for example, a certification signature that has the "sign data" flag is stating that the certification is for that use. On the other hand, the "communications encryption" flag in a self-signature is stating a preference that a given key be used for communications. Note however, that it is a thorny issue to determine what is "communications" and what is "storage". This decision is left wholly up to the implementation; the authors of this document do not claim any special wisdom on the issue and realize that accepted opinion may change.
此数据包中的标志可能出现在自签名或认证签名中。它们的含义不同，这取决于谁在做声明——例如，带有“sign data”标志的认证签名表示该认证用于该用途。另一方面，自签名中的“通信加密”标志表示将给定密钥用于通信的偏好。然而，请注意，确定什么是“通信”和什么是“存储”是一个棘手的问题。这一决定完全取决于执行情况；本文件的作者并不声称在这个问题上有任何特殊的智慧，并意识到公认的观点可能会改变。
The "split key" (0x10) and "group key" (0x80) flags are placed on a self-signature only; they are meaningless on a certification signature. They SHOULD be placed only on a direct-key signature (type 0x1F) or a subkey signature (type 0x18), one that refers to the key the flag applies to.
“分割密钥”（0x10）和“组密钥”（0x80）标志仅放置在自签名上；它们在认证签名上没有意义。它们只能放在直接密钥签名（类型0x1F）或子密钥签名（类型0x18）上，该签名指的是该标志适用的密钥。
(String)
（字符串）
This subpacket allows a keyholder to state which User ID is responsible for the signing. Many keyholders use a single key for different purposes, such as business communications as well as personal communications. This subpacket allows such a keyholder to state which of their roles is making a signature.
此子包允许密钥持有者声明哪个用户ID负责签名。许多钥匙持有者将一把钥匙用于不同的目的，如商业通信和个人通信。此子包允许此类密钥持有者声明他们的哪个角色正在进行签名。
This subpacket is not appropriate to use to refer to a User Attribute packet.
此子包不适合用于引用用户属性包。
(1 octet of revocation code, N octets of reason string)
（撤销代码的1个八位字节，原因字符串的N个八位字节）
This subpacket is used only in key revocation and certification revocation signatures. It describes the reason why the key or certificate was revoked.
此子包仅用于密钥吊销和证书吊销签名。它描述了密钥或证书被吊销的原因。
The first octet contains a machine-readable code that denotes the reason for the revocation:
第一个八位组包含一个机器可读代码，表示撤销的原因：
0 - No reason specified (key revocations or cert revocations) 1 - Key is superseded (key revocations) 2 - Key material has been compromised (key revocations) 3 - Key is retired and no longer used (key revocations) 32 - User ID information is no longer valid (cert revocations) 100-110 - Private Use
0-未指定原因（密钥撤销或证书撤销）1-密钥被取代（密钥撤销）2-密钥材料已泄露（密钥撤销）3-密钥已失效且不再使用（密钥撤销）32-用户ID信息不再有效（证书撤销）100-110-私人使用
Following the revocation code is a string of octets that gives information about the Reason for Revocation in human-readable form (UTF-8). The string may be null, that is, of zero length. The length of the subpacket is the length of the reason string plus one. An implementation SHOULD implement this subpacket, include it in all revocation signatures, and interpret revocations appropriately. There are important semantic differences between the reasons, and there are thus important reasons for revoking signatures.
撤销代码后面是一串八位字节，以人类可读的形式（UTF-8）给出撤销原因的信息。字符串可以为null，即长度为零。子包的长度是原因字符串的长度加上一。一个实现应该实现这个子包，将它包含在所有撤销签名中，并适当地解释撤销。原因之间存在重要的语义差异，因此撤销签名也有重要的原因。
If a key has been revoked because of a compromise, all signatures created by that key are suspect. However, if it was merely superseded or retired, old signatures are still valid. If the revoked signature is the self-signature for certifying a User ID, a revocation denotes that that user name is no longer in use. Such a revocation SHOULD include a 0x20 code.
如果密钥因泄露而被撤销，则该密钥创建的所有签名都是可疑的。然而，如果只是被取代或失效，旧签名仍然有效。如果撤销的签名是用于认证用户ID的自签名，则撤销表示该用户名不再使用。此类撤销应包括0x20代码。
Note that any signature may be revoked, including a certification on some other person's key. There are many good reasons for revoking a certification signature, such as the case where the keyholder leaves the employ of a business with an email address. A revoked certification is no longer a part of validity calculations.
请注意，任何签名都可能被撤销，包括其他人密钥上的证书。撤销认证签名有很多很好的理由，例如密钥持有人带着电子邮件地址离开公司的情况。吊销的证书不再是有效性计算的一部分。
(N octets of flags)
（N个八位组的旗帜）
The Features subpacket denotes which advanced OpenPGP features a user's implementation supports. This is so that as features are added to OpenPGP that cannot be backwards-compatible, a user can state that they can use that feature. The flags are single bits that indicate that a given feature is supported.
Features子包表示用户的实现支持哪些高级OpenPGP功能。这是为了在OpenPGP中添加不能向后兼容的功能时，用户可以声明他们可以使用该功能。标志是表示支持给定功能的单个位。
This subpacket is similar to a preferences subpacket, and only appears in a self-signature.
此子包类似于首选项子包，仅显示在自签名中。
An implementation SHOULD NOT use a feature listed when sending to a user who does not state that they can use it.
当发送给未声明可以使用功能的用户时，实现不应使用列出的功能。
Defined features are as follows:
定义的特征如下：
First octet:
第一个八位组：
0x01 - Modification Detection (packets 18 and 19)
0x01-修改检测（数据包18和19）
If an implementation implements any of the defined features, it SHOULD implement the Features subpacket, too.
如果一个实现实现了任何定义的特性，它也应该实现特性子包。
An implementation may freely infer features from other suitable implementation-dependent mechanisms.
实现可以自由地从其他合适的依赖于实现的机制推断特征。
(1 octet public-key algorithm, 1 octet hash algorithm, N octets hash)
（1个八位公钥算法，1个八位哈希算法，N个八位哈希）
This subpacket identifies a specific target signature to which a signature refers. For revocation signatures, this subpacket provides explicit designation of which signature is being revoked. For a third-party or timestamp signature, this designates what signature is signed. All arguments are an identifier of that target 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.
哈希数据的N个八位字节必须是签名哈希的大小。例如，具有SHA-1哈希的目标签名必须具有20个八位字节的哈希数据。
(1 signature packet body)
（1签名包体）
This subpacket contains a complete Signature packet body as specified in Section 5.2 above. It is useful when one signature needs to refer to, or be incorporated in, another signature.
此子包包含上文第5.2节规定的完整签名包正文。当一个签名需要引用或合并到另一个签名中时，它非常有用。
All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm.
所有签名都是通过在签名数据上生成哈希，然后在签名算法中使用生成的哈希来形成的。
For binary document signatures (type 0x00), the document data is hashed directly. For text document signatures (type 0x01), the document is canonicalized by converting line endings to <CR><LF>, and the resulting data is hashed.
对于二进制文档签名（类型0x00），直接对文档数据进行散列。对于文本文档签名（类型0x01），文档通过将行尾转换为<CR><LF>来规范化，并对结果数据进行哈希处理。
When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey binding signature (type 0x18) or primary key binding signature (type 0x19) then hashes the subkey using the same format as the main key (also using 0x99 as the first octet). Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked.
当对密钥进行签名时，哈希数据以八位字节0x99开始，后跟密钥的两个八位字节长度，然后是密钥包的正文。（请注意，这是具有两个八位字节长度的密钥数据包的旧式数据包头。）然后，子密钥绑定签名（类型0x18）或主键绑定签名（类型0x19）使用与主键相同的格式散列子密钥（也使用0x99作为第一个八位字节）。密钥撤销签名（类型0x20和0x28）仅哈希正在撤销的密钥。
A certification signature (type 0x10 through 0x13) hashes the User ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the User ID or attribute packet packet, without any header. A V4 certification hashes the constant 0xB4 for User ID certifications or the constant 0xD1 for User Attribute certifications, followed by a four-octet number giving the length of the User ID or User Attribute data, and then the User ID or User Attribute data.
证书签名（类型0x10到0x13）将绑定到密钥的用户ID散列到上述数据之后的散列上下文中。V3认证散列用户ID或属性数据包的内容，没有任何头。V4认证对用户ID认证的常数0xB4或用户属性认证的常数0xD1进行散列，然后是四个八位组数字，给出用户ID或用户属性数据的长度，然后是用户ID或用户属性数据。
When a signature is made over a Signature packet (type 0x50), the hash data starts with the octet 0x88, followed by the four-octet length of the signature, and then the body of the Signature packet. (Note that this is an old-style packet header for a Signature packet with the length-of-length set to zero.) The unhashed subpacket data of the Signature packet being hashed is not included in the hash, and the unhashed subpacket data length value is set to zero.
当在签名包（类型0x50）上进行签名时，哈希数据以八位字节0x88开始，然后是签名的四个八位字节长度，然后是签名包的正文。（注意，这是长度设置为零的签名包的旧式包头。）哈希中不包括正在哈希的签名包的未哈希子包数据，且未哈希子包数据长度值设置为零。
Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature time. A V4 signature hashes the packet body
对数据体进行散列后，将对尾部进行散列。V3签名从签名类型字段开始，散列数据包正文的五个八位字节。此数据是签名类型，后跟四个八位数字签名时间。V4签名对数据包体进行散列
starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public-key algorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body.
从它的第一个字段，版本号开始，一直到散列子包数据的末尾。因此，散列的字段是签名版本、签名类型、公钥算法、散列算法、散列子包长度和散列子包体。
V4 signatures also hash in a final trailer of six octets: the version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, big-endian number that is the length of the hashed data from the Signature packet (note that this number does not include these final six octets).
V4签名还散列在六个八位组的最后一个预告片中：签名包的版本，即0x04；0xFF；和一个四个八位组的大端数字，它是来自签名包的散列数据的长度（注意，这个数字不包括最后六个八位组）。
After all this has been hashed in a single hash context, the resulting hash field is used in the signature algorithm and placed at the end of the Signature packet.
在单个散列上下文中对所有这些内容进行散列后，生成的散列字段将用于签名算法，并放置在签名数据包的末尾。
It is certainly possible for a signature to contain conflicting information in subpackets. For example, a signature may contain multiple copies of a preference or multiple expiration times. In most cases, an implementation SHOULD use the last subpacket in the signature, but MAY use any conflict resolution scheme that makes more sense. Please note that we are intentionally leaving conflict resolution to the implementer; most conflicts are simply syntax errors, and the wishy-washy language here allows a receiver to be generous in what they accept, while putting pressure on a creator to be stingy in what they generate.
签名在子包中当然可能包含冲突信息。例如，签名可能包含首选项的多个副本或多个过期时间。在大多数情况下，实现应该使用签名中的最后一个子包，但可以使用任何更有意义的冲突解决方案。请注意，我们有意将冲突解决留给实施者；大多数冲突仅仅是语法错误，这里的含糊不清的语言允许接收者在他们接受的东西上慷慨大方，同时给创造者施加压力，要求他们在他们产生的东西上吝啬。
Some apparent conflicts may actually make sense -- for example, suppose a keyholder has a V3 key and a V4 key that share the same RSA key material. Either of these keys can verify a signature created by the other, and it may be reasonable for a signature to contain an issuer subpacket for each key, as a way of explicitly tying those keys to the signature.
一些明显的冲突实际上可能是有意义的——例如，假设一个密钥持有者有一个V3密钥和一个V4密钥，它们共享相同的RSA密钥材料。这些密钥中的任何一个都可以验证由另一个密钥创建的签名，并且签名包含每个密钥的颁发者子包可能是合理的，作为将这些密钥显式绑定到签名的一种方式。
The Symmetric-Key Encrypted Session Key packet holds the symmetric-key encryption of a session key used to encrypt a message. Zero or more Public-Key Encrypted Session Key packets and/or Symmetric-Key Encrypted Session Key packets may precede a Symmetrically Encrypted Data packet that holds an encrypted message. The message is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet or the Symmetric-Key Encrypted Session Key packet.
对称密钥加密会话密钥包保存用于加密消息的会话密钥的对称密钥加密。零个或多个公钥加密的会话密钥分组和/或对称密钥加密的会话密钥分组可以位于持有加密消息的对称加密数据分组之前。消息用会话密钥加密，会话密钥本身被加密并存储在加密会话密钥分组或对称密钥加密会话密钥分组中。
If the Symmetrically Encrypted Data packet is preceded by one or more Symmetric-Key Encrypted Session Key packets, each specifies a passphrase that may be used to decrypt the message. This allows a message to be encrypted to a number of public keys, and also to one or more passphrases. This packet type is new and is not generated by PGP 2.x or PGP 5.0.
如果对称加密的数据包前面有一个或多个对称密钥加密的会话密钥包，则每个会话密钥包指定可用于解密消息的密码短语。这允许将消息加密为多个公钥，以及一个或多个密码短语。此数据包类型是新的，不是由PGP2.x或PGP5.0生成的。
The body of this packet consists of:
本文件包正文包括：
- A one-octet version number. The only currently defined version is 4.
- 一个八位字节的版本号。当前唯一定义的版本是4。
- A one-octet number describing the symmetric algorithm used.
- 描述所用对称算法的一个八位组数。
- A string-to-key (S2K) specifier, length as defined above.
- 字符串到键（S2K）说明符，长度如上所述。
- Optionally, the encrypted session key itself, which is decrypted with the string-to-key object.
- （可选）加密的会话密钥本身，使用字符串到密钥对象进行解密。
If the encrypted session key is not present (which can be detected on the basis of packet length and S2K specifier size), then the S2K algorithm applied to the passphrase produces the session key for decrypting the file, using the symmetric cipher algorithm from the Symmetric-Key Encrypted Session Key packet.
如果加密的会话密钥不存在（可根据分组长度和S2K说明符大小检测），则应用于密码短语的S2K算法使用对称密钥加密的会话密钥分组中的对称密码算法生成用于解密文件的会话密钥。
If the encrypted session key is present, the result of applying the S2K algorithm to the passphrase is used to decrypt just that encrypted session key field, using CFB mode with an IV of all zeros. The decryption result consists of a one-octet algorithm identifier that specifies the symmetric-key encryption algorithm used to encrypt the following Symmetrically Encrypted Data packet, followed by the session key octets themselves.
如果存在加密会话密钥，则将S2K算法应用于密码短语的结果用于仅解密该加密会话密钥字段，使用带有IV全零的CFB模式。解密结果由一个八位组算法标识符组成，该标识符指定用于加密以下对称加密数据包的对称密钥加密算法，然后是会话密钥八位组本身。
Note: because an all-zero IV is used for this decryption, the S2K specifier MUST use a salt value, either a Salted S2K or an Iterated-Salted S2K. The salt value will ensure that the decryption key is not repeated even if the passphrase is reused.
注意：由于此解密使用全零IV，S2K说明符必须使用salt值，salt S2K或迭代salt S2K。salt值将确保即使重新使用密码短语，解密密钥也不会重复。
The One-Pass Signature packet precedes the signed data and contains enough information to allow the receiver to begin calculating any hashes needed to verify the signature. It allows the Signature packet to be placed at the end of the message, so that the signer can compute the entire signed message in one pass.
单程签名包位于签名数据之前，包含足够的信息，允许接收方开始计算验证签名所需的任何散列。它允许将签名包放在消息的末尾，以便签名者可以在一次传递中计算整个签名消息。
A One-Pass Signature does not interoperate with PGP 2.6.x or earlier.
一次性签名不能与PGP 2.6.x或更早版本互操作。
The body of this packet consists of:
本文件包正文包括：
- A one-octet version number. The current version is 3.
- 一个八位字节的版本号。目前的版本是3。
- A one-octet signature type. Signature types are described in Section 5.2.1.
- 一个八位组签名类型。第5.2.1节描述了签名类型。
- A one-octet number describing the hash algorithm used.
- 描述所用哈希算法的一个八位组数。
- A one-octet number describing the public-key algorithm used.
- 描述所用公钥算法的一个八位组数。
- An eight-octet number holding the Key ID of the signing key.
- 保存签名密钥的密钥ID的八个八位组的数字。
- A one-octet number holding a flag showing whether the signature is nested. A zero value indicates that the next packet is another One-Pass Signature packet that describes another signature to be applied to the same message data.
- 一个八位组的数字，带有一个标志，显示签名是否嵌套。零值表示下一个数据包是另一个单通道签名数据包，该数据包描述了应用于同一消息数据的另一个签名。
Note that if a message contains more than one one-pass signature, then the Signature packets bracket the message; that is, the first Signature packet after the message corresponds to the last one-pass packet and the final Signature packet corresponds to the first one-pass packet.
请注意，如果一条消息包含多个一次性签名，那么签名包将包含该消息；即，消息之后的第一签名分组对应于最后一个一次通过分组，并且最终签名分组对应于第一个一次通过分组。
A key material packet contains all the information about a public or private key. There are four variants of this packet type, and two major versions. Consequently, this section is complex.
密钥材料包包含关于公钥或私钥的所有信息。此数据包类型有四种变体和两个主要版本。因此，这一部分很复杂。
A Public-Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate).
公钥数据包启动一系列数据包，形成OpenPGP密钥（有时称为OpenPGP证书）。
A Public-Subkey packet (tag 14) has exactly the same format as a Public-Key packet, but denotes a subkey. One or more subkeys may be associated with a top-level key. By convention, the top-level key provides signature services, and the subkeys provide encryption services.
公钥分组（标签14）具有与公钥分组完全相同的格式，但表示子密钥。一个或多个子键可能与顶级键关联。按照惯例，顶级密钥提供签名服务，子密钥提供加密服务。
Note: in PGP 2.6.x, tag 14 was intended to indicate a comment packet. This tag was selected for reuse because no previous version of PGP ever emitted comment packets but they did properly ignore
注：在PGP2.6.x中，标记14用于表示注释包。选择此标记以供重用，因为以前版本的PGP从未发出注释数据包，但它们确实正确地忽略了注释数据包
them. Public-Subkey packets are ignored by PGP 2.6.x and do not cause it to fail, providing a limited degree of backward compatibility.
他们PGP2.6.x会忽略公钥数据包，不会导致其失败，从而提供有限程度的向后兼容性。
A Secret-Key packet contains all the information that is found in a Public-Key packet, including the public-key material, but also includes the secret-key material after all the public-key fields.
密钥包包含在公钥包中找到的所有信息，包括公钥材料，但也包括在所有公钥字段之后的密钥材料。
A Secret-Subkey packet (tag 7) is the subkey analog of the Secret Key packet and has exactly the same format.
A Secret-Subkey packet (tag 7) is the subkey analog of the Secret Key packet and has exactly the same format.translate error, please retry
There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 4 keys first appeared in PGP 5.0 and are the preferred key version for OpenPGP.
关键材料包有两个版本。版本3数据包首先由PGP2.6生成。版本4密钥最早出现在PGP5.0中，是OpenPGP的首选密钥版本。
OpenPGP implementations MUST create keys with version 4 format. V3 keys are deprecated; an implementation MUST NOT generate a V3 key, but MAY accept it.
OpenPGP实现必须使用版本4格式创建密钥。V3密钥已弃用；实现不能生成V3密钥，但可以接受它。
A version 3 public key or public-subkey packet contains:
版本3公钥或公钥子密钥包包含：
- A one-octet version number (3).
- 一个八位组版本号（3）。
- A four-octet number denoting the time that the key was created.
- 表示密钥创建时间的四个八位组数字。
- A two-octet number denoting the time in days that this key is valid. If this number is zero, then it does not expire.
- 两个八位组的数字，表示此密钥有效的时间（以天为单位）。如果此数字为零，则不会过期。
- A one-octet number denoting the public-key algorithm of this key.
- 表示该密钥的公钥算法的一个八位组数。
- A series of multiprecision integers comprising the key material:
- 包含关键材料的一系列多精度整数：
- a multiprecision integer (MPI) of RSA public modulus n;
- RSA公共模n的多精度整数（MPI）；
- an MPI of RSA public encryption exponent e.
- RSA公共加密指数e的MPI。
V3 keys are deprecated. They contain three weaknesses. First, it is relatively easy to construct a V3 key that has the same Key ID as any other key because the Key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, there is an increased opportunity for fingerprint collisions. Third, there are weaknesses in the MD5
V3密钥已弃用。它们有三个弱点。首先，构造与任何其他密钥具有相同密钥ID的V3密钥相对容易，因为密钥ID只是公共模的低64位。其次，由于V3密钥的指纹会散列密钥材料，而不是其长度，因此指纹冲突的机会会增加。第三，MD5中存在弱点
hash algorithm that make developers prefer other algorithms. See below for a fuller discussion of Key IDs and fingerprints.
使开发人员更喜欢其他算法的哈希算法。有关密钥ID和指纹的详细讨论，请参见下文。
V2 keys are identical to the deprecated V3 keys except for the version number. An implementation MUST NOT generate them and MAY accept or reject them as it sees fit.
V2密钥与不推荐使用的V3密钥相同，只是版本号不同。实现不能生成它们，并且可以根据需要接受或拒绝它们。
The version 4 format is similar to the version 3 format except for the absence of a validity period. This has been moved to the Signature packet. In addition, fingerprints of version 4 keys are calculated differently from version 3 keys, as described in the section "Enhanced Key Formats".
版本4格式与版本3格式类似，只是没有有效期。这已移动到签名包。此外，第4版密钥的指纹计算与第3版密钥不同，如“增强密钥格式”一节所述。
A version 4 packet contains:
版本4数据包包含：
- A one-octet version number (4).
- 一个八位组版本号（4）。
- A four-octet number denoting the time that the key was created.
- 表示密钥创建时间的四个八位组数字。
- A one-octet number denoting the public-key algorithm of this key.
- 表示该密钥的公钥算法的一个八位组数。
- A series of multiprecision integers comprising the key material. This algorithm-specific portion is:
- 包含关键材料的一系列多精度整数。该算法的特定部分是：
Algorithm-Specific Fields for RSA public keys:
RSA公钥的算法特定字段：
- multiprecision integer (MPI) of RSA public modulus n;
- RSA公共模n的多精度整数（MPI）；
- MPI of RSA public encryption exponent e.
- RSA公共加密指数e的MPI。
Algorithm-Specific Fields for DSA public keys:
DSA公钥的算法特定字段：
- MPI of DSA prime p;
- DSA素数p的MPI；
- MPI of DSA group order q (q is a prime divisor of p-1);
- DSA组阶q的MPI（q是p-1的素因子）；
- MPI of DSA group generator g;
- DSA组生成器g的MPI；
- MPI of DSA public-key value y (= g**x mod p where x is secret).
- DSA公钥值y的MPI（=g**x mod p，其中x为机密）。
Algorithm-Specific Fields for Elgamal public keys:
Elgamal公钥的算法特定字段：
- MPI of Elgamal prime p;
- Elgamal素数p的MPI；
- MPI of Elgamal group generator g;
- Elgamal群生成器g的MPI；
- MPI of Elgamal public key value y (= g**x mod p where x is secret).
- Elgamal公钥值y的MPI（=g**x mod p，其中x为机密）。
The Secret-Key and Secret-Subkey packets contain all the data of the Public-Key and Public-Subkey packets, with additional algorithm-specific secret-key data appended, usually in encrypted form.
秘密密钥和秘密子密钥数据包包含公开密钥和公开子密钥数据包的所有数据，通常以加密形式附加额外的算法特定秘密密钥数据。
The packet contains:
数据包包含：
- A Public-Key or Public-Subkey packet, as described above.
- 公开密钥或公开子密钥包，如上所述。
- One octet indicating string-to-key usage conventions. Zero indicates that the secret-key data is not encrypted. 255 or 254 indicates that a string-to-key specifier is being given. Any other value is a symmetric-key encryption algorithm identifier.
- 一个八位字节，表示字符串到键的使用约定。零表示密钥数据未加密。255或254表示正在向键说明符提供字符串。任何其他值都是对称密钥加密算法标识符。
- [Optional] If string-to-key usage octet was 255 or 254, a one-octet symmetric encryption algorithm.
- [可选]如果字符串到密钥的使用八位字节为255或254，则使用一个八位字节对称加密算法。
- [Optional] If string-to-key usage octet was 255 or 254, a string-to-key specifier. The length of the string-to-key specifier is implied by its type, as described above.
- [可选]如果字符串到键的使用八位字节为255或254，则为字符串到键说明符。字符串到键说明符的长度由其类型暗示，如上所述。
- [Optional] If secret data is encrypted (string-to-key usage octet not zero), an Initial Vector (IV) of the same length as the cipher's block size.
- [可选]如果加密了机密数据（字符串到密钥的使用八位字节不为零），则初始向量（IV）的长度与密码的块大小相同。
- Plain or encrypted multiprecision integers comprising the secret key data. These algorithm-specific fields are as described below.
- 包含密钥数据的普通或加密的多精度整数。这些特定于算法的字段如下所述。
- If the string-to-key usage octet is zero or 255, then a two-octet checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536). If the string-to-key usage octet was 254, then a 20-octet SHA-1 hash of the plaintext of the algorithm-specific portion. This checksum or hash is encrypted together with the algorithm-specific fields (if string-to-key usage octet is not zero). Note that for all other values, a two-octet checksum is required.
- 如果字符串到密钥使用八位字节为零或255，则算法特定部分的明文的两个八位字节校验和（所有八位字节之和，mod 65536）。如果字符串到键的使用八位字节为254，则算法特定部分的明文的20八位字节SHA-1哈希。此校验和或哈希与特定于算法的字段一起加密（如果字符串到密钥的使用八位字节不为零）。请注意，对于所有其他值，需要两个八位校验和。
Algorithm-Specific Fields for RSA secret keys:
RSA密钥的算法特定字段：
- multiprecision integer (MPI) of RSA secret exponent d.
- RSA秘密指数d的多精度整数（MPI）。
- MPI of RSA secret prime value p.
- RSA秘密素数p的MPI。
- MPI of RSA secret prime value q (p < q).
- RSA秘密素数值q的MPI（p<q）。
- MPI of u, the multiplicative inverse of p, mod q.
- u的MPI，p的乘法逆，mod q。
Algorithm-Specific Fields for DSA secret keys:
DSA密钥的算法特定字段：
- MPI of DSA secret exponent x.
- DSA秘密指数x的MPI。
Algorithm-Specific Fields for Elgamal secret keys:
Elgamal密钥的算法特定字段：
- MPI of Elgamal secret exponent x.
- Elgamal秘密指数x的MPI。
Secret MPI values can be encrypted using a passphrase. If a string-to-key specifier is given, that describes the algorithm for converting the passphrase to a key, else a simple MD5 hash of the passphrase is used. Implementations MUST use a string-to-key specifier; the simple hash is for backward compatibility and is deprecated, though implementations MAY continue to use existing private keys in the old format. The cipher for encrypting the MPIs is specified in the Secret-Key packet.
可以使用MPI密码对值进行加密。如果给定了一个字符串到密钥说明符，该说明符描述了将密码短语转换为密钥的算法，否则将使用密码短语的简单MD5哈希。实现必须使用字符串作为键说明符；简单散列是为了向后兼容，不推荐使用，不过实现可能会继续使用旧格式的现有私钥。加密MPI的密码在密钥包中指定。
Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initial Vector from the packet. A different mode is used with V3 keys (which are only RSA) than with other key formats. With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non-prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block boundary is aligned with the start of the MPI data.
机密数据的加密/解密在CFB模式下完成，使用从密码短语创建的密钥和来自数据包的初始向量。V3密钥（仅为RSA）使用的模式与其他密钥格式不同。对于V3密钥，MPI位计数前缀（即前两个八位字节）不加密。仅对MPI非前缀数据进行加密。此外，CFB状态在每个新MPI值的开始处重新同步，以便CFB块边界与MPI数据的开始处对齐。
With V4 keys, a simpler method is used. All secret MPI values are encrypted in CFB mode, including the MPI bitcount prefix.
对于V4键，使用了一种更简单的方法。所有机密MPI值都在CFB模式下加密，包括MPI位计数前缀。
The two-octet checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm-specific octets (including MPI prefix and data). With V3 keys, the checksum is stored in the clear. With V4 keys, the checksum is encrypted like the algorithm-specific data. This value is used to check that the passphrase was correct. However, this checksum is deprecated; an implementation SHOULD NOT use it, but should rather use the SHA-1 hash denoted with a usage octet of 254. The reason for this is that there are some attacks that involve undetectably modifying the secret key.
算法特定部分后面的两个八位字节校验和是所有算法特定八位字节（包括MPI前缀和数据）的明文的代数和mod 65536。对于V3键，校验和存储在clear中。对于V4密钥，校验和与特定算法的数据一样进行加密。此值用于检查密码短语是否正确。但是，不推荐使用此校验和；一个实现不应该使用它，而是应该使用SHA-1哈希，用254的用法八位组表示。这是因为存在一些涉及无法检测到修改密钥的攻击。
The Compressed Data packet contains compressed data. Typically, this packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains a literal data packet.
压缩数据包包含压缩数据。通常，此数据包被发现为加密数据包的内容，或在签名或单次签名数据包之后，并包含文字数据包。
The body of this packet consists of:
本文件包正文包括：
- One octet that gives the algorithm used to compress the packet.
- 一个八位组，给出用于压缩数据包的算法。
- Compressed data, which makes up the remainder of the packet.
- 压缩数据，构成数据包的剩余部分。
A Compressed Data Packet's body contains an block that compresses some set of packets. See section "Packet Composition" for details on how messages are formed.
压缩数据包的主体包含一个块，该块压缩一组数据包。有关如何形成消息的详细信息，请参见“数据包组成”一节。
ZIP-compressed packets are compressed with raw RFC 1951 [RFC1951] DEFLATE blocks. Note that PGP V2.6 uses 13 bits of compression. If an implementation uses more bits of compression, PGP V2.6 cannot decompress it.
ZIP压缩包使用原始RFC 1951[RFC1951]DEFLATE块进行压缩。请注意，PGPv2.6使用13位压缩。如果一个实现使用了更多的压缩位，PGP V2.6将无法对其进行解压缩。
ZLIB-compressed packets are compressed with RFC 1950 [RFC1950] ZLIB-style blocks.
ZLIB压缩包使用RFC1950[RFC1950]ZLIB样式块进行压缩。
BZip2-compressed packets are compressed using the BZip2 [BZ2] algorithm.
BZip2压缩包使用BZip2[BZ2]算法进行压缩。
The Symmetrically Encrypted Data packet contains data encrypted with a symmetric-key algorithm. When it has been decrypted, it contains other packets (usually a literal data packet or compressed data packet, but in theory other Symmetrically Encrypted Data packets or sequences of packets that form whole OpenPGP messages).
对称加密的数据包包含使用对称密钥算法加密的数据。解密后，它包含其他数据包（通常是文字数据包或压缩数据包，但理论上是其他对称加密的数据包或形成整个OpenPGP消息的数据包序列）。
The body of this packet consists of:
本文件包正文包括：
- Encrypted data, the output of the selected symmetric-key cipher operating in OpenPGP's variant of Cipher Feedback (CFB) mode.
- 加密数据，在OpenPGP的密码反馈变体（CFB）模式下运行的选定对称密钥密码的输出。
The symmetric cipher used may be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data packet. In that case, the cipher algorithm octet is prefixed to the session key before it is encrypted. If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase, though this use is deprecated.
所使用的对称密码可以在对称加密数据分组之前的公钥或对称密钥加密会话密钥分组中指定。在这种情况下，加密算法octet在会话密钥加密之前被加上前缀。如果加密数据之前没有这些类型的数据包，则IDEA算法将与会话密钥一起使用，会话密钥计算为密码短语的MD5散列，尽管这种用法已被弃用。
The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes a string of length equal to the block size of the cipher plus two to the data before it is encrypted. The first block-size octets (for example, 8 octets for a 64-bit block length) are random, and the following two octets are copies of the last two octets of the IV. For example, in an 8-octet block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15 and octet 18 is a repeat of octet 16. As a pedantic clarification, in both these examples, we consider the first octet to be numbered 1.
数据在CFB模式下加密，CFB移位大小等于密码的块大小。初始向量（IV）指定为全零。OpenPGP不使用IV，而是在加密前为数据添加长度等于密码块大小加2的字符串前缀。第一个块大小的八位字节（例如，64位块长度的8个八位字节）是随机的，接下来的两个八位字节是IV的最后两个八位字节的副本。例如，在8个八位字节的块中，八位字节9是八位字节7的重复，八位字节10是八位字节8的重复。在长度为16的密码中，八位组17是八位组15的重复，八位组18是八位组16的重复。作为迂腐的澄清，在这两个例子中，我们认为第一个八位字节被编号为1。
After encrypting the first block-size-plus-two octets, the CFB state is resynchronized. The last block-size octets of ciphertext are passed through the cipher and the block boundary is reset.
加密第一个块大小加上两个八位字节后，CFB状态将重新同步。密文的最后一个块大小的八位字节通过密码，并重置块边界。
The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. See the "Security Considerations" section for hints on the proper use of this "quick check".
在消息前缀的随机数据中重复16位，允许接收方立即检查会话密钥是否不正确。有关正确使用此“快速检查”的提示，请参阅“安全注意事项”部分。
An experimental version of PGP used this packet as the Literal packet, but no released version of PGP generated Literal packets with this tag. With PGP 5.x, this packet has been reassigned and is reserved for use as the Marker packet.
PGP的一个实验版本使用此数据包作为文本数据包，但没有发布版本的PGP生成带有此标记的文本数据包。对于PGP5.x，此数据包已重新分配，并保留用作标记数据包。
The body of this packet consists of:
本文件包正文包括：
- The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).
- 三个八位字节0x50、0x47、0x50（在UTF-8中拼写为“PGP”）。
Such a packet MUST be ignored when received. It may be placed at the beginning of a message that uses features not available in PGP 2.6.x in order to cause that version to report that newer software is necessary to process the message.
接收到这样的数据包时必须忽略。它可以放在使用PGP 2.6.x中不可用功能的消息的开头，以使该版本报告需要更新的软件来处理该消息。
A Literal Data packet contains the body of a message; data that is not to be further interpreted.
文字数据包包含消息体；不需要进一步解释的数据。
The body of this packet consists of:
本文件包正文包括：
- 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 't' (0x74), then it contains text data, and thus may need line ends converted to local form, or other text-mode changes. The tag 'u' (0x75) means the same as 't', but also indicates that implementation believes that the literal data contains UTF-8 text.
如果是“b”（0x62），则文字数据包包含二进制数据。如果是“t”（0x74），则它包含文本数据，因此可能需要将行尾转换为本地形式，或更改其他文本模式。标记“u”（0x75）的意思与“t”相同，但也表示实现认为文本数据包含UTF-8文本。
Early versions of PGP also defined a value of 'l' as a 'local' mode for machine-local conversions. RFC 1991 [RFC1991] incorrectly stated this local mode flag as '1' (ASCII numeral one). Both of these local modes are deprecated.
PGP的早期版本还将值“l”定义为机器本地转换的“本地”模式。RFC 1991[RFC1991]错误地将此本地模式标志表示为“1”（ASCII数字1）。这两种本地模式都不推荐使用。
- File name as a string (one-octet length, followed by a file name). This may be a zero-length string. Commonly, if the source of the encrypted data is a file, this will be the name of the encrypted file. An implementation MAY consider the file name in the Literal packet to be a more authoritative name than the actual file name.
- 文件名为字符串（一个八位字节长度，后跟一个文件名）。这可能是长度为零的字符串。通常，如果加密数据的源是文件，则这将是加密文件的名称。实现可以考虑文本包中的文件名是比实际文件名更权威的名称。
If the special name "_CONSOLE" is used, the message is considered to be "for your eyes only". This advises that the message data is unusually sensitive, and the receiving program should process it more carefully, perhaps avoiding storing the received data to disk, for example.
如果使用了特殊名称“_CONSOLE”，则消息将被视为“仅供您观看”。这表明消息数据异常敏感，接收程序应该更仔细地处理它，例如，可能避免将接收到的数据存储到磁盘。
- A four-octet number that indicates a date associated with the literal data. Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time.
- 四个八位组的数字，表示和文字数据相关的日期。通常，日期可能是文件的修改日期，或数据包创建的时间，或表示没有特定时间的零。
- The remainder of the packet is literal data.
- 数据包的其余部分是文字数据。
Text data is stored with <CR><LF> text endings (i.e., network-normal line endings). These should be converted to native line endings by the receiving software.
文本数据以<CR><LF>文本结尾（即网络正常行结尾）存储。接收软件应将其转换为本机行结尾。
The Trust packet is used only within keyrings and is not normally exported. Trust packets contain data that record the user's specifications of which key holders are trustworthy introducers, along with other information that implementing software uses for trust information. The format of Trust packets is defined by a given implementation.
信任数据包仅在密钥环内使用，通常不会导出。信任包包含记录用户规范的数据，其中密钥持有者是值得信任的介绍人，以及实现软件用于信任信息的其他信息。信任包的格式由给定的实现定义。
Trust packets SHOULD NOT be emitted to output streams that are transferred to other users, and they SHOULD be ignored on any input other than local keyring files.
不应将信任数据包发送到传输给其他用户的输出流，并且应忽略本地密钥环文件以外的任何输入。
A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID.
用户ID数据包由UTF-8文本组成，用于表示密钥持有者的姓名和电子邮件地址。按照惯例，它包括一个RFC 2822[RFC2822]邮件名addr，但对其内容没有限制。报头中的数据包长度指定用户ID的长度。
The User Attribute packet is a variation of the User ID packet. It is capable of storing more types of data than the User ID packet, which is limited to text. Like the User ID packet, a User Attribute packet may be certified by the key owner ("self-signed") or any other key owner who cares to certify it. Except as noted, a User Attribute packet may be used anywhere that a User ID packet may be used.
用户属性分组是用户ID分组的变体。它能够存储比仅限于文本的用户ID数据包更多类型的数据。与用户ID分组一样，用户属性分组可以由密钥所有者（“自签名”）或关心认证它的任何其他密钥所有者认证。除如上所述之外，用户属性分组可以在可以使用用户ID分组的任何地方使用。
While User Attribute packets are not a required part of the OpenPGP standard, implementations SHOULD provide at least enough compatibility to properly handle a certification signature on the User Attribute packet. A simple way to do this is by treating the User Attribute packet as a User ID packet with opaque contents, but an implementation may use any method desired.
虽然用户属性数据包不是OpenPGP标准的必需部分，但实现应至少提供足够的兼容性，以便正确处理用户属性数据包上的认证签名。实现这一点的一个简单方法是将用户属性数据包视为具有不透明内容的用户ID数据包，但实现可以使用任何所需的方法。
The User Attribute packet is made up of one or more attribute subpackets. Each subpacket consists of a subpacket header and a body. The header consists of:
用户属性包由一个或多个属性子包组成。每个子包由一个子包头和一个子包体组成。标题包括：
- the subpacket length (1, 2, or 5 octets)
- 子包长度（1、2或5个八位字节）
- the subpacket type (1 octet)
- 子包类型（1个八位字节）
and is followed by the subpacket specific data.
然后是子包特定的数据。
The only currently defined subpacket type is 1, signifying an image. An implementation SHOULD ignore any subpacket of a type that it does not recognize. Subpacket types 100 through 110 are reserved for private or experimental use.
当前唯一定义的子包类型是1，表示图像。实现应该忽略它无法识别的任何类型的子包。子包类型100到110保留供私人或实验使用。
The Image Attribute subpacket is used to encode an image, presumably (but not required to be) that of the key owner.
图像属性子包用于编码图像，可能（但不要求）是密钥所有者的图像。
The Image Attribute subpacket begins with an image header. The first two octets of the image header contain the length of the image header. Note that unlike other multi-octet numerical values in this document, due to a historical accident this value is encoded as a
图像属性子包以图像标题开始。图像头的前两个八位字节包含图像头的长度。请注意，与本文档中的其他多个八位组数值不同，由于历史事故，该值被编码为
little-endian number. The image header length is followed by a single octet for the image header version. The only currently defined version of the image header is 1, which is a 16-octet image header. The first three octets of a version 1 image header are thus 0x10, 0x00, 0x01.
小端数。对于图像头版本，图像头长度后面跟着一个八位字节。当前唯一定义的图像头版本是1，它是一个16字节的图像头。因此，版本1图像头的前三个八位字节是0x10、0x00、0x01。
The fourth octet of a version 1 image header designates the encoding format of the image. The only currently defined encoding format is the value 1 to indicate JPEG. Image format types 100 through 110 are reserved for private or experimental use. The rest of the version 1 image header is made up of 12 reserved octets, all of which MUST be set to 0.
版本1图像头的第四个八位字节指定图像的编码格式。当前唯一定义的编码格式是表示JPEG的值1。图像格式类型100到110保留供私人或实验使用。版本1图像头的其余部分由12个保留的八位字节组成，所有八位字节都必须设置为0。
The rest of the image subpacket contains the image itself. As the only currently defined image type is JPEG, the image is encoded in the JPEG File Interchange Format (JFIF), a standard file format for JPEG images [JFIF].
图像子包的其余部分包含图像本身。由于当前唯一定义的图像类型是JPEG，因此图像以JPEG文件交换格式（JFIF）编码，这是JPEG图像的标准文件格式[JFIF]。
An implementation MAY try to determine the type of an image by examination of the image data if it is unable to handle a particular version of the image header or if a specified encoding format value is not recognized.
如果无法处理特定版本的图像头或者如果无法识别指定的编码格式值，则实现可以尝试通过检查图像数据来确定图像的类型。
The Symmetrically Encrypted Integrity Protected Data packet is a variant of the Symmetrically Encrypted Data packet. It is a new feature created for OpenPGP that addresses the problem of detecting a modification to encrypted data. It is used in combination with a Modification Detection Code packet.
对称加密完整性保护数据包是对称加密数据包的变体。它是为OpenPGP创建的一个新特性，解决了检测加密数据修改的问题。它与修改检测代码包结合使用。
There is a corresponding feature in the features Signature subpacket that denotes that an implementation can properly use this packet type. An implementation MUST support decrypting these packets and SHOULD prefer generating them to the older Symmetrically Encrypted Data packet when possible. Since this data packet protects against modification attacks, this standard encourages its proliferation. While blanket adoption of this data packet would create interoperability problems, rapid adoption is nevertheless important. An implementation SHOULD specifically denote support for this packet, but it MAY infer it from other mechanisms.
features Signature子包中有一个对应的特性，表示实现可以正确使用此数据包类型。一个实现必须支持对这些数据包进行解密，并且在可能的情况下，应该更倾向于生成这些数据包，而不是生成较旧的对称加密数据包。由于此数据包可防止修改攻击，因此本标准鼓励其扩散。虽然全面采用该数据包会造成互操作性问题，但快速采用仍然很重要。一个实现应该明确表示对这个数据包的支持，但是它可以从其他机制中推断出来。
For example, an implementation might infer from the use of a cipher such as Advanced Encryption Standard (AES) or Twofish that a user supports this feature. It might place in the unhashed portion of another user's key signature a Features subpacket. It might also present a user with an opportunity to regenerate their own self-signature with a Features subpacket.
例如，一个实现可能通过使用密码（如高级加密标准（AES）或Twofish）推断用户支持此功能。它可能会在另一个用户的密钥签名的未隐藏部分放置一个Features子包。它还可能为用户提供一个机会，使其能够使用Features子包重新生成自己的自签名。
This packet contains data encrypted with a symmetric-key algorithm and protected against modification by the SHA-1 hash algorithm. When it has been decrypted, it will typically contain other packets (often a Literal Data packet or Compressed Data packet). The last decrypted packet in this packet's payload MUST be a Modification Detection Code packet.
此数据包包含使用对称密钥算法加密的数据，并受到SHA-1哈希算法的保护以防修改。解密后，它通常会包含其他数据包（通常是文字数据包或压缩数据包）。此数据包有效负载中的最后一个解密数据包必须是修改检测代码数据包。
The body of this packet consists of:
本文件包正文包括：
- A one-octet version number. The only currently defined value is 1.
- 一个八位字节的版本号。当前唯一定义的值是1。
- Encrypted data, the output of the selected symmetric-key cipher operating in Cipher Feedback mode with shift amount equal to the block size of the cipher (CFB-n where n is the block size).
- 加密数据，在密码反馈模式下运行的选定对称密钥密码的输出，移位量等于密码的块大小（CFB-n，其中n是块大小）。
The symmetric cipher used MUST be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data packet. In either case, the cipher algorithm octet is prefixed to the session key before it is encrypted.
必须在对称加密数据包之前的公钥或对称密钥加密会话密钥包中指定使用的对称密码。在任何一种情况下，加密算法八位字节都会在会话密钥加密之前加上前缀。
The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes an octet string to the data before it is encrypted. The length of the octet string equals the block size of the cipher in octets, plus two. The first octets in the group, of length equal to the block size of the cipher, are random; the last two octets are each copies of their 2nd preceding octet. For example, with a cipher whose block size is 128 bits or 16 octets, the prefix data will contain 16 random octets, then two more octets, which are copies of the 15th and 16th octets, respectively. Unlike the Symmetrically Encrypted Data Packet, no special CFB resynchronization is done after encrypting this prefix data. See "OpenPGP CFB Mode" below for more details.
数据在CFB模式下加密，CFB移位大小等于密码的块大小。初始向量（IV）指定为全零。OpenPGP没有使用IV，而是在数据加密之前在其前面加上八位字节字符串。八位字节字符串的长度等于密码的块大小（以八位字节为单位）加上二。组中长度等于密码块大小的前八位字节是随机的；最后两个八位组分别是前两个八位组的副本。例如，对于块大小为128位或16个八位字节的密码，前缀数据将包含16个随机八位字节，然后再包含两个八位字节，分别是第15个和第16个八位字节的副本。与对称加密的数据包不同，加密此前缀数据后，不会进行特殊的CFB重新同步。有关更多详细信息，请参阅下面的“OpenPGP CFB模式”。
The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect.
在消息前缀的随机数据中重复16位，允许接收方立即检查会话密钥是否不正确。
The plaintext of the data to be encrypted is passed through the SHA-1 hash function, and the result of the hash is appended to the plaintext in a Modification Detection Code packet. The input to the hash function includes the prefix data described above; it includes all of the plaintext, and then also includes two octets of values 0xD3, 0x14. These represent the encoding of a Modification Detection Code packet tag and length field of 20 octets.
要加密的数据的明文通过SHA-1散列函数传递，并且散列的结果被附加到修改检测码分组中的明文。散列函数的输入包括上述前缀数据；它包括所有纯文本，然后还包括两个值为0xD3、0x14的八位字节。这些表示修改检测代码包标签和20个八位字节的长度字段的编码。
The resulting hash value is stored in a Modification Detection Code (MDC) packet, which MUST use the two octet encoding just given to represent its tag and length field. The body of the MDC packet is the 20-octet output of the SHA-1 hash.
生成的哈希值存储在修改检测码（MDC）数据包中，该数据包必须使用刚刚给出的两个八位组编码来表示其标记和长度字段。MDC数据包的主体是SHA-1散列的20个八位字节的输出。
The Modification Detection Code packet is appended to the plaintext and encrypted along with the plaintext using the same CFB context.
修改检测代码包附加到明文中，并使用相同的CFB上下文与明文一起加密。
During decryption, the plaintext data should be hashed with SHA-1, including the prefix data as well as the packet tag and length field of the Modification Detection Code packet. The body of the MDC packet, upon decryption, is compared with the result of the SHA-1 hash.
在解密期间，明文数据应使用SHA-1散列，包括前缀数据以及修改检测码分组的分组标签和长度字段。MDC数据包的主体在解密后与SHA-1散列的结果进行比较。
Any failure of the MDC indicates that the message has been modified and MUST be treated as a security problem. Failures include a 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 plaintext. Any failure SHOULD be reported to the user.
MDC的任何故障都表明消息已被修改，必须将其视为安全问题。失败包括散列值的差异，但也包括MDC数据包或MDC数据包不在明文末尾以外的任何位置。任何故障都应报告给用户。
Note: future designs of new versions of this packet should consider rollback attacks since it will be possible for an attacker to change the version back to 1.
注意：这个包的新版本的未来设计应该考虑回滚攻击，因为攻击者可以将版本更改为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.
创建MDC系统（称为数据包18和19）是为了提供一种完整性机制，该机制不如签名强大，但比裸露的CFB加密更强大。
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.)
CFB加密的一个限制是，对密文的损坏将损坏受影响的密码块和随后的块。此外，如果从CFB加密块的末尾删除数据，则无法检测到该删除。（还要注意，CBC模式也有类似的限制，但从块前面移除的数据是无法检测到的。）
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.
OpenPGP解决了这一需求，即比原始加密更安全，同时保持MDC系统的可否认性。MDC故意不是MAC。它的名字不是偶然选择的。它类似于校验和。
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 or identification and with a threat model that includes forgers, he has a problem that transcends mere cryptography.)
因此，因为它是一个适度的安全系统，所以它对所使用的哈希函数有适度的要求。它不依赖于无冲突的哈希函数，而是依赖于单向的哈希函数。如果伪造者弗兰克想给爱丽丝发送一条（数字）未签名的信息，上面写着“我一直暗恋着你，签名的鲍勃”，那么对他来说，构建一条新的信息要比修改从鲍勃那里截获的任何信息容易得多。（还请注意，如果Bob希望与Alice秘密通信，但没有身份验证或身份验证，并且使用包含伪造者的威胁模型，那么他的问题将超越单纯的加密技术。）
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.)
还要注意的是，与几乎所有其他OpenPGP子系统不同，MDC系统中没有参数。它很难将SHA-1定义为其哈希函数。这不是意外。这是一个有意的选择，以避免降级和跨等级攻击，同时使一个简单，快速的系统。（例如，降级攻击是将SHA-256替换为SHA-1的攻击。交叉等级攻击是将SHA-1替换为另一个160位哈希，例如CREAME-MD/160）
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 13.11 in the "IANA Considerations" for guidance.
然而，鉴于哈希函数密码分析和密码学的现状，可能需要将MDC系统升级为新的哈希函数。有关指南，请参见“IANA注意事项”中的第13.11节。
The Modification Detection Code packet contains a SHA-1 hash of plaintext data, which is used to detect message modification. It is only used with a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data that is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place.
修改检测码包包含明文数据的SHA-1散列，用于检测消息修改。它仅用于对称加密的完整性保护数据包。修改检测码分组必须是在对称加密的完整性保护数据分组中加密的明文数据中的最后一个分组，并且不得出现在其他任何地方。
A Modification Detection Code packet MUST have a length of 20 octets.
修改检测代码包的长度必须为20个八位字节。
The body of this packet consists of:
本文件包正文包括：
- A 20-octet SHA-1 hash of the preceding plaintext data of the Symmetrically Encrypted Integrity Protected Data packet, including prefix data, the tag octet, and length octet of the Modification Detection Code packet.
- 对称加密的完整性保护数据分组的先前明文数据的20个八位组SHA-1散列，包括修改检测码分组的前缀数据、标记八位组和长度八位组。
Note that the Modification Detection Code packet MUST always use a new format encoding of the packet tag, and a one-octet encoding of the packet length. The reason for this is that the hashing rules for modification detection include a one-octet tag and one-octet length in the data hash. While this is a bit restrictive, it reduces complexity.
注意，修改检测码分组必须始终使用分组标签的新格式编码和分组长度的一个八位编码。原因是用于修改检测的哈希规则在数据哈希中包括一个八位字节标记和一个八位字节长度。虽然这有点限制，但它降低了复杂性。
As stated in the introduction, OpenPGP's underlying native representation for objects is a stream of arbitrary octets, and some systems desire these objects to be immune to damage caused by character set translation, data conversions, etc.
如引言中所述，OpenPGP对象的底层本机表示是任意八位字节流，一些系统希望这些对象不受字符集转换、数据转换等造成的损害。
In principle, any printable encoding scheme that met the requirements of the unsafe channel would suffice, since it would not change the underlying binary bit streams of the native OpenPGP data structures. The OpenPGP standard specifies one such printable encoding scheme to ensure interoperability.
原则上，任何满足不安全通道要求的可打印编码方案都已足够，因为它不会改变本机OpenPGP数据结构的底层二进制位流。OpenPGP标准指定了一种这样的可打印编码方案，以确保互操作性。
OpenPGP's Radix-64 encoding is composed of two parts: a base64 encoding of the binary data and a checksum. The base64 encoding is identical to the MIME base64 content-transfer-encoding [RFC2045].
OpenPGP的基数-64编码由两部分组成：二进制数据的base64编码和校验和。base64编码与MIME base64内容传输编码[RFC2045]相同。
The checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to four characters of radix-64 encoding by the same MIME base64 transformation, preceded by an equal sign (=). The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. The accumulation is done on the data before it is converted to radix-64, rather than on the converted data. A sample implementation of this algorithm is in the next section.
校验和是一种24位循环冗余校验（CRC），通过相同的MIME base64转换转换转换为四个基数为64的字符，前面加一个等号（=）。CRC通过使用生成器0x864CFB和0xB704CE初始化来计算。在将数据转换为基数64之前，对数据进行累加，而不是对转换后的数据进行累加。下一节将介绍该算法的示例实现。
The checksum with its leading equal sign MAY appear on the first line after the base64 encoded data.
带前导等号的校验和可能出现在base64编码数据后的第一行。
Rationale for CRC-24: The size of 24 bits fits evenly into printable base64. The nonzero initialization can detect more errors than a zero initialization.
CRC-24的基本原理：24位的大小均匀地适合可打印的base64。非零初始化可以检测到比零初始化更多的错误。
#define CRC24_INIT 0xB704CEL #define CRC24_POLY 0x1864CFBL
#定义CRC24_INIT 0xB704CEL#定义CRC24_POLY 0x1864CFBL
typedef long crc24;
crc24 crc_octets(unsigned char *octets, size_t len)
{
crc24 crc = CRC24_INIT;
int i;
while (len--) {
crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) {
crc <<= 1;
if (crc & 0x1000000)
crc ^= CRC24_POLY;
}
}
return crc & 0xFFFFFFL;
}
typedef long crc24;
crc24 crc_octets(unsigned char *octets, size_t len)
{
crc24 crc = CRC24_INIT;
int i;
while (len--) {
crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) {
crc <<= 1;
if (crc & 0x1000000)
crc ^= CRC24_POLY;
}
}
return crc & 0xFFFFFFL;
}
When OpenPGP encodes data into ASCII Armor, it puts specific headers around the Radix-64 encoded data, so OpenPGP can reconstruct the data later. An OpenPGP implementation MAY use ASCII armor to protect raw binary data. OpenPGP informs the user what kind of data is encoded in the ASCII armor through the use of the headers.
当OpenPGP将数据编码为ASCII格式时，它会在基数为64的编码数据周围放置特定的头，以便OpenPGP以后可以重建数据。OpenPGP实现可以使用ASCII保护来保护原始二进制数据。OpenPGP通过使用头通知用户ASCII格式中编码的数据类型。
Concatenating the following data creates ASCII Armor:
连接以下数据将创建ASCII铠装：
- An Armor Header Line, appropriate for the type of data
- 适合于数据类型的标题行
- Armor Headers
- 装甲头
- A blank (zero-length, or containing only whitespace) line
- 空白行（长度为零，或仅包含空格）
- The ASCII-Armored data
- ASCII铠装数据
- An Armor Checksum
- 护甲校验和
- The Armor Tail, which depends on the Armor Header Line
- 装甲尾部，取决于装甲头线
An Armor Header Line consists of the appropriate header line text surrounded by five (5) dashes ('-', 0x2D) on either side of the header line text. The header line text is chosen based upon the type of data that is being encoded in Armor, and how it is being encoded. Header line texts include the following strings:
Armor标题行由相应的标题行文本组成，标题行文本两侧有五（5）个短划线（“-”，0x2D）环绕。标题行文本是根据Armor中编码的数据类型以及编码方式选择的。标题行文本包括以下字符串：
BEGIN PGP MESSAGE Used for signed, encrypted, or compressed files.
用于签名、加密或压缩文件的BEGIN PGP消息。
BEGIN PGP PUBLIC KEY BLOCK Used for armoring public keys.
开始用于铠装公钥的PGP公钥块。
BEGIN PGP PRIVATE KEY BLOCK Used for armoring private keys.
开始用于铠装私钥的PGP私钥块。
BEGIN PGP MESSAGE, PART X/Y Used for multi-part messages, where the armor is split amongst Y parts, and this is the Xth part out of Y.
开始PGP消息，用于多部分消息的X/Y部分，装甲在Y部分之间分割，这是Y中的第X部分。
BEGIN PGP MESSAGE, PART X Used for multi-part messages, where this is the Xth part of an unspecified number of parts. Requires the MESSAGE-ID Armor Header to be used.
BEGIN PGP MESSAGE，用于多部分消息的第X部分，其中这是未指定数量部分的第X部分。需要使用MESSAGE-ID Armor标头。
BEGIN PGP SIGNATURE Used for detached signatures, OpenPGP/MIME signatures, and cleartext signatures. Note that PGP 2.x uses BEGIN PGP MESSAGE for detached signatures.
开始用于分离签名、OpenPGP/MIME签名和明文签名的PGP签名。请注意，PGP2.x使用BEGIN PGP消息来分离签名。
Note that all these Armor Header Lines are to consist of a complete line. That is to say, there is always a line ending preceding the starting five dashes, and following the ending five dashes. The header lines, therefore, MUST start at the beginning of a line, and MUST NOT have text other than whitespace following them on the same line. These line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit. This is particularly important when computing a cleartext signature (see below).
请注意，所有这些装甲头线都由一条完整的线组成。也就是说，在开始的五条破折号之前和结束的五条破折号之后总是有一条线结束。因此，标题行必须从行的开头开始，并且在同一行上，标题行后面不能有除空格以外的文本。这些线条端点被视为装甲标题线条的一部分，用于确定它们所界定的内容。这在计算明文签名时尤其重要（见下文）。
The Armor Headers are pairs of strings that can give the user or the receiving OpenPGP implementation some information about how to decode or use the message. The Armor Headers are a part of the armor, not a part of the message, and hence are not protected by any signatures applied to the message.
Armor头是一对字符串，可以为用户或接收OpenPGP实现提供有关如何解码或使用消息的一些信息。装甲头是装甲的一部分，而不是消息的一部分，因此不受应用于消息的任何签名的保护。
The format of an Armor Header is that of a key-value pair. A colon (':' 0x38) and a single space (0x20) separate the key and value. OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. Unknown keys should be reported to the user, but OpenPGP should continue to process the message.
Armor头的格式是键值对的格式。冒号（“：”0x38）和单个空格（0x20）分隔键和值。OpenPGP应考虑不正确格式化的装甲标头是ASCII装甲的破坏。未知密钥应报告给用户，但OpenPGP应继续处理该消息。
Note that some transport methods are sensitive to line length. While there is a limit of 76 characters for the Radix-64 data (Section 6.3), there is no limit to the length of Armor Headers. Care should
请注意，某些传输方法对线路长度很敏感。虽然基数为64的数据限制为76个字符（第6.3节），但Armor头的长度没有限制。当心
be taken that the Armor Headers are short enough to survive transport. One way to do this is to repeat an Armor Header key multiple times with different values for each so that no one line is overly long.
需要注意的是，装甲头足够短，足以承受运输。一种方法是使用不同的值重复Armor头键多次，这样就不会有一行过长。
Currently defined Armor Header Keys are as follows:
当前定义的Armor标头键如下所示：
- "Version", which states the OpenPGP implementation and version used to encode the message.
- “版本”，说明OpenPGP实现和用于编码消息的版本。
- "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. Consequently, if a comment has characters that are outside the US-ASCII range of UTF, they may very well not survive transport.
- “注释”，用户定义的注释。OpenPGP将所有文本定义为UTF-8格式。注释可以是任何UTF-8字符串。然而，铠装的全部目的是提供七位干净的数据。因此，如果注释中的字符超出了UTF的US-ASCII范围，则它们很可能无法在传输中存活。
- "MessageID", a 32-character string of printable characters. The string must be the same for all parts of a multi-part message that uses the "PART X" Armor Header. MessageID strings should be unique enough that the recipient of the mail can associate all the parts of a message with each other. A good checksum or cryptographic hash function is sufficient.
- “MessageID”，一个32个字符的可打印字符字符串。对于使用“part X”标题的多部分消息的所有部分，字符串必须相同。MessageID字符串应足够唯一，以便邮件收件人可以将邮件的所有部分相互关联。一个好的校验和或加密哈希函数就足够了。
The MessageID SHOULD NOT appear unless it is in a multi-part message. If it appears at all, it MUST be computed from the finished (encrypted, signed, etc.) message in a deterministic fashion, rather than contain a purely random value. This is to allow the legitimate recipient to determine that the MessageID cannot serve as a covert means of leaking cryptographic key information.
MessageID不应出现，除非它位于多部分消息中。如果它出现了，则必须以确定的方式从完成的（加密、签名等）消息中计算出来，而不是包含一个纯粹的随机值。这是为了允许合法收件人确定MessageID不能作为泄露加密密钥信息的隐蔽手段。
- "Hash", a comma-separated list of hash algorithms used in this message. This is used only in cleartext signed messages.
- “Hash”，此消息中使用的哈希算法的逗号分隔列表。这仅用于明文签名的消息。
- "Charset", a description of the character set that the plaintext is in. Please note that OpenPGP defines text to be in UTF-8. An implementation will get best results by translating into and out of UTF-8. However, there are many instances where this is easier said than done. Also, there are communities of users who have no need for UTF-8 because they are all happy with a character set like ISO Latin-5 or a Japanese character set. In such instances, an implementation MAY override the UTF-8 default by using this header key. An implementation MAY implement this key and any translations it cares to; an implementation MAY ignore it and assume all text is UTF-8.
- “字符集”，对明文所在字符集的描述。请注意，OpenPGP将文本定义为UTF-8格式。通过将UTF-8转换成UTF-8，实现将获得最佳结果。然而，在许多情况下，这说起来容易做起来难。此外，还有一些用户社区不需要UTF-8，因为他们都喜欢ISO拉丁语-5或日语字符集这样的字符集。在这种情况下，实现可以通过使用此头密钥覆盖UTF-8默认值。一个实现可以实现这个密钥和它关心的任何翻译；实现可能会忽略它，并假定所有文本都是UTF-8。
The Armor Tail Line is composed in the same manner as the Armor Header Line, except the string "BEGIN" is replaced by the string "END".
装甲尾线的组成方式与装甲头线相同，只是字符串“开始”替换为字符串“结束”。
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating three 8-bit input groups. These 24 bits are then treated as four concatenated 6-bit groups, each of which is translated into a single digit in the Radix-64 alphabet. When encoding a bit stream with the Radix-64 encoding, the bit stream must be presumed to be ordered with the most significant bit first. That is, the first bit in the stream will be the high-order bit in the first 8-bit octet, and the eighth bit will be the low-order bit in the first 8-bit octet, and so on.
编码过程将输入位的24位组表示为4个编码字符的输出字符串。从左到右，通过连接三个8位输入组形成24位输入组。然后将这24位视为四个串联的6位组，每个组被转换为基数为64的字母表中的一个数字。当使用基数-64编码对位流进行编码时，必须假定该位流以最高有效位优先排序。也就是说，流中的第一位将是第一个8位八位组中的高阶位，第八位将是第一个8位八位组中的低阶位，依此类推。
+--first octet--+-second octet--+--third octet--+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
+--first octet--+-second octet--+--third octet--+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
Each 6-bit group is used as an index into an array of 64 printable characters from the table below. The character referenced by the index is placed in the output string.
每个6位组用作下表中64个可打印字符数组的索引。索引引用的字符被放置在输出字符串中。
Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y
数值编码数值编码数值编码数值编码数值编码0a17r34i51z1b18s35j520c19t36k531d20u37l542e21v21v21v38m5535f22w39n5646g23x40o577h24y41p5868i25z42q597j26a43r60810k27b6111l28t62+12m29d46u63/13n30e47v31f48w（pad）=15 P 32 g 49 x 16 Q 33 h 50 y
The encoded output stream must be represented in lines of no more than 76 characters each.
编码的输出流必须以不超过76个字符的行表示。
Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. There are three possibilities:
如果在编码的数据末尾可用的位少于24位，则执行特殊处理。有三种可能性：
1. The last data group has 24 bits (3 octets). No special processing is needed.
1. 最后一个数据组有24位（3个八位字节）。无需特殊处理。
2. The last data group has 16 bits (2 octets). The first two 6-bit groups are processed as above. The third (incomplete) data group has two zero-value bits added to it, and is processed as above. A pad character (=) is added to the output.
2. 最后一个数据组有16位（2个八位字节）。前两个6位组的处理如上所述。第三个（不完整）数据组添加了两个零值位，并按上述方式进行处理。一个填充字符（=）被添加到输出中。
3. The last data group has 8 bits (1 octet). The first 6-bit group is processed as above. The second (incomplete) data group has four zero-value bits added to it, and is processed as above. Two pad characters (=) are added to the output.
3. 最后一个数据组有8位（1个八位字节）。第一个6位组的处理如上所述。第二个（不完整）数据组添加了四个零值位，并按上述方式进行处理。输出中添加了两个pad字符（=）。
In Radix-64 data, characters other than those in the table, line breaks, and other white space probably indicate a transmission error, about which a warning message or even a message rejection might be appropriate under some circumstances. Decoding software must ignore all white space.
在基数为64的数据中，表中字符以外的字符、换行符和其他空白可能表示传输错误，在某些情况下，可能需要发出警告消息，甚至拒绝消息。解码软件必须忽略所有空白。
Because it is used only for padding at the end of the data, the occurrence of any "=" characters may be taken as evidence that the end of the data has been reached (without truncation in transit). No such assurance is possible, however, when the number of octets transmitted was a multiple of three and no "=" characters are present.
由于它仅用于数据结尾处的填充，因此任何“=”字符的出现都可以作为已到达数据结尾的证据（在传输过程中没有截断）。然而，当传输的八位字节数是三的倍数且不存在“=”字符时，不可能有这样的保证。
Input data: 0x14FB9C03D97E
Hex: 1 4 F B 9 C | 0 3 D 9 7 E
8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110
6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110
Decimal: 5 15 46 28 0 61 37 62
Output: F P u c A 9 l +
Input data: 0x14FB9C03D9
Hex: 1 4 F B 9 C | 0 3 D 9
8-bit: 00010100 11111011 10011100 | 00000011 11011001
pad with 00
6-bit: 000101 001111 101110 011100 | 000000 111101 100100
Decimal: 5 15 46 28 0 61 36
pad with =
Output: F P u c A 9 k =
Input data: 0x14FB9C03
Hex: 1 4 F B 9 C | 0 3
8-bit: 00010100 11111011 10011100 | 00000011
pad with 0000
6-bit: 000101 001111 101110 011100 | 000000 110000
Decimal: 5 15 46 28 0 48
pad with = =
Output: F P u c A w = =
Input data: 0x14FB9C03D97E
Hex: 1 4 F B 9 C | 0 3 D 9 7 E
8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110
6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110
Decimal: 5 15 46 28 0 61 37 62
Output: F P u c A 9 l +
Input data: 0x14FB9C03D9
Hex: 1 4 F B 9 C | 0 3 D 9
8-bit: 00010100 11111011 10011100 | 00000011 11011001
pad with 00
6-bit: 000101 001111 101110 011100 | 000000 111101 100100
Decimal: 5 15 46 28 0 61 36
pad with =
Output: F P u c A 9 k =
Input data: 0x14FB9C03
Hex: 1 4 F B 9 C | 0 3
8-bit: 00010100 11111011 10011100 | 00000011
pad with 0000
6-bit: 000101 001111 101110 011100 | 000000 110000
Decimal: 5 15 46 28 0 48
pad with = =
Output: F P u c A w = =
-----BEGIN PGP MESSAGE-----
Version: OpenPrivacy 0.99
-----BEGIN PGP MESSAGE-----
Version: OpenPrivacy 0.99
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA==
=njUN
-----END PGP MESSAGE-----
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA==
=njUN
-----END PGP MESSAGE-----
Note that this example has extra indenting; an actual armored message would have no leading whitespace.
注意这个例子有额外的缩进；实际的装甲邮件将没有前导空格。
It is desirable to be able to sign a textual octet stream without ASCII armoring the stream itself, so the signed text is still readable without special software. In order to bind a signature to such a cleartext, this framework is used. (Note that this framework is not intended to be reversible. RFC 3156 [RFC3156] defines another way to sign cleartext messages for environments that support MIME.)
希望能够对文本八位字节流进行签名，而无需对流本身进行ASCII铠装，因此签名文本在无需特殊软件的情况下仍然可读。为了将签名绑定到这样的明文，使用了这个框架。（请注意，此框架并不打算是可逆的。RFC 3156[RFC3156]为支持MIME的环境定义了另一种签署明文消息的方法。）
The cleartext signed message consists of:
明文签名的消息包括：
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a single line,
- 明文标题“----开始PGP签名消息”--在一行上，
- One or more "Hash" Armor Headers,
- 一个或多个“散列”装甲头，
- Exactly one empty line not included into the message digest,
- 只有一行空行未包含在消息摘要中，
- The dash-escaped cleartext that is included into the message digest,
- 包含在消息摘要中的破折号转义明文，
- The ASCII armored signature(s) including the '-----BEGIN PGP SIGNATURE-----' Armor Header and Armor Tail Lines.
- ASCII装甲签名，包括“-----开始PGP签名---”装甲头线和装甲尾线。
If the "Hash" Armor Header is given, the specified message digest algorithm(s) are used for the signature. If there are no such headers, MD5 is used. If MD5 is the only hash used, then an implementation MAY omit this header for improved V2.x compatibility. If more than one message digest is used in the signature, the "Hash" armor header contains a comma-delimited list of used message digests.
如果给出了“散列”标题，则签名将使用指定的消息摘要算法。如果没有这样的头，则使用MD5。如果MD5是唯一使用的哈希，那么实现可能会省略此头以提高V2.x兼容性。如果签名中使用了多个消息摘要，“哈希”标题包含一个逗号分隔的已用消息摘要列表。
Current message digest names are described below with the algorithm IDs.
下面用算法ID描述了当前消息摘要名称。
An implementation SHOULD add a line break after the cleartext, but MAY omit it if the cleartext ends with a line break. This is for visual clarity.
一个实现应该在明文之后添加一个换行符，但是如果明文以换行符结尾，可能会忽略它。这是为了视觉清晰度。
The cleartext content of the message must also be dash-escaped.
消息的明文内容也必须进行破折号转义。
Dash-escaped cleartext is the ordinary cleartext where every line starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and space ' ' (0x20). This prevents the parser from recognizing armor headers of the cleartext itself. An implementation MAY dash-escape any line, SHOULD dash-escape lines commencing "From" followed by a space, and MUST dash-escape any line commencing in a dash. The message digest is computed using the cleartext itself, not the dash-escaped form.
破折号转义明文是普通明文，其中以破折号“-”（0x2D）开头的每一行都以破折号“-”（0x2D）和空格“”作为前缀。这会阻止解析器识别明文本身的标题。一个实现可以破折号逃逸任何一行，破折号逃逸线应该从“From”开始，后面跟一个空格，并且必须破折号逃逸从破折号开始的任何一行。消息摘要是使用明文本身而不是破折号转义形式计算的。
As with binary signatures on text documents, a cleartext signature is
calculated on the text using canonical <CR><LF> line endings. The
line ending (i.e., the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text.
As with binary signatures on text documents, a cleartext signature is
calculated on the text using canonical <CR><LF> line endings. The
line ending (i.e., the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text.
When reversing dash-escaping, an implementation MUST strip the string "- " if it occurs at the beginning of a line, and SHOULD warn on "-" and any character other than a space at the beginning of a line.
在反转破折号转义时，如果字符串“-”出现在行首，则实现必须去除该字符串，并应警告“-”和行首空格以外的任何字符。
Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is removed when the cleartext signature is generated.
此外，当生成明文签名时，任何行末尾的任何尾随空格——空格（0x20）和制表符（0x09）——都将被删除。
A regular expression is zero or more branches, separated by '|'. It matches anything that matches one of the branches.
正则表达式是零个或多个分支，由“|”分隔。它匹配与其中一个分支匹配的任何对象。
A branch is zero or more pieces, concatenated. It matches a match for the first, followed by a match for the second, etc.
分支是零个或多个连接的片段。它与第一个匹配，然后与第二个匹配，以此类推。
A piece is an atom possibly followed by '*', '+', or '?'. An atom followed by '*' matches a sequence of 0 or more matches of the atom. An atom followed by '+' matches a sequence of 1 or more matches of the atom. An atom followed by '?' matches a match of the atom, or the null string.
片段是一个原子，后面可能跟有“*”、“+”或“？”。一个或多个原子序列的“*”匹配。后跟“+”的原子匹配该原子的一个或多个匹配序列。后跟“？”的原子与该原子的匹配项或空字符串匹配。
An atom is a regular expression in parentheses (matching a match for the regular expression), a range (see below), '.' (matching any single character), '^' (matching the null string at the beginning of the input string), '$' (matching the null string at the end of the input string), a '\' followed by a single character (matching that character), or a single character with no other significance (matching that character).
原子是括号中的正则表达式（匹配正则表达式）、范围（见下文）、“.”（匹配任何单个字符）、“^”（匹配输入字符串开头的空字符串）、“$”（匹配输入字符串结尾的空字符串）、后跟单个字符的“\”（匹配该字符），或者一个没有其他意义的字符（匹配该字符）。
A range is a sequence of characters enclosed in '[]'. It normally matches any single character from the sequence. If the sequence begins with '^', it matches any single character not from the rest of the sequence. If two characters in the sequence are separated by '-', this is shorthand for the full list of ASCII characters between them (e.g., '[0-9]' matches any decimal digit). To include a literal ']' in the sequence, make it the first character (following a possible '^'). To include a literal '-', make it the first or last character.
范围是包含在“[]”中的字符序列。它通常匹配序列中的任何单个字符。如果序列以“^”开头，它将匹配序列其余部分以外的任何单个字符。如果序列中的两个字符以“-”分隔，则这是它们之间ASCII字符的完整列表的缩写（例如，“[0-9]”匹配任何十进制数字）。要在序列中包含文字']'，请将其作为第一个字符（可能的'^'后面）。要包含文字'-'，请将其作为第一个或最后一个字符。
This section describes the constants used in OpenPGP.
本节介绍OpenPGP中使用的常量。
Note that these tables are not exhaustive lists; an implementation MAY implement an algorithm not on these lists, so long as the algorithm numbers are chosen from the private or experimental algorithm range.
请注意，这些表格并非详尽无遗的列表；实现可以实现不在这些列表上的算法，只要算法编号是从私有或实验算法范围中选择的。
See the section "Notes on Algorithms" below for more discussion of the algorithms.
有关算法的更多讨论，请参见下面的“算法注释”部分。
ID Algorithm
-- ---------
1 - RSA (Encrypt or Sign) [HAC]
2 - RSA Encrypt-Only [HAC]
3 - RSA Sign-Only [HAC]
16 - Elgamal (Encrypt-Only) [ELGAMAL] [HAC]
17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA
20 - Reserved (formerly Elgamal Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm
ID Algorithm
-- ---------
1 - RSA (Encrypt or Sign) [HAC]
2 - RSA Encrypt-Only [HAC]
3 - RSA Sign-Only [HAC]
16 - Elgamal (Encrypt-Only) [ELGAMAL] [HAC]
17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA
20 - Reserved (formerly Elgamal Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm
Implementations MUST implement DSA for signatures, and Elgamal for encryption. Implementations SHOULD implement RSA keys (1). RSA Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be generated, but may be interpreted. See Section 13.5. See Section 13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement any other algorithm.
实现必须实现签名的DSA和加密的Elgamal。实现应该实现RSA密钥（1）。RSA Encrypt Only（2）和RSA Sign Only已弃用，不应生成，但可能会被解释。见第13.5节。有关椭圆曲线（18）、ECDSA（19）、Elgamal加密或签名（20）和X9.42（21）的注释，请参见第13.8节。实现可以实现任何其他算法。
ID Algorithm
-- ---------
0 - Plaintext or unencrypted data
1 - IDEA [IDEA]
2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
168 bit key derived from 192)
3 - CAST5 (128 bit key, as per [RFC2144])
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - Reserved
6 - Reserved
7 - AES with 128-bit key [AES]
8 - AES with 192-bit key
9 - AES with 256-bit key
10 - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm
ID Algorithm
-- ---------
0 - Plaintext or unencrypted data
1 - IDEA [IDEA]
2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
168 bit key derived from 192)
3 - CAST5 (128 bit key, as per [RFC2144])
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - Reserved
6 - Reserved
7 - AES with 128-bit key [AES]
8 - AES with 192-bit key
9 - AES with 256-bit key
10 - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm
Implementations MUST implement TripleDES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate with
实现必须实现三元组。实现应实现AES-128和CAST5。与互操作的实现
PGP 2.6 or earlier need to support IDEA, as that is the only symmetric cipher those versions use. Implementations MAY implement any other algorithm.
PGP2.6或更早版本需要支持IDEA，因为这是这些版本使用的唯一对称密码。实现可以实现任何其他算法。
ID Algorithm
-- ---------
0 - Uncompressed
1 - ZIP [RFC1951]
2 - ZLIB [RFC1950]
3 - BZip2 [BZ2]
100 to 110 - Private/Experimental algorithm
ID Algorithm
-- ---------
0 - Uncompressed
1 - ZIP [RFC1951]
2 - ZLIB [RFC1950]
3 - BZip2 [BZ2]
100 to 110 - Private/Experimental algorithm
Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. Implementations MAY implement any other algorithm.
实现必须实现未压缩的数据。实现应该实现ZIP。实现可以实现任何其他算法。
ID Algorithm Text Name
-- --------- ---------
1 - MD5 [HAC] "MD5"
2 - SHA-1 [FIPS180] "SHA1"
3 - RIPE-MD/160 [HAC] "RIPEMD160"
4 - Reserved
5 - Reserved
6 - Reserved
7 - Reserved
8 - SHA256 [FIPS180] "SHA256"
9 - SHA384 [FIPS180] "SHA384"
10 - SHA512 [FIPS180] "SHA512"
11 - SHA224 [FIPS180] "SHA224"
100 to 110 - Private/Experimental algorithm
ID Algorithm Text Name
-- --------- ---------
1 - MD5 [HAC] "MD5"
2 - SHA-1 [FIPS180] "SHA1"
3 - RIPE-MD/160 [HAC] "RIPEMD160"
4 - Reserved
5 - Reserved
6 - Reserved
7 - Reserved
8 - SHA256 [FIPS180] "SHA256"
9 - SHA384 [FIPS180] "SHA384"
10 - SHA512 [FIPS180] "SHA512"
11 - SHA224 [FIPS180] "SHA224"
100 to 110 - Private/Experimental algorithm
Implementations MUST implement SHA-1. Implementations MAY implement other algorithms. MD5 is deprecated.
实现必须实现SHA-1。实现可以实现其他算法。MD5已被弃用。
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.
OpenPGP是高度参数化的，因此在为扩展分配参数时需要考虑很多因素。本节介绍IANA应如何看待本文档中所述的协议扩展。
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 Section 3.7.1. Adding a new S2K specifier MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP S2K说明符包含一种新算法将字符串转换为密钥的机制。本规范创建S2K说明符类型的注册表。注册表包括S2K类型、S2K的名称和对定义规范的引用。该注册表的初始值见第3.7.1节。如[RFC2434]所述，必须通过IETF共识方法添加新的S2K说明符。
Major new features of OpenPGP are defined through 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 Section 4.3. Adding a new packet type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP的主要新特性是通过新的数据包类型定义的。此规范创建数据包类型的注册表。注册表包括数据包类型、数据包名称和对定义规范的引用。该注册表的初始值可在第4.3节中找到。如[RFC2434]所述，必须通过IETF共识方法添加新的数据包类型。
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 Section 5.12. Adding a new User Attribute type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
用户属性包允许用于其他类型证书标识的可扩展机制。此规范创建用户属性类型的注册表。注册表包括用户属性类型、用户属性的名称以及对定义规范的引用。该注册表的初始值见第5.12节。如[RFC2434]所述，必须通过IETF共识方法添加新的用户属性类型。
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 Section 5.12.1. Adding a new Image Attribute subpacket type MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
在用户属性包中，有一种可扩展的机制，用于其他类型的基于图像的用户属性。此规范创建图像属性子包类型的注册表。注册表包括图像属性子包类型、图像属性子包的名称以及对定义规范的引用。该注册表的初始值见第5.12.1节。如[RFC2434]所述，必须通过IETF一致方法添加新的图像属性子包类型。
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
OpenPGP签名包含一种机制，用于将签名（或未签名）数据添加到签名子包中，以用于第5.2.3.1节中讨论的各种目的。此规范创建签名子包类型的注册表。注册表包括签名子包类型、子包的名称以及对定义规范的引用。的初始值
this registry can be found in Section 5.2.3.1. Adding a new Signature subpacket MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
该注册表可在第5.2.3.1节中找到。如[RFC2434]所述，必须通过IETF共识方法添加新的签名子包。
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 that is completely unmanaged and an IETF space.
OpenPGP签名还包含签名扩展机制。这些是表示法数据子包，其中包含一个键/值对。符号包含完全非托管的用户空间和IETF空间。
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 Section 5.2.3.16. Adding a new Signature Notation Data subpacket MUST be done through the EXPERT REVIEW method, as described in [RFC2434].
本规范创建签名符号数据类型的注册表。注册表包括签名符号数据类型、签名符号数据的名称、允许的值以及对定义规范的引用。该注册表的初始值见第5.2.3.16节。如[RFC2434]所述，必须通过专家评审方法添加新的签名符号数据子包。
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 Section 5.2.3.17. Adding a new key server preference MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP签名包含一种机制，用于指定有关密钥服务器的首选项。此规范创建密钥服务器首选项的注册表。注册表包括密钥服务器首选项、首选项的名称以及对定义规范的引用。该注册表的初始值见第5.2.3.17节。如[RFC2434]所述，必须通过IETF共识方法添加新的密钥服务器首选项。
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 Section 5.2.3.21. Adding a new key usage flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP签名包含一种机制，用于指定有关密钥使用的标志。此规范创建密钥使用标志的注册表。注册表包括键标志值、标志名称和对定义规范的引用。该注册表的初始值见第5.2.3.21节。如[RFC2434]所述，必须通过IETF共识方法添加新的密钥使用标志。
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 Section 5.2.3.23. Adding a new feature flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP签名包含一种机制，用于指定有关密钥被吊销原因的标志。本规范创建一个“撤销原因”标志的注册表。注册表包括“撤销原因”标志值、标志名称和对定义规范的引用。该注册表的初始值见第5.2.3.23节。如[RFC2434]所述，必须通过IETF共识方法添加新的功能标志。
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 Section 5.2.3.24. Adding a new feature-implementation flag MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP签名包含一种机制，用于指定标志，说明实现支持哪些可选功能。此规范创建功能实现标志的注册表。注册表包括特性实现标志值、标志名称和对定义规范的引用。该注册表的初始值见第5.2.3.24节。如[RFC2434]所述，必须通过IETF共识方法添加新的功能实现标志。
Also see Section 13.12 for more information about when feature flags are needed.
有关何时需要功能标志的更多信息，请参见第13.12节。
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 Section 5. Adding a new packet version MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
核心OpenPGP包都有版本号，可以通过引入现有包的新版本进行修改。此规范创建数据包类型的注册表。注册表包括数据包类型、版本号和对定义规范的引用。该注册表的初始值可在第5节中找到。如[RFC2434]所述，必须通过IETF共识方法添加新的数据包版本。
Section 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 made mainly for emphasis.
第9节列出了OpenPGP使用的核心算法。加入一个新的算法通常很简单。例如，添加一个新的对称密码通常只需要为该密码分配一个常量。如果该密码的块大小不是64位或128位，则可能需要额外的文档来描述如何调整OpenPGP CFB模式。类似地，当DSA从1024位公钥的最大值扩展到3072位公钥时，FIPS 186的修订版本身包含足够的信息以允许实现。本文件的修改主要是为了强调重点。
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].
OpenPGP指定了许多公钥算法。此规范创建公钥算法标识符的注册表。注册表包括算法名称、密钥大小和参数，以及对定义规范的引用。该注册表的初始值可在第9节中找到。如[RFC2434]所述，必须通过IETF协商一致方法添加新的公钥算法。
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].
OpenPGP指定了许多对称密钥算法。此规范创建对称密钥算法标识符的注册表。注册表包括算法名称、其键大小和块大小，以及对定义规范的引用。该注册表的初始值可在第9节中找到。如[RFC2434]所述，必须通过IETF一致性方法添加新的对称密钥算法。
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].
OpenPGP指定了许多散列算法。此规范创建哈希算法标识符的注册表。注册表包括算法名称、该名称的文本表示、其块大小、OID哈希前缀和对定义规范的引用。该注册表的初始值可在第9节中找到算法标识符和文本名称，在第5.2.2节中找到OID和扩展签名前缀。如[RFC2434]所述，必须通过IETF共识方法添加新的哈希算法。
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.3. Adding a new compression key algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
OpenPGP指定了许多压缩算法。此规范创建压缩算法标识符的注册表。注册表包括算法名称和对定义规范的引用。该注册表的初始值见第9.3节。如[RFC2434]所述，必须通过IETF一致性方法添加新的压缩密钥算法。
OpenPGP packets are assembled into sequences in order to create messages and to transfer keys. Not all possible packet sequences are meaningful and correct. This section describes the rules for how packets should be placed into sequences.
OpenPGP数据包被组装成序列，以便创建消息和传输密钥。并非所有可能的数据包序列都是有意义和正确的。本节介绍如何将数据包放入序列中的规则。
OpenPGP users may transfer public keys. The essential elements of a transferable public key are as follows:
OpenPGP用户可以传输公钥。可转让公钥的基本要素如下：
- One Public-Key packet
- 一个公钥包
- Zero or more revocation signatures
- 零个或多个撤销签名
- One or more User ID packets
- 一个或多个用户ID数据包
- After each User ID packet, zero or more Signature packets (certifications)
- 在每个用户ID数据包之后，零个或多个签名数据包（证书）
- Zero or more User Attribute packets
- 零个或多个用户属性数据包
- After each User Attribute packet, zero or more Signature packets (certifications)
- 在每个用户属性数据包之后，零个或多个签名数据包（证书）
- Zero or more Subkey packets
- 零个或多个子密钥包
- After each Subkey packet, one Signature packet, plus optionally a revocation
- 在每个子密钥包之后，一个签名包，以及可选的撤销
The Public-Key packet occurs first. Each of the following User ID packets provides the identity of the owner of this public key. If there are multiple User ID packets, this corresponds to multiple means of identifying the same unique individual user; for example, a user may have more than one email address, and construct a User ID for each one.
公钥包首先出现。以下每个用户ID数据包都提供此公钥所有者的身份。如果存在多个用户ID分组，则这对应于识别相同唯一个人用户的多个方法；例如，用户可能有多个电子邮件地址，并为每个电子邮件地址构造一个用户ID。
Immediately following each User ID packet, there are zero or more Signature packets. Each Signature packet is calculated on the immediately preceding User ID packet and the initial Public-Key packet. The signature serves to certify the corresponding public key and User ID. In effect, the signer is testifying to his or her belief that this public key belongs to the user identified by this User ID.
紧接着每个用户ID数据包，就有零个或多个签名数据包。每个签名包都是在紧接前一个用户ID包和初始公钥包上计算的。签名用于证明相应的公钥和用户ID。实际上，签名者证明他或她相信该公钥属于该用户ID标识的用户。
Within the same section as the User ID packets, there are zero or more User Attribute packets. Like the User ID packets, a User Attribute packet is followed by zero or more Signature packets calculated on the immediately preceding User Attribute packet and the initial Public-Key packet.
在与用户ID数据包相同的部分中，存在零个或多个用户属性数据包。与用户ID分组一样，用户属性分组后面紧跟着零个或多个签名分组，这些签名分组是在紧接前的用户属性分组和初始公钥分组上计算的。
User Attribute packets and User ID packets may be freely intermixed in this section, so long as the signatures that follow them are maintained on the proper User Attribute or User ID packet.
在本节中，用户属性数据包和用户ID数据包可以自由混合，只要在适当的用户属性数据包或用户ID数据包上保留它们后面的签名。
After the User ID packet or Attribute packet, there may be zero or more Subkey packets. 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, and the subkeys may be encryption-only keys, signature-only keys, or general-purpose keys. V3 keys MUST NOT have subkeys.
在用户ID分组或属性分组之后，可能存在零个或多个子密钥分组。通常，在顶级公钥是仅签名密钥的情况下提供子密钥。然而，任何V4密钥都可以具有子密钥，并且子密钥可以是仅加密密钥、仅签名密钥或通用密钥。V3键不能有子键。
Each Subkey packet MUST be followed by one Signature packet, which should be a subkey binding signature issued by the top-level key. For subkeys that can issue signatures, the subkey binding signature MUST contain an Embedded Signature subpacket with a primary key binding signature (0x19) issued by the subkey on the top-level key.
每个子密钥包后面必须有一个签名包，该签名包应该是由顶级密钥发布的子密钥绑定签名。对于可以发出签名的子密钥，子密钥绑定签名必须包含一个嵌入的签名子包，该子包具有由顶级密钥上的子密钥发出的主键绑定签名（0x19）。
Subkey and Key packets may each be followed by a revocation Signature packet to indicate that the key is revoked. Revocation 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 Key subpacket in a self-signature by the top-level key.
子密钥和密钥分组可各自后跟撤销签名分组，以指示密钥被撤销。只有当撤销签名是由密钥本身发出的，或者是由顶级密钥通过自签名中的撤销密钥子包授权发出撤销的密钥发出的时，才接受撤销签名。
Transferable public-key packet sequences may be concatenated to allow transferring multiple public keys in one operation.
可转移公钥分组序列可被串联以允许在一个操作中转移多个公钥。
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 and secret-subkey packets are used instead of the public key and public-subkey packets. Implementations SHOULD include self-signatures on any user IDs and subkeys, as this allows for a complete public key to be automatically extracted from the transferable secret key. Implementations MAY choose to omit the self-signatures, especially if a transferable public key accompanies the transferable secret key.
OpenPGP用户可以传输密钥。可转移密钥的格式与可转移公钥的格式相同，只是使用了密钥和秘密子密钥包，而不是公钥和公开子密钥包。实现应该包括对任何用户ID和子密钥的自签名，因为这允许从可转移密钥中自动提取完整的公钥。实现可以选择省略自签名，特别是当可转移公钥伴随可转移密钥时。
An OpenPGP message is a packet or sequence of packets that corresponds to the following grammatical rules (comma represents sequential composition, and vertical bar separates alternatives):
OpenPGP消息是与以下语法规则相对应的数据包或数据包序列（逗号表示顺序组合，竖线分隔备选方案）：
OpenPGP Message :- Encrypted Message | Signed Message | Compressed Message | Literal Message.
OpenPGP消息：-加密消息|签名消息|压缩消息|文字消息。
Compressed Message :- Compressed Data Packet.
压缩消息：-压缩数据包。
Literal Message :- Literal Data Packet.
文字信息：-文字数据包。
ESK :- Public-Key Encrypted Session Key Packet | Symmetric-Key Encrypted Session Key Packet.
ESK:-公钥加密会话密钥包|对称密钥加密会话密钥包。
ESK Sequence :- ESK | ESK Sequence, ESK.
ESK序列：ESK | ESK序列，ESK。
Encrypted Data :- Symmetrically Encrypted Data Packet | Symmetrically Encrypted Integrity Protected Data Packet
加密数据：-对称加密数据包|对称加密完整性保护数据包
Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data.
加密消息：-加密数据| ESK序列，加密数据。
One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packet.
一次签名报文：-一次签名报文，OpenPGP报文，对应的签名报文。
Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message.
签名消息：-签名包，OpenPGP消息|一次通过签名消息。
In addition, decrypting a Symmetrically Encrypted Data packet or a Symmetrically Encrypted Integrity Protected Data packet as well as decompressing a Compressed Data packet must yield a valid OpenPGP Message.
此外，解密对称加密数据包或对称加密完整性保护数据包以及解压缩压缩数据包必须产生有效的OpenPGP消息。
Some OpenPGP applications use so-called "detached signatures". For 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 signatures are simply a Signature packet stored separately from the data for which they are a signature.
一些OpenPGP应用程序使用所谓的“分离签名”。例如，一个程序包可能包含一个文件，以及一个作为第一个文件的分离签名的第二个文件。这些分离的签名只是一个签名包，它与作为签名的数据分开存储。
The format of an OpenPGP V3 key is as follows. Entries in square brackets are optional and ellipses indicate repetition.
OpenPGPV3密钥的格式如下所示。方括号中的条目是可选的，省略号表示重复。
RSA Public Key
[Revocation Self Signature]
User ID [Signature ...]
[User ID [Signature ...] ...]
RSA Public Key
[Revocation Self Signature]
User ID [Signature ...]
[User ID [Signature ...] ...]
Each signature certifies the RSA public key and the preceding User ID. The RSA public key can have many User IDs and each User ID can have many signatures. V3 keys are deprecated. Implementations MUST NOT generate new V3 keys, but MAY continue to use existing ones.
每个签名都证明RSA公钥和前面的用户ID。RSA公钥可以有多个用户ID，每个用户ID可以有多个签名。V3密钥已弃用。实现不能生成新的V3密钥，但可以继续使用现有密钥。
The format of an OpenPGP V4 key that uses multiple public keys is similar except that the other keys are added to the end as "subkeys" of the primary key.
使用多个公钥的OpenPGP V4密钥的格式类似，只是其他密钥作为主键的“子密钥”添加到末尾。
Primary-Key
[Revocation Self Signature]
[Direct Key Signature...]
User ID [Signature ...]
[User ID [Signature ...] ...]
[User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...]
Primary-Key
[Revocation Self Signature]
[Direct Key Signature...]
User ID [Signature ...]
[User ID [Signature ...] ...]
[User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...]
A subkey always has a single signature after it that is issued using the primary key to tie the two keys together. This binding signature may be in either V3 or V4 format, but SHOULD be V4. Subkeys that can issue signatures MUST have a V4 binding signature due to the REQUIRED embedded primary key binding signature.
子密钥之后始终有一个签名，该签名使用主键将两个密钥绑定在一起。此绑定签名可以是V3或V4格式，但应该是V4。由于需要嵌入主键绑定签名，因此可以发出签名的子键必须具有V4绑定签名。
In the above diagram, if the binding signature of a subkey has been revoked, the revoked key may be removed, leaving only one key.
在上图中，如果子密钥的绑定签名已被撤销，则可以删除被撤销的密钥，只留下一个密钥。
In a V4 key, the primary key MUST be a key capable of certification. The subkeys may be keys of any other type. There may be other 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 encryption key, or RSA primary key with an Elgamal subkey, etc.
在V4密钥中，主键必须是能够认证的密钥。子键可以是任何其他类型的键。V4键也可能有其他构造。例如，可能有V4格式的单密钥RSA密钥、带有RSA加密密钥的DSA主密钥或带有Elgamal子密钥的RSA主密钥等。
It is also possible to have a signature-only subkey. This permits a primary key that collects certifications (key signatures), but is used only for certifying subkeys that are used for encryption and signatures.
也可以具有仅签名的子密钥。这允许主密钥收集证书（密钥签名），但仅用于认证用于加密和签名的子密钥。
For a V3 key, the eight-octet Key ID consists of the low 64 bits of the public modulus of the RSA key.
对于V3密钥，八个八位组密钥ID由RSA密钥的公共模的低64位组成。
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 modulus n, followed by exponent e) with MD5. Note that both V3 keys and MD5 are deprecated.
V3密钥的指纹是通过将构成密钥材料（公共模数n，后跟指数e）的MPI的主体（而不是两个八位组长度）散列到MD5来形成的。请注意，V3键和MD5都已弃用。
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. The Key ID is the low-order 64 bits of the fingerprint. Here are the fields of the hash material, with the example of a DSA key:
V4指纹是八位字节0x99的160位SHA-1散列，后跟两个八位字节的数据包长度，后跟从版本字段开始的整个公钥数据包。密钥ID是指纹的低阶64位。以下是哈希材料的字段，以DSA密钥为例：
a.1) 0x99 (1 octet)
a、 1）0x99（1个八位组）
a.2) high-order length octet of (b)-(e) (1 octet)
a、 （b）-（e）（1个八位组）的高阶长度八位组
a.3) low-order length octet of (b)-(e) (1 octet)
a、 （b）-（e）（1个八位组）的低阶长度八位组
b) version number = 4 (1 octet);
b) 版本号=4（1个八位组）；
c) timestamp of key creation (4 octets);
c) 密钥创建的时间戳（4个八位字节）；
d) algorithm (1 octet): 17 = DSA (example);
d) algorithm (1 octet): 17 = DSA (example);
e) Algorithm-specific fields.
e) 算法特定字段。
Algorithm-Specific Fields for DSA keys (example):
DSA密钥的算法特定字段（示例）：
e.1) MPI of DSA prime p;
e、 1）DSA素数p的MPI；
e.2) MPI of DSA group order q (q is a prime divisor of p-1);
e、 2）DSA组阶q的MPI（q是p-1的素因子）；
e.3) MPI of DSA group generator g;
e、 3）DSA组生成器g的MPI；
e.4) MPI of DSA public-key value y (= g**x mod p where x is secret).
e、 4）DSA公钥值y的MPI（=g**x mod p，其中x为机密）。
Note that it is possible for there to be collisions of Key IDs -- two different keys with the same Key ID. Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint.
请注意，可能存在密钥ID的冲突——两个具有相同密钥ID的不同密钥。请注意，两个不同密钥具有相同指纹的概率更小，但仍然不是零。
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 fingerprints.
还要注意，如果V3和V4格式密钥共享相同的RSA密钥材料，则它们将具有不同的密钥ID以及不同的指纹。
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 octet (even though this is not a valid packet ID for a public subkey).
最后，以与主键相同的方式计算子键的密钥ID和指纹，包括0x99作为第一个八位组（即使这不是公共子键的有效数据包ID）。
This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. However, the calling conventions of these functions has changed in the past. To avoid potential confusion and interoperability problems, we are including local copies in this document, adapted from those in PKCS#1 v2.1 [RFC3447]. RFC 3447 should be treated as the ultimate authority on PKCS#1 for OpenPGP. Nonetheless, we believe that there is value in having a self-contained document that avoids problems in the future with needed changes in the conventions.
本标准使用了PKCS#1功能EME-PKCS1-v1#5和EMSA-PKCS1-v1#5。但是，这些函数的调用约定在过去发生了变化。为了避免潜在的混淆和互操作性问题，我们在本文档中加入了本地副本，这些副本是根据PKCS#1 v2.1[RFC3447]中的副本改编的。RFC 3447应被视为OpenPGP PKCS#1的最终权威。尽管如此，我们认为，有一份自成一体的文件是有价值的，它可以避免今后在公约中进行必要的修改时出现问题。
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
mLen <= k - 11
M = message to be encoded, an octet string of length mLen, where
mLen <= k - 11
Output:
输出：
EM = encoded message, an octet string of length k
EM=编码消息，长度为k的八位字节字符串
Error: "message too long"
错误：“消息太长”
1. Length checking: If mLen > k - 11, output "message too long" and stop.
1. 长度检查：如果mLen>k-11，输出“消息太长”并停止。
2. Generate an octet string PS of length k - mLen - 3 consisting of pseudo-randomly generated nonzero octets. The length of PS will be at least eight octets.
2. 生成长度为k-mLen-3的八位元字符串PS，由伪随机生成的非零八位元组成。PS的长度至少为八个八位字节。
3. Concatenate PS, the message M, and other padding to form an encoded message EM of length k octets as
3. 将PS、消息M和其他填充连接起来，形成长度为k个八位字节的编码消息EM，如下所示：
EM = 0x00 || 0x02 || PS || 0x00 || M.
EM=0x00 | | 0x02 | | PS | | 0x00 | | M。
4. Output EM.
4. 输出EM。
Input:
输入：
EM = encoded message, an octet string
EM=编码消息，八位字节字符串
Output:
输出：
M = message, an octet string
M=消息，八位字节字符串
Error: "decryption error"
错误：“解密错误”
To decode an EME-PKCS1_v1_5 message, separate the encoded message EM into an octet string PS consisting of nonzero octets and a message M as follows
要解码EME-PKCS1_v1_5消息，请将编码消息EM分离为八位字节字符串PS，由非零八位字节和消息M组成，如下所示
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 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, or if the length of PS is less than 8 octets, output "decryption error" and stop. See also the security note in Section 14 regarding differences in reporting between a decryption error and a padding error.
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 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 error" and stop. See also the security note in Section 14 regarding differences in reporting between a decryption error and a padding error.translate error, please retry
This encoding method is deterministic and only has an encoding operation.
此编码方法是确定性的，并且只有一个编码操作。
Option:
选项：
Hash - a hash function in which hLen denotes the length in octets of the hash function output
哈希-一种哈希函数，其中hLen表示哈希函数输出的长度（以八位字节为单位）
Input:
输入：
M = message to be encoded
M = message to be encoded
mL = intended length in octets of the encoded message, at least tLen + 11, where tLen is the octet length of the DER encoding T of a certain value computed during the encoding operation
mL=编码消息的预期八位字节长度，至少为tLen+11，其中tLen是在编码操作期间计算的特定值的DER编码T的八位字节长度
Output:
输出：
EM = encoded message, an octet string of length emLen
EM=编码消息，长度为emLen的八位字节字符串
Errors: "message too long"; "intended encoded message length too short"
错误：“消息太长”；“预期的编码消息长度太短”
Steps:
步骤：
1. Apply the hash function to the message M to produce a hash value H:
1. 将哈希函数应用于消息M以生成哈希值H：
H = Hash(M).
散列（H=散列）。
If the hash function outputs "message too long," output "message too long" and stop.
如果哈希函数输出“message too long”，则输出“message too long”并停止。
2. Using the list in Section 5.2.2, produce an ASN.1 DER value for the hash function used. Let T be the full hash prefix from Section 5.2.2, and let tLen be the length in octets of T.
2. 使用第5.2.2节中的列表，为所使用的哈希函数生成ASN.1顺序值。设T为第5.2.2节中的完整哈希前缀，设tLen为T的八位字节长度。
3. If emLen < tLen + 11, output "intended encoded message length too short" and stop.
3. 如果emLen<tLen+11，则输出“预期编码消息长度太短”并停止。
4. Generate an octet string PS consisting of emLen - tLen - 3 octets with hexadecimal value 0xFF. The length of PS will be at least 8 octets.
4. 生成一个八位字节字符串PS，由十六进制值0xFF的emLen-tLen-3个八位字节组成。PS的长度至少为8个八位字节。
5. Concatenate PS, the hash prefix T, and other padding to form the encoded message EM as
5. 将PS、散列前缀T和其他填充连接起来，形成编码消息EM as
EM = 0x00 || 0x01 || PS || 0x00 || T.
EM=0x00 | | 0x01 | | PS | | 0x00 | | T。
6. Output EM.
6. 输出EM。
The symmetric algorithm preference is an ordered list of algorithms that the keyholder accepts. Since it is found on a self-signature, it is possible that a keyholder may have multiple, different preferences. For example, Alice may have TripleDES only specified for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for "alice@home.org". Note that it is also possible for preferences to be in a subkey's binding signature.
对称算法首选项是密钥持有者接受的算法的有序列表。因为它是在自签名上发现的，所以一个密钥持有者可能有多个不同的偏好。例如，Alice可能只为“指定了三个参数”alice@work.com但是CAST5、河豚和三倍体是为alice@home.org". 请注意，首选项也可以位于子键的绑定签名中。
Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. Note also that if an implementation does not implement the preference, then it is implicitly a TripleDES-only implementation.
由于TripleDES是必须实现的算法，如果它没有显式地出现在列表中，那么它将默认地出现在最后。然而，明确地将其放在那里是一种很好的形式。还要注意的是，如果一个实现没有实现首选项，那么它隐式地是一个只有三元组的实现。
An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the MUST-implement algorithm, TripleDES, ensures that the intersection is not null. The implementation may use any mechanism to pick an algorithm in the intersection.
实现不能使用不在收件人首选项列表中的对称算法。当对多个收件人进行加密时，实现通过获取收件人偏好的交集来找到合适的算法。请注意，必须实现算法TripleDES，以确保交点不为空。该实现可以使用任何机制来选择交叉点中的算法。
If an implementation can decrypt a message that a keyholder doesn't have in their preferences, the implementation SHOULD decrypt the message anyway, but MUST warn the keyholder that the protocol has been violated. For example, suppose that Alice, above, has software that implements all algorithms in this specification. Nonetheless, she prefers subsets for work or home. If she is sent a message encrypted with IDEA, which is not in her preferences, the software warns her that someone sent her an IDEA-encrypted message, but it would ideally decrypt it anyway.
如果实现可以解密密钥持有者首选项中没有的消息，那么实现无论如何都应该解密该消息，但必须警告密钥持有者违反了协议。例如，假设上面的Alice拥有实现本规范中所有算法的软件。尽管如此，她更喜欢工作或家庭的子集。如果向她发送了一条使用IDEA加密的消息（这不在她的首选项中），软件会警告她有人向她发送了一条IDEA加密消息，但理想情况下它会对其进行解密。
Other algorithm preferences work similarly to the symmetric algorithm preference, in that they specify which algorithms the keyholder accepts. There are two interesting cases that other comments need to be made about, though, the compression preferences and the hash preferences.
其他算法首选项的工作方式与对称算法首选项类似，因为它们指定了密钥持有者接受的算法。不过，有两个有趣的例子需要对压缩首选项和哈希首选项进行其他注释。
Compression has been an integral part of PGP since its first days. OpenPGP and all previous versions of PGP have offered compression. In this specification, the default is for messages to be compressed, although an implementation is not required to do so. Consequently, the compression preference gives a way for a keyholder to request that messages not be compressed, presumably because they are using a minimal implementation that does not include compression. Additionally, this gives a keyholder a way to state that it can support alternate algorithms.
自PGP诞生之日起，压缩就成为其不可或缺的一部分。OpenPGP和所有以前版本的PGP都提供了压缩。在本规范中，默认情况下是对消息进行压缩，尽管不需要实现。因此，压缩首选项为密钥持有者提供了一种请求消息不被压缩的方式，可能是因为它们使用的是不包括压缩的最小实现。此外，这为密钥持有者提供了一种声明它可以支持其他算法的方式。
Like the algorithm preferences, an implementation MUST NOT use an algorithm that is not in the preference vector. If the preferences are not present, then they are assumed to be [ZIP(1), Uncompressed(0)].
与算法首选项一样，实现不得使用不在首选项向量中的算法。如果首选项不存在，则假定它们为[ZIP（1），未压缩（0）]。
Additionally, an implementation MUST implement this preference to the degree of recognizing when to send an uncompressed message. A robust implementation would satisfy this requirement by looking at the recipient's preference and acting accordingly. A minimal implementation can satisfy this requirement by never generating a compressed message, since all implementations can handle messages that have not been compressed.
此外，实现必须实现此首选项，以识别何时发送未压缩消息。一个健壮的实现将通过查看接收者的偏好并相应地采取行动来满足这一要求。最小的实现可以通过从不生成压缩消息来满足这一要求，因为所有实现都可以处理未压缩的消息。
Typically, the choice of a hash algorithm is something the signer does, rather than the verifier, because a signer rarely knows who is going to be verifying the signature. This preference, though, allows a protocol based upon digital signatures ease in negotiation.
通常，哈希算法的选择是签名者而不是验证者所做的，因为签名者很少知道谁将要验证签名。然而，这种偏好使得基于数字签名的协议易于协商。
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 uses. This preference allows Bob to state in his key which algorithms Alice may use.
因此，如果Alice使用签名向Bob验证自己，那么她使用Bob软件使用的哈希算法是有意义的。此首选项允许Bob在其密钥中声明Alice可能使用的算法。
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 good form to place it there explicitly.
由于SHA1是必须实现的哈希算法，如果它没有显式地出现在列表中，那么它将默认地出现在最后。然而，明确地将其放在那里是一种很好的形式。
Algorithm 0, "plaintext", may only be used to denote secret keys that are stored in the clear. Implementations MUST NOT use plaintext in Symmetrically Encrypted Data packets; they must use Literal Data packets to encode unencrypted or literal data.
算法0“明文”只能用于表示明文中存储的密钥。实现不能在对称加密的数据包中使用明文；他们必须使用文字数据包对未加密或文字数据进行编码。
There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only keys. These types are deprecated. The "key flags" subpacket in a signature is a much better way to express the same idea, and generalizes it to all algorithms. An implementation SHOULD NOT create such a key, but MAY interpret it.
有只用于RSA签名和只用于RSA加密密钥的算法类型。这些类型已弃用。签名中的“密钥标志”子包是表达相同想法的更好方法，并将其推广到所有算法。实现不应该创建这样一个键，但可以解释它。
An implementation SHOULD NOT implement RSA keys of size less than 1024 bits.
实现不应实现大小小于1024位的RSA密钥。
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 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 (DSS) [FIPS186] specifies that DSA be used in one of the following ways:
实现不应实现大小小于1024位的DSA密钥。它不能实现q大小小于160位的DSA密钥。DSA密钥也必须是64位的倍数，q大小必须是8位的倍数。数字签名标准（DSS）[FIPS186]规定DSA应以以下方式之一使用：
* 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 hash
* 1024位密钥、160位q、SHA-1、SHA-224、SHA-256、SHA-384或SHA-512哈希
* 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 hash
* 2048位密钥、224位q、SHA-224、SHA-256、SHA-384或SHA-512哈希
* 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash
* 2048位密钥、256位q、SHA-256、SHA-384或SHA-512哈希
* 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash
* 3072位密钥、256位q、SHA-256、SHA-384或SHA-512哈希
The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations 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 must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance.
选择上述密钥和q大小对是为了最好地平衡密钥的强度和散列的强度。在生成DSA密钥时，实现应使用上述密钥和q大小对之一。如果需要符合DSS，则还必须使用指定的SHA哈希之一。[FIPS186]是DSS的最终权威，应就DSS合规性的所有问题咨询。
Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash.
请注意，此标准的早期版本只允许160位q，不允许截断，因此早期实现可能无法处理具有不同q大小或截断哈希的签名。
An implementation SHOULD NOT implement Elgamal keys of size less than 1024 bits.
实现不应实现大小小于1024位的Elgamal密钥。
A number of algorithm IDs have been reserved for algorithms that would be useful to use in an OpenPGP implementation, yet there are issues that prevent an implementer from actually implementing the algorithm. These are marked in Section 9.1, "Public-Key Algorithms", as "reserved for".
许多算法ID都是为OpenPGP实现中使用的算法保留的，但也有一些问题妨碍了实现者实际实现该算法。第9.1节“公钥算法”中将这些标记为“预留”。
The reserved public-key algorithms, Elliptic Curve (18), ECDSA (19), and X9.42 (21), do not have the necessary parameters, parameter order, or semantics defined.
保留公钥算法椭圆曲线（18）、ECDSA（19）和X9.42（21）没有定义必要的参数、参数顺序或语义。
Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures with a public-key identifier of 20. These are no longer permitted. An implementation MUST NOT generate such keys. An implementation MUST NOT generate Elgamal signatures. See [BLEICHENBACHER].
OpenPGP的早期版本允许使用公钥标识符为20的Elgamal[Elgamal]签名。这是不允许的。实现不能生成这样的密钥。实现不能生成Elgamal签名。见[BLEICHENBACHER]。
OpenPGP does symmetric encryption using a variant of Cipher Feedback mode (CFB mode). This section describes the procedure it uses in detail. This mode is what is used for Symmetrically Encrypted Data Packets; the mechanism used for encrypting secret-key material is similar, and is described in the sections above.
OpenPGP使用密码反馈模式（CFB模式）的变体进行对称加密。本节详细介绍了它使用的过程。此模式用于对称加密的数据包；用于加密密钥材料的机制类似，并在上述章节中描述。
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 and Twofish have a block size of 16 octets. Also note that the description below assumes that the IV and CFB arrays start with an index of 1 (unlike the C language, which assumes arrays start with a zero index).
在下面的描述中，值BS是密码的块大小（以八位字节为单位）。大多数密码的块大小为8个八位字节。AES和Twofish的块大小为16个八位组。还要注意，下面的描述假定IV和CFB数组以索引1开头（与C语言不同，C语言假定数组以零索引开头）。
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with BS+2 octets of random data, such that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB resynchronization after encrypting those BS+2 octets.
OpenPGP CFB模式使用全零的初始化向量（IV），并在明文前加上随机数据的BS+2八位字节，以便八位字节BS+1和BS+2匹配八位字节BS-1和BS。它在加密这些BS+2八位字节后执行CFB重新同步。
Thus, for an algorithm that has a block size of 8 octets (64 bits), the IV is 10 octets long and octets 7 and 8 of the IV are the same as octets 9 and 10. For an algorithm with a block size of 16 octets (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate octets 15 and 16. Those extra two octets are an easy check for a correct key.
因此，对于块大小为8个八位字节（64位）的算法，IV的长度为10个八位字节，IV的八位字节7和8与八位字节9和10相同。对于块大小为16个八位字节（128位）的算法，IV的长度为18个八位字节，而八位字节17和18复制了八位字节15和16。这两个额外的八位组是一个简单的检查一个正确的关键。
Step by step, here is the procedure:
步骤如下：
1. The feedback register (FR) is set to the IV, which is all zeros.
1. 反馈寄存器（FR）设置为IV，该值为全零。
2. FR is encrypted to produce FRE (FR Encrypted). This is the encryption of an all-zero value.
2. FR被加密以产生FRE（FR加密）。这是一个全零值的加密。
3. FRE is xored with the first BS octets of random data prefixed to the plaintext to produce C[1] through C[BS], the first BS octets of ciphertext.
3. FRE与以明文为前缀的随机数据的第一个BS八位字节进行异或运算，以产生C[1]到C[BS]，即密文的第一个BS八位字节。
4. FR is loaded with C[1] through C[BS].
4. FR通过C[1]到C[BS]加载。
5. FR is encrypted to produce FRE, the encryption of the first BS octets of ciphertext.
5. FR被加密以产生FRE，即加密密文的第一个BS八位字节。
6. The left two octets of FRE get xored with the next two octets of data that were prefixed to the plaintext. This produces C[BS+1] and C[BS+2], the next two octets of ciphertext.
6. FRE的左两个八位字节与以明文为前缀的下两个八位字节数据进行异或。这将产生C[BS+1]和C[BS+2]，这是密文的下两个八位字节。
7. (The resynchronization step) FR is loaded with C[3] through C[BS+2].
7. （重新同步步骤）FR加载C[3]到C[BS+2]。
8. FR is encrypted to produce FRE.
8. FR被加密以产生FRE。
9. FRE is xored with the first BS octets of the given plaintext, now that we have finished encrypting the BS+2 octets of prefixed data. This produces C[BS+3] through C[BS+(BS+2)], the next BS octets of ciphertext.
9. FRE与给定明文的第一个BS八位字节异或，现在我们已经完成了对前缀数据的BS+2八位字节的加密。这将产生C[BS+3]到C[BS+（BS+2）]，这是密文的下一个BS八位字节。
10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an 8-octet block).
10. FR加载C[BS+3]到C[BS+（BS+2）]（对于8个八位组块来说是C11-C18）。
11. FR is encrypted to produce FRE.
11. FR被加密以产生FRE。
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 process is repeated until the plaintext is used up.
12. 下一个八位字节的密文是frexobs，下一个八位字节的密文是frexobs。这些文件被加载到FR中，并重复该过程，直到明文用完为止。
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].
第9节中描述的S2K说明符、签名子包类型、用户属性类型、图像格式类型和算法都保留100到110的范围供私人和实验使用。数据包类型保留60到63的范围以供私人和实验使用。如[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.
但是，实现需要小心处理这些参数，当它们超出原始的有限系统时，将它们升级为完整的IANA管理参数。
As described in the non-normative explanation in Section 5.13, the MDC system is uniquely unparameterized in OpenPGP. This was an intentional decision to avoid cross-grade attacks. If the MDC system is extended to a stronger hash function, care must be taken to avoid downgrade and cross-grade attacks.
如第5.13节的非规范性解释所述，MDC系统在OpenPGP中是唯一未经参数化的。这是为了避免跨年级攻击而故意做出的决定。如果将MDC系统扩展为更强的哈希函数，则必须小心避免降级和跨级攻击。
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).
一种简单的方法是为新的MDC创建新的数据包。例如，与使用数据包18和19的MDC系统不同，新的MDC可以使用数据包20和21。这有明显的缺点（它在一个最大为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.
扩展MDC系统的另一个简单方法是创建数据包18的新版本，并在数据包19中反映这一点。例如，假设数据包18的V2隐式使用SHA-256。这将要求数据包19的长度为32个八位字节。数据包18中版本的变化和数据包19的大小可防止降级攻击。
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.
后一种方法有两个缺点。首先，从协议设计的角度来看，使用数据包的版本号来携带算法信息是不整洁的。MDC系统可能有多个通用版本，但这种不一致性反映了关于哈希函数安全性的密码共识中的不一致性。第二个是数据包19的不同版本必须具有唯一的大小。如果有两个版本，每个版本都有256位哈希，那么它们不可能都有32个八位组数据包19，而不承认发生跨等级攻击的可能性。
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.
另一种扩展MDC系统的复杂方法是上述两种方法的混合——创建一对完全参数化的新MDC数据包，同时防止降级和交叉降级。
Any change to the MDC system MUST be done through the IETF CONSENSUS method, as described in [RFC2434].
如[RFC2434]所述，对MDC系统的任何更改必须通过IETF协商一致的方法进行。
If OpenPGP is extended in a way that is not backwards-compatible, meaning that old implementations will not gracefully handle their
如果OpenPGP以一种不向后兼容的方式进行扩展，这意味着旧的实现将无法优雅地处理它们的
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, whereas 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.
如果扩展提案未更新功能系统，则应包括对不必要的原因的解释。如果提案中既没有对功能系统进行扩展，也没有解释为何不需要进行扩展，则应拒绝该提案。
* As with any technology involving cryptography, you should check the current literature to determine if any algorithms used here have been found to be vulnerable to attack.
* 与任何涉及密码学的技术一样，您应该检查当前的文献，以确定此处使用的任何算法是否容易受到攻击。
* This specification uses Public-Key Cryptography technologies. It is assumed that the private key portion of a public-private key pair is controlled and secured by the proper party or parties.
* 本规范使用公钥加密技术。假定公私密钥对的私钥部分由适当的一方或多方控制和保护。
* Certain operations in this specification involve the use of random numbers. An appropriate entropy source should be used to generate these numbers (see [RFC4086]).
* 本规范中的某些操作涉及使用随机数。应使用适当的熵源生成这些数字（参见[RFC4086]）。
* The MD5 hash algorithm has been found to have weaknesses, with collisions found in a number of cases. MD5 is deprecated for use in OpenPGP. Implementations MUST NOT generate new signatures using MD5 as a hash function. They MAY continue to consider old signatures that used MD5 as valid.
* MD5哈希算法被发现有弱点，在许多情况下都会发生冲突。MD5不推荐在OpenPGP中使用。实现不能使用MD5作为哈希函数生成新签名。他们可以继续考虑使用MD5有效的旧签名。
* SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512, respectively. In general, there are few reasons to use them outside of DSS compatibility. You need a situation where one needs more security than smaller hashes, but does not want to have the full 256-bit or 512-bit data length.
* SHA-224和SHA-384分别需要与SHA-256和SHA-512相同的工作。一般来说，除了DSS兼容性之外，很少有理由使用它们。您需要这样一种情况，即需要比较小的散列更高的安全性，但不希望拥有完整的256位或512位数据长度。
* Many security protocol designers think that it is a bad idea to use a single key for both privacy (encryption) and integrity (signatures). In fact, this was one of the motivating forces behind the V4 key format with separate signature and encryption keys. If you as an implementer promote dual-use keys, you should at least be aware of this controversy.
* 许多安全协议设计人员认为，对隐私（加密）和完整性（签名）使用单一密钥是个坏主意。事实上，这是V4密钥格式背后的推动力之一，该格式具有单独的签名和加密密钥。如果您作为一个实现者推广两用密钥，您至少应该意识到这一争议。
* The DSA algorithm will work with any hash, but is sensitive to the quality of the hash algorithm. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid.
* DSA算法可以处理任何哈希，但对哈希算法的质量很敏感。验证者应该知道，即使签名者使用了强散列，攻击者也可能会修改签名以使用弱散列。只有使用可接受的强哈希算法的签名才应被视为有效。
* As OpenPGP combines many different asymmetric, symmetric, and hash algorithms, each with different measures of strength, care should be taken that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. While consensus about the strength of a given algorithm may evolve, NIST Special Publication 800-57 [SP800-57] recommends the following list of equivalent strengths:
* 由于OpenPGP结合了许多不同的非对称、对称和散列算法，每种算法都具有不同的强度度量，因此应注意OpenPGP消息中最薄弱的元素对于当前目的来说仍然足够强大。虽然对给定算法的强度可能会形成共识，但NIST特别出版物800-57[SP800-57]推荐了以下等效强度列表：
Asymmetric | Hash | Symmetric
key size | size | key size
------------+--------+-----------
1024 160 80
2048 224 112
3072 256 128
7680 384 192
15360 512 256
Asymmetric | Hash | Symmetric
key size | size | key size
------------+--------+-----------
1024 160 80
2048 224 112
3072 256 128
7680 384 192
15360 512 256
* There is a somewhat-related potential security problem in signatures. If an attacker can find a message that hashes to the same hash with a different algorithm, a bogus signature structure can be constructed that evaluates correctly.
* 签名中存在某种相关的潜在安全问题。如果攻击者可以找到一条消息，该消息使用不同的算法散列到同一个散列中，则可以构造一个正确计算的伪签名结构。
For example, suppose Alice DSA signs message M using hash algorithm H. Suppose that Mallet finds a message M' that has the same hash value as M with H'. Mallet can then construct a signature block that verifies as Alice's signature of M' with H'. However, this would also constitute a weakness in either H or H' or both. Should this ever occur, a revision will have to be made to this document to revise the allowed hash algorithms.
例如，假设Alice DSA使用哈希算法H对消息M进行签名。假设Mallet找到一条消息M'，该消息的哈希值与带有H的消息M'的哈希值相同。Mallet然后可以构造一个签名块，该签名块验证为Alice的M'与H'的签名。然而，这也将构成H或H'或两者的弱点。如果发生这种情况，必须对本文件进行修订，以修订允许的哈希算法。
* If you are building an authentication system, the recipient may specify a preferred signing algorithm. However, the signer would be foolish to use a weak algorithm simply because the recipient requests it.
* 如果您正在构建身份验证系统，则收件人可以指定首选的签名算法。然而，仅仅因为接收者请求，签名者使用弱算法是愚蠢的。
* Some of the encryption algorithms mentioned in this document have been analyzed less than others. For example, although CAST5 is presently considered strong, it has been analyzed less than TripleDES. Other algorithms may have other controversies surrounding them.
* 本文中提到的一些加密算法的分析较少。例如，尽管CAST5目前被认为是强大的，但它的分析还不到三倍。其他算法可能会有其他争议。
* In late summer 2002, Jallad, Katz, and Schneier published an interesting attack on the OpenPGP protocol and some of its implementations [JKS02]. In this attack, the attacker modifies a message and sends it to a user who then returns the erroneously decrypted message to the attacker. The attacker is thus using the user as a random oracle, and can often decrypt the message.
* 2002年夏末，Jallad、Katz和Schneier发表了一篇关于OpenPGP协议及其一些实现的有趣的攻击[JKS02]。在此攻击中，攻击者修改消息并将其发送给用户，然后用户将错误解密的消息返回给攻击者。因此，攻击者将用户用作随机oracle，通常可以解密消息。
Compressing data can ameliorate this attack. The incorrectly decrypted data nearly always decompresses in ways that defeat the attack. However, this is not a rigorous fix, and leaves open some small vulnerabilities. For example, if an implementation does not compress a message before encryption (perhaps because it knows it was already compressed), then that message is vulnerable. Because of this happenstance -- that modification attacks can be thwarted by decompression errors -- an implementation SHOULD treat a decompression error as a security problem, not merely a data problem.
压缩数据可以改善这种攻击。解密不正确的数据几乎总是以击败攻击的方式进行解压缩。然而，这并不是一个严格的修复，留下了一些小漏洞。例如，如果一个实现在加密之前没有压缩消息（可能是因为它知道消息已经压缩），那么该消息就容易受到攻击。由于这种偶然性（即可以通过解压缩错误阻止修改攻击），实现应该将解压缩错误视为安全问题，而不仅仅是数据问题。
This attack can be defeated by the use of Modification Detection, provided that the implementation does not let the user naively return the data to the attacker. An implementation MUST treat an MDC failure as a security problem, not merely a data problem.
如果实现不允许用户天真地将数据返回给攻击者，则可以通过使用修改检测来击败此攻击。实现必须将MDC故障视为安全问题，而不仅仅是数据问题。
In either case, the implementation MAY allow the user access to the erroneous data, but MUST warn the user as to potential security problems should that data be returned to the sender.
在任何一种情况下，实现都可能允许用户访问错误的数据，但如果数据返回给发送方，则必须警告用户潜在的安全问题。
While this attack is somewhat obscure, requiring a special set of circumstances to create it, it is nonetheless quite serious as it permits someone to trick a user to decrypt a message. Consequently, it is important that:
虽然这种攻击有点模糊，需要一组特殊的环境来创建它，但它仍然相当严重，因为它允许有人欺骗用户解密消息。因此，重要的是：
1. Implementers treat MDC errors and decompression failures as security problems.
1. 实现者将MDC错误和解压缩失败视为安全问题。
2. Implementers implement Modification Detection with all due speed and encourage its spread.
2. 实施者以应有的速度实施修改检测，并鼓励其传播。
3. Users migrate to implementations that support Modification Detection with all due speed.
3. 用户以应有的速度迁移到支持修改检测的实现。
* PKCS#1 has been found to be vulnerable to attacks in which a system that reports errors in padding differently from errors in decryption becomes a random oracle that can leak the private key in mere millions of queries. Implementations must be aware of this attack and prevent it from happening. The simplest solution is to report a single error code for all variants of decryption errors so as not to leak information to an attacker.
* PKCS#1已被发现容易受到攻击，在这种攻击中，报告填充错误与解密错误不同的系统会变成一个随机预言机，只需数百万次查询就可以泄漏私钥。实现必须了解此攻击并防止其发生。最简单的解决方案是为解密错误的所有变体报告一个单一的错误代码，以便不向攻击者泄漏信息。
* Some technologies mentioned here may be subject to government control in some countries.
* 这里提到的一些技术可能受到某些国家政府的控制。
* In winter 2005, Serge Mister and Robert Zuccherato from Entrust released a paper describing a way that the "quick check" in OpenPGP CFB mode can be used with a random oracle to decrypt two octets of every cipher block [MZ05]. They recommend as prevention not using the quick check at all.
* 2005年冬天，委托公司的Serge Mister和Robert Zuccherato发表了一篇论文，描述了OpenPGP CFB模式下的“快速检查”可以与随机预言机一起使用，对每个密码块的两个八位字节进行解密的方法[MZ05]。他们建议不要使用快速检查作为预防措施。
Many implementers have taken this advice to heart for any data that is symmetrically encrypted and for which the session key is public-key encrypted. In this case, the quick check is not needed as the public-key encryption of the session key should guarantee that it is the right session key. In other cases, the implementation should use the quick check with care.
对于对称加密且会话密钥为公钥加密的任何数据，许多实现者都牢记这一建议。在这种情况下，不需要快速检查，因为会话密钥的公钥加密应该保证它是正确的会话密钥。在其他情况下，实现应谨慎使用快速检查。
On the one hand, there is a danger to using it if there is a random oracle that can leak information to an attacker. In plainer language, there is a danger to using the quick check if timing information about the check can be exposed to an attacker, particularly via an automated service that allows rapidly repeated queries.
一方面，如果有一个随机的oracle可以向攻击者泄露信息，那么使用它就有危险。用更简单的语言来说，如果有关检查的计时信息可能暴露给攻击者，特别是通过允许快速重复查询的自动服务，则使用快速检查存在危险。
On the other hand, it is inconvenient to the user to be informed that they typed in the wrong passphrase only after a petabyte of data is decrypted. There are many cases in cryptographic engineering where the implementer must use care and wisdom, and this is one.
另一方面，仅在对PB级数据进行解密后，才告知用户键入了错误的密码短语，这对用户来说是不方便的。在密码工程中有许多情况下，实现者必须谨慎和智慧，这就是其中之一。
This section is a collection of comments to help an implementer, particularly with an eye to backward compatibility. Previous implementations of PGP are not OpenPGP compliant. Often the differences are small, but small differences are frequently more vexing than large differences. Thus, this is a non-comprehensive list of potential problems and gotchas for a developer who is trying to be backward-compatible.
本节是帮助实现者的注释集合，特别是着眼于向后兼容性。以前的PGP实现不符合OpenPGP。通常差异很小，但小差异往往比大差异更令人烦恼。因此，对于试图向后兼容的开发人员来说，这是一个不全面的潜在问题和陷阱列表。
* The IDEA algorithm is patented, and yet it is required for PGP 2.x interoperability. It is also the de-facto preferred algorithm for a V3 key with a V3 self-signature (or no self-signature).
* IDEA算法已获得专利，但它是PGP2.x互操作性所必需的。对于具有V3自签名（或无自签名）的V3密钥，它也是事实上的首选算法。
* When exporting a private key, PGP 2.x generates the header "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK". All previous versions ignore the implied data type, and look directly at the packet data type.
* 导出私钥时，PGP 2.x生成标题“BEGIN PGP SECRET key BLOCK”，而不是“BEGIN PGP private key BLOCK”。所有以前的版本都会忽略隐含的数据类型，并直接查看数据包数据类型。
* PGP 2.0 through 2.5 generated V2 Public-Key packets. These are identical to the deprecated V3 keys except for the version number. An implementation MUST NOT generate them and may accept or reject them as it sees fit. Some older PGP versions generated V2 PKESK packets (Tag 1) as well. An implementation may accept or reject V2 PKESK packets as it sees fit, and MUST NOT generate them.
* PGP2.0至2.5生成了V2公钥数据包。除版本号外，这些密钥与不推荐使用的V3密钥相同。实现不能生成它们，并且可以根据需要接受或拒绝它们。一些较旧的PGP版本也生成V2 PKESK数据包（标记1）。一个实现可以根据需要接受或拒绝V2 PKESK数据包，并且不能生成它们。
* PGP 2.6.x will not accept key-material packets with versions greater than 3.
* PGP 2.6.x不接受版本大于3的关键材料包。
* There are many ways possible for two keys to have the same key material, but different fingerprints (and thus Key IDs). Perhaps the most interesting is an RSA key that has been "upgraded" to V4 format, but since a V4 fingerprint is constructed by hashing the key creation time along with other things, two V4 keys created at different times, yet with the same key material will have different fingerprints.
* 有许多方法可以使两个密钥具有相同的密钥材料，但指纹不同（因此密钥ID也不同）。也许最有趣的是已“升级”为V4格式的RSA密钥，但由于V4指纹是通过哈希密钥创建时间和其他内容构建的，因此在不同时间创建的两个V4密钥（使用相同的密钥材料）将具有不同的指纹。
* If an implementation is using zlib to interoperate with PGP 2.x, then the "windowBits" parameter should be set to -13.
* 如果一个实现使用zlib与PGP2.x进行互操作，那么“windowBits”参数应该设置为-13。
* The 0x19 back signatures were not required for signing subkeys until relatively recently. Consequently, there may be keys in the wild that do not have these back signatures. Implementing software may handle these keys as it sees fit.
* 直到最近，签名子密钥才需要0x19反向签名。因此，在野外可能存在没有这些反向签名的密钥。实现软件可以根据需要处理这些关键点。
* OpenPGP does not put limits on the size of public keys. However, larger keys are not necessarily better keys. Larger keys take more computation time to use, and this can quickly become impractical. Different OpenPGP implementations may also use different upper bounds for public key sizes, and so care should be taken when choosing sizes to maintain interoperability. As of 2007 most implementations have an upper bound of 4096 bits.
* OpenPGP不限制公钥的大小。但是，较大的键不一定是更好的键。使用较大的键需要更多的计算时间，这可能很快变得不切实际。不同的OpenPGP实现也可能对公钥大小使用不同的上限，因此在选择大小以保持互操作性时应小心。截至2007年，大多数实现的上限为4096位。
* ASCII armor is an optional feature of OpenPGP. The OpenPGP working group strives for a minimal set of mandatory-to-implement features, and since there could be useful implementations that only use binary object formats, this is not a "MUST" feature for an implementation. For example, an implementation that is using OpenPGP as a mechanism for file signatures may find ASCII armor unnecessary. OpenPGP permits an implementation to declare what features it does and does not support, but ASCII armor is not one of these. Since most implementations allow binary and armored objects to be used indiscriminately, an implementation that does not implement ASCII armor may find itself with compatibility issues with general-purpose implementations. Moreover, implementations of OpenPGP-MIME [RFC3156] already have a
* ASCII装甲是OpenPGP的可选功能。OpenPGP工作组致力于实现一组最少的强制功能，并且由于可能存在只使用二进制对象格式的有用实现，因此这不是实现的“必须”功能。例如，使用OpenPGP作为文件签名机制的实现可能会发现没有必要。OpenPGP允许实现声明它支持和不支持哪些功能，但ASCII armor不是其中之一。由于大多数实现允许不加区别地使用二进制和铠装对象，因此未实现ASCII铠装的实现可能会发现自己与通用实现存在兼容性问题。此外，OpenPGP MIME[RFC3156]的实现已经有了一个
requirement for ASCII armor so those implementations will necessarily have support.
对ASCII装甲的要求，因此这些实现必须有支持。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
(AES)," November 2001.
http://csrc.nist.gov/publications/fips/fips197/fips-
197.{ps,pdf}
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
(AES)," November 2001.
http://csrc.nist.gov/publications/fips/fips197/fips-
197.{ps,pdf}
[BLOWFISH] Schneier, B. "Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish)" Fast Software Encryption, Cambridge Security Workshop Proceedings (December 1993), Springer-Verlag, 1994, pp191-204 <http://www.counterpane.com/bfsverlag.html>
[BLOWFISH]Schneier，B.“一种新的可变长度密钥的描述，64位分组密码（BLOWFISH）”，快速软件加密，剑桥安全研讨会论文集（1993年12月），Springer Verlag，1994年，第191-204页<http://www.counterpane.com/bfsverlag.html>
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page" <http://www.bzip.org/>
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page" <http://www.bzip.org/>
[ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms," IEEE Transactions on Information Theory, v. IT-31, n. 4, 1985, pp. 469-472.
[ELGAMAL]T.ELGAMAL，“基于离散对数的公钥密码系统和签名方案”，IEEE信息论交易，v。IT-31，n。1985年4月，第469-472页。
[FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB 180-
2).
<http://csrc.nist.gov/publications/fips/fips180-
2/fips180-2withchangenotice.pdf>
[FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB 180-
2).
<http://csrc.nist.gov/publications/fips/fips180-
2/fips180-2withchangenotice.pdf>
[FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2).
<http://csrc.nist.gov/publications/fips/fips186-2/
fips186-2-change1.pdf> FIPS 186-3 describes keys
greater than 1024 bits. The latest draft is at:
<http://csrc.nist.gov/publications/drafts/
fips_186-3/Draft-FIPS-186-3%20_March2006.pdf>
[FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2).
<http://csrc.nist.gov/publications/fips/fips186-2/
fips186-2-change1.pdf> FIPS 186-3 describes keys
greater than 1024 bits. The latest draft is at:
<http://csrc.nist.gov/publications/drafts/
fips_186-3/Draft-FIPS-186-3%20_March2006.pdf>
[HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.
<http://www.cacr.math.uwaterloo.ca/hac/>
[HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.
<http://www.cacr.math.uwaterloo.ca/hac/>
[IDEA] Lai, X, "On the design and security of block ciphers", ETH Series in Information Processing, J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag Knostanz, Technische Hochschule (Zurich), 1992
[IDEA]Lai，X，“关于分组密码的设计和安全”，信息处理ETH系列，J.L.Massey（编辑），第一卷，Hartung Gorre Verlag Knostanz，Technische Hochschule（苏黎世），1992年
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane.
[ISO10646]ISO/IEC 10646-1:1993。国际标准信息技术通用多八位编码字符集（UCS）第1部分：体系结构和基本多语言平面。
[JFIF] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992.
[JFIF]JPEG文件交换格式（版本1.02）。埃里克·汉密尔顿，C-Cube微系统公司，加利福尼亚州米尔皮塔斯，1992年9月1日。
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950]Deutsch，P.和J-L.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，1996年5月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC1951]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144]Adams，C.，“CAST-128加密算法”，RFC2144，1997年5月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996.
[SCHNEIER]SCHNEIER，B.，“应用密码学第二版：C语言中的协议、算法和源代码”，1996年。
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "The Twofish Encryption Algorithm", John Wiley & Sons, 1999.
[TWOFISH]B.Schneier，J.Kelsey，D.Whiting，D.Wagner，C.Hall和N.Ferguson，“TWOFISH加密算法”，John Wiley&Sons，1999年。
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is
available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps>
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is
available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps>
[JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier "Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG" http://www.counterpane.com/pgp-attack.html
[JKS02]Kahil Jallad，Jonathan Katz，Bruce Schneier“针对PGP和GnuPG的选择密文攻击的实现”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.
[MAURER]Ueli MAURER，“公钥基础设施建模”，Proc。1996年欧洲计算机安全研究研讨会（ESORICS'96），计算机科学课堂讲稿，Springer Verlag，第1146卷，第325-350页，1996年9月。
[MZ05] Serge Mister, Robert Zuccherato, "An Attack on CFB
Mode Encryption As Used By OpenPGP," IACR ePrint
Archive: Report 2005/033, 8 Feb 2005
http://eprint.iacr.org/2005/033
[MZ05] Serge Mister, Robert Zuccherato, "An Attack on CFB
Mode Encryption As Used By OpenPGP," IACR ePrint
Archive: Report 2005/033, 8 Feb 2005
http://eprint.iacr.org/2005/033
[REGEX] Jeffrey Friedl, "Mastering Regular Expressions," O'Reilly, ISBN 0-596-00289-0.
Jeffrey Friedl，“掌握正则表达式”，O'Reilly，ISBN 0-596-00289-0。
[RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
[RFC1423]Balenson，D.，“互联网电子邮件的隐私增强：第三部分：算法、模式和标识符”，RFC 1423，1993年2月。
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996.
[RFC1991]Atkins，D.，Stallings，W.，和P.Zimmermann，“PGP消息交换格式”，RFC 1991，1996年8月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440]Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC 24401998年11月。
[SP800-57] NIST Special Publication 800-57, Recommendation on
Key Management
<http://csrc.nist.gov/publications/nistpubs/ 800-
57/SP800-57-Part1.pdf>
<http://csrc.nist.gov/publications/nistpubs/ 800-
57/SP800-57-Part2.pdf>
[SP800-57] NIST Special Publication 800-57, Recommendation on
Key Management
<http://csrc.nist.gov/publications/nistpubs/ 800-
57/SP800-57-Part1.pdf>
<http://csrc.nist.gov/publications/nistpubs/ 800-
57/SP800-57-Part2.pdf>
Acknowledgements
致谢
This memo also draws on much previous work from a number of other authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark Weaver, and Philip R. Zimmermann.
这份备忘录还借鉴了许多其他作者以前的作品，包括：德里克·阿特金斯、查尔斯·布莱德、戴夫·德尔·托托、马克·戴克斯特豪斯、盖尔·哈斯珀特、吉恩·霍夫曼、保罗·霍夫曼、本·劳里、拉斐尔·莱文、科林·普拉姆、威尔·普莱斯、大卫·肖、威廉·斯泰林斯、马克·韦弗和菲利普·齐默尔曼。
Authors' Addresses
作者地址
The working group can be contacted via the current chair:
可通过现任主席联系工作组：
Derek Atkins IHTFP Consulting, Inc. 4 Farragut Ave Somerville, MA 02144 USA
德里克·阿特金斯IHTFP咨询公司，美国马萨诸塞州萨默维尔法拉古特大道4号，邮编：02144
EMail: derek@ihtfp.com
Tel: +1 617 623 3745
EMail: derek@ihtfp.com
Tel: +1 617 623 3745
The principal authors of this document are as follows:
本文件的主要作者如下：
Jon Callas EMail: jon@callas.org
Jon Callas电子邮件：jon@callas.org
Lutz Donnerhacke IKS GmbH Wildenbruchstr. 15 07745 Jena, Germany EMail: lutz@iks-jena.de
卢茨·唐纳哈克IKS有限公司Wildenbruchstr。15 07745德国耶拿电子邮件：lutz@iks-杰娜·德
Hal Finney EMail: hal@finney.org
Hal Finney电子邮件：hal@finney.org
David Shaw EMail: dshaw@jabberwocky.com
David Shaw电子邮件：dshaw@jabberwocky.com
Rodney Thayer EMail: rodney@canola-jones.com
Rodney Thayer电子邮件：rodney@canola-琼斯网
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.