idnits 2.17.1 draft-ietf-openpgp-crypto-refresh-05.txt: -(3731): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3733): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3735): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 14 characters in excess of 72. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC6637, but the abstract doesn't seem to directly say this. It does mention RFC6637 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC4880, but the abstract doesn't seem to directly say this. It does mention RFC4880 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC5581, but the abstract doesn't seem to directly say this. It does mention RFC5581 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 780 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 2972 -- Looks like a reference, but probably isn't: '1' on line 5636 -- Looks like a reference, but probably isn't: '2' on line 474 -- Looks like a reference, but probably isn't: '3' on line 5645 == Missing Reference: 'Optional' is mentioned on line 2719, but not defined -- Looks like a reference, but probably isn't: '31' on line 2974 == Missing Reference: '0-9' is mentioned on line 3954, but not defined == Missing Reference: 'BS' is mentioned on line 5636, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'BLOWFISH' -- Possible downref: Non-RFC (?) normative reference: ref. 'BZ2' -- Possible downref: Non-RFC (?) normative reference: ref. 'EAX' -- Possible downref: Non-RFC (?) normative reference: ref. 'ELGAMAL' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS202' -- Possible downref: Non-RFC (?) normative reference: ref. 'HAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDEA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- Possible downref: Non-RFC (?) normative reference: ref. 'JFIF' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS5' ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 2144 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Downref: Normative reference to an Informational RFC: RFC 3713 ** Downref: Normative reference to an Informational RFC: RFC 7253 ** Downref: Normative reference to an Informational RFC: RFC 7748 ** Downref: Normative reference to an Informational RFC: RFC 8017 ** Downref: Normative reference to an Informational RFC: RFC 8032 ** Downref: Normative reference to an Informational RFC: RFC 9106 -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-38D' -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-56A' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOFISH' -- Obsolete informational reference (is this intentional?): RFC 1991 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Koch, Ed. 3 Internet-Draft GnuPG e.V. 4 Obsoletes: 4880, 5581, 6637 (if approved) P. Wouters, Ed. 5 Intended status: Standards Track Aiven 6 Expires: 8 September 2022 7 March 2022 8 OpenPGP Message Format 9 draft-ietf-openpgp-crypto-refresh-05 11 Abstract 13 This document specifies the message formats used in OpenPGP. OpenPGP 14 provides encryption with public-key or symmetric cryptographic 15 algorithms, digital signatures, compression and key management. 17 This document is maintained in order to publish all necessary 18 information needed to develop interoperable applications based on the 19 OpenPGP format. It is not a step-by-step cookbook for writing an 20 application. It describes only the format and methods needed to 21 read, check, generate, and write conforming packets crossing any 22 network. It does not deal with storage and implementation questions. 23 It does, however, discuss implementation issues necessary to avoid 24 security flaws. 26 This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in 27 OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 8 September 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2. General functions . . . . . . . . . . . . . . . . . . . . . . 8 65 2.1. Confidentiality via Encryption . . . . . . . . . . . . . 8 66 2.2. Authentication via Digital Signature . . . . . . . . . . 9 67 2.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 10 68 2.4. Conversion to Radix-64 . . . . . . . . . . . . . . . . . 10 69 2.5. Signature-Only Applications . . . . . . . . . . . . . . . 10 70 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 10 71 3.1. Scalar Numbers . . . . . . . . . . . . . . . . . . . . . 10 72 3.2. Multiprecision Integers . . . . . . . . . . . . . . . . . 11 73 3.2.1. Using MPIs to encode other data . . . . . . . . . . . 11 74 3.3. Key IDs . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.4. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 3.5. Time Fields . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.6. Keyrings . . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.7. String-to-Key (S2K) Specifiers . . . . . . . . . . . . . 12 79 3.7.1. String-to-Key (S2K) Specifier Types . . . . . . . . . 12 80 3.7.1.1. Simple S2K . . . . . . . . . . . . . . . . . . . 13 81 3.7.1.2. Salted S2K . . . . . . . . . . . . . . . . . . . 14 82 3.7.1.3. Iterated and Salted S2K . . . . . . . . . . . . . 14 83 3.7.1.4. Argon2 . . . . . . . . . . . . . . . . . . . . . 15 84 3.7.2. String-to-Key Usage . . . . . . . . . . . . . . . . . 16 85 3.7.2.1. Secret-Key Encryption . . . . . . . . . . . . . . 16 86 3.7.2.2. Symmetric-Key Message Encryption . . . . . . . . 17 87 4. Packet Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 88 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 89 4.2. Packet Headers . . . . . . . . . . . . . . . . . . . . . 18 90 4.2.1. OpenPGP Format Packet Lengths . . . . . . . . . . . . 19 91 4.2.1.1. One-Octet Lengths . . . . . . . . . . . . . . . . 20 92 4.2.1.2. Two-Octet Lengths . . . . . . . . . . . . . . . . 20 93 4.2.1.3. Five-Octet Lengths . . . . . . . . . . . . . . . 20 94 4.2.1.4. Partial Body Lengths . . . . . . . . . . . . . . 20 95 4.2.2. Legacy Format Packet Lengths . . . . . . . . . . . . 21 96 4.2.3. Packet Length Examples . . . . . . . . . . . . . . . 21 97 4.3. Packet Tags . . . . . . . . . . . . . . . . . . . . . . . 22 98 5. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . 23 99 5.1. Public-Key Encrypted Session Key Packets (Tag 1) . . . . 23 100 5.1.1. v3 PKESK . . . . . . . . . . . . . . . . . . . . . . 23 101 5.1.2. v5 PKESK . . . . . . . . . . . . . . . . . . . . . . 24 102 5.1.3. Algorithm Specific Fields for RSA encryption . . . . 25 103 5.1.4. Algorithm Specific Fields for Elgamal encryption . . 25 104 5.1.5. Algorithm-Specific Fields for ECDH encryption . . . . 25 105 5.1.6. Notes on PKESK . . . . . . . . . . . . . . . . . . . 25 106 5.2. Signature Packet (Tag 2) . . . . . . . . . . . . . . . . 26 107 5.2.1. Signature Types . . . . . . . . . . . . . . . . . . . 26 108 5.2.2. Version 3 Signature Packet Format . . . . . . . . . . 28 109 5.2.3. Version 4 and 5 Signature Packet Formats . . . . . . 31 110 5.2.3.1. Algorithm-Specific Fields for RSA signatures . . 32 111 5.2.3.2. Algorithm-Specific Fields for DSA or ECDSA 112 signatures . . . . . . . . . . . . . . . . . . . . 32 113 5.2.3.3. Algorithm-Specific Fields for EdDSA signatures . 32 114 5.2.3.4. Notes on Signatures . . . . . . . . . . . . . . . 33 115 5.2.3.5. Signature Subpacket Specification . . . . . . . . 34 116 5.2.3.6. Signature Subpacket Types . . . . . . . . . . . . 37 117 5.2.3.7. Notes on Self-Signatures . . . . . . . . . . . . 37 118 5.2.3.8. Signature Creation Time . . . . . . . . . . . . . 38 119 5.2.3.9. Issuer . . . . . . . . . . . . . . . . . . . . . 38 120 5.2.3.10. Key Expiration Time . . . . . . . . . . . . . . . 38 121 5.2.3.11. Preferred Symmetric Ciphers for v1 SEIPD . . . . 39 122 5.2.3.12. Preferred AEAD Ciphersuites . . . . . . . . . . . 39 123 5.2.3.13. Preferred Hash Algorithms . . . . . . . . . . . . 40 124 5.2.3.14. Preferred Compression Algorithms . . . . . . . . 40 125 5.2.3.15. Signature Expiration Time . . . . . . . . . . . . 40 126 5.2.3.16. Exportable Certification . . . . . . . . . . . . 40 127 5.2.3.17. Revocable . . . . . . . . . . . . . . . . . . . . 41 128 5.2.3.18. Trust Signature . . . . . . . . . . . . . . . . . 41 129 5.2.3.19. Regular Expression . . . . . . . . . . . . . . . 42 130 5.2.3.20. Revocation Key . . . . . . . . . . . . . . . . . 42 131 5.2.3.21. Notation Data . . . . . . . . . . . . . . . . . . 43 132 5.2.3.22. Key Server Preferences . . . . . . . . . . . . . 44 133 5.2.3.23. Preferred Key Server . . . . . . . . . . . . . . 44 134 5.2.3.24. Primary User ID . . . . . . . . . . . . . . . . . 45 135 5.2.3.25. Policy URI . . . . . . . . . . . . . . . . . . . 45 136 5.2.3.26. Key Flags . . . . . . . . . . . . . . . . . . . . 45 137 5.2.3.27. Signer's User ID . . . . . . . . . . . . . . . . 47 138 5.2.3.28. Reason for Revocation . . . . . . . . . . . . . . 47 139 5.2.3.29. Features . . . . . . . . . . . . . . . . . . . . 49 140 5.2.3.30. Signature Target . . . . . . . . . . . . . . . . 50 141 5.2.3.31. Embedded Signature . . . . . . . . . . . . . . . 50 142 5.2.3.32. Issuer Fingerprint . . . . . . . . . . . . . . . 50 143 5.2.3.33. Intended Recipient Fingerprint . . . . . . . . . 50 144 5.2.4. Computing Signatures . . . . . . . . . . . . . . . . 51 145 5.2.4.1. Subpacket Hints . . . . . . . . . . . . . . . . . 52 146 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) . . . 53 147 5.3.1. v4 SKESK . . . . . . . . . . . . . . . . . . . . . . 53 148 5.3.2. v5 SKESK . . . . . . . . . . . . . . . . . . . . . . 54 149 5.4. One-Pass Signature Packets (Tag 4) . . . . . . . . . . . 55 150 5.5. Key Material Packet . . . . . . . . . . . . . . . . . . . 56 151 5.5.1. Key Packet Variants . . . . . . . . . . . . . . . . . 56 152 5.5.1.1. Public-Key Packet (Tag 6) . . . . . . . . . . . . 56 153 5.5.1.2. Public-Subkey Packet (Tag 14) . . . . . . . . . . 57 154 5.5.1.3. Secret-Key Packet (Tag 5) . . . . . . . . . . . . 57 155 5.5.1.4. Secret-Subkey Packet (Tag 7) . . . . . . . . . . 57 156 5.5.2. Public-Key Packet Formats . . . . . . . . . . . . . . 57 157 5.5.3. Secret-Key Packet Formats . . . . . . . . . . . . . . 59 158 5.6. Algorithm-specific Parts of Keys . . . . . . . . . . . . 61 159 5.6.1. Algorithm-Specific Part for RSA Keys . . . . . . . . 62 160 5.6.2. Algorithm-Specific Part for DSA Keys . . . . . . . . 62 161 5.6.3. Algorithm-Specific Part for Elgamal Keys . . . . . . 62 162 5.6.4. Algorithm-Specific Part for ECDSA Keys . . . . . . . 63 163 5.6.5. Algorithm-Specific Part for EdDSA Keys . . . . . . . 63 164 5.6.6. Algorithm-Specific Part for ECDH Keys . . . . . . . . 63 165 5.6.6.1. ECDH Secret Key Material . . . . . . . . . . . . 64 166 5.7. Compressed Data Packet (Tag 8) . . . . . . . . . . . . . 65 167 5.8. Symmetrically Encrypted Data Packet (Tag 9) . . . . . . . 66 168 5.9. Marker Packet (Tag 10) . . . . . . . . . . . . . . . . . 67 169 5.10. Literal Data Packet (Tag 11) . . . . . . . . . . . . . . 67 170 5.10.1. Special Filename _CONSOLE (Deprecated) . . . . . . . 69 171 5.11. Trust Packet (Tag 12) . . . . . . . . . . . . . . . . . . 69 172 5.12. User ID Packet (Tag 13) . . . . . . . . . . . . . . . . . 70 173 5.13. User Attribute Packet (Tag 17) . . . . . . . . . . . . . 70 174 5.13.1. The Image Attribute Subpacket . . . . . . . . . . . 71 175 5.14. Sym. Encrypted Integrity Protected Data Packet (Tag 176 18) . . . . . . . . . . . . . . . . . . . . . . . . . . 71 177 5.14.1. Version 1 Sym. Encrypted Integrity Protected Data 178 Packet Format . . . . . . . . . . . . . . . . . . . . 72 179 5.14.2. Version 2 Sym. Encrypted Integrity Protected Data 180 Packet Format . . . . . . . . . . . . . . . . . . . . 74 181 5.14.3. EAX Mode . . . . . . . . . . . . . . . . . . . . . . 76 182 5.14.4. OCB Mode . . . . . . . . . . . . . . . . . . . . . . 76 183 5.14.5. GCM Mode . . . . . . . . . . . . . . . . . . . . . . 76 184 5.15. Padding Packet (Tag 21) . . . . . . . . . . . . . . . . . 76 185 6. Radix-64 Conversions . . . . . . . . . . . . . . . . . . . . 77 186 6.1. An Implementation of the CRC-24 in "C" . . . . . . . . . 78 187 6.2. Forming ASCII Armor . . . . . . . . . . . . . . . . . . . 78 188 6.3. Encoding Binary in Radix-64 . . . . . . . . . . . . . . . 81 189 6.4. Decoding Radix-64 . . . . . . . . . . . . . . . . . . . . 83 190 6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 83 191 6.6. Example of an ASCII Armored Message . . . . . . . . . . . 84 192 7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 84 193 7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 85 194 8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 86 195 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 87 196 9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 87 197 9.2. ECC Curves for OpenPGP . . . . . . . . . . . . . . . . . 89 198 9.2.1. Curve-Specific Wire Formats . . . . . . . . . . . . . 91 199 9.3. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 92 200 9.4. Compression Algorithms . . . . . . . . . . . . . . . . . 93 201 9.5. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 93 202 9.6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . 94 203 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 204 10.1. New String-to-Key Specifier Types . . . . . . . . . . . 95 205 10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 95 206 10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 96 207 10.2.1.1. Image Format Subpacket Types . . . . . . . . . . 96 208 10.2.2. New Signature Subpackets . . . . . . . . . . . . . . 96 209 10.2.2.1. Signature Notation Data Subpackets . . . . . . . 96 210 10.2.2.2. Signature Notation Data Subpacket Notation 211 Flags . . . . . . . . . . . . . . . . . . . . . . . 97 212 10.2.2.3. Key Server Preference Extensions . . . . . . . . 97 213 10.2.2.4. Key Flags Extensions . . . . . . . . . . . . . . 97 214 10.2.2.5. Reason for Revocation Extensions . . . . . . . . 97 215 10.2.2.6. Implementation Features . . . . . . . . . . . . 97 216 10.2.3. New Packet Versions . . . . . . . . . . . . . . . . 98 217 10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 98 218 10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 98 219 10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 99 220 10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 99 221 10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 100 222 10.3.5. Elliptic Curve Algorithms . . . . . . . . . . . . . 100 223 10.4. Elliptic Curve Point and Scalar Wire Formats . . . . . . 100 224 10.5. Changes to existing registries . . . . . . . . . . . . . 101 225 11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 101 226 11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 101 227 11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 103 228 11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 103 229 11.3.1. Unwrapping Encrypted and Compressed Messages . . . . 104 230 11.3.2. Additional Constraints on Packet Sequences . . . . . 104 231 11.3.2.1. Packet Versions in Encrypted Messages . . . . . 105 232 11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 106 233 12. Enhanced Key Formats . . . . . . . . . . . . . . . . . . . . 106 234 12.1. Key Structures . . . . . . . . . . . . . . . . . . . . . 106 235 12.2. Key IDs and Fingerprints . . . . . . . . . . . . . . . . 107 236 13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 108 237 13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 109 238 13.2. EC Point Wire Formats . . . . . . . . . . . . . . . . . 109 239 13.2.1. SEC1 EC Point Wire Format . . . . . . . . . . . . . 109 240 13.2.2. Prefixed Native EC Point Wire Format . . . . . . . . 110 241 13.2.3. Notes on EC Point Wire Formats . . . . . . . . . . . 110 242 13.3. EC Scalar Wire Formats . . . . . . . . . . . . . . . . . 110 243 13.3.1. EC Octet String Wire Format . . . . . . . . . . . . 111 244 13.3.2. Elliptic Curve Prefixed Octet String Wire Format . . 112 245 13.4. Key Derivation Function . . . . . . . . . . . . . . . . 112 246 13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 113 247 14. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 116 248 14.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 116 249 14.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 116 250 14.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 117 251 14.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 118 252 14.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 119 253 14.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . 119 254 14.3. Other Algorithm Preferences . . . . . . . . . . . . . . 120 255 14.3.1. Compression Preferences . . . . . . . . . . . . . . 120 256 14.3.1.1. Uncompressed . . . . . . . . . . . . . . . . . . 120 257 14.3.2. Hash Algorithm Preferences . . . . . . . . . . . . . 120 258 14.4. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 121 259 14.5. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . 121 260 14.6. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 121 261 14.7. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 122 262 14.8. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 122 263 14.9. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 122 264 14.10. Private or Experimental Parameters . . . . . . . . . . . 124 265 14.11. Meta-Considerations for Expansion . . . . . . . . . . . 124 266 15. Security Considerations . . . . . . . . . . . . . . . . . . . 124 267 15.1. Avoiding Ciphertext Malleability . . . . . . . . . . . . 128 268 15.2. Escrowed Revocation Signatures . . . . . . . . . . . . . 130 269 15.3. Random Number Generation and Seeding . . . . . . . . . . 131 270 15.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 131 271 16. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 132 272 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 133 273 17.1. Normative References . . . . . . . . . . . . . . . . . . 133 274 17.2. Informative References . . . . . . . . . . . . . . . . . 136 275 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 138 276 A.1. Sample EdDSA key . . . . . . . . . . . . . . . . . . . . 138 277 A.2. Sample EdDSA signature . . . . . . . . . . . . . . . . . 138 278 A.3. Sample AEAD-EAX encryption and decryption . . . . . . . . 139 279 A.3.1. Sample Parameters . . . . . . . . . . . . . . . . . . 139 280 A.3.2. Sample symmetric-key encrypted session key packet 281 (v5) . . . . . . . . . . . . . . . . . . . . . . . . 139 282 A.3.3. Starting AEAD-EAX decryption of the session key . . . 140 283 A.3.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 140 284 A.3.5. Decryption of data . . . . . . . . . . . . . . . . . 141 285 A.3.6. Complete AEAD-EAX encrypted packet sequence . . . . . 142 287 A.4. Sample AEAD-OCB encryption and decryption . . . . . . . . 142 288 A.4.1. Sample Parameters . . . . . . . . . . . . . . . . . . 142 289 A.4.2. Sample symmetric-key encrypted session key packet 290 (v5) . . . . . . . . . . . . . . . . . . . . . . . . 143 291 A.4.3. Starting AEAD-EAX decryption of the session key . . . 143 292 A.4.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 144 293 A.4.5. Decryption of data . . . . . . . . . . . . . . . . . 144 294 A.4.6. Complete AEAD-EAX encrypted packet sequence . . . . . 145 295 A.5. Sample AEAD-GCM encryption and decryption . . . . . . . . 146 296 A.5.1. Sample Parameters . . . . . . . . . . . . . . . . . . 146 297 A.5.2. Sample symmetric-key encrypted session key packet 298 (v5) . . . . . . . . . . . . . . . . . . . . . . . . 146 299 A.5.3. Starting AEAD-EAX decryption of the session key . . . 146 300 A.5.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 147 301 A.5.5. Decryption of data . . . . . . . . . . . . . . . . . 148 302 A.5.6. Complete AEAD-EAX encrypted packet sequence . . . . . 149 303 A.6. Sample message encrypted using Argon2 . . . . . . . . . . 149 304 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 150 305 Appendix C. Document Workflow . . . . . . . . . . . . . . . . . 150 306 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 150 308 1. Introduction 310 This document provides information on the message-exchange packet 311 formats used by OpenPGP to provide encryption, decryption, signing, 312 and key management functions. It is a revision of RFC 4880, "OpenPGP 313 Message Format", which is a revision of RFC 2440, which itself 314 replaces RFC 1991, "PGP Message Exchange Formats" [RFC1991] [RFC2440] 315 [RFC4880]. 317 This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in 318 OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP). 320 1.1. Terms 322 * OpenPGP - This is a term for security software that uses PGP 5 as 323 a basis, formalized in this document. 325 * PGP - Pretty Good Privacy. PGP is a family of software systems 326 developed by Philip R. Zimmermann from which OpenPGP is based. 328 * PGP 2 - This version of PGP has many variants; where necessary a 329 more detailed version number is used here. PGP 2 uses only RSA, 330 MD5, and IDEA for its cryptographic transforms. An informational 331 RFC, RFC 1991, was written describing this version of PGP. 333 * PGP 5 - This version of PGP is formerly known as "PGP 3" in the 334 community. It has new formats and corrects a number of problems 335 in the PGP 2 design. It is referred to here as PGP 5 because that 336 software was the first release of the "PGP 3" code base. 338 * GnuPG - GNU Privacy Guard, also called GPG. GnuPG is an OpenPGP 339 implementation that avoids all encumbered algorithms. 340 Consequently, early versions of GnuPG did not include RSA public 341 keys. 343 "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP 344 Corporation and are used with permission. The term "OpenPGP" refers 345 to the protocol described in this and related documents. 347 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 348 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 349 "OPTIONAL" in this document are to be interpreted as described in BCP 350 14 [RFC2119] [RFC8174] when, and only when, they appear in all 351 capitals, as shown here. 353 The key words "PRIVATE USE", "SPECIFICATION REQUIRED", and "RFC 354 REQUIRED" that appear in this document when used to describe 355 namespace allocation are to be interpreted as described in [RFC8126]. 357 2. General functions 359 OpenPGP provides data integrity services for messages and data files 360 by using these core technologies: 362 * digital signatures 364 * encryption 366 * compression 368 * Radix-64 conversion 370 In addition, OpenPGP provides key management and certificate 371 services, but many of these are beyond the scope of this document. 373 2.1. Confidentiality via Encryption 375 OpenPGP combines symmetric-key encryption and public-key encryption 376 to provide confidentiality. When made confidential, first the object 377 is encrypted using a symmetric encryption algorithm. Each symmetric 378 key is used only once, for a single object. A new "session key" is 379 generated as a random number for each object (sometimes referred to 380 as a session). Since it is used only once, the session key is bound 381 to the message and transmitted with it. To protect the key, it is 382 encrypted with the receiver's public key. The sequence is as 383 follows: 385 1. The sender creates a message. 387 2. The sending OpenPGP generates a random number to be used as a 388 session key for this message only. 390 3. The session key is encrypted using each recipient's public key. 391 These "encrypted session keys" start the message. 393 4. The sending OpenPGP encrypts the message using the session key, 394 which forms the remainder of the message. 396 5. The receiving OpenPGP decrypts the session key using the 397 recipient's private key. 399 6. The receiving OpenPGP decrypts the message using the session key. 400 If the message was compressed, it will be decompressed. 402 With symmetric-key encryption, an object may be encrypted with a 403 symmetric key derived from a passphrase (or other shared secret), or 404 a two-stage mechanism similar to the public-key method described 405 above in which a session key is itself encrypted with a symmetric 406 algorithm keyed from a shared secret. 408 Both digital signature and confidentiality services may be applied to 409 the same message. First, a signature is generated for the message 410 and attached to the message. Then the message plus signature is 411 encrypted using a symmetric session key. Finally, the session key is 412 encrypted using public-key encryption and prefixed to the encrypted 413 block. 415 2.2. Authentication via Digital Signature 417 The digital signature uses a hash code or message digest algorithm, 418 and a public-key signature algorithm. The sequence is as follows: 420 1. The sender creates a message. 422 2. The sending software generates a hash code of the message. 424 3. The sending software generates a signature from the hash code 425 using the sender's private key. 427 4. The binary signature is attached to the message. 429 5. The receiving software keeps a copy of the message signature. 431 6. The receiving software generates a new hash code for the received 432 message and verifies it using the message's signature. If the 433 verification is successful, the message is accepted as authentic. 435 2.3. Compression 437 If an implementation does not implement compression, its authors 438 should be aware that most OpenPGP messages in the world are 439 compressed. Thus, it may even be wise for a space-constrained 440 implementation to implement decompression, but not compression. 442 2.4. Conversion to Radix-64 444 OpenPGP's underlying native representation for encrypted messages, 445 signature certificates, and keys is a stream of arbitrary octets. 446 Some systems only permit the use of blocks consisting of seven-bit, 447 printable text. For transporting OpenPGP's native raw binary octets 448 through channels that are not safe to raw binary data, a printable 449 encoding of these binary octets is needed. OpenPGP provides the 450 service of converting the raw 8-bit binary octet stream to a stream 451 of printable ASCII characters, called Radix-64 encoding or ASCII 452 Armor. 454 Implementations SHOULD provide Radix-64 conversions. 456 2.5. Signature-Only Applications 458 OpenPGP is designed for applications that use both encryption and 459 signatures, but there are a number of problems that are solved by a 460 signature-only implementation. Although this specification requires 461 both encryption and signatures, it is reasonable for there to be 462 subset implementations that are non-conformant only in that they omit 463 encryption. 465 3. Data Element Formats 467 This section describes the data elements used by OpenPGP. 469 3.1. Scalar Numbers 471 Scalar numbers are unsigned and are always stored in big-endian 472 format. Using n[k] to refer to the kth octet being interpreted, the 473 value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a 474 four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + 475 n[3]). 477 3.2. Multiprecision Integers 479 Multiprecision integers (also called MPIs) are unsigned integers used 480 to hold large integers such as the ones used in cryptographic 481 calculations. 483 An MPI consists of two pieces: a two-octet scalar that is the length 484 of the MPI in bits followed by a string of octets that contain the 485 actual integer. 487 These octets form a big-endian number; a big-endian number can be 488 made into an MPI by prefixing it with the appropriate length. 490 Examples: 492 (all numbers are in hexadecimal) 494 The string of octets [00 01 01] forms an MPI with the value 1. The 495 string [00 09 01 FF] forms an MPI with the value of 511. 497 Additional rules: 499 The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. 501 The length field of an MPI describes the length starting from its 502 most significant non-zero bit. Thus, the MPI [00 02 01] is not 503 formed correctly. It should be [00 01 01]. 505 Unused bits of an MPI MUST be zero. 507 Also note that when an MPI is encrypted, the length refers to the 508 plaintext MPI. It may be ill-formed in its ciphertext. 510 3.2.1. Using MPIs to encode other data 512 Note that MPIs are used in some places used to encode non-integer 513 data, such as an elliptic curve point (see Section 13.2, or an octet 514 string of known, fixed length (see Section 13.3). The wire 515 representation is the same: two octets of length in bits counted from 516 the first non-zero bit, followed by the smallest series of octets 517 that can represent the value while stripping off any leading zero 518 octets. 520 3.3. Key IDs 522 A Key ID is an eight-octet scalar that identifies a key. 523 Implementations SHOULD NOT assume that Key IDs are unique. 524 Section 12.2 describes how Key IDs are formed. 526 3.4. Text 528 Unless otherwise specified, the character set for text is the UTF-8 529 [RFC3629] encoding of Unicode [ISO10646]. 531 3.5. Time Fields 533 A time field is an unsigned four-octet number containing the number 534 of seconds elapsed since midnight, 1 January 1970 UTC. 536 3.6. Keyrings 538 A keyring is a collection of one or more keys in a file or database. 539 Traditionally, a keyring is simply a sequential list of keys, but may 540 be any suitable database. It is beyond the scope of this standard to 541 discuss the details of keyrings or other databases. 543 3.7. String-to-Key (S2K) Specifiers 545 A string-to-key (S2K) specifier is used to convert a passphrase 546 string into a symmetric-key encryption/decryption key. They are used 547 in two places, currently: to encrypt the secret part of private keys 548 in the private keyring, and to convert passphrases to encryption keys 549 for symmetrically encrypted messages. 551 3.7.1. String-to-Key (S2K) Specifier Types 553 There are four types of S2K specifiers currently supported, and some 554 reserved values: 556 +=====+==============+==================+===============+===========+ 557 | ID | S2K Type | Generate? | S2K field | Reference | 558 | | | | size (octets) | | 559 +=====+==============+==================+===============+===========+ 560 | 0 | Simple S2K | N | 2 | Section | 561 | | | | | 3.7.1.1 | 562 +-----+--------------+------------------+---------------+-----------+ 563 | 1 | Salted S2K | Only when | 10 | Section | 564 | | | string is | | 3.7.1.2 | 565 | | | high entropy | | | 566 +-----+--------------+------------------+---------------+-----------+ 567 | 2 | Reserved | N | | | 568 | | value | | | | 569 +-----+--------------+------------------+---------------+-----------+ 570 | 3 | Iterated and | Y | 11 | Section | 571 | | Salted S2K | | | 3.7.1.3 | 572 +-----+--------------+------------------+---------------+-----------+ 573 | 4 | Argon2 | Y | 20 | Section | 574 | | | | | 3.7.1.4 | 575 +-----+--------------+------------------+---------------+-----------+ 576 | 100 | Private/ | As | | | 577 | to | Experimental | appropriate | | | 578 | 110 | S2K | | | | 579 +-----+--------------+------------------+---------------+-----------+ 581 Table 1: S2K type registry 583 These are described in the subsections below. 585 3.7.1.1. Simple S2K 587 This directly hashes the string to produce the key data. See below 588 for how this hashing is done. 590 Octet 0: 0x00 591 Octet 1: hash algorithm 593 Simple S2K hashes the passphrase to produce the session key. The 594 manner in which this is done depends on the size of the session key 595 (which will depend on the cipher used) and the size of the hash 596 algorithm's output. If the hash size is greater than the session key 597 size, the high-order (leftmost) octets of the hash are used as the 598 key. 600 If the hash size is less than the key size, multiple instances of the 601 hash context are created --- enough to produce the required key data. 602 These instances are preloaded with 0, 1, 2, ... octets of zeros (that 603 is to say, the first instance has no preloading, the second gets 604 preloaded with 1 octet of zero, the third is preloaded with two 605 octets of zeros, and so forth). 607 As the data is hashed, it is given independently to each hash 608 context. Since the contexts have been initialized differently, they 609 will each produce different hash output. Once the passphrase is 610 hashed, the output data from the multiple hashes is concatenated, 611 first hash leftmost, to produce the key data, with any excess octets 612 on the right discarded. 614 3.7.1.2. Salted S2K 616 This includes a "salt" value in the S2K specifier --- some arbitrary 617 data --- that gets hashed along with the passphrase string, to help 618 prevent dictionary attacks. 620 Octet 0: 0x01 621 Octet 1: hash algorithm 622 Octets 2-9: 8-octet salt value 624 Salted S2K is exactly like Simple S2K, except that the input to the 625 hash function(s) consists of the 8 octets of salt from the S2K 626 specifier, followed by the passphrase. 628 3.7.1.3. Iterated and Salted S2K 630 This includes both a salt and an octet count. The salt is combined 631 with the passphrase and the resulting value is hashed repeatedly. 632 This further increases the amount of work an attacker must do to try 633 dictionary attacks. 635 Octet 0: 0x03 636 Octet 1: hash algorithm 637 Octets 2-9: 8-octet salt value 638 Octet 10: count, a one-octet, coded value 640 The count is coded into a one-octet number using the following 641 formula: 643 #define EXPBIAS 6 644 count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); 646 The above formula is in C, where "Int32" is a type for a 32-bit 647 integer, and the variable "c" is the coded count, Octet 10. 649 Iterated-Salted S2K hashes the passphrase and salt data multiple 650 times. The total number of octets to be hashed is specified in the 651 encoded count in the S2K specifier. Note that the resulting count 652 value is an octet count of how many octets will be hashed, not an 653 iteration count. 655 Initially, one or more hash contexts are set up as with the other S2K 656 algorithms, depending on how many octets of key data are needed. 657 Then the salt, followed by the passphrase data, is repeatedly hashed 658 until the number of octets specified by the octet count has been 659 hashed. The one exception is that if the octet count is less than 660 the size of the salt plus passphrase, the full salt plus passphrase 661 will be hashed even though that is greater than the octet count. 662 After the hashing is done, the data is unloaded from the hash 663 context(s) as with the other S2K algorithms. 665 3.7.1.4. Argon2 667 This S2K method hashes the passphrase using Argon2, specified in 668 [RFC9106]. This provides memory-hardness, further protecting the 669 passphrase against brute-force attacks. 671 Octet 0: 0x04 672 Octets 1-16: 16-octet salt value 673 Octet 17: one-octet number of passes t 674 Octet 18: one-octet degree of parallelism p 675 Octet 19: one-octet exponent indicating the memory size m 677 The salt SHOULD be unique for each password. 679 The number of passes t and the degree of parallelism p MUST be non- 680 zero. 682 The memory size m is 2**encoded_m kibibytes of RAM, where "encoded_m" 683 is the encoded memory size in Octet 19. The encoded memory size MUST 684 be a value from 3+ceil(log_2(p)) to 31, such that the decoded memory 685 size m is a value from 8*p to 2**31. Note that memory-hardness size 686 is indicated in kibibytes (KiB), not octets. 688 Argon2 is invoked with the passphrase as P, the salt as S, the values 689 of t, p and m as described above, the required key size as the tag 690 length T, 0x13 as the version v, and Argon2id as the type. 692 For the recommended values of t, p and m, see Section 4 of [RFC9106]. 693 If the recommended value of m for a given application is not a power 694 of 2, it is RECOMMENDED to round up to the next power of 2 if the 695 resulting performance would be acceptable, and round down otherwise 696 (keeping in mind that m must be at least 8*p). 698 As an example, with the first recommended option (t=1, p=4, m=2**21), 699 the full S2K specifier would be: 701 04 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 702 XX 01 04 15 704 (where XX represents a random octet of salt). 706 3.7.2. String-to-Key Usage 708 Simple S2K and Salted S2K specifiers can be brute-forced when used 709 with a low-entropy string, such as those typically provided by users. 710 In addition, the usage of Simple S2K can lead to key and IV reuse 711 (see Section 5.3). Therefore, when generating S2K specifiers, 712 implementations MUST NOT use Simple S2K, and SHOULD NOT use Salted 713 S2K unless the implementation knows that the string is high-entropy 714 (for example, it generated the string itself using a known-good 715 source of randomness). It is RECOMMENDED that implementations use 716 Argon2. 718 3.7.2.1. Secret-Key Encryption 720 An S2K specifier can be stored in the secret keyring to specify how 721 to convert the passphrase to a key that unlocks the secret data. 722 Older versions of PGP just stored a symmetric cipher algorithm octet 723 preceding the secret data or a zero to indicate that the secret data 724 was unencrypted. The MD5 hash function was always used to convert 725 the passphrase to a key for the specified cipher algorithm. 727 For compatibility, when an S2K specifier is used, the special value 728 253, 254, or 255 is stored in the position where the cipher algorithm 729 octet would have been in the old data structure. This is then 730 followed immediately by a one-octet algorithm identifier, and other 731 fields relevant to the type of encryption used. 733 Therefore, the first octet of the secret key material describes how 734 the secret key data is presented. 736 In the table below, check(x) means the "2-octet checksum" meaning the 737 sum of all octets in x mod 65536. 739 +==============+================+=====================+===========+ 740 | First octet | Next fields | Encryption | Generate? | 741 +==============+================+=====================+===========+ 742 | 0 | - | cleartext | Yes | 743 | | | secrets || | | 744 | | | check(secrets) | | 745 +--------------+----------------+---------------------+-----------+ 746 | Known | IV | CFB(MD5(password), | No | 747 | symmetric | | secrets || | | 748 | cipher algo | | check(secrets)) | | 749 | ID (see | | | | 750 | Section 9.3) | | | | 751 +--------------+----------------+---------------------+-----------+ 752 | 253 | cipher-algo, | AEAD(S2K(password), | Yes | 753 | | AEAD-mode, | secrets, pubkey) | | 754 | | S2K-specifier, | | | 755 | | nonce | | | 756 +--------------+----------------+---------------------+-----------+ 757 | 254 | cipher-algo, | CFB(S2K(password), | Yes | 758 | | S2K-specifier, | secrets || | | 759 | | IV | SHA1(secrets)) | | 760 +--------------+----------------+---------------------+-----------+ 761 | 255 | cipher-algo, | CFB(S2K(password), | No | 762 | | S2K-specifier, | secrets || | | 763 | | IV | check(secrets)) | | 764 +--------------+----------------+---------------------+-----------+ 766 Table 2: Secret Key protection details 768 Each row with "Generate?" marked as "No" is described for backward 769 compatibility, and MUST NOT be generated. 771 An implementation MUST NOT create and MUST reject as malformed a 772 secret key packet where the S2K usage octet is anything but 253 and 773 the S2K specifier type is Argon2. 775 3.7.2.2. Symmetric-Key Message Encryption 777 OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet 778 at the front of a message. This is used to allow S2K specifiers to 779 be used for the passphrase conversion or to create messages with a 780 mix of symmetric-key ESKs and public-key ESKs. This allows a message 781 to be decrypted either with a passphrase or a public-key pair. 783 PGP 2 always used IDEA with Simple string-to-key conversion when 784 encrypting a message with a symmetric algorithm. See Section 5.8. 785 This MUST NOT be generated, but MAY be consumed for backward- 786 compatibility. 788 4. Packet Syntax 790 This section describes the packets used by OpenPGP. 792 4.1. Overview 794 An OpenPGP message is constructed from a number of records that are 795 traditionally called packets. A packet is a chunk of data that has a 796 tag specifying its meaning. An OpenPGP message, keyring, 797 certificate, and so forth consists of a number of packets. Some of 798 those packets may contain other OpenPGP packets (for example, a 799 compressed data packet, when uncompressed, contains OpenPGP packets). 801 Each packet consists of a packet header, followed by the packet body. 802 The packet header is of variable length. 804 When handling a stream of packets, the length information in each 805 packet header is the canonical source of packet boundaries. An 806 implementation handling a packet stream that wants to find the next 807 packet MUST look for it at the precise offset indicated in the 808 previous packet header. 810 Additionally, some packets contain internal length indicators (for 811 example, a subfield within the packet). In the event that a subfield 812 length indicator within a packet implies inclusion of octets outside 813 the range indicated in the packet header, a parser MUST truncate the 814 subfield at the octet boundary indicated in the packet header. Such 815 a truncation renders the packet malformed and unusable. An 816 implementation MUST NOT interpret octets outside the range indicated 817 in the packet header as part of the contents of the packet. 819 4.2. Packet Headers 821 The first octet of the packet header is called the "Packet Tag". It 822 determines the format of the header and denotes the packet contents. 823 The remainder of the packet header is the length of the packet. 825 There are two packet formats, the (current) OpenPGP packet format 826 specified by this document and its predecessors and the Legacy packet 827 format as used by PGP 2.x implementations. 829 Note that the most significant bit is the leftmost bit, called bit 7. 830 A mask for this bit is 0x80 in hexadecimal. 832 ┌───────────────┐ 833 PTag │7 6 5 4 3 2 1 0│ 834 └───────────────┘ 835 Bit 7 -- Always one 836 Bit 6 -- Always one (except for Legacy packet format) 838 The Legacy packet format MAY be used when consuming packets to 839 facilitate interoperability with legacy implementations and accessing 840 archived data. The Legacy packet format SHOULD NOT be used to 841 generate new data, unless the recipient is known to only support the 842 Legacy packet format. 844 An implementation that consumes and re-distributes pre-existing 845 OpenPGP data (such as Transferable Public Keys) may encounter packets 846 framed with the Legacy packet format. Such an implementation MAY 847 either re-distribute these packets in their Legacy format, or 848 transform them to the current OpenPGP packet format before re- 849 distribution. 851 The current OpenPGP packet format packets contain: 853 Bits 5 to 0 -- packet tag 855 Legacy packet format packets contain: 857 Bits 5 to 2 -- packet tag 858 Bits 1 to 0 -- length-type 860 4.2.1. OpenPGP Format Packet Lengths 862 OpenPGP format packets have four possible ways of encoding length: 864 1. A one-octet Body Length header encodes packet lengths of up to 865 191 octets. 867 2. A two-octet Body Length header encodes packet lengths of 192 to 868 8383 octets. 870 3. A five-octet Body Length header encodes packet lengths of up to 871 4,294,967,295 (0xFFFFFFFF) octets in length. (This actually 872 encodes a four-octet scalar number.) 874 4. When the length of the packet body is not known in advance by the 875 issuer, Partial Body Length headers encode a packet of 876 indeterminate length, effectively making it a stream. 878 4.2.1.1. One-Octet Lengths 880 A one-octet Body Length header encodes a length of 0 to 191 octets. 881 This type of length header is recognized because the one octet value 882 is less than 192. The body length is equal to: 884 bodyLen = 1st_octet; 886 4.2.1.2. Two-Octet Lengths 888 A two-octet Body Length header encodes a length of 192 to 8383 889 octets. It is recognized because its first octet is in the range 192 890 to 223. The body length is equal to: 892 bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 894 4.2.1.3. Five-Octet Lengths 896 A five-octet Body Length header consists of a single octet holding 897 the value 255, followed by a four-octet scalar. The body length is 898 equal to: 900 bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | 901 (4th_octet << 8) | 5th_octet 903 This basic set of one, two, and five-octet lengths is also used 904 internally to some packets. 906 4.2.1.4. Partial Body Lengths 908 A Partial Body Length header is one octet long and encodes the length 909 of only part of the data packet. This length is a power of 2, from 1 910 to 1,073,741,824 (2 to the 30th power). It is recognized by its one 911 octet value that is greater than or equal to 224, and less than 255. 912 The Partial Body Length is equal to: 914 partialBodyLen = 1 << (1st_octet & 0x1F); 916 Each Partial Body Length header is followed by a portion of the 917 packet body data. The Partial Body Length header specifies this 918 portion's length. Another length header (one octet, two-octet, five- 919 octet, or partial) follows that portion. The last length header in 920 the packet MUST NOT be a Partial Body Length header. Partial Body 921 Length headers may only be used for the non-final parts of the 922 packet. 924 Note also that the last Body Length header can be a zero-length 925 header. 927 An implementation MAY use Partial Body Lengths for data packets, be 928 they literal, compressed, or encrypted. The first partial length 929 MUST be at least 512 octets long. Partial Body Lengths MUST NOT be 930 used for any other packet types. 932 4.2.2. Legacy Format Packet Lengths 934 The meaning of the length-type in Legacy format packets is: 936 0 The packet has a one-octet length. The header is 2 octets long. 938 1 The packet has a two-octet length. The header is 3 octets long. 940 2 The packet has a four-octet length. The header is 5 octets long. 942 3 The packet is of indeterminate length. The header is 1 octet 943 long, and the implementation must determine how long the packet 944 is. If the packet is in a file, this means that the packet 945 extends until the end of the file. The OpenPGP format headers 946 have a mechanism for precisely encoding data of indeterminate 947 length. An implementation MUST NOT generate a Legacy format 948 packet with indeterminate length. An implementation MAY interpret 949 an indeterminate length Legacy format packet in order to deal with 950 historic data, or data generated by a legacy system. 952 4.2.3. Packet Length Examples 954 These examples show ways that OpenPGP format packets might encode the 955 packet lengths. 957 A packet with length 100 may have its length encoded in one octet: 958 0x64. This is followed by 100 octets of data. 960 A packet with length 1723 may have its length encoded in two octets: 961 0xC5, 0xFB. This header is followed by the 1723 octets of data. 963 A packet with length 100000 may have its length encoded in five 964 octets: 0xFF, 0x00, 0x01, 0x86, 0xA0. 966 It might also be encoded in the following octet stream: 0xEF, first 967 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one 968 octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693 969 octets of data. This is just one possible encoding, and many 970 variations are possible on the size of the Partial Body Length 971 headers, as long as a regular Body Length header encodes the last 972 portion of the data. 974 Please note that in all of these explanations, the total length of 975 the packet is the length of the header(s) plus the length of the 976 body. 978 4.3. Packet Tags 980 The packet tag denotes what type of packet the body holds. Note that 981 Legacy format headers can only have tags less than 16, whereas 982 OpenPGP format headers can have tags as great as 63. The defined 983 tags (in decimal) are as follows: 985 +==========+========================================================+ 986 | Tag | Packet Type | 987 +==========+========================================================+ 988 | 0 | Reserved - a packet tag MUST NOT have this value | 989 +----------+--------------------------------------------------------+ 990 | 1 | Public-Key Encrypted Session Key Packet | 991 +----------+--------------------------------------------------------+ 992 | 2 | Signature Packet | 993 +----------+--------------------------------------------------------+ 994 | 3 | Symmetric-Key Encrypted Session Key Packet | 995 +----------+--------------------------------------------------------+ 996 | 4 | One-Pass Signature Packet | 997 +----------+--------------------------------------------------------+ 998 | 5 | Secret-Key Packet | 999 +----------+--------------------------------------------------------+ 1000 | 6 | Public-Key Packet | 1001 +----------+--------------------------------------------------------+ 1002 | 7 | Secret-Subkey Packet | 1003 +----------+--------------------------------------------------------+ 1004 | 8 | Compressed Data Packet | 1005 +----------+--------------------------------------------------------+ 1006 | 9 | Symmetrically Encrypted Data Packet | 1007 +----------+--------------------------------------------------------+ 1008 | 10 | Marker Packet | 1009 +----------+--------------------------------------------------------+ 1010 | 11 | Literal Data Packet | 1011 +----------+--------------------------------------------------------+ 1012 | 12 | Trust Packet | 1013 +----------+--------------------------------------------------------+ 1014 | 13 | User ID Packet | 1015 +----------+--------------------------------------------------------+ 1016 | 14 | Public-Subkey Packet | 1017 +----------+--------------------------------------------------------+ 1018 | 17 | User Attribute Packet | 1019 +----------+--------------------------------------------------------+ 1020 | 18 | Sym. Encrypted and Integrity Protected Data Packet | 1021 +----------+--------------------------------------------------------+ 1022 | 19 | Reserved (formerly Modification Detection Code Packet) | 1023 +----------+--------------------------------------------------------+ 1024 | 20 | Reserved (formerly AEAD Encrypted Data Packet) | 1025 +----------+--------------------------------------------------------+ 1026 | 21 | Padding Packet | 1027 +----------+--------------------------------------------------------+ 1028 | 60 to | Private or Experimental Values | 1029 | 63 | | 1030 +----------+--------------------------------------------------------+ 1032 Table 3: Packet type registry 1034 5. Packet Types 1036 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 1038 Zero or more Public-Key Encrypted Session Key (PKESK) packets and/or 1039 Symmetric-Key Encrypted Session Key packets (Section 5.3) may precede 1040 an encryption container (that is, a Symmetrically Encrypted Integrity 1041 Protected Data packet or --- for historic data --- a Symmetrically 1042 Encrypted Data packet), which holds an encrypted message. The 1043 message is encrypted with the session key, and the session key is 1044 itself encrypted and stored in the Encrypted Session Key packet(s). 1045 The encryption container is preceded by one Public-Key Encrypted 1046 Session Key packet for each OpenPGP key to which the message is 1047 encrypted. The recipient of the message finds a session key that is 1048 encrypted to their public key, decrypts the session key, and then 1049 uses the session key to decrypt the message. 1051 The body of this packet starts with a one-octet number giving the 1052 version number of the packet type. The currently defined versions 1053 are 3 and 5. The remainder of the packet depends on the version. 1055 The versions differ in how they identify the recipient key, and in 1056 what they encode. The version of the PKESK packet must align with 1057 the version of the SEIPD packet (see Section 11.3.2.1). 1059 5.1.1. v3 PKESK 1061 A version 3 Public-Key Encrypted Session Key (PKESK) packet precedes 1062 a version 1 Symmetrically Encrypted Integrity Protected Data (v1 1063 SEIPD, see Section 5.14.1) packet. In historic data, it is sometimes 1064 found preceding a deprecated Symmetrically Encrypted Data packet 1065 (SED, see Section 5.8). A v3 PKESK packet MUST NOT precede a v2 1066 SEIPD packet (see Section 11.3.2.1). 1068 The v3 PKESK packet consists of: 1070 * A one-octet version number with value 3. 1072 * An eight-octet number that gives the Key ID of the public key to 1073 which the session key is encrypted. If the session key is 1074 encrypted to a subkey, then the Key ID of this subkey is used here 1075 instead of the Key ID of the primary key. The Key ID may also be 1076 all zeros, for an "anonymous recipient" (see Section 5.1.6). 1078 * A one-octet number giving the public-key algorithm used. 1080 * A series of values comprising the encrypted session key. This is 1081 algorithm-specific and described below. 1083 When creating a v3 PKESK packet, the session key is first prefixed 1084 with a one-octet algorithm identifier that specifies the symmetric 1085 encryption algorithm used to encrypt the following encryption 1086 container. Then a two-octet checksum is appended, which is equal to 1087 the sum of the preceding session key octets, not including the 1088 algorithm identifier, modulo 65536. 1090 The resulting octet string (algorithm identifier, session key, and 1091 checksum) is encrypted according to the public-key algorithm used, as 1092 described below. 1094 5.1.2. v5 PKESK 1096 A version 5 Public-Key Encrypted Session Key (PKESK) packet precedes 1097 a version 2 Symmetrically Encrypted Integrity Protected Data (v2 1098 SEIPD, see Section 5.14.2) packet. A v5 PKESK packet MUST NOT 1099 precede a v1 SEIPD packet or a deprecated Symmetrically Encrypted 1100 Data packet (see Section 11.3.2.1). 1102 The v5 PKESK packet consists of: 1104 * A one-octet version number with value 5. 1106 * A one octet key version number and N octets of the fingerprint of 1107 the public key or subkey to which the session key is encrypted. 1108 Note that the length N of the fingerprint for a version 4 key is 1109 20 octets; for a version 5 key N is 32. The key version number 1110 may also be zero, and the fingerprint omitted (that is, the length 1111 N is zero in this case), for an "anonymous recipient" (see 1112 Section 5.1.6). 1114 * A one-octet number giving the public-key algorithm used. 1116 * A series of values comprising the encrypted session key. This is 1117 algorithm-specific and described below. 1119 When creating a V5 PKESK packet, the symmetric encryption algorithm 1120 identifier is not included. Before encrypting, a two-octet checksum 1121 is appended, which is equal to the sum of the preceding session key 1122 octets, modulo 65536. 1124 The resulting octet string (session key and checksum) is encrypted 1125 according to the public-key algorithm used, as described below. 1127 5.1.3. Algorithm Specific Fields for RSA encryption 1129 * Multiprecision integer (MPI) of RSA-encrypted value m**e mod n. 1131 The value "m" in the above formula is the plaintext value described 1132 above, encoded in the PKCS#1 block encoding EME-PKCS1-v1_5 described 1133 in Section 7.2.1 of [RFC8017] (see also Section 14.1). Note that 1134 when an implementation forms several PKESKs with one session key, 1135 forming a message that can be decrypted by several keys, the 1136 implementation MUST make a new PKCS#1 encoding for each key. 1138 5.1.4. Algorithm Specific Fields for Elgamal encryption 1140 * MPI of Elgamal (Diffie-Hellman) value g**k mod p. 1142 * MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. 1144 The value "m" in the above formula is the plaintext value described 1145 above, encoded in the PKCS#1 block encoding EME-PKCS1-v1_5 described 1146 in Section 7.2.1 of [RFC8017] (see also Section 14.1). Note that 1147 when an implementation forms several PKESKs with one session key, 1148 forming a message that can be decrypted by several keys, the 1149 implementation MUST make a new PKCS#1 encoding for each key. 1151 5.1.5. Algorithm-Specific Fields for ECDH encryption 1153 * MPI of an EC point representing an ephemeral public key, in the 1154 point format associated with the curve as specified in 1155 Section 9.2. 1157 * A one-octet size, followed by a symmetric key encoded using the 1158 method described in Section 13.5. 1160 5.1.6. Notes on PKESK 1162 An implementation MAY accept or use a Key ID of all zeros, or a key 1163 version of zero and no key fingerprint, to hide the intended 1164 decryption key. In this case, the receiving implementation would try 1165 all available private keys, checking for a valid decrypted session 1166 key. This format helps reduce traffic analysis of messages. 1168 5.2. Signature Packet (Tag 2) 1170 A Signature packet describes a binding between some public key and 1171 some data. The most common signatures are a signature of a file or a 1172 block of text, and a signature that is a certification of a User ID. 1174 Three versions of Signature packets are defined. Version 3 provides 1175 basic signature information, while versions 4 and 5 provide an 1176 expandable format with subpackets that can specify more information 1177 about the signature. 1179 An implementation MUST generate a version 5 signature when signing 1180 with a version 5 key. An implementation MUST generate a version 4 1181 signature when signing with a version 4 key. Implementations MUST 1182 NOT create version 3 signatures; they MAY accept version 3 1183 signatures. 1185 5.2.1. Signature Types 1187 There are a number of possible meanings for a signature, which are 1188 indicated in a signature type octet in any given signature. Please 1189 note that the vagueness of these meanings is not a flaw, but a 1190 feature of the system. Because OpenPGP places final authority for 1191 validity upon the receiver of a signature, it may be that one 1192 signer's casual act might be more rigorous than some other 1193 authority's positive act. See Section 5.2.4 for detailed information 1194 on how to compute and verify signatures of each type. 1196 These meanings are as follows: 1198 0x00: Signature of a binary document. 1199 This means the signer owns it, created it, or certifies that it 1200 has not been modified. 1202 0x01: Signature of a canonical text document. 1203 This means the signer owns it, created it, or certifies that it 1204 has not been modified. The signature is calculated over the text 1205 data with its line endings converted to . 1207 0x02: Standalone signature. 1208 This signature is a signature of only its own subpacket contents. 1209 It is calculated identically to a signature over a zero-length 1210 binary document. V3 standalone signatures MUST NOT be generated 1211 and MUST be ignored. 1213 0x10: Generic certification of a User ID and Public-Key packet. 1215 The issuer of this certification does not make any particular 1216 assertion as to how well the certifier has checked that the owner 1217 of the key is in fact the person described by the User ID. 1219 0x11: Persona certification of a User ID and Public-Key packet. 1220 The issuer of this certification has not done any verification of 1221 the claim that the owner of this key is the User ID specified. 1223 0x12: Casual certification of a User ID and Public-Key packet. 1224 The issuer of this certification has done some casual verification 1225 of the claim of identity. 1227 0x13: Positive certification of a User ID and Public-Key packet. 1228 The issuer of this certification has done substantial verification 1229 of the claim of identity. 1231 Most OpenPGP implementations make their "key signatures" as 0x10 1232 certifications. Some implementations can issue 0x11-0x13 1233 certifications, but few differentiate between the types. 1235 0x18: Subkey Binding Signature. 1236 This signature is a statement by the top-level signing key that 1237 indicates that it owns the subkey. This signature is calculated 1238 directly on the primary key and subkey, and not on any User ID or 1239 other packets. A signature that binds a signing subkey MUST have 1240 an Embedded Signature subpacket in this binding signature that 1241 contains a 0x19 signature made by the signing subkey on the 1242 primary key and subkey. 1244 0x19: Primary Key Binding Signature. 1245 This signature is a statement by a signing subkey, indicating that 1246 it is owned by the primary key and subkey. This signature is 1247 calculated the same way as a 0x18 signature: directly on the 1248 primary key and subkey, and not on any User ID or other packets. 1250 0x1F: Signature directly on a key. 1251 This signature is calculated directly on a key. It binds the 1252 information in the Signature subpackets to the key, and is 1253 appropriate to be used for subpackets that provide information 1254 about the key, such as the Key Flags subpacket or (deprecated) 1255 Revocation Key. It is also appropriate for statements that non- 1256 self certifiers want to make about the key itself, rather than the 1257 binding between a key and a name. 1259 0x20: Key revocation signature. 1261 The signature is calculated directly on the key being revoked. A 1262 revoked key is not to be used. Only revocation signatures by the 1263 key being revoked, or by a (deprecated) Revocation Key, should be 1264 considered valid revocation signatures. 1266 0x28: Subkey revocation signature. 1267 The signature is calculated directly on the subkey being revoked. 1268 A revoked subkey is not to be used. Only revocation signatures by 1269 the top-level signature key that is bound to this subkey, or by a 1270 (deprecated) Revocation Key, should be considered valid revocation 1271 signatures. 1273 0x30: Certification revocation signature. 1274 This signature revokes an earlier User ID certification signature 1275 (signature class 0x10 through 0x13) or direct-key signature 1276 (0x1F). It should be issued by the same key that issued the 1277 revoked signature or by a (deprecated) Revocation Key. The 1278 signature is computed over the same data as the certificate that 1279 it revokes, and should have a later creation date than that 1280 certificate. 1282 0x40: Timestamp signature. 1283 This signature is only meaningful for the timestamp contained in 1284 it. 1286 0x50: Third-Party Confirmation signature. 1287 This signature is a signature over some other OpenPGP Signature 1288 packet(s). It is analogous to a notary seal on the signed data. 1289 A third-party signature SHOULD include Signature Target 1290 subpacket(s) to give easy identification. Note that we really do 1291 mean SHOULD. There are plausible uses for this (such as a blind 1292 party that only sees the signature, not the key or source 1293 document) that cannot include a target subpacket. 1295 5.2.2. Version 3 Signature Packet Format 1297 The body of a version 3 Signature Packet contains: 1299 * One-octet version number (3). 1301 * One-octet length of following hashed material. MUST be 5. 1303 - One-octet signature type. 1305 - Four-octet creation time. 1307 * Eight-octet Key ID of signer. 1309 * One-octet public-key algorithm. 1311 * One-octet hash algorithm. 1313 * Two-octet field holding left 16 bits of signed hash value. 1315 * One or more multiprecision integers comprising the signature. 1316 This portion is algorithm specific, as described below. 1318 The concatenation of the data to be signed, the signature type, and 1319 creation time from the Signature packet (5 additional octets) is 1320 hashed. The resulting hash value is used in the signature algorithm. 1321 The high 16 bits (first two octets) of the hash are included in the 1322 Signature packet to provide a way to reject some invalid signatures 1323 without performing a signature verification. 1325 Algorithm-Specific Fields for RSA signatures: 1327 * Multiprecision integer (MPI) of RSA signature value m**d mod n. 1329 Algorithm-Specific Fields for DSA signatures: 1331 * MPI of DSA value r. 1333 * MPI of DSA value s. 1335 The signature calculation is based on a hash of the signed data, as 1336 described above. The details of the calculation are different for 1337 DSA signatures than for RSA signatures. 1339 With RSA signatures, the hash value is encoded using PKCS#1 encoding 1340 type EMSA-PKCS1-v1_5 as described in Section 9.2 of [RFC8017]. This 1341 requires inserting the hash value as an octet string into an ASN.1 1342 structure. The object identifier for the type of hash being used is 1343 included in the structure. The hexadecimal representations for the 1344 currently defined hash algorithms are as follows: 1346 +============+======================================================+ 1347 | algorithm | hexadecimal representation | 1348 +============+======================================================+ 1349 | MD5 | 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 | 1350 +------------+------------------------------------------------------+ 1351 | RIPEMD-160 | 0x2B, 0x24, 0x03, 0x02, 0x01 | 1352 +------------+------------------------------------------------------+ 1353 | SHA-1 | 0x2B, 0x0E, 0x03, 0x02, 0x1A | 1354 +------------+------------------------------------------------------+ 1355 | SHA224 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, | 1356 | | 0x02, 0x04 | 1357 +------------+------------------------------------------------------+ 1358 | SHA256 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, | 1359 | | 0x02, 0x01 | 1360 +------------+------------------------------------------------------+ 1361 | SHA384 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, | 1362 | | 0x02, 0x02 | 1363 +------------+------------------------------------------------------+ 1364 | SHA512 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, | 1365 | | 0x02, 0x03 | 1366 +------------+------------------------------------------------------+ 1368 Table 4: Hash hexadecimal representations 1370 The ASN.1 Object Identifiers (OIDs) are as follows: 1372 +============+========================+ 1373 | algorithm | OID | 1374 +============+========================+ 1375 | MD5 | 1.2.840.113549.2.5 | 1376 +------------+------------------------+ 1377 | RIPEMD-160 | 1.3.36.3.2.1 | 1378 +------------+------------------------+ 1379 | SHA-1 | 1.3.14.3.2.26 | 1380 +------------+------------------------+ 1381 | SHA224 | 2.16.840.1.101.3.4.2.4 | 1382 +------------+------------------------+ 1383 | SHA256 | 2.16.840.1.101.3.4.2.1 | 1384 +------------+------------------------+ 1385 | SHA384 | 2.16.840.1.101.3.4.2.2 | 1386 +------------+------------------------+ 1387 | SHA512 | 2.16.840.1.101.3.4.2.3 | 1388 +------------+------------------------+ 1390 Table 5: Hash OIDs 1392 The full hash prefixes for these are as follows: 1394 +============+==========================================+ 1395 | algorithm | full hash prefix | 1396 +============+==========================================+ 1397 | MD5 | 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, | 1398 | | 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, | 1399 | | 0x02, 0x05, 0x05, 0x00, 0x04, 0x10 | 1400 +------------+------------------------------------------+ 1401 | RIPEMD-160 | 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, | 1402 | | 0x2B, 0x24, 0x03, 0x02, 0x01, 0x05, | 1403 | | 0x00, 0x04, 0x14 | 1404 +------------+------------------------------------------+ 1405 | SHA-1 | 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, | 1406 | | 0x2B, 0x0E, 0x03, 0x02, 0x1A, 0x05, | 1407 | | 0x00, 0x04, 0x14 | 1408 +------------+------------------------------------------+ 1409 | SHA224 | 0x30, 0x2D, 0x30, 0x0D, 0x06, 0x09, | 1410 | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | 1411 | | 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C | 1412 +------------+------------------------------------------+ 1413 | SHA256 | 0x30, 0x31, 0x30, 0x0D, 0x06, 0x09, | 1414 | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | 1415 | | 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 | 1416 +------------+------------------------------------------+ 1417 | SHA384 | 0x30, 0x41, 0x30, 0x0D, 0x06, 0x09, | 1418 | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | 1419 | | 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30 | 1420 +------------+------------------------------------------+ 1421 | SHA512 | 0x30, 0x51, 0x30, 0x0D, 0x06, 0x09, | 1422 | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | 1423 | | 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40 | 1424 +------------+------------------------------------------+ 1426 Table 6: Hash hexadecimal prefixes 1428 DSA signatures MUST use hashes that are equal in size to the number 1429 of bits of q, the group generated by the DSA key's generator value. 1431 If the output size of the chosen hash is larger than the number of 1432 bits of q, the hash result is truncated to fit by taking the number 1433 of leftmost bits equal to the number of bits of q. This (possibly 1434 truncated) hash function result is treated as a number and used 1435 directly in the DSA signature algorithm. 1437 5.2.3. Version 4 and 5 Signature Packet Formats 1439 The body of a V4 or V5 Signature packet contains: 1441 * One-octet version number. This is 4 for V4 signatures and 5 for 1442 V5 signatures. 1444 * One-octet signature type. 1446 * One-octet public-key algorithm. 1448 * One-octet hash algorithm. 1450 * A scalar octet count for following hashed subpacket data. For a 1451 V4 signature, this is a two-octet field. For a V5 signature, this 1452 is a four-octet field. Note that this is the length in octets of 1453 all of the hashed subpackets; a pointer incremented by this number 1454 will skip over the hashed subpackets. 1456 * Hashed subpacket data set (zero or more subpackets). 1458 * A scalar octet count for the following unhashed subpacket data. 1459 For a V4 signature, this is a two-octet field. For a V5 1460 signature, this is a four-octet field. Note that this is the 1461 length in octets of all of the unhashed subpackets; a pointer 1462 incremented by this number will skip over the unhashed subpackets. 1464 * Unhashed subpacket data set (zero or more subpackets). 1466 * Two-octet field holding the left 16 bits of the signed hash value. 1468 * Only for V5 signatures, a 16 octet field containing random values 1469 used as salt. 1471 * One or more multiprecision integers comprising the signature. 1472 This portion is algorithm specific: 1474 5.2.3.1. Algorithm-Specific Fields for RSA signatures 1476 * Multiprecision integer (MPI) of RSA signature value m**d mod n. 1478 5.2.3.2. Algorithm-Specific Fields for DSA or ECDSA signatures 1480 * MPI of DSA or ECDSA value r. 1482 * MPI of DSA or ECDSA value s. 1484 A version 3 signature MUST NOT be created and MUST NOT be used with 1485 ECDSA. 1487 5.2.3.3. Algorithm-Specific Fields for EdDSA signatures 1488 * Two MPI-encoded values, whose contents and formatting depend on 1489 the choice of curve used (see Section 9.2.1). 1491 A version 3 signature MUST NOT be created and MUST NOT be used with 1492 EdDSA. 1494 5.2.3.3.1. Algorithm-Specific Fields for Ed25519 signatures 1496 The two MPIs for Ed25519 use octet strings R and S as described in 1497 [RFC8032]. 1499 * MPI of an EC point R, represented as a (non-prefixed) native 1500 (little-endian) octet string up to 32 octets. 1502 * MPI of EdDSA value S, also in (non-prefixed) native little-endian 1503 format with a length up to 32 octets. 1505 5.2.3.3.2. Algorithm-Specific Fields for Ed448 signatures 1507 For Ed448 signatures, the native signature format is used as 1508 described in [RFC8032]. The two MPIs are composed as follows: 1510 * The first MPI has a body of 58 octets: a prefix 0x40 octet, 1511 followed by 57 octets of the native signature. 1513 * The second MPI is set to 0 (this is a placeholder, and is unused). 1514 Note that an MPI with a value of 0 is encoded on the wire as a 1515 pair of zero octets: 00 00. 1517 5.2.3.4. Notes on Signatures 1519 The concatenation of the data being signed and the signature data 1520 from the version number through the hashed subpacket data (inclusive) 1521 is hashed. The resulting hash value is what is signed. The high 16 1522 bits (first two octets) of the hash are included in the Signature 1523 packet to provide a way to reject some invalid signatures without 1524 performing a signature verification. 1526 There are two fields consisting of Signature subpackets. The first 1527 field is hashed with the rest of the signature data, while the second 1528 is unhashed. The second set of subpackets is not cryptographically 1529 protected by the signature and should include only advisory 1530 information. 1532 The differences between a V4 and V5 signature are two-fold: first, a 1533 V5 signature increases the width of the size indicators for the 1534 signed data, making it more capable when signing large keys or 1535 messages. Second, the hash is salted with 128 bit of random data. 1537 The algorithms for converting the hash function result to a signature 1538 are described in Section 5.2.4. 1540 5.2.3.5. Signature Subpacket Specification 1542 A subpacket data set consists of zero or more Signature subpackets. 1543 In Signature packets, the subpacket data set is preceded by a two- 1544 octet (for V4 signatures) or four-octet (for V5 signatures) scalar 1545 count of the length in octets of all the subpackets. A pointer 1546 incremented by this number will skip over the subpacket data set. 1548 Each subpacket consists of a subpacket header and a body. The header 1549 consists of: 1551 * the subpacket length (1, 2, or 5 octets), 1553 * the subpacket type (1 octet), 1555 and is followed by the subpacket-specific data. 1557 The length includes the type octet but not this length. Its format 1558 is similar to the "new" format packet header lengths, but cannot have 1559 Partial Body Lengths. That is: 1561 if the 1st octet < 192, then 1562 lengthOfLength = 1 1563 subpacketLen = 1st_octet 1565 if the 1st octet >= 192 and < 255, then 1566 lengthOfLength = 2 1567 subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 1569 if the 1st octet = 255, then 1570 lengthOfLength = 5 1571 subpacket length = [four-octet scalar starting at 2nd_octet] 1573 The value of the subpacket type octet may be: 1575 +============+==========================================+ 1576 | Type | Description | 1577 +============+==========================================+ 1578 | 0 | Reserved | 1579 +------------+------------------------------------------+ 1580 | 1 | Reserved | 1581 +------------+------------------------------------------+ 1582 | 2 | Signature Creation Time | 1583 +------------+------------------------------------------+ 1584 | 3 | Signature Expiration Time | 1585 +------------+------------------------------------------+ 1586 | 4 | Exportable Certification | 1587 +------------+------------------------------------------+ 1588 | 5 | Trust Signature | 1589 +------------+------------------------------------------+ 1590 | 6 | Regular Expression | 1591 +------------+------------------------------------------+ 1592 | 7 | Revocable | 1593 +------------+------------------------------------------+ 1594 | 8 | Reserved | 1595 +------------+------------------------------------------+ 1596 | 9 | Key Expiration Time | 1597 +------------+------------------------------------------+ 1598 | 10 | Placeholder for backward compatibility | 1599 +------------+------------------------------------------+ 1600 | 11 | Preferred Symmetric Ciphers for v1 SEIPD | 1601 +------------+------------------------------------------+ 1602 | 12 | Revocation Key (deprecated) | 1603 +------------+------------------------------------------+ 1604 | 13 to 15 | Reserved | 1605 +------------+------------------------------------------+ 1606 | 16 | Issuer | 1607 +------------+------------------------------------------+ 1608 | 17 to 19 | Reserved | 1609 +------------+------------------------------------------+ 1610 | 20 | Notation Data | 1611 +------------+------------------------------------------+ 1612 | 21 | Preferred Hash Algorithms | 1613 +------------+------------------------------------------+ 1614 | 22 | Preferred Compression Algorithms | 1615 +------------+------------------------------------------+ 1616 | 23 | Key Server Preferences | 1617 +------------+------------------------------------------+ 1618 | 24 | Preferred Key Server | 1619 +------------+------------------------------------------+ 1620 | 25 | Primary User ID | 1621 +------------+------------------------------------------+ 1622 | 26 | Policy URI | 1623 +------------+------------------------------------------+ 1624 | 27 | Key Flags | 1625 +------------+------------------------------------------+ 1626 | 28 | Signer's User ID | 1627 +------------+------------------------------------------+ 1628 | 29 | Reason for Revocation | 1629 +------------+------------------------------------------+ 1630 | 30 | Features | 1631 +------------+------------------------------------------+ 1632 | 31 | Signature Target | 1633 +------------+------------------------------------------+ 1634 | 32 | Embedded Signature | 1635 +------------+------------------------------------------+ 1636 | 33 | Issuer Fingerprint | 1637 +------------+------------------------------------------+ 1638 | 34 | Reserved | 1639 +------------+------------------------------------------+ 1640 | 35 | Intended Recipient Fingerprint | 1641 +------------+------------------------------------------+ 1642 | 37 | Reserved (Attested Certifications) | 1643 +------------+------------------------------------------+ 1644 | 38 | Reserved (Key Block) | 1645 +------------+------------------------------------------+ 1646 | 39 | Preferred AEAD Ciphersuites | 1647 +------------+------------------------------------------+ 1648 | 100 to 110 | Private or experimental | 1649 +------------+------------------------------------------+ 1651 Table 7: Subpacket type registry 1653 An implementation SHOULD ignore any subpacket of a type that it does 1654 not recognize. 1656 Bit 7 of the subpacket type is the "critical" bit. If set, it 1657 denotes that the subpacket is one that is critical for the evaluator 1658 of the signature to recognize. If a subpacket is encountered that is 1659 marked critical but is unknown to the evaluating software, the 1660 evaluator SHOULD consider the signature to be in error. 1662 An evaluator may "recognize" a subpacket, but not implement it. The 1663 purpose of the critical bit is to allow the signer to tell an 1664 evaluator that it would prefer a new, unknown feature to generate an 1665 error than be ignored. 1667 Implementations SHOULD implement the four preferred algorithm 1668 subpackets (11, 21, 22, and 34), as well as the "Reason for 1669 Revocation" subpacket. Note, however, that if an implementation 1670 chooses not to implement some of the preferences, it is required to 1671 behave in a polite manner to respect the wishes of those users who do 1672 implement these preferences. 1674 5.2.3.6. Signature Subpacket Types 1676 A number of subpackets are currently defined. Some subpackets apply 1677 to the signature itself and some are attributes of the key. 1678 Subpackets that are found on a self-signature are placed on a 1679 certification made by the key itself. Note that a key may have more 1680 than one User ID, and thus may have more than one self-signature, and 1681 differing subpackets. 1683 A subpacket may be found either in the hashed or unhashed subpacket 1684 sections of a signature. If a subpacket is not hashed, then the 1685 information in it cannot be considered definitive because it is not 1686 part of the signature proper. 1688 5.2.3.7. Notes on Self-Signatures 1690 A self-signature is a binding signature made by the key to which the 1691 signature refers. There are three types of self-signatures, the 1692 certification signatures (types 0x10-0x13), the direct-key signature 1693 (type 0x1F), and the subkey binding signature (type 0x18). A 1694 cryptographically-valid self-signature should be accepted from any 1695 primary key, regardless of what Key Flags (Section 5.2.3.26) apply to 1696 the primary key. In particular, a primary key does not need to have 1697 0x01 set in the first octet of Key Flags order to make a valid self- 1698 signature. 1700 For certification self-signatures, each User ID may have a self- 1701 signature, and thus different subpackets in those self-signatures. 1702 For subkey binding signatures, each subkey in fact has a self- 1703 signature. Subpackets that appear in a certification self-signature 1704 apply to the user name, and subpackets that appear in the subkey 1705 self-signature apply to the subkey. Lastly, subpackets on the 1706 direct-key signature apply to the entire key. 1708 Implementing software should interpret a self-signature's preference 1709 subpackets as narrowly as possible. For example, suppose a key has 1710 two user names, Alice and Bob. Suppose that Alice prefers the AEAD 1711 ciphersuite AES-256 with OCB, and Bob prefers Camellia-256 with GCM. 1712 If the software locates this key via Alice's name, then the preferred 1713 AEAD ciphersuite is AES-256 with OCB; if software locates the key via 1714 Bob's name, then the preferred algorithm is Camellia-256 with GCM. 1715 If the key is located by Key ID, the algorithm of the primary User ID 1716 of the key provides the preferred AEAD ciphersuite. 1718 Revoking a self-signature or allowing it to expire has a semantic 1719 meaning that varies with the signature type. Revoking the self- 1720 signature on a User ID effectively retires that user name. The self- 1721 signature is a statement, "My name X is tied to my signing key K" and 1722 is corroborated by other users' certifications. If another user 1723 revokes their certification, they are effectively saying that they no 1724 longer believe that name and that key are tied together. Similarly, 1725 if the users themselves revoke their self-signature, then the users 1726 no longer go by that name, no longer have that email address, etc. 1727 Revoking a binding signature effectively retires that subkey. 1728 Revoking a direct-key signature cancels that signature. Please see 1729 Section 5.2.3.28 for more relevant detail. 1731 Since a self-signature contains important information about the key's 1732 use, an implementation SHOULD allow the user to rewrite the self- 1733 signature, and important information in it, such as preferences and 1734 key expiration. 1736 It is good practice to verify that a self-signature imported into an 1737 implementation doesn't advertise features that the implementation 1738 doesn't support, rewriting the signature as appropriate. 1740 An implementation that encounters multiple self-signatures on the 1741 same object may resolve the ambiguity in any way it sees fit, but it 1742 is RECOMMENDED that priority be given to the most recent self- 1743 signature. 1745 5.2.3.8. Signature Creation Time 1747 (4-octet time field) 1749 The time the signature was made. 1751 MUST be present in the hashed area. 1753 5.2.3.9. Issuer 1755 (8-octet Key ID) 1757 The OpenPGP Key ID of the key issuing the signature. If the version 1758 of that key is greater than 4, this subpacket MUST NOT be included in 1759 the signature. 1761 5.2.3.10. Key Expiration Time 1763 (4-octet time field) 1764 The validity period of the key. This is the number of seconds after 1765 the key creation time that the key expires. For a direct or 1766 certification self-signature, the key creation time is that of the 1767 primary key. For a subkey binding signature, the key creation time 1768 is that of the subkey. If this is not present or has a value of 1769 zero, the key never expires. This is found only on a self-signature. 1771 5.2.3.11. Preferred Symmetric Ciphers for v1 SEIPD 1773 (array of one-octet values) 1775 A series of symmetric cipher algorithm identifiers indicating how the 1776 keyholder prefers to receive version 1 Symmetrically Encrypted 1777 Integrity Protected Data (Section 5.14.1). The subpacket body is an 1778 ordered list of octets with the most preferred listed first. It is 1779 assumed that only algorithms listed are supported by the recipient's 1780 software. Algorithm numbers are in Section 9.3. This is only found 1781 on a self-signature. 1783 When generating a v2 SEIPD packet, this preference list is not 1784 relevant. See Section 5.2.3.12 instead. 1786 5.2.3.12. Preferred AEAD Ciphersuites 1788 (array of pairs of octets indicating Symmetric Cipher and AEAD 1789 algorithms) 1791 A series of paired algorithm identifiers indicating how the keyholder 1792 prefers to receive version 2 Symmetrically Encrypted Integrity 1793 Protected Data (Section 5.14.2). Each pair of octets indicates a 1794 combination of a symmetric cipher and an AEAD mode that the key 1795 holder prefers to use. The symmetric cipher identifier precedes the 1796 AEAD identifier in each pair. The subpacket body is an ordered list 1797 of pairs of octets with the most preferred algorithm combination 1798 listed first. 1800 It is assumed that only the combinations of algorithms listed are 1801 supported by the recipient's software, with the exception of the 1802 mandatory-to-implement combination of AES-128 and OCB. If AES-128 1803 and OCB are not found in the subpacket, it is implicitly listed at 1804 the end. 1806 AEAD algorithm numbers are listed in Section 9.6. Symmetric cipher 1807 algorithm numbers are listed in Section 9.3. 1809 For example, a subpacket with content of these six octets: 1811 09 02 09 03 13 02 1812 Indicates that the keyholder prefers to receive v2 SEIPD using 1813 AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB, 1814 and finally the implicit AES-128 with OCB. 1816 Note that support for version 2 of the Symmetrically Encrypted 1817 Integrity Protected Data packet (Section 5.14.2) in general is 1818 indicated by a Feature Flag (Section 5.2.3.29). 1820 This subpacket is only found on a self-signature. 1822 When generating a v1 SEIPD packet, this preference list is not 1823 relevant. See Section 5.2.3.11 instead. 1825 5.2.3.13. Preferred Hash Algorithms 1827 (array of one-octet values) 1829 Message digest algorithm numbers that indicate which algorithms the 1830 key holder prefers to receive. Like the preferred AEAD ciphersuites, 1831 the list is ordered. Algorithm numbers are in Section 9.5. This is 1832 only found on a self-signature. 1834 5.2.3.14. Preferred Compression Algorithms 1836 (array of one-octet values) 1838 Compression algorithm numbers that indicate which algorithms the key 1839 holder prefers to use. Like the preferred AEAD ciphersuites, the 1840 list is ordered. Algorithm numbers are in Section 9.4. A zero, or 1841 the absence of this subpacket, denotes that uncompressed data is 1842 preferred; the key holder's software might have no compression 1843 software in that implementation. This is only found on a self- 1844 signature. 1846 5.2.3.15. Signature Expiration Time 1848 (4-octet time field) 1850 The validity period of the signature. This is the number of seconds 1851 after the signature creation time that the signature expires. If 1852 this is not present or has a value of zero, it never expires. 1854 5.2.3.16. Exportable Certification 1856 (1 octet of exportability, 0 for not, 1 for exportable) 1857 This subpacket denotes whether a certification signature is 1858 "exportable", to be used by other users than the signature's issuer. 1859 The packet body contains a Boolean flag indicating whether the 1860 signature is exportable. If this packet is not present, the 1861 certification is exportable; it is equivalent to a flag containing a 1862 1. 1864 Non-exportable, or "local", certifications are signatures made by a 1865 user to mark a key as valid within that user's implementation only. 1867 Thus, when an implementation prepares a user's copy of a key for 1868 transport to another user (this is the process of "exporting" the 1869 key), any local certification signatures are deleted from the key. 1871 The receiver of a transported key "imports" it, and likewise trims 1872 any local certifications. In normal operation, there won't be any, 1873 assuming the import is performed on an exported key. However, there 1874 are instances where this can reasonably happen. For example, if an 1875 implementation allows keys to be imported from a key database in 1876 addition to an exported key, then this situation can arise. 1878 Some implementations do not represent the interest of a single user 1879 (for example, a key server). Such implementations always trim local 1880 certifications from any key they handle. 1882 5.2.3.17. Revocable 1884 (1 octet of revocability, 0 for not, 1 for revocable) 1886 Signature's revocability status. The packet body contains a Boolean 1887 flag indicating whether the signature is revocable. Signatures that 1888 are not revocable have any later revocation signatures ignored. They 1889 represent a commitment by the signer that he cannot revoke his 1890 signature for the life of his key. If this packet is not present, 1891 the signature is revocable. 1893 5.2.3.18. Trust Signature 1895 (1 octet "level" (depth), 1 octet of trust amount) 1897 Signer asserts that the key is not only valid but also trustworthy at 1898 the specified level. Level 0 has the same meaning as an ordinary 1899 validity signature. Level 1 means that the signed key is asserted to 1900 be a valid trusted introducer, with the 2nd octet of the body 1901 specifying the degree of trust. Level 2 means that the signed key is 1902 asserted to be trusted to issue level 1 trust signatures; that is, 1903 the signed key is a "meta introducer". Generally, a level n trust 1904 signature asserts that a key is trusted to issue level n-1 trust 1905 signatures. The trust amount is in a range from 0-255, interpreted 1906 such that values less than 120 indicate partial trust and values of 1907 120 or greater indicate complete trust. Implementations SHOULD emit 1908 values of 60 for partial trust and 120 for complete trust. 1910 5.2.3.19. Regular Expression 1912 (null-terminated regular expression) 1914 Used in conjunction with trust Signature packets (of level > 0) to 1915 limit the scope of trust that is extended. Only signatures by the 1916 target key on User IDs that match the regular expression in the body 1917 of this packet have trust extended by the trust Signature subpacket. 1918 The regular expression uses the same syntax as the Henry Spencer's 1919 "almost public domain" regular expression [REGEX] package. A 1920 description of the syntax is found in Section 8. 1922 5.2.3.20. Revocation Key 1924 (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of 1925 V4 fingerprint) 1927 This mechanism is deprecated. Applications MUST NOT generate such a 1928 subpacket. 1930 An application that wants the functionality of delegating revocation 1931 SHOULD instead use an escrowed Revocation Signature. See 1932 Section 15.2 for more details. 1934 The remainder of this section describes how some implementations 1935 attempt to interpret this deprecated subpacket. 1937 This packet was intended to authorize the specified key to issue 1938 revocation signatures for this key. Class octet must have bit 0x80 1939 set. If the bit 0x40 is set, then this means that the revocation 1940 information is sensitive. Other bits are for future expansion to 1941 other kinds of authorizations. This is only found on a direct-key 1942 self-signature (type 0x1f). The use on other types of self- 1943 signatures is unspecified. 1945 If the "sensitive" flag is set, the keyholder feels this subpacket 1946 contains private trust information that describes a real-world 1947 sensitive relationship. If this flag is set, implementations SHOULD 1948 NOT export this signature to other users except in cases where the 1949 data needs to be available: when the signature is being sent to the 1950 designated revoker, or when it is accompanied by a revocation 1951 signature from that revoker. Note that it may be appropriate to 1952 isolate this subpacket within a separate signature so that it is not 1953 combined with other subpackets that need to be exported. 1955 5.2.3.21. Notation Data 1957 (4 octets of flags, 2 octets of name length (M), 2 octets of value 1958 length (N), M octets of name data, N octets of value data) 1960 This subpacket describes a "notation" on the signature that the 1961 issuer wishes to make. The notation has a name and a value, each of 1962 which are strings of octets. There may be more than one notation in 1963 a signature. Notations can be used for any extension the issuer of 1964 the signature cares to make. The "flags" field holds four octets of 1965 flags. 1967 All undefined flags MUST be zero. Defined flags are as follows: 1969 First octet: 1971 +======+================+==========================+ 1972 | flag | shorthand | definition | 1973 +======+================+==========================+ 1974 | 0x80 | human-readable | This note value is text. | 1975 +------+----------------+--------------------------+ 1977 Table 8: Notation flag registry (first octet) 1979 Other octets: none. 1981 Notation names are arbitrary strings encoded in UTF-8. They reside 1982 in two namespaces: The IETF namespace and the user namespace. 1984 The IETF namespace is registered with IANA. These names MUST NOT 1985 contain the "@" character (0x40). This is a tag for the user 1986 namespace. 1988 Names in the user namespace consist of a UTF-8 string tag followed by 1989 "@" followed by a DNS domain name. Note that the tag MUST NOT 1990 contain an "@" character. For example, the "sample" tag used by 1991 Example Corporation could be "sample@example.com". 1993 Names in a user space are owned and controlled by the owners of that 1994 domain. Obviously, it's bad form to create a new name in a DNS space 1995 that you don't own. 1997 Since the user namespace is in the form of an email address, 1998 implementers MAY wish to arrange for that address to reach a person 1999 who can be consulted about the use of the named tag. Note that due 2000 to UTF-8 encoding, not all valid user space name tags are valid email 2001 addresses. 2003 If there is a critical notation, the criticality applies to that 2004 specific notation and not to notations in general. 2006 5.2.3.22. Key Server Preferences 2008 (N octets of flags) 2010 This is a list of one-bit flags that indicate preferences that the 2011 key holder has about how the key is handled on a key server. All 2012 undefined flags MUST be zero. 2014 First octet: 2016 +======+===========+============================================+ 2017 | flag | shorthand | definition | 2018 +======+===========+============================================+ 2019 | 0x80 | No-modify | The key holder requests that this key only | 2020 | | | be modified or updated by the key holder | 2021 | | | or an administrator of the key server. | 2022 +------+-----------+--------------------------------------------+ 2024 Table 9: Key server preferences flag registry (first octet) 2026 This is found only on a self-signature. 2028 5.2.3.23. Preferred Key Server 2030 (String) 2032 This is a URI of a key server that the key holder prefers be used for 2033 updates. Note that keys with multiple User IDs can have a preferred 2034 key server for each User ID. Note also that since this is a URI, the 2035 key server can actually be a copy of the key retrieved by ftp, http, 2036 finger, etc. 2038 5.2.3.24. Primary User ID 2040 (1 octet, Boolean) 2042 This is a flag in a User ID's self-signature that states whether this 2043 User ID is the main User ID for this key. It is reasonable for an 2044 implementation to resolve ambiguities in preferences, etc. by 2045 referring to the primary User ID. If this flag is absent, its value 2046 is zero. If more than one User ID in a key is marked as primary, the 2047 implementation may resolve the ambiguity in any way it sees fit, but 2048 it is RECOMMENDED that priority be given to the User ID with the most 2049 recent self-signature. 2051 When appearing on a self-signature on a User ID packet, this 2052 subpacket applies only to User ID packets. When appearing on a self- 2053 signature on a User Attribute packet, this subpacket applies only to 2054 User Attribute packets. That is to say, there are two different and 2055 independent "primaries" --- one for User IDs, and one for User 2056 Attributes. 2058 5.2.3.25. Policy URI 2060 (String) 2062 This subpacket contains a URI of a document that describes the policy 2063 under which the signature was issued. 2065 5.2.3.26. Key Flags 2067 (N octets of flags) 2069 This subpacket contains a list of binary flags that hold information 2070 about a key. It is a string of octets, and an implementation MUST 2071 NOT assume a fixed size. This is so it can grow over time. If a 2072 list is shorter than an implementation expects, the unstated flags 2073 are considered to be zero. The defined flags are as follows: 2075 First octet: 2077 +======+=====================================================+ 2078 | flag | definition | 2079 +======+=====================================================+ 2080 | 0x01 | This key may be used to make User ID certifications | 2081 | | (signature types 0x10-0x13) or direct key | 2082 | | signatures (signature type 0x1F) over other keys. | 2083 +------+-----------------------------------------------------+ 2084 | 0x02 | This key may be used to sign data. | 2085 +------+-----------------------------------------------------+ 2086 | 0x04 | This key may be used to encrypt communications. | 2087 +------+-----------------------------------------------------+ 2088 | 0x08 | This key may be used to encrypt storage. | 2089 +------+-----------------------------------------------------+ 2090 | 0x10 | The private component of this key may have been | 2091 | | split by a secret-sharing mechanism. | 2092 +------+-----------------------------------------------------+ 2093 | 0x20 | This key may be used for authentication. | 2094 +------+-----------------------------------------------------+ 2095 | 0x80 | The private component of this key may be in the | 2096 | | possession of more than one person. | 2097 +------+-----------------------------------------------------+ 2099 Table 10: Key flags registry (first octet) 2101 Second octet: 2103 +======+==========================+ 2104 | flag | definition | 2105 +======+==========================+ 2106 | 0x04 | Reserved (ADSK). | 2107 +------+--------------------------+ 2108 | 0x08 | Reserved (timestamping). | 2109 +------+--------------------------+ 2111 Table 11: Key flags registry 2112 (second octet) 2114 Usage notes: 2116 The flags in this packet may appear in self-signatures or in 2117 certification signatures. They mean different things depending on 2118 who is making the statement --- for example, a certification 2119 signature that has the "sign data" flag is stating that the 2120 certification is for that use. On the other hand, the 2121 "communications encryption" flag in a self-signature is stating a 2122 preference that a given key be used for communications. Note 2123 however, that it is a thorny issue to determine what is 2124 "communications" and what is "storage". This decision is left wholly 2125 up to the implementation; the authors of this document do not claim 2126 any special wisdom on the issue and realize that accepted opinion may 2127 change. 2129 The "split key" (0x10) and "group key" (0x80) flags are placed on a 2130 self-signature only; they are meaningless on a certification 2131 signature. They SHOULD be placed only on a direct-key signature 2132 (type 0x1F) or a subkey signature (type 0x18), one that refers to the 2133 key the flag applies to. 2135 5.2.3.27. Signer's User ID 2137 (String) 2139 This subpacket allows a keyholder to state which User ID is 2140 responsible for the signing. Many keyholders use a single key for 2141 different purposes, such as business communications as well as 2142 personal communications. This subpacket allows such a keyholder to 2143 state which of their roles is making a signature. 2145 This subpacket is not appropriate to use to refer to a User Attribute 2146 packet. 2148 5.2.3.28. Reason for Revocation 2150 (1 octet of revocation code, N octets of reason string) 2152 This subpacket is used only in key revocation and certification 2153 revocation signatures. It describes the reason why the key or 2154 certificate was revoked. 2156 The first octet contains a machine-readable code that denotes the 2157 reason for the revocation: 2159 +=========+==================================+ 2160 | Code | Reason | 2161 +=========+==================================+ 2162 | 0 | No reason specified (key | 2163 | | revocations or cert revocations) | 2164 +---------+----------------------------------+ 2165 | 1 | Key is superseded (key | 2166 | | revocations) | 2167 +---------+----------------------------------+ 2168 | 2 | Key material has been | 2169 | | compromised (key revocations) | 2170 +---------+----------------------------------+ 2171 | 3 | Key is retired and no longer | 2172 | | used (key revocations) | 2173 +---------+----------------------------------+ 2174 | 32 | User ID information is no longer | 2175 | | valid (cert revocations) | 2176 +---------+----------------------------------+ 2177 | 100-110 | Private Use | 2178 +---------+----------------------------------+ 2180 Table 12: Reasons for revocation 2182 Following the revocation code is a string of octets that gives 2183 information about the Reason for Revocation in human-readable form 2184 (UTF-8). The string may be null (of zero length). The length of the 2185 subpacket is the length of the reason string plus one. An 2186 implementation SHOULD implement this subpacket, include it in all 2187 revocation signatures, and interpret revocations appropriately. 2188 There are important semantic differences between the reasons, and 2189 there are thus important reasons for revoking signatures. 2191 If a key has been revoked because of a compromise, all signatures 2192 created by that key are suspect. However, if it was merely 2193 superseded or retired, old signatures are still valid. If the 2194 revoked signature is the self-signature for certifying a User ID, a 2195 revocation denotes that that user name is no longer in use. Such a 2196 revocation SHOULD include a 0x20 code. 2198 Note that any signature may be revoked, including a certification on 2199 some other person's key. There are many good reasons for revoking a 2200 certification signature, such as the case where the keyholder leaves 2201 the employ of a business with an email address. A revoked 2202 certification is no longer a part of validity calculations. 2204 5.2.3.29. Features 2206 (N octets of flags) 2208 The Features subpacket denotes which advanced OpenPGP features a 2209 user's implementation supports. This is so that as features are 2210 added to OpenPGP that cannot be backwards-compatible, a user can 2211 state that they can use that feature. The flags are single bits that 2212 indicate that a given feature is supported. 2214 This subpacket is similar to a preferences subpacket, and only 2215 appears in a self-signature. 2217 An implementation SHOULD NOT use a feature listed when sending to a 2218 user who does not state that they can use it. 2220 Defined features are as follows: 2222 First octet: 2224 +=========+===================================+===========+ 2225 | Feature | Definition | Reference | 2226 +=========+===================================+===========+ 2227 | 0x01 | Symmetrically Encrypted Integrity | Section | 2228 | | Protected Data packet version 1 | 5.14.1 | 2229 +---------+-----------------------------------+-----------+ 2230 | 0x02 | Reserved | | 2231 +---------+-----------------------------------+-----------+ 2232 | 0x04 | Reserved | | 2233 +---------+-----------------------------------+-----------+ 2234 | 0x08 | Symmetrically Encrypted Integrity | Section | 2235 | | Protected Data packet version 2 | 5.14.2 | 2236 +---------+-----------------------------------+-----------+ 2238 Table 13: Features registry 2240 If an implementation implements any of the defined features, it 2241 SHOULD implement the Features subpacket, too. 2243 An implementation may freely infer features from other suitable 2244 implementation-dependent mechanisms. 2246 See Section 15.1 for details about how to use the Features subpacket 2247 when generating encryption data. 2249 5.2.3.30. Signature Target 2251 (1 octet public-key algorithm, 1 octet hash algorithm, N octets hash) 2253 This subpacket identifies a specific target signature to which a 2254 signature refers. For revocation signatures, this subpacket provides 2255 explicit designation of which signature is being revoked. For a 2256 third-party or timestamp signature, this designates what signature is 2257 signed. All arguments are an identifier of that target signature. 2259 The N octets of hash data MUST be the size of the hash of the 2260 signature. For example, a target signature with a SHA-1 hash MUST 2261 have 20 octets of hash data. 2263 5.2.3.31. Embedded Signature 2265 (1 signature packet body) 2267 This subpacket contains a complete Signature packet body as specified 2268 in Section 5.2. It is useful when one signature needs to refer to, 2269 or be incorporated in, another signature. 2271 5.2.3.32. Issuer Fingerprint 2273 (1 octet key version number, N octets of fingerprint) 2275 The OpenPGP Key fingerprint of the key issuing the signature. This 2276 subpacket SHOULD be included in all signatures. If the version of 2277 the issuing key is 4 and an Issuer subpacket is also included in the 2278 signature, the key ID of the Issuer subpacket MUST match the low 64 2279 bits of the fingerprint. 2281 Note that the length N of the fingerprint for a version 4 key is 20 2282 octets; for a version 5 key N is 32. 2284 5.2.3.33. Intended Recipient Fingerprint 2286 (1 octet key version number, N octets of fingerprint) 2288 The OpenPGP Key fingerprint of the intended recipient primary key. 2289 If one or more subpackets of this type are included in a signature, 2290 it SHOULD be considered valid only in an encrypted context, where the 2291 key it was encrypted to is one of the indicated primary keys, or one 2292 of their subkeys. This can be used to prevent forwarding a signature 2293 outside of its intended, encrypted context. 2295 Note that the length N of the fingerprint for a version 4 key is 20 2296 octets; for a version 5 key N is 32. 2298 5.2.4. Computing Signatures 2300 All signatures are formed by producing a hash over the signature 2301 data, and then using the resulting hash in the signature algorithm. 2303 When a V5 signature is made, the salt is hashed first. 2305 For binary document signatures (type 0x00), the document data is 2306 hashed directly. For text document signatures (type 0x01), the 2307 document is canonicalized by converting line endings to , and 2308 the resulting data is hashed. 2310 When a V4 signature is made over a key, the hash data starts with the 2311 octet 0x99, followed by a two-octet length of the key, and then body 2312 of the key packet. When a V5 signature is made over a key, the hash 2313 data starts with the octet 0x9a, followed by a four-octet length of 2314 the key, and then body of the key packet. 2316 A subkey binding signature (type 0x18) or primary key binding 2317 signature (type 0x19) then hashes the subkey using the same format as 2318 the main key (also using 0x99 or 0x9a as the first octet). Primary 2319 key revocation signatures (type 0x20) hash only the key being 2320 revoked. Subkey revocation signature (type 0x28) hash first the 2321 primary key and then the subkey being revoked. 2323 A certification signature (type 0x10 through 0x13) hashes the User ID 2324 being bound to the key into the hash context after the above data. A 2325 V3 certification hashes the contents of the User ID or attribute 2326 packet packet, without any header. A V4 or V5 certification hashes 2327 the constant 0xB4 for User ID certifications or the constant 0xD1 for 2328 User Attribute certifications, followed by a four-octet number giving 2329 the length of the User ID or User Attribute data, and then the User 2330 ID or User Attribute data. 2332 When a signature is made over a Signature packet (type 0x50, "Third- 2333 Party Confirmation signature"), the hash data starts with the octet 2334 0x88, followed by the four-octet length of the signature, and then 2335 the body of the Signature packet. (Note that this is a Legacy packet 2336 header for a Signature packet with the length-of-length field set to 2337 zero.) The unhashed subpacket data of the Signature packet being 2338 hashed is not included in the hash, and the unhashed subpacket data 2339 length value is set to zero. 2341 Once the data body is hashed, then a trailer is hashed. This trailer 2342 depends on the version of the signature. 2344 * A V3 signature hashes five octets of the packet body, starting 2345 from the signature type field. This data is the signature type, 2346 followed by the four-octet signature time. 2348 * A V4 or V5 signature hashes the packet body starting from its 2349 first field, the version number, through the end of the hashed 2350 subpacket data and a final extra trailer. Thus, the hashed fields 2351 are: 2353 - An octet indicating the signature version (0x04 for V4, 0x05 2354 for V5), 2356 - the signature type, 2358 - the public-key algorithm, 2360 - the hash algorithm, 2362 - the hashed subpacket length, 2364 - the hashed subpacket body, 2366 - A second version octet (0x04 for V4, 0x05 for V5) 2368 - A single octet 0xFF, 2370 - A number representing the length of the hashed data from the 2371 Signature packet stopping right before the second version 2372 octet. For a V4 signature, this is a four-octet big-endian 2373 number, considered to be an unsigned integer modulo 2**32. For 2374 a V5 signature, this is an eight-octet big-endian number, 2375 considered to be an unsigned integer modulo 2**64. 2377 After all this has been hashed in a single hash context, the 2378 resulting hash field is used in the signature algorithm and placed at 2379 the end of the Signature packet. 2381 5.2.4.1. Subpacket Hints 2383 It is certainly possible for a signature to contain conflicting 2384 information in subpackets. For example, a signature may contain 2385 multiple copies of a preference or multiple expiration times. In 2386 most cases, an implementation SHOULD use the last subpacket in the 2387 signature, but MAY use any conflict resolution scheme that makes more 2388 sense. Please note that we are intentionally leaving conflict 2389 resolution to the implementer; most conflicts are simply syntax 2390 errors, and the wishy-washy language here allows a receiver to be 2391 generous in what they accept, while putting pressure on a creator to 2392 be stingy in what they generate. 2394 Some apparent conflicts may actually make sense --- for example, 2395 suppose a keyholder has a V3 key and a V4 key that share the same RSA 2396 key material. Either of these keys can verify a signature created by 2397 the other, and it may be reasonable for a signature to contain an 2398 issuer subpacket for each key, as a way of explicitly tying those 2399 keys to the signature. 2401 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 2403 The Symmetric-Key Encrypted Session Key (SKESK) packet holds the 2404 symmetric-key encryption of a session key used to encrypt a message. 2405 Zero or more Public-Key Encrypted Session Key packets (Section 5.1) 2406 and/or Symmetric-Key Encrypted Session Key packets may precede a an 2407 encryption container (that is, a Symmetrically Encrypted Integrity 2408 Protected Data packet or --- for historic data --- a Symmetrically 2409 Encrypted Data packet) that holds an encrypted message. The message 2410 is encrypted with a session key, and the session key is itself 2411 encrypted and stored in the Encrypted Session Key packet(s). 2413 If the encryption container is preceded by one or more Symmetric-Key 2414 Encrypted Session Key packets, each specifies a passphrase that may 2415 be used to decrypt the message. This allows a message to be 2416 encrypted to a number of public keys, and also to one or more 2417 passphrases. 2419 The body of this packet starts with a one-octet number giving the 2420 version number of the packet type. The currently defined versions 2421 are 4 and 5. The remainder of the packet depends on the version. 2423 The versions differ in how they encrypt the session key with the 2424 password, and in what they encode. The version of the SKESK packet 2425 must align with the version of the SEIPD packet (see 2426 Section 11.3.2.1). 2428 5.3.1. v4 SKESK 2430 A version 4 Symmetric-Key Encrypted Session Key (SKESK) packet 2431 precedes a version 1 Symmetrically Encrypted Integrity Protected Data 2432 (v1 SEIPD, see Section 5.14.1) packet. In historic data, it is 2433 sometimes found preceding a deprecated Symmetrically Encrypted Data 2434 packet (SED, see Section 5.8). A v4 SKESK packet MUST NOT precede a 2435 v2 SEIPD packet (see Section 11.3.2.1). 2437 A version 4 Symmetric-Key Encrypted Session Key packet consists of: 2439 * A one-octet version number with value 4. 2441 * A one-octet number describing the symmetric algorithm used. 2443 * A string-to-key (S2K) specifier. The length of the string-to-key 2444 specifier depends on its type (see Section 3.7.1). 2446 * Optionally, the encrypted session key itself, which is decrypted 2447 with the string-to-key object. 2449 If the encrypted session key is not present (which can be detected on 2450 the basis of packet length and S2K specifier size), then the S2K 2451 algorithm applied to the passphrase produces the session key for 2452 decrypting the message, using the symmetric cipher algorithm from the 2453 Symmetric-Key Encrypted Session Key packet. 2455 If the encrypted session key is present, the result of applying the 2456 S2K algorithm to the passphrase is used to decrypt just that 2457 encrypted session key field, using CFB mode with an IV of all zeros. 2458 The decryption result consists of a one-octet algorithm identifier 2459 that specifies the symmetric-key encryption algorithm used to encrypt 2460 the following encryption container, followed by the session key 2461 octets themselves. 2463 Note: because an all-zero IV is used for this decryption, the S2K 2464 specifier MUST use a salt value, either a Salted S2K, an Iterated- 2465 Salted S2K, or Argon2. The salt value will ensure that the 2466 decryption key is not repeated even if the passphrase is reused. 2468 5.3.2. v5 SKESK 2470 A version 5 Symmetric-Key Encrypted Session Key (SKESK) packet 2471 precedes a version 2 Symmetrically Encrypted Integrity Protected Data 2472 (v2 SEIPD, see Section 5.14.2) packet. A v5 SKESK packet MUST NOT 2473 precede a v1 SEIPD packet or a deprecated Symmetrically Encrypted 2474 Data packet (see Section 11.3.2.1). 2476 A version 5 Symmetric-Key Encrypted Session Key packet consists of: 2478 * A one-octet version number with value 5. 2480 * A one-octet scalar octet count of the following 5 fields. 2482 * A one-octet symmetric cipher algorithm identifier. 2484 * A one-octet AEAD algorithm identifier. 2486 * A one-octet scalar octet count of the following field. 2488 * A string-to-key (S2K) specifier. The length of the string-to-key 2489 specifier depends on its type (see Section 3.7.1). 2491 * A starting initialization vector of size specified by the AEAD 2492 algorithm. 2494 * The encrypted session key itself. 2496 * An authentication tag for the AEAD mode. 2498 HKDF is used with SHA256 as hash algorithm, the key derived from S2K 2499 as Initial Keying Material (IKM), no salt, and the Packet Tag in new 2500 format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), 2501 the packet version, and the cipher-algo and AEAD-mode used to encrypt 2502 the key material, are used as info parameter. Then, the session key 2503 is encrypted using the resulting key, with the AEAD algorithm 2504 specified for version 2 of the Symmetrically Encrypted Integrity 2505 Protected Data packet. Note that no chunks are used and that there 2506 is only one authentication tag. The Packet Tag in OpenPGP format 2507 encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), the 2508 packet version number, the cipher algorithm octet, and the AEAD 2509 algorithm octet are given as additional data. For example, the 2510 additional data used with AES-128 with OCB consists of the octets 2511 0xC3, 0x05, 0x07, and 0x02. 2513 5.4. One-Pass Signature Packets (Tag 4) 2515 The One-Pass Signature packet precedes the signed data and contains 2516 enough information to allow the receiver to begin calculating any 2517 hashes needed to verify the signature. It allows the Signature 2518 packet to be placed at the end of the message, so that the signer can 2519 compute the entire signed message in one pass. 2521 The body of this packet consists of: 2523 * A one-octet version number. The currently defined versions are 3 2524 and 5. 2526 * A one-octet signature type. Signature types are described in 2527 Section 5.2.1. 2529 * A one-octet number describing the hash algorithm used. 2531 * A one-octet number describing the public-key algorithm used. 2533 * Only for V5 packets, a 16 octet field containing random values 2534 used as salt. The value must match the salt field of the 2535 corresponding Signature packet. 2537 * Only for V3 packets, an eight-octet number holding the Key ID of 2538 the signing key. 2540 * Only for V5 packets, a one octet key version number and N octets 2541 of the fingerprint of the signing key. Note that the length N of 2542 the fingerprint for a version 5 key is 32. 2544 * A one-octet number holding a flag showing whether the signature is 2545 nested. A zero value indicates that the next packet is another 2546 One-Pass Signature packet that describes another signature to be 2547 applied to the same message data. 2549 When generating a one-pass signature, the OPS packet version MUST 2550 correspond to the version of the associated signature packet, except 2551 for the historical accident that v4 keys use a v3 one-pass signature 2552 packet (there is no v4 OPS): 2554 +=====================+====================+================+ 2555 | Signing key version | OPS packet version | Signature | 2556 | | | packet version | 2557 +=====================+====================+================+ 2558 | 4 | 3 | 4 | 2559 +---------------------+--------------------+----------------+ 2560 | 5 | 5 | 5 | 2561 +---------------------+--------------------+----------------+ 2563 Table 14: Versions of packets used in a one-pass signature 2565 Note that if a message contains more than one one-pass signature, 2566 then the Signature packets bracket the message; that is, the first 2567 Signature packet after the message corresponds to the last one-pass 2568 packet and the final Signature packet corresponds to the first one- 2569 pass packet. 2571 5.5. Key Material Packet 2573 A key material packet contains all the information about a public or 2574 private key. There are four variants of this packet type, and two 2575 major versions. Consequently, this section is complex. 2577 5.5.1. Key Packet Variants 2579 5.5.1.1. Public-Key Packet (Tag 6) 2581 A Public-Key packet starts a series of packets that forms an OpenPGP 2582 key (sometimes called an OpenPGP certificate). 2584 5.5.1.2. Public-Subkey Packet (Tag 14) 2586 A Public-Subkey packet (tag 14) has exactly the same format as a 2587 Public-Key packet, but denotes a subkey. One or more subkeys may be 2588 associated with a top-level key. By convention, the top-level key 2589 provides signature services, and the subkeys provide encryption 2590 services. 2592 5.5.1.3. Secret-Key Packet (Tag 5) 2594 A Secret-Key packet contains all the information that is found in a 2595 Public-Key packet, including the public-key material, but also 2596 includes the secret-key material after all the public-key fields. 2598 5.5.1.4. Secret-Subkey Packet (Tag 7) 2600 A Secret-Subkey packet (tag 7) is the subkey analog of the Secret Key 2601 packet and has exactly the same format. 2603 5.5.2. Public-Key Packet Formats 2605 There are three versions of key-material packets. 2607 OpenPGP implementations SHOULD create keys with version 5 format. V4 2608 keys are deprecated; an implementation SHOULD NOT generate a V4 key, 2609 but SHOULD accept it. V3 keys are deprecated; an implementation MUST 2610 NOT generate a V3 key, but MAY accept it. V2 keys are deprecated; an 2611 implementation MUST NOT generate a V2 key, but MAY accept it. 2613 A version 3 public key or public-subkey packet contains: 2615 * A one-octet version number (3). 2617 * A four-octet number denoting the time that the key was created. 2619 * A two-octet number denoting the time in days that this key is 2620 valid. If this number is zero, then it does not expire. 2622 * A one-octet number denoting the public-key algorithm of this key. 2624 * A series of multiprecision integers comprising the key material: 2626 - a multiprecision integer (MPI) of RSA public modulus n; 2628 - an MPI of RSA public encryption exponent e. 2630 V3 keys are deprecated. They contain three weaknesses. First, it is 2631 relatively easy to construct a V3 key that has the same Key ID as any 2632 other key because the Key ID is simply the low 64 bits of the public 2633 modulus. Secondly, because the fingerprint of a V3 key hashes the 2634 key material, but not its length, there is an increased opportunity 2635 for fingerprint collisions. Third, there are weaknesses in the MD5 2636 hash algorithm that make developers prefer other algorithms. See 2637 Section 12.2 for a fuller discussion of Key IDs and fingerprints. 2639 V2 keys are identical to the deprecated V3 keys except for the 2640 version number. 2642 The version 4 format is similar to the version 3 format except for 2643 the absence of a validity period. This has been moved to the 2644 Signature packet. In addition, fingerprints of version 4 keys are 2645 calculated differently from version 3 keys, as described in 2646 Section 12. 2648 A version 4 packet contains: 2650 * A one-octet version number (4). 2652 * A four-octet number denoting the time that the key was created. 2654 * A one-octet number denoting the public-key algorithm of this key. 2656 * A series of values comprising the key material. This is 2657 algorithm-specific and described in Section 5.6. 2659 The version 5 format is similar to the version 4 format except for 2660 the addition of a count for the key material. This count helps 2661 parsing secret key packets (which are an extension of the public key 2662 packet format) in the case of an unknown algorithm. In addition, 2663 fingerprints of version 5 keys are calculated differently from 2664 version 4 keys, as described in Section 12. 2666 A version 5 packet contains: 2668 * A one-octet version number (5). 2670 * A four-octet number denoting the time that the key was created. 2672 * A one-octet number denoting the public-key algorithm of this key. 2674 * A four-octet scalar octet count for the following public key 2675 material. 2677 * A series of values comprising the public key material. This is 2678 algorithm-specific and described in Section 5.6. 2680 5.5.3. Secret-Key Packet Formats 2682 The Secret-Key and Secret-Subkey packets contain all the data of the 2683 Public-Key and Public-Subkey packets, with additional algorithm- 2684 specific secret-key data appended, usually in encrypted form. 2686 The packet contains: 2688 * The fields of a Public-Key or Public-Subkey packet, as described 2689 above. 2691 * One octet indicating string-to-key usage conventions. Zero 2692 indicates that the secret-key data is not encrypted. 255, 254, or 2693 253 indicates that a string-to-key specifier is being given. Any 2694 other value is a symmetric-key encryption algorithm identifier. A 2695 version 5 packet MUST NOT use the value 255. 2697 * Only for a version 5 packet, a one-octet scalar octet count of the 2698 next 5 optional fields. 2700 * [Optional] If string-to-key usage octet was 255, 254, or 253, a 2701 one-octet symmetric encryption algorithm. 2703 * [Optional] If string-to-key usage octet was 253, a one-octet AEAD 2704 algorithm. 2706 * [Optional] Only for a version 5 packet, and if string-to-key usage 2707 octet was 255, 254, or 253, an one-octet count of the following 2708 field. 2710 * [Optional] If string-to-key usage octet was 255, 254, or 253, a 2711 string-to-key (S2K) specifier. The length of the string-to-key 2712 specifier depends on its type (see Section 3.7.1). 2714 * [Optional] If string-to-key usage octet was 253 (that is, the 2715 secret data is AEAD-encrypted), an initialization vector (IV) of 2716 size specified by the AEAD algorithm (see Section 5.14.2), which 2717 is used as the nonce for the AEAD algorithm. 2719 * [Optional] If string-to-key usage octet was 255, 254, or a cipher 2720 algorithm identifier (that is, the secret data is CFB-encrypted), 2721 an initialization vector (IV) of the same length as the cipher's 2722 block size. 2724 * Plain or encrypted multiprecision integers comprising the secret 2725 key data. This is algorithm-specific and described in 2726 Section 5.6. If the string-to-key usage octet is 253, then an 2727 AEAD authentication tag is part of that data. If the string-to- 2728 key usage octet is 254, a 20-octet SHA-1 hash of the plaintext of 2729 the algorithm-specific portion is appended to plaintext and 2730 encrypted with it. If the string-to-key usage octet is 255 or 2731 another nonzero value (that is, a symmetric-key encryption 2732 algorithm identifier), a two-octet checksum of the plaintext of 2733 the algorithm-specific portion (sum of all octets, mod 65536) is 2734 appended to plaintext and encrypted with it. (This is deprecated 2735 and SHOULD NOT be used, see below.) 2737 * If the string-to-key usage octet is zero, then a two-octet 2738 checksum of the algorithm-specific portion (sum of all octets, mod 2739 65536). 2741 The details about storing algorithm-specific secrets above are 2742 summarized in Table 2. 2744 Note that the version 5 packet format adds two count values to help 2745 parsing packets with unknown S2K or public key algorithms. 2747 Secret MPI values can be encrypted using a passphrase. If a string- 2748 to-key specifier is given, that describes the algorithm for 2749 converting the passphrase to a key, else a simple MD5 hash of the 2750 passphrase is used. Implementations MUST use a string-to-key 2751 specifier; the simple hash is for backward compatibility and is 2752 deprecated, though implementations MAY continue to use existing 2753 private keys in the old format. The cipher for encrypting the MPIs 2754 is specified in the Secret-Key packet. 2756 Encryption/decryption of the secret data is done using the key 2757 created from the passphrase and the initialization vector from the 2758 packet. If the string-to-key usage octet is not 253, CFB mode is 2759 used. A different mode is used with V3 keys (which are only RSA) 2760 than with other key formats. With V3 keys, the MPI bit count prefix 2761 (that is, the first two octets) is not encrypted. Only the MPI non- 2762 prefix data is encrypted. Furthermore, the CFB state is 2763 resynchronized at the beginning of each new MPI value, so that the 2764 CFB block boundary is aligned with the start of the MPI data. 2766 With V4 and V5 keys, a simpler method is used. All secret MPI values 2767 are encrypted, including the MPI bitcount prefix. 2769 If the string-to-key usage octet is 253, the key encryption key is 2770 derived using HKDF (see [RFC5869]) to provide key separation. HKDF 2771 is used with SHA256 as hash algorithm, the key derived from S2K as 2772 Initial Keying Material (IKM), no salt, and the Packet Tag in OpenPGP 2773 format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), 2774 the packet version, and the cipher-algo and AEAD-mode used to encrypt 2775 the key material, are used as info parameter. Then, the encrypted 2776 MPI values are encrypted as one combined plaintext using one of the 2777 AEAD algorithms specified for version 2 of the Symmetrically 2778 Encrypted Integrity Protected Data packet. Note that no chunks are 2779 used and that there is only one authentication tag. As additional 2780 data, the Packet Tag in OpenPGP format encoding (bits 7 and 6 set, 2781 bits 5-0 carry the packet tag), followed by the public key packet 2782 fields, starting with the packet version number, are passed to the 2783 AEAD algorithm. For example, the additional data used with a Secret- 2784 Key Packet of version 4 consists of the octets 0xC5, 0x04, followed 2785 by four octets of creation time, one octet denoting the public-key 2786 algorithm, and the algorithm-specific public-key parameters. For a 2787 Secret-Subkey Packet, the first octet would be 0xC7. For a version 5 2788 key packet, the second octet would be 0x05, and the four-octet octet 2789 count of the public key material would be included as well (see 2790 Section 5.5.2). 2792 The two-octet checksum that follows the algorithm-specific portion is 2793 the algebraic sum, mod 65536, of the plaintext of all the algorithm- 2794 specific octets (including MPI prefix and data). With V3 keys, the 2795 checksum is stored in the clear. With V4 keys, the checksum is 2796 encrypted like the algorithm-specific data. This value is used to 2797 check that the passphrase was correct. However, this checksum is 2798 deprecated; an implementation SHOULD NOT use it, but should rather 2799 use the SHA-1 hash denoted with a usage octet of 254. The reason for 2800 this is that there are some attacks that involve undetectably 2801 modifying the secret key. If the string-to-key usage octet is 253 no 2802 checksum or SHA-1 hash is used but the authentication tag of the AEAD 2803 algorithm follows. 2805 When decrypting the secret key material using any of these schemes 2806 (that is, where the usage octet is non-zero), the resulting cleartext 2807 octet stream MUST be well-formed. In particular, an implementation 2808 MUST NOT interpret octets beyond the unwrapped cleartext octet stream 2809 as part of any of the unwrapped MPI objects. Furthermore, an 2810 implementation MUST reject as unusable any secret key material whose 2811 cleartext length does not align with the lengths of the unwrapped MPI 2812 objects. 2814 5.6. Algorithm-specific Parts of Keys 2816 The public and secret key format specifies algorithm-specific parts 2817 of a key. The following sections describe them in detail. 2819 5.6.1. Algorithm-Specific Part for RSA Keys 2821 The public key is this series of multiprecision integers: 2823 * MPI of RSA public modulus n; 2825 * MPI of RSA public encryption exponent e. 2827 The secret key is this series of multiprecision integers: 2829 * MPI of RSA secret exponent d; 2831 * MPI of RSA secret prime value p; 2833 * MPI of RSA secret prime value q (p < q); 2835 * MPI of u, the multiplicative inverse of p, mod q. 2837 5.6.2. Algorithm-Specific Part for DSA Keys 2839 The public key is this series of multiprecision integers: 2841 * MPI of DSA prime p; 2843 * MPI of DSA group order q (q is a prime divisor of p-1); 2845 * MPI of DSA group generator g; 2847 * MPI of DSA public-key value y (= g**x mod p where x is secret). 2849 The secret key is this single multiprecision integer: 2851 * MPI of DSA secret exponent x. 2853 5.6.3. Algorithm-Specific Part for Elgamal Keys 2855 The public key is this series of multiprecision integers: 2857 * MPI of Elgamal prime p; 2859 * MPI of Elgamal group generator g; 2861 * MPI of Elgamal public key value y (= g**x mod p where x is 2862 secret). 2864 The secret key is this single multiprecision integer: 2866 * MPI of Elgamal secret exponent x. 2868 5.6.4. Algorithm-Specific Part for ECDSA Keys 2870 The public key is this series of values: 2872 * A variable-length field containing a curve OID, which is formatted 2873 as follows: 2875 - A one-octet size of the following field; values 0 and 0xFF are 2876 reserved for future extensions, 2878 - The octets representing a curve OID (defined in Section 9.2); 2880 * MPI of an EC point representing a public key. 2882 The secret key is this single multiprecision integer: 2884 * MPI of an integer representing the secret key, which is a scalar 2885 of the public EC point. 2887 5.6.5. Algorithm-Specific Part for EdDSA Keys 2889 The public key is this series of values: 2891 * A variable-length field containing a curve OID, formatted as 2892 follows: 2894 - A one-octet size of the following field; values 0 and 0xFF are 2895 reserved for future extensions, 2897 - The octets representing a curve OID, defined in Section 9.2; 2899 * An MPI of an EC point representing a public key Q in prefixed 2900 native form (see Section 13.2.2). 2902 The secret key is this single multiprecision integer: 2904 * An MPI-encoded octet string representing the native form of the 2905 secret key, in the curve-specific format described in 2906 Section 9.2.1. 2908 See [RFC8032] for more details about the native octet strings. 2910 5.6.6. Algorithm-Specific Part for ECDH Keys 2912 The public key is this series of values: 2914 * A variable-length field containing a curve OID, which is formatted 2915 as follows: 2917 - A one-octet size of the following field; values 0 and 0xFF are 2918 reserved for future extensions, 2920 - Octets representing a curve OID, defined in Section 9.2; 2922 * MPI of an EC point representing a public key, in the point format 2923 associated with the curve as specified in Section 9.2.1 2925 * A variable-length field containing KDF parameters, which is 2926 formatted as follows: 2928 - A one-octet size of the following fields; values 0 and 0xFF are 2929 reserved for future extensions, 2931 - A one-octet value 1, reserved for future extensions, 2933 - A one-octet hash function ID used with a KDF, 2935 - A one-octet algorithm ID for the symmetric algorithm used to 2936 wrap the symmetric key used for the message encryption; see 2937 Section 13.5 for details. 2939 Observe that an ECDH public key is composed of the same sequence of 2940 fields that define an ECDSA key plus the KDF parameters field. 2942 The secret key is this single multiprecision integer: 2944 * An MPI representing the secret key, in the curve-specific format 2945 described in Section 9.2.1. 2947 5.6.6.1. ECDH Secret Key Material 2949 When curve P-256, P-384, or P-521 are used in ECDH, their secret keys 2950 are represented as a simple integer in standard MPI form. Other 2951 curves are presented on the wire differently (though still as a 2952 single MPI), as described below and in Section 9.2.1. 2954 5.6.6.1.1. Curve25519 ECDH Secret Key Material 2956 A Curve25519 secret key is stored as a standard integer in big-endian 2957 MPI form. Note that this form is in reverse octet order from the 2958 little-endian "native" form found in [RFC7748]. 2960 Note also that the integer for a Curve25519 secret key for OpenPGP 2961 MUST have the appropriate form: that is, it MUST be divisible by 8, 2962 MUST be at least 2**254, and MUST be less than 2**255. The length of 2963 this MPI in bits is by definition always 255, so the two leading 2964 octets of the MPI will always be 00 ff and reversing the following 32 2965 octets from the wire will produce the "native" form. 2967 When generating a new Curve25519 secret key from 32 fully-random 2968 octets, the following pseudocode produces the MPI wire format (note 2969 the similarity to decodeScalar25519 from [RFC7748]): 2971 def curve25519_MPI_from_random(octet_list): 2972 octet_list[0] &= 248 2973 octet_list[31] &= 127 2974 octet_list[31] |= 64 2975 mpi_header = [ 0x00, 0xff ] 2976 return mpi_header || reversed(octet_list) 2978 5.6.6.1.2. X448 ECDH Secret Key Material 2980 An X448 secret key is contained within its MPI as a prefixed octet 2981 string (see Section 13.3.2), which encapsulates the native secret key 2982 format found in [RFC7748]. The full wire format (as an MPI) will 2983 thus be the three octets 01 c7 40 followed by the full 56 octet 2984 native secret key. 2986 When generating a new X448 secret key from 56 fully-random octets, 2987 the following pseudocode produces the MPI wire format: 2989 def X448_MPI_from_random(octet_list): 2990 prefixed_header = [ 0x01, 0xc7, 0x40 ] 2991 return prefixed_header || octet_list 2993 5.7. Compressed Data Packet (Tag 8) 2995 The Compressed Data packet contains compressed data. Typically, this 2996 packet is found as the contents of an encrypted packet, or following 2997 a Signature or One-Pass Signature packet, and contains a literal data 2998 packet. 3000 The body of this packet consists of: 3002 * One octet that gives the algorithm used to compress the packet. 3004 * Compressed data, which makes up the remainder of the packet. 3006 A Compressed Data Packet's body contains an block that compresses 3007 some set of packets. See Section 11 for details on how messages are 3008 formed. 3010 ZIP-compressed packets are compressed with raw [RFC1951] DEFLATE 3011 blocks. 3013 ZLIB-compressed packets are compressed with [RFC1950] ZLIB-style 3014 blocks. 3016 BZip2-compressed packets are compressed using the BZip2 [BZ2] 3017 algorithm. 3019 An implementation that generates a Compressed Data packet MUST use 3020 the non-legacy format for packet framing (see Section 4.2.1). It 3021 MUST NOT generate a Compressed Data packet with Legacy format 3022 (Section 4.2.2) 3024 An implementation that deals with either historic data or data 3025 generated by legacy implementations MAY interpret Compressed Data 3026 packets that use the Legacy format for packet framing. 3028 5.8. Symmetrically Encrypted Data Packet (Tag 9) 3030 The Symmetrically Encrypted Data packet contains data encrypted with 3031 a symmetric-key algorithm. When it has been decrypted, it contains 3032 other packets (usually a literal data packet or compressed data 3033 packet, but in theory other Symmetrically Encrypted Data packets or 3034 sequences of packets that form whole OpenPGP messages). 3036 This packet is obsolete. An implementation MUST NOT create this 3037 packet. An implementation MAY process such a packet but it MUST 3038 return a clear diagnostic that a non-integrity protected packet has 3039 been processed. The implementation SHOULD also return an error in 3040 this case and stop processing. 3042 This packet format is impossible to handle safely in general because 3043 the ciphertext it provides is malleable. See Section 15.1 about 3044 selecting a better OpenPGP encryption container that does not have 3045 this flaw. 3047 The body of this packet consists of: 3049 * Encrypted data, the output of the selected symmetric-key cipher 3050 operating in OpenPGP's variant of Cipher Feedback (CFB) mode. 3052 The symmetric cipher used may be specified in a Public-Key or 3053 Symmetric-Key Encrypted Session Key packet that precedes the 3054 Symmetrically Encrypted Data packet. In that case, the cipher 3055 algorithm octet is prefixed to the session key before it is 3056 encrypted. If no packets of these types precede the encrypted data, 3057 the IDEA algorithm is used with the session key calculated as the MD5 3058 hash of the passphrase, though this use is deprecated. 3060 The data is encrypted in CFB mode, with a CFB shift size equal to the 3061 cipher's block size. The Initial Vector (IV) is specified as all 3062 zeros. Instead of using an IV, OpenPGP prefixes a string of length 3063 equal to the block size of the cipher plus two to the data before it 3064 is encrypted. The first block-size octets (for example, 8 octets for 3065 a 64-bit block length) are random, and the following two octets are 3066 copies of the last two octets of the IV. For example, in an 8-octet 3067 block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of 3068 octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15 3069 and octet 18 is a repeat of octet 16. As a pedantic clarification, 3070 in both these examples, we consider the first octet to be numbered 1. 3072 After encrypting the first block-size-plus-two octets, the CFB state 3073 is resynchronized. The last block-size octets of ciphertext are 3074 passed through the cipher and the block boundary is reset. 3076 The repetition of 16 bits in the random data prefixed to the message 3077 allows the receiver to immediately check whether the session key is 3078 incorrect. See Section 15 for hints on the proper use of this "quick 3079 check". 3081 5.9. Marker Packet (Tag 10) 3083 The body of this packet consists of: 3085 * The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). 3087 Such a packet MUST be ignored when received. 3089 5.10. Literal Data Packet (Tag 11) 3091 A Literal Data packet contains the body of a message; data that is 3092 not to be further interpreted. 3094 The body of this packet consists of: 3096 * A one-octet field that describes how the data is formatted. 3098 If it is a b (0x62), then the Literal packet contains binary data. 3099 If it is a u (0x75), then the Literal packet contains UTF- 3100 8-encoded text data, and thus may need line ends converted to 3101 local form, or other text mode changes. 3103 Older versions of OpenPGP used t (0x74) to indicate textual data, 3104 but did not specify the character encoding. Implementations 3105 SHOULD NOT emit this value. An implementation that receives a 3106 literal data packet with this value in the format field SHOULD 3107 interpret the packet data as UTF-8 encoded text, unless reliable 3108 (not attacker-controlled) context indicates a specific alternate 3109 text encoding. This mode is deprecated due to its ambiguity. 3111 Early versions of PGP also defined a value of l as a 'local' mode 3112 for machine-local conversions. [RFC1991] incorrectly stated this 3113 local mode flag as 1 (ASCII numeral one). Both of these local 3114 modes are deprecated. 3116 * File name as a string (one-octet length, followed by a file name). 3117 This may be a zero-length string. Commonly, if the source of the 3118 encrypted data is a file, this will be the name of the encrypted 3119 file. An implementation MAY consider the file name in the Literal 3120 packet to be a more authoritative name than the actual file name. 3122 * A four-octet number that indicates a date associated with the 3123 literal data. Commonly, the date might be the modification date 3124 of a file, or the time the packet was created, or a zero that 3125 indicates no specific time. 3127 * The remainder of the packet is literal data. 3129 Text data is stored with text endings (that is, network- 3130 normal line endings). These should be converted to native line 3131 endings by the receiving software. 3133 Note that OpenPGP signatures do not include the formatting octet, the 3134 file name, and the date field of the literal packet in a signature 3135 hash and thus those fields are not protected against tampering in a 3136 signed document. A receiving implementation MUST NOT treat those 3137 fields as though they were cryptographically secured by the 3138 surrounding signature either when representing them to the user or 3139 acting on them. 3141 Due to their inherent malleability, an implementation that generates 3142 a literal data packet SHOULD avoid storing any significant data in 3143 these fields. If the implementation is certain that the data is 3144 textual and is encoded with UTF-8 (for example, if it will follow 3145 this literal data packet with a signature packet of type 0x01 (see 3146 Section 5.2.1), it MAY set the format octet to u. Otherwise, it 3147 SHOULD set the format octet to b. It SHOULD set the filename to the 3148 empty string (encoded as a single zero octet), and the timestamp to 3149 zero (encoded as four zero octets). 3151 An application that wishes to include such filesystem metadata within 3152 a signature is advised to sign an encapsulated archive (for example, 3153 [PAX]). 3155 An implementation that generates a Literal Data packet MUST use the 3156 OpenPGP format for packet framing (see Section 4.2.1). It MUST NOT 3157 generate a Literal Data packet with Legacy format (Section 4.2.2) 3159 An implementation that deals with either historic data or data 3160 generated by legacy implementations MAY interpret Literal Data 3161 packets that use the Legacy format for packet framing. 3163 5.10.1. Special Filename _CONSOLE (Deprecated) 3165 The Literal Data packet's filename field has a historical special 3166 case for the special name _CONSOLE. When the filename field is 3167 _CONSOLE, the message is considered to be "for your eyes only". This 3168 advises that the message data is unusually sensitive, and the 3169 receiving program should process it more carefully, perhaps avoiding 3170 storing the received data to disk, for example. 3172 An OpenPGP deployment that generates literal data packets MUST NOT 3173 depend on this indicator being honored in any particular way. It 3174 cannot be enforced, and the field itself is not covered by any 3175 cryptographic signature. 3177 It is NOT RECOMMENDED to use this special filename in a newly- 3178 generated literal data packet. 3180 5.11. Trust Packet (Tag 12) 3182 The Trust packet is used only within keyrings and is not normally 3183 exported. Trust packets contain data that record the user's 3184 specifications of which key holders are trustworthy introducers, 3185 along with other information that implementing software uses for 3186 trust information. The format of Trust packets is defined by a given 3187 implementation. 3189 Trust packets SHOULD NOT be emitted to output streams that are 3190 transferred to other users, and they SHOULD be ignored on any input 3191 other than local keyring files. 3193 5.12. User ID Packet (Tag 13) 3195 A User ID packet consists of UTF-8 text that is intended to represent 3196 the name and email address of the key holder. By convention, it 3197 includes an [RFC2822] mail name-addr, but there are no restrictions 3198 on its content. The packet length in the header specifies the length 3199 of the User ID. 3201 5.13. User Attribute Packet (Tag 17) 3203 The User Attribute packet is a variation of the User ID packet. It 3204 is capable of storing more types of data than the User ID packet, 3205 which is limited to text. Like the User ID packet, a User Attribute 3206 packet may be certified by the key owner ("self-signed") or any other 3207 key owner who cares to certify it. Except as noted, a User Attribute 3208 packet may be used anywhere that a User ID packet may be used. 3210 While User Attribute packets are not a required part of the OpenPGP 3211 standard, implementations SHOULD provide at least enough 3212 compatibility to properly handle a certification signature on the 3213 User Attribute packet. A simple way to do this is by treating the 3214 User Attribute packet as a User ID packet with opaque contents, but 3215 an implementation may use any method desired. 3217 The User Attribute packet is made up of one or more attribute 3218 subpackets. Each subpacket consists of a subpacket header and a 3219 body. The header consists of: 3221 * the subpacket length (1, 2, or 5 octets) 3223 * the subpacket type (1 octet) 3225 and is followed by the subpacket specific data. 3227 The following table lists the currently known subpackets: 3229 +=========+===========================+ 3230 | Type | Attribute Subpacket | 3231 +=========+===========================+ 3232 | 1 | Image Attribute Subpacket | 3233 +---------+---------------------------+ 3234 | 100-110 | Private/Experimental Use | 3235 +---------+---------------------------+ 3237 Table 15: User Attribute type registry 3239 An implementation SHOULD ignore any subpacket of a type that it does 3240 not recognize. 3242 5.13.1. The Image Attribute Subpacket 3244 The Image Attribute subpacket is used to encode an image, presumably 3245 (but not required to be) that of the key owner. 3247 The Image Attribute subpacket begins with an image header. The first 3248 two octets of the image header contain the length of the image 3249 header. Note that unlike other multi-octet numerical values in this 3250 document, due to a historical accident this value is encoded as a 3251 little-endian number. The image header length is followed by a 3252 single octet for the image header version. The only currently 3253 defined version of the image header is 1, which is a 16-octet image 3254 header. The first three octets of a version 1 image header are thus 3255 0x10, 0x00, 0x01. 3257 The fourth octet of a version 1 image header designates the encoding 3258 format of the image. The only currently defined encoding format is 3259 the value 1 to indicate JPEG. Image format types 100 through 110 are 3260 reserved for private or experimental use. The rest of the version 1 3261 image header is made up of 12 reserved octets, all of which MUST be 3262 set to 0. 3264 The rest of the image subpacket contains the image itself. As the 3265 only currently defined image type is JPEG, the image is encoded in 3266 the JPEG File Interchange Format (JFIF), a standard file format for 3267 JPEG images [JFIF]. 3269 An implementation MAY try to determine the type of an image by 3270 examination of the image data if it is unable to handle a particular 3271 version of the image header or if a specified encoding format value 3272 is not recognized. 3274 5.14. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 3276 This packet contains integrity protected and encrypted data. When it 3277 has been decrypted, it will contain other packets forming an OpenPGP 3278 Message (see Section 11.3). 3280 The first octet of this packet is always used to indicate the version 3281 number, but different versions contain differently-structured 3282 ciphertext. Version 1 of this packet contains data encrypted with a 3283 symmetric-key algorithm and protected against modification by the 3284 SHA-1 hash algorithm. This is a legacy OpenPGP mechanism that offers 3285 some protections against ciphertext malleability. 3287 Version 2 of this packet contains data encrypted with an 3288 authenticated encryption and additional data (AEAD) construction. 3289 This offers a more cryptographically rigorous defense against 3290 ciphertext malleability, but may not be as widely supported yet. See 3291 Section 15.1 for more details on choosing between these formats. 3293 5.14.1. Version 1 Sym. Encrypted Integrity Protected Data Packet Format 3295 A version 1 Symmetrically Encrypted Integrity Protected Data packet 3296 consists of: 3298 * A one-octet version number with value 1. 3300 * Encrypted data, the output of the selected symmetric-key cipher 3301 operating in Cipher Feedback mode with shift amount equal to the 3302 block size of the cipher (CFB-n where n is the block size). 3304 The symmetric cipher used MUST be specified in a Public-Key or 3305 Symmetric-Key Encrypted Session Key packet that precedes the 3306 Symmetrically Encrypted Integrity Protected Data packet. In either 3307 case, the cipher algorithm octet is prefixed to the session key 3308 before it is encrypted. 3310 The data is encrypted in CFB mode, with a CFB shift size equal to the 3311 cipher's block size. The Initial Vector (IV) is specified as all 3312 zeros. Instead of using an IV, OpenPGP prefixes an octet string to 3313 the data before it is encrypted. The length of the octet string 3314 equals the block size of the cipher in octets, plus two. The first 3315 octets in the group, of length equal to the block size of the cipher, 3316 are random; the last two octets are each copies of their 2nd 3317 preceding octet. For example, with a cipher whose block size is 128 3318 bits or 16 octets, the prefix data will contain 16 random octets, 3319 then two more octets, which are copies of the 15th and 16th octets, 3320 respectively. Unlike the Symmetrically Encrypted Data Packet, no 3321 special CFB resynchronization is done after encrypting this prefix 3322 data. See Section 14.9 for more details. 3324 The repetition of 16 bits in the random data prefixed to the message 3325 allows the receiver to immediately check whether the session key is 3326 incorrect. 3328 Two constant octets with the values 0xD3 and 0x14 are appended to the 3329 plaintext. Then, the plaintext of the data to be encrypted is passed 3330 through the SHA-1 hash function. The input to the hash function 3331 includes the prefix data described above; it includes all of the 3332 plaintext, including the trailing constant octets 0xD3, 0x14. The 20 3333 octets of the SHA-1 hash are then appended to the plaintext (after 3334 the constant octets 0xD3, 0x14) and encrypted along with the 3335 plaintext using the same CFB context. This trailing checksum is 3336 known as the Modification Detection Code (MDC). 3338 During decryption, the plaintext data should be hashed with SHA-1, 3339 including the prefix data as well as the trailing constant octets 3340 0xD3, 0x14, but excluding the last 20 octets containing the SHA-1 3341 hash. The computed SHA-1 hash is then compared with the last 20 3342 octets of plaintext. A mismatch of the hash indicates that the 3343 message has been modified and MUST be treated as a security problem. 3344 Any failure SHOULD be reported to the user. 3346 NON-NORMATIVE EXPLANATION 3348 The Modification Detection Code (MDC) system, as the integrity 3349 protection mechanism of version 1 of the Symmetrically Encrypted 3350 Integrity Protected Data packet is called, was created to provide 3351 an integrity mechanism that is less strong than a signature, yet 3352 stronger than bare CFB encryption. 3354 It is a limitation of CFB encryption that damage to the ciphertext 3355 will corrupt the affected cipher blocks and the block following. 3356 Additionally, if data is removed from the end of a CFB-encrypted 3357 block, that removal is undetectable. (Note also that CBC mode has 3358 a similar limitation, but data removed from the front of the block 3359 is undetectable.) 3361 The obvious way to protect or authenticate an encrypted block is 3362 to digitally sign it. However, many people do not wish to 3363 habitually sign data, for a large number of reasons beyond the 3364 scope of this document. Suffice it to say that many people 3365 consider properties such as deniability to be as valuable as 3366 integrity. 3368 OpenPGP addresses this desire to have more security than raw 3369 encryption and yet preserve deniability with the MDC system. An 3370 MDC is intentionally not a MAC. Its name was not selected by 3371 accident. It is analogous to a checksum. 3373 Despite the fact that it is a relatively modest system, it has 3374 proved itself in the real world. It is an effective defense to 3375 several attacks that have surfaced since it has been created. It 3376 has met its modest goals admirably. 3378 Consequently, because it is a modest security system, it has 3379 modest requirements on the hash function(s) it employs. It does 3380 not rely on a hash function being collision-free, it relies on a 3381 hash function being one-way. If a forger, Frank, wishes to send 3382 Alice a (digitally) unsigned message that says, "I've always 3383 secretly loved you, signed Bob", it is far easier for him to 3384 construct a new message than it is to modify anything intercepted 3385 from Bob. (Note also that if Bob wishes to communicate secretly 3386 with Alice, but without authentication or identification and with 3387 a threat model that includes forgers, he has a problem that 3388 transcends mere cryptography.) 3390 Note also that unlike nearly every other OpenPGP subsystem, there 3391 are no parameters in the MDC system. It hard-defines SHA-1 as its 3392 hash function. This is not an accident. It is an intentional 3393 choice to avoid downgrade and cross-grade attacks while making a 3394 simple, fast system. (A downgrade attack would be an attack that 3395 replaced SHA2-256 with SHA-1, for example. A cross-grade attack 3396 would replace SHA-1 with another 160-bit hash, such as RIPE- 3397 MD/160, for example.) 3399 However, no update will be needed because the MDC has been 3400 replaced by the AEAD encryption described in this document. 3402 5.14.2. Version 2 Sym. Encrypted Integrity Protected Data Packet Format 3404 A version 2 Symmetrically Encrypted Integrity Protected Data packet 3405 consists of: 3407 * A one-octet version number with value 2. 3409 * A one-octet cipher algorithm. 3411 * A one-octet AEAD algorithm. 3413 * A one-octet chunk size. 3415 * Thirty-two octets of salt. The salt is used to derive the message 3416 key and must be unique. 3418 * Encrypted data, the output of the selected symmetric-key cipher 3419 operating in the given AEAD mode. 3421 * A final, summary authentication tag for the AEAD mode. 3423 The decrypted session key and the salt are used to derive an M-bit 3424 message key and N-64 bits used as initialization vector, where M is 3425 the key size of the symmetric algorithm and N is the nonce size of 3426 the AEAD algorithm. M + N - 64 bits are derived using HKDF (see 3427 [RFC5869]). The left-most M bits are used as symmetric algorithm 3428 key, the remaining N - 64 bits are used as initialization vector. 3429 HKDF is used with SHA256 as hash algorithm, the session key as 3430 Initial Keying Material (IKM), the salt as salt, and the Packet Tag 3431 in OpenPGP format encoding (bits 7 and 6 set, bits 5-0 carry the 3432 packet tag), version number, cipher algorithm octet, AEAD algorithm 3433 octet, and chunk size octet as info parameter. 3435 The KDF mechanism provides key separation between cipher and AEAD 3436 algorithms. Furthermore, an implementation can securely reply to a 3437 message even if a recipients certificate is unknown by reusing the 3438 encrypted session key packets and replying with a different salt 3439 yielding a new, unique message key. 3441 A v2 SEIPD packet consists of one or more chunks of data. The 3442 plaintext of each chunk is of a size specified using the chunk size 3443 octet using the method specified below. 3445 The encrypted data consists of the encryption of each chunk of 3446 plaintext, followed immediately by the relevant authentication tag. 3447 If the last chunk of plaintext is smaller than the chunk size, the 3448 ciphertext for that data may be shorter; it is nevertheless followed 3449 by a full authentication tag. 3451 For each chunk, the AEAD construction is given the Packet Tag in 3452 OpenPGP format encoding (bits 7 and 6 set, bits 5-0 carry the packet 3453 tag), version number, cipher algorithm octet, AEAD algorithm octet, 3454 and chunk size octet as additional data. For example, the additional 3455 data of the first chunk using EAX and AES-128 with a chunk size of 3456 2**16 octets consists of the octets 0xD2, 0x02, 0x07, 0x01, and 0x10. 3458 After the final chunk, the AEAD algorithm is used to produce a final 3459 authentication tag encrypting the empty string. This AEAD instance 3460 is given the additional data specified above, plus an eight-octet, 3461 big-endian value specifying the total number of plaintext octets 3462 encrypted. This allows detection of a truncated ciphertext. 3464 The chunk size octet specifies the size of chunks using the following 3465 formula (in C), where c is the chunk size octet: 3467 chunk_size = ((uint64_t)1 << (c + 6)) 3469 An implementation MUST accept chunk size octets with values from 0 to 3470 16. An implementation MUST NOT create data with a chunk size octet 3471 value larger than 16 (4 MiB chunks). 3473 The nonce for AEAD mode consists of two parts. Let N be the size of 3474 the nonce. The left-most N - 64 bits are the initialization vector 3475 derived using HKDF. The right-most 64 bits are the chunk index as 3476 big-endian value. The index of the first chunk is zero. 3478 5.14.3. EAX Mode 3480 The EAX AEAD Algorithm used in this document is defined in [EAX]. 3482 The EAX algorithm can only use block ciphers with 16-octet blocks. 3483 The nonce is 16 octets long. EAX authentication tags are 16 octets 3484 long. 3486 5.14.4. OCB Mode 3488 The OCB AEAD Algorithm used in this document is defined in [RFC7253]. 3490 The OCB algorithm can only use block ciphers with 16-octet blocks. 3491 The nonce is 15 octets long. OCB authentication tags are 16 octets 3492 long. 3494 5.14.5. GCM Mode 3496 The GCM AEAD Algorithm used in this document is defined in 3497 [SP800-38D]. 3499 The GCM algorithm can only use block ciphers with 16-octet blocks. 3500 The nonce is 12 octets long. GCM authentication tags are 16 octets 3501 long. 3503 5.15. Padding Packet (Tag 21) 3505 The Padding packet contains random data, and can be used to defend 3506 against traffic analysis (see Section 15.4) on version 2 SEIPD 3507 messages (see Section 5.14.2) and Transferable Public Keys (see 3508 Section 11.1). 3510 Such a packet MUST be ignored when received. 3512 Its contents SHOULD be random octets to make the length obfuscation 3513 it provides more robust even when compressed. 3515 An implementation adding padding to an OpenPGP stream SHOULD place 3516 such a packet: 3518 * At the end of a v5 Transferable Public Key that is transferred 3519 over an encrypted channel (see Section 11.1). 3521 * As the last packet of an Optionally Padded Message within a 3522 version 2 Symmetrically Encrypted Integrity Protected Data Packet 3523 (see Section 11.3.1). 3525 An implementation MUST be able to process padding packets anywhere 3526 else in an OpenPGP stream, so that future revisions of this document 3527 may specify further locations for padding. 3529 Policy about how large to make such a packet to defend against 3530 traffic analysis is beyond the scope of this document. 3532 6. Radix-64 Conversions 3534 As stated in the introduction, OpenPGP's underlying native 3535 representation for objects is a stream of arbitrary octets, and some 3536 systems desire these objects to be immune to damage caused by 3537 character set translation, data conversions, etc. 3539 In principle, any printable encoding scheme that met the requirements 3540 of the unsafe channel would suffice, since it would not change the 3541 underlying binary bit streams of the native OpenPGP data structures. 3542 The OpenPGP standard specifies one such printable encoding scheme to 3543 ensure interoperability. 3545 OpenPGP's Radix-64 encoding is composed of two parts: a base64 3546 encoding of the binary data and an optional checksum. The base64 3547 encoding is identical to the MIME base64 content-transfer-encoding 3548 [RFC2045]. 3550 The optional checksum is a 24-bit Cyclic Redundancy Check (CRC) 3551 converted to four characters of radix-64 encoding by the same MIME 3552 base64 transformation, preceded by an equal sign (=). The CRC is 3553 computed by using the generator 0x864CFB and an initialization of 3554 0xB704CE. The accumulation is done on the data before it is 3555 converted to radix-64, rather than on the converted data. A sample 3556 implementation of this algorithm is in Section 6.1. 3558 If present, the checksum with its leading equal sign MUST appear on 3559 the next line after the base64 encoded data. 3561 Rationale for CRC-24: The size of 24 bits fits evenly into printable 3562 base64. The nonzero initialization can detect more errors than a 3563 zero initialization. 3565 6.1. An Implementation of the CRC-24 in "C" 3567 #define CRC24_INIT 0xB704CEL 3568 #define CRC24_GENERATOR 0x864CFBL 3570 typedef unsigned long crc24; 3571 crc24 crc_octets(unsigned char *octets, size_t len) 3572 { 3573 crc24 crc = CRC24_INIT; 3574 int i; 3575 while (len--) { 3576 crc ^= (*octets++) << 16; 3577 for (i = 0; i < 8; i++) { 3578 crc <<= 1; 3579 if (crc & 0x1000000) { 3580 crc &= 0xffffff; /* Clear bit 25 to avoid overflow */ 3581 crc ^= CRC24_GENERATOR; 3582 } 3583 } 3584 } 3585 return crc & 0xFFFFFFL; 3586 } 3588 6.2. Forming ASCII Armor 3590 When OpenPGP encodes data into ASCII Armor, it puts specific headers 3591 around the Radix-64 encoded data, so OpenPGP can reconstruct the data 3592 later. An OpenPGP implementation MAY use ASCII armor to protect raw 3593 binary data. OpenPGP informs the user what kind of data is encoded 3594 in the ASCII armor through the use of the headers. 3596 Concatenating the following data creates ASCII Armor: 3598 * An Armor Header Line, appropriate for the type of data 3600 * Armor Headers 3602 * A blank (zero-length, or containing only whitespace) line 3604 * The ASCII-Armored data 3606 * An Armor Checksum 3608 * The Armor Tail, which depends on the Armor Header Line 3609 An Armor Header Line consists of the appropriate header line text 3610 surrounded by five (5) dashes (-, 0x2D) on either side of the header 3611 line text. The header line text is chosen based upon the type of 3612 data that is being encoded in Armor, and how it is being encoded. 3613 Header line texts include the following strings: 3615 BEGIN PGP MESSAGE 3616 Used for signed, encrypted, or compressed files. 3618 BEGIN PGP PUBLIC KEY BLOCK 3619 Used for armoring public keys. 3621 BEGIN PGP PRIVATE KEY BLOCK 3622 Used for armoring private keys. 3624 BEGIN PGP MESSAGE, PART X/Y 3625 Used for multi-part messages, where the armor is split amongst Y 3626 parts, and this is the Xth part out of Y. 3628 BEGIN PGP MESSAGE, PART X 3629 Used for multi-part messages, where this is the Xth part of an 3630 unspecified number of parts. Requires the MESSAGE-ID Armor Header 3631 to be used. 3633 BEGIN PGP SIGNATURE 3634 Used for detached signatures, OpenPGP/MIME signatures, and 3635 cleartext signatures. 3637 Note that all these Armor Header Lines are to consist of a complete 3638 line. That is to say, there is always a line ending preceding the 3639 starting five dashes, and following the ending five dashes. The 3640 header lines, therefore, MUST start at the beginning of a line, and 3641 MUST NOT have text other than whitespace following them on the same 3642 line. These line endings are considered a part of the Armor Header 3643 Line for the purposes of determining the content they delimit. This 3644 is particularly important when computing a cleartext signature (see 3645 Section 7). 3647 The Armor Headers are pairs of strings that can give the user or the 3648 receiving OpenPGP implementation some information about how to decode 3649 or use the message. The Armor Headers are a part of the armor, not a 3650 part of the message, and hence are not protected by any signatures 3651 applied to the message. 3653 The format of an Armor Header is that of a key-value pair. A colon 3654 (: 0x38) and a single space (0x20) separate the key and value. 3655 OpenPGP should consider improperly formatted Armor Headers to be 3656 corruption of the ASCII Armor. Unknown keys should be reported to 3657 the user, but OpenPGP should continue to process the message. 3659 Note that some transport methods are sensitive to line length. While 3660 there is a limit of 76 characters for the Radix-64 data 3661 (Section 6.3), there is no limit to the length of Armor Headers. 3662 Care should be taken that the Armor Headers are short enough to 3663 survive transport. One way to do this is to repeat an Armor Header 3664 Key multiple times with different values for each so that no one line 3665 is overly long. 3667 Currently defined Armor Header Keys are as follows: 3669 * "Version", which states the OpenPGP implementation and version 3670 used to encode the message. To minimize metadata, implementations 3671 SHOULD NOT emit this key and its corresponding value except for 3672 debugging purposes with explicit user consent. 3674 * "Comment", a user-defined comment. OpenPGP defines all text to be 3675 in UTF-8. A comment may be any UTF-8 string. However, the whole 3676 point of armoring is to provide seven-bit-clean data. 3677 Consequently, if a comment has characters that are outside the US- 3678 ASCII range of UTF, they may very well not survive transport. 3680 * "MessageID", a 32-character string of printable characters. The 3681 string must be the same for all parts of a multi-part message that 3682 uses the "PART X" Armor Header. MessageID strings should be 3683 unique enough that the recipient of the mail can associate all the 3684 parts of a message with each other. A good checksum or 3685 cryptographic hash function is sufficient. 3687 The MessageID SHOULD NOT appear unless it is in a multi-part 3688 message. If it appears at all, it MUST be computed from the 3689 finished (encrypted, signed, etc.) message in a deterministic 3690 fashion, rather than contain a purely random value. This is to 3691 allow the legitimate recipient to determine that the MessageID 3692 cannot serve as a covert means of leaking cryptographic key 3693 information. 3695 * "Hash", a comma-separated list of hash algorithms used in this 3696 message. This is used only in cleartext signed messages. 3698 * "SaltedHash", a salt and hash algorithm used in this message. 3699 This is used only in cleartext signed messages that are followed 3700 by a v5 Signature. 3702 * "Charset", a description of the character set that the plaintext 3703 is in. Please note that OpenPGP defines text to be in UTF-8. An 3704 implementation will get best results by translating into and out 3705 of UTF-8. However, there are many instances where this is easier 3706 said than done. Also, there are communities of users who have no 3707 need for UTF-8 because they are all happy with a character set 3708 like ISO Latin-5 or a Japanese character set. In such instances, 3709 an implementation MAY override the UTF-8 default by using this 3710 header key. An implementation MAY implement this key and any 3711 translations it cares to; an implementation MAY ignore it and 3712 assume all text is UTF-8. 3714 The Armor Tail Line is composed in the same manner as the Armor 3715 Header Line, except the string "BEGIN" is replaced by the string 3716 "END". 3718 6.3. Encoding Binary in Radix-64 3720 The encoding process represents 24-bit groups of input bits as output 3721 strings of 4 encoded characters. Proceeding from left to right, a 3722 24-bit input group is formed by concatenating three 8-bit input 3723 groups. These 24 bits are then treated as four concatenated 6-bit 3724 groups, each of which is translated into a single digit in the 3725 Radix-64 alphabet. When encoding a bit stream with the Radix-64 3726 encoding, the bit stream must be presumed to be ordered with the most 3727 significant bit first. That is, the first bit in the stream will be 3728 the high-order bit in the first 8-bit octet, and the eighth bit will 3729 be the low-order bit in the first 8-bit octet, and so on. 3731 ┌──first octet──┬─second octet──┬──third octet──┐ 3732 │7 6 5 4 3 2 1 0│7 6 5 4 3 2 1 0│7 6 5 4 3 2 1 0│ 3733 ├───────────┬───┴───────┬───────┴───┬───────────┤ 3734 │5 4 3 2 1 0│5 4 3 2 1 0│5 4 3 2 1 0│5 4 3 2 1 0│ 3735 └──1.index──┴──2.index──┴──3.index──┴──4.index──┘ 3737 Each 6-bit group is used as an index into an array of 64 printable 3738 characters from the table below. The character referenced by the 3739 index is placed in the output string. 3741 +=====+========++=====+=========++=====+==========++=====+==========+ 3742 |Value|Encoding||Value|Encoding ||Value| Encoding ||Value| Encoding | 3743 +=====+========++=====+=========++=====+==========++=====+==========+ 3744 | 0|A || 17|R || 34| i || 51| z | 3745 +-----+--------++-----+---------++-----+----------++-----+----------+ 3746 | 1|B || 18|S || 35| j || 52| 0 | 3747 +-----+--------++-----+---------++-----+----------++-----+----------+ 3748 | 2|C || 19|T || 36| k || 53| 1 | 3749 +-----+--------++-----+---------++-----+----------++-----+----------+ 3750 | 3|D || 20|U || 37| l || 54| 2 | 3751 +-----+--------++-----+---------++-----+----------++-----+----------+ 3752 | 4|E || 21|V || 38| m || 55| 3 | 3753 +-----+--------++-----+---------++-----+----------++-----+----------+ 3754 | 5|F || 22|W || 39| n || 56| 4 | 3755 +-----+--------++-----+---------++-----+----------++-----+----------+ 3756 | 6|G || 23|X || 40| o || 57| 5 | 3757 +-----+--------++-----+---------++-----+----------++-----+----------+ 3758 | 7|H || 24|Y || 41| p || 58| 6 | 3759 +-----+--------++-----+---------++-----+----------++-----+----------+ 3760 | 8|I || 25|Z || 42| q || 59| 7 | 3761 +-----+--------++-----+---------++-----+----------++-----+----------+ 3762 | 9|J || 26|a || 43| r || 60| 8 | 3763 +-----+--------++-----+---------++-----+----------++-----+----------+ 3764 | 10|K || 27|b || 44| s || 61| 9 | 3765 +-----+--------++-----+---------++-----+----------++-----+----------+ 3766 | 11|L || 28|c || 45| t || 62| + | 3767 +-----+--------++-----+---------++-----+----------++-----+----------+ 3768 | 12|M || 29|d || 46| u || 63| / | 3769 +-----+--------++-----+---------++-----+----------++-----+----------+ 3770 | 13|N || 30|e || 47| v || | | 3771 +-----+--------++-----+---------++-----+----------++-----+----------+ 3772 | 14|O || 31|f || 48| w ||(pad)| = | 3773 +-----+--------++-----+---------++-----+----------++-----+----------+ 3774 | 15|P || 32|g || 49| x || | | 3775 +-----+--------++-----+---------++-----+----------++-----+----------+ 3776 | 16|Q || 33|h || 50| y || | | 3777 +-----+--------++-----+---------++-----+----------++-----+----------+ 3779 Table 16: Encoding for Radix-64 3781 The encoded output stream must be represented in lines of no more 3782 than 76 characters each. 3784 Special processing is performed if fewer than 24 bits are available 3785 at the end of the data being encoded. There are three possibilities: 3787 1. The last data group has 24 bits (3 octets). No special 3788 processing is needed. 3790 2. The last data group has 16 bits (2 octets). The first two 6-bit 3791 groups are processed as above. The third (incomplete) data group 3792 has two zero-value bits added to it, and is processed as above. 3793 A pad character (=) is added to the output. 3795 3. The last data group has 8 bits (1 octet). The first 6-bit group 3796 is processed as above. The second (incomplete) data group has 3797 four zero-value bits added to it, and is processed as above. Two 3798 pad characters (=) are added to the output. 3800 6.4. Decoding Radix-64 3802 In Radix-64 data, characters other than those in the table, line 3803 breaks, and other white space probably indicate a transmission error, 3804 about which a warning message or even a message rejection might be 3805 appropriate under some circumstances. Decoding software must ignore 3806 all white space. 3808 Because it is used only for padding at the end of the data, the 3809 occurrence of any "=" characters may be taken as evidence that the 3810 end of the data has been reached (without truncation in transit). No 3811 such assurance is possible, however, when the number of octets 3812 transmitted was a multiple of three and no "=" characters are 3813 present. 3815 6.5. Examples of Radix-64 3816 Input data: 0x14FB9C03D97E 3817 Hex: 1 4 F B 9 C | 0 3 D 9 7 E 3818 8-bit: 00010100 11111011 10011100 | 00000011 11011001 01111110 3819 6-bit: 000101 001111 101110 011100 | 000000 111101 100101 111110 3820 Decimal: 5 15 46 28 0 61 37 62 3821 Output: F P u c A 9 l + 3822 Input data: 0x14FB9C03D9 3823 Hex: 1 4 F B 9 C | 0 3 D 9 3824 8-bit: 00010100 11111011 10011100 | 00000011 11011001 3825 pad with 00 3826 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 3827 Decimal: 5 15 46 28 0 61 36 3828 pad with = 3829 Output: F P u c A 9 k = 3830 Input data: 0x14FB9C03 3831 Hex: 1 4 F B 9 C | 0 3 3832 8-bit: 00010100 11111011 10011100 | 00000011 3833 pad with 0000 3834 6-bit: 000101 001111 101110 011100 | 000000 110000 3835 Decimal: 5 15 46 28 0 48 3836 pad with = = 3837 Output: F P u c A w = = 3839 6.6. Example of an ASCII Armored Message 3841 -----BEGIN PGP MESSAGE----- 3843 yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS 3844 vBSFjNSiVHsuAA== 3845 =njUN 3846 -----END PGP MESSAGE----- 3848 Note that this example has extra indenting; an actual armored message 3849 would have no leading whitespace. 3851 7. Cleartext Signature Framework 3853 It is desirable to be able to sign a textual octet stream without 3854 ASCII armoring the stream itself, so the signed text is still 3855 readable without special software. In order to bind a signature to 3856 such a cleartext, this framework is used, which follows the same 3857 basic format and restrictions as the ASCII armoring described in 3858 Section 6.2. (Note that this framework is not intended to be 3859 reversible. [RFC3156] defines another way to sign cleartext messages 3860 for environments that support MIME.) 3862 The cleartext signed message consists of: 3864 * The cleartext header -----BEGIN PGP SIGNED MESSAGE----- on a 3865 single line, 3867 * If the message is signed using v3 or v4 Signatures, one or more 3868 "Hash" Armor Headers, 3870 * If the message is signed using v5 Signatures, one or more 3871 "SaltedHash" Armor Headers, 3873 * Exactly one empty line not included into the message digest, 3875 * The dash-escaped cleartext that is included into the message 3876 digest, 3878 * The ASCII armored signature(s) including the -----BEGIN PGP 3879 SIGNATURE----- Armor Header and Armor Tail Lines. 3881 If the "Hash" Armor Header is given, the specified message digest 3882 algorithm(s) are used for the signature. If more than one message 3883 digest is used in the signature, the "Hash" armor header contains a 3884 comma-delimited list of used message digests. 3886 If the "SaltedHash" Armor Header is given, the specified message 3887 digest algorithm and salt are used for a signature. The message 3888 digest name is followed by a colon (:) followed by 22 characters of 3889 Radix-64 encoded salt without padding. Note: The "SaltedHash" Armor 3890 Header contains digest algorithm and salt for a single signature; a 3891 second signature requires a second "SaltedHash" Armor Header. 3893 Current message digest names are described with the algorithm IDs in 3894 Section 9.5. 3896 An implementation SHOULD add a line break after the cleartext, but 3897 MAY omit it if the cleartext ends with a line break. This is for 3898 visual clarity. 3900 7.1. Dash-Escaped Text 3902 The cleartext content of the message must also be dash-escaped. 3904 Dash-escaped cleartext is the ordinary cleartext where every line 3905 starting with a "-" (HYPHEN-MINUS, U+002D) is prefixed by the 3906 sequence "-" (HYPHEN-MINUS, U+002D) and " " (SPACE, U+0020). This 3907 prevents the parser from recognizing armor headers of the cleartext 3908 itself. An implementation MAY dash-escape any line, SHOULD dash- 3909 escape lines commencing "From" followed by a space, and MUST dash- 3910 escape any line commencing in a dash. The message digest is computed 3911 using the cleartext itself, not the dash-escaped form. 3913 As with binary signatures on text documents, a cleartext signature is 3914 calculated on the text using canonical line endings. The 3915 line ending (that is, the ) before the -----BEGIN PGP 3916 SIGNATURE----- line that terminates the signed text is not considered 3917 part of the signed text. 3919 When reversing dash-escaping, an implementation MUST strip the string 3920 - if it occurs at the beginning of a line, and SHOULD warn on - and 3921 any character other than a space at the beginning of a line. 3923 Also, any trailing whitespace --- spaces (0x20) and tabs (0x09) --- 3924 at the end of any line is removed when the cleartext signature is 3925 generated. 3927 8. Regular Expressions 3929 A regular expression is zero or more branches, separated by |. It 3930 matches anything that matches one of the branches. 3932 A branch is zero or more pieces, concatenated. It matches a match 3933 for the first, followed by a match for the second, etc. 3935 A piece is an atom possibly followed by *, +, or ?. An atom followed 3936 by * matches a sequence of 0 or more matches of the atom. An atom 3937 followed by + matches a sequence of 1 or more matches of the atom. 3938 An atom followed by ? matches a match of the atom, or the null 3939 string. 3941 An atom is a regular expression in parentheses (matching a match for 3942 the regular expression), a range (see below), . (matching any single 3943 character), ^ (matching the null string at the beginning of the input 3944 string), $ (matching the null string at the end of the input string), 3945 a \ followed by a single character (matching that character), or a 3946 single character with no other significance (matching that 3947 character). 3949 A range is a sequence of characters enclosed in []. It normally 3950 matches any single character from the sequence. If the sequence 3951 begins with ^, it matches any single character not from the rest of 3952 the sequence. If two characters in the sequence are separated by -, 3953 this is shorthand for the full list of ASCII characters between them 3954 (for example, [0-9] matches any decimal digit). To include a literal 3955 ] in the sequence, make it the first character (following a possible 3956 ^). To include a literal -, make it the first or last character. 3958 9. Constants 3960 This section describes the constants used in OpenPGP. 3962 Note that these tables are not exhaustive lists; an implementation 3963 MAY implement an algorithm not on these lists, so long as the 3964 algorithm numbers are chosen from the private or experimental 3965 algorithm range. 3967 See Section 14 for more discussion of the algorithms. 3969 9.1. Public-Key Algorithms 3971 +===+==============+===========+============+===========+===========+ 3972 | ID|Algorithm |Public Key |Secret Key | Signature |PKESK | 3973 | | |Format |Format | Format |Format | 3974 +===+==============+===========+============+===========+===========+ 3975 | 1|RSA (Encrypt |MPI(n), |MPI(d), | MPI(m**d |MPI(m**e | 3976 | |or Sign) [HAC]|MPI(e) |MPI(p), | mod n) |mod n) | 3977 | | |[Section |MPI(q), | [Section |[Section | 3978 | | |5.6.1] |MPI(u) | 5.2.3.1] |5.1.3] | 3979 +---+--------------+-----------+------------+-----------+-----------+ 3980 | 2|RSA Encrypt- |MPI(n), |MPI(d), | N/A |MPI(m**e | 3981 | |Only [HAC] |MPI(e) |MPI(p), | |mod n) | 3982 | | |[Section |MPI(q), | |[Section | 3983 | | |5.6.1] |MPI(u) | |5.1.3] | 3984 +---+--------------+-----------+------------+-----------+-----------+ 3985 | 3|RSA Sign-Only |MPI(n), |MPI(d), | MPI(m**d |N/A | 3986 | |[HAC] |MPI(e) |MPI(p), | mod n) | | 3987 | | |[Section |MPI(q), | [Section | | 3988 | | |5.6.1] |MPI(u) | 5.2.3.1] | | 3989 +---+--------------+-----------+------------+-----------+-----------+ 3990 | 16|Elgamal |MPI(p), |MPI(x) | N/A |MPI(g**k | 3991 | |(Encrypt-Only)|MPI(g), | | |mod p), MPI| 3992 | |[ELGAMAL] |MPI(y) | | |(m * y**k | 3993 | |[HAC] |[Section | | |mod p) | 3994 | | |5.6.3] | | |[Section | 3995 | | | | | |5.1.4] | 3996 +---+--------------+-----------+------------+-----------+-----------+ 3997 | 17|DSA (Digital |MPI(p), |MPI(x) | MPI(r), |N/A | 3998 | |Signature |MPI(q), | | MPI(s) | | 3999 | |Algorithm) |MPI(g), | | [Section | | 4000 | |[FIPS186] |MPI(y) | | 5.2.3.2] | | 4001 | |[HAC] |[Section | | | | 4002 | | |5.6.2] | | | | 4003 +---+--------------+-----------+------------+-----------+-----------+ 4004 | 18|ECDH public |OID, |MPI(value in| N/A |MPI(point | 4005 | |key algorithm |MPI(point |curve- | |in curve- | 4006 | | |in curve- |specific | |specific | 4007 | | |specific |format) | |point | 4008 | | |point |[Section | |format), | 4009 | | |format), |9.2.1] | |size octet,| 4010 | | |KDFParams | | |encoded key| 4011 | | |[see | | |[Section | 4012 | | |Section | | |9.2.1, | 4013 | | |9.2.1, | | |Section | 4014 | | |Section | | |5.1.5, | 4015 | | |5.6.6] | | |Section | 4016 | | | | | |13.5] | 4017 +---+--------------+-----------+------------+-----------+-----------+ 4018 | 19|ECDSA public |OID, |MPI(value) | MPI(r), |N/A | 4019 | |key algorithm |MPI(point | | MPI(s) | | 4020 | |[FIPS186] |in SEC1 | | [Section | | 4021 | | |format) | | 5.2.3.2] | | 4022 | | |[Section | | | | 4023 | | |5.6.4] | | | | 4024 +---+--------------+-----------+------------+-----------+-----------+ 4025 | 20|Reserved | | | | | 4026 | |(formerly | | | | | 4027 | |Elgamal | | | | | 4028 | |Encrypt or | | | | | 4029 | |Sign) | | | | | 4030 +---+--------------+-----------+------------+-----------+-----------+ 4031 | 21|Reserved for | | | | | 4032 | |Diffie-Hellman| | | | | 4033 | |(X9.42, as | | | | | 4034 | |defined for | | | | | 4035 | |IETF-S/MIME) | | | | | 4036 +---+--------------+-----------+------------+-----------+-----------+ 4037 | 22|EdDSA |OID, |MPI(value in| MPI, MPI |N/A | 4038 | |[RFC8032] |MPI(point |curve- | [see | | 4039 | | |in prefixed|specific | Section | | 4040 | | |native |format) [see| 9.2.1, | | 4041 | | |format) |Section | Section | | 4042 | | |[see |9.2.1] | 5.2.3.3] | | 4043 | | |Section | | | | 4044 | | |13.2.2, | | | | 4045 | | |Section | | | | 4046 | | |5.6.5] | | | | 4047 +---+--------------+-----------+------------+-----------+-----------+ 4048 | 23|Reserved | | | | | 4049 | |(AEDH) | | | | | 4050 +---+--------------+-----------+------------+-----------+-----------+ 4051 | 24|Reserved | | | | | 4052 | |(AEDSA) | | | | | 4053 +---+--------------+-----------+------------+-----------+-----------+ 4054 |100|Private/ | | | | | 4055 | to|Experimental | | | | | 4056 |110|algorithm | | | | | 4057 +---+--------------+-----------+------------+-----------+-----------+ 4059 Table 17: Public-key algorithm registry 4061 Implementations MUST implement EdDSA (19) for signatures, and ECDH 4062 (18) for encryption. Implementations SHOULD implement RSA (1) for 4063 signatures and encryption. 4065 RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and SHOULD 4066 NOT be generated, but may be interpreted. See Section 14.4. See 4067 Section 14.8 for notes on Elgamal Encrypt or Sign (20), and X9.42 4068 (21). Implementations MAY implement any other algorithm. 4070 Note that an implementation conforming to the previous version of 4071 this standard ([RFC4880]) have only DSA (17) and Elgamal (16) as its 4072 MUST-implement algorithms. 4074 A compatible specification of ECDSA is given in [RFC6090] as "KT-I 4075 Signatures" and in [SEC1]; ECDH is defined in Section 13.5 of this 4076 document. 4078 9.2. ECC Curves for OpenPGP 4080 The parameter curve OID is an array of octets that define a named 4081 curve. 4083 The table below specifies the exact sequence of octets for each named 4084 curve referenced in this document. It also specifies which public 4085 key algorithms the curve can be used with, as well as the size of 4086 expected elements in octets: 4088 +======================+===+==============+==========+======+=======+ 4089 |ASN.1 Object |OID|Curve OID |Curve name|Usage |Field | 4090 |Identifier |len|octets in | | |Size | 4091 | | |hexadecimal | | |(fsize)| 4092 | | |representation| | | | 4093 +======================+===+==============+==========+======+=======+ 4094 |1.2.840.10045.3.1.7 |8 |2A 86 48 CE 3D|NIST P-256|ECDSA,|32 | 4095 | | |03 01 07 | |ECDH | | 4096 +----------------------+---+--------------+----------+------+-------+ 4097 |1.3.132.0.34 |5 |2B 81 04 00 22|NIST P-384|ECDSA,|48 | 4098 | | | | |ECDH | | 4099 +----------------------+---+--------------+----------+------+-------+ 4100 |1.3.132.0.35 |5 |2B 81 04 00 23|NIST P-521|ECDSA,|66 | 4101 | | | | |ECDH | | 4102 +----------------------+---+--------------+----------+------+-------+ 4103 |1.3.6.1.4.1.11591.15.1|9 |2B 06 01 04 01|Ed25519 |EdDSA |32 | 4104 | | |DA 47 0F 01 | | | | 4105 +----------------------+---+--------------+----------+------+-------+ 4106 |1.3.101.113 |3 |2B 65 71 |Ed448 |EdDSA |57 | 4107 +----------------------+---+--------------+----------+------+-------+ 4108 |1.3.6.1.4.1.3029.1.5.1|10 |2B 06 01 04 01|Curve25519|ECDH |32 | 4109 | | |97 55 01 05 01| | | | 4110 +----------------------+---+--------------+----------+------+-------+ 4111 |1.3.101.111 |3 |2B 65 6F |X448 |ECDH |56 | 4112 +----------------------+---+--------------+----------+------+-------+ 4114 Table 18: ECC Curve OID and usage registry 4116 The "Field Size (fsize)" column represents the field size of the 4117 group in number of octets, rounded up, such that x or y coordinates 4118 for a point on the curve, native point representations, or scalars 4119 with high enough entropy for the curve can be represented in that 4120 many octets. 4122 The sequence of octets in the third column is the result of applying 4123 the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier 4124 with subsequent truncation. The truncation removes the two fields of 4125 encoded Object Identifier. The first omitted field is one octet 4126 representing the Object Identifier tag, and the second omitted field 4127 is the length of the Object Identifier body. For example, the 4128 complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A 4129 86 48 CE 3D 03 01 07", from which the first entry in the table above 4130 is constructed by omitting the first two octets. Only the truncated 4131 sequence of octets is the valid representation of a curve OID. 4133 Implementations MUST implement Ed25519 for use with EdDSA, and 4134 Curve25519 for use with ECDH. Implementations SHOULD implement Ed448 4135 for use with EdDSA, and X448 for use with ECDH. 4137 9.2.1. Curve-Specific Wire Formats 4139 Some Elliptic Curve Public Key Algorithms use different conventions 4140 for specific fields depending on the curve in use. Each field is 4141 always formatted as an MPI, but with a curve-specific framing. This 4142 table summarizes those distinctions. 4144 +===========+========+============+========+=========+==============+ 4145 |Curve |ECDH |ECDH Secret |EdDSA |EdDSA |EdDSA | 4146 | |Point |Key MPI |Secret |Signature|Signature | 4147 | |Format | |Key MPI |first MPI|second MPI | 4148 +===========+========+============+========+=========+==============+ 4149 |NIST P-256 |SEC1 |integer |N/A |N/A |N/A | 4150 +-----------+--------+------------+--------+---------+--------------+ 4151 |NIST P-384 |SEC1 |integer |N/A |N/A |N/A | 4152 +-----------+--------+------------+--------+---------+--------------+ 4153 |NIST P-521 |SEC1 |integer |N/A |N/A |N/A | 4154 +-----------+--------+------------+--------+---------+--------------+ 4155 |Ed25519 |N/A |N/A |32 |32 octets|32 octets of S| 4156 | | | |octets |of R | | 4157 | | | |of | | | 4158 | | | |secret | | | 4159 +-----------+--------+------------+--------+---------+--------------+ 4160 |Ed448 |N/A |N/A |prefixed|prefixed |0 [this is an | 4161 | | | |57 |114 |unused | 4162 | | | |octets |octets of|placeholder] | 4163 | | | |of |signature| | 4164 | | | |secret | | | 4165 +-----------+--------+------------+--------+---------+--------------+ 4166 |Curve25519 |prefixed|integer (see|N/A |N/A |N/A | 4167 | |native |Section | | | | 4168 | | |5.6.6.1.1) | | | | 4169 +-----------+--------+------------+--------+---------+--------------+ 4170 |X448 |prefixed|prefixed 56 |N/A |N/A |N/A | 4171 | |native |octets of | | | | 4172 | | |secret | | | | 4173 +-----------+--------+------------+--------+---------+--------------+ 4175 Table 19: Curve-specific wire formats 4177 For the native octet-string forms of EdDSA values, see [RFC8032]. 4178 For the native octet-string forms of ECDH secret scalars and points, 4179 see [RFC7748]. 4181 9.3. Symmetric-Key Algorithms 4183 +==========+====================================================+ 4184 | ID | Algorithm | 4185 +==========+====================================================+ 4186 | 0 | Plaintext or unencrypted data | 4187 +----------+----------------------------------------------------+ 4188 | 1 | IDEA [IDEA] | 4189 +----------+----------------------------------------------------+ 4190 | 2 | TripleDES (DES-EDE, [SCHNEIER], [HAC] - 168 bit | 4191 | | key derived from 192) | 4192 +----------+----------------------------------------------------+ 4193 | 3 | CAST5 (128 bit key, as per [RFC2144]) | 4194 +----------+----------------------------------------------------+ 4195 | 4 | Blowfish (128 bit key, 16 rounds) [BLOWFISH] | 4196 +----------+----------------------------------------------------+ 4197 | 5 | Reserved | 4198 +----------+----------------------------------------------------+ 4199 | 6 | Reserved | 4200 +----------+----------------------------------------------------+ 4201 | 7 | AES with 128-bit key [AES] | 4202 +----------+----------------------------------------------------+ 4203 | 8 | AES with 192-bit key | 4204 +----------+----------------------------------------------------+ 4205 | 9 | AES with 256-bit key | 4206 +----------+----------------------------------------------------+ 4207 | 10 | Twofish with 256-bit key [TWOFISH] | 4208 +----------+----------------------------------------------------+ 4209 | 11 | Camellia with 128-bit key [RFC3713] | 4210 +----------+----------------------------------------------------+ 4211 | 12 | Camellia with 192-bit key | 4212 +----------+----------------------------------------------------+ 4213 | 13 | Camellia with 256-bit key | 4214 +----------+----------------------------------------------------+ 4215 | 100 to | Private/Experimental algorithm | 4216 | 110 | | 4217 +----------+----------------------------------------------------+ 4218 | 253, 254 | Reserved to avoid collision with Secret Key | 4219 | and 255 | Encryption (see Section 3.7.2.1 and Section 5.5.3) | 4220 +----------+----------------------------------------------------+ 4222 Table 20: Symmetric-key algorithm registry 4224 Implementations MUST implement AES-128. Implementations SHOULD 4225 implement AES-256. Implementations MUST NOT encrypt data with IDEA, 4226 TripleDES, or CAST5. Implementations MAY decrypt data that uses 4227 IDEA, TripleDES, or CAST5 for the sake of reading older messages or 4228 new messages from legacy clients. Implementations MAY implement any 4229 other algorithm. 4231 9.4. Compression Algorithms 4233 +============+================================+ 4234 | ID | Algorithm | 4235 +============+================================+ 4236 | 0 | Uncompressed | 4237 +------------+--------------------------------+ 4238 | 1 | ZIP [RFC1951] | 4239 +------------+--------------------------------+ 4240 | 2 | ZLIB [RFC1950] | 4241 +------------+--------------------------------+ 4242 | 3 | BZip2 [BZ2] | 4243 +------------+--------------------------------+ 4244 | 100 to 110 | Private/Experimental algorithm | 4245 +------------+--------------------------------+ 4247 Table 21: Compression algorithm registry 4249 Implementations MUST implement uncompressed data. Implementations 4250 SHOULD implement ZLIB. For interoperability reasons implementations 4251 SHOULD be able to decompress using ZIP. Implementations MAY 4252 implement any other algorithm. 4254 9.5. Hash Algorithms 4256 +============+================================+=============+ 4257 | ID | Algorithm | Text Name | 4258 +============+================================+=============+ 4259 | 1 | MD5 [HAC] | "MD5" | 4260 +------------+--------------------------------+-------------+ 4261 | 2 | SHA-1 [FIPS180] | "SHA1" | 4262 +------------+--------------------------------+-------------+ 4263 | 3 | RIPE-MD/160 [HAC] | "RIPEMD160" | 4264 +------------+--------------------------------+-------------+ 4265 | 4 | Reserved | | 4266 +------------+--------------------------------+-------------+ 4267 | 5 | Reserved | | 4268 +------------+--------------------------------+-------------+ 4269 | 6 | Reserved | | 4270 +------------+--------------------------------+-------------+ 4271 | 7 | Reserved | | 4272 +------------+--------------------------------+-------------+ 4273 | 8 | SHA2-256 [FIPS180] | "SHA256" | 4274 +------------+--------------------------------+-------------+ 4275 | 9 | SHA2-384 [FIPS180] | "SHA384" | 4276 +------------+--------------------------------+-------------+ 4277 | 10 | SHA2-512 [FIPS180] | "SHA512" | 4278 +------------+--------------------------------+-------------+ 4279 | 11 | SHA2-224 [FIPS180] | "SHA224" | 4280 +------------+--------------------------------+-------------+ 4281 | 12 | SHA3-256 [FIPS202] | "SHA3-256" | 4282 +------------+--------------------------------+-------------+ 4283 | 13 | Reserved | | 4284 +------------+--------------------------------+-------------+ 4285 | 14 | SHA3-512 [FIPS202] | "SHA3-512" | 4286 +------------+--------------------------------+-------------+ 4287 | 100 to 110 | Private/Experimental algorithm | | 4288 +------------+--------------------------------+-------------+ 4290 Table 22: Hash algorithm registry 4292 Implementations MUST implement SHA2-256. Implementations SHOULD 4293 implement SHA2-384 and SHA2-512. Implementations MAY implement other 4294 algorithms. Implementations SHOULD NOT create messages which require 4295 the use of SHA-1 with the exception of computing version 4 key 4296 fingerprints and for purposes of the Modification Detection Code 4297 (MDC) in version 1 Symmetrically Encrypted Integrity Protected Data 4298 packets. Implementations MUST NOT generate signatures with MD5, SHA- 4299 1, or RIPE-MD/160. Implementations MUST NOT use MD5, SHA-1, or RIPE- 4300 MD/160 as a hash function in an ECDH KDF. Implementations MUST NOT 4301 validate any recent signature that depends on MD5, SHA-1, or RIPE- 4302 MD/160. Implementations SHOULD NOT validate any old signature that 4303 depends on MD5, SHA-1, or RIPE-MD/160 unless the signature's creation 4304 date predates known weakness of the algorithm used, and the 4305 implementation is confident that the message has been in the secure 4306 custody of the user the whole time. 4308 9.6. AEAD Algorithms 4310 +========+======================+===========+====================+ 4311 | ID | Algorithm | IV length | authentication tag | 4312 | | | (octets) | length (octets) | 4313 +========+======================+===========+====================+ 4314 | 1 | EAX [EAX] | 16 | 16 | 4315 +--------+----------------------+-----------+--------------------+ 4316 | 2 | OCB [RFC7253] | 15 | 16 | 4317 +--------+----------------------+-----------+--------------------+ 4318 | 3 | GCM [SP800-38D] | 12 | 16 | 4319 +--------+----------------------+-----------+--------------------+ 4320 | 100 to | Private/Experimental | | | 4321 | 110 | algorithm | | | 4322 +--------+----------------------+-----------+--------------------+ 4324 Table 23: AEAD algorithm registry 4326 Implementations MUST implement OCB. Implementations MAY implement 4327 EAX, GCM and other algorithms. 4329 10. IANA Considerations 4331 Because this document obsoletes [RFC4880], IANA is requested to 4332 update all registration information that references [RFC4880] to 4333 instead reference this RFC. 4335 OpenPGP is highly parameterized, and consequently there are a number 4336 of considerations for allocating parameters for extensions. This 4337 section describes how IANA should look at extensions to the protocol 4338 as described in this document. 4340 10.1. New String-to-Key Specifier Types 4342 OpenPGP S2K specifiers contain a mechanism for new algorithms to turn 4343 a string into a key. This specification creates a registry of S2K 4344 specifier types. The registry includes the S2K type, the name of the 4345 S2K, and a reference to the defining specification. The initial 4346 values for this registry can be found in Section 3.7.1. Adding a new 4347 S2K specifier MUST be done through the SPECIFICATION REQUIRED method, 4348 as described in [RFC8126]. 4350 IANA should add a column "Generate?" to the S2K type registry, with 4351 initial values taken from Section 3.7.1. 4353 10.2. New Packets 4355 Major new features of OpenPGP are defined through new packet types. 4356 This specification creates a registry of packet types. The registry 4357 includes the packet type, the name of the packet, and a reference to 4358 the defining specification. The initial values for this registry can 4359 be found in Section 4.3. Adding a new packet type MUST be done 4360 through the RFC REQUIRED method, as described in [RFC8126]. 4362 10.2.1. User Attribute Types 4364 The User Attribute packet permits an extensible mechanism for other 4365 types of certificate identification. This specification creates a 4366 registry of User Attribute types. The registry includes the User 4367 Attribute type, the name of the User Attribute, and a reference to 4368 the defining specification. The initial values for this registry can 4369 be found in Section 5.13. Adding a new User Attribute type MUST be 4370 done through the SPECIFICATION REQUIRED method, as described in 4371 [RFC8126]. 4373 10.2.1.1. Image Format Subpacket Types 4375 Within User Attribute packets, there is an extensible mechanism for 4376 other types of image-based User Attributes. This specification 4377 creates a registry of Image Attribute subpacket types. The registry 4378 includes the Image Attribute subpacket type, the name of the Image 4379 Attribute subpacket, and a reference to the defining specification. 4380 The initial values for this registry can be found in Section 5.13.1. 4381 Adding a new Image Attribute subpacket type MUST be done through the 4382 SPECIFICATION REQUIRED method, as described in [RFC8126]. 4384 10.2.2. New Signature Subpackets 4386 OpenPGP signatures contain a mechanism for signed (or unsigned) data 4387 to be added to them for a variety of purposes in the Signature 4388 subpackets as discussed in Section 5.2.3.5. This specification 4389 creates a registry of Signature subpacket types. The registry 4390 includes the Signature subpacket type, the name of the subpacket, and 4391 a reference to the defining specification. The initial values for 4392 this registry can be found in Section 5.2.3.5. Adding a new 4393 Signature subpacket MUST be done through the SPECIFICATION REQUIRED 4394 method, as described in [RFC8126]. 4396 10.2.2.1. Signature Notation Data Subpackets 4398 OpenPGP signatures further contain a mechanism for extensions in 4399 signatures. These are the Notation Data subpackets, which contain a 4400 key/value pair. Notations contain a user space that is completely 4401 unmanaged and an IETF space. 4403 This specification creates a registry of Signature Notation Data 4404 types. The registry includes the Signature Notation Data type, the 4405 name of the Signature Notation Data, its allowed values, and a 4406 reference to the defining specification. The initial values for this 4407 registry can be found in Section 5.2.3.21. Adding a new Signature 4408 Notation Data subpacket MUST be done through the SPECIFICATION 4409 REQUIRED method, as described in [RFC8126]. 4411 10.2.2.2. Signature Notation Data Subpacket Notation Flags 4413 This specification creates a new registry of Signature Notation Data 4414 Subpacket Notation Flags. The registry includes the columns "Flag", 4415 "Description", "Security Recommended", "Interoperability 4416 Recommended", and "Reference". The initial values for this registry 4417 can be found in Section 5.2.3.21. Adding a new item MUST be done 4418 through the SPECIFICATION REQUIRED method, as described in [RFC8126]. 4420 10.2.2.3. Key Server Preference Extensions 4422 OpenPGP signatures contain a mechanism for preferences to be 4423 specified about key servers. This specification creates a registry 4424 of key server preferences. The registry includes the key server 4425 preference, the name of the preference, and a reference to the 4426 defining specification. The initial values for this registry can be 4427 found in Section 5.2.3.22. Adding a new key server preference MUST 4428 be done through the SPECIFICATION REQUIRED method, as described in 4429 [RFC8126]. 4431 10.2.2.4. Key Flags Extensions 4433 OpenPGP signatures contain a mechanism for flags to be specified 4434 about key usage. This specification creates a registry of key usage 4435 flags. The registry includes the key flags value, the name of the 4436 flag, and a reference to the defining specification. The initial 4437 values for this registry can be found in Section 5.2.3.26. Adding a 4438 new key usage flag MUST be done through the SPECIFICATION REQUIRED 4439 method, as described in [RFC8126]. 4441 10.2.2.5. Reason for Revocation Extensions 4443 OpenPGP signatures contain a mechanism for flags to be specified 4444 about why a key was revoked. This specification creates a registry 4445 of "Reason for Revocation" flags. The registry includes the "Reason 4446 for Revocation" flags value, the name of the flag, and a reference to 4447 the defining specification. The initial values for this registry can 4448 be found in Section 5.2.3.28. Adding a new feature flag MUST be done 4449 through the SPECIFICATION REQUIRED method, as described in [RFC8126]. 4451 10.2.2.6. Implementation Features 4453 OpenPGP signatures contain a mechanism for flags to be specified 4454 stating which optional features an implementation supports. This 4455 specification creates a registry of feature-implementation flags. 4456 The registry includes the feature-implementation flags value, the 4457 name of the flag, and a reference to the defining specification. The 4458 initial values for this registry can be found in Section 5.2.3.29. 4460 Adding a new feature-implementation flag MUST be done through the 4461 SPECIFICATION REQUIRED method, as described in [RFC8126]. 4463 Also see Section 14.11 for more information about when feature flags 4464 are needed. 4466 10.2.3. New Packet Versions 4468 The core OpenPGP packets all have version numbers, and can be revised 4469 by introducing a new version of an existing packet. This 4470 specification creates a registry of packet types. The registry 4471 includes the packet type, the number of the version, and a reference 4472 to the defining specification. The initial values for this registry 4473 can be found in Section 5. Adding a new packet version MUST be done 4474 through the RFC REQUIRED method, as described in [RFC8126]. 4476 10.3. New Algorithms 4478 Section 9 lists the core algorithms that OpenPGP uses. Adding in a 4479 new algorithm is usually simple. For example, adding in a new 4480 symmetric cipher usually would not need anything more than allocating 4481 a constant for that cipher. If that cipher had other than a 64-bit 4482 or 128-bit block size, there might need to be additional 4483 documentation describing how OpenPGP-CFB mode would be adjusted. 4484 Similarly, when DSA was expanded from a maximum of 1024-bit public 4485 keys to 3072-bit public keys, the revision of FIPS 186 contained 4486 enough information itself to allow implementation. Changes to this 4487 document were made mainly for emphasis. 4489 10.3.1. Public-Key Algorithms 4491 OpenPGP specifies a number of public-key algorithms. This 4492 specification creates a registry of public-key algorithm identifiers. 4493 The registry includes the algorithm name, its key sizes and 4494 parameters, and a reference to the defining specification. The 4495 initial values for this registry can be found in Section 9.1. Adding 4496 a new public-key algorithm MUST be done through the SPECIFICATION 4497 REQUIRED method, as described in [RFC8126]. 4499 This document requests IANA register the following new public-key 4500 algorithm: 4502 +====+============================+========================+ 4503 | ID | Algorithm | Reference | 4504 +====+============================+========================+ 4505 | 22 | EdDSA public key algorithm | This doc, Section 14.7 | 4506 +----+----------------------------+------------------------+ 4508 Table 24: New public-Key algorithms registered 4510 [ Note to RFC-Editor: Please remove the table above on publication. ] 4512 10.3.2. Symmetric-Key Algorithms 4514 OpenPGP specifies a number of symmetric-key algorithms. This 4515 specification creates a registry of symmetric-key algorithm 4516 identifiers. The registry includes the algorithm name, its key sizes 4517 and block size, and a reference to the defining specification. The 4518 initial values for this registry can be found in Section 9.3. Adding 4519 a new symmetric-key algorithm MUST be done through the SPECIFICATION 4520 REQUIRED method, as described in [RFC8126]. 4522 10.3.3. Hash Algorithms 4524 OpenPGP specifies a number of hash algorithms. This specification 4525 creates a registry of hash algorithm identifiers. The registry 4526 includes the algorithm name, a text representation of that name, its 4527 block size, an OID hash prefix, and a reference to the defining 4528 specification. The initial values for this registry can be found in 4529 Section 9.5 for the algorithm identifiers and text names, and 4530 Section 5.2.2 for the OIDs and expanded signature prefixes. Adding a 4531 new hash algorithm MUST be done through the SPECIFICATION REQUIRED 4532 method, as described in [RFC8126]. 4534 This document requests IANA register the following hash algorithms: 4536 +====+===========+===========+ 4537 | ID | Algorithm | Reference | 4538 +====+===========+===========+ 4539 | 12 | SHA3-256 | This doc | 4540 +----+-----------+-----------+ 4541 | 13 | Reserved | | 4542 +----+-----------+-----------+ 4543 | 14 | SHA3-512 | This doc | 4544 +----+-----------+-----------+ 4546 Table 25: New hash 4547 algorithms registered 4549 [Notes to RFC-Editor: Please remove the table above on publication. 4550 It is desirable not to reuse old or reserved algorithms because some 4551 existing tools might print a wrong description. The ID 13 has been 4552 reserved so that the SHA3 algorithm IDs align nicely with their SHA2 4553 counterparts.] 4555 10.3.4. Compression Algorithms 4557 OpenPGP specifies a number of compression algorithms. This 4558 specification creates a registry of compression algorithm 4559 identifiers. The registry includes the algorithm name and a 4560 reference to the defining specification. The initial values for this 4561 registry can be found in Section 9.4. Adding a new compression key 4562 algorithm MUST be done through the SPECIFICATION REQUIRED method, as 4563 described in [RFC8126]. 4565 10.3.5. Elliptic Curve Algorithms 4567 This document requests IANA add a registry of elliptic curves for use 4568 in OpenPGP. 4570 Each curve is identified on the wire by OID, and is acceptable for 4571 use in certain OpenPGP public key algorithms. The table's initial 4572 headings and values can be found in Section 9.2. Adding a new 4573 elliptic curve algorithm to OpenPGP MUST be done through the 4574 SPECIFICATION REQUIRED method, as described in [RFC8126]. If the new 4575 curve can be used for ECDH or EdDSA, it must also be added to the 4576 "Curve-specific wire formats" table described in Section 9.2.1. 4578 10.4. Elliptic Curve Point and Scalar Wire Formats 4580 This document requests IANA add a registry of wire formats that 4581 represent elliptic curve points. The table's initial headings and 4582 values can be found in Section 13.2. Adding a new EC point wire 4583 format MUST be done through the SPECIFICATION REQUIRED method, as 4584 described in [RFC8126]. 4586 This document also requests IANA add a registry of wire formats that 4587 represent scalars for use with elliptic curve cryptography. The 4588 table's initial headings and values can be found in Section 13.3. 4589 Adding a new EC scalar wire format MUST be done through the 4590 SPECIFICATION REQUIRED method, as described in [RFC8126]. 4592 This document also requests that IANA add a registry mapping curve- 4593 specific MPI octet-string encoding conventions for ECDH and EdDSA. 4594 The table's initial headings and values can be found in 4595 Section 9.2.1. Adding a new elliptic curve algorithm to OpenPGP MUST 4596 be done through the SPECIFICATION REQUIRED method, as described in 4597 [RFC8126], and requires adding an entry to this table if the curve is 4598 to be used with either EdDSA or ECDH. 4600 10.5. Changes to existing registries 4602 This document requests IANA add the following wire format columns to 4603 the OpenPGP public-key algorithm registry: 4605 * Public Key Format 4607 * Secret Key Format 4609 * Signature Format 4611 * PKESK Format 4613 And populate them with the values found in Section 9.1. 4615 11. Packet Composition 4617 OpenPGP packets are assembled into sequences in order to create 4618 messages and to transfer keys. Not all possible packet sequences are 4619 meaningful and correct. This section describes the rules for how 4620 packets should be placed into sequences. 4622 11.1. Transferable Public Keys 4624 OpenPGP users may transfer public keys. The essential elements of a 4625 transferable public key are as follows: 4627 * One Public-Key packet 4629 * Zero or more revocation signatures 4631 * Zero or more User ID packets 4633 * After each User ID packet, zero or more Signature packets 4634 (certifications) 4636 * Zero or more User Attribute packets 4638 * After each User Attribute packet, zero or more Signature packets 4639 (certifications) 4641 * Zero or more Subkey packets 4643 * After each Subkey packet, one Signature packet, plus optionally a 4644 revocation 4646 * An optional Padding packet 4648 The Public-Key packet occurs first. Each of the following User ID 4649 packets provides the identity of the owner of this public key. If 4650 there are multiple User ID packets, this corresponds to multiple 4651 means of identifying the same unique individual user; for example, a 4652 user may have more than one email address, and construct a User ID 4653 for each one. A transferable public key SHOULD include at least one 4654 User ID packet unless storage requirements prohibit this. 4656 Immediately following each User ID packet, there are zero or more 4657 Signature packets. Each Signature packet is calculated on the 4658 immediately preceding User ID packet and the initial Public-Key 4659 packet. The signature serves to certify the corresponding public key 4660 and User ID. In effect, the signer is testifying to his or her 4661 belief that this public key belongs to the user identified by this 4662 User ID. 4664 Within the same section as the User ID packets, there are zero or 4665 more User Attribute packets. Like the User ID packets, a User 4666 Attribute packet is followed by zero or more Signature packets 4667 calculated on the immediately preceding User Attribute packet and the 4668 initial Public-Key packet. 4670 User Attribute packets and User ID packets may be freely intermixed 4671 in this section, so long as the signatures that follow them are 4672 maintained on the proper User Attribute or User ID packet. 4674 After the User ID packet or Attribute packet, there may be zero or 4675 more Subkey packets. In general, subkeys are provided in cases where 4676 the top-level public key is a signature-only key. However, any V4 or 4677 V5 key may have subkeys, and the subkeys may be encryption-only keys, 4678 signature-only keys, or general-purpose keys. V3 keys MUST NOT have 4679 subkeys. 4681 Each Subkey packet MUST be followed by one Signature packet, which 4682 should be a subkey binding signature issued by the top-level key. 4683 For subkeys that can issue signatures, the subkey binding signature 4684 MUST contain an Embedded Signature subpacket with a primary key 4685 binding signature (0x19) issued by the subkey on the top-level key. 4687 Subkey and Key packets may each be followed by a revocation Signature 4688 packet to indicate that the key is revoked. Revocation signatures 4689 are only accepted if they are issued by the key itself, or by a key 4690 that is authorized to issue revocations via a Revocation Key 4691 subpacket in a self-signature by the top-level key. 4693 The optional trailing Padding packet is a mechanism to defend against 4694 traffic analysis (see Section 15.4). For maximum interoperability, 4695 if the Public-Key packet is a V4 key, the optional Padding packet 4696 SHOULD NOT be present unless the recipient has indicated that they 4697 are capable of ignoring it successfully. An implementation that is 4698 capable of receiving a transferable public key with a V5 Public-Key 4699 primary key MUST be able to accept (and ignore) the trailing optional 4700 Padding packet. 4702 Transferable public-key packet sequences may be concatenated to allow 4703 transferring multiple public keys in one operation. 4705 11.2. Transferable Secret Keys 4707 OpenPGP users may transfer secret keys. The format of a transferable 4708 secret key is the same as a transferable public key except that 4709 secret-key and secret-subkey packets are used instead of the public 4710 key and public-subkey packets. Implementations SHOULD include self- 4711 signatures on any User IDs and subkeys, as this allows for a complete 4712 public key to be automatically extracted from the transferable secret 4713 key. Implementations MAY choose to omit the self-signatures, 4714 especially if a transferable public key accompanies the transferable 4715 secret key. 4717 11.3. OpenPGP Messages 4719 An OpenPGP message is a packet or sequence of packets that 4720 corresponds to the following grammatical rules (comma represents 4721 sequential composition, and vertical bar separates alternatives): 4723 OpenPGP Message :- Encrypted Message | Signed Message | Compressed 4724 Message | Literal Message. 4726 Compressed Message :- Compressed Data Packet. 4728 Literal Message :- Literal Data Packet. 4730 ESK :- Public-Key Encrypted Session Key Packet | Symmetric-Key 4731 Encrypted Session Key Packet. 4733 ESK Sequence :- ESK | ESK Sequence, ESK. 4735 Encrypted Data :- Symmetrically Encrypted Data Packet | 4736 Symmetrically Encrypted Integrity Protected Data Packet 4738 Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data. 4740 One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP 4741 Message, Corresponding Signature Packet. 4743 Signed Message :- Signature Packet, OpenPGP Message | One-Pass 4744 Signed Message. 4746 Optionally Padded Message :- OpenPGP Message | OpenPGP Message, 4747 Padding Packet. 4749 11.3.1. Unwrapping Encrypted and Compressed Messages 4751 In addition to the above grammar, certain messages can be "unwrapped" 4752 to yield new messages. In particular: 4754 * Decrypting a version 2 Symmetrically Encrypted and Integrity 4755 Protected Data packet must yield a valid Optionally Padded 4756 Message. 4758 * Decrypting a version 1 Symmetrically Encrypted and Integrity 4759 Protected Data packet or --- for historic data --- a Symmetrically 4760 Encrypted Data packet must yield a valid OpenPGP Message. 4762 * Decompressing a Compressed Data packet must also yield a valid 4763 OpenPGP Message. 4765 When either such unwrapping is performed, the resulting stream of 4766 octets is parsed into a series OpenPGP packets like any other stream 4767 of octets. The packet boundaries found in the series of octets are 4768 expected to align with the length of the unwrapped octet stream. An 4769 implementation MUST NOT interpret octets beyond the boundaries of the 4770 unwrapped octet stream as part of any OpenPGP packet. If an 4771 implementation encounters a packet whose header length indicates that 4772 it would extend beyond the boundaries of the unwrapped octet stream, 4773 the implementation MUST reject that packet as malformed and unusable. 4775 11.3.2. Additional Constraints on Packet Sequences 4777 Note that some subtle combinations that are formally acceptable by 4778 this grammar are nonetheless unacceptable. 4780 11.3.2.1. Packet Versions in Encrypted Messages 4782 As noted above, an Encrypted Message is a sequence of zero or more 4783 PKESKs (Section 5.1) and SKESKs (Section 5.3), followed by an SEIPD 4784 (Section 5.14) payload. In some historic data, the payload may be a 4785 deprecated SED (Section 5.8) packet instead of SEIPD, though 4786 implementations MUST NOT generate SED packets (see Section 15.1). 4787 The versions of the preceding ESK packets within an Encrypted Message 4788 MUST align with the version of the payload SEIPD packet, as described 4789 in this section. 4791 v3 PKESK and v4 SKESK packets both contain in their cleartext the 4792 symmetric cipher algorithm identifier in addition to the session key 4793 for the subsequent SEIPD packet. Since a v1 SEIPD does not contain a 4794 symmetric algorithm identifier, so all ESK packets preceding a v1 4795 SEIPD payload MUST be either v3 PKESK or v4 SKESK. 4797 On the other hand, the cleartext of the v5 ESK packets (either PKESK 4798 or SKESK) do not contain a symmetric cipher algorithm identifier, so 4799 they cannot be used in combination with a v1 SEIPD payload. The 4800 payload following any v5 PKESK or v5 SKESK packet MUST be a v2 SEIPD. 4802 Additionally, to avoid potentially conflicting cipher algorithm 4803 identifiers, and for simplicity, implementations MUST NOT precede a 4804 v2 SEIPD payload with either v3 PKESK or v4 SKESK packets. 4806 The acceptable versions of packets in an Encrypted Message are 4807 summarized in the following table: 4809 +======================+======================+===================+ 4810 | Version of Encrypted | Version of preceding | Version of | 4811 | Data payload | Symmetric-Key ESK | preceding Public- | 4812 | | (if any) | Key ESK (if any) | 4813 +======================+======================+===================+ 4814 | v1 SEIPD | v4 SKESK | v3 PKESK | 4815 +----------------------+----------------------+-------------------+ 4816 | v2 SEIPD | v5 SKESK | v5 PKESK | 4817 +----------------------+----------------------+-------------------+ 4819 Table 26: Encrypted Message Packet Version Alignment 4821 An implementation processing an Encrypted Message MUST discard any 4822 preceding ESK packet with a version that does not align with the 4823 version of the payload. 4825 11.4. Detached Signatures 4827 Some OpenPGP applications use so-called "detached signatures". For 4828 example, a program bundle may contain a file, and with it a second 4829 file that is a detached signature of the first file. These detached 4830 signatures are simply a Signature packet stored separately from the 4831 data for which they are a signature. 4833 12. Enhanced Key Formats 4835 12.1. Key Structures 4837 The format of an OpenPGP V3 key is as follows. Entries in square 4838 brackets are optional and ellipses indicate repetition. 4840 RSA Public Key 4841 [Revocation Self Signature] 4842 User ID [Signature ...] 4843 [User ID [Signature ...] ...] 4845 Each signature certifies the RSA public key and the preceding User 4846 ID. The RSA public key can have many User IDs and each User ID can 4847 have many signatures. V3 keys are deprecated. Implementations MUST 4848 NOT generate new V3 keys, but MAY continue to use existing ones. 4850 The format of an OpenPGP V4 key that uses multiple public keys is 4851 similar except that the other keys are added to the end as "subkeys" 4852 of the primary key. 4854 Primary-Key 4855 [Revocation Self Signature] 4856 [Direct Key Signature...] 4857 [User ID [Signature ...] ...] 4858 [User Attribute [Signature ...] ...] 4859 [[Subkey [Binding-Signature-Revocation ...] 4860 Subkey-Binding-Signature ...] ...] 4862 A subkey always has at least one subkey binding signature after it 4863 that is issued using the primary key to tie the two keys together. 4864 These binding signatures may be in either V3 or V4 format, but SHOULD 4865 be V4. Subkeys that can issue signatures MUST have a V4 binding 4866 signature due to the REQUIRED embedded primary key binding signature. 4868 In order to create self-signatures (see Section 5.2.3.7), the primary 4869 key MUST be an algorithm capable of making signatures (that is, not 4870 an encryption-only algorithm). The subkeys may be keys of any type. 4871 For example, there may be a single-key RSA key, an EdDSA primary key 4872 with an RSA encryption key, or an EdDSA primary key with an ECDH 4873 subkey, etc. 4875 It is also possible to have a signature-only subkey. This permits a 4876 primary key that collects certifications (key signatures), but is 4877 used only for certifying subkeys that are used for encryption and 4878 signatures. 4880 12.2. Key IDs and Fingerprints 4882 For a V3 key, the eight-octet Key ID consists of the low 64 bits of 4883 the public modulus of the RSA key. 4885 The fingerprint of a V3 key is formed by hashing the body (but not 4886 the two-octet length) of the MPIs that form the key material (public 4887 modulus n, followed by exponent e) with MD5. Note that both V3 keys 4888 and MD5 are deprecated. 4890 A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, 4891 followed by the two-octet packet length, followed by the entire 4892 Public-Key packet starting with the version field. The Key ID is the 4893 low-order 64 bits of the fingerprint. Here are the fields of the 4894 hash material, with the example of an EdDSA key: 4896 a.1) 0x99 (1 octet) 4898 a.2) two-octet, big-endian scalar octet count of (b)-(e) 4900 b) version number = 4 (1 octet); 4902 c) timestamp of key creation (4 octets); 4904 d) algorithm (1 octet): 22 = EdDSA (example); 4906 e) Algorithm-specific fields. 4908 Algorithm-Specific Fields for EdDSA keys (example): 4910 e.1) A one-octet size of the following field; 4912 e.2) The octets representing a curve OID, defined in Section 9.2; 4914 e.3) An MPI of an EC point representing a public key Q in prefixed 4915 native form (see Section 13.2.2). 4917 A V5 fingerprint is the 256-bit SHA2-256 hash of the octet 0x9A, 4918 followed by the four-octet packet length, followed by the entire 4919 Public-Key packet starting with the version field. The Key ID is the 4920 high-order 64 bits of the fingerprint. Here are the fields of the 4921 hash material, with the example of an EdDSA key: 4923 a.1) 0x9A (1 octet) 4925 a.2) four-octet scalar octet count of (b)-(f) 4927 b) version number = 5 (1 octet); 4929 c) timestamp of key creation (4 octets); 4931 d) algorithm (1 octet): 22 = EdDSA (example); 4933 e) four-octet scalar octet count for the following key material; 4935 f) algorithm-specific fields. 4937 Algorithm-Specific Fields for EdDSA keys (example): 4939 f.1) A one-octet size of the following field; 4941 f.2) The octets representing a curve OID, defined in Section 9.2; 4943 f.3) An MPI of an EC point representing a public key Q in prefixed 4944 native form (see Section 13.2.2). 4946 Note that it is possible for there to be collisions of Key IDs --- 4947 two different keys with the same Key ID. Note that there is a much 4948 smaller, but still non-zero, probability that two different keys have 4949 the same fingerprint. 4951 Also note that if V3, V4, and V5 format keys share the same RSA key 4952 material, they will have different Key IDs as well as different 4953 fingerprints. 4955 Finally, the Key ID and fingerprint of a subkey are calculated in the 4956 same way as for a primary key, including the 0x99 (V4 key) or 0x9A 4957 (V5 key) as the first octet (even though this is not a valid packet 4958 ID for a public subkey). 4960 13. Elliptic Curve Cryptography 4962 This section describes algorithms and parameters used with Elliptic 4963 Curve Cryptography (ECC) keys. A thorough introduction to ECC can be 4964 found in [KOBLITZ]. 4966 None of the ECC methods described in this document are allowed with 4967 deprecated V3 keys. Refer to [FIPS186], B.4.1, for the method to 4968 generate a uniformly distributed ECC private key. 4970 13.1. Supported ECC Curves 4972 This document references three named prime field curves defined in 4973 [FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521". These 4974 three [FIPS186] curves can be used with ECDSA and ECDH public key 4975 algorithms. Additionally, curve "Curve25519" and "Curve448" are 4976 referenced for use with Ed25519 and Ed448 (EdDSA signing, see 4977 [RFC8032]); and X25519 and X448 (ECDH encryption, see [RFC7748]). 4979 The named curves are referenced as a sequence of octets in this 4980 document, called throughout, curve OID. Section 9.2 describes in 4981 detail how this sequence of octets is formed. 4983 13.2. EC Point Wire Formats 4985 A point on an elliptic curve will always be represented on the wire 4986 as an MPI. Each curve uses a specific point format for the data 4987 within the MPI itself. Each format uses a designated prefix octet to 4988 ensure that the high octet has at least one bit set to make the MPI a 4989 constant size. 4991 +=================+================+================+ 4992 | Name | Wire Format | Reference | 4993 +=================+================+================+ 4994 | SEC1 | 0x04 || x || y | Section 13.2.1 | 4995 +-----------------+----------------+----------------+ 4996 | Prefixed native | 0x40 || native | Section 13.2.2 | 4997 +-----------------+----------------+----------------+ 4999 Table 27: Elliptic Curve Point Wire Formats 5001 13.2.1. SEC1 EC Point Wire Format 5003 For a SEC1-encoded (uncompressed) point the content of the MPI is: 5005 B = 04 || x || y 5007 where x and y are coordinates of the point P = (x, y), and each is 5008 encoded in the big-endian format and zero-padded to the adjusted 5009 underlying field size. The adjusted underlying field size is the 5010 underlying field size rounded up to the nearest 8-bit boundary, as 5011 noted in the "fsize" column in Section 9.2. This encoding is 5012 compatible with the definition given in [SEC1]. 5014 13.2.2. Prefixed Native EC Point Wire Format 5016 For a custom compressed point the content of the MPI is: 5018 B = 40 || p 5020 where p is the public key of the point encoded using the rules 5021 defined for the specified curve. This format is used for ECDH keys 5022 based on curves expressed in Montgomery form, and for points when 5023 using EdDSA. 5025 13.2.3. Notes on EC Point Wire Formats 5027 Given the above definitions, the exact size of the MPI payload for an 5028 encoded point is 515 bits for "Curve P-256", 771 for "Curve P-384", 5029 1059 for "Curve P-521", 263 for both "Curve25519" and "Ed25519", 463 5030 for "Ed448", and 455 for "X448". For example, the length of a EdDSA 5031 public key for the curve Ed25519 is 263 bits: 7 bits to represent the 5032 0x40 prefix octet and 32 octets for the native value of the public 5033 key. 5035 Even though the zero point, also called the point at infinity, may 5036 occur as a result of arithmetic operations on points of an elliptic 5037 curve, it SHALL NOT appear in data structures defined in this 5038 document. 5040 Each particular curve uses a designated wire format for the point 5041 found in its public key or ECDH data structure. An implementation 5042 MUST NOT use a different wire format for a point than the wire format 5043 associated with the curve. 5045 13.3. EC Scalar Wire Formats 5047 Some non-curve values in elliptic curve cryptography (for example, 5048 secret keys and signature components) are not points on a curve, but 5049 are also encoded on the wire in OpenPGP as an MPI. 5051 Because of different patterns of deployment, some curves treat these 5052 values as opaque bit strings with the high bit set, while others are 5053 treated as actual integers, encoded in the standard OpenPGP big- 5054 endian form. The choice of encoding is specific to the public key 5055 algorithm in use. 5057 +==========+=====================================+===========+ 5058 | Type | Description | Reference | 5059 +==========+=====================================+===========+ 5060 | integer | An integer, big-endian encoded as a | Section | 5061 | | standard OpenPGP MPI | 3.2 | 5062 +----------+-------------------------------------+-----------+ 5063 | octet | An octet string of fixed length, | Section | 5064 | string | that may be shorter on the wire due | 13.3.1 | 5065 | | to leading zeros being stripped by | | 5066 | | the MPI encoding, and may need to | | 5067 | | be zero-padded before usage | | 5068 +----------+-------------------------------------+-----------+ 5069 | prefixed | An octet string of fixed length N, | Section | 5070 | N octets | prefixed with octet 0x40 to ensure | 13.3.2 | 5071 | | no leading zero octet | | 5072 +----------+-------------------------------------+-----------+ 5074 Table 28: Elliptic Curve Scalar Encodings 5076 13.3.1. EC Octet String Wire Format 5078 Some opaque strings of octets are represented on the wire as an MPI 5079 by simply stripping the leading zeros and counting the remaining 5080 bits. These strings are of known, fixed length. They are 5081 represented in this document as MPI(N octets of X) where N is the 5082 expected length in octets of the octet string. 5084 For example, a five-octet opaque string (MPI(5 octets of X)) where X 5085 has the value 00 02 ee 19 00 would be represented on the wire as an 5086 MPI like so: 00 1a 02 ee 19 00. 5088 To encode X to the wire format, we set the MPI's two-octet bit 5089 counter to the value of the highest set bit (bit 26, or 0x001a), and 5090 do not transfer the leading all-zero octet to the wire. 5092 To reverse the process, an implementation that knows this value has 5093 an expected length of 5 octets can take the following steps: 5095 * ensure that the MPI's two-octet bitcount is less than or equal to 5096 40 (5 octets of 8 bits) 5098 * allocate 5 octets, setting all to zero initially 5100 * copy the MPI data octets (without the two count octets) into the 5101 lower octets of the allocated space 5103 13.3.2. Elliptic Curve Prefixed Octet String Wire Format 5105 Another way to ensure that a fixed-length bytestring is encoded 5106 simply to the wire while remaining in MPI format is to prefix the 5107 bytestring with a dedicated non-zero octet. This specification uses 5108 0x40 as the prefix octet. This is represented in this standard as 5109 MPI(prefixed N octets of X), where N is the known bytestring length. 5111 For example, a five-octet opaque string using MPI(prefixed 5 octets 5112 of X) where X has the value 00 02 ee 19 00 would be written to the 5113 wire form as: 00 2f 40 00 02 ee 19 00. 5115 To encode the string, we prefix it with the octet 0x40 (whose 7th bit 5116 is set), then set the MPI's two-octet bit counter to 47 (0x002f, 7 5117 bits for the prefix octet and 40 bits for the string). 5119 To decode the string from the wire, an implementation that knows that 5120 the variable is formed in this way can: 5122 * ensure that the first three octets of the MPI (the two bit-count 5123 octets plus the prefix octet) are 00 2f 40, and 5125 * use the remainder of the MPI directly off the wire. 5127 Note that this is a similar approach to that used in the EC point 5128 encodings found in Section 13.2.2. 5130 13.4. Key Derivation Function 5132 A key derivation function (KDF) is necessary to implement EC 5133 encryption. The Concatenation Key Derivation Function (Approved 5134 Alternative 1) [SP800-56A] with the KDF hash function that is 5135 SHA2-256 [FIPS180] or stronger is REQUIRED. 5137 For convenience, the synopsis of the encoding method is given below 5138 with significant simplifications attributable to the restricted 5139 choice of hash functions in this document. However, [SP800-56A] is 5140 the normative source of the definition. 5142 // Implements KDF( X, oBits, Param ); 5143 // Input: point X = (x,y) 5144 // oBits - the desired size of output 5145 // hBits - the size of output of hash function Hash 5146 // Param - octets representing the parameters 5147 // Assumes that oBits <= hBits 5148 // Convert the point X to the octet string: 5149 // ZB' = 04 || x || y 5150 // and extract the x portion from ZB' 5151 ZB = x; 5152 MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param ); 5153 return oBits leftmost bits of MB. 5155 Note that ZB in the KDF description above is the compact 5156 representation of X as defined in Section 4.2 of [RFC6090]. 5158 13.5. EC DH Algorithm (ECDH) 5160 The method is a combination of an ECC Diffie-Hellman method to 5161 establish a shared secret, a key derivation method to process the 5162 shared secret into a derived key, and a key wrapping method that uses 5163 the derived key to protect a session key used to encrypt a message. 5165 The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [SP800-56A] MUST 5166 be implemented with the following restrictions: the ECC CDH primitive 5167 employed by this method is modified to always assume the cofactor is 5168 1, the KDF specified in Section 13.4 is used, and the KDF parameters 5169 specified below are used. 5171 The KDF parameters are encoded as a concatenation of the following 5 5172 variable-length and fixed-length fields, which are compatible with 5173 the definition of the OtherInfo bitstring [SP800-56A]: 5175 * A variable-length field containing a curve OID, which is formatted 5176 as follows: 5178 - A one-octet size of the following field, 5180 - The octets representing a curve OID defined in Section 9.2; 5182 * A one-octet public key algorithm ID defined in Section 9.1; 5184 * A variable-length field containing KDF parameters, which are 5185 identical to the corresponding field in the ECDH public key, and 5186 are formatted as follows: 5188 - A one-octet size of the following fields; values 0 and 0xFF are 5189 reserved for future extensions, 5191 - A one-octet value 0x01, reserved for future extensions, 5193 - A one-octet hash function ID used with the KDF, 5195 - A one-octet algorithm ID for the symmetric algorithm used to 5196 wrap the symmetric key for message encryption; see Section 13.5 5197 for details; 5199 * 20 octets representing the UTF-8 encoding of the string Anonymous 5200 Sender , which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 5201 20 53 65 6E 64 65 72 20 20 20 20; 5203 * A variable-length field containing the fingerprint of the 5204 recipient encryption subkey or a primary key fingerprint 5205 identifying the key material that is needed for decryption. For 5206 version 4 keys, this field is 20 octets. For version 5 keys, this 5207 field is 32 octets. 5209 The size in octets of the KDF parameters sequence, defined above, for 5210 encrypting to a v4 key is either 54 for curve P-256, 51 for curves 5211 P-384 and P-521, 56 for Curve25519, or 49 for X448. For encrypting 5212 to a v5 key, the size of the sequence is either 66 for curve P-256, 5213 63 for curves P-384 and P-521, 68 for Curve25519, or 61 for X448. 5215 The key wrapping method is described in [RFC3394]. The KDF produces 5216 a symmetric key that is used as a key-encryption key (KEK) as 5217 specified in [RFC3394]. Refer to Section 15 for the details 5218 regarding the choice of the KEK algorithm, which SHOULD be one of 5219 three AES algorithms. Key wrapping and unwrapping is performed with 5220 the default initial value of [RFC3394]. 5222 The input to the key wrapping method is the plaintext described in 5223 Section 5.1, "Public-Key Encrypted Session Key Packets (Tag 1)", 5224 padded using the method described in [PKCS5] to an 8-octet 5225 granularity. 5227 For example, in a V4 Public-Key Encrypted Session Key packet, the 5228 following AES-256 session key, in which 32 octets are denoted from k0 5229 to k31, is composed to form the following 40 octet sequence: 5231 09 k0 k1 ... k31 s0 s1 05 05 05 05 05 5232 The octets s0 and s1 above denote the checksum of the session key 5233 octets. This encoding allows the sender to obfuscate the size of the 5234 symmetric encryption key used to encrypt the data. For example, 5235 assuming that an AES algorithm is used for the session key, the 5236 sender MAY use 21, 13, and 5 octets of padding for AES-128, AES-192, 5237 and AES-256, respectively, to provide the same number of octets, 40 5238 total, as an input to the key wrapping method. 5240 In a V5 Public-Key Encrypted Session Key packet, the symmetric 5241 algorithm is not included, as described in Section 5.1. For example, 5242 an AES-256 session key would be composed as follows: 5244 k0 k1 ... k31 s0 s1 06 06 06 06 06 06 5246 The octets k0 to k31 above again denote the session key, and the 5247 octets s0 and s1 denote the checksum. In this case, assuming that an 5248 AES algorithm is used for the session key, the sender MAY use 22, 14, 5249 and 6 octets of padding for AES-128, AES-192, and AES-256, 5250 respectively, to provide the same number of octets, 40 total, as an 5251 input to the key wrapping method. 5253 The output of the method consists of two fields. The first field is 5254 the MPI containing the ephemeral key used to establish the shared 5255 secret. The second field is composed of the following two subfields: 5257 * One octet encoding the size in octets of the result of the key 5258 wrapping method; the value 255 is reserved for future extensions; 5260 * Up to 254 octets representing the result of the key wrapping 5261 method, applied to the 8-octet padded session key, as described 5262 above. 5264 Note that for session key sizes 128, 192, and 256 bits, the size of 5265 the result of the key wrapping method is, respectively, 32, 40, and 5266 48 octets, unless size obfuscation is used. 5268 For convenience, the synopsis of the encoding method is given below; 5269 however, this section, [SP800-56A], and [RFC3394] are the normative 5270 sources of the definition. 5272 * Obtain the authenticated recipient public key R 5274 * Generate an ephemeral key pair {v, V=vG} 5276 * Compute the shared point S = vR; 5278 * m = symm_alg_ID || session key || checksum || pkcs5_padding; 5279 * curve_OID_len = (octet)len(curve_OID); 5281 * Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || 5282 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || Anonymous 5283 Sender || recipient_fingerprint; 5285 * Z_len = the key size for the KEK_alg_ID used with AESKeyWrap 5287 * Compute Z = KDF( S, Z_len, Param ); 5289 * Compute C = AESKeyWrap( Z, m ) as per [RFC3394] 5291 * VB = convert point V to the octet string 5293 * Output (MPI(VB) || len(C) || C). 5295 The decryption is the inverse of the method given. Note that the 5296 recipient obtains the shared secret by calculating 5298 S = rV = rvG, where (r,R) is the recipient's key pair. 5300 Consistent with Section 5.14, AEAD encryption or a Modification 5301 Detection Code (MDC) MUST be used anytime the symmetric key is 5302 protected by ECDH. 5304 14. Notes on Algorithms 5306 14.1. PKCS#1 Encoding in OpenPGP 5308 This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and 5309 EMSA-PKCS1-v1_5. However, the calling conventions of these functions 5310 has changed in the past. To avoid potential confusion and 5311 interoperability problems, we are including local copies in this 5312 document, adapted from those in PKCS#1 v2.1 [RFC8017]. [RFC8017] 5313 should be treated as the ultimate authority on PKCS#1 for OpenPGP. 5314 Nonetheless, we believe that there is value in having a self- 5315 contained document that avoids problems in the future with needed 5316 changes in the conventions. 5318 14.1.1. EME-PKCS1-v1_5-ENCODE 5320 Input: 5322 k = the length in octets of the key modulus. 5324 M = message to be encoded, an octet string of length mLen, where 5325 mLen <= k - 11. 5327 Output: 5329 EM = encoded message, an octet string of length k. 5331 Error: "message too long". 5333 1. Length checking: If mLen > k - 11, output "message too long" and 5334 stop. 5336 2. Generate an octet string PS of length k - mLen - 3 consisting of 5337 pseudo-randomly generated nonzero octets. The length of PS will 5338 be at least eight octets. 5340 3. Concatenate PS, the message M, and other padding to form an 5341 encoded message EM of length k octets as 5343 EM = 0x00 || 0x02 || PS || 0x00 || M. 5345 4. Output EM. 5347 14.1.2. EME-PKCS1-v1_5-DECODE 5349 Input: 5351 EM = encoded message, an octet string 5353 Output: 5355 M = message, an octet string. 5357 Error: "decryption error". 5359 To decode an EME-PKCS1_v1_5 message, separate the encoded message EM 5360 into an octet string PS consisting of nonzero octets and a message M 5361 as follows 5363 EM = 0x00 || 0x02 || PS || 0x00 || M. 5365 If the first octet of EM does not have hexadecimal value 0x00, if the 5366 second octet of EM does not have hexadecimal value 0x02, if there is 5367 no octet with hexadecimal value 0x00 to separate PS from M, or if the 5368 length of PS is less than 8 octets, output "decryption error" and 5369 stop. See also the security note in Section 15 regarding differences 5370 in reporting between a decryption error and a padding error. 5372 14.1.3. EMSA-PKCS1-v1_5 5374 This encoding method is deterministic and only has an encoding 5375 operation. 5377 Option: 5379 Hash - a hash function in which hLen denotes the length in octets of 5380 the hash function output. 5382 Input: 5384 M = message to be encoded. 5386 emLen = intended length in octets of the encoded message, at least 5387 tLen + 11, where tLen is the octet length of the DER encoding T of 5388 a certain value computed during the encoding operation. 5390 Output: 5392 EM = encoded message, an octet string of length emLen. 5394 Errors: "message too long"; "intended encoded message length too 5395 short". 5397 Steps: 5399 1. Apply the hash function to the message M to produce a hash value 5400 H: 5402 H = Hash(M). 5404 If the hash function outputs "message too long," output "message 5405 too long" and stop. 5407 2. Using the list in Section 5.2.2, produce an ASN.1 DER value for 5408 the hash function used. Let T be the full hash prefix from the 5409 list, and let tLen be the length in octets of T. 5411 3. If emLen < tLen + 11, output "intended encoded message length too 5412 short" and stop. 5414 4. Generate an octet string PS consisting of emLen - tLen - 3 octets 5415 with hexadecimal value 0xFF. The length of PS will be at least 8 5416 octets. 5418 5. Concatenate PS, the hash prefix T, and other padding to form the 5419 encoded message EM as 5421 EM = 0x00 || 0x01 || PS || 0x00 || T. 5423 6. Output EM. 5425 14.2. Symmetric Algorithm Preferences 5427 The symmetric algorithm preference is an ordered list of algorithms 5428 that the keyholder accepts. Since it is found on a self-signature, 5429 it is possible that a keyholder may have multiple, different 5430 preferences. For example, Alice may have AES-128 only specified for 5431 "alice@work.com" but Camellia-256, Twofish, and AES-128 specified for 5432 "alice@home.org". Note that it is also possible for preferences to 5433 be in a subkey's binding signature. 5435 Since AES-128 is the MUST-implement algorithm, if it is not 5436 explicitly in the list, it is tacitly at the end. However, it is 5437 good form to place it there explicitly. Note also that if an 5438 implementation does not implement the preference, then it is 5439 implicitly an AES-128-only implementation. Note further that 5440 implementations conforming to previous versions of this standard 5441 [RFC4880] have TripleDES as its only MUST-implement algorithm. 5443 An implementation MUST NOT use a symmetric algorithm that is not in 5444 the recipient's preference list. When encrypting to more than one 5445 recipient, the implementation finds a suitable algorithm by taking 5446 the intersection of the preferences of the recipients. Note that the 5447 MUST-implement algorithm, AES-128, ensures that the intersection is 5448 not null. The implementation may use any mechanism to pick an 5449 algorithm in the intersection. 5451 If an implementation can decrypt a message that a keyholder doesn't 5452 have in their preferences, the implementation SHOULD decrypt the 5453 message anyway, but MUST warn the keyholder that the protocol has 5454 been violated. For example, suppose that Alice, above, has software 5455 that implements all algorithms in this specification. Nonetheless, 5456 she prefers subsets for work or home. If she is sent a message 5457 encrypted with IDEA, which is not in her preferences, the software 5458 warns her that someone sent her an IDEA-encrypted message, but it 5459 would ideally decrypt it anyway. 5461 14.2.1. Plaintext 5463 Algorithm 0, "plaintext", may only be used to denote secret keys that 5464 are stored in the clear. Implementations MUST NOT use plaintext in 5465 encrypted data packets; they must use Literal Data packets to encode 5466 unencrypted literal data. 5468 14.3. Other Algorithm Preferences 5470 Other algorithm preferences work similarly to the symmetric algorithm 5471 preference, in that they specify which algorithms the keyholder 5472 accepts. There are two interesting cases that other comments need to 5473 be made about, though, the compression preferences and the hash 5474 preferences. 5476 14.3.1. Compression Preferences 5478 Like the algorithm preferences, an implementation MUST NOT use an 5479 algorithm that is not in the preference vector. If Uncompressed (0) 5480 is not explicitly in the list, it is tacitly at the end. That is, 5481 uncompressed messages may always be sent. 5483 Note that earlier implementations may assume that the absence of 5484 compression preferences means that [ZIP(1), Uncompressed(0)] are 5485 preferred, and default to ZIP compression. Therefore, an 5486 implementation that prefers uncompressed data SHOULD explicitly state 5487 this in the preferred compression algorithms. 5489 14.3.1.1. Uncompressed 5491 Algorithm 0, "uncompressed", may only be used to denote a preference 5492 for uncompressed data. Implementations MUST NOT use uncompressed in 5493 Compressed Data packets; they must use Literal Data packets to encode 5494 uncompressed literal data. 5496 14.3.2. Hash Algorithm Preferences 5498 Typically, the choice of a hash algorithm is something the signer 5499 does, rather than the verifier, because a signer rarely knows who is 5500 going to be verifying the signature. This preference, though, allows 5501 a protocol based upon digital signatures ease in negotiation. 5503 Thus, if Alice is authenticating herself to Bob with a signature, it 5504 makes sense for her to use a hash algorithm that Bob's software uses. 5505 This preference allows Bob to state in his key which algorithms Alice 5506 may use. 5508 Since SHA2-256 is the MUST-implement hash algorithm, if it is not 5509 explicitly in the list, it is tacitly at the end. However, it is 5510 good form to place it there explicitly. 5512 14.4. RSA 5514 There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only 5515 keys. These types are deprecated. The "key flags" subpacket in a 5516 signature is a much better way to express the same idea, and 5517 generalizes it to all algorithms. An implementation SHOULD NOT 5518 create such a key, but MAY interpret it. 5520 An implementation SHOULD NOT implement RSA keys of size less than 5521 1024 bits. 5523 14.5. DSA 5525 An implementation SHOULD NOT implement DSA keys of size less than 5526 1024 bits. It MUST NOT implement a DSA key with a q size of less 5527 than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the 5528 q size MUST be a multiple of 8 bits. The Digital Signature Standard 5529 (DSS) [FIPS186] specifies that DSA be used in one of the following 5530 ways: 5532 * 1024-bit key, 160-bit q, SHA-1, SHA2-224, SHA2-256, SHA2-384, or 5533 SHA2-512 hash 5535 * 2048-bit key, 224-bit q, SHA2-224, SHA2-256, SHA2-384, or SHA2-512 5536 hash 5538 * 2048-bit key, 256-bit q, SHA2-256, SHA2-384, or SHA2-512 hash 5540 * 3072-bit key, 256-bit q, SHA2-256, SHA2-384, or SHA2-512 hash 5542 The above key and q size pairs were chosen to best balance the 5543 strength of the key with the strength of the hash. Implementations 5544 SHOULD use one of the above key and q size pairs when generating DSA 5545 keys. If DSS compliance is desired, one of the specified SHA hashes 5546 must be used as well. [FIPS186] is the ultimate authority on DSS, 5547 and should be consulted for all questions of DSS compliance. 5549 Note that earlier versions of this standard only allowed a 160-bit q 5550 with no truncation allowed, so earlier implementations may not be 5551 able to handle signatures with a different q size or a truncated 5552 hash. 5554 14.6. Elgamal 5556 An implementation SHOULD NOT implement Elgamal keys of size less than 5557 1024 bits. 5559 14.7. EdDSA 5561 Although the EdDSA algorithm allows arbitrary data as input, its use 5562 with OpenPGP requires that a digest of the message is used as input 5563 (pre-hashed). See Section 5.2.4 for details. Truncation of the 5564 resulting digest is never applied; the resulting digest value is used 5565 verbatim as input to the EdDSA algorithm. 5567 For clarity: while [RFC8032] describes different variants of EdDSA, 5568 OpenPGP uses the "pure" variant (PureEdDSA). The hashing that 5569 happens with OpenPGP is done as part of the standard OpenPGP 5570 signature process, and that hash itself is fed as the input message 5571 to the PureEdDSA algorithm. 5573 As specified in [RFC8032], Ed448 also expects a "context string". In 5574 OpenPGP, Ed448 is used with the empty string as a context string. 5576 14.8. Reserved Algorithm Numbers 5578 A number of algorithm IDs have been reserved for algorithms that 5579 would be useful to use in an OpenPGP implementation, yet there are 5580 issues that prevent an implementer from actually implementing the 5581 algorithm. These are marked in Section 9.1 as "reserved for". 5583 The reserved public-key algorithm X9.42 (21) does not have the 5584 necessary parameters, parameter order, or semantics defined. The 5585 same is currently true for reserved public-key algorithms AEDH (23) 5586 and AEDSA (24). 5588 Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures 5589 with a public-key identifier of 20. These are no longer permitted. 5590 An implementation MUST NOT generate such keys. An implementation 5591 MUST NOT generate Elgamal signatures. See [BLEICHENBACHER]. 5593 14.9. OpenPGP CFB Mode 5595 When using a version 1 Symmetrically Encrypted Integrity Protected 5596 Data packet (Section 5.14.1) or --- for historic data --- a 5597 Symmetrically Encrypted Data packet (Section 5.8), OpenPGP does 5598 symmetric encryption using a variant of Cipher Feedback mode (CFB 5599 mode). This section describes the procedure it uses in detail. This 5600 mode is what is used for Symmetrically Encrypted Integrity Protected 5601 Data Packets (and the dangerously malleable --- and deprecated --- 5602 Symmetrically Encrypted Data Packets). Some mechanisms for 5603 encrypting secret-key material also use CFB mode, as described in 5604 Section 3.7.2.1. 5606 In the description below, the value BS is the block size in octets of 5607 the cipher. Most ciphers have a block size of 8 octets. The AES and 5608 Twofish have a block size of 16 octets. Also note that the 5609 description below assumes that the IV and CFB arrays start with an 5610 index of 1 (unlike the C language, which assumes arrays start with a 5611 zero index). 5613 OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and 5614 prefixes the plaintext with BS+2 octets of random data, such that 5615 octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB 5616 resynchronization after encrypting those BS+2 octets. 5618 Thus, for an algorithm that has a block size of 8 octets (64 bits), 5619 the IV is 10 octets long and octets 7 and 8 of the IV are the same as 5620 octets 9 and 10. For an algorithm with a block size of 16 octets 5621 (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate 5622 octets 15 and 16. Those extra two octets are an easy check for a 5623 correct key. 5625 Step by step, here is the procedure: 5627 1. The feedback register (FR) is set to the IV, which is all zeros. 5629 2. FR is encrypted to produce FRE (FR Encrypted). This is the 5630 encryption of an all-zero value. 5632 3. FRE is xored with the first BS octets of random data prefixed to 5633 the plaintext to produce C[1] through C[BS], the first BS octets 5634 of ciphertext. 5636 4. FR is loaded with C[1] through C[BS]. 5638 5. FR is encrypted to produce FRE, the encryption of the first BS 5639 octets of ciphertext. 5641 6. The left two octets of FRE get xored with the next two octets of 5642 data that were prefixed to the plaintext. This produces C[BS+1] 5643 and C[BS+2], the next two octets of ciphertext. 5645 7. (The resynchronization step) FR is loaded with C[3] through 5646 C[BS+2]. 5648 8. FR is encrypted to produce FRE. 5650 9. FRE is xored with the first BS octets of the given plaintext, 5651 now that we have finished encrypting the BS+2 octets of prefixed 5652 data. This produces C[BS+3] through C[BS+(BS+2)], the next BS 5653 octets of ciphertext. 5655 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 5656 for an 8-octet block). 5658 11. FR is encrypted to produce FRE. 5660 12. FRE is xored with the next BS octets of plaintext, to produce 5661 the next BS octets of ciphertext. These are loaded into FR, and 5662 the process is repeated until the plaintext is used up. 5664 14.10. Private or Experimental Parameters 5666 S2K specifiers, Signature subpacket types, User Attribute types, 5667 image format types, and algorithms described in Section 9 all reserve 5668 the range 100 to 110 for private and experimental use. Packet types 5669 reserve the range 60 to 63 for private and experimental use. These 5670 are intentionally managed with the PRIVATE USE method, as described 5671 in [RFC8126]. 5673 However, implementations need to be careful with these and promote 5674 them to full IANA-managed parameters when they grow beyond the 5675 original, limited system. 5677 14.11. Meta-Considerations for Expansion 5679 If OpenPGP is extended in a way that is not backwards-compatible, 5680 meaning that old implementations will not gracefully handle their 5681 absence of a new feature, the extension proposal can be declared in 5682 the key holder's self-signature as part of the Features signature 5683 subpacket. 5685 We cannot state definitively what extensions will not be upwards- 5686 compatible, but typically new algorithms are upwards-compatible, 5687 whereas new packets are not. 5689 If an extension proposal does not update the Features system, it 5690 SHOULD include an explanation of why this is unnecessary. If the 5691 proposal contains neither an extension to the Features system nor an 5692 explanation of why such an extension is unnecessary, the proposal 5693 SHOULD be rejected. 5695 15. Security Considerations 5697 * As with any technology involving cryptography, you should check 5698 the current literature to determine if any algorithms used here 5699 have been found to be vulnerable to attack. 5701 * This specification uses Public-Key Cryptography technologies. It 5702 is assumed that the private key portion of a public-private key 5703 pair is controlled and secured by the proper party or parties. 5705 * The MD5 hash algorithm has been found to have weaknesses, with 5706 collisions found in a number of cases. MD5 is deprecated for use 5707 in OpenPGP. Implementations MUST NOT generate new signatures 5708 using MD5 as a hash function. They MAY continue to consider old 5709 signatures that used MD5 as valid. 5711 * SHA2-224 and SHA2-384 require the same work as SHA2-256 and 5712 SHA2-512, respectively. In general, there are few reasons to use 5713 them outside of DSS compatibility. You need a situation where one 5714 needs more security than smaller hashes, but does not want to have 5715 the full 256-bit or 512-bit data length. 5717 * Many security protocol designers think that it is a bad idea to 5718 use a single key for both privacy (encryption) and integrity 5719 (signatures). In fact, this was one of the motivating forces 5720 behind the V4 key format with separate signature and encryption 5721 keys. If you as an implementer promote dual-use keys, you should 5722 at least be aware of this controversy. 5724 * The DSA algorithm will work with any hash, but is sensitive to the 5725 quality of the hash algorithm. Verifiers should be aware that 5726 even if the signer used a strong hash, an attacker could have 5727 modified the signature to use a weak one. Only signatures using 5728 acceptably strong hash algorithms should be accepted as valid. 5730 * As OpenPGP combines many different asymmetric, symmetric, and hash 5731 algorithms, each with different measures of strength, care should 5732 be taken that the weakest element of an OpenPGP message is still 5733 sufficiently strong for the purpose at hand. While consensus 5734 about the strength of a given algorithm may evolve, NIST Special 5735 Publication 800-57 [SP800-57] recommends the following list of 5736 equivalent strengths: 5738 +=====================+===========+====================+ 5739 | Asymmetric key size | Hash size | Symmetric key size | 5740 +=====================+===========+====================+ 5741 | 1024 | 160 | 80 | 5742 +---------------------+-----------+--------------------+ 5743 | 2048 | 224 | 112 | 5744 +---------------------+-----------+--------------------+ 5745 | 3072 | 256 | 128 | 5746 +---------------------+-----------+--------------------+ 5747 | 7680 | 384 | 192 | 5748 +---------------------+-----------+--------------------+ 5749 | 15360 | 512 | 256 | 5750 +---------------------+-----------+--------------------+ 5752 Table 29: Key length equivalences 5754 * There is a somewhat-related potential security problem in 5755 signatures. If an attacker can find a message that hashes to the 5756 same hash with a different algorithm, a bogus signature structure 5757 can be constructed that evaluates correctly. 5759 For example, suppose Alice DSA signs message M using hash 5760 algorithm H. Suppose that Mallet finds a message M' that has the 5761 same hash value as M with H'. Mallet can then construct a 5762 signature block that verifies as Alice's signature of M' with H'. 5763 However, this would also constitute a weakness in either H or H' 5764 or both. Should this ever occur, a revision will have to be made 5765 to this document to revise the allowed hash algorithms. 5767 * If you are building an authentication system, the recipient may 5768 specify a preferred signing algorithm. However, the signer would 5769 be foolish to use a weak algorithm simply because the recipient 5770 requests it. 5772 * Some of the encryption algorithms mentioned in this document have 5773 been analyzed less than others. For example, although CAST5 is 5774 presently considered strong, it has been analyzed less than 5775 TripleDES. Other algorithms may have other controversies 5776 surrounding them. 5778 * In late summer 2002, Jallad, Katz, and Schneier published an 5779 interesting attack on older versions of the OpenPGP protocol and 5780 some of its implementations [JKS02]. In this attack, the attacker 5781 modifies a message and sends it to a user who then returns the 5782 erroneously decrypted message to the attacker. The attacker is 5783 thus using the user as a random oracle, and can often decrypt the 5784 message. This attack is a particular form of ciphertext 5785 malleability. See Section 15.1 for information on how to defend 5786 against such an attack using more recent versions of OpenPGP. 5788 * PKCS#1 has been found to be vulnerable to attacks in which a 5789 system that reports errors in padding differently from errors in 5790 decryption becomes a random oracle that can leak the private key 5791 in mere millions of queries. Implementations must be aware of 5792 this attack and prevent it from happening. The simplest solution 5793 is to report a single error code for all variants of decryption 5794 errors so as not to leak information to an attacker. 5796 * Some technologies mentioned here may be subject to government 5797 control in some countries. 5799 * In winter 2005, Serge Mister and Robert Zuccherato from Entrust 5800 released a paper describing a way that the "quick check" in 5801 OpenPGP CFB mode can be used with a random oracle to decrypt two 5802 octets of every cipher block [MZ05]. They recommend as prevention 5803 not using the quick check at all. 5805 Many implementers have taken this advice to heart for any data 5806 that is symmetrically encrypted and for which the session key is 5807 public-key encrypted. In this case, the quick check is not needed 5808 as the public-key encryption of the session key should guarantee 5809 that it is the right session key. In other cases, the 5810 implementation should use the quick check with care. 5812 On the one hand, there is a danger to using it if there is a 5813 random oracle that can leak information to an attacker. In 5814 plainer language, there is a danger to using the quick check if 5815 timing information about the check can be exposed to an attacker, 5816 particularly via an automated service that allows rapidly repeated 5817 queries. 5819 On the other hand, it is inconvenient to the user to be informed 5820 that they typed in the wrong passphrase only after a petabyte of 5821 data is decrypted. There are many cases in cryptographic 5822 engineering where the implementer must use care and wisdom, and 5823 this is one. 5825 * An implementation SHOULD only use an AES algorithm as a KEK 5826 algorithm, since backward compatibility of the ECDH format is not 5827 a concern. The KEK algorithm is only used within the scope of a 5828 Public-Key Encrypted Session Key Packet, which represents an ECDH 5829 key recipient of a message. Compare this with the algorithm used 5830 for the session key of the message, which MAY be different from a 5831 KEK algorithm. 5833 Side channel attacks are a concern when a compliant application's 5834 use of the OpenPGP format can be modeled by a decryption or 5835 signing oracle, for example, when an application is a network 5836 service performing decryption to unauthenticated remote users. 5837 ECC scalar multiplication operations used in ECDSA and ECDH are 5838 vulnerable to side channel attacks. Countermeasures can often be 5839 taken at the higher protocol level, such as limiting the number of 5840 allowed failures or time-blinding of the operations associated 5841 with each network interface. Mitigations at the scalar 5842 multiplication level seek to eliminate any measurable distinction 5843 between the ECC point addition and doubling operations. 5845 * V5 signatures include a 128 bit salt that is hashed first. This 5846 makes OpenPGP signatures non-deterministic and protects against a 5847 broad class of attacks that depend on creating a signature over a 5848 predictable message. Hashing the salt first means that there is 5849 no attacker controlled hashed prefix. An example of this kind of 5850 attack is described in the paper SHA-1 Is A Shambles (see 5851 [SHAMBLES]), which leverages a chosen prefix collision attack 5852 against SHA-1. 5854 15.1. Avoiding Ciphertext Malleability 5856 If ciphertext can be modified by an attacker but still subsequently 5857 decrypted to some new plaintext, it is considered "malleable". A 5858 number of attacks can arise in any cryptosystem that uses malleable 5859 encryption, so modern OpenPGP offers mechanisms to defend against it. 5860 However, legacy OpenPGP data may have been created before these 5861 mechanisms were available. Because OpenPGP implementations deal with 5862 historic stored data, they may encounter malleable ciphertexts. 5864 When an OpenPGP implementation discovers that it is decrypting data 5865 that appears to be malleable, it MUST indicate a clear error message 5866 that the integrity of the message is suspect, SHOULD NOT release 5867 decrypted data to the user, and SHOULD halt with an error. An 5868 implementation that encounters malleable ciphertext MAY choose to 5869 release cleartext to the user if it is known to be dealing with 5870 historic archived legacy data, and the user is aware of the risks. 5872 Any of the following OpenPGP data elements indicate that malleable 5873 ciphertext is present: 5875 * all Symmetrically Encrypted Data packets (Section 5.8). 5877 * within any encrypted container, any Compressed Data packet 5878 (Section 5.7) where there is a decompression failure. 5880 * any version 1 Symmetrically Encrypted Integrity Protected Data 5881 packet (Section 5.14.1) where the internal Modification Detection 5882 Code does not validate. 5884 * any version 2 Symmetrically Encrypted Integrity Protected Data 5885 packet (Section 5.14.2) where the authentication tag of any chunk 5886 fails, or where there is no final zero-octet chunk. 5888 * any Secret Key packet with encrypted secret key material 5889 (Section 3.7.2.1) where there is an integrity failure, based on 5890 the value of the secret key protection octet: 5892 - value 255 or raw cipher algorithm: where the trailing 2-octet 5893 checksum does not match. 5895 - value 254: where the SHA1 checksum is mismatched. 5897 - value 253: where the AEAD authentication tag is invalid. 5899 To avoid these circumstances, an implementation that generates 5900 OpenPGP encrypted data SHOULD select the encrypted container format 5901 with the most robust protections that can be handled by the intended 5902 recipients. In particular: 5904 * The SED packet is deprecated, and MUST NOT be generated. 5906 * When encrypting to one or more public keys: 5908 - all recipient keys indicate support for version 2 of the 5909 Symmetrically Encrypted Integrity Protected Data packet in 5910 their Features subpacket (Section 5.2.3.29), or are v5 keys 5911 without a Features subpacket, or the implementation can 5912 otherwise infer that all recipients support v2 SEIPD packets, 5913 the implementation MUST encrypt using a v2 SEIPD packet. 5915 - If one of the recipients does not support v2 SEIPD packets, 5916 then the message generator MAY use a v1 SEIPD packet instead. 5918 * Password-protected secret key material in a V5 Secret Key or V5 5919 Secret Subkey packet SHOULD be protected with AEAD encryption (S2K 5920 usage octet 253) unless it will be transferred to an 5921 implementation that is known to not support AEAD. 5923 Implementers should implement AEAD (v2 SEIPD and S2K usage octet 253) 5924 promptly and encourage its spread. 5926 Users should migrate to AEAD with all due speed. 5928 15.2. Escrowed Revocation Signatures 5930 A keyholder Alice may wish to designate a third party to be able to 5931 revoke Alice's own key. 5933 The preferred way for her to do this is produce a specific Revocation 5934 Signature (signature types 0x20, 0x28, or 0x30) and distribute it 5935 securely to her preferred revoker who can hold it in escrow. The 5936 preferred revoker can then publish the escrowed Revocation Signature 5937 at whatever time is deemed appropriate, rather than generating a 5938 revocation signature themselves. 5940 There are multiple advantages of using an escrowed Revocation 5941 Signature over the deprecated Revocation Key subpacket 5942 (Section 5.2.3.20): 5944 * The keyholder can constrain what types of revocation the preferred 5945 revoker can issue, by only escrowing those specific signatures. 5947 * There is no public/visible linkage between the keyholder and the 5948 preferred revoker. 5950 * Third parties can verify the revocation without needing to find 5951 the key of the preferred revoker. 5953 * The preferred revoker doesn't even need to have a public OpenPGP 5954 key if some other secure transport is possible between them and 5955 the keyholder. 5957 * Implementation support for enforcing a revocation from an 5958 authorized Revocation Key subpacket is uneven and unreliable. 5960 * If the fingerprint mechanism suffers a cryptanalytic flaw, the 5961 escrowed Revocation Signature is not affected. 5963 A Revocation Signature may also be split up into shares and 5964 distributed among multiple parties, requiring some subset of those 5965 parties to collaborate before the escrowed Revocation Signature is 5966 recreated. 5968 15.3. Random Number Generation and Seeding 5970 OpenPGP requires a cryptographically secure pseudorandom number 5971 generator (CSPRNG). In most cases, the operating system provides an 5972 appropriate facility such as a getrandom() syscall, which should be 5973 used absent other (for example, performance) concerns. It is 5974 RECOMMENDED to use an existing CSPRNG implementation in preference to 5975 crafting a new one. Many adequate cryptographic libraries are 5976 already available under favorable license terms. Should those prove 5977 unsatisfactory, [RFC4086] provides guidance on the generation of 5978 random values. 5980 OpenPGP uses random data with three different levels of visibility: 5982 * in publicly-visible fields such as nonces, IVs, public padding 5983 material, or salts, 5985 * in shared-secret values, such as session keys for encrypted data 5986 or padding material within an encrypted packet, and 5988 * in entirely private data, such as asymmetric key generation. 5990 With a properly functioning CSPRNG, this does not present a security 5991 problem, as it is not feasible to determine the CSPRNG state from its 5992 output. However, with a broken CSPRNG, it may be possible for an 5993 attacker to use visible output to determine the CSPRNG internal state 5994 and thereby predict less-visible data like keying material, as 5995 documented in [CHECKOWAY]. 5997 An implementation can provide extra security against this form of 5998 attack by using separate CSPRNGs to generate random data with 5999 different levels of visibility. 6001 15.4. Traffic Analysis 6003 When sending OpenPGP data through the network, the size of the data 6004 may leak information to an attacker. There are circumstances where 6005 such a leak could be unacceptable from a security perspective. 6007 For example, if possible cleartext messages for a given protocol are 6008 known to be either yes (three octets) and no (two octets) and the 6009 messages are sent within a Symmetrically-Encrypted Integrity 6010 Protected Data packet, the length of the encrypted message will 6011 reveal the contents of the cleartext. 6013 In another example, sending an OpenPGP Transferable Public Key over 6014 an encrypted network connection might reveal the length of the 6015 certificate. Since the length of an OpenPGP certificate varies based 6016 on the content, an external observer interested in metadata (who is 6017 trying to contact who) may be able to guess the identity of the 6018 certificate sent, if its length is unique. 6020 In both cases, an implementation can adjust the size of the compound 6021 structure by including a Padding packet (see Section 5.15). 6023 16. Implementation Nits 6025 This section is a collection of comments to help an implementer, 6026 particularly with an eye to backward compatibility. Often the 6027 differences are small, but small differences are frequently more 6028 vexing than large differences. Thus, this is a non-comprehensive 6029 list of potential problems and gotchas for a developer who is trying 6030 to be backward-compatible. 6032 * There are many ways possible for two keys to have the same key 6033 material, but different fingerprints (and thus Key IDs). For 6034 example, since a V4 fingerprint is constructed by hashing the key 6035 creation time along with other things, two V4 keys created at 6036 different times, yet with the same key material will have 6037 different fingerprints. 6039 * OpenPGP does not put limits on the size of public keys. However, 6040 larger keys are not necessarily better keys. Larger keys take 6041 more computation time to use, and this can quickly become 6042 impractical. Different OpenPGP implementations may also use 6043 different upper bounds for public key sizes, and so care should be 6044 taken when choosing sizes to maintain interoperability. 6046 * ASCII armor is an optional feature of OpenPGP. The OpenPGP 6047 working group strives for a minimal set of mandatory-to-implement 6048 features, and since there could be useful implementations that 6049 only use binary object formats, this is not a "MUST" feature for 6050 an implementation. For example, an implementation that is using 6051 OpenPGP as a mechanism for file signatures may find ASCII armor 6052 unnecessary. OpenPGP permits an implementation to declare what 6053 features it does and does not support, but ASCII armor is not one 6054 of these. Since most implementations allow binary and armored 6055 objects to be used indiscriminately, an implementation that does 6056 not implement ASCII armor may find itself with compatibility 6057 issues with general-purpose implementations. Moreover, 6058 implementations of OpenPGP-MIME [RFC3156] already have a 6059 requirement for ASCII armor so those implementations will 6060 necessarily have support. 6062 * What this document calls Legacy packet format Section 4.2.2 is 6063 what older documents called the "old packet format". It is the 6064 packet format of the legacy PGP 2 implementation. Older RFCs 6065 called the current OpenPGP packet format Section 4.2.1 the "new 6066 packet format". 6068 17. References 6070 17.1. Normative References 6072 [AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)", 6073 November 2001, 6074 . 6077 [BLOWFISH] Schneier, B., "Description of a New Variable-Length Key, 6078 64-Bit Block Cipher (Blowfish)", Fast Software Encryption, 6079 Cambridge Security Workshop Proceedings Springer-Verlag, 6080 1994, pp191-204, December 1993, 6081 . 6083 [BZ2] Seward, J., "The Bzip2 and libbzip2 home page", 2010, 6084 . 6086 [EAX] Bellare, M., Rogaway, P., and D. Wagner, "A Conventional 6087 Authenticated-Encryption Mode", April 2003. 6089 [ELGAMAL] Elgamal, T., "A Public-Key Cryptosystem and a Signature 6090 Scheme Based on Discrete Logarithms", IEEE Transactions on 6091 Information Theory v. IT-31, n. 4, 1985, pp. 469-472, 6092 1985. 6094 [FIPS180] National Institute of Standards and Technology, U.S. 6095 Department of Commerce, "Secure Hash Standard (SHS), FIPS 6096 180-4", August 2015, 6097 . 6099 [FIPS186] National Institute of Standards and Technology, U.S. 6100 Department of Commerce, "Digital Signature Standard (DSS), 6101 FIPS 186-4", July 2013, 6102 . 6104 [FIPS202] National Institute of Standards and Technology, U.S. 6105 Department of Commerce, "SHA-3 Standard: Permutation-Based 6106 Hash and Extendable-Output Functions, FIPS 202", August 6107 2015, . 6109 [HAC] Menezes, A.J., Oorschot, P.v., and S. Vanstone, "Handbook 6110 of Applied Cryptography", 1996. 6112 [IDEA] Lai, X., "On the design and security of block ciphers", 6113 ETH Series in Information Processing, J.L. Massey 6114 (editor) Vol. 1, Hartung-Gorre Verlag Konstanz, Technische 6115 Hochschule (Zurich), 1992. 6117 [ISO10646] International Organization for Standardization, 6118 "Information Technology - Universal Multiple-octet coded 6119 Character Set (UCS) - Part 1: Architecture and Basic 6120 Multilingual Plane", ISO Standard 10646-1, May 1993. 6122 [JFIF] CA, E.H.M., "JPEG File Interchange Format (Version 6123 1.02).", September 1996. 6125 [PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based 6126 Cryptography Standard", 25 March 1999. 6128 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format 6129 Specification version 3.3", RFC 1950, 6130 DOI 10.17487/RFC1950, May 1996, 6131 . 6133 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 6134 version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996, 6135 . 6137 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 6138 Extensions (MIME) Part One: Format of Internet Message 6139 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 6140 . 6142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6143 Requirement Levels", BCP 14, RFC 2119, 6144 DOI 10.17487/RFC2119, March 1997, 6145 . 6147 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 6148 DOI 10.17487/RFC2144, May 1997, 6149 . 6151 [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, 6152 DOI 10.17487/RFC2822, April 2001, 6153 . 6155 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 6156 "MIME Security with OpenPGP", RFC 3156, 6157 DOI 10.17487/RFC3156, August 2001, 6158 . 6160 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 6161 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 6162 September 2002, . 6164 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 6165 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 6166 2003, . 6168 [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of 6169 the Camellia Encryption Algorithm", RFC 3713, 6170 DOI 10.17487/RFC3713, April 2004, 6171 . 6173 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 6174 "Randomness Requirements for Security", BCP 106, RFC 4086, 6175 DOI 10.17487/RFC4086, June 2005, 6176 . 6178 [RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated- 6179 Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May 6180 2014, . 6182 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 6183 for Security", RFC 7748, DOI 10.17487/RFC7748, January 6184 2016, . 6186 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 6187 "PKCS #1: RSA Cryptography Specifications Version 2.2", 6188 RFC 8017, DOI 10.17487/RFC8017, November 2016, 6189 . 6191 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 6192 Signature Algorithm (EdDSA)", RFC 8032, 6193 DOI 10.17487/RFC8032, January 2017, 6194 . 6196 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6197 Writing an IANA Considerations Section in RFCs", BCP 26, 6198 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6199 . 6201 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6202 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6203 May 2017, . 6205 [RFC9106] Biryukov, A., Dinu, D., Khovratovich, D., and S. 6206 Josefsson, "Argon2 Memory-Hard Function for Password 6207 Hashing and Proof-of-Work Applications", RFC 9106, 6208 DOI 10.17487/RFC9106, September 2021, 6209 . 6211 [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: 6212 protocols, algorithms, and source code in C", 1996. 6214 [SP800-38D] 6215 Dworkin, M., "Recommendation for Block Cipher Modes of 6216 Operation: Galois/Counter Mode (GCM) and GMAC", NIST 6217 Special Publication 800-38D, November 2007. 6219 [SP800-56A] 6220 Barker, E., Johnson, D., and M. Smid, "Recommendation for 6221 Pair-Wise Key Establishment Schemes Using Discrete 6222 Logarithm Cryptography", NIST Special Publication 800-56A 6223 Revision 1, March 2007. 6225 [TWOFISH] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall, 6226 C., and N. Ferguson, "The Twofish Encryption Algorithm", 6227 1999. 6229 17.2. Informative References 6231 [BLEICHENBACHER] 6232 Bleichenbacher, D., "Generating ElGamal Signatures Without 6233 Knowing the Secret Key", Lecture Notes in Computer 6234 Science Volume 1070, pp. 10-18, 1996. 6236 [CHECKOWAY] 6237 Checkoway, S., Maskiewicz, J., Garman, C., Fried, J., 6238 Cohney, S., Green, M., Heninger, N., Weinmann, R., 6239 Rescorla, E., and H. Shacham, "A Systematic Analysis of 6240 the Juniper Dual EC Incident", Proceedings of the 2016 ACM 6241 SIGSAC Conference on Computer and Communications Security, 6242 DOI 10.1145/2976749.2978395, October 2016, 6243 . 6245 [JKS02] Jallad, K., Katz, J., and B. Schneier, "Implementation of 6246 Chosen-Ciphertext Attacks against PGP and GnuPG", 2002, 6247 . 6249 [KOBLITZ] Koblitz, N., "A course in number theory and cryptography, 6250 Chapter VI. Elliptic Curves", ISBN 0-387-96576-9, 1997. 6252 [MZ05] Mister, S. and R. Zuccherato, "An Attack on CFB Mode 6253 Encryption As Used By OpenPGP", IACR ePrint Archive Report 6254 2005/033, 8 February 2005, 6255 . 6257 [PAX] The Open Group, "IEEE Standard for Information 6258 Technology--Portable Operating System Interface (POSIX(R)) 6259 Base Specifications, Issue 7: pax - portable archive 6260 interchange", IEEE Standard 1003.1-2017, 6261 DOI 10.1109/IEEESTD.2018.8277153, 2018, 6262 . 6265 [REGEX] Friedl, J., "Mastering Regular Expressions", 6266 ISBN 0-596-00289-0, August 2002. 6268 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 6269 Exchange Formats", RFC 1991, DOI 10.17487/RFC1991, August 6270 1996, . 6272 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 6273 "OpenPGP Message Format", RFC 2440, DOI 10.17487/RFC2440, 6274 November 1998, . 6276 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 6277 Thayer, "OpenPGP Message Format", RFC 4880, 6278 DOI 10.17487/RFC4880, November 2007, 6279 . 6281 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 6282 Key Derivation Function (HKDF)", RFC 5869, 6283 DOI 10.17487/RFC5869, May 2010, 6284 . 6286 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 6287 Curve Cryptography Algorithms", RFC 6090, 6288 DOI 10.17487/RFC6090, February 2011, 6289 . 6291 [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 6292 Elliptic Curve Cryptography", September 2000. 6294 [SHAMBLES] Leurent, G. and T. Peyrin, "Sha-1 is a shambles: First 6295 chosen-prefix collision on sha-1 and application to the 6296 PGP web of trust", 2020, . 6298 [SP800-57] NIST, "Recommendation on Key Management", NIST Special 6299 Publication 800-57, March 2007, 6300 . 6303 Appendix A. Test vectors 6305 To help implementing this specification a non-normative example for 6306 the EdDSA algorithm is given. 6308 A.1. Sample EdDSA key 6310 The secret key used for this example is: 6312 D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2 6314 Note that this is the raw secret key used as input to the EdDSA 6315 signing operation. The key was created on 2014-08-19 14:28:27 and 6316 thus the fingerprint of the OpenPGP key is: 6318 C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A 6320 The algorithm specific input parameters without the MPI length 6321 headers are: 6323 oid: 2b06010401da470f01 6325 q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406 6327 The entire public key packet is thus: 6329 98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47 6330 0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19 6331 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e 6332 43 ee 3b 24 06 6334 A.2. Sample EdDSA signature 6336 The signature is created using the sample key over the input data 6337 "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash 6338 function is: 6340 m: 4f70656e504750040016080006050255f95f9504ff0000000c 6341 Using the SHA2-256 hash algorithm yields the digest: 6343 d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280 6345 Which is fed into the EdDSA signature function and yields this 6346 signature: 6348 r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366 6350 s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404 6352 The entire signature packet is thus: 6354 88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a 6355 09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9 6356 0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2 6357 7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00 6358 d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e 6359 a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04 6361 A.3. Sample AEAD-EAX encryption and decryption 6363 This example encrypts the cleartext string Hello, world! with the 6364 password password, using AES-128 with AEAD-EAX encryption. 6366 A.3.1. Sample Parameters 6368 S2K: 6370 Iterated and Salted S2K 6372 Iterations: 6374 65011712 (255), SHA2-256 6376 Salt: 6378 a5 ae 57 9d 1f c5 d8 2b 6380 A.3.2. Sample symmetric-key encrypted session key packet (v5) 6382 Packet header: 6384 c3 40 6386 Version, algorithms, S2K fields: 6388 05 1e 07 01 0b 03 08 a5 ae 57 9d 1f c5 d8 2b ff 6389 69 22 6391 Nonce: 6393 69 22 4f 91 99 93 b3 50 6f a3 b5 9a 6a 73 cf f8 6395 Encrypted session key and AEAD tag: 6397 da 74 6b 88 e3 57 e8 ae 54 eb 87 e1 d7 05 75 d7 6398 2f 60 23 29 90 52 3e 9a 59 09 49 22 40 6b e1 c3 6400 A.3.3. Starting AEAD-EAX decryption of the session key 6402 The derived key is: 6404 15 49 67 e5 90 aa 1f 92 3e 1c 0a c6 4c 88 f2 3d 6406 HKDF info: 6408 c3 05 07 01 6410 HKDF output: 6412 74 f0 46 03 63 a7 00 76 db 08 c4 92 ab f2 95 52 6414 Authenticated Data: 6416 c3 05 07 01 6418 Nonce: 6420 69 22 4f 91 99 93 b3 50 6f a3 b5 9a 6a 73 cf f8 6422 Decrypted session key: 6424 38 81 ba fe 98 54 12 45 9b 86 c3 6f 98 cb 9a 5e 6426 A.3.4. Sample v2 SEIPD packet 6428 Packet header: 6430 d2 69 6432 Version, AES-128, EAX, Chunk size octet: 6434 02 07 01 06 6436 Salt: 6438 9f f9 0e 3b 32 19 64 f3 a4 29 13 c8 dc c6 61 93 6439 25 01 52 27 ef b7 ea ea a4 9f 04 c2 e6 74 17 5d 6441 Chunk #0 encrypted data: 6443 4a 3d 22 6e d6 af cb 9c a9 ac 12 2c 14 70 e1 1c 6444 63 d4 c0 ab 24 1c 6a 93 8a d4 8b f9 9a 5a 99 b9 6445 0b ba 83 25 de 6447 Chunk #0 authentication tag: 6449 61 04 75 40 25 8a b7 95 9a 95 ad 05 1d da 96 eb 6451 Final (zero-sized chunk #1) authentication tag: 6453 15 43 1d fe f5 f5 e2 25 5c a7 82 61 54 6e 33 9a 6455 A.3.5. Decryption of data 6457 Starting AEAD-EAX decryption of data, using the session key. 6459 HKDF info: 6461 d2 02 07 01 06 6463 HKDF output: 6465 b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f 6466 78 b8 33 f2 e9 4a 60 c0 6468 Message key: 6470 b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f 6472 Initialization vector: 6474 78 b8 33 f2 e9 4a 60 c0 6476 Chunk #0: 6478 Nonce: 6480 78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 00 6482 Additional authenticated data: 6484 d2 02 07 01 06 6486 Decrypted chunk #0. 6488 Literal data packet with the string contents Hello, world!: 6490 cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77 6491 6f 72 6c 64 21 6493 Padding packet: 6495 d5 0e ae 5b f0 cd 67 05 50 03 55 81 6c b0 c8 ff 6497 Authenticating final tag: 6499 Final nonce: 6501 78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 01 6503 Final additional authenticated data: 6505 d2 02 07 01 06 00 00 00 00 00 00 00 25 6507 A.3.6. Complete AEAD-EAX encrypted packet sequence 6509 -----BEGIN PGP MESSAGE----- 6511 w0AFHgcBCwMIpa5XnR/F2Cv/aSJPkZmTs1Bvo7WaanPP+Np0a4jjV+iuVOuH4dcF 6512 ddcvYCMpkFI+mlkJSSJAa+HD0mkCBwEGn/kOOzIZZPOkKRPI3MZhkyUBUifvt+rq 6513 pJ8EwuZ0F11KPSJu1q/LnKmsEiwUcOEcY9TAqyQcapOK1Iv5mlqZuQu6gyXeYQR1 6514 QCWKt5Wala0FHdqW6xVDHf719eIlXKeCYVRuM5o= 6515 =wG7F 6516 -----END PGP MESSAGE----- 6518 A.4. Sample AEAD-OCB encryption and decryption 6520 This example encrypts the cleartext string Hello, world! with the 6521 password password, using AES-128 with AEAD-OCB encryption. 6523 A.4.1. Sample Parameters 6525 S2K: 6527 Iterated and Salted S2K 6529 Iterations: 6531 65011712 (255), SHA2-256 6533 Salt: 6535 56 a2 98 d2 f5 e3 64 53 6537 A.4.2. Sample symmetric-key encrypted session key packet (v5) 6539 Packet header: 6541 c3 3f 6543 Version, algorithms, S2K fields: 6545 05 1d 07 02 0b 03 08 56 a2 98 d2 f5 e3 64 53 ff 6546 cf cc 6548 Nonce: 6550 cf cc 5c 11 66 4e db 9d b4 25 90 d7 dc 46 b0 6552 Encrypted session key and AEAD tag: 6554 78 c5 c0 41 9c c5 1b 3a 46 87 cb 32 e5 b7 03 1c 6555 e7 c6 69 75 76 5b 5c 21 d9 2a ef 4c c0 5c 3f ea 6557 A.4.3. Starting AEAD-EAX decryption of the session key 6559 The derived key is: 6561 e8 0d e2 43 a3 62 d9 3b 9d c6 07 ed e9 6a 73 56 6563 HKDF info: 6565 c3 05 07 02 6567 HKDF output: 6569 20 62 fb 76 31 ef be f4 df 81 67 ce d7 f3 a4 64 6571 Authenticated Data: 6573 c3 05 07 02 6575 Nonce: 6577 cf cc 5c 11 66 4e db 9d b4 25 90 d7 dc 46 b0 6579 Decrypted session key: 6581 28 e7 9a b8 23 97 d3 c6 3d e2 4a c2 17 d7 b7 91 6583 A.4.4. Sample v2 SEIPD packet 6585 Packet header: 6587 d2 69 6589 Version, AES-128, EAX, Chunk size octet: 6591 02 07 02 06 6593 Salt: 6595 20 a6 61 f7 31 fc 9a 30 32 b5 62 33 26 02 7e 3a 6596 5d 8d b5 74 8e be ff 0b 0c 59 10 d0 9e cd d6 41 6598 Chunk #0 encrypted data: 6600 ff 9f d3 85 62 75 80 35 bc 49 75 4c e1 bf 3f ff 6601 a7 da d0 a3 b8 10 4f 51 33 cf 42 a4 10 0a 83 ee 6602 f4 ca 1b 48 01 6604 Chunk #0 authentication tag: 6606 a8 84 6b f4 2b cd a7 c8 ce 9d 65 e2 12 f3 01 cb 6608 Final (zero-sized chunk #1) authentication tag: 6610 cd 98 fd ca de 69 4a 87 7a d4 24 73 23 f6 e8 57 6612 A.4.5. Decryption of data 6614 Starting AEAD-OCB decryption of data, using the session key. 6616 HKDF info: 6618 d2 02 07 02 06 6620 HKDF output: 6622 71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99 6623 eb de 12 bb 57 0d cf 6625 Message key: 6627 71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99 6629 Initialization vector: 6631 eb de 12 bb 57 0d cf 6633 Chunk #0: 6635 Nonce: 6637 eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 00 6639 Additional authenticated data: 6641 d2 02 07 02 06 6643 Decrypted chunk #0. 6645 Literal data packet with the string contents Hello, world!: 6647 cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77 6648 6f 72 6c 64 21 6650 Padding packet: 6652 d5 0e ae 6a a1 64 9b 56 aa 83 5b 26 13 90 2b d2 6654 Authenticating final tag: 6656 Final nonce: 6658 eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 01 6660 Final additional authenticated data: 6662 d2 02 07 02 06 00 00 00 00 00 00 00 25 6664 A.4.6. Complete AEAD-EAX encrypted packet sequence 6666 -----BEGIN PGP MESSAGE----- 6668 wz8FHQcCCwMIVqKY0vXjZFP/z8xcEWZO2520JZDX3EaweMXAQZzFGzpGh8sy5bcD 6669 HOfGaXV2W1wh2SrvTMBcP+rSaQIHAgYgpmH3MfyaMDK1YjMmAn46XY21dI6+/wsM 6670 WRDQns3WQf+f04VidYA1vEl1TOG/P/+n2tCjuBBPUTPPQqQQCoPu9MobSAGohGv0 6671 K82nyM6dZeIS8wHLzZj9yt5pSod61CRzI/boVw== 6672 =K/pk 6673 -----END PGP MESSAGE----- 6675 A.5. Sample AEAD-GCM encryption and decryption 6677 This example encrypts the cleartext string Hello, world! with the 6678 password password, using AES-128 with AEAD-GCM encryption. 6680 A.5.1. Sample Parameters 6682 S2K: 6684 Iterated and Salted S2K 6686 Iterations: 6688 65011712 (255), SHA2-256 6690 Salt: 6692 e9 d3 97 85 b2 07 00 08 6694 A.5.2. Sample symmetric-key encrypted session key packet (v5) 6696 Packet header: 6698 c3 3c 6700 Version, algorithms, S2K fields: 6702 05 1a 07 03 0b 03 08 e9 d3 97 85 b2 07 00 08 ff 6703 b4 2e 6705 Nonce: 6707 b4 2e 7c 48 3e f4 88 44 57 cb 37 26 6709 Encrypted session key and AEAD tag: 6711 0c 0c 4b f3 f2 cd 6c b7 b6 e3 8b 5b f3 34 67 c1 6712 c7 19 44 dd 59 03 46 66 2f 5a de 61 ff 84 bc e0 6714 A.5.3. Starting AEAD-EAX decryption of the session key 6716 The derived key is: 6718 25 02 81 71 5b ba 78 28 ef 71 ef 64 c4 78 47 53 6720 HKDF info: 6722 c3 05 07 03 6724 HKDF output: 6726 de ec e5 81 8b c0 aa b9 0f 8a fb 02 fa 00 cd 13 6728 Authenticated Data: 6730 c3 05 07 03 6732 Nonce: 6734 b4 2e 7c 48 3e f4 88 44 57 cb 37 26 6736 Decrypted session key: 6738 19 36 fc 85 68 98 02 74 bb 90 0d 83 19 36 0c 77 6740 A.5.4. Sample v2 SEIPD packet 6742 Packet header: 6744 d2 69 6746 Version, AES-128, EAX, Chunk size octet: 6748 02 07 03 06 6750 Salt: 6752 fc b9 44 90 bc b9 8b bd c9 d1 06 c6 09 02 66 94 6753 0f 72 e8 9e dc 21 b5 59 6b 15 76 b1 01 ed 0f 9f 6755 Chunk #0 encrypted data: 6757 fc 6f c6 d6 5b bf d2 4d cd 07 90 96 6e 6d 1e 85 6758 a3 00 53 78 4c b1 d8 b6 a0 69 9e f1 21 55 a7 b2 6759 ad 62 58 53 1b 6761 Chunk #0 authentication tag: 6763 57 65 1f d7 77 79 12 fa 95 e3 5d 9b 40 21 6f 69 6765 Final (zero-sized chunk #1) authentication tag: 6767 a4 c2 48 db 28 ff 43 31 f1 63 29 07 39 9e 6f f9 6769 A.5.5. Decryption of data 6771 Starting AEAD-GCM decryption of data, using the session key. 6773 HKDF info: 6775 d2 02 07 03 06 6777 HKDF output: 6779 ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d 6780 4d 2b dc 2b 6782 Message key: 6784 ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d 6786 Initialization vector: 6788 4d 2b dc 2b 6790 Chunk #0: 6792 Nonce: 6794 4d 2b dc 2b 00 00 00 00 00 00 00 00 6796 Additional authenticated data: 6798 d2 02 07 03 06 6800 Decrypted chunk #0. 6802 Literal data packet with the string contents Hello, world!: 6804 cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77 6805 6f 72 6c 64 21 6807 Padding packet: 6809 d5 0e 1c e2 26 9a 9e dd ef 81 03 21 72 b7 ed 7c 6811 Authenticating final tag: 6813 Final nonce: 6815 4d 2b dc 2b 00 00 00 00 00 00 00 01 6817 Final additional authenticated data: 6819 d2 02 07 03 06 00 00 00 00 00 00 00 25 6821 A.5.6. Complete AEAD-EAX encrypted packet sequence 6823 -----BEGIN PGP MESSAGE----- 6825 wzwFGgcDCwMI6dOXhbIHAAj/tC58SD70iERXyzcmDAxL8/LNbLe244tb8zRnwccZ 6826 RN1ZA0ZmL1reYf+EvODSaQIHAwb8uUSQvLmLvcnRBsYJAmaUD3LontwhtVlrFXax 6827 Ae0Pn/xvxtZbv9JNzQeQlm5tHoWjAFN4TLHYtqBpnvEhVaeyrWJYUxtXZR/Xd3kS 6828 +pXjXZtAIW9ppMJI2yj/QzHxYykHOZ5v+Q== 6829 =ClBe 6830 -----END PGP MESSAGE----- 6832 A.6. Sample message encrypted using Argon2 6834 These messages are the literal data "Hello, world!" encrypted using 6835 Argon2 and the passphrase "password", using different session key 6836 sizes. In all cases, the Argon2 parameters are t = 1, p = 4, and m = 6837 21. 6839 AES-128: 6841 -----BEGIN PGP MESSAGE----- 6842 Comment: Encrypted using AES with 128-bit key 6843 Comment: Session key: 01FE16BBACFD1E7B78EF3B865187374F 6845 wycEBwScUvg8J/leUNU1RA7N/zE2AQQVnlL8rSLPP5VlQsunlO+ECxHSPgGYGKY+ 6846 YJz4u6F+DDlDBOr5NRQXt/KJIf4m4mOlKyC/uqLbpnLJZMnTq3o79GxBTdIdOzhH 6847 XfA3pqV4mTzF 6848 =uIks 6849 -----END PGP MESSAGE----- 6851 AES-192: 6853 -----BEGIN PGP MESSAGE----- 6854 Comment: Encrypted using AES with 192-bit key 6855 Comment: Session key: 27006DAE68E509022CE45A14E569E91001C2955AF8DFE194 6857 wy8ECAThTKxHFTRZGKli3KNH4UP4AQQVhzLJ2va3FG8/pmpIPd/H/mdoVS5VBLLw 6858 F9I+AdJ1Sw56PRYiKZjCvHg+2bnq02s33AJJoyBexBI4QKATFRkyez2gldJldRys 6859 LVg77Mwwfgl2n/d572WciAM= 6860 =n8Ma 6861 -----END PGP MESSAGE----- 6863 AES-256: 6865 -----BEGIN PGP MESSAGE----- 6866 Comment: Encrypted using AES with 256-bit key 6867 Comment: Session key: BBEDA55B9AAE63DAC45D4F49D89DACF4AF37FEFC13BAB2F1F8E18FB74580D8B0 6869 wzcECQS4eJUgIG/3mcaILEJFpmJ8AQQVnZ9l7KtagdClm9UaQ/Z6M/5roklSGpGu 6870 623YmaXezGj80j4B+Ku1sgTdJo87X1Wrup7l0wJypZls21Uwd67m9koF60eefH/K 6871 95D1usliXOEm8ayQJQmZrjf6K6v9PWwqMQ== 6872 =1fB/ 6873 -----END PGP MESSAGE----- 6875 Appendix B. Acknowledgements 6877 This memo also draws on much previous work from a number of other 6878 authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc 6879 Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, 6880 Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings, 6881 Mark Weaver, and Philip R. Zimmermann. 6883 Appendix C. Document Workflow 6885 This document is built from markdown using ruby-kramdown-rfc2629 6886 (https://rubygems.org/gems/kramdown-rfc2629), and tracked using git 6887 (https://git-scm.com/). The markdown source under development can be 6888 found in the file crypto-refresh.md in the main branch of the git 6889 repository (https://gitlab.com/openpgp-wg/rfc4880bis). Discussion of 6890 this document should take place on the openpgp@ietf.org mailing list 6891 (https://www.ietf.org/mailman/listinfo/openpgp). 6893 A non-substantive editorial nit can be submitted directly as a merge 6894 request (https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/ 6895 new). A substantive proposed edit may also be submitted as a merge 6896 request, but should simultaneously be sent to the mailing list for 6897 discussion. 6899 An open problem can be recorded and tracked as an issue 6900 (https://gitlab.com/openpgp-wg/rfc4880bis/-/issues) in the gitlab 6901 issue tracker, but discussion of the issue should take place on the 6902 mailing list. 6904 [Note to RFC-Editor: Please remove this section on publication.] 6906 Authors' Addresses 6908 Werner Koch (editor) 6909 GnuPG e.V. 6910 Rochusstr. 44 6911 40479 Duesseldorf 6912 Germany 6913 Email: wk@gnupg.org 6914 URI: https://gnupg.org/verein 6916 Paul Wouters (editor) 6917 Aiven 6918 Email: paul.wouters@aiven.io