draft-ietf-openpgp-crypto-refresh-05.txt   draft-ietf-openpgp-crypto-refresh-06.txt 
Network Working Group W. Koch, Ed. Network Working Group W. Koch, Ed.
Internet-Draft GnuPG e.V. Internet-Draft GnuPG e.V.
Obsoletes: 4880, 5581, 6637 (if approved) P. Wouters, Ed. Obsoletes: 4880, 5581, 6637 (if approved) P. Wouters, Ed.
Intended status: Standards Track Aiven Intended status: Standards Track Aiven
Expires: 8 September 2022 7 March 2022 Expires: 8 December 2022 D. Huigens
Proton AG
J. Winter
Sequoia-PGP
. Yutaka N
FSIJ
6 June 2022
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-crypto-refresh-05 draft-ietf-openpgp-crypto-refresh-06
Abstract Abstract
This document specifies the message formats used in OpenPGP. OpenPGP This document specifies the message formats used in OpenPGP. OpenPGP
provides encryption with public-key or symmetric cryptographic provides encryption with public-key or symmetric cryptographic
algorithms, digital signatures, compression and key management. algorithms, digital signatures, compression and key management.
This document is maintained in order to publish all necessary This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on the information needed to develop interoperable applications based on the
OpenPGP format. It is not a step-by-step cookbook for writing an OpenPGP format. It is not a step-by-step cookbook for writing an
skipping to change at page 1, line 44 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 December 2022.
This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. General functions . . . . . . . . . . . . . . . . . . . . . . 8 2. General functions . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Confidentiality via Encryption . . . . . . . . . . . . . 8 2.1. Confidentiality via Encryption . . . . . . . . . . . . . 9
2.2. Authentication via Digital Signature . . . . . . . . . . 9 2.2. Authentication via Digital Signature . . . . . . . . . . 10
2.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Conversion to Radix-64 . . . . . . . . . . . . . . . . . 10 2.4. Conversion to Radix-64 . . . . . . . . . . . . . . . . . 10
2.5. Signature-Only Applications . . . . . . . . . . . . . . . 10 2.5. Signature-Only Applications . . . . . . . . . . . . . . . 11
3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 10 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 11
3.1. Scalar Numbers . . . . . . . . . . . . . . . . . . . . . 10 3.1. Scalar Numbers . . . . . . . . . . . . . . . . . . . . . 11
3.2. Multiprecision Integers . . . . . . . . . . . . . . . . . 11 3.2. Multiprecision Integers . . . . . . . . . . . . . . . . . 11
3.2.1. Using MPIs to encode other data . . . . . . . . . . . 11 3.2.1. Using MPIs to encode other data . . . . . . . . . . . 12
3.3. Key IDs . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Key IDs . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Time Fields . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Time Fields . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Keyrings . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Keyrings . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. String-to-Key (S2K) Specifiers . . . . . . . . . . . . . 12 3.7. String-to-Key (S2K) Specifiers . . . . . . . . . . . . . 13
3.7.1. String-to-Key (S2K) Specifier Types . . . . . . . . . 12 3.7.1. String-to-Key (S2K) Specifier Types . . . . . . . . . 13
3.7.1.1. Simple S2K . . . . . . . . . . . . . . . . . . . 13 3.7.1.1. Simple S2K . . . . . . . . . . . . . . . . . . . 13
3.7.1.2. Salted S2K . . . . . . . . . . . . . . . . . . . 14 3.7.1.2. Salted S2K . . . . . . . . . . . . . . . . . . . 14
3.7.1.3. Iterated and Salted S2K . . . . . . . . . . . . . 14 3.7.1.3. Iterated and Salted S2K . . . . . . . . . . . . . 14
3.7.1.4. Argon2 . . . . . . . . . . . . . . . . . . . . . 15 3.7.1.4. Argon2 . . . . . . . . . . . . . . . . . . . . . 15
3.7.2. String-to-Key Usage . . . . . . . . . . . . . . . . . 16 3.7.2. String-to-Key Usage . . . . . . . . . . . . . . . . . 16
3.7.2.1. Secret-Key Encryption . . . . . . . . . . . . . . 16 3.7.2.1. Secret-Key Encryption . . . . . . . . . . . . . . 16
3.7.2.2. Symmetric-Key Message Encryption . . . . . . . . 17 3.7.2.2. Symmetric-Key Message Encryption . . . . . . . . 18
4. Packet Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Packet Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Packet Headers . . . . . . . . . . . . . . . . . . . . . 18 4.2. Packet Headers . . . . . . . . . . . . . . . . . . . . . 19
4.2.1. OpenPGP Format Packet Lengths . . . . . . . . . . . . 19 4.2.1. OpenPGP Format Packet Lengths . . . . . . . . . . . . 20
4.2.1.1. One-Octet Lengths . . . . . . . . . . . . . . . . 20 4.2.1.1. One-Octet Lengths . . . . . . . . . . . . . . . . 20
4.2.1.2. Two-Octet Lengths . . . . . . . . . . . . . . . . 20 4.2.1.2. Two-Octet Lengths . . . . . . . . . . . . . . . . 21
4.2.1.3. Five-Octet Lengths . . . . . . . . . . . . . . . 20 4.2.1.3. Five-Octet Lengths . . . . . . . . . . . . . . . 21
4.2.1.4. Partial Body Lengths . . . . . . . . . . . . . . 20 4.2.1.4. Partial Body Lengths . . . . . . . . . . . . . . 21
4.2.2. Legacy Format Packet Lengths . . . . . . . . . . . . 21 4.2.2. Legacy Format Packet Lengths . . . . . . . . . . . . 22
4.2.3. Packet Length Examples . . . . . . . . . . . . . . . 21 4.2.3. Packet Length Examples . . . . . . . . . . . . . . . 22
4.3. Packet Tags . . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Packet Tags . . . . . . . . . . . . . . . . . . . . . . . 23
5. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.1. Packet Criticality . . . . . . . . . . . . . . . . . 24
5.1. Public-Key Encrypted Session Key Packets (Tag 1) . . . . 23 5. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. v3 PKESK . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Public-Key Encrypted Session Key Packets (Tag 1) . . . . 24
5.1.2. v5 PKESK . . . . . . . . . . . . . . . . . . . . . . 24 5.1.1. v3 PKESK . . . . . . . . . . . . . . . . . . . . . . 25
5.1.3. Algorithm Specific Fields for RSA encryption . . . . 25 5.1.2. v5 PKESK . . . . . . . . . . . . . . . . . . . . . . 26
5.1.4. Algorithm Specific Fields for Elgamal encryption . . 25 5.1.3. Algorithm-Specific Fields for RSA encryption . . . . 26
5.1.5. Algorithm-Specific Fields for ECDH encryption . . . . 25 5.1.4. Algorithm-Specific Fields for Elgamal encryption . . 26
5.1.6. Notes on PKESK . . . . . . . . . . . . . . . . . . . 25 5.1.5. Algorithm-Specific Fields for ECDH encryption . . . . 27
5.2. Signature Packet (Tag 2) . . . . . . . . . . . . . . . . 26 5.1.6. Notes on PKESK . . . . . . . . . . . . . . . . . . . 27
5.2.1. Signature Types . . . . . . . . . . . . . . . . . . . 26 5.2. Signature Packet (Tag 2) . . . . . . . . . . . . . . . . 27
5.2.2. Version 3 Signature Packet Format . . . . . . . . . . 28 5.2.1. Signature Types . . . . . . . . . . . . . . . . . . . 28
5.2.3. Version 4 and 5 Signature Packet Formats . . . . . . 31 5.2.2. Version 3 Signature Packet Format . . . . . . . . . . 30
5.2.3.1. Algorithm-Specific Fields for RSA signatures . . 32 5.2.3. Version 4 and 5 Signature Packet Formats . . . . . . 33
5.2.3.1. Algorithm-Specific Fields for RSA signatures . . 34
5.2.3.2. Algorithm-Specific Fields for DSA or ECDSA 5.2.3.2. Algorithm-Specific Fields for DSA or ECDSA
signatures . . . . . . . . . . . . . . . . . . . . 32 signatures . . . . . . . . . . . . . . . . . . . . 34
5.2.3.3. Algorithm-Specific Fields for EdDSA signatures . 32 5.2.3.3. Algorithm-Specific Fields for EdDSA signatures . 34
5.2.3.4. Notes on Signatures . . . . . . . . . . . . . . . 33 5.2.3.4. Notes on Signatures . . . . . . . . . . . . . . . 35
5.2.3.5. Signature Subpacket Specification . . . . . . . . 34 5.2.3.5. Signature Subpacket Specification . . . . . . . . 36
5.2.3.6. Signature Subpacket Types . . . . . . . . . . . . 37 5.2.3.6. Signature Subpacket Types . . . . . . . . . . . . 39
5.2.3.7. Notes on Self-Signatures . . . . . . . . . . . . 37 5.2.3.7. Notes on Self-Signatures . . . . . . . . . . . . 39
5.2.3.8. Signature Creation Time . . . . . . . . . . . . . 38 5.2.3.8. Signature Creation Time . . . . . . . . . . . . . 41
5.2.3.9. Issuer . . . . . . . . . . . . . . . . . . . . . 38 5.2.3.9. Issuer Key ID . . . . . . . . . . . . . . . . . . 41
5.2.3.10. Key Expiration Time . . . . . . . . . . . . . . . 38 5.2.3.10. Key Expiration Time . . . . . . . . . . . . . . . 41
5.2.3.11. Preferred Symmetric Ciphers for v1 SEIPD . . . . 39 5.2.3.11. Preferred Symmetric Ciphers for v1 SEIPD . . . . 42
5.2.3.12. Preferred AEAD Ciphersuites . . . . . . . . . . . 39 5.2.3.12. Preferred AEAD Ciphersuites . . . . . . . . . . . 42
5.2.3.13. Preferred Hash Algorithms . . . . . . . . . . . . 40 5.2.3.13. Preferred Hash Algorithms . . . . . . . . . . . . 43
5.2.3.14. Preferred Compression Algorithms . . . . . . . . 40 5.2.3.14. Preferred Compression Algorithms . . . . . . . . 43
5.2.3.15. Signature Expiration Time . . . . . . . . . . . . 40 5.2.3.15. Signature Expiration Time . . . . . . . . . . . . 43
5.2.3.16. Exportable Certification . . . . . . . . . . . . 40 5.2.3.16. Exportable Certification . . . . . . . . . . . . 43
5.2.3.17. Revocable . . . . . . . . . . . . . . . . . . . . 41 5.2.3.17. Revocable . . . . . . . . . . . . . . . . . . . . 44
5.2.3.18. Trust Signature . . . . . . . . . . . . . . . . . 41 5.2.3.18. Trust Signature . . . . . . . . . . . . . . . . . 44
5.2.3.19. Regular Expression . . . . . . . . . . . . . . . 42 5.2.3.19. Regular Expression . . . . . . . . . . . . . . . 45
5.2.3.20. Revocation Key . . . . . . . . . . . . . . . . . 42 5.2.3.20. Revocation Key . . . . . . . . . . . . . . . . . 45
5.2.3.21. Notation Data . . . . . . . . . . . . . . . . . . 43 5.2.3.21. Notation Data . . . . . . . . . . . . . . . . . . 46
5.2.3.22. Key Server Preferences . . . . . . . . . . . . . 44 5.2.3.22. Key Server Preferences . . . . . . . . . . . . . 47
5.2.3.23. Preferred Key Server . . . . . . . . . . . . . . 44 5.2.3.23. Preferred Key Server . . . . . . . . . . . . . . 47
5.2.3.24. Primary User ID . . . . . . . . . . . . . . . . . 45 5.2.3.24. Primary User ID . . . . . . . . . . . . . . . . . 47
5.2.3.25. Policy URI . . . . . . . . . . . . . . . . . . . 45 5.2.3.25. Policy URI . . . . . . . . . . . . . . . . . . . 48
5.2.3.26. Key Flags . . . . . . . . . . . . . . . . . . . . 45 5.2.3.26. Key Flags . . . . . . . . . . . . . . . . . . . . 48
5.2.3.27. Signer's User ID . . . . . . . . . . . . . . . . 47 5.2.3.27. Signer's User ID . . . . . . . . . . . . . . . . 50
5.2.3.28. Reason for Revocation . . . . . . . . . . . . . . 47 5.2.3.28. Reason for Revocation . . . . . . . . . . . . . . 50
5.2.3.29. Features . . . . . . . . . . . . . . . . . . . . 49 5.2.3.29. Features . . . . . . . . . . . . . . . . . . . . 52
5.2.3.30. Signature Target . . . . . . . . . . . . . . . . 50 5.2.3.30. Signature Target . . . . . . . . . . . . . . . . 53
5.2.3.31. Embedded Signature . . . . . . . . . . . . . . . 50 5.2.3.31. Embedded Signature . . . . . . . . . . . . . . . 53
5.2.3.32. Issuer Fingerprint . . . . . . . . . . . . . . . 50 5.2.3.32. Issuer Fingerprint . . . . . . . . . . . . . . . 53
5.2.3.33. Intended Recipient Fingerprint . . . . . . . . . 50 5.2.3.33. Intended Recipient Fingerprint . . . . . . . . . 53
5.2.4. Computing Signatures . . . . . . . . . . . . . . . . 51 5.2.4. Computing Signatures . . . . . . . . . . . . . . . . 54
5.2.4.1. Subpacket Hints . . . . . . . . . . . . . . . . . 52 5.2.4.1. Subpacket Hints . . . . . . . . . . . . . . . . . 56
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) . . . 53 5.2.5. Malformed and Unknown Signatures . . . . . . . . . . 56
5.3.1. v4 SKESK . . . . . . . . . . . . . . . . . . . . . . 53 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) . . . 57
5.3.2. v5 SKESK . . . . . . . . . . . . . . . . . . . . . . 54 5.3.1. v4 SKESK . . . . . . . . . . . . . . . . . . . . . . 57
5.4. One-Pass Signature Packets (Tag 4) . . . . . . . . . . . 55 5.3.2. v5 SKESK . . . . . . . . . . . . . . . . . . . . . . 58
5.5. Key Material Packet . . . . . . . . . . . . . . . . . . . 56 5.4. One-Pass Signature Packets (Tag 4) . . . . . . . . . . . 59
5.5.1. Key Packet Variants . . . . . . . . . . . . . . . . . 56 5.5. Key Material Packet . . . . . . . . . . . . . . . . . . . 60
5.5.1.1. Public-Key Packet (Tag 6) . . . . . . . . . . . . 56 5.5.1. Key Packet Variants . . . . . . . . . . . . . . . . . 60
5.5.1.2. Public-Subkey Packet (Tag 14) . . . . . . . . . . 57 5.5.1.1. Public-Key Packet (Tag 6) . . . . . . . . . . . . 61
5.5.1.3. Secret-Key Packet (Tag 5) . . . . . . . . . . . . 57 5.5.1.2. Public-Subkey Packet (Tag 14) . . . . . . . . . . 61
5.5.1.4. Secret-Subkey Packet (Tag 7) . . . . . . . . . . 57 5.5.1.3. Secret-Key Packet (Tag 5) . . . . . . . . . . . . 61
5.5.2. Public-Key Packet Formats . . . . . . . . . . . . . . 57 5.5.1.4. Secret-Subkey Packet (Tag 7) . . . . . . . . . . 61
5.5.3. Secret-Key Packet Formats . . . . . . . . . . . . . . 59 5.5.2. Public-Key Packet Formats . . . . . . . . . . . . . . 61
5.6. Algorithm-specific Parts of Keys . . . . . . . . . . . . 61 5.5.3. Secret-Key Packet Formats . . . . . . . . . . . . . . 63
5.6.1. Algorithm-Specific Part for RSA Keys . . . . . . . . 62 5.5.4. Key IDs and Fingerprints . . . . . . . . . . . . . . 65
5.6.2. Algorithm-Specific Part for DSA Keys . . . . . . . . 62 5.5.5. Algorithm-specific Parts of Keys . . . . . . . . . . 67
5.6.3. Algorithm-Specific Part for Elgamal Keys . . . . . . 62 5.5.5.1. Algorithm-Specific Part for RSA Keys . . . . . . 67
5.6.4. Algorithm-Specific Part for ECDSA Keys . . . . . . . 63 5.5.5.2. Algorithm-Specific Part for DSA Keys . . . . . . 68
5.6.5. Algorithm-Specific Part for EdDSA Keys . . . . . . . 63 5.5.5.3. Algorithm-Specific Part for Elgamal Keys . . . . 68
5.6.6. Algorithm-Specific Part for ECDH Keys . . . . . . . . 63 5.5.5.4. Algorithm-Specific Part for ECDSA Keys . . . . . 68
5.6.6.1. ECDH Secret Key Material . . . . . . . . . . . . 64 5.5.5.5. Algorithm-Specific Part for EdDSA Keys . . . . . 69
5.7. Compressed Data Packet (Tag 8) . . . . . . . . . . . . . 65 5.5.5.6. Algorithm-Specific Part for ECDH Keys . . . . . . 69
5.8. Symmetrically Encrypted Data Packet (Tag 9) . . . . . . . 66 5.6. Compressed Data Packet (Tag 8) . . . . . . . . . . . . . 71
5.9. Marker Packet (Tag 10) . . . . . . . . . . . . . . . . . 67 5.7. Symmetrically Encrypted Data Packet (Tag 9) . . . . . . . 72
5.10. Literal Data Packet (Tag 11) . . . . . . . . . . . . . . 67 5.8. Marker Packet (Tag 10) . . . . . . . . . . . . . . . . . 73
5.10.1. Special Filename _CONSOLE (Deprecated) . . . . . . . 69 5.9. Literal Data Packet (Tag 11) . . . . . . . . . . . . . . 73
5.11. Trust Packet (Tag 12) . . . . . . . . . . . . . . . . . . 69 5.9.1. Special Filename _CONSOLE (Deprecated) . . . . . . . 75
5.12. User ID Packet (Tag 13) . . . . . . . . . . . . . . . . . 70 5.10. Trust Packet (Tag 12) . . . . . . . . . . . . . . . . . . 75
5.13. User Attribute Packet (Tag 17) . . . . . . . . . . . . . 70 5.11. User ID Packet (Tag 13) . . . . . . . . . . . . . . . . . 75
5.13.1. The Image Attribute Subpacket . . . . . . . . . . . 71 5.12. User Attribute Packet (Tag 17) . . . . . . . . . . . . . 75
5.14. Sym. Encrypted Integrity Protected Data Packet (Tag 5.12.1. The Image Attribute Subpacket . . . . . . . . . . . 76
18) . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag
5.14.1. Version 1 Sym. Encrypted Integrity Protected Data 18) . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Packet Format . . . . . . . . . . . . . . . . . . . . 72 5.13.1. Version 1 Sym. Encrypted Integrity Protected Data
5.14.2. Version 2 Sym. Encrypted Integrity Protected Data Packet Format . . . . . . . . . . . . . . . . . . . . 77
Packet Format . . . . . . . . . . . . . . . . . . . . 74 5.13.2. Version 2 Sym. Encrypted Integrity Protected Data
5.14.3. EAX Mode . . . . . . . . . . . . . . . . . . . . . . 76 Packet Format . . . . . . . . . . . . . . . . . . . . 80
5.14.4. OCB Mode . . . . . . . . . . . . . . . . . . . . . . 76 5.13.3. EAX Mode . . . . . . . . . . . . . . . . . . . . . . 81
5.14.5. GCM Mode . . . . . . . . . . . . . . . . . . . . . . 76 5.13.4. OCB Mode . . . . . . . . . . . . . . . . . . . . . . 82
5.15. Padding Packet (Tag 21) . . . . . . . . . . . . . . . . . 76 5.13.5. GCM Mode . . . . . . . . . . . . . . . . . . . . . . 82
6. Radix-64 Conversions . . . . . . . . . . . . . . . . . . . . 77 5.14. Padding Packet (Tag 21) . . . . . . . . . . . . . . . . . 82
6.1. An Implementation of the CRC-24 in "C" . . . . . . . . . 78 6. Radix-64 Conversions . . . . . . . . . . . . . . . . . . . . 83
6.2. Forming ASCII Armor . . . . . . . . . . . . . . . . . . . 78 6.1. Optional checksum . . . . . . . . . . . . . . . . . . . . 83
6.3. Encoding Binary in Radix-64 . . . . . . . . . . . . . . . 81 6.1.1. An Implementation of the CRC-24 in "C" . . . . . . . 84
6.4. Decoding Radix-64 . . . . . . . . . . . . . . . . . . . . 83 6.2. Forming ASCII Armor . . . . . . . . . . . . . . . . . . . 84
6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 83 6.3. Encoding Binary in Radix-64 . . . . . . . . . . . . . . . 87
6.6. Example of an ASCII Armored Message . . . . . . . . . . . 84 6.4. Decoding Radix-64 . . . . . . . . . . . . . . . . . . . . 89
7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 84 6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 89
7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 85 6.6. Example of an ASCII Armored Message . . . . . . . . . . . 90
8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 86 7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 90
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 87 7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 91
9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 87 8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 92
9.2. ECC Curves for OpenPGP . . . . . . . . . . . . . . . . . 89 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.2.1. Curve-Specific Wire Formats . . . . . . . . . . . . . 91 9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 93
9.3. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 92 9.2. ECC Curves for OpenPGP . . . . . . . . . . . . . . . . . 95
9.4. Compression Algorithms . . . . . . . . . . . . . . . . . 93 9.2.1. Curve-Specific Wire Formats . . . . . . . . . . . . . 97
9.5. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 93 9.3. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 98
9.6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . 94 9.4. Compression Algorithms . . . . . . . . . . . . . . . . . 99
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 9.5. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 99
10.1. New String-to-Key Specifier Types . . . . . . . . . . . 95 9.6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . 100
10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 101
10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 96 10.1. New String-to-Key Specifier Types . . . . . . . . . . . 101
10.2.1.1. Image Format Subpacket Types . . . . . . . . . . 96 10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 101
10.2.2. New Signature Subpackets . . . . . . . . . . . . . . 96 10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 101
10.2.2.1. Signature Notation Data Subpackets . . . . . . . 96 10.2.1.1. Image Format Subpacket Types . . . . . . . . . . 102
10.2.2. New Signature Subpackets . . . . . . . . . . . . . . 102
10.2.2.1. Signature Notation Data Subpackets . . . . . . . 102
10.2.2.2. Signature Notation Data Subpacket Notation 10.2.2.2. Signature Notation Data Subpacket Notation
Flags . . . . . . . . . . . . . . . . . . . . . . . 97 Flags . . . . . . . . . . . . . . . . . . . . . . . 103
10.2.2.3. Key Server Preference Extensions . . . . . . . . 97 10.2.2.3. Key Server Preference Extensions . . . . . . . . 103
10.2.2.4. Key Flags Extensions . . . . . . . . . . . . . . 97 10.2.2.4. Key Flags Extensions . . . . . . . . . . . . . . 103
10.2.2.5. Reason for Revocation Extensions . . . . . . . . 97 10.2.2.5. Reason for Revocation Extensions . . . . . . . . 103
10.2.2.6. Implementation Features . . . . . . . . . . . . 97 10.2.2.6. Implementation Features . . . . . . . . . . . . 103
10.2.3. New Packet Versions . . . . . . . . . . . . . . . . 98 10.2.3. New Packet Versions . . . . . . . . . . . . . . . . 104
10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 98 10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 104
10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 98 10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 104
10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 99 10.3.1.1. Elliptic Curve Algorithms . . . . . . . . . . . 105
10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 99 10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 105
10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 100 10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 105
10.3.5. Elliptic Curve Algorithms . . . . . . . . . . . . . 100 10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 106
10.4. Elliptic Curve Point and Scalar Wire Formats . . . . . . 100 10.3.5. Elliptic Curve Algorithms . . . . . . . . . . . . . 106
10.5. Changes to existing registries . . . . . . . . . . . . . 101 10.4. Elliptic Curve Point and Scalar Wire Formats . . . . . . 107
11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 101 10.5. Changes to existing registries . . . . . . . . . . . . . 107
11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 101 11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 107
11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 103 11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 108
11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 103 11.1.1. OpenPGP v5 Key Structure . . . . . . . . . . . . . . 108
11.3.1. Unwrapping Encrypted and Compressed Messages . . . . 104 11.1.2. OpenPGP v4 Key Structure . . . . . . . . . . . . . . 109
11.3.2. Additional Constraints on Packet Sequences . . . . . 104 11.1.3. OpenPGP v3 Key Structure . . . . . . . . . . . . . . 110
11.3.2.1. Packet Versions in Encrypted Messages . . . . . 105 11.1.4. Common requirements . . . . . . . . . . . . . . . . 110
11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 106 11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 112
12. Enhanced Key Formats . . . . . . . . . . . . . . . . . . . . 106 11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 112
12.1. Key Structures . . . . . . . . . . . . . . . . . . . . . 106 11.3.1. Unwrapping Encrypted and Compressed Messages . . . . 113
12.2. Key IDs and Fingerprints . . . . . . . . . . . . . . . . 107 11.3.2. Additional Constraints on Packet Sequences . . . . . 113
13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 108 11.3.2.1. Packet Versions in Encrypted Messages . . . . . 113
13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 109 11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 114
13.2. EC Point Wire Formats . . . . . . . . . . . . . . . . . 109 12. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 114
13.2.1. SEC1 EC Point Wire Format . . . . . . . . . . . . . 109 12.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 115
13.2.2. Prefixed Native EC Point Wire Format . . . . . . . . 110 12.2. EC Point Wire Formats . . . . . . . . . . . . . . . . . 115
13.2.3. Notes on EC Point Wire Formats . . . . . . . . . . . 110 12.2.1. SEC1 EC Point Wire Format . . . . . . . . . . . . . 115
13.3. EC Scalar Wire Formats . . . . . . . . . . . . . . . . . 110 12.2.2. Prefixed Native EC Point Wire Format . . . . . . . . 115
13.3.1. EC Octet String Wire Format . . . . . . . . . . . . 111 12.2.3. Notes on EC Point Wire Formats . . . . . . . . . . . 116
13.3.2. Elliptic Curve Prefixed Octet String Wire Format . . 112 12.3. EC Scalar Wire Formats . . . . . . . . . . . . . . . . . 116
13.4. Key Derivation Function . . . . . . . . . . . . . . . . 112 12.3.1. EC Octet String Wire Format . . . . . . . . . . . . 117
13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 113 12.3.2. Elliptic Curve Prefixed Octet String Wire Format . . 118
14. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 116 12.4. Key Derivation Function . . . . . . . . . . . . . . . . 118
14.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 116 12.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 119
14.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 116 12.5.1. ECDH Parameters . . . . . . . . . . . . . . . . . . 122
14.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 117 13. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 123
14.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 118 13.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 123
14.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 119 13.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 123
14.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . 119 13.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 124
14.3. Other Algorithm Preferences . . . . . . . . . . . . . . 120 13.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 124
14.3.1. Compression Preferences . . . . . . . . . . . . . . 120 13.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 126
14.3.1.1. Uncompressed . . . . . . . . . . . . . . . . . . 120 13.2.1. Plaintext . . . . . . . . . . . . . . . . . . . . . 126
14.3.2. Hash Algorithm Preferences . . . . . . . . . . . . . 120 13.3. Other Algorithm Preferences . . . . . . . . . . . . . . 127
14.4. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 121 13.3.1. Compression Preferences . . . . . . . . . . . . . . 127
14.5. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . 121 13.3.1.1. Uncompressed . . . . . . . . . . . . . . . . . . 127
14.6. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 121 13.3.2. Hash Algorithm Preferences . . . . . . . . . . . . . 127
14.7. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 122 13.4. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 128
14.8. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 122 13.5. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . 128
14.9. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 122 13.6. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 128
14.10. Private or Experimental Parameters . . . . . . . . . . . 124 13.7. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 128
14.11. Meta-Considerations for Expansion . . . . . . . . . . . 124 13.8. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 129
15. Security Considerations . . . . . . . . . . . . . . . . . . . 124 13.9. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 129
15.1. Avoiding Ciphertext Malleability . . . . . . . . . . . . 128 13.10. Private or Experimental Parameters . . . . . . . . . . . 131
15.2. Escrowed Revocation Signatures . . . . . . . . . . . . . 130 13.11. Meta-Considerations for Expansion . . . . . . . . . . . 131
15.3. Random Number Generation and Seeding . . . . . . . . . . 131 14. Security Considerations . . . . . . . . . . . . . . . . . . . 131
15.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 131 14.1. SHA-1 Collision Detection . . . . . . . . . . . . . . . 133
16. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 132 14.2. Advantages of Salted Signatures . . . . . . . . . . . . 134
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 133 14.3. Elliptic Curve Side Channels . . . . . . . . . . . . . . 134
17.1. Normative References . . . . . . . . . . . . . . . . . . 133 14.4. Risks of a Quick Check Oracle . . . . . . . . . . . . . 135
17.2. Informative References . . . . . . . . . . . . . . . . . 136 14.5. Avoiding Leaks From PKCS#1 Errors . . . . . . . . . . . 135
Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 138 14.6. Fingerprint Usability . . . . . . . . . . . . . . . . . 136
A.1. Sample EdDSA key . . . . . . . . . . . . . . . . . . . . 138 14.7. Avoiding Ciphertext Malleability . . . . . . . . . . . . 137
A.2. Sample EdDSA signature . . . . . . . . . . . . . . . . . 138 14.8. Escrowed Revocation Signatures . . . . . . . . . . . . . 138
A.3. Sample AEAD-EAX encryption and decryption . . . . . . . . 139 14.9. Random Number Generation and Seeding . . . . . . . . . . 139
A.3.1. Sample Parameters . . . . . . . . . . . . . . . . . . 139 14.10. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 140
A.3.2. Sample symmetric-key encrypted session key packet 14.11. Surreptitious Forwarding . . . . . . . . . . . . . . . . 140
(v5) . . . . . . . . . . . . . . . . . . . . . . . . 139
A.3.3. Starting AEAD-EAX decryption of the session key . . . 140
A.3.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 140
A.3.5. Decryption of data . . . . . . . . . . . . . . . . . 141
A.3.6. Complete AEAD-EAX encrypted packet sequence . . . . . 142
A.4. Sample AEAD-OCB encryption and decryption . . . . . . . . 142 15. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 141
A.4.1. Sample Parameters . . . . . . . . . . . . . . . . . . 142 15.1. Constrained Legacy Fingerprint Storage for v5 Keys . . . 142
A.4.2. Sample symmetric-key encrypted session key packet 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 142
(v5) . . . . . . . . . . . . . . . . . . . . . . . . 143 16.1. Normative References . . . . . . . . . . . . . . . . . . 142
A.4.3. Starting AEAD-EAX decryption of the session key . . . 143 16.2. Informative References . . . . . . . . . . . . . . . . . 145
A.4.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 144 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 148
A.4.5. Decryption of data . . . . . . . . . . . . . . . . . 144 A.1. Sample v4 Ed25519 key . . . . . . . . . . . . . . . . . . 148
A.4.6. Complete AEAD-EAX encrypted packet sequence . . . . . 145 A.2. Sample v4 Ed25519 signature . . . . . . . . . . . . . . . 149
A.5. Sample AEAD-GCM encryption and decryption . . . . . . . . 146 A.3. Sample v5 Certificate (Transferable Public Key) . . . . . 150
A.5.1. Sample Parameters . . . . . . . . . . . . . . . . . . 146 A.4. Sample v5 Secret Key (Transferable Secret Key) . . . . . 150
A.5. Sample AEAD-EAX encryption and decryption . . . . . . . . 151
A.5.1. Sample Parameters . . . . . . . . . . . . . . . . . . 151
A.5.2. Sample symmetric-key encrypted session key packet A.5.2. Sample symmetric-key encrypted session key packet
(v5) . . . . . . . . . . . . . . . . . . . . . . . . 146 (v5) . . . . . . . . . . . . . . . . . . . . . . . . 152
A.5.3. Starting AEAD-EAX decryption of the session key . . . 146 A.5.3. Starting AEAD-EAX decryption of the session key . . . 152
A.5.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 147 A.5.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 153
A.5.5. Decryption of data . . . . . . . . . . . . . . . . . 148 A.5.5. Decryption of data . . . . . . . . . . . . . . . . . 153
A.5.6. Complete AEAD-EAX encrypted packet sequence . . . . . 149 A.5.6. Complete AEAD-EAX encrypted packet sequence . . . . . 154
A.6. Sample message encrypted using Argon2 . . . . . . . . . . 149 A.6. Sample AEAD-OCB encryption and decryption . . . . . . . . 154
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 150 A.6.1. Sample Parameters . . . . . . . . . . . . . . . . . . 155
Appendix C. Document Workflow . . . . . . . . . . . . . . . . . 150 A.6.2. Sample symmetric-key encrypted session key packet
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 150 (v5) . . . . . . . . . . . . . . . . . . . . . . . . 155
A.6.3. Starting AEAD-OCB decryption of the session key . . . 155
A.6.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 156
A.6.5. Decryption of data . . . . . . . . . . . . . . . . . 156
A.6.6. Complete AEAD-OCB encrypted packet sequence . . . . . 157
A.7. Sample AEAD-GCM encryption and decryption . . . . . . . . 158
A.7.1. Sample Parameters . . . . . . . . . . . . . . . . . . 158
A.7.2. Sample symmetric-key encrypted session key packet
(v5) . . . . . . . . . . . . . . . . . . . . . . . . 158
A.7.3. Starting AEAD-GCM decryption of the session key . . . 159
A.7.4. Sample v2 SEIPD packet . . . . . . . . . . . . . . . 159
A.7.5. Decryption of data . . . . . . . . . . . . . . . . . 160
A.7.6. Complete AEAD-GCM encrypted packet sequence . . . . . 161
A.8. Sample messages encrypted using Argon2 . . . . . . . . . 161
A.8.1. v4 SKESK using Argon2 with AES-128 . . . . . . . . . 161
A.8.2. v4 SKESK using Argon2 with AES-192 . . . . . . . . . 161
A.8.3. v4 SKESK using Argon2 with AES-256 . . . . . . . . . 162
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 162
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC 4880, "OpenPGP and key management functions. It is a revision of RFC 4880, "OpenPGP
Message Format", which is a revision of RFC 2440, which itself Message Format", which is a revision of RFC 2440, which itself
replaces RFC 1991, "PGP Message Exchange Formats" [RFC1991] [RFC2440] replaces RFC 1991, "PGP Message Exchange Formats" [RFC1991] [RFC2440]
[RFC4880]. [RFC4880].
skipping to change at page 8, line 21 skipping to change at page 8, line 46
implementation that avoids all encumbered algorithms. implementation that avoids all encumbered algorithms.
Consequently, early versions of GnuPG did not include RSA public Consequently, early versions of GnuPG did not include RSA public
keys. keys.
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP
Corporation and are used with permission. The term "OpenPGP" refers Corporation and are used with permission. The term "OpenPGP" refers
to the protocol described in this and related documents. to the protocol described in this and related documents.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The key words "PRIVATE USE", "SPECIFICATION REQUIRED", and "RFC The key words "PRIVATE USE", "SPECIFICATION REQUIRED", and "RFC
REQUIRED" that appear in this document when used to describe REQUIRED" that appear in this document when used to describe
namespace allocation are to be interpreted as described in [RFC8126]. namespace allocation are to be interpreted as described in [RFC8126].
2. General functions 2. General functions
OpenPGP provides data integrity services for messages and data files OpenPGP provides data integrity services for messages and data files
by using these core technologies: by using these core technologies:
skipping to change at page 11, line 22 skipping to change at page 11, line 48
of the MPI in bits followed by a string of octets that contain the of the MPI in bits followed by a string of octets that contain the
actual integer. actual integer.
These octets form a big-endian number; a big-endian number can be These octets form a big-endian number; a big-endian number can be
made into an MPI by prefixing it with the appropriate length. made into an MPI by prefixing it with the appropriate length.
Examples: Examples:
(all numbers are in hexadecimal) (all numbers are in hexadecimal)
The string of octets [00 01 01] forms an MPI with the value 1. The The string of octets [00 00] forms an MPI with the value 0. The
string of octets [00 01 01] forms an MPI with the value 1. The
string [00 09 01 FF] forms an MPI with the value of 511. string [00 09 01 FF] forms an MPI with the value of 511.
Additional rules: Additional rules:
The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.
The length field of an MPI describes the length starting from its The length field of an MPI describes the length starting from its
most significant non-zero bit. Thus, the MPI [00 02 01] is not most significant non-zero bit. Thus, the MPI [00 02 01] is not
formed correctly. It should be [00 01 01]. formed correctly. It should be [00 01 01].
Unused bits of an MPI MUST be zero. Unused bits of an MPI MUST be zero.
Also note that when an MPI is encrypted, the length refers to the Also note that when an MPI is encrypted, the length refers to the
plaintext MPI. It may be ill-formed in its ciphertext. plaintext MPI. It may be ill-formed in its ciphertext.
3.2.1. Using MPIs to encode other data 3.2.1. Using MPIs to encode other data
Note that MPIs are used in some places used to encode non-integer Note that MPIs are used in some places used to encode non-integer
data, such as an elliptic curve point (see Section 13.2, or an octet data, such as an elliptic curve point (see Section 12.2, or an octet
string of known, fixed length (see Section 13.3). The wire string of known, fixed length (see Section 12.3). The wire
representation is the same: two octets of length in bits counted from representation is the same: two octets of length in bits counted from
the first non-zero bit, followed by the smallest series of octets the first non-zero bit, followed by the smallest series of octets
that can represent the value while stripping off any leading zero that can represent the value while stripping off any leading zero
octets. octets.
3.3. Key IDs 3.3. Key IDs
A Key ID is an eight-octet scalar that identifies a key. A Key ID is an eight-octet scalar that identifies a key.
Implementations SHOULD NOT assume that Key IDs are unique. Implementations SHOULD NOT assume that Key IDs are unique.
Section 12.2 describes how Key IDs are formed. Section 5.5.4 describes how Key IDs are formed.
3.4. Text 3.4. Text
Unless otherwise specified, the character set for text is the UTF-8 Unless otherwise specified, the character set for text is the UTF-8
[RFC3629] encoding of Unicode [ISO10646]. [RFC3629] encoding of Unicode [ISO10646].
3.5. Time Fields 3.5. Time Fields
A time field is an unsigned four-octet number containing the number A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC. of seconds elapsed since midnight, 1 January 1970 UTC.
skipping to change at page 16, line 41 skipping to change at page 17, line 12
was unencrypted. The MD5 hash function was always used to convert was unencrypted. The MD5 hash function was always used to convert
the passphrase to a key for the specified cipher algorithm. the passphrase to a key for the specified cipher algorithm.
For compatibility, when an S2K specifier is used, the special value For compatibility, when an S2K specifier is used, the special value
253, 254, or 255 is stored in the position where the cipher algorithm 253, 254, or 255 is stored in the position where the cipher algorithm
octet would have been in the old data structure. This is then octet would have been in the old data structure. This is then
followed immediately by a one-octet algorithm identifier, and other followed immediately by a one-octet algorithm identifier, and other
fields relevant to the type of encryption used. fields relevant to the type of encryption used.
Therefore, the first octet of the secret key material describes how Therefore, the first octet of the secret key material describes how
the secret key data is presented. the secret key data is presented. The structures differ based on the
version of the enclosing OpenPGP packet. The tables below summarize
the details described in Section 5.5.3.
In the table below, check(x) means the "2-octet checksum" meaning the In the tables below, check(x) means the "2-octet checksum" meaning
sum of all octets in x mod 65536. the sum of all octets in x mod 65536.
+==============+================+=====================+===========+ +==============+================+=====================+===========+
| First octet | Next fields | Encryption | Generate? | | First octet | Encryption | Encryption | Generate? |
| | parameter | | |
| | fields | | |
+==============+================+=====================+===========+ +==============+================+=====================+===========+
| 0 | - | cleartext | Yes | | 0 | - | cleartext | Yes |
| | | secrets || | | | | | secrets || | |
| | | check(secrets) | | | | | check(secrets) | |
+--------------+----------------+---------------------+-----------+ +--------------+----------------+---------------------+-----------+
| Known | IV | CFB(MD5(password), | No | | Known | IV | CFB(MD5(password), | No |
| symmetric | | secrets || | | | symmetric | | secrets || | |
| cipher algo | | check(secrets)) | | | cipher algo | | check(secrets)) | |
| ID (see | | | | | ID (see | | | |
| Section 9.3) | | | | | Section 9.3) | | | |
skipping to change at page 17, line 32 skipping to change at page 17, line 48
+--------------+----------------+---------------------+-----------+ +--------------+----------------+---------------------+-----------+
| 254 | cipher-algo, | CFB(S2K(password), | Yes | | 254 | cipher-algo, | CFB(S2K(password), | Yes |
| | S2K-specifier, | secrets || | | | | S2K-specifier, | secrets || | |
| | IV | SHA1(secrets)) | | | | IV | SHA1(secrets)) | |
+--------------+----------------+---------------------+-----------+ +--------------+----------------+---------------------+-----------+
| 255 | cipher-algo, | CFB(S2K(password), | No | | 255 | cipher-algo, | CFB(S2K(password), | No |
| | S2K-specifier, | secrets || | | | | S2K-specifier, | secrets || | |
| | IV | check(secrets)) | | | | IV | check(secrets)) | |
+--------------+----------------+---------------------+-----------+ +--------------+----------------+---------------------+-----------+
Table 2: Secret Key protection details Table 2: Version 4 Secret Key protection details
Each row with "Generate?" marked as "No" is described for backward Each row with "Generate?" marked as "No" is described for backward
compatibility, and MUST NOT be generated. compatibility, and MUST NOT be generated.
A version 5 secret key that is cryptographically protected is stored
with an additional pair of length counts, each of which is one octet
wide:
+=======+==============================+======================+
| First | Encryption parameter fields | Encryption |
| octet | | |
+=======+==============================+======================+
| 0 | - | cleartext secrets || |
| | | check(secrets) |
+-------+------------------------------+----------------------+
| 253 | params-length, cipher-algo, | AEAD(S2K(password), |
| | AEAD-mode, S2K-specifier- | secrets, pubkey) |
| | length, S2K-specifier, nonce | |
+-------+------------------------------+----------------------+
| 254 | params-length, cipher-algo, | CFB(S2K(password), |
| | S2K-specifier-length, S2K- | secrets || |
| | specifier, IV | SHA1(secrets)) |
+-------+------------------------------+----------------------+
Table 3: Version 5 Secret Key protection details
An implementation MUST NOT create and MUST reject as malformed a An implementation MUST NOT create and MUST reject as malformed a
secret key packet where the S2K usage octet is anything but 253 and secret key packet where the S2K usage octet is anything but 253 and
the S2K specifier type is Argon2. the S2K specifier type is Argon2.
3.7.2.2. Symmetric-Key Message Encryption 3.7.2.2. Symmetric-Key Message Encryption
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet
at the front of a message. This is used to allow S2K specifiers to at the front of a message. This is used to allow S2K specifiers to
be used for the passphrase conversion or to create messages with a be used for the passphrase conversion or to create messages with a
mix of symmetric-key ESKs and public-key ESKs. This allows a message mix of symmetric-key ESKs and public-key ESKs. This allows a message
to be decrypted either with a passphrase or a public-key pair. to be decrypted either with a passphrase or a public-key pair.
PGP 2 always used IDEA with Simple string-to-key conversion when PGP 2 always used IDEA with Simple string-to-key conversion when
encrypting a message with a symmetric algorithm. See Section 5.8. encrypting a message with a symmetric algorithm. See Section 5.7.
This MUST NOT be generated, but MAY be consumed for backward- This MUST NOT be generated, but MAY be consumed for backward-
compatibility. compatibility.
4. Packet Syntax 4. Packet Syntax
This section describes the packets used by OpenPGP. This section describes the packets used by OpenPGP.
4.1. Overview 4.1. Overview
An OpenPGP message is constructed from a number of records that are An OpenPGP message is constructed from a number of records that are
skipping to change at page 22, line 16 skipping to change at page 23, line 12
the packet is the length of the header(s) plus the length of the the packet is the length of the header(s) plus the length of the
body. body.
4.3. Packet Tags 4.3. Packet Tags
The packet tag denotes what type of packet the body holds. Note that The packet tag denotes what type of packet the body holds. Note that
Legacy format headers can only have tags less than 16, whereas Legacy format headers can only have tags less than 16, whereas
OpenPGP format headers can have tags as great as 63. The defined OpenPGP format headers can have tags as great as 63. The defined
tags (in decimal) are as follows: tags (in decimal) are as follows:
+==========+========================================================+ +=======+==========+=================================+
| Tag | Packet Type | | Tag | Critical | Packet Type |
+==========+========================================================+ +=======+==========+=================================+
| 0 | Reserved - a packet tag MUST NOT have this value | | 0 | yes | Reserved - a packet tag MUST |
+----------+--------------------------------------------------------+ | | | NOT have this value |
| 1 | Public-Key Encrypted Session Key Packet | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 1 | yes | Public-Key Encrypted Session |
| 2 | Signature Packet | | | | Key Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 3 | Symmetric-Key Encrypted Session Key Packet | | 2 | yes | Signature Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 4 | One-Pass Signature Packet | | 3 | yes | Symmetric-Key Encrypted Session |
+----------+--------------------------------------------------------+ | | | Key Packet |
| 5 | Secret-Key Packet | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 4 | yes | One-Pass Signature Packet |
| 6 | Public-Key Packet | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 5 | yes | Secret-Key Packet |
| 7 | Secret-Subkey Packet | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 6 | yes | Public-Key Packet |
| 8 | Compressed Data Packet | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 7 | yes | Secret-Subkey Packet |
| 9 | Symmetrically Encrypted Data Packet | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 8 | yes | Compressed Data Packet |
| 10 | Marker Packet | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 9 | yes | Symmetrically Encrypted Data |
| 11 | Literal Data Packet | | | | Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 12 | Trust Packet | | 10 | yes | Marker Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 13 | User ID Packet | | 11 | yes | Literal Data Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 14 | Public-Subkey Packet | | 12 | yes | Trust Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 17 | User Attribute Packet | | 13 | yes | User ID Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 18 | Sym. Encrypted and Integrity Protected Data Packet | | 14 | yes | Public-Subkey Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 19 | Reserved (formerly Modification Detection Code Packet) | | 17 | yes | User Attribute Packet |
+----------+--------------------------------------------------------+ +-------+----------+---------------------------------+
| 20 | Reserved (formerly AEAD Encrypted Data Packet) | | 18 | yes | Sym. Encrypted and Integrity |
+----------+--------------------------------------------------------+ | | | Protected Data Packet |
| 21 | Padding Packet | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 19 | yes | Reserved (formerly Modification |
| 60 to | Private or Experimental Values | | | | Detection Code Packet) |
| 63 | | +-------+----------+---------------------------------+
+----------+--------------------------------------------------------+ | 20 | yes | Reserved (formerly AEAD |
| | | Encrypted Data Packet) |
+-------+----------+---------------------------------+
| 21 | yes | Padding Packet |
+-------+----------+---------------------------------+
| 22 to | yes | Unassigned Critical Packet |
| 39 | | |
+-------+----------+---------------------------------+
| 40 to | no | Unassigned Non-Critical Packet |
| 59 | | |
+-------+----------+---------------------------------+
| 60 to | no | Private or Experimental Values |
| 63 | | |
+-------+----------+---------------------------------+
Table 3: Packet type registry Table 4: Packet type registry
4.3.1. Packet Criticality
The Packet Tag space is partitioned into critical packets and non-
critical packets. If an implementation encounters a critical packet
where the packet type is unknown in a Packet Sequence, it MUST reject
the whole Packet Sequence (see Section 11). On the other hand, an
unknown non-critical packet MUST be ignored.
Packet Tags from 0 to 39 are critical. Packet Tags from 40 to 63 are
non-critical.
5. Packet Types 5. Packet Types
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 5.1. Public-Key Encrypted Session Key Packets (Tag 1)
Zero or more Public-Key Encrypted Session Key (PKESK) packets and/or Zero or more Public-Key Encrypted Session Key (PKESK) packets and/or
Symmetric-Key Encrypted Session Key packets (Section 5.3) may precede Symmetric-Key Encrypted Session Key packets (Section 5.3) may precede
an encryption container (that is, a Symmetrically Encrypted Integrity an encryption container (that is, a Symmetrically Encrypted Integrity
Protected Data packet or --- for historic data --- a Symmetrically Protected Data packet or --- for historic data --- a Symmetrically
Encrypted Data packet), which holds an encrypted message. The Encrypted Data packet), which holds an encrypted message. The
skipping to change at page 23, line 45 skipping to change at page 25, line 17
are 3 and 5. The remainder of the packet depends on the version. are 3 and 5. The remainder of the packet depends on the version.
The versions differ in how they identify the recipient key, and in The versions differ in how they identify the recipient key, and in
what they encode. The version of the PKESK packet must align with what they encode. The version of the PKESK packet must align with
the version of the SEIPD packet (see Section 11.3.2.1). the version of the SEIPD packet (see Section 11.3.2.1).
5.1.1. v3 PKESK 5.1.1. v3 PKESK
A version 3 Public-Key Encrypted Session Key (PKESK) packet precedes A version 3 Public-Key Encrypted Session Key (PKESK) packet precedes
a version 1 Symmetrically Encrypted Integrity Protected Data (v1 a version 1 Symmetrically Encrypted Integrity Protected Data (v1
SEIPD, see Section 5.14.1) packet. In historic data, it is sometimes SEIPD, see Section 5.13.1) packet. In historic data, it is sometimes
found preceding a deprecated Symmetrically Encrypted Data packet found preceding a deprecated Symmetrically Encrypted Data packet
(SED, see Section 5.8). A v3 PKESK packet MUST NOT precede a v2 (SED, see Section 5.7). A v3 PKESK packet MUST NOT precede a v2
SEIPD packet (see Section 11.3.2.1). SEIPD packet (see Section 11.3.2.1).
The v3 PKESK packet consists of: The v3 PKESK packet consists of:
* A one-octet version number with value 3. * A one-octet version number with value 3.
* An eight-octet number that gives the Key ID of the public key to * An eight-octet number that gives the Key ID of the public key to
which the session key is encrypted. If the session key is which the session key is encrypted. If the session key is
encrypted to a subkey, then the Key ID of this subkey is used here encrypted to a subkey, then the Key ID of this subkey is used here
instead of the Key ID of the primary key. The Key ID may also be instead of the Key ID of the primary key. The Key ID may also be
skipping to change at page 24, line 33 skipping to change at page 26, line 9
algorithm identifier, modulo 65536. algorithm identifier, modulo 65536.
The resulting octet string (algorithm identifier, session key, and The resulting octet string (algorithm identifier, session key, and
checksum) is encrypted according to the public-key algorithm used, as checksum) is encrypted according to the public-key algorithm used, as
described below. described below.
5.1.2. v5 PKESK 5.1.2. v5 PKESK
A version 5 Public-Key Encrypted Session Key (PKESK) packet precedes A version 5 Public-Key Encrypted Session Key (PKESK) packet precedes
a version 2 Symmetrically Encrypted Integrity Protected Data (v2 a version 2 Symmetrically Encrypted Integrity Protected Data (v2
SEIPD, see Section 5.14.2) packet. A v5 PKESK packet MUST NOT SEIPD, see Section 5.13.2) packet. A v5 PKESK packet MUST NOT
precede a v1 SEIPD packet or a deprecated Symmetrically Encrypted precede a v1 SEIPD packet or a deprecated Symmetrically Encrypted
Data packet (see Section 11.3.2.1). Data packet (see Section 11.3.2.1).
The v5 PKESK packet consists of: The v5 PKESK packet consists of:
* A one-octet version number with value 5. * A one-octet version number with value 5.
* A one octet key version number and N octets of the fingerprint of * A one octet key version number and N octets of the fingerprint of
the public key or subkey to which the session key is encrypted. the public key or subkey to which the session key is encrypted.
Note that the length N of the fingerprint for a version 4 key is Note that the length N of the fingerprint for a version 4 key is
20 octets; for a version 5 key N is 32. The key version number 20 octets; for a version 5 key N is 32. The key version number
may also be zero, and the fingerprint omitted (that is, the length may also be zero, and the fingerprint omitted (that is, the length
N is zero in this case), for an "anonymous recipient" (see N is zero in this case), for an "anonymous recipient" (see
Section 5.1.6). Section 5.1.6).
* A one-octet number giving the public-key algorithm used. * A one-octet number giving the public-key algorithm used.
* A series of values comprising the encrypted session key. This is * A series of values comprising the encrypted session key. This is
algorithm-specific and described below. algorithm-specific and described below.
When creating a V5 PKESK packet, the symmetric encryption algorithm When creating a v5 PKESK packet, the symmetric encryption algorithm
identifier is not included. Before encrypting, a two-octet checksum identifier is not included. Before encrypting, a two-octet checksum
is appended, which is equal to the sum of the preceding session key is appended, which is equal to the sum of the preceding session key
octets, modulo 65536. octets, modulo 65536.
The resulting octet string (session key and checksum) is encrypted The resulting octet string (session key and checksum) is encrypted
according to the public-key algorithm used, as described below. according to the public-key algorithm used, as described below.
5.1.3. Algorithm Specific Fields for RSA encryption 5.1.3. Algorithm-Specific Fields for RSA encryption
* Multiprecision integer (MPI) of RSA-encrypted value m**e mod n. * Multiprecision integer (MPI) of RSA-encrypted value m**e mod n.
The value "m" in the above formula is the plaintext value described The value "m" in the above formula is the plaintext value described
above, encoded in the PKCS#1 block encoding EME-PKCS1-v1_5 described above, encoded in the PKCS#1 block encoding EME-PKCS1-v1_5 described
in Section 7.2.1 of [RFC8017] (see also Section 14.1). Note that in Section 7.2.1 of [RFC8017] (see also Section 13.1). Note that
when an implementation forms several PKESKs with one session key, when an implementation forms several PKESKs with one session key,
forming a message that can be decrypted by several keys, the forming a message that can be decrypted by several keys, the
implementation MUST make a new PKCS#1 encoding for each key. implementation MUST make a new PKCS#1 encoding for each key.
5.1.4. Algorithm Specific Fields for Elgamal encryption 5.1.4. Algorithm-Specific Fields for Elgamal encryption
* MPI of Elgamal (Diffie-Hellman) value g**k mod p. * MPI of Elgamal (Diffie-Hellman) value g**k mod p.
* MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. * MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
The value "m" in the above formula is the plaintext value described The value "m" in the above formula is the plaintext value described
above, encoded in the PKCS#1 block encoding EME-PKCS1-v1_5 described above, encoded in the PKCS#1 block encoding EME-PKCS1-v1_5 described
in Section 7.2.1 of [RFC8017] (see also Section 14.1). Note that in Section 7.2.1 of [RFC8017] (see also Section 13.1). Note that
when an implementation forms several PKESKs with one session key, when an implementation forms several PKESKs with one session key,
forming a message that can be decrypted by several keys, the forming a message that can be decrypted by several keys, the
implementation MUST make a new PKCS#1 encoding for each key. implementation MUST make a new PKCS#1 encoding for each key.
5.1.5. Algorithm-Specific Fields for ECDH encryption 5.1.5. Algorithm-Specific Fields for ECDH encryption
* MPI of an EC point representing an ephemeral public key, in the * MPI of an EC point representing an ephemeral public key, in the
point format associated with the curve as specified in point format associated with the curve as specified in
Section 9.2. Section 9.2.
* A one-octet size, followed by a symmetric key encoded using the * A one-octet size, followed by a symmetric key encoded using the
method described in Section 13.5. method described in Section 12.5.
5.1.6. Notes on PKESK 5.1.6. Notes on PKESK
An implementation MAY accept or use a Key ID of all zeros, or a key An implementation MAY accept or use a Key ID of all zeros, or a key
version of zero and no key fingerprint, to hide the intended version of zero and no key fingerprint, to hide the intended
decryption key. In this case, the receiving implementation would try decryption key. In this case, the receiving implementation would try
all available private keys, checking for a valid decrypted session all available private keys, checking for a valid decrypted session
key. This format helps reduce traffic analysis of messages. key. This format helps reduce traffic analysis of messages.
5.2. Signature Packet (Tag 2) 5.2. Signature Packet (Tag 2)
skipping to change at page 29, line 12 skipping to change at page 30, line 38
* Eight-octet Key ID of signer. * Eight-octet Key ID of signer.
* One-octet public-key algorithm. * One-octet public-key algorithm.
* One-octet hash algorithm. * One-octet hash algorithm.
* Two-octet field holding left 16 bits of signed hash value. * Two-octet field holding left 16 bits of signed hash value.
* One or more multiprecision integers comprising the signature. * One or more multiprecision integers comprising the signature.
This portion is algorithm specific, as described below. This portion is algorithm-specific, as described below.
The concatenation of the data to be signed, the signature type, and The concatenation of the data to be signed, the signature type, and
creation time from the Signature packet (5 additional octets) is creation time from the Signature packet (5 additional octets) is
hashed. The resulting hash value is used in the signature algorithm. hashed. The resulting hash value is used in the signature algorithm.
The high 16 bits (first two octets) of the hash are included in the The high 16 bits (first two octets) of the hash are included in the
Signature packet to provide a way to reject some invalid signatures Signature packet to provide a way to reject some invalid signatures
without performing a signature verification. without performing a signature verification.
Algorithm-Specific Fields for RSA signatures: Algorithm-Specific Fields for RSA signatures:
skipping to change at page 30, line 27 skipping to change at page 31, line 42
| SHA256 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, | | SHA256 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, |
| | 0x02, 0x01 | | | 0x02, 0x01 |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| SHA384 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, | | SHA384 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, |
| | 0x02, 0x02 | | | 0x02, 0x02 |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| SHA512 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, | | SHA512 | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, |
| | 0x02, 0x03 | | | 0x02, 0x03 |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
Table 4: Hash hexadecimal representations Table 5: Hash hexadecimal representations
The ASN.1 Object Identifiers (OIDs) are as follows: The ASN.1 Object Identifiers (OIDs) are as follows:
+============+========================+ +============+========================+
| algorithm | OID | | algorithm | OID |
+============+========================+ +============+========================+
| MD5 | 1.2.840.113549.2.5 | | MD5 | 1.2.840.113549.2.5 |
+------------+------------------------+ +------------+------------------------+
| RIPEMD-160 | 1.3.36.3.2.1 | | RIPEMD-160 | 1.3.36.3.2.1 |
+------------+------------------------+ +------------+------------------------+
skipping to change at page 30, line 49 skipping to change at page 32, line 23
+------------+------------------------+ +------------+------------------------+
| SHA224 | 2.16.840.1.101.3.4.2.4 | | SHA224 | 2.16.840.1.101.3.4.2.4 |
+------------+------------------------+ +------------+------------------------+
| SHA256 | 2.16.840.1.101.3.4.2.1 | | SHA256 | 2.16.840.1.101.3.4.2.1 |
+------------+------------------------+ +------------+------------------------+
| SHA384 | 2.16.840.1.101.3.4.2.2 | | SHA384 | 2.16.840.1.101.3.4.2.2 |
+------------+------------------------+ +------------+------------------------+
| SHA512 | 2.16.840.1.101.3.4.2.3 | | SHA512 | 2.16.840.1.101.3.4.2.3 |
+------------+------------------------+ +------------+------------------------+
Table 5: Hash OIDs Table 6: Hash OIDs
The full hash prefixes for these are as follows: The full hash prefixes for these are as follows:
+============+==========================================+ +============+==========================================+
| algorithm | full hash prefix | | algorithm | full hash prefix |
+============+==========================================+ +============+==========================================+
| MD5 | 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, | | MD5 | 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, |
| | 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, | | | 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, |
| | 0x02, 0x05, 0x05, 0x00, 0x04, 0x10 | | | 0x02, 0x05, 0x05, 0x00, 0x04, 0x10 |
+------------+------------------------------------------+ +------------+------------------------------------------+
skipping to change at page 31, line 37 skipping to change at page 33, line 37
+------------+------------------------------------------+ +------------+------------------------------------------+
| SHA384 | 0x30, 0x41, 0x30, 0x0D, 0x06, 0x09, | | SHA384 | 0x30, 0x41, 0x30, 0x0D, 0x06, 0x09, |
| | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, |
| | 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30 | | | 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30 |
+------------+------------------------------------------+ +------------+------------------------------------------+
| SHA512 | 0x30, 0x51, 0x30, 0x0D, 0x06, 0x09, | | SHA512 | 0x30, 0x51, 0x30, 0x0D, 0x06, 0x09, |
| | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, |
| | 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40 | | | 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40 |
+------------+------------------------------------------+ +------------+------------------------------------------+
Table 6: Hash hexadecimal prefixes Table 7: Hash hexadecimal prefixes
DSA signatures MUST use hashes that are equal in size to the number DSA signatures MUST use hashes that are equal in size to the number
of bits of q, the group generated by the DSA key's generator value. of bits of q, the group generated by the DSA key's generator value.
If the output size of the chosen hash is larger than the number of If the output size of the chosen hash is larger than the number of
bits of q, the hash result is truncated to fit by taking the number bits of q, the hash result is truncated to fit by taking the number
of leftmost bits equal to the number of bits of q. This (possibly of leftmost bits equal to the number of bits of q. This (possibly
truncated) hash function result is treated as a number and used truncated) hash function result is treated as a number and used
directly in the DSA signature algorithm. directly in the DSA signature algorithm.
5.2.3. Version 4 and 5 Signature Packet Formats 5.2.3. Version 4 and 5 Signature Packet Formats
The body of a V4 or V5 Signature packet contains: The body of a v4 or v5 Signature packet contains:
* One-octet version number. This is 4 for V4 signatures and 5 for * One-octet version number. This is 4 for v4 signatures and 5 for
V5 signatures. v5 signatures.
* One-octet signature type. * One-octet signature type.
* One-octet public-key algorithm. * One-octet public-key algorithm.
* One-octet hash algorithm. * One-octet hash algorithm.
* A scalar octet count for following hashed subpacket data. For a * A scalar octet count for following hashed subpacket data. For a
V4 signature, this is a two-octet field. For a V5 signature, this v4 signature, this is a two-octet field. For a v5 signature, this
is a four-octet field. Note that this is the length in octets of is a four-octet field. Note that this is the length in octets of
all of the hashed subpackets; a pointer incremented by this number all of the hashed subpackets; a pointer incremented by this number
will skip over the hashed subpackets. will skip over the hashed subpackets.
* Hashed subpacket data set (zero or more subpackets). * Hashed subpacket data set (zero or more subpackets).
* A scalar octet count for the following unhashed subpacket data. * A scalar octet count for the following unhashed subpacket data.
For a V4 signature, this is a two-octet field. For a V5 For a v4 signature, this is a two-octet field. For a v5
signature, this is a four-octet field. Note that this is the signature, this is a four-octet field. Note that this is the
length in octets of all of the unhashed subpackets; a pointer length in octets of all of the unhashed subpackets; a pointer
incremented by this number will skip over the unhashed subpackets. incremented by this number will skip over the unhashed subpackets.
* Unhashed subpacket data set (zero or more subpackets). * Unhashed subpacket data set (zero or more subpackets).
* Two-octet field holding the left 16 bits of the signed hash value. * Two-octet field holding the left 16 bits of the signed hash value.
* Only for V5 signatures, a 16 octet field containing random values * Only for v5 signatures, a 16 octet field containing random values
used as salt. used as salt.
* One or more multiprecision integers comprising the signature. * One or more multiprecision integers comprising the signature.
This portion is algorithm specific: This portion is algorithm-specific:
5.2.3.1. Algorithm-Specific Fields for RSA signatures 5.2.3.1. Algorithm-Specific Fields for RSA signatures
* Multiprecision integer (MPI) of RSA signature value m**d mod n. * Multiprecision integer (MPI) of RSA signature value m**d mod n.
5.2.3.2. Algorithm-Specific Fields for DSA or ECDSA signatures 5.2.3.2. Algorithm-Specific Fields for DSA or ECDSA signatures
* MPI of DSA or ECDSA value r. * MPI of DSA or ECDSA value r.
* MPI of DSA or ECDSA value s. * MPI of DSA or ECDSA value s.
skipping to change at page 33, line 26 skipping to change at page 35, line 26
(little-endian) octet string up to 32 octets. (little-endian) octet string up to 32 octets.
* MPI of EdDSA value S, also in (non-prefixed) native little-endian * MPI of EdDSA value S, also in (non-prefixed) native little-endian
format with a length up to 32 octets. format with a length up to 32 octets.
5.2.3.3.2. Algorithm-Specific Fields for Ed448 signatures 5.2.3.3.2. Algorithm-Specific Fields for Ed448 signatures
For Ed448 signatures, the native signature format is used as For Ed448 signatures, the native signature format is used as
described in [RFC8032]. The two MPIs are composed as follows: described in [RFC8032]. The two MPIs are composed as follows:
* The first MPI has a body of 58 octets: a prefix 0x40 octet, * The first MPI has a body of 115 octets: a prefix 0x40 octet,
followed by 57 octets of the native signature. followed by 114 octets of the native signature.
* The second MPI is set to 0 (this is a placeholder, and is unused). * The second MPI is set to 0 (this is a placeholder, and is unused).
Note that an MPI with a value of 0 is encoded on the wire as a Note that an MPI with a value of 0 is encoded on the wire as a
pair of zero octets: 00 00. pair of zero octets: 00 00.
5.2.3.4. Notes on Signatures 5.2.3.4. Notes on Signatures
The concatenation of the data being signed and the signature data The concatenation of the data being signed and the signature data
from the version number through the hashed subpacket data (inclusive) from the version number through the hashed subpacket data (inclusive)
is hashed. The resulting hash value is what is signed. The high 16 is hashed. The resulting hash value is what is signed. The high 16
bits (first two octets) of the hash are included in the Signature bits (first two octets) of the hash are included in the Signature
packet to provide a way to reject some invalid signatures without packet to provide a way to reject some invalid signatures without
performing a signature verification. performing a signature verification.
There are two fields consisting of Signature subpackets. The first There are two fields consisting of Signature subpackets. The first
field is hashed with the rest of the signature data, while the second field is hashed with the rest of the signature data, while the second
is unhashed. The second set of subpackets is not cryptographically is unhashed. The second set of subpackets is not cryptographically
protected by the signature and should include only advisory protected by the signature and should include only advisory
information. information.
The differences between a V4 and V5 signature are two-fold: first, a The differences between a v4 and v5 signature are two-fold: first, a
V5 signature increases the width of the size indicators for the v5 signature increases the width of the size indicators for the
signed data, making it more capable when signing large keys or signed data, making it more capable when signing large keys or
messages. Second, the hash is salted with 128 bit of random data. messages. Second, the hash is salted with 128 bit of random data
(see Section 14.2.
The algorithms for converting the hash function result to a signature The algorithms for converting the hash function result to a signature
are described in Section 5.2.4. are described in Section 5.2.4.
5.2.3.5. Signature Subpacket Specification 5.2.3.5. Signature Subpacket Specification
A subpacket data set consists of zero or more Signature subpackets. A subpacket data set consists of zero or more Signature subpackets.
In Signature packets, the subpacket data set is preceded by a two- In Signature packets, the subpacket data set is preceded by a two-
octet (for V4 signatures) or four-octet (for V5 signatures) scalar octet (for v4 signatures) or four-octet (for v5 signatures) scalar
count of the length in octets of all the subpackets. A pointer count of the length in octets of all the subpackets. A pointer
incremented by this number will skip over the subpacket data set. incremented by this number will skip over the subpacket data set.
Each subpacket consists of a subpacket header and a body. The header Each subpacket consists of a subpacket header and a body. The header
consists of: consists of:
* the subpacket length (1, 2, or 5 octets), * the subpacket length (1, 2, or 5 octets),
* the subpacket type (1 octet), * the subpacket type (1 octet),
skipping to change at page 35, line 25 skipping to change at page 37, line 36
| 9 | Key Expiration Time | | 9 | Key Expiration Time |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 10 | Placeholder for backward compatibility | | 10 | Placeholder for backward compatibility |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 11 | Preferred Symmetric Ciphers for v1 SEIPD | | 11 | Preferred Symmetric Ciphers for v1 SEIPD |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 12 | Revocation Key (deprecated) | | 12 | Revocation Key (deprecated) |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 13 to 15 | Reserved | | 13 to 15 | Reserved |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 16 | Issuer | | 16 | Issuer Key ID |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 17 to 19 | Reserved | | 17 to 19 | Reserved |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 20 | Notation Data | | 20 | Notation Data |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 21 | Preferred Hash Algorithms | | 21 | Preferred Hash Algorithms |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 22 | Preferred Compression Algorithms | | 22 | Preferred Compression Algorithms |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 23 | Key Server Preferences | | 23 | Key Server Preferences |
skipping to change at page 36, line 22 skipping to change at page 38, line 32
+------------+------------------------------------------+ +------------+------------------------------------------+
| 37 | Reserved (Attested Certifications) | | 37 | Reserved (Attested Certifications) |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 38 | Reserved (Key Block) | | 38 | Reserved (Key Block) |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 39 | Preferred AEAD Ciphersuites | | 39 | Preferred AEAD Ciphersuites |
+------------+------------------------------------------+ +------------+------------------------------------------+
| 100 to 110 | Private or experimental | | 100 to 110 | Private or experimental |
+------------+------------------------------------------+ +------------+------------------------------------------+
Table 7: Subpacket type registry Table 8: Subpacket type registry
An implementation SHOULD ignore any subpacket of a type that it does An implementation SHOULD ignore any subpacket of a type that it does
not recognize. not recognize.
Bit 7 of the subpacket type is the "critical" bit. If set, it Bit 7 of the subpacket type is the "critical" bit. If set, it
denotes that the subpacket is one that is critical for the evaluator denotes that the subpacket is one that is critical for the evaluator
of the signature to recognize. If a subpacket is encountered that is of the signature to recognize. If a subpacket is encountered that is
marked critical but is unknown to the evaluating software, the marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error. evaluator SHOULD consider the signature to be in error.
skipping to change at page 38, line 23 skipping to change at page 40, line 38
Since a self-signature contains important information about the key's Since a self-signature contains important information about the key's
use, an implementation SHOULD allow the user to rewrite the self- use, an implementation SHOULD allow the user to rewrite the self-
signature, and important information in it, such as preferences and signature, and important information in it, such as preferences and
key expiration. key expiration.
It is good practice to verify that a self-signature imported into an It is good practice to verify that a self-signature imported into an
implementation doesn't advertise features that the implementation implementation doesn't advertise features that the implementation
doesn't support, rewriting the signature as appropriate. doesn't support, rewriting the signature as appropriate.
An implementation that encounters multiple self-signatures on the An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but it same object MUST select the most recent valid self-signature, and
is RECOMMENDED that priority be given to the most recent self- ignore all other self-signatures.
signature.
By convention, a version 4 key stores information about the primary
Public-Key (key flags, key expiration, etc.) and the Transferable
Public Key as a whole (features, algorithm preferences, etc.) in a
User ID self-signature of type 0x10 or 0x13. Some implementations
require at least one User ID with a valid self-signature to be
present to use a v4 key. For this reason, it is RECOMMENDED to
include at least one User ID with a self-signature in v4 keys.
For version 5 keys, it is RECOMMENDED to store information about the
primary Public-Key as well as the Transferable Public Key as a whole
(key flags, key expiration, features, algorithm preferences, etc.) in
a direct-key signature (type 0x1F) over the Public-Key instead of
placing that information in a User ID self-signature. An
implementation MUST ensure that a valid direct-key signature is
present before using a v5 key. This prevents certain attacks where
an adversary strips a self-signature specifying a key expiration time
or certain preferences.
An implementation SHOULD NOT require a User ID self-signature to be
present in order to consume or use a key, unless the particular use
is contingent on the keyholder identifying themselves with the
textual label in the User ID. For example, when refreshing a key to
learn about changes in expiration, advertised features, algorithm
preferences, revocation, subkey rotation, and so forth, there is no
need to require a User ID self-signature. On the other hand, when
verifying a signature over an e-mail message, an implementation MAY
choose to only accept a signature from a key that has a valid self-
signature over a User ID that matches the message's From: header, as
a way to avoid a signature transplant attack.
5.2.3.8. Signature Creation Time 5.2.3.8. Signature Creation Time
(4-octet time field) (4-octet time field)
The time the signature was made. The time the signature was made.
MUST be present in the hashed area. MUST be present in the hashed area.
5.2.3.9. Issuer 5.2.3.9. Issuer Key ID
(8-octet Key ID) (8-octet Key ID)
The OpenPGP Key ID of the key issuing the signature. If the version The OpenPGP Key ID of the key issuing the signature. If the version
of that key is greater than 4, this subpacket MUST NOT be included in of that key is greater than 4, this subpacket MUST NOT be included in
the signature. the signature. For these keys, consider the Issuer Fingerprint
subpacket (Section 5.2.3.32) instead.
Note: in previous versions of this specification, this subpacket was
simply known as the "Issuer" subpacket.
5.2.3.10. Key Expiration Time 5.2.3.10. Key Expiration Time
(4-octet time field) (4-octet time field)
The validity period of the key. This is the number of seconds after The validity period of the key. This is the number of seconds after
the key creation time that the key expires. For a direct or the key creation time that the key expires. For a direct or
certification self-signature, the key creation time is that of the certification self-signature, the key creation time is that of the
primary key. For a subkey binding signature, the key creation time primary key. For a subkey binding signature, the key creation time
is that of the subkey. If this is not present or has a value of is that of the subkey. If this is not present or has a value of
zero, the key never expires. This is found only on a self-signature. zero, the key never expires. This is found only on a self-signature.
5.2.3.11. Preferred Symmetric Ciphers for v1 SEIPD 5.2.3.11. Preferred Symmetric Ciphers for v1 SEIPD
(array of one-octet values) (array of one-octet values)
skipping to change at page 39, line 17 skipping to change at page 42, line 11
primary key. For a subkey binding signature, the key creation time primary key. For a subkey binding signature, the key creation time
is that of the subkey. If this is not present or has a value of is that of the subkey. If this is not present or has a value of
zero, the key never expires. This is found only on a self-signature. zero, the key never expires. This is found only on a self-signature.
5.2.3.11. Preferred Symmetric Ciphers for v1 SEIPD 5.2.3.11. Preferred Symmetric Ciphers for v1 SEIPD
(array of one-octet values) (array of one-octet values)
A series of symmetric cipher algorithm identifiers indicating how the A series of symmetric cipher algorithm identifiers indicating how the
keyholder prefers to receive version 1 Symmetrically Encrypted keyholder prefers to receive version 1 Symmetrically Encrypted
Integrity Protected Data (Section 5.14.1). The subpacket body is an Integrity Protected Data (Section 5.13.1). The subpacket body is an
ordered list of octets with the most preferred listed first. It is ordered list of octets with the most preferred listed first. It is
assumed that only algorithms listed are supported by the recipient's assumed that only algorithms listed are supported by the recipient's
software. Algorithm numbers are in Section 9.3. This is only found software. Algorithm numbers are in Section 9.3. This is only found
on a self-signature. on a self-signature.
When generating a v2 SEIPD packet, this preference list is not When generating a v2 SEIPD packet, this preference list is not
relevant. See Section 5.2.3.12 instead. relevant. See Section 5.2.3.12 instead.
5.2.3.12. Preferred AEAD Ciphersuites 5.2.3.12. Preferred AEAD Ciphersuites
(array of pairs of octets indicating Symmetric Cipher and AEAD (array of pairs of octets indicating Symmetric Cipher and AEAD
algorithms) algorithms)
A series of paired algorithm identifiers indicating how the keyholder A series of paired algorithm identifiers indicating how the keyholder
prefers to receive version 2 Symmetrically Encrypted Integrity prefers to receive version 2 Symmetrically Encrypted Integrity
Protected Data (Section 5.14.2). Each pair of octets indicates a Protected Data (Section 5.13.2). Each pair of octets indicates a
combination of a symmetric cipher and an AEAD mode that the key combination of a symmetric cipher and an AEAD mode that the key
holder prefers to use. The symmetric cipher identifier precedes the holder prefers to use. The symmetric cipher identifier precedes the
AEAD identifier in each pair. The subpacket body is an ordered list AEAD identifier in each pair. The subpacket body is an ordered list
of pairs of octets with the most preferred algorithm combination of pairs of octets with the most preferred algorithm combination
listed first. listed first.
It is assumed that only the combinations of algorithms listed are It is assumed that only the combinations of algorithms listed are
supported by the recipient's software, with the exception of the supported by the recipient's software, with the exception of the
mandatory-to-implement combination of AES-128 and OCB. If AES-128 mandatory-to-implement combination of AES-128 and OCB. If AES-128
and OCB are not found in the subpacket, it is implicitly listed at and OCB are not found in the subpacket, it is implicitly listed at
skipping to change at page 40, line 4 skipping to change at page 42, line 46
mandatory-to-implement combination of AES-128 and OCB. If AES-128 mandatory-to-implement combination of AES-128 and OCB. If AES-128
and OCB are not found in the subpacket, it is implicitly listed at and OCB are not found in the subpacket, it is implicitly listed at
the end. the end.
AEAD algorithm numbers are listed in Section 9.6. Symmetric cipher AEAD algorithm numbers are listed in Section 9.6. Symmetric cipher
algorithm numbers are listed in Section 9.3. algorithm numbers are listed in Section 9.3.
For example, a subpacket with content of these six octets: For example, a subpacket with content of these six octets:
09 02 09 03 13 02 09 02 09 03 13 02
Indicates that the keyholder prefers to receive v2 SEIPD using Indicates that the keyholder prefers to receive v2 SEIPD using
AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB, AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB,
and finally the implicit AES-128 with OCB. and finally the implicit AES-128 with OCB.
Note that support for version 2 of the Symmetrically Encrypted Note that support for version 2 of the Symmetrically Encrypted
Integrity Protected Data packet (Section 5.14.2) in general is Integrity Protected Data packet (Section 5.13.2) in general is
indicated by a Feature Flag (Section 5.2.3.29). indicated by a Feature Flag (Section 5.2.3.29).
This subpacket is only found on a self-signature. This subpacket is only found on a self-signature.
When generating a v1 SEIPD packet, this preference list is not When generating a v1 SEIPD packet, this preference list is not
relevant. See Section 5.2.3.11 instead. relevant. See Section 5.2.3.11 instead.
5.2.3.13. Preferred Hash Algorithms 5.2.3.13. Preferred Hash Algorithms
(array of one-octet values) (array of one-octet values)
skipping to change at page 42, line 24 skipping to change at page 45, line 20
limit the scope of trust that is extended. Only signatures by the limit the scope of trust that is extended. Only signatures by the
target key on User IDs that match the regular expression in the body target key on User IDs that match the regular expression in the body
of this packet have trust extended by the trust Signature subpacket. of this packet have trust extended by the trust Signature subpacket.
The regular expression uses the same syntax as the Henry Spencer's The regular expression uses the same syntax as the Henry Spencer's
"almost public domain" regular expression [REGEX] package. A "almost public domain" regular expression [REGEX] package. A
description of the syntax is found in Section 8. description of the syntax is found in Section 8.
5.2.3.20. Revocation Key 5.2.3.20. Revocation Key
(1 octet of class, 1 octet of public-key algorithm ID, 20 octets of (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of
V4 fingerprint) v4 fingerprint)
This mechanism is deprecated. Applications MUST NOT generate such a This mechanism is deprecated. Applications MUST NOT generate such a
subpacket. subpacket.
An application that wants the functionality of delegating revocation An application that wants the functionality of delegating revocation
SHOULD instead use an escrowed Revocation Signature. See SHOULD instead use an escrowed Revocation Signature. See
Section 15.2 for more details. Section 14.8 for more details.
The remainder of this section describes how some implementations The remainder of this section describes how some implementations
attempt to interpret this deprecated subpacket. attempt to interpret this deprecated subpacket.
This packet was intended to authorize the specified key to issue This packet was intended to authorize the specified key to issue
revocation signatures for this key. Class octet must have bit 0x80 revocation signatures for this key. Class octet must have bit 0x80
set. If the bit 0x40 is set, then this means that the revocation set. If the bit 0x40 is set, then this means that the revocation
information is sensitive. Other bits are for future expansion to information is sensitive. Other bits are for future expansion to
other kinds of authorizations. This is only found on a direct-key other kinds of authorizations. This is only found on a direct-key
self-signature (type 0x1f). The use on other types of self- self-signature (type 0x1f). The use on other types of self-
skipping to change at page 43, line 29 skipping to change at page 46, line 19
This subpacket describes a "notation" on the signature that the This subpacket describes a "notation" on the signature that the
issuer wishes to make. The notation has a name and a value, each of issuer wishes to make. The notation has a name and a value, each of
which are strings of octets. There may be more than one notation in which are strings of octets. There may be more than one notation in
a signature. Notations can be used for any extension the issuer of a signature. Notations can be used for any extension the issuer of
the signature cares to make. The "flags" field holds four octets of the signature cares to make. The "flags" field holds four octets of
flags. flags.
All undefined flags MUST be zero. Defined flags are as follows: All undefined flags MUST be zero. Defined flags are as follows:
First octet: +====+=========+===========+===========+==================+=========+
|Flag|Shorthand|Description|Security | Interoperability |Reference|
+======+================+==========================+ | | | |Recommended| Recommended | |
| flag | shorthand | definition | +====+=========+===========+===========+==================+=========+
+======+================+==========================+ |0x80|human- |Notation |No | Yes |This |
| 0x80 | human-readable | This note value is text. | |0x00|readable |value is | | |document |
+------+----------------+--------------------------+ |0x00| |text. | | | |
|0x00| | | | | |
Table 8: Notation flag registry (first octet) +----+---------+-----------+-----------+------------------+---------+
Other octets: none. Table 9: Signature Notation Data Subpacket Notation Flag registry
Notation names are arbitrary strings encoded in UTF-8. They reside Notation names are arbitrary strings encoded in UTF-8. They reside
in two namespaces: The IETF namespace and the user namespace. in two namespaces: The IETF namespace and the user namespace.
The IETF namespace is registered with IANA. These names MUST NOT The IETF namespace is registered with IANA. These names MUST NOT
contain the "@" character (0x40). This is a tag for the user contain the "@" character (0x40). This is a tag for the user
namespace. namespace.
+===============+===========+================+===========+
| Notation Name | Data Type | Allowed Values | Reference |
+===============+===========+================+===========+
+---------------+-----------+----------------+-----------+
Table 10: Signature Notation Data Subpacket registry
Names in the user namespace consist of a UTF-8 string tag followed by Names in the user namespace consist of a UTF-8 string tag followed by
"@" followed by a DNS domain name. Note that the tag MUST NOT "@" followed by a DNS domain name. Note that the tag MUST NOT
contain an "@" character. For example, the "sample" tag used by contain an "@" character. For example, the "sample" tag used by
Example Corporation could be "sample@example.com". Example Corporation could be "sample@example.com".
Names in a user space are owned and controlled by the owners of that Names in a user space are owned and controlled by the owners of that
domain. Obviously, it's bad form to create a new name in a DNS space domain. Obviously, it's bad form to create a new name in a DNS space
that you don't own. that you don't own.
Since the user namespace is in the form of an email address, Since the user namespace is in the form of an email address,
skipping to change at page 44, line 36 skipping to change at page 47, line 32
First octet: First octet:
+======+===========+============================================+ +======+===========+============================================+
| flag | shorthand | definition | | flag | shorthand | definition |
+======+===========+============================================+ +======+===========+============================================+
| 0x80 | No-modify | The key holder requests that this key only | | 0x80 | No-modify | The key holder requests that this key only |
| | | be modified or updated by the key holder | | | | be modified or updated by the key holder |
| | | or an administrator of the key server. | | | | or an administrator of the key server. |
+------+-----------+--------------------------------------------+ +------+-----------+--------------------------------------------+
Table 9: Key server preferences flag registry (first octet) Table 11: Key server preferences flag registry (first octet)
This is found only on a self-signature. This is found only on a self-signature.
5.2.3.23. Preferred Key Server 5.2.3.23. Preferred Key Server
(String) (String)
This is a URI of a key server that the key holder prefers be used for This is a URI of a key server that the key holder prefers be used for
updates. Note that keys with multiple User IDs can have a preferred updates. Note that keys with multiple User IDs can have a preferred
key server for each User ID. Note also that since this is a URI, the key server for each User ID. Note also that since this is a URI, the
skipping to change at page 46, line 9 skipping to change at page 49, line 9
NOT assume a fixed size. This is so it can grow over time. If a NOT assume a fixed size. This is so it can grow over time. If a
list is shorter than an implementation expects, the unstated flags list is shorter than an implementation expects, the unstated flags
are considered to be zero. The defined flags are as follows: are considered to be zero. The defined flags are as follows:
First octet: First octet:
+======+=====================================================+ +======+=====================================================+
| flag | definition | | flag | definition |
+======+=====================================================+ +======+=====================================================+
| 0x01 | This key may be used to make User ID certifications | | 0x01 | This key may be used to make User ID certifications |
| | (signature types 0x10-0x13) or direct key | | | (signature types 0x10-0x13) or direct-key |
| | signatures (signature type 0x1F) over other keys. | | | signatures (signature type 0x1F) over other keys. |
+------+-----------------------------------------------------+ +------+-----------------------------------------------------+
| 0x02 | This key may be used to sign data. | | 0x02 | This key may be used to sign data. |
+------+-----------------------------------------------------+ +------+-----------------------------------------------------+
| 0x04 | This key may be used to encrypt communications. | | 0x04 | This key may be used to encrypt communications. |
+------+-----------------------------------------------------+ +------+-----------------------------------------------------+
| 0x08 | This key may be used to encrypt storage. | | 0x08 | This key may be used to encrypt storage. |
+------+-----------------------------------------------------+ +------+-----------------------------------------------------+
| 0x10 | The private component of this key may have been | | 0x10 | The private component of this key may have been |
| | split by a secret-sharing mechanism. | | | split by a secret-sharing mechanism. |
+------+-----------------------------------------------------+ +------+-----------------------------------------------------+
| 0x20 | This key may be used for authentication. | | 0x20 | This key may be used for authentication. |
+------+-----------------------------------------------------+ +------+-----------------------------------------------------+
| 0x80 | The private component of this key may be in the | | 0x80 | The private component of this key may be in the |
| | possession of more than one person. | | | possession of more than one person. |
+------+-----------------------------------------------------+ +------+-----------------------------------------------------+
Table 10: Key flags registry (first octet) Table 12: Key flags registry (first octet)
Second octet: Second octet:
+======+==========================+ +======+==========================+
| flag | definition | | flag | definition |
+======+==========================+ +======+==========================+
| 0x04 | Reserved (ADSK). | | 0x04 | Reserved (ADSK). |
+------+--------------------------+ +------+--------------------------+
| 0x08 | Reserved (timestamping). | | 0x08 | Reserved (timestamping). |
+------+--------------------------+ +------+--------------------------+
Table 11: Key flags registry Table 13: Key flags registry
(second octet) (second octet)
Usage notes: Usage notes:
The flags in this packet may appear in self-signatures or in The flags in this packet may appear in self-signatures or in
certification signatures. They mean different things depending on certification signatures. They mean different things depending on
who is making the statement --- for example, a certification who is making the statement --- for example, a certification
signature that has the "sign data" flag is stating that the signature that has the "sign data" flag is stating that the
certification is for that use. On the other hand, the certification is for that use. On the other hand, the
"communications encryption" flag in a self-signature is stating a "communications encryption" flag in a self-signature is stating a
skipping to change at page 48, line 26 skipping to change at page 51, line 26
+---------+----------------------------------+ +---------+----------------------------------+
| 3 | Key is retired and no longer | | 3 | Key is retired and no longer |
| | used (key revocations) | | | used (key revocations) |
+---------+----------------------------------+ +---------+----------------------------------+
| 32 | User ID information is no longer | | 32 | User ID information is no longer |
| | valid (cert revocations) | | | valid (cert revocations) |
+---------+----------------------------------+ +---------+----------------------------------+
| 100-110 | Private Use | | 100-110 | Private Use |
+---------+----------------------------------+ +---------+----------------------------------+
Table 12: Reasons for revocation Table 14: Reasons for revocation
Following the revocation code is a string of octets that gives Following the revocation code is a string of octets that gives
information about the Reason for Revocation in human-readable form information about the Reason for Revocation in human-readable form
(UTF-8). The string may be null (of zero length). The length of the (UTF-8). The string may be null (of zero length). The length of the
subpacket is the length of the reason string plus one. An subpacket is the length of the reason string plus one. An
implementation SHOULD implement this subpacket, include it in all implementation SHOULD implement this subpacket, include it in all
revocation signatures, and interpret revocations appropriately. revocation signatures, and interpret revocations appropriately.
There are important semantic differences between the reasons, and There are important semantic differences between the reasons, and
there are thus important reasons for revoking signatures. there are thus important reasons for revoking signatures.
skipping to change at page 49, line 29 skipping to change at page 52, line 29
user who does not state that they can use it. user who does not state that they can use it.
Defined features are as follows: Defined features are as follows:
First octet: First octet:
+=========+===================================+===========+ +=========+===================================+===========+
| Feature | Definition | Reference | | Feature | Definition | Reference |
+=========+===================================+===========+ +=========+===================================+===========+
| 0x01 | Symmetrically Encrypted Integrity | Section | | 0x01 | Symmetrically Encrypted Integrity | Section |
| | Protected Data packet version 1 | 5.14.1 | | | Protected Data packet version 1 | 5.13.1 |
+---------+-----------------------------------+-----------+ +---------+-----------------------------------+-----------+
| 0x02 | Reserved | | | 0x02 | Reserved | |
+---------+-----------------------------------+-----------+ +---------+-----------------------------------+-----------+
| 0x04 | Reserved | | | 0x04 | Reserved | |
+---------+-----------------------------------+-----------+ +---------+-----------------------------------+-----------+
| 0x08 | Symmetrically Encrypted Integrity | Section | | 0x08 | Symmetrically Encrypted Integrity | Section |
| | Protected Data packet version 2 | 5.14.2 | | | Protected Data packet version 2 | 5.13.2 |
+---------+-----------------------------------+-----------+ +---------+-----------------------------------+-----------+
Table 13: Features registry Table 15: Features registry
If an implementation implements any of the defined features, it If an implementation implements any of the defined features, it
SHOULD implement the Features subpacket, too. SHOULD implement the Features subpacket, too.
An implementation may freely infer features from other suitable An implementation may freely infer features from other suitable
implementation-dependent mechanisms. implementation-dependent mechanisms.
See Section 15.1 for details about how to use the Features subpacket See Section 14.7 for details about how to use the Features subpacket
when generating encryption data. when generating encryption data.
5.2.3.30. Signature Target 5.2.3.30. Signature Target
(1 octet public-key algorithm, 1 octet hash algorithm, N octets hash) (1 octet public-key algorithm, 1 octet hash algorithm, N octets hash)
This subpacket identifies a specific target signature to which a This subpacket identifies a specific target signature to which a
signature refers. For revocation signatures, this subpacket provides signature refers. For revocation signatures, this subpacket provides
explicit designation of which signature is being revoked. For a explicit designation of which signature is being revoked. For a
third-party or timestamp signature, this designates what signature is third-party or timestamp signature, this designates what signature is
skipping to change at page 50, line 33 skipping to change at page 53, line 33
This subpacket contains a complete Signature packet body as specified This subpacket contains a complete Signature packet body as specified
in Section 5.2. It is useful when one signature needs to refer to, in Section 5.2. It is useful when one signature needs to refer to,
or be incorporated in, another signature. or be incorporated in, another signature.
5.2.3.32. Issuer Fingerprint 5.2.3.32. Issuer Fingerprint
(1 octet key version number, N octets of fingerprint) (1 octet key version number, N octets of fingerprint)
The OpenPGP Key fingerprint of the key issuing the signature. This The OpenPGP Key fingerprint of the key issuing the signature. This
subpacket SHOULD be included in all signatures. If the version of subpacket SHOULD be included in all signatures. If the version of
the issuing key is 4 and an Issuer subpacket is also included in the the issuing key is 4 and an Issuer Key ID subpacket (Section 5.2.3.9)
signature, the key ID of the Issuer subpacket MUST match the low 64 is also included in the signature, the key ID of the Issuer Key ID
bits of the fingerprint. subpacket MUST match the low 64 bits of the fingerprint.
Note that the length N of the fingerprint for a version 4 key is 20 Note that the length N of the fingerprint for a version 4 key is 20
octets; for a version 5 key N is 32. octets; for a version 5 key N is 32. Since the version of the
signature is bound to the version of the key, the version octet here
MUST match the version of the signature. If the version octet does
not match the signature version, the receiving implementation MUST
treat it as a malformed signature (see Section 5.2.5).
5.2.3.33. Intended Recipient Fingerprint 5.2.3.33. Intended Recipient Fingerprint
(1 octet key version number, N octets of fingerprint) (1 octet key version number, N octets of fingerprint)
The OpenPGP Key fingerprint of the intended recipient primary key. The OpenPGP Key fingerprint of the intended recipient primary key.
If one or more subpackets of this type are included in a signature, If one or more subpackets of this type are included in a signature,
it SHOULD be considered valid only in an encrypted context, where the it SHOULD be considered valid only in an encrypted context, where the
key it was encrypted to is one of the indicated primary keys, or one key it was encrypted to is one of the indicated primary keys, or one
of their subkeys. This can be used to prevent forwarding a signature of their subkeys. This can be used to prevent forwarding a signature
outside of its intended, encrypted context. outside of its intended, encrypted context (see Section 14.11).
Note that the length N of the fingerprint for a version 4 key is 20 Note that the length N of the fingerprint for a version 4 key is 20
octets; for a version 5 key N is 32. octets; for a version 5 key N is 32.
An implementation SHOULD generate this subpacket when creating a
signed and encrypted message.
5.2.4. Computing Signatures 5.2.4. Computing Signatures
All signatures are formed by producing a hash over the signature All signatures are formed by producing a hash over the signature
data, and then using the resulting hash in the signature algorithm. data, and then using the resulting hash in the signature algorithm.
When a V5 signature is made, the salt is hashed first. When a v5 signature is made, the salt is hashed first.
For binary document signatures (type 0x00), the document data is For binary document signatures (type 0x00), the document data is
hashed directly. For text document signatures (type 0x01), the hashed directly. For text document signatures (type 0x01), the
document is canonicalized by converting line endings to <CR><LF>, and implementation MUST first canonicalize the document by converting
the resulting data is hashed. line endings to <CR><LF> and encoding it in UTF-8 (see [RFC3629]).
The resulting UTF-8 bytestream is hashed.
When a V4 signature is made over a key, the hash data starts with the When a v4 signature is made over a key, the hash data starts with the
octet 0x99, followed by a two-octet length of the key, and then body octet 0x99, followed by a two-octet length of the key, and then body
of the key packet. When a V5 signature is made over a key, the hash of the key packet. When a v5 signature is made over a key, the hash
data starts with the octet 0x9a, followed by a four-octet length of data starts with the octet 0x9a, followed by a four-octet length of
the key, and then body of the key packet. the key, and then body of the key packet.
A subkey binding signature (type 0x18) or primary key binding A subkey binding signature (type 0x18) or primary key binding
signature (type 0x19) then hashes the subkey using the same format as signature (type 0x19) then hashes the subkey using the same format as
the main key (also using 0x99 or 0x9a as the first octet). Primary the main key (also using 0x99 or 0x9a as the first octet). Primary
key revocation signatures (type 0x20) hash only the key being key revocation signatures (type 0x20) hash only the key being
revoked. Subkey revocation signature (type 0x28) hash first the revoked. Subkey revocation signature (type 0x28) hash first the
primary key and then the subkey being revoked. primary key and then the subkey being revoked.
A certification signature (type 0x10 through 0x13) hashes the User ID A certification signature (type 0x10 through 0x13) hashes the User ID
being bound to the key into the hash context after the above data. A being bound to the key into the hash context after the above data. A
V3 certification hashes the contents of the User ID or attribute v3 certification hashes the contents of the User ID or attribute
packet packet, without any header. A V4 or V5 certification hashes packet packet, without any header. A v4 or v5 certification hashes
the constant 0xB4 for User ID certifications or the constant 0xD1 for the constant 0xB4 for User ID certifications or the constant 0xD1 for
User Attribute certifications, followed by a four-octet number giving User Attribute certifications, followed by a four-octet number giving
the length of the User ID or User Attribute data, and then the User the length of the User ID or User Attribute data, and then the User
ID or User Attribute data. ID or User Attribute data.
When a signature is made over a Signature packet (type 0x50, "Third- When a signature is made over a Signature packet (type 0x50, "Third-
Party Confirmation signature"), the hash data starts with the octet Party Confirmation signature"), the hash data starts with the octet
0x88, followed by the four-octet length of the signature, and then 0x88, followed by the four-octet length of the signature, and then
the body of the Signature packet. (Note that this is a Legacy packet the body of the Signature packet. (Note that this is a Legacy packet
header for a Signature packet with the length-of-length field set to header for a Signature packet with the length-of-length field set to
zero.) The unhashed subpacket data of the Signature packet being zero.) The unhashed subpacket data of the Signature packet being
hashed is not included in the hash, and the unhashed subpacket data hashed is not included in the hash, and the unhashed subpacket data
length value is set to zero. length value is set to zero.
Once the data body is hashed, then a trailer is hashed. This trailer Once the data body is hashed, then a trailer is hashed. This trailer
depends on the version of the signature. depends on the version of the signature.
* A V3 signature hashes five octets of the packet body, starting * A v3 signature hashes five octets of the packet body, starting
from the signature type field. This data is the signature type, from the signature type field. This data is the signature type,
followed by the four-octet signature time. followed by the four-octet signature time.
* A V4 or V5 signature hashes the packet body starting from its * A v4 or v5 signature hashes the packet body starting from its
first field, the version number, through the end of the hashed first field, the version number, through the end of the hashed
subpacket data and a final extra trailer. Thus, the hashed fields subpacket data and a final extra trailer. Thus, the hashed fields
are: are:
- An octet indicating the signature version (0x04 for V4, 0x05 - An octet indicating the signature version (0x04 for v4, 0x05
for V5), for v5),
- the signature type, - the signature type,
- the public-key algorithm, - the public-key algorithm,
- the hash algorithm, - the hash algorithm,
- the hashed subpacket length, - the hashed subpacket length,
- the hashed subpacket body, - the hashed subpacket body,
- A second version octet (0x04 for V4, 0x05 for V5) - A second version octet (0x04 for v4, 0x05 for v5)
- A single octet 0xFF, - A single octet 0xFF,
- A number representing the length of the hashed data from the - A number representing the length of the hashed data from the
Signature packet stopping right before the second version Signature packet stopping right before the second version
octet. For a V4 signature, this is a four-octet big-endian octet. For a v4 signature, this is a four-octet big-endian
number, considered to be an unsigned integer modulo 2**32. For number, considered to be an unsigned integer modulo 2**32. For
a V5 signature, this is an eight-octet big-endian number, a v5 signature, this is an eight-octet big-endian number,
considered to be an unsigned integer modulo 2**64. considered to be an unsigned integer modulo 2**64.
After all this has been hashed in a single hash context, the After all this has been hashed in a single hash context, the
resulting hash field is used in the signature algorithm and placed at resulting hash field is used in the signature algorithm and placed at
the end of the Signature packet. the end of the Signature packet.
5.2.4.1. Subpacket Hints 5.2.4.1. Subpacket Hints
It is certainly possible for a signature to contain conflicting It is certainly possible for a signature to contain conflicting
information in subpackets. For example, a signature may contain information in subpackets. For example, a signature may contain
multiple copies of a preference or multiple expiration times. In multiple copies of a preference or multiple expiration times. In
most cases, an implementation SHOULD use the last subpacket in the most cases, an implementation SHOULD use the last subpacket in the
signature, but MAY use any conflict resolution scheme that makes more signature, but MAY use any conflict resolution scheme that makes more
sense. Please note that we are intentionally leaving conflict sense. Please note that we are intentionally leaving conflict
resolution to the implementer; most conflicts are simply syntax resolution to the implementer; most conflicts are simply syntax
errors, and the wishy-washy language here allows a receiver to be errors, and the wishy-washy language here allows a receiver to be
generous in what they accept, while putting pressure on a creator to generous in what they accept, while putting pressure on a creator to
be stingy in what they generate. be stingy in what they generate.
Some apparent conflicts may actually make sense --- for example, Some apparent conflicts may actually make sense --- for example,
suppose a keyholder has a V3 key and a V4 key that share the same RSA suppose a keyholder has a v3 key and a v4 key that share the same RSA
key material. Either of these keys can verify a signature created by key material. Either of these keys can verify a signature created by
the other, and it may be reasonable for a signature to contain an the other, and it may be reasonable for a signature to contain an
issuer subpacket for each key, as a way of explicitly tying those Issuer Key ID subpacket (Section 5.2.3.9) for each key, as a way of
keys to the signature. explicitly tying those keys to the signature.
5.2.5. Malformed and Unknown Signatures
In some cases, a signature packet (or its corresponding One-Pass
Signature Packet, see Section 5.4) may be malformed or unknown. For
example, it might encounter any of the following problems (this is
not an exhaustive list):
* an unknown signature type
* an unknown signature version
* an unsupported signature version
* an unknown "critical" subpacket (see Section 5.2.3.5) in the
hashed area
* a subpacket with a length that diverges from the expected length
* a hashed subpacket area with length that exceeds the length of the
signature packet itself
* a known-weak hash algorithm (e.g. MD5)
When an implementation encounters such a malformed or unknown
signature, it MUST ignore the signature for validation purposes. It
MUST NOT indicate a successful signature validation for such a
signature. At the same time, it MUST NOT halt processing on the
packet stream or reject other signatures in the same packet stream
just because an unknown or invalid signature exists.
This requirement is necessary for forward-compatibility. Producing
an output that indicates that no successful signatures were found is
preferable to aborting processing entirely.
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3)
The Symmetric-Key Encrypted Session Key (SKESK) packet holds the The Symmetric-Key Encrypted Session Key (SKESK) packet holds the
symmetric-key encryption of a session key used to encrypt a message. symmetric-key encryption of a session key used to encrypt a message.
Zero or more Public-Key Encrypted Session Key packets (Section 5.1) Zero or more Public-Key Encrypted Session Key packets (Section 5.1)
and/or Symmetric-Key Encrypted Session Key packets may precede a an and/or Symmetric-Key Encrypted Session Key packets may precede a an
encryption container (that is, a Symmetrically Encrypted Integrity encryption container (that is, a Symmetrically Encrypted Integrity
Protected Data packet or --- for historic data --- a Symmetrically Protected Data packet or --- for historic data --- a Symmetrically
Encrypted Data packet) that holds an encrypted message. The message Encrypted Data packet) that holds an encrypted message. The message
skipping to change at page 53, line 44 skipping to change at page 57, line 46
The versions differ in how they encrypt the session key with the The versions differ in how they encrypt the session key with the
password, and in what they encode. The version of the SKESK packet password, and in what they encode. The version of the SKESK packet
must align with the version of the SEIPD packet (see must align with the version of the SEIPD packet (see
Section 11.3.2.1). Section 11.3.2.1).
5.3.1. v4 SKESK 5.3.1. v4 SKESK
A version 4 Symmetric-Key Encrypted Session Key (SKESK) packet A version 4 Symmetric-Key Encrypted Session Key (SKESK) packet
precedes a version 1 Symmetrically Encrypted Integrity Protected Data precedes a version 1 Symmetrically Encrypted Integrity Protected Data
(v1 SEIPD, see Section 5.14.1) packet. In historic data, it is (v1 SEIPD, see Section 5.13.1) packet. In historic data, it is
sometimes found preceding a deprecated Symmetrically Encrypted Data sometimes found preceding a deprecated Symmetrically Encrypted Data
packet (SED, see Section 5.8). A v4 SKESK packet MUST NOT precede a packet (SED, see Section 5.7). A v4 SKESK packet MUST NOT precede a
v2 SEIPD packet (see Section 11.3.2.1). v2 SEIPD packet (see Section 11.3.2.1).
A version 4 Symmetric-Key Encrypted Session Key packet consists of: A version 4 Symmetric-Key Encrypted Session Key packet consists of:
* A one-octet version number with value 4. * A one-octet version number with value 4.
* A one-octet number describing the symmetric algorithm used. * A one-octet number describing the symmetric algorithm used.
* A string-to-key (S2K) specifier. The length of the string-to-key * A string-to-key (S2K) specifier. The length of the string-to-key
specifier depends on its type (see Section 3.7.1). specifier depends on its type (see Section 3.7.1).
skipping to change at page 54, line 36 skipping to change at page 58, line 38
Note: because an all-zero IV is used for this decryption, the S2K Note: because an all-zero IV is used for this decryption, the S2K
specifier MUST use a salt value, either a Salted S2K, an Iterated- specifier MUST use a salt value, either a Salted S2K, an Iterated-
Salted S2K, or Argon2. The salt value will ensure that the Salted S2K, or Argon2. The salt value will ensure that the
decryption key is not repeated even if the passphrase is reused. decryption key is not repeated even if the passphrase is reused.
5.3.2. v5 SKESK 5.3.2. v5 SKESK
A version 5 Symmetric-Key Encrypted Session Key (SKESK) packet A version 5 Symmetric-Key Encrypted Session Key (SKESK) packet
precedes a version 2 Symmetrically Encrypted Integrity Protected Data precedes a version 2 Symmetrically Encrypted Integrity Protected Data
(v2 SEIPD, see Section 5.14.2) packet. A v5 SKESK packet MUST NOT (v2 SEIPD, see Section 5.13.2) packet. A v5 SKESK packet MUST NOT
precede a v1 SEIPD packet or a deprecated Symmetrically Encrypted precede a v1 SEIPD packet or a deprecated Symmetrically Encrypted
Data packet (see Section 11.3.2.1). Data packet (see Section 11.3.2.1).
A version 5 Symmetric-Key Encrypted Session Key packet consists of: A version 5 Symmetric-Key Encrypted Session Key packet consists of:
* A one-octet version number with value 5. * A one-octet version number with value 5.
* A one-octet scalar octet count of the following 5 fields. * A one-octet scalar octet count of the following 5 fields.
* A one-octet symmetric cipher algorithm identifier. * A one-octet symmetric cipher algorithm identifier.
skipping to change at page 55, line 50 skipping to change at page 59, line 50
* A one-octet version number. The currently defined versions are 3 * A one-octet version number. The currently defined versions are 3
and 5. and 5.
* A one-octet signature type. Signature types are described in * A one-octet signature type. Signature types are described in
Section 5.2.1. Section 5.2.1.
* A one-octet number describing the hash algorithm used. * A one-octet number describing the hash algorithm used.
* A one-octet number describing the public-key algorithm used. * A one-octet number describing the public-key algorithm used.
* Only for V5 packets, a 16 octet field containing random values * Only for v5 packets, a 16 octet field containing random values
used as salt. The value must match the salt field of the used as salt. The value must match the salt field of the
corresponding Signature packet. corresponding Signature packet.
* Only for V3 packets, an eight-octet number holding the Key ID of * Only for v3 packets, an eight-octet number holding the Key ID of
the signing key. the signing key.
* Only for V5 packets, a one octet key version number and N octets * Only for v5 packets, a one octet key version number and N octets
of the fingerprint of the signing key. Note that the length N of of the fingerprint of the signing key. Note that the length N of
the fingerprint for a version 5 key is 32. the fingerprint for a version 5 key is 32. Since a v5 signature
can only be made by a v5 key, the key version number MUST be 5.
An application that encounters a v5 One-Pass Signature packet
where the key version number is not 5 MUST treat the signature as
invalid (see Section 5.2.5).
* A one-octet number holding a flag showing whether the signature is * A one-octet number holding a flag showing whether the signature is
nested. A zero value indicates that the next packet is another nested. A zero value indicates that the next packet is another
One-Pass Signature packet that describes another signature to be One-Pass Signature packet that describes another signature to be
applied to the same message data. applied to the same message data.
When generating a one-pass signature, the OPS packet version MUST When generating a one-pass signature, the OPS packet version MUST
correspond to the version of the associated signature packet, except correspond to the version of the associated signature packet, except
for the historical accident that v4 keys use a v3 one-pass signature for the historical accident that v4 keys use a v3 one-pass signature
packet (there is no v4 OPS): packet (there is no v4 OPS):
+=====================+====================+================+ +=====================+====================+================+
| Signing key version | OPS packet version | Signature | | Signing key version | OPS packet version | Signature |
| | | packet version | | | | packet version |
+=====================+====================+================+ +=====================+====================+================+
| 4 | 3 | 4 | | 4 | 3 | 4 |
+---------------------+--------------------+----------------+ +---------------------+--------------------+----------------+
| 5 | 5 | 5 | | 5 | 5 | 5 |
+---------------------+--------------------+----------------+ +---------------------+--------------------+----------------+
Table 14: Versions of packets used in a one-pass signature Table 16: Versions of packets used in a one-pass signature
Note that if a message contains more than one one-pass signature, Note that if a message contains more than one one-pass signature,
then the Signature packets bracket the message; that is, the first then the Signature packets bracket the message; that is, the first
Signature packet after the message corresponds to the last one-pass Signature packet after the message corresponds to the last one-pass
packet and the final Signature packet corresponds to the first one- packet and the final Signature packet corresponds to the first one-
pass packet. pass packet.
5.5. Key Material Packet 5.5. Key Material Packet
A key material packet contains all the information about a public or A key material packet contains all the information about a public or
skipping to change at page 57, line 29 skipping to change at page 61, line 33
5.5.1.4. Secret-Subkey Packet (Tag 7) 5.5.1.4. Secret-Subkey Packet (Tag 7)
A Secret-Subkey packet (tag 7) is the subkey analog of the Secret Key A Secret-Subkey packet (tag 7) is the subkey analog of the Secret Key
packet and has exactly the same format. packet and has exactly the same format.
5.5.2. Public-Key Packet Formats 5.5.2. Public-Key Packet Formats
There are three versions of key-material packets. There are three versions of key-material packets.
OpenPGP implementations SHOULD create keys with version 5 format. V4 OpenPGP implementations SHOULD create keys with version 5 format. V4
keys are deprecated; an implementation SHOULD NOT generate a V4 key, keys are deprecated; an implementation SHOULD NOT generate a v4 key,
but SHOULD accept it. V3 keys are deprecated; an implementation MUST but SHOULD accept it. V3 keys are deprecated; an implementation MUST
NOT generate a V3 key, but MAY accept it. V2 keys are deprecated; an NOT generate a v3 key, but MAY accept it. V2 keys are deprecated; an
implementation MUST NOT generate a V2 key, but MAY accept it. implementation MUST NOT generate a v2 key, but MAY accept it.
A version 3 public key or public-subkey packet contains: A version 3 public key or public-subkey packet contains:
* A one-octet version number (3). * A one-octet version number (3).
* A four-octet number denoting the time that the key was created. * A four-octet number denoting the time that the key was created.
* A two-octet number denoting the time in days that this key is * A two-octet number denoting the time in days that this key is
valid. If this number is zero, then it does not expire. valid. If this number is zero, then it does not expire.
skipping to change at page 57, line 48 skipping to change at page 62, line 4
* A four-octet number denoting the time that the key was created. * A four-octet number denoting the time that the key was created.
* A two-octet number denoting the time in days that this key is * A two-octet number denoting the time in days that this key is
valid. If this number is zero, then it does not expire. valid. If this number is zero, then it does not expire.
* A one-octet number denoting the public-key algorithm of this key. * A one-octet number denoting the public-key algorithm of this key.
* A series of multiprecision integers comprising the key material: * A series of multiprecision integers comprising the key material:
- a multiprecision integer (MPI) of RSA public modulus n; - a multiprecision integer (MPI) of RSA public modulus n;
- an MPI of RSA public encryption exponent e. - an MPI of RSA public encryption exponent e.
V3 keys are deprecated. They contain three weaknesses. First, it is V3 keys are deprecated. They contain three weaknesses. First, it is
relatively easy to construct a V3 key that has the same Key ID as any relatively easy to construct a v3 key that has the same Key ID as any
other key because the Key ID is simply the low 64 bits of the public other key because the Key ID is simply the low 64 bits of the public
modulus. Secondly, because the fingerprint of a V3 key hashes the modulus. Secondly, because the fingerprint of a v3 key hashes the
key material, but not its length, there is an increased opportunity key material, but not its length, there is an increased opportunity
for fingerprint collisions. Third, there are weaknesses in the MD5 for fingerprint collisions. Third, there are weaknesses in the MD5
hash algorithm that make developers prefer other algorithms. See hash algorithm that make developers prefer other algorithms. See
Section 12.2 for a fuller discussion of Key IDs and fingerprints. Section 5.5.4 for a fuller discussion of Key IDs and fingerprints.
V2 keys are identical to the deprecated V3 keys except for the V2 keys are identical to the deprecated v3 keys except for the
version number. version number.
The version 4 format is similar to the version 3 format except for The version 4 format is similar to the version 3 format except for
the absence of a validity period. This has been moved to the the absence of a validity period. This has been moved to the
Signature packet. In addition, fingerprints of version 4 keys are Signature packet. In addition, fingerprints of version 4 keys are
calculated differently from version 3 keys, as described in calculated differently from version 3 keys, as described in
Section 12. Section 5.5.4.
A version 4 packet contains: A version 4 packet contains:
* A one-octet version number (4). * A one-octet version number (4).
* A four-octet number denoting the time that the key was created. * A four-octet number denoting the time that the key was created.
* A one-octet number denoting the public-key algorithm of this key. * A one-octet number denoting the public-key algorithm of this key.
* A series of values comprising the key material. This is * A series of values comprising the key material. This is
algorithm-specific and described in Section 5.6. algorithm-specific and described in Section 5.5.5.
The version 5 format is similar to the version 4 format except for The version 5 format is similar to the version 4 format except for
the addition of a count for the key material. This count helps the addition of a count for the key material. This count helps
parsing secret key packets (which are an extension of the public key parsing secret key packets (which are an extension of the public key
packet format) in the case of an unknown algorithm. In addition, packet format) in the case of an unknown algorithm. In addition,
fingerprints of version 5 keys are calculated differently from fingerprints of version 5 keys are calculated differently from
version 4 keys, as described in Section 12. version 4 keys, as described in Section 5.5.4.
A version 5 packet contains: A version 5 packet contains:
* A one-octet version number (5). * A one-octet version number (5).
* A four-octet number denoting the time that the key was created. * A four-octet number denoting the time that the key was created.
* A one-octet number denoting the public-key algorithm of this key. * A one-octet number denoting the public-key algorithm of this key.
* A four-octet scalar octet count for the following public key * A four-octet scalar octet count for the following public key
material. material.
* A series of values comprising the public key material. This is * A series of values comprising the public key material. This is
algorithm-specific and described in Section 5.6. algorithm-specific and described in Section 5.5.5.
5.5.3. Secret-Key Packet Formats 5.5.3. Secret-Key Packet Formats
The Secret-Key and Secret-Subkey packets contain all the data of the The Secret-Key and Secret-Subkey packets contain all the data of the
Public-Key and Public-Subkey packets, with additional algorithm- Public-Key and Public-Subkey packets, with additional algorithm-
specific secret-key data appended, usually in encrypted form. specific secret-key data appended, usually in encrypted form.
The packet contains: The packet contains:
* The fields of a Public-Key or Public-Subkey packet, as described * The fields of a Public-Key or Public-Subkey packet, as described
above. above.
* One octet indicating string-to-key usage conventions. Zero * One octet indicating string-to-key usage conventions. Zero
indicates that the secret-key data is not encrypted. 255, 254, or indicates that the secret-key data is not encrypted. 255, 254, or
253 indicates that a string-to-key specifier is being given. Any 253 indicates that a string-to-key specifier is being given. Any
other value is a symmetric-key encryption algorithm identifier. A other value is a symmetric-key encryption algorithm identifier. A
version 5 packet MUST NOT use the value 255. version 5 packet MUST NOT use the value 255.
* Only for a version 5 packet, a one-octet scalar octet count of the * Only for a version 5 packet where the secret key material is
next 5 optional fields. encrypted (that is, where the previous octet is not zero), a one-
octet scalar octet count of the cumulative length of all the
following optional string-to-key parameter fields.
* [Optional] If string-to-key usage octet was 255, 254, or 253, a * [Optional] If string-to-key usage octet was 255, 254, or 253, a
one-octet symmetric encryption algorithm. one-octet symmetric encryption algorithm.
* [Optional] If string-to-key usage octet was 253, a one-octet AEAD * [Optional] If string-to-key usage octet was 253, a one-octet AEAD
algorithm. algorithm.
* [Optional] Only for a version 5 packet, and if string-to-key usage * [Optional] Only for a version 5 packet, and if string-to-key usage
octet was 255, 254, or 253, an one-octet count of the following octet was 255, 254, or 253, an one-octet count of the following
field. field.
* [Optional] If string-to-key usage octet was 255, 254, or 253, a * [Optional] If string-to-key usage octet was 255, 254, or 253, a
string-to-key (S2K) specifier. The length of the string-to-key string-to-key (S2K) specifier. The length of the string-to-key
specifier depends on its type (see Section 3.7.1). specifier depends on its type (see Section 3.7.1).
* [Optional] If string-to-key usage octet was 253 (that is, the * [Optional] If string-to-key usage octet was 253 (that is, the
secret data is AEAD-encrypted), an initialization vector (IV) of secret data is AEAD-encrypted), an initialization vector (IV) of
size specified by the AEAD algorithm (see Section 5.14.2), which size specified by the AEAD algorithm (see Section 5.13.2), which
is used as the nonce for the AEAD algorithm. is used as the nonce for the AEAD algorithm.
* [Optional] If string-to-key usage octet was 255, 254, or a cipher * [Optional] If string-to-key usage octet was 255, 254, or a cipher
algorithm identifier (that is, the secret data is CFB-encrypted), algorithm identifier (that is, the secret data is CFB-encrypted),
an initialization vector (IV) of the same length as the cipher's an initialization vector (IV) of the same length as the cipher's
block size. block size.
* Plain or encrypted multiprecision integers comprising the secret * Plain or encrypted multiprecision integers comprising the secret
key data. This is algorithm-specific and described in key data. This is algorithm-specific and described in
Section 5.6. If the string-to-key usage octet is 253, then an Section 5.5.5. If the string-to-key usage octet is 253, then an
AEAD authentication tag is part of that data. If the string-to- AEAD authentication tag is part of that data. If the string-to-
key usage octet is 254, a 20-octet SHA-1 hash of the plaintext of key usage octet is 254, a 20-octet SHA-1 hash of the plaintext of
the algorithm-specific portion is appended to plaintext and the algorithm-specific portion is appended to plaintext and
encrypted with it. If the string-to-key usage octet is 255 or encrypted with it. If the string-to-key usage octet is 255 or
another nonzero value (that is, a symmetric-key encryption another nonzero value (that is, a symmetric-key encryption
algorithm identifier), a two-octet checksum of the plaintext of algorithm identifier), a two-octet checksum of the plaintext of
the algorithm-specific portion (sum of all octets, mod 65536) is the algorithm-specific portion (sum of all octets, mod 65536) is
appended to plaintext and encrypted with it. (This is deprecated appended to plaintext and encrypted with it. (This is deprecated
and SHOULD NOT be used, see below.) and SHOULD NOT be used, see below.)
* If the string-to-key usage octet is zero, then a two-octet * If the string-to-key usage octet is zero, then a two-octet
checksum of the algorithm-specific portion (sum of all octets, mod checksum of the algorithm-specific portion (sum of all octets, mod
65536). 65536).
The details about storing algorithm-specific secrets above are The details about storing algorithm-specific secrets above are
summarized in Table 2. summarized in Section 3.7.2.1.
Note that the version 5 packet format adds two count values to help Note that the version 5 packet format adds two count values to help
parsing packets with unknown S2K or public key algorithms. parsing packets with unknown S2K or public key algorithms.
Secret MPI values can be encrypted using a passphrase. If a string- Secret MPI values can be encrypted using a passphrase. If a string-
to-key specifier is given, that describes the algorithm for to-key specifier is given, that describes the algorithm for
converting the passphrase to a key, else a simple MD5 hash of the converting the passphrase to a key, else a simple MD5 hash of the
passphrase is used. Implementations MUST use a string-to-key passphrase is used. Implementations MUST use a string-to-key
specifier; the simple hash is for backward compatibility and is specifier; the simple hash is for backward compatibility and is
deprecated, though implementations MAY continue to use existing deprecated, though implementations MAY continue to use existing
private keys in the old format. The cipher for encrypting the MPIs private keys in the old format. The cipher for encrypting the MPIs
is specified in the Secret-Key packet. is specified in the Secret-Key packet.
Encryption/decryption of the secret data is done using the key Encryption/decryption of the secret data is done using the key
created from the passphrase and the initialization vector from the created from the passphrase and the initialization vector from the
packet. If the string-to-key usage octet is not 253, CFB mode is packet. If the string-to-key usage octet is not 253, CFB mode is
used. A different mode is used with V3 keys (which are only RSA) used. A different mode is used with v3 keys (which are only RSA)
than with other key formats. With V3 keys, the MPI bit count prefix than with other key formats. With v3 keys, the MPI bit count prefix
(that is, the first two octets) is not encrypted. Only the MPI non- (that is, the first two octets) is not encrypted. Only the MPI non-
prefix data is encrypted. Furthermore, the CFB state is prefix data is encrypted. Furthermore, the CFB state is
resynchronized at the beginning of each new MPI value, so that the resynchronized at the beginning of each new MPI value, so that the
CFB block boundary is aligned with the start of the MPI data. CFB block boundary is aligned with the start of the MPI data.
With V4 and V5 keys, a simpler method is used. All secret MPI values With v4 and v5 keys, a simpler method is used. All secret MPI values
are encrypted, including the MPI bitcount prefix. are encrypted, including the MPI bitcount prefix.
If the string-to-key usage octet is 253, the key encryption key is If the string-to-key usage octet is 253, the key encryption key is
derived using HKDF (see [RFC5869]) to provide key separation. HKDF derived using HKDF (see [RFC5869]) to provide key separation. HKDF
is used with SHA256 as hash algorithm, the key derived from S2K as is used with SHA256 as hash algorithm, the key derived from S2K as
Initial Keying Material (IKM), no salt, and the Packet Tag in OpenPGP Initial Keying Material (IKM), no salt, and the Packet Tag in OpenPGP
format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag), format encoding (bits 7 and 6 set, bits 5-0 carry the packet tag),
the packet version, and the cipher-algo and AEAD-mode used to encrypt the packet version, and the cipher-algo and AEAD-mode used to encrypt
the key material, are used as info parameter. Then, the encrypted the key material, are used as info parameter. Then, the encrypted
MPI values are encrypted as one combined plaintext using one of the MPI values are encrypted as one combined plaintext using one of the
skipping to change at page 61, line 26 skipping to change at page 65, line 26
Key Packet of version 4 consists of the octets 0xC5, 0x04, followed Key Packet of version 4 consists of the octets 0xC5, 0x04, followed
by four octets of creation time, one octet denoting the public-key by four octets of creation time, one octet denoting the public-key
algorithm, and the algorithm-specific public-key parameters. For a algorithm, and the algorithm-specific public-key parameters. For a
Secret-Subkey Packet, the first octet would be 0xC7. For a version 5 Secret-Subkey Packet, the first octet would be 0xC7. For a version 5
key packet, the second octet would be 0x05, and the four-octet octet key packet, the second octet would be 0x05, and the four-octet octet
count of the public key material would be included as well (see count of the public key material would be included as well (see
Section 5.5.2). Section 5.5.2).
The two-octet checksum that follows the algorithm-specific portion is The two-octet checksum that follows the algorithm-specific portion is
the algebraic sum, mod 65536, of the plaintext of all the algorithm- the algebraic sum, mod 65536, of the plaintext of all the algorithm-
specific octets (including MPI prefix and data). With V3 keys, the specific octets (including MPI prefix and data). With v3 keys, the
checksum is stored in the clear. With V4 keys, the checksum is checksum is stored in the clear. With v4 keys, the checksum is
encrypted like the algorithm-specific data. This value is used to encrypted like the algorithm-specific data. This value is used to
check that the passphrase was correct. However, this checksum is check that the passphrase was correct. However, this checksum is
deprecated; an implementation SHOULD NOT use it, but should rather deprecated; an implementation SHOULD NOT use it, but should rather
use the SHA-1 hash denoted with a usage octet of 254. The reason for use the SHA-1 hash denoted with a usage octet of 254. The reason for
this is that there are some attacks that involve undetectably this is that there are some attacks that involve undetectably
modifying the secret key. If the string-to-key usage octet is 253 no modifying the secret key. If the string-to-key usage octet is 253 no
checksum or SHA-1 hash is used but the authentication tag of the AEAD checksum or SHA-1 hash is used but the authentication tag of the AEAD
algorithm follows. algorithm follows.
When decrypting the secret key material using any of these schemes When decrypting the secret key material using any of these schemes
(that is, where the usage octet is non-zero), the resulting cleartext (that is, where the usage octet is non-zero), the resulting cleartext
octet stream MUST be well-formed. In particular, an implementation octet stream MUST be well-formed. In particular, an implementation
MUST NOT interpret octets beyond the unwrapped cleartext octet stream MUST NOT interpret octets beyond the unwrapped cleartext octet stream
as part of any of the unwrapped MPI objects. Furthermore, an as part of any of the unwrapped MPI objects. Furthermore, an
implementation MUST reject as unusable any secret key material whose implementation MUST reject as unusable any secret key material whose
cleartext length does not align with the lengths of the unwrapped MPI cleartext length does not align with the lengths of the unwrapped MPI
objects. objects.
5.6. Algorithm-specific Parts of Keys 5.5.4. Key IDs and Fingerprints
For a v3 key, the eight-octet Key ID consists of the low 64 bits of
the public modulus of the RSA key.
The fingerprint of a v3 key is formed by hashing the body (but not
the two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5. Note that both v3 keys
and MD5 are deprecated.
A v4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
followed by the two-octet packet length, followed by the entire
Public-Key packet starting with the version field. The Key ID is the
low-order 64 bits of the fingerprint. Here are the fields of the
hash material, with the example of an EdDSA key:
a.1) 0x99 (1 octet)
a.2) two-octet, big-endian scalar octet count of (b)-(e)
b) version number = 4 (1 octet);
c) timestamp of key creation (4 octets);
d) algorithm (1 octet): 22 = EdDSA (example);
e) Algorithm-specific fields.
Algorithm-Specific Fields for EdDSA keys (example):
e.1) A one-octet size of the following field;
e.2) The octets representing a curve OID, defined in Section 9.2;
e.3) An MPI of an EC point representing a public key Q in prefixed
native form (see Section 12.2.2).
A v5 fingerprint is the 256-bit SHA2-256 hash of the octet 0x9A,
followed by the four-octet packet length, followed by the entire
Public-Key packet starting with the version field. The Key ID is the
high-order 64 bits of the fingerprint. Here are the fields of the
hash material, with the example of an EdDSA key:
a.1) 0x9A (1 octet)
a.2) four-octet scalar octet count of (b)-(f)
b) version number = 5 (1 octet);
c) timestamp of key creation (4 octets);
d) algorithm (1 octet): 22 = EdDSA (example);
e) four-octet scalar octet count for the following key material;
f) algorithm-specific fields.
Algorithm-Specific Fields for EdDSA keys (example):
f.1) A one-octet size of the following field;
f.2) The octets representing a curve OID, defined in Section 9.2;
f.3) An MPI of an EC point representing a public key Q in prefixed
native form (see Section 12.2.2).
Note that it is possible for there to be collisions of Key IDs ---
two different keys with the same Key ID. Note that there is a much
smaller, but still non-zero, probability that two different keys have
the same fingerprint.
Also note that if v3, v4, and v5 format keys share the same RSA key
material, they will have different Key IDs as well as different
fingerprints.
Finally, the Key ID and fingerprint of a subkey are calculated in the
same way as for a primary key, including the 0x99 (v4 key) or 0x9A
(v5 key) as the first octet (even though this is not a valid packet
ID for a public subkey).
5.5.5. Algorithm-specific Parts of Keys
The public and secret key format specifies algorithm-specific parts The public and secret key format specifies algorithm-specific parts
of a key. The following sections describe them in detail. of a key. The following sections describe them in detail.
5.6.1. Algorithm-Specific Part for RSA Keys 5.5.5.1. Algorithm-Specific Part for RSA Keys
The public key is this series of multiprecision integers: The public key is this series of multiprecision integers:
* MPI of RSA public modulus n; * MPI of RSA public modulus n;
* MPI of RSA public encryption exponent e. * MPI of RSA public encryption exponent e.
The secret key is this series of multiprecision integers: The secret key is this series of multiprecision integers:
* MPI of RSA secret exponent d; * MPI of RSA secret exponent d;
skipping to change at page 62, line 20 skipping to change at page 68, line 4
* MPI of RSA public encryption exponent e. * MPI of RSA public encryption exponent e.
The secret key is this series of multiprecision integers: The secret key is this series of multiprecision integers:
* MPI of RSA secret exponent d; * MPI of RSA secret exponent d;
* MPI of RSA secret prime value p; * MPI of RSA secret prime value p;
* MPI of RSA secret prime value q (p < q); * MPI of RSA secret prime value q (p < q);
* MPI of u, the multiplicative inverse of p, mod q. * MPI of u, the multiplicative inverse of p, mod q.
5.6.2. Algorithm-Specific Part for DSA Keys 5.5.5.2. Algorithm-Specific Part for DSA Keys
The public key is this series of multiprecision integers: The public key is this series of multiprecision integers:
* MPI of DSA prime p; * MPI of DSA prime p;
* MPI of DSA group order q (q is a prime divisor of p-1); * MPI of DSA group order q (q is a prime divisor of p-1);
* MPI of DSA group generator g; * MPI of DSA group generator g;
* MPI of DSA public-key value y (= g**x mod p where x is secret). * MPI of DSA public-key value y (= g**x mod p where x is secret).
The secret key is this single multiprecision integer: The secret key is this single multiprecision integer:
* MPI of DSA secret exponent x. * MPI of DSA secret exponent x.
5.6.3. Algorithm-Specific Part for Elgamal Keys 5.5.5.3. Algorithm-Specific Part for Elgamal Keys
The public key is this series of multiprecision integers: The public key is this series of multiprecision integers:
* MPI of Elgamal prime p; * MPI of Elgamal prime p;
* MPI of Elgamal group generator g; * MPI of Elgamal group generator g;
* MPI of Elgamal public key value y (= g**x mod p where x is * MPI of Elgamal public key value y (= g**x mod p where x is
secret). secret).
The secret key is this single multiprecision integer: The secret key is this single multiprecision integer:
* MPI of Elgamal secret exponent x. * MPI of Elgamal secret exponent x.
5.6.4. Algorithm-Specific Part for ECDSA Keys 5.5.5.4. Algorithm-Specific Part for ECDSA Keys
The public key is this series of values: The public key is this series of values:
* A variable-length field containing a curve OID, which is formatted * A variable-length field containing a curve OID, which is formatted
as follows: as follows:
- A one-octet size of the following field; values 0 and 0xFF are - A one-octet size of the following field; values 0 and 0xFF are
reserved for future extensions, reserved for future extensions,
- The octets representing a curve OID (defined in Section 9.2); - The octets representing a curve OID (defined in Section 9.2);
* MPI of an EC point representing a public key. * MPI of an EC point representing a public key.
The secret key is this single multiprecision integer: The secret key is this single multiprecision integer:
* MPI of an integer representing the secret key, which is a scalar * MPI of an integer representing the secret key, which is a scalar
of the public EC point. of the public EC point.
5.6.5. Algorithm-Specific Part for EdDSA Keys 5.5.5.5. Algorithm-Specific Part for EdDSA Keys
The public key is this series of values: The public key is this series of values:
* A variable-length field containing a curve OID, formatted as * A variable-length field containing a curve OID, formatted as
follows: follows:
- A one-octet size of the following field; values 0 and 0xFF are - A one-octet size of the following field; values 0 and 0xFF are
reserved for future extensions, reserved for future extensions,
- The octets representing a curve OID, defined in Section 9.2; - The octets representing a curve OID, defined in Section 9.2;
* An MPI of an EC point representing a public key Q in prefixed * An MPI of an EC point representing a public key Q in prefixed
native form (see Section 13.2.2). native form (see Section 12.2.2).
The secret key is this single multiprecision integer: The secret key is this single multiprecision integer:
* An MPI-encoded octet string representing the native form of the * An MPI-encoded octet string representing the native form of the
secret key, in the curve-specific format described in secret key, in the curve-specific format described in
Section 9.2.1. Section 9.2.1.
See [RFC8032] for more details about the native octet strings. Note that the native form for an EdDSA secret key is a fixed-width
sequence of unstructured random octets, with size corresponding to
the specific curve. That sequence of random octets is used with a
cryptographic digest to produce both a curve-specific secret scalar
and a prefix used when making a signature. See [RFC8032] for more
details about how to use the native octet strings (section 5.1.5 for
Ed25519 and 5.2.5 for Ed448). The value stored in an OpenPGP EdDSA
secret key packet is the original sequence of random octets.
5.6.6. Algorithm-Specific Part for ECDH Keys Note that a ECDH secret key over the equivalent curve instead stores
the curve-specific secret scalar itself, rather than the sequence of
random octets stored in an EdDSA secret key.
5.5.5.6. Algorithm-Specific Part for ECDH Keys
The public key is this series of values: The public key is this series of values:
* A variable-length field containing a curve OID, which is formatted * A variable-length field containing a curve OID, which is formatted
as follows: as follows:
- A one-octet size of the following field; values 0 and 0xFF are - A one-octet size of the following field; values 0 and 0xFF are
reserved for future extensions, reserved for future extensions,
- Octets representing a curve OID, defined in Section 9.2; - Octets representing a curve OID, defined in Section 9.2;
skipping to change at page 64, line 25 skipping to change at page 70, line 20
- A one-octet size of the following fields; values 0 and 0xFF are - A one-octet size of the following fields; values 0 and 0xFF are
reserved for future extensions, reserved for future extensions,
- A one-octet value 1, reserved for future extensions, - A one-octet value 1, reserved for future extensions,
- A one-octet hash function ID used with a KDF, - A one-octet hash function ID used with a KDF,
- A one-octet algorithm ID for the symmetric algorithm used to - A one-octet algorithm ID for the symmetric algorithm used to
wrap the symmetric key used for the message encryption; see wrap the symmetric key used for the message encryption; see
Section 13.5 for details. Section 12.5 for details.
Observe that an ECDH public key is composed of the same sequence of Observe that an ECDH public key is composed of the same sequence of
fields that define an ECDSA key plus the KDF parameters field. fields that define an ECDSA key plus the KDF parameters field.
The secret key is this single multiprecision integer: The secret key is this single multiprecision integer:
* An MPI representing the secret key, in the curve-specific format * An MPI representing the secret key, in the curve-specific format
described in Section 9.2.1. described in Section 9.2.1.
5.6.6.1. ECDH Secret Key Material 5.5.5.6.1. ECDH Secret Key Material
When curve P-256, P-384, or P-521 are used in ECDH, their secret keys When curve P-256, P-384, or P-521 are used in ECDH, their secret keys
are represented as a simple integer in standard MPI form. Other are represented as a simple integer in standard MPI form. Other
curves are presented on the wire differently (though still as a curves are presented on the wire differently (though still as a
single MPI), as described below and in Section 9.2.1. single MPI), as described below and in Section 9.2.1.
5.6.6.1.1. Curve25519 ECDH Secret Key Material 5.5.5.6.1.1. Curve25519 ECDH Secret Key Material
A Curve25519 secret key is stored as a standard integer in big-endian A Curve25519 secret key is stored as a standard integer in big-endian
MPI form. Note that this form is in reverse octet order from the MPI form. Note that this form is in reverse octet order from the
little-endian "native" form found in [RFC7748]. little-endian "native" form found in [RFC7748].
Note also that the integer for a Curve25519 secret key for OpenPGP Note also that the integer for a Curve25519 secret key for OpenPGP
MUST have the appropriate form: that is, it MUST be divisible by 8, MUST have the appropriate form: that is, it MUST be divisible by 8,
MUST be at least 2**254, and MUST be less than 2**255. The length of MUST be at least 2**254, and MUST be less than 2**255. The length of
this MPI in bits is by definition always 255, so the two leading this MPI in bits is by definition always 255, so the two leading
octets of the MPI will always be 00 ff and reversing the following 32 octets of the MPI will always be 00 ff and reversing the following 32
skipping to change at page 65, line 23 skipping to change at page 71, line 12
octets, the following pseudocode produces the MPI wire format (note octets, the following pseudocode produces the MPI wire format (note
the similarity to decodeScalar25519 from [RFC7748]): the similarity to decodeScalar25519 from [RFC7748]):
def curve25519_MPI_from_random(octet_list): def curve25519_MPI_from_random(octet_list):
octet_list[0] &= 248 octet_list[0] &= 248
octet_list[31] &= 127 octet_list[31] &= 127
octet_list[31] |= 64 octet_list[31] |= 64
mpi_header = [ 0x00, 0xff ] mpi_header = [ 0x00, 0xff ]
return mpi_header || reversed(octet_list) return mpi_header || reversed(octet_list)
5.6.6.1.2. X448 ECDH Secret Key Material 5.5.5.6.1.2. X448 ECDH Secret Key Material
An X448 secret key is contained within its MPI as a prefixed octet An X448 secret key is contained within its MPI as a prefixed octet
string (see Section 13.3.2), which encapsulates the native secret key string (see Section 12.3.2), which encapsulates the native secret key
format found in [RFC7748]. The full wire format (as an MPI) will format found in [RFC7748]. The full wire format (as an MPI) will
thus be the three octets 01 c7 40 followed by the full 56 octet thus be the three octets 01 c7 40 followed by the full 56 octet
native secret key. native secret key.
When generating a new X448 secret key from 56 fully-random octets, When generating a new X448 secret key from 56 fully-random octets,
the following pseudocode produces the MPI wire format: the following pseudocode produces the MPI wire format:
def X448_MPI_from_random(octet_list): def X448_MPI_from_random(octet_list):
prefixed_header = [ 0x01, 0xc7, 0x40 ] prefixed_header = [ 0x01, 0xc7, 0x40 ]
return prefixed_header || octet_list return prefixed_header || octet_list
5.7. Compressed Data Packet (Tag 8) 5.6. Compressed Data Packet (Tag 8)
The Compressed Data packet contains compressed data. Typically, this The Compressed Data packet contains compressed data. Typically, this
packet is found as the contents of an encrypted packet, or following packet is found as the contents of an encrypted packet, or following
a Signature or One-Pass Signature packet, and contains a literal data a Signature or One-Pass Signature packet, and contains a literal data
packet. packet.
The body of this packet consists of: The body of this packet consists of:
* One octet that gives the algorithm used to compress the packet. * One octet that gives the algorithm used to compress the packet.
skipping to change at page 66, line 27 skipping to change at page 72, line 14
An implementation that generates a Compressed Data packet MUST use An implementation that generates a Compressed Data packet MUST use
the non-legacy format for packet framing (see Section 4.2.1). It the non-legacy format for packet framing (see Section 4.2.1). It
MUST NOT generate a Compressed Data packet with Legacy format MUST NOT generate a Compressed Data packet with Legacy format
(Section 4.2.2) (Section 4.2.2)
An implementation that deals with either historic data or data An implementation that deals with either historic data or data
generated by legacy implementations MAY interpret Compressed Data generated by legacy implementations MAY interpret Compressed Data
packets that use the Legacy format for packet framing. packets that use the Legacy format for packet framing.
5.8. Symmetrically Encrypted Data Packet (Tag 9) 5.7. Symmetrically Encrypted Data Packet (Tag 9)
The Symmetrically Encrypted Data packet contains data encrypted with The Symmetrically Encrypted Data packet contains data encrypted with
a symmetric-key algorithm. When it has been decrypted, it contains a symmetric-key algorithm. When it has been decrypted, it contains
other packets (usually a literal data packet or compressed data other packets (usually a literal data packet or compressed data
packet, but in theory other Symmetrically Encrypted Data packets or packet, but in theory other Symmetrically Encrypted Data packets or
sequences of packets that form whole OpenPGP messages). sequences of packets that form whole OpenPGP messages).
This packet is obsolete. An implementation MUST NOT create this This packet is obsolete. An implementation MUST NOT create this
packet. An implementation MAY process such a packet but it MUST packet. An implementation MAY process such a packet but it MUST
return a clear diagnostic that a non-integrity protected packet has return a clear diagnostic that a non-integrity protected packet has
been processed. The implementation SHOULD also return an error in been processed. The implementation SHOULD also return an error in
this case and stop processing. this case and stop processing.
This packet format is impossible to handle safely in general because This packet format is impossible to handle safely in general because
the ciphertext it provides is malleable. See Section 15.1 about the ciphertext it provides is malleable. See Section 14.7 about
selecting a better OpenPGP encryption container that does not have selecting a better OpenPGP encryption container that does not have
this flaw. this flaw.
The body of this packet consists of: The body of this packet consists of:
* Encrypted data, the output of the selected symmetric-key cipher * Encrypted data, the output of the selected symmetric-key cipher
operating in OpenPGP's variant of Cipher Feedback (CFB) mode. operating in OpenPGP's variant of Cipher Feedback (CFB) mode.
The symmetric cipher used may be specified in a Public-Key or The symmetric cipher used may be specified in a Public-Key or
Symmetric-Key Encrypted Session Key packet that precedes the Symmetric-Key Encrypted Session Key packet that precedes the
skipping to change at page 67, line 31 skipping to change at page 73, line 15
octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15 octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15
and octet 18 is a repeat of octet 16. As a pedantic clarification, and octet 18 is a repeat of octet 16. As a pedantic clarification,
in both these examples, we consider the first octet to be numbered 1. in both these examples, we consider the first octet to be numbered 1.
After encrypting the first block-size-plus-two octets, the CFB state After encrypting the first block-size-plus-two octets, the CFB state
is resynchronized. The last block-size octets of ciphertext are is resynchronized. The last block-size octets of ciphertext are
passed through the cipher and the block boundary is reset. passed through the cipher and the block boundary is reset.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. See Section 15 for hints on the proper use of this "quick incorrect. See Section 14.4 for hints on the proper use of this
check". "quick check".
5.9. Marker Packet (Tag 10) 5.8. Marker Packet (Tag 10)
The body of this packet consists of: The body of this packet consists of:
* The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). * The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).
Such a packet MUST be ignored when received. Such a packet MUST be ignored when received.
5.10. Literal Data Packet (Tag 11) 5.9. Literal Data Packet (Tag 11)
A Literal Data packet contains the body of a message; data that is A Literal Data packet contains the body of a message; data that is
not to be further interpreted. not to be further interpreted.
The body of this packet consists of: The body of this packet consists of:
* A one-octet field that describes how the data is formatted. * A one-octet field that describes how the data is formatted.
If it is a b (0x62), then the Literal packet contains binary data. If it is a b (0x62), then the Literal packet contains binary data.
If it is a u (0x75), then the Literal packet contains UTF- If it is a u (0x75), then the Literal packet contains UTF-
skipping to change at page 68, line 36 skipping to change at page 74, line 18
file. An implementation MAY consider the file name in the Literal file. An implementation MAY consider the file name in the Literal
packet to be a more authoritative name than the actual file name. packet to be a more authoritative name than the actual file name.
* A four-octet number that indicates a date associated with the * A four-octet number that indicates a date associated with the
literal data. Commonly, the date might be the modification date literal data. Commonly, the date might be the modification date
of a file, or the time the packet was created, or a zero that of a file, or the time the packet was created, or a zero that
indicates no specific time. indicates no specific time.
* The remainder of the packet is literal data. * The remainder of the packet is literal data.
Text data is stored with <CR><LF> text endings (that is, network- Text data MUST be encoded with UTF-8 (see [RFC3629]), and stored
normal line endings). These should be converted to native line with <CR><LF> text endings (that is, network-normal line endings).
endings by the receiving software. These should be converted to native line endings by the receiving
software.
Note that OpenPGP signatures do not include the formatting octet, the Note that OpenPGP signatures do not include the formatting octet, the
file name, and the date field of the literal packet in a signature file name, and the date field of the literal packet in a signature
hash and thus those fields are not protected against tampering in a hash and thus those fields are not protected against tampering in a
signed document. A receiving implementation MUST NOT treat those signed document. A receiving implementation MUST NOT treat those
fields as though they were cryptographically secured by the fields as though they were cryptographically secured by the
surrounding signature either when representing them to the user or surrounding signature either when representing them to the user or
acting on them. acting on them.
Due to their inherent malleability, an implementation that generates Due to their inherent malleability, an implementation that generates
skipping to change at page 69, line 21 skipping to change at page 75, line 5
[PAX]). [PAX]).
An implementation that generates a Literal Data packet MUST use the An implementation that generates a Literal Data packet MUST use the
OpenPGP format for packet framing (see Section 4.2.1). It MUST NOT OpenPGP format for packet framing (see Section 4.2.1). It MUST NOT
generate a Literal Data packet with Legacy format (Section 4.2.2) generate a Literal Data packet with Legacy format (Section 4.2.2)
An implementation that deals with either historic data or data An implementation that deals with either historic data or data
generated by legacy implementations MAY interpret Literal Data generated by legacy implementations MAY interpret Literal Data
packets that use the Legacy format for packet framing. packets that use the Legacy format for packet framing.
5.10.1. Special Filename _CONSOLE (Deprecated) 5.9.1. Special Filename _CONSOLE (Deprecated)
The Literal Data packet's filename field has a historical special The Literal Data packet's filename field has a historical special
case for the special name _CONSOLE. When the filename field is case for the special name _CONSOLE. When the filename field is
_CONSOLE, the message is considered to be "for your eyes only". This _CONSOLE, the message is considered to be "for your eyes only". This
advises that the message data is unusually sensitive, and the advises that the message data is unusually sensitive, and the
receiving program should process it more carefully, perhaps avoiding receiving program should process it more carefully, perhaps avoiding
storing the received data to disk, for example. storing the received data to disk, for example.
An OpenPGP deployment that generates literal data packets MUST NOT An OpenPGP deployment that generates literal data packets MUST NOT
depend on this indicator being honored in any particular way. It depend on this indicator being honored in any particular way. It
cannot be enforced, and the field itself is not covered by any cannot be enforced, and the field itself is not covered by any
cryptographic signature. cryptographic signature.
It is NOT RECOMMENDED to use this special filename in a newly- It is NOT RECOMMENDED to use this special filename in a newly-
generated literal data packet. generated literal data packet.
5.11. Trust Packet (Tag 12) 5.10. Trust Packet (Tag 12)
The Trust packet is used only within keyrings and is not normally The Trust packet is used only within keyrings and is not normally
exported. Trust packets contain data that record the user's exported. Trust packets contain data that record the user's
specifications of which key holders are trustworthy introducers, specifications of which key holders are trustworthy introducers,
along with other information that implementing software uses for along with other information that implementing software uses for
trust information. The format of Trust packets is defined by a given trust information. The format of Trust packets is defined by a given
implementation. implementation.
Trust packets SHOULD NOT be emitted to output streams that are Trust packets SHOULD NOT be emitted to output streams that are
transferred to other users, and they SHOULD be ignored on any input transferred to other users, and they SHOULD be ignored on any input
other than local keyring files. other than local keyring files.
5.12. User ID Packet (Tag 13) 5.11. User ID Packet (Tag 13)
A User ID packet consists of UTF-8 text that is intended to represent A User ID packet consists of UTF-8 text that is intended to represent
the name and email address of the key holder. By convention, it the name and email address of the key holder. By convention, it
includes an [RFC2822] mail name-addr, but there are no restrictions includes an [RFC2822] mail name-addr, but there are no restrictions
on its content. The packet length in the header specifies the length on its content. The packet length in the header specifies the length
of the User ID. of the User ID.
5.13. User Attribute Packet (Tag 17) 5.12. User Attribute Packet (Tag 17)
The User Attribute packet is a variation of the User ID packet. It The User Attribute packet is a variation of the User ID packet. It
is capable of storing more types of data than the User ID packet, is capable of storing more types of data than the User ID packet,
which is limited to text. Like the User ID packet, a User Attribute which is limited to text. Like the User ID packet, a User Attribute
packet may be certified by the key owner ("self-signed") or any other packet may be certified by the key owner ("self-signed") or any other
key owner who cares to certify it. Except as noted, a User Attribute key owner who cares to certify it. Except as noted, a User Attribute
packet may be used anywhere that a User ID packet may be used. packet may be used anywhere that a User ID packet may be used.
While User Attribute packets are not a required part of the OpenPGP While User Attribute packets are not a required part of the OpenPGP
standard, implementations SHOULD provide at least enough standard, implementations SHOULD provide at least enough
skipping to change at page 70, line 49 skipping to change at page 76, line 32
The following table lists the currently known subpackets: The following table lists the currently known subpackets:
+=========+===========================+ +=========+===========================+
| Type | Attribute Subpacket | | Type | Attribute Subpacket |
+=========+===========================+ +=========+===========================+
| 1 | Image Attribute Subpacket | | 1 | Image Attribute Subpacket |
+---------+---------------------------+ +---------+---------------------------+
| 100-110 | Private/Experimental Use | | 100-110 | Private/Experimental Use |
+---------+---------------------------+ +---------+---------------------------+
Table 15: User Attribute type registry Table 17: User Attribute type registry
An implementation SHOULD ignore any subpacket of a type that it does An implementation SHOULD ignore any subpacket of a type that it does
not recognize. not recognize.
5.13.1. The Image Attribute Subpacket 5.12.1. The Image Attribute Subpacket
The Image Attribute subpacket is used to encode an image, presumably The Image Attribute subpacket is used to encode an image, presumably
(but not required to be) that of the key owner. (but not required to be) that of the key owner.
The Image Attribute subpacket begins with an image header. The first The Image Attribute subpacket begins with an image header. The first
two octets of the image header contain the length of the image two octets of the image header contain the length of the image
header. Note that unlike other multi-octet numerical values in this header. Note that unlike other multi-octet numerical values in this
document, due to a historical accident this value is encoded as a document, due to a historical accident this value is encoded as a
little-endian number. The image header length is followed by a little-endian number. The image header length is followed by a
single octet for the image header version. The only currently single octet for the image header version. The only currently
skipping to change at page 71, line 37 skipping to change at page 77, line 22
The rest of the image subpacket contains the image itself. As the The rest of the image subpacket contains the image itself. As the
only currently defined image type is JPEG, the image is encoded in only currently defined image type is JPEG, the image is encoded in
the JPEG File Interchange Format (JFIF), a standard file format for the JPEG File Interchange Format (JFIF), a standard file format for
JPEG images [JFIF]. JPEG images [JFIF].
An implementation MAY try to determine the type of an image by An implementation MAY try to determine the type of an image by
examination of the image data if it is unable to handle a particular examination of the image data if it is unable to handle a particular
version of the image header or if a specified encoding format value version of the image header or if a specified encoding format value
is not recognized. is not recognized.
5.14. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18)
This packet contains integrity protected and encrypted data. When it This packet contains integrity protected and encrypted data. When it
has been decrypted, it will contain other packets forming an OpenPGP has been decrypted, it will contain other packets forming an OpenPGP
Message (see Section 11.3). Message (see Section 11.3).
The first octet of this packet is always used to indicate the version The first octet of this packet is always used to indicate the version
number, but different versions contain differently-structured number, but different versions contain differently-structured
ciphertext. Version 1 of this packet contains data encrypted with a ciphertext. Version 1 of this packet contains data encrypted with a
symmetric-key algorithm and protected against modification by the symmetric-key algorithm and protected against modification by the
SHA-1 hash algorithm. This is a legacy OpenPGP mechanism that offers SHA-1 hash algorithm. This is a legacy OpenPGP mechanism that offers
some protections against ciphertext malleability. some protections against ciphertext malleability.
Version 2 of this packet contains data encrypted with an Version 2 of this packet contains data encrypted with an
authenticated encryption and additional data (AEAD) construction. authenticated encryption and additional data (AEAD) construction.
This offers a more cryptographically rigorous defense against This offers a more cryptographically rigorous defense against
ciphertext malleability, but may not be as widely supported yet. See ciphertext malleability, but may not be as widely supported yet. See
Section 15.1 for more details on choosing between these formats. Section 14.7 for more details on choosing between these formats.
5.14.1. Version 1 Sym. Encrypted Integrity Protected Data Packet Format 5.13.1. Version 1 Sym. Encrypted Integrity Protected Data Packet Format
A version 1 Symmetrically Encrypted Integrity Protected Data packet A version 1 Symmetrically Encrypted Integrity Protected Data packet
consists of: consists of:
* A one-octet version number with value 1. * A one-octet version number with value 1.
* Encrypted data, the output of the selected symmetric-key cipher * Encrypted data, the output of the selected symmetric-key cipher
operating in Cipher Feedback mode with shift amount equal to the operating in Cipher Feedback mode with shift amount equal to the
block size of the cipher (CFB-n where n is the block size). block size of the cipher (CFB-n where n is the block size).
skipping to change at page 72, line 40 skipping to change at page 78, line 23
zeros. Instead of using an IV, OpenPGP prefixes an octet string to zeros. Instead of using an IV, OpenPGP prefixes an octet string to
the data before it is encrypted. The length of the octet string the data before it is encrypted. The length of the octet string
equals the block size of the cipher in octets, plus two. The first equals the block size of the cipher in octets, plus two. The first
octets in the group, of length equal to the block size of the cipher, octets in the group, of length equal to the block size of the cipher,
are random; the last two octets are each copies of their 2nd are random; the last two octets are each copies of their 2nd
preceding octet. For example, with a cipher whose block size is 128 preceding octet. For example, with a cipher whose block size is 128
bits or 16 octets, the prefix data will contain 16 random octets, bits or 16 octets, the prefix data will contain 16 random octets,
then two more octets, which are copies of the 15th and 16th octets, then two more octets, which are copies of the 15th and 16th octets,
respectively. Unlike the Symmetrically Encrypted Data Packet, no respectively. Unlike the Symmetrically Encrypted Data Packet, no
special CFB resynchronization is done after encrypting this prefix special CFB resynchronization is done after encrypting this prefix
data. See Section 14.9 for more details. data. See Section 13.9 for more details.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. incorrect.
Two constant octets with the values 0xD3 and 0x14 are appended to the Two constant octets with the values 0xD3 and 0x14 are appended to the
plaintext. Then, the plaintext of the data to be encrypted is passed plaintext. Then, the plaintext of the data to be encrypted is passed
through the SHA-1 hash function. The input to the hash function through the SHA-1 hash function. The input to the hash function
includes the prefix data described above; it includes all of the includes the prefix data described above; it includes all of the
plaintext, including the trailing constant octets 0xD3, 0x14. The 20 plaintext, including the trailing constant octets 0xD3, 0x14. The 20
skipping to change at page 74, line 21 skipping to change at page 80, line 4
modest requirements on the hash function(s) it employs. It does modest requirements on the hash function(s) it employs. It does
not rely on a hash function being collision-free, it relies on a not rely on a hash function being collision-free, it relies on a
hash function being one-way. If a forger, Frank, wishes to send hash function being one-way. If a forger, Frank, wishes to send
Alice a (digitally) unsigned message that says, "I've always Alice a (digitally) unsigned message that says, "I've always
secretly loved you, signed Bob", it is far easier for him to secretly loved you, signed Bob", it is far easier for him to
construct a new message than it is to modify anything intercepted construct a new message than it is to modify anything intercepted
from Bob. (Note also that if Bob wishes to communicate secretly from Bob. (Note also that if Bob wishes to communicate secretly
with Alice, but without authentication or identification and with with Alice, but without authentication or identification and with
a threat model that includes forgers, he has a problem that a threat model that includes forgers, he has a problem that
transcends mere cryptography.) transcends mere cryptography.)
Note also that unlike nearly every other OpenPGP subsystem, there Note also that unlike nearly every other OpenPGP subsystem, there
are no parameters in the MDC system. It hard-defines SHA-1 as its are no parameters in the MDC system. It hard-defines SHA-1 as its
hash function. This is not an accident. It is an intentional hash function. This is not an accident. It is an intentional
choice to avoid downgrade and cross-grade attacks while making a choice to avoid downgrade and cross-grade attacks while making a
simple, fast system. (A downgrade attack would be an attack that simple, fast system. (A downgrade attack would be an attack that
replaced SHA2-256 with SHA-1, for example. A cross-grade attack replaced SHA2-256 with SHA-1, for example. A cross-grade attack
would replace SHA-1 with another 160-bit hash, such as RIPE- would replace SHA-1 with another 160-bit hash, such as RIPEMD-160,
MD/160, for example.) for example.)
However, no update will be needed because the MDC has been However, no update will be needed because the MDC has been
replaced by the AEAD encryption described in this document. replaced by the AEAD encryption described in this document.
5.14.2. Version 2 Sym. Encrypted Integrity Protected Data Packet Format 5.13.2. Version 2 Sym. Encrypted Integrity Protected Data Packet Format
A version 2 Symmetrically Encrypted Integrity Protected Data packet A version 2 Symmetrically Encrypted Integrity Protected Data packet
consists of: consists of:
* A one-octet version number with value 2. * A one-octet version number with value 2.
* A one-octet cipher algorithm. * A one-octet cipher algorithm.
* A one-octet AEAD algorithm. * A one-octet AEAD algorithm.
skipping to change at page 76, line 14 skipping to change at page 81, line 48
An implementation MUST accept chunk size octets with values from 0 to An implementation MUST accept chunk size octets with values from 0 to
16. An implementation MUST NOT create data with a chunk size octet 16. An implementation MUST NOT create data with a chunk size octet
value larger than 16 (4 MiB chunks). value larger than 16 (4 MiB chunks).
The nonce for AEAD mode consists of two parts. Let N be the size of The nonce for AEAD mode consists of two parts. Let N be the size of
the nonce. The left-most N - 64 bits are the initialization vector the nonce. The left-most N - 64 bits are the initialization vector
derived using HKDF. The right-most 64 bits are the chunk index as derived using HKDF. The right-most 64 bits are the chunk index as
big-endian value. The index of the first chunk is zero. big-endian value. The index of the first chunk is zero.
5.14.3. EAX Mode 5.13.3. EAX Mode
The EAX AEAD Algorithm used in this document is defined in [EAX]. The EAX AEAD Algorithm used in this document is defined in [EAX].
The EAX algorithm can only use block ciphers with 16-octet blocks. The EAX algorithm can only use block ciphers with 16-octet blocks.
The nonce is 16 octets long. EAX authentication tags are 16 octets The nonce is 16 octets long. EAX authentication tags are 16 octets
long. long.
5.14.4. OCB Mode 5.13.4. OCB Mode
The OCB AEAD Algorithm used in this document is defined in [RFC7253]. The OCB AEAD Algorithm used in this document is defined in [RFC7253].
The OCB algorithm can only use block ciphers with 16-octet blocks. The OCB algorithm can only use block ciphers with 16-octet blocks.
The nonce is 15 octets long. OCB authentication tags are 16 octets The nonce is 15 octets long. OCB authentication tags are 16 octets
long. long.
5.14.5. GCM Mode 5.13.5. GCM Mode
The GCM AEAD Algorithm used in this document is defined in The GCM AEAD Algorithm used in this document is defined in
[SP800-38D]. [SP800-38D].
The GCM algorithm can only use block ciphers with 16-octet blocks. The GCM algorithm can only use block ciphers with 16-octet blocks.
The nonce is 12 octets long. GCM authentication tags are 16 octets The nonce is 12 octets long. GCM authentication tags are 16 octets
long. long.
5.15. Padding Packet (Tag 21) 5.14. Padding Packet (Tag 21)
The Padding packet contains random data, and can be used to defend The Padding packet contains random data, and can be used to defend
against traffic analysis (see Section 15.4) on version 2 SEIPD against traffic analysis (see Section 14.10) on version 2 SEIPD
messages (see Section 5.14.2) and Transferable Public Keys (see messages (see Section 5.13.2) and Transferable Public Keys (see
Section 11.1). Section 11.1).
Such a packet MUST be ignored when received. Such a packet MUST be ignored when received.
Its contents SHOULD be random octets to make the length obfuscation Its contents SHOULD be random octets to make the length obfuscation
it provides more robust even when compressed. it provides more robust even when compressed.
An implementation adding padding to an OpenPGP stream SHOULD place An implementation adding padding to an OpenPGP stream SHOULD place
such a packet: such a packet:
skipping to change at page 77, line 37 skipping to change at page 83, line 26
of the unsafe channel would suffice, since it would not change the of the unsafe channel would suffice, since it would not change the
underlying binary bit streams of the native OpenPGP data structures. underlying binary bit streams of the native OpenPGP data structures.
The OpenPGP standard specifies one such printable encoding scheme to The OpenPGP standard specifies one such printable encoding scheme to
ensure interoperability. ensure interoperability.
OpenPGP's Radix-64 encoding is composed of two parts: a base64 OpenPGP's Radix-64 encoding is composed of two parts: a base64
encoding of the binary data and an optional checksum. The base64 encoding of the binary data and an optional checksum. The base64
encoding is identical to the MIME base64 content-transfer-encoding encoding is identical to the MIME base64 content-transfer-encoding
[RFC2045]. [RFC2045].
6.1. Optional checksum
The optional checksum is a 24-bit Cyclic Redundancy Check (CRC) The optional checksum is a 24-bit Cyclic Redundancy Check (CRC)
converted to four characters of radix-64 encoding by the same MIME converted to four characters of radix-64 encoding by the same MIME
base64 transformation, preceded by an equal sign (=). The CRC is base64 transformation, preceded by an equal sign (=). The CRC is
computed by using the generator 0x864CFB and an initialization of computed by using the generator 0x864CFB and an initialization of
0xB704CE. The accumulation is done on the data before it is 0xB704CE. The accumulation is done on the data before it is
converted to radix-64, rather than on the converted data. A sample converted to radix-64, rather than on the converted data. A sample
implementation of this algorithm is in Section 6.1. implementation of this algorithm is in Section 6.1.1.
If present, the checksum with its leading equal sign MUST appear on If present, the checksum with its leading equal sign MUST appear on
the next line after the base64 encoded data. the next line after the base64 encoded data.
Rationale for CRC-24: The size of 24 bits fits evenly into printable An implementation MUST NOT reject an OpenPGP object when the CRC24
base64. The nonzero initialization can detect more errors than a footer is present, missing, malformed, or disagrees with the computed
zero initialization. CRC24 sum. When forming ASCII Armor, the CRC24 footer SHOULD NOT be
generated, unless interoperability with implementations that require
the CRC24 footer to be present is a concern.
6.1. An Implementation of the CRC-24 in "C" The CRC24 footer MUST NOT be generated if it can be determined by
context or by the OpenPGP object being encoded that the consuming
implementation accepts Radix-64 encoded blocks without CRC24 footer.
Notably:
* An ASCII-armored Encrypted Message packet sequence that ends in an
v2 SEIPD packet MUST NOT contain a CRC24 footer.
* An ASCII-armored sequence of Signature packets that only includes
v5 Signature packets MUST NOT contain a CRC24 footer.
* An ASCII-armored Transferable Public Key packet sequence of a v5
key MUST NOT contain a CRC24 footer.
* An ASCII-armored keyring consisting of only v5 keys MUST NOT
contain a CRC24 footer.
Rationale: Previous versions of this document state that the CRC24
footer is optional, but the text was ambiguous. In practice, very
few implementations require the CRC24 footer to be present.
Computing the CRC24 incurs a significant cost, while providing no
meaningful integrity protection. Therefore, generating it is now
discouraged.
6.1.1. An Implementation of the CRC-24 in "C"
#define CRC24_INIT 0xB704CEL #define CRC24_INIT 0xB704CEL
#define CRC24_GENERATOR 0x864CFBL #define CRC24_GENERATOR 0x864CFBL
typedef unsigned long crc24; typedef unsigned long crc24;
crc24 crc_octets(unsigned char *octets, size_t len) crc24 crc_octets(unsigned char *octets, size_t len)
{ {
crc24 crc = CRC24_INIT; crc24 crc = CRC24_INIT;
int i; int i;
while (len--) { while (len--) {
skipping to change at page 78, line 46 skipping to change at page 85, line 13
Concatenating the following data creates ASCII Armor: Concatenating the following data creates ASCII Armor:
* An Armor Header Line, appropriate for the type of data * An Armor Header Line, appropriate for the type of data
* Armor Headers * Armor Headers
* A blank (zero-length, or containing only whitespace) line * A blank (zero-length, or containing only whitespace) line
* The ASCII-Armored data * The ASCII-Armored data
* An Armor Checksum * An optional Armor Checksum (discouraged, see Section 6.1)
* The Armor Tail, which depends on the Armor Header Line * The Armor Tail, which depends on the Armor Header Line
An Armor Header Line consists of the appropriate header line text An Armor Header Line consists of the appropriate header line text
surrounded by five (5) dashes (-, 0x2D) on either side of the header surrounded by five (5) dashes (-, 0x2D) on either side of the header
line text. The header line text is chosen based upon the type of line text. The header line text is chosen based upon the type of
data that is being encoded in Armor, and how it is being encoded. data that is being encoded in Armor, and how it is being encoded.
Header line texts include the following strings: Header line texts include the following strings:
BEGIN PGP MESSAGE BEGIN PGP MESSAGE
Used for signed, encrypted, or compressed files. Used for signed, encrypted, or compressed files.
BEGIN PGP PUBLIC KEY BLOCK BEGIN PGP PUBLIC KEY BLOCK
skipping to change at page 79, line 19 skipping to change at page 85, line 32
BEGIN PGP MESSAGE BEGIN PGP MESSAGE
Used for signed, encrypted, or compressed files. Used for signed, encrypted, or compressed files.
BEGIN PGP PUBLIC KEY BLOCK BEGIN PGP PUBLIC KEY BLOCK
Used for armoring public keys. Used for armoring public keys.
BEGIN PGP PRIVATE KEY BLOCK BEGIN PGP PRIVATE KEY BLOCK
Used for armoring private keys. Used for armoring private keys.
BEGIN PGP MESSAGE, PART X/Y
Used for multi-part messages, where the armor is split amongst Y
parts, and this is the Xth part out of Y.
BEGIN PGP MESSAGE, PART X
Used for multi-part messages, where this is the Xth part of an
unspecified number of parts. Requires the MESSAGE-ID Armor Header
to be used.
BEGIN PGP SIGNATURE BEGIN PGP SIGNATURE
Used for detached signatures, OpenPGP/MIME signatures, and Used for detached signatures, OpenPGP/MIME signatures, and
cleartext signatures. cleartext signatures.
Note that all these Armor Header Lines are to consist of a complete Note that all these Armor Header Lines are to consist of a complete
line. That is to say, there is always a line ending preceding the line. That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text other than whitespace following them on the same MUST NOT have text other than whitespace following them on the same
line. These line endings are considered a part of the Armor Header line. These line endings are considered a part of the Armor Header
skipping to change at page 80, line 6 skipping to change at page 86, line 6
is particularly important when computing a cleartext signature (see is particularly important when computing a cleartext signature (see
Section 7). Section 7).
The Armor Headers are pairs of strings that can give the user or the The Armor Headers are pairs of strings that can give the user or the
receiving OpenPGP implementation some information about how to decode receiving OpenPGP implementation some information about how to decode
or use the message. The Armor Headers are a part of the armor, not a or use the message. The Armor Headers are a part of the armor, not a
part of the message, and hence are not protected by any signatures part of the message, and hence are not protected by any signatures
applied to the message. applied to the message.
The format of an Armor Header is that of a key-value pair. A colon The format of an Armor Header is that of a key-value pair. A colon
(: 0x38) and a single space (0x20) separate the key and value. (: 0x38) and a single space (0x20) separate the key and value. An
OpenPGP should consider improperly formatted Armor Headers to be OpenPGP implementation may consider improperly formatted Armor
corruption of the ASCII Armor. Unknown keys should be reported to Headers to be corruption of the ASCII Armor, but SHOULD make an
the user, but OpenPGP should continue to process the message. effort to recover. Unknown keys should be silently ignored, and an
OpenPGP implementation SHOULD continue to process the message.
Note that some transport methods are sensitive to line length. While Note that some transport methods are sensitive to line length. While
there is a limit of 76 characters for the Radix-64 data there is a limit of 76 characters for the Radix-64 data
(Section 6.3), there is no limit to the length of Armor Headers. (Section 6.3), there is no limit to the length of Armor Headers.
Care should be taken that the Armor Headers are short enough to Care should be taken that the Armor Headers are short enough to
survive transport. One way to do this is to repeat an Armor Header survive transport. One way to do this is to repeat an Armor Header
Key multiple times with different values for each so that no one line Key multiple times with different values for each so that no one line
is overly long. is overly long.
Currently defined Armor Header Keys are as follows: Currently defined Armor Header Keys are as follows:
skipping to change at page 80, line 32 skipping to change at page 86, line 33
used to encode the message. To minimize metadata, implementations used to encode the message. To minimize metadata, implementations
SHOULD NOT emit this key and its corresponding value except for SHOULD NOT emit this key and its corresponding value except for
debugging purposes with explicit user consent. debugging purposes with explicit user consent.
* "Comment", a user-defined comment. OpenPGP defines all text to be * "Comment", a user-defined comment. OpenPGP defines all text to be
in UTF-8. A comment may be any UTF-8 string. However, the whole in UTF-8. A comment may be any UTF-8 string. However, the whole
point of armoring is to provide seven-bit-clean data. point of armoring is to provide seven-bit-clean data.
Consequently, if a comment has characters that are outside the US- Consequently, if a comment has characters that are outside the US-
ASCII range of UTF, they may very well not survive transport. ASCII range of UTF, they may very well not survive transport.
* "MessageID", a 32-character string of printable characters. The
string must be the same for all parts of a multi-part message that
uses the "PART X" Armor Header. MessageID strings should be
unique enough that the recipient of the mail can associate all the
parts of a message with each other. A good checksum or
cryptographic hash function is sufficient.
The MessageID SHOULD NOT appear unless it is in a multi-part
message. If it appears at all, it MUST be computed from the
finished (encrypted, signed, etc.) message in a deterministic
fashion, rather than contain a purely random value. This is to
allow the legitimate recipient to determine that the MessageID
cannot serve as a covert means of leaking cryptographic key
information.
* "Hash", a comma-separated list of hash algorithms used in this * "Hash", a comma-separated list of hash algorithms used in this
message. This is used only in cleartext signed messages. message. This is used only in cleartext signed messages.
* "SaltedHash", a salt and hash algorithm used in this message. * "SaltedHash", a salt and hash algorithm used in this message.
This is used only in cleartext signed messages that are followed This is used only in cleartext signed messages that are followed
by a v5 Signature. by a v5 Signature.
* "Charset", a description of the character set that the plaintext * "Charset", a description of the character set that the plaintext
is in. Please note that OpenPGP defines text to be in UTF-8. An is in. Please note that OpenPGP defines text to be in UTF-8. An
implementation will get best results by translating into and out implementation will get best results by translating into and out
skipping to change at page 82, line 43 skipping to change at page 88, line 43
+-----+--------++-----+---------++-----+----------++-----+----------+ +-----+--------++-----+---------++-----+----------++-----+----------+
| 13|N || 30|e || 47| v || | | | 13|N || 30|e || 47| v || | |
+-----+--------++-----+---------++-----+----------++-----+----------+ +-----+--------++-----+---------++-----+----------++-----+----------+
| 14|O || 31|f || 48| w ||(pad)| = | | 14|O || 31|f || 48| w ||(pad)| = |
+-----+--------++-----+---------++-----+----------++-----+----------+ +-----+--------++-----+---------++-----+----------++-----+----------+
| 15|P || 32|g || 49| x || | | | 15|P || 32|g || 49| x || | |
+-----+--------++-----+---------++-----+----------++-----+----------+ +-----+--------++-----+---------++-----+----------++-----+----------+
| 16|Q || 33|h || 50| y || | | | 16|Q || 33|h || 50| y || | |
+-----+--------++-----+---------++-----+----------++-----+----------+ +-----+--------++-----+---------++-----+----------++-----+----------+
Table 16: Encoding for Radix-64 Table 18: Encoding for Radix-64
The encoded output stream must be represented in lines of no more The encoded output stream must be represented in lines of no more
than 76 characters each. than 76 characters each.
Special processing is performed if fewer than 24 bits are available Special processing is performed if fewer than 24 bits are available
at the end of the data being encoded. There are three possibilities: at the end of the data being encoded. There are three possibilities:
1. The last data group has 24 bits (3 octets). No special 1. The last data group has 24 bits (3 octets). No special
processing is needed. processing is needed.
skipping to change at page 84, line 33 skipping to change at page 90, line 33
Decimal: 5 15 46 28 0 48 Decimal: 5 15 46 28 0 48
pad with = = pad with = =
Output: F P u c A w = = Output: F P u c A w = =
6.6. Example of an ASCII Armored Message 6.6. Example of an ASCII Armored Message
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA== vBSFjNSiVHsuAA==
=njUN
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
Note that this example has extra indenting; an actual armored message Note that this example has extra indenting; an actual armored message
would have no leading whitespace. would have no leading whitespace.
7. Cleartext Signature Framework 7. Cleartext Signature Framework
It is desirable to be able to sign a textual octet stream without It is desirable to be able to sign a textual octet stream without
ASCII armoring the stream itself, so the signed text is still ASCII armoring the stream itself, so the signed text is still
readable without special software. In order to bind a signature to readable without special software. In order to bind a signature to
skipping to change at page 85, line 24 skipping to change at page 91, line 24
* Exactly one empty line not included into the message digest, * Exactly one empty line not included into the message digest,
* The dash-escaped cleartext that is included into the message * The dash-escaped cleartext that is included into the message
digest, digest,
* The ASCII armored signature(s) including the -----BEGIN PGP * The ASCII armored signature(s) including the -----BEGIN PGP
SIGNATURE----- Armor Header and Armor Tail Lines. SIGNATURE----- Armor Header and Armor Tail Lines.
If the "Hash" Armor Header is given, the specified message digest If the "Hash" Armor Header is given, the specified message digest
algorithm(s) are used for the signature. If more than one message algorithm(s) are used for the signature. If more than one message
digest is used in the signature, the "Hash" armor header contains a digest is used in the signatures, each digest algorithm has to be
comma-delimited list of used message digests. specified. To that end, the "Hash" Armor Header contains a comma-
delimited list of used message digests, and the "Hash" Armor Header
can be given multiple times.
If the "SaltedHash" Armor Header is given, the specified message If the "SaltedHash" Armor Header is given, the specified message
digest algorithm and salt are used for a signature. The message digest algorithm and salt are used for a signature. The message
digest name is followed by a colon (:) followed by 22 characters of digest name is followed by a colon (:) followed by 22 characters of
Radix-64 encoded salt without padding. Note: The "SaltedHash" Armor Radix-64 encoded salt without padding. Note: The "SaltedHash" Armor
Header contains digest algorithm and salt for a single signature; a Header contains digest algorithm and salt for a single signature; a
second signature requires a second "SaltedHash" Armor Header. second signature requires a second "SaltedHash" Armor Header.
If neither a "Hash" nor a "SaltedHash" Armor Header is given, or the
message digest algorithms (and salts) used in the signatures do not
match the information in the headers, the signature MUST be
considered invalid.
Current message digest names are described with the algorithm IDs in Current message digest names are described with the algorithm IDs in
Section 9.5. Section 9.5.
An implementation SHOULD add a line break after the cleartext, but An implementation SHOULD add a line break after the cleartext, but
MAY omit it if the cleartext ends with a line break. This is for MAY omit it if the cleartext ends with a line break. This is for
visual clarity. visual clarity.
7.1. Dash-Escaped Text 7.1. Dash-Escaped Text
The cleartext content of the message must also be dash-escaped. The cleartext content of the message must also be dash-escaped.
skipping to change at page 87, line 14 skipping to change at page 93, line 19
9. Constants 9. Constants
This section describes the constants used in OpenPGP. This section describes the constants used in OpenPGP.
Note that these tables are not exhaustive lists; an implementation Note that these tables are not exhaustive lists; an implementation
MAY implement an algorithm not on these lists, so long as the MAY implement an algorithm not on these lists, so long as the
algorithm numbers are chosen from the private or experimental algorithm numbers are chosen from the private or experimental
algorithm range. algorithm range.
See Section 14 for more discussion of the algorithms. See Section 13 for more discussion of the algorithms.
9.1. Public-Key Algorithms 9.1. Public-Key Algorithms
+===+==============+===========+============+===========+===========+ +===+==============+===========+============+===========+===========+
| ID|Algorithm |Public Key |Secret Key | Signature |PKESK | | ID|Algorithm |Public Key |Secret Key | Signature |PKESK |
| | |Format |Format | Format |Format | | | |Format |Format | Format |Format |
+===+==============+===========+============+===========+===========+ +===+==============+===========+============+===========+===========+
| 1|RSA (Encrypt |MPI(n), |MPI(d), | MPI(m**d |MPI(m**e | | 1|RSA (Encrypt |MPI(n), |MPI(d), | MPI(m**d |MPI(m**e |
| |or Sign) [HAC]|MPI(e) |MPI(p), | mod n) |mod n) | | |or Sign) [HAC]|MPI(e) |MPI(p), | mod n) |mod n) |
| | |[Section |MPI(q), | [Section |[Section | | | |[Section |MPI(q), | [Section |[Section |
| | |5.6.1] |MPI(u) | 5.2.3.1] |5.1.3] | | | |5.5.5.1] |MPI(u) | 5.2.3.1] |5.1.3] |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 2|RSA Encrypt- |MPI(n), |MPI(d), | N/A |MPI(m**e | | 2|RSA Encrypt- |MPI(n), |MPI(d), | N/A |MPI(m**e |
| |Only [HAC] |MPI(e) |MPI(p), | |mod n) | | |Only [HAC] |MPI(e) |MPI(p), | |mod n) |
| | |[Section |MPI(q), | |[Section | | | |[Section |MPI(q), | |[Section |
| | |5.6.1] |MPI(u) | |5.1.3] | | | |5.5.5.1] |MPI(u) | |5.1.3] |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 3|RSA Sign-Only |MPI(n), |MPI(d), | MPI(m**d |N/A | | 3|RSA Sign-Only |MPI(n), |MPI(d), | MPI(m**d |N/A |
| |[HAC] |MPI(e) |MPI(p), | mod n) | | | |[HAC] |MPI(e) |MPI(p), | mod n) | |
| | |[Section |MPI(q), | [Section | | | | |[Section |MPI(q), | [Section | |
| | |5.6.1] |MPI(u) | 5.2.3.1] | | | | |5.5.5.1] |MPI(u) | 5.2.3.1] | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 16|Elgamal |MPI(p), |MPI(x) | N/A |MPI(g**k | | 16|Elgamal |MPI(p), |MPI(x) | N/A |MPI(g**k |
| |(Encrypt-Only)|MPI(g), | | |mod p), MPI| | |(Encrypt-Only)|MPI(g), | | |mod p), MPI|
| |[ELGAMAL] |MPI(y) | | |(m * y**k | | |[ELGAMAL] |MPI(y) | | |(m * y**k |
| |[HAC] |[Section | | |mod p) | | |[HAC] |[Section | | |mod p) |
| | |5.6.3] | | |[Section | | | |5.5.5.3] | | |[Section |
| | | | | |5.1.4] | | | | | | |5.1.4] |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 17|DSA (Digital |MPI(p), |MPI(x) | MPI(r), |N/A | | 17|DSA (Digital |MPI(p), |MPI(x) | MPI(r), |N/A |
| |Signature |MPI(q), | | MPI(s) | | | |Signature |MPI(q), | | MPI(s) | |
| |Algorithm) |MPI(g), | | [Section | | | |Algorithm) |MPI(g), | | [Section | |
| |[FIPS186] |MPI(y) | | 5.2.3.2] | | | |[FIPS186] |MPI(y) | | 5.2.3.2] | |
| |[HAC] |[Section | | | | | |[HAC] |[Section | | | |
| | |5.6.2] | | | | | | |5.5.5.2] | | | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 18|ECDH public |OID, |MPI(value in| N/A |MPI(point | | 18|ECDH public |OID, |MPI(value in| N/A |MPI(point |
| |key algorithm |MPI(point |curve- | |in curve- | | |key algorithm |MPI(point |curve- | |in curve- |
| | |in curve- |specific | |specific | | | |in curve- |specific | |specific |
| | |specific |format) | |point | | | |specific |format) | |point |
| | |point |[Section | |format), | | | |point |[Section | |format), |
| | |format), |9.2.1] | |size octet,| | | |format), |9.2.1] | |size octet,|
| | |KDFParams | | |encoded key| | | |KDFParams | | |encoded key|
| | |[see | | |[Section | | | |[see | | |[Section |
| | |Section | | |9.2.1, | | | |Section | | |9.2.1, |
| | |9.2.1, | | |Section | | | |9.2.1, | | |Section |
| | |Section | | |5.1.5, | | | |Section | | |5.1.5, |
| | |5.6.6] | | |Section | | | |5.5.5.6] | | |Section |
| | | | | |13.5] | | | | | | |12.5] |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 19|ECDSA public |OID, |MPI(value) | MPI(r), |N/A | | 19|ECDSA public |OID, |MPI(value) | MPI(r), |N/A |
| |key algorithm |MPI(point | | MPI(s) | | | |key algorithm |MPI(point | | MPI(s) | |
| |[FIPS186] |in SEC1 | | [Section | | | |[FIPS186] |in SEC1 | | [Section | |
| | |format) | | 5.2.3.2] | | | | |format) | | 5.2.3.2] | |
| | |[Section | | | | | | |[Section | | | |
| | |5.6.4] | | | | | | |5.5.5.4] | | | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 20|Reserved | | | | | | 20|Reserved | | | | |
| |(formerly | | | | | | |(formerly | | | | |
| |Elgamal | | | | | | |Elgamal | | | | |
| |Encrypt or | | | | | | |Encrypt or | | | | |
| |Sign) | | | | | | |Sign) | | | | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 21|Reserved for | | | | | | 21|Reserved for | | | | |
| |Diffie-Hellman| | | | | | |Diffie-Hellman| | | | |
| |(X9.42, as | | | | | | |(X9.42, as | | | | |
| |defined for | | | | | | |defined for | | | | |
| |IETF-S/MIME) | | | | | | |IETF-S/MIME) | | | | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 22|EdDSA |OID, |MPI(value in| MPI, MPI |N/A | | 22|EdDSA |OID, |MPI(value in| MPI, MPI |N/A |
| |[RFC8032] |MPI(point |curve- | [see | | | |[RFC8032] |MPI(point |curve- | [see | |
| | |in prefixed|specific | Section | | | | |in prefixed|specific | Section | |
| | |native |format) [see| 9.2.1, | | | | |native |format) [see| 9.2.1, | |
| | |format) |Section | Section | | | | |format) |Section | Section | |
| | |[see |9.2.1] | 5.2.3.3] | | | | |[see |9.2.1] | 5.2.3.3] | |
| | |Section | | | | | | |Section | | | |
| | |13.2.2, | | | | | | |12.2.2, | | | |
| | |Section | | | | | | |Section | | | |
| | |5.6.5] | | | | | | |5.5.5.5] | | | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 23|Reserved | | | | | | 23|Reserved | | | | |
| |(AEDH) | | | | | | |(AEDH) | | | | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
| 24|Reserved | | | | | | 24|Reserved | | | | |
| |(AEDSA) | | | | | | |(AEDSA) | | | | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
|100|Private/ | | | | | |100|Private/ | | | | |
| to|Experimental | | | | | | to|Experimental | | | | |
|110|algorithm | | | | | |110|algorithm | | | | |
+---+--------------+-----------+------------+-----------+-----------+ +---+--------------+-----------+------------+-----------+-----------+
Table 17: Public-key algorithm registry Table 19: Public-key algorithm registry
Implementations MUST implement EdDSA (19) for signatures, and ECDH Implementations MUST implement EdDSA (19) for signatures, and ECDH
(18) for encryption. Implementations SHOULD implement RSA (1) for (18) for encryption.
signatures and encryption.
RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and SHOULD RSA (1) keys are deprecated and SHOULD NOT be generated, but may be
NOT be generated, but may be interpreted. See Section 14.4. See interpreted. RSA Encrypt-Only (2) and RSA Sign-Only (3) are
Section 14.8 for notes on Elgamal Encrypt or Sign (20), and X9.42 deprecated and MUST NOT be generated. See Section 13.4. Elgamal
(21). Implementations MAY implement any other algorithm. (16) keys are deprecated and MUST NOT be generated (see
Section 13.6). DSA (17) keys are deprecated and MUST NOT be
generated (see Section 13.5). See Section 13.8 for notes on Elgamal
Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement
any other algorithm.
Note that an implementation conforming to the previous version of Note that an implementation conforming to the previous version of
this standard ([RFC4880]) have only DSA (17) and Elgamal (16) as its this standard ([RFC4880]) have only DSA (17) and Elgamal (16) as its
MUST-implement algorithms. MUST-implement algorithms.
A compatible specification of ECDSA is given in [RFC6090] as "KT-I A compatible specification of ECDSA is given in [RFC6090] as "KT-I
Signatures" and in [SEC1]; ECDH is defined in Section 13.5 of this Signatures" and in [SEC1]; ECDH is defined in Section 12.5 of this
document. document.
9.2. ECC Curves for OpenPGP 9.2. ECC Curves for OpenPGP
The parameter curve OID is an array of octets that define a named The parameter curve OID is an array of octets that define a named
curve. curve.
The table below specifies the exact sequence of octets for each named The table below specifies the exact sequence of octets for each named
curve referenced in this document. It also specifies which public curve referenced in this document. It also specifies which public
key algorithms the curve can be used with, as well as the size of key algorithms the curve can be used with, as well as the size of
skipping to change at page 90, line 31 skipping to change at page 96, line 31
| | |DA 47 0F 01 | | | | | | |DA 47 0F 01 | | | |
+----------------------+---+--------------+----------+------+-------+ +----------------------+---+--------------+----------+------+-------+
|1.3.101.113 |3 |2B 65 71 |Ed448 |EdDSA |57 | |1.3.101.113 |3 |2B 65 71 |Ed448 |EdDSA |57 |
+----------------------+---+--------------+----------+------+-------+ +----------------------+---+--------------+----------+------+-------+
|1.3.6.1.4.1.3029.1.5.1|10 |2B 06 01 04 01|Curve25519|ECDH |32 | |1.3.6.1.4.1.3029.1.5.1|10 |2B 06 01 04 01|Curve25519|ECDH |32 |
| | |97 55 01 05 01| | | | | | |97 55 01 05 01| | | |
+----------------------+---+--------------+----------+------+-------+ +----------------------+---+--------------+----------+------+-------+
|1.3.101.111 |3 |2B 65 6F |X448 |ECDH |56 | |1.3.101.111 |3 |2B 65 6F |X448 |ECDH |56 |
+----------------------+---+--------------+----------+------+-------+ +----------------------+---+--------------+----------+------+-------+
Table 18: ECC Curve OID and usage registry Table 20: ECC Curve OID and usage registry
The "Field Size (fsize)" column represents the field size of the The "Field Size (fsize)" column represents the field size of the
group in number of octets, rounded up, such that x or y coordinates group in number of octets, rounded up, such that x or y coordinates
for a point on the curve, native point representations, or scalars for a point on the curve, native point representations, or scalars
with high enough entropy for the curve can be represented in that with high enough entropy for the curve can be represented in that
many octets. many octets.
The sequence of octets in the third column is the result of applying The sequence of octets in the third column is the result of applying
the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier
with subsequent truncation. The truncation removes the two fields of with subsequent truncation. The truncation removes the two fields of
skipping to change at page 91, line 12 skipping to change at page 97, line 12
Curve25519 for use with ECDH. Implementations SHOULD implement Ed448 Curve25519 for use with ECDH. Implementations SHOULD implement Ed448
for use with EdDSA, and X448 for use with ECDH. for use with EdDSA, and X448 for use with ECDH.
9.2.1. Curve-Specific Wire Formats 9.2.1. Curve-Specific Wire Formats
Some Elliptic Curve Public Key Algorithms use different conventions Some Elliptic Curve Public Key Algorithms use different conventions
for specific fields depending on the curve in use. Each field is for specific fields depending on the curve in use. Each field is
always formatted as an MPI, but with a curve-specific framing. This always formatted as an MPI, but with a curve-specific framing. This
table summarizes those distinctions. table summarizes those distinctions.
+===========+========+============+========+=========+==============+ +==========+========+=============+========+=========+==============+
|Curve |ECDH |ECDH Secret |EdDSA |EdDSA |EdDSA | |Curve |ECDH |ECDH Secret |EdDSA |EdDSA |EdDSA |
| |Point |Key MPI |Secret |Signature|Signature | | |Point |Key MPI |Secret |Signature|Signature |
| |Format | |Key MPI |first MPI|second MPI | | |Format | |Key MPI |first MPI|second MPI |
+===========+========+============+========+=========+==============+ +==========+========+=============+========+=========+==============+
|NIST P-256 |SEC1 |integer |N/A |N/A |N/A | |NIST P-256|SEC1 |integer |N/A |N/A |N/A |
+-----------+--------+------------+--------+---------+--------------+ +----------+--------+-------------+--------+---------+--------------+
|NIST P-384 |SEC1 |integer |N/A |N/A |N/A | |NIST P-384|SEC1 |integer |N/A |N/A |N/A |
+-----------+--------+------------+--------+---------+--------------+ +----------+--------+-------------+--------+---------+--------------+
|NIST P-521 |SEC1 |integer |N/A |N/A |N/A | |NIST P-521|SEC1 |integer |N/A |N/A |N/A |
+-----------+--------+------------+--------+---------+--------------+ +----------+--------+-------------+--------+---------+--------------+
|Ed25519 |N/A |N/A |32 |32 octets|32 octets of S| |Ed25519 |N/A |N/A |32 |32 octets|32 octets of S|
| | | |octets |of R | | | | | |octets |of R | |
| | | |of | | | | | | |of | | |
| | | |secret | | | | | | |secret | | |
+-----------+--------+------------+--------+---------+--------------+ +----------+--------+-------------+--------+---------+--------------+
|Ed448 |N/A |N/A |prefixed|prefixed |0 [this is an | |Ed448 |N/A |N/A |prefixed|prefixed |0 [this is an |
| | | |57 |114 |unused | | | | |57 |114 |unused |
| | | |octets |octets of|placeholder] | | | | |octets |octets of|placeholder] |
| | | |of |signature| | | | | |of |signature| |
| | | |secret | | | | | | |secret | | |
+-----------+--------+------------+--------+---------+--------------+ +----------+--------+-------------+--------+---------+--------------+
|Curve25519 |prefixed|integer (see|N/A |N/A |N/A | |Curve25519|prefixed|integer (see |N/A |N/A |N/A |
| |native |Section | | | | | |native |Section | | | |
| | |5.6.6.1.1) | | | | | | |5.5.5.6.1.1) | | | |
+-----------+--------+------------+--------+---------+--------------+ +----------+--------+-------------+--------+---------+--------------+
|X448 |prefixed|prefixed 56 |N/A |N/A |N/A | |X448 |prefixed|prefixed 56 |N/A |N/A |N/A |
| |native |octets of | | | | | |native |octets of | | | |
| | |secret | | | | | | |secret | | | |
+-----------+--------+------------+--------+---------+--------------+ +----------+--------+-------------+--------+---------+--------------+
Table 19: Curve-specific wire formats Table 21: Curve-specific wire formats
For the native octet-string forms of EdDSA values, see [RFC8032]. For the native octet-string forms of EdDSA values, see [RFC8032].
For the native octet-string forms of ECDH secret scalars and points, For the native octet-string forms of ECDH secret scalars and points,
see [RFC7748]. see [RFC7748].
9.3. Symmetric-Key Algorithms 9.3. Symmetric-Key Algorithms
+==========+====================================================+ +==========+====================================================+
| ID | Algorithm | | ID | Algorithm |
+==========+====================================================+ +==========+====================================================+
skipping to change at page 92, line 46 skipping to change at page 98, line 46
+----------+----------------------------------------------------+ +----------+----------------------------------------------------+
| 13 | Camellia with 256-bit key | | 13 | Camellia with 256-bit key |
+----------+----------------------------------------------------+ +----------+----------------------------------------------------+
| 100 to | Private/Experimental algorithm | | 100 to | Private/Experimental algorithm |
| 110 | | | 110 | |
+----------+----------------------------------------------------+ +----------+----------------------------------------------------+
| 253, 254 | Reserved to avoid collision with Secret Key | | 253, 254 | Reserved to avoid collision with Secret Key |
| and 255 | Encryption (see Section 3.7.2.1 and Section 5.5.3) | | and 255 | Encryption (see Section 3.7.2.1 and Section 5.5.3) |
+----------+----------------------------------------------------+ +----------+----------------------------------------------------+
Table 20: Symmetric-key algorithm registry Table 22: Symmetric-key algorithm registry
Implementations MUST implement AES-128. Implementations SHOULD Implementations MUST implement AES-128. Implementations SHOULD
implement AES-256. Implementations MUST NOT encrypt data with IDEA, implement AES-256. Implementations MUST NOT encrypt data with IDEA,
TripleDES, or CAST5. Implementations MAY decrypt data that uses TripleDES, or CAST5. Implementations MAY decrypt data that uses
IDEA, TripleDES, or CAST5 for the sake of reading older messages or IDEA, TripleDES, or CAST5 for the sake of reading older messages or
new messages from legacy clients. Implementations MAY implement any new messages from legacy clients. An Implementation that decrypts
other algorithm. data using IDEA, TripleDES, or CAST5 SHOULD generate a deprecation
warning about the symmetric algorithm, indicating that message
confidentiality is suspect. Implementations MAY implement any other
algorithm.
9.4. Compression Algorithms 9.4. Compression Algorithms
+============+================================+ +============+================================+
| ID | Algorithm | | ID | Algorithm |
+============+================================+ +============+================================+
| 0 | Uncompressed | | 0 | Uncompressed |
+------------+--------------------------------+ +------------+--------------------------------+
| 1 | ZIP [RFC1951] | | 1 | ZIP [RFC1951] |
+------------+--------------------------------+ +------------+--------------------------------+
| 2 | ZLIB [RFC1950] | | 2 | ZLIB [RFC1950] |
+------------+--------------------------------+ +------------+--------------------------------+
| 3 | BZip2 [BZ2] | | 3 | BZip2 [BZ2] |
+------------+--------------------------------+ +------------+--------------------------------+
| 100 to 110 | Private/Experimental algorithm | | 100 to 110 | Private/Experimental algorithm |
+------------+--------------------------------+ +------------+--------------------------------+
Table 21: Compression algorithm registry Table 23: Compression algorithm registry
Implementations MUST implement uncompressed data. Implementations Implementations MUST implement uncompressed data. Implementations
SHOULD implement ZLIB. For interoperability reasons implementations SHOULD implement ZLIB. For interoperability reasons implementations
SHOULD be able to decompress using ZIP. Implementations MAY SHOULD be able to decompress using ZIP. Implementations MAY
implement any other algorithm. implement any other algorithm.
9.5. Hash Algorithms 9.5. Hash Algorithms
+============+================================+=============+ +============+================================+=============+
| ID | Algorithm | Text Name | | ID | Algorithm | Text Name |
+============+================================+=============+ +============+================================+=============+
| 1 | MD5 [HAC] | "MD5" | | 1 | MD5 [HAC] | "MD5" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 2 | SHA-1 [FIPS180] | "SHA1" | | 2 | SHA-1 [FIPS180], Section 14.1 | "SHA1" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 3 | RIPE-MD/160 [HAC] | "RIPEMD160" | | 3 | RIPEMD-160 [HAC] | "RIPEMD160" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 4 | Reserved | | | 4 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 5 | Reserved | | | 5 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 6 | Reserved | | | 6 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 7 | Reserved | | | 7 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 8 | SHA2-256 [FIPS180] | "SHA256" | | 8 | SHA2-256 [FIPS180] | "SHA256" |
skipping to change at page 94, line 22 skipping to change at page 100, line 20
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 12 | SHA3-256 [FIPS202] | "SHA3-256" | | 12 | SHA3-256 [FIPS202] | "SHA3-256" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 13 | Reserved | | | 13 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 14 | SHA3-512 [FIPS202] | "SHA3-512" | | 14 | SHA3-512 [FIPS202] | "SHA3-512" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 100 to 110 | Private/Experimental algorithm | | | 100 to 110 | Private/Experimental algorithm | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
Table 22: Hash algorithm registry Table 24: Hash algorithm registry
Implementations MUST implement SHA2-256. Implementations SHOULD Implementations MUST implement SHA2-256. Implementations SHOULD
implement SHA2-384 and SHA2-512. Implementations MAY implement other implement SHA2-384 and SHA2-512. Implementations MAY implement other
algorithms. Implementations SHOULD NOT create messages which require algorithms. Implementations SHOULD NOT create messages which require
the use of SHA-1 with the exception of computing version 4 key the use of SHA-1 with the exception of computing version 4 key
fingerprints and for purposes of the Modification Detection Code fingerprints and for purposes of the Modification Detection Code
(MDC) in version 1 Symmetrically Encrypted Integrity Protected Data (MDC) in version 1 Symmetrically Encrypted Integrity Protected Data
packets. Implementations MUST NOT generate signatures with MD5, SHA- packets. Implementations MUST NOT generate signatures with MD5, SHA-
1, or RIPE-MD/160. Implementations MUST NOT use MD5, SHA-1, or RIPE- 1, or RIPEMD-160. Implementations MUST NOT use MD5, SHA-1, or
MD/160 as a hash function in an ECDH KDF. Implementations MUST NOT RIPEMD-160 as a hash function in an ECDH KDF. Implementations MUST
validate any recent signature that depends on MD5, SHA-1, or RIPE- NOT validate any recent signature that depends on MD5, SHA-1, or
MD/160. Implementations SHOULD NOT validate any old signature that RIPEMD-160. Implementations SHOULD NOT validate any old signature
depends on MD5, SHA-1, or RIPE-MD/160 unless the signature's creation that depends on MD5, SHA-1, or RIPEMD-160 unless the signature's
date predates known weakness of the algorithm used, and the creation date predates known weakness of the algorithm used, and the
implementation is confident that the message has been in the secure implementation is confident that the message has been in the secure
custody of the user the whole time. custody of the user the whole time.
9.6. AEAD Algorithms 9.6. AEAD Algorithms
+========+======================+===========+====================+ +========+======================+===========+====================+
| ID | Algorithm | IV length | authentication tag | | ID | Algorithm | IV length | authentication tag |
| | | (octets) | length (octets) | | | | (octets) | length (octets) |
+========+======================+===========+====================+ +========+======================+===========+====================+
| 1 | EAX [EAX] | 16 | 16 | | 1 | EAX [EAX] | 16 | 16 |
+--------+----------------------+-----------+--------------------+ +--------+----------------------+-----------+--------------------+
| 2 | OCB [RFC7253] | 15 | 16 | | 2 | OCB [RFC7253] | 15 | 16 |
+--------+----------------------+-----------+--------------------+ +--------+----------------------+-----------+--------------------+
| 3 | GCM [SP800-38D] | 12 | 16 | | 3 | GCM [SP800-38D] | 12 | 16 |
+--------+----------------------+-----------+--------------------+ +--------+----------------------+-----------+--------------------+
| 100 to | Private/Experimental | | | | 100 to | Private/Experimental | | |
| 110 | algorithm | | | | 110 | algorithm | | |
+--------+----------------------+-----------+--------------------+ +--------+----------------------+-----------+--------------------+
Table 23: AEAD algorithm registry Table 25: AEAD algorithm registry
Implementations MUST implement OCB. Implementations MAY implement Implementations MUST implement OCB. Implementations MAY implement
EAX, GCM and other algorithms. EAX, GCM and other algorithms.
10. IANA Considerations 10. IANA Considerations
Because this document obsoletes [RFC4880], IANA is requested to Because this document obsoletes [RFC4880], IANA is requested to
update all registration information that references [RFC4880] to update all registration information that references [RFC4880] to
instead reference this RFC. instead reference this RFC.
skipping to change at page 96, line 12 skipping to change at page 101, line 51
be found in Section 4.3. Adding a new packet type MUST be done be found in Section 4.3. Adding a new packet type MUST be done
through the RFC REQUIRED method, as described in [RFC8126]. through the RFC REQUIRED method, as described in [RFC8126].
10.2.1. User Attribute Types 10.2.1. User Attribute Types
The User Attribute packet permits an extensible mechanism for other The User Attribute packet permits an extensible mechanism for other
types of certificate identification. This specification creates a types of certificate identification. This specification creates a
registry of User Attribute types. The registry includes the User registry of User Attribute types. The registry includes the User
Attribute type, the name of the User Attribute, and a reference to Attribute type, the name of the User Attribute, and a reference to
the defining specification. The initial values for this registry can the defining specification. The initial values for this registry can
be found in Section 5.13. Adding a new User Attribute type MUST be be found in Section 5.12. Adding a new User Attribute type MUST be
done through the SPECIFICATION REQUIRED method, as described in done through the SPECIFICATION REQUIRED method, as described in
[RFC8126]. [RFC8126].
10.2.1.1. Image Format Subpacket Types 10.2.1.1. Image Format Subpacket Types
Within User Attribute packets, there is an extensible mechanism for Within User Attribute packets, there is an extensible mechanism for
other types of image-based User Attributes. This specification other types of image-based User Attributes. This specification
creates a registry of Image Attribute subpacket types. The registry creates a registry of Image Attribute subpacket types. The registry
includes the Image Attribute subpacket type, the name of the Image includes the Image Attribute subpacket type, the name of the Image
Attribute subpacket, and a reference to the defining specification. Attribute subpacket, and a reference to the defining specification.
The initial values for this registry can be found in Section 5.13.1. The initial values for this registry can be found in Section 5.12.1.
Adding a new Image Attribute subpacket type MUST be done through the Adding a new Image Attribute subpacket type MUST be done through the
SPECIFICATION REQUIRED method, as described in [RFC8126]. SPECIFICATION REQUIRED method, as described in [RFC8126].
10.2.2. New Signature Subpackets 10.2.2. New Signature Subpackets
OpenPGP signatures contain a mechanism for signed (or unsigned) data OpenPGP signatures contain a mechanism for signed (or unsigned) data
to be added to them for a variety of purposes in the Signature to be added to them for a variety of purposes in the Signature
subpackets as discussed in Section 5.2.3.5. This specification subpackets as discussed in Section 5.2.3.5. This specification
creates a registry of Signature subpacket types. The registry creates a registry of Signature subpacket types. The registry
includes the Signature subpacket type, the name of the subpacket, and includes the Signature subpacket type, the name of the subpacket, and
skipping to change at page 96, line 47 skipping to change at page 102, line 38
method, as described in [RFC8126]. method, as described in [RFC8126].
10.2.2.1. Signature Notation Data Subpackets 10.2.2.1. Signature Notation Data Subpackets
OpenPGP signatures further contain a mechanism for extensions in OpenPGP signatures further contain a mechanism for extensions in
signatures. These are the Notation Data subpackets, which contain a signatures. These are the Notation Data subpackets, which contain a
key/value pair. Notations contain a user space that is completely key/value pair. Notations contain a user space that is completely
unmanaged and an IETF space. unmanaged and an IETF space.
This specification creates a registry of Signature Notation Data This specification creates a registry of Signature Notation Data
types. The registry includes the Signature Notation Data type, the types. The registry includes the name of the Signature Notation
name of the Signature Notation Data, its allowed values, and a Data, the Signature Notation Data type, its allowed values, and a
reference to the defining specification. The initial values for this reference to the defining specification. The initial values for this
registry can be found in Section 5.2.3.21. Adding a new Signature registry can be found in Section 5.2.3.21. Adding a new Signature
Notation Data subpacket MUST be done through the SPECIFICATION Notation Data subpacket MUST be done through the SPECIFICATION
REQUIRED method, as described in [RFC8126]. REQUIRED method, as described in [RFC8126].
10.2.2.2. Signature Notation Data Subpacket Notation Flags 10.2.2.2. Signature Notation Data Subpacket Notation Flags
This specification creates a new registry of Signature Notation Data This specification creates a new registry of Signature Notation Data
Subpacket Notation Flags. The registry includes the columns "Flag", Subpacket Notation Flags. The registry includes the columns "Flag",
"Description", "Security Recommended", "Interoperability "Shorthand", "Description", "Security Recommended", "Interoperability
Recommended", and "Reference". The initial values for this registry Recommended", and "Reference". The initial values for this registry
can be found in Section 5.2.3.21. Adding a new item MUST be done can be found in Section 5.2.3.21. Adding a new item MUST be done
through the SPECIFICATION REQUIRED method, as described in [RFC8126]. through the SPECIFICATION REQUIRED method, as described in [RFC8126].
10.2.2.3. Key Server Preference Extensions 10.2.2.3. Key Server Preference Extensions
OpenPGP signatures contain a mechanism for preferences to be OpenPGP signatures contain a mechanism for preferences to be
specified about key servers. This specification creates a registry specified about key servers. This specification creates a registry
of key server preferences. The registry includes the key server of key server preferences. The registry includes the key server
preference, the name of the preference, and a reference to the preference, the name of the preference, and a reference to the
skipping to change at page 98, line 8 skipping to change at page 104, line 8
OpenPGP signatures contain a mechanism for flags to be specified OpenPGP signatures contain a mechanism for flags to be specified
stating which optional features an implementation supports. This stating which optional features an implementation supports. This
specification creates a registry of feature-implementation flags. specification creates a registry of feature-implementation flags.
The registry includes the feature-implementation flags value, the The registry includes the feature-implementation flags value, the
name of the flag, and a reference to the defining specification. The name of the flag, and a reference to the defining specification. The
initial values for this registry can be found in Section 5.2.3.29. initial values for this registry can be found in Section 5.2.3.29.
Adding a new feature-implementation flag MUST be done through the Adding a new feature-implementation flag MUST be done through the
SPECIFICATION REQUIRED method, as described in [RFC8126]. SPECIFICATION REQUIRED method, as described in [RFC8126].
Also see Section 14.11 for more information about when feature flags Also see Section 13.11 for more information about when feature flags
are needed. are needed.
10.2.3. New Packet Versions 10.2.3. New Packet Versions
The core OpenPGP packets all have version numbers, and can be revised The core OpenPGP packets all have version numbers, and can be revised
by introducing a new version of an existing packet. This by introducing a new version of an existing packet. This
specification creates a registry of packet types. The registry specification creates a registry of packet types. The registry
includes the packet type, the number of the version, and a reference includes the packet type, the number of the version, and a reference
to the defining specification. The initial values for this registry to the defining specification. The initial values for this registry
can be found in Section 5. Adding a new packet version MUST be done can be found in Section 5. Adding a new packet version MUST be done
skipping to change at page 99, line 8 skipping to change at page 105, line 8
initial values for this registry can be found in Section 9.1. Adding initial values for this registry can be found in Section 9.1. Adding
a new public-key algorithm MUST be done through the SPECIFICATION a new public-key algorithm MUST be done through the SPECIFICATION
REQUIRED method, as described in [RFC8126]. REQUIRED method, as described in [RFC8126].
This document requests IANA register the following new public-key This document requests IANA register the following new public-key
algorithm: algorithm:
+====+============================+========================+ +====+============================+========================+
| ID | Algorithm | Reference | | ID | Algorithm | Reference |
+====+============================+========================+ +====+============================+========================+
| 22 | EdDSA public key algorithm | This doc, Section 14.7 | | 22 | EdDSA public key algorithm | This doc, Section 13.7 |
+----+----------------------------+------------------------+ +----+----------------------------+------------------------+
Table 24: New public-Key algorithms registered Table 26: New public-Key algorithms registered
[ Note to RFC-Editor: Please remove the table above on publication. ] [ Note to RFC-Editor: Please remove the table above on publication. ]
10.3.1.1. Elliptic Curve Algorithms
Some public key algorithms use Elliptic Curves. In particular,
ECDH/EdDSA/ECDSA public key algorithms all allow specific curves to
be used, as indicated by OID. To register a new elliptic curve for
use with OpenPGP, its OID needs to be registered in Table 20, its
wire format needs to be documented in Table 21, and if used for ECDH,
its KDF and KEK parameters must be populated in Table 31.
10.3.2. Symmetric-Key Algorithms 10.3.2. Symmetric-Key Algorithms
OpenPGP specifies a number of symmetric-key algorithms. This OpenPGP specifies a number of symmetric-key algorithms. This
specification creates a registry of symmetric-key algorithm specification creates a registry of symmetric-key algorithm
identifiers. The registry includes the algorithm name, its key sizes identifiers. The registry includes the algorithm name, its key sizes
and block size, and a reference to the defining specification. The and block size, and a reference to the defining specification. The
initial values for this registry can be found in Section 9.3. Adding initial values for this registry can be found in Section 9.3. Adding
a new symmetric-key algorithm MUST be done through the SPECIFICATION a new symmetric-key algorithm MUST be done through the SPECIFICATION
REQUIRED method, as described in [RFC8126]. REQUIRED method, as described in [RFC8126].
skipping to change at page 99, line 49 skipping to change at page 106, line 15
+====+===========+===========+ +====+===========+===========+
| ID | Algorithm | Reference | | ID | Algorithm | Reference |
+====+===========+===========+ +====+===========+===========+
| 12 | SHA3-256 | This doc | | 12 | SHA3-256 | This doc |
+----+-----------+-----------+ +----+-----------+-----------+
| 13 | Reserved | | | 13 | Reserved | |
+----+-----------+-----------+ +----+-----------+-----------+
| 14 | SHA3-512 | This doc | | 14 | SHA3-512 | This doc |
+----+-----------+-----------+ +----+-----------+-----------+
Table 25: New hash Table 27: New hash
algorithms registered algorithms registered
[Notes to RFC-Editor: Please remove the table above on publication. [Notes to RFC-Editor: Please remove the table above on publication.
It is desirable not to reuse old or reserved algorithms because some It is desirable not to reuse old or reserved algorithms because some
existing tools might print a wrong description. The ID 13 has been existing tools might print a wrong description. The ID 13 has been
reserved so that the SHA3 algorithm IDs align nicely with their SHA2 reserved so that the SHA3 algorithm IDs align nicely with their SHA2
counterparts.] counterparts.]
10.3.4. Compression Algorithms 10.3.4. Compression Algorithms
skipping to change at page 100, line 38 skipping to change at page 107, line 9
headings and values can be found in Section 9.2. Adding a new headings and values can be found in Section 9.2. Adding a new
elliptic curve algorithm to OpenPGP MUST be done through the elliptic curve algorithm to OpenPGP MUST be done through the
SPECIFICATION REQUIRED method, as described in [RFC8126]. If the new SPECIFICATION REQUIRED method, as described in [RFC8126]. If the new
curve can be used for ECDH or EdDSA, it must also be added to the curve can be used for ECDH or EdDSA, it must also be added to the
"Curve-specific wire formats" table described in Section 9.2.1. "Curve-specific wire formats" table described in Section 9.2.1.
10.4. Elliptic Curve Point and Scalar Wire Formats 10.4. Elliptic Curve Point and Scalar Wire Formats
This document requests IANA add a registry of wire formats that This document requests IANA add a registry of wire formats that
represent elliptic curve points. The table's initial headings and represent elliptic curve points. The table's initial headings and
values can be found in Section 13.2. Adding a new EC point wire values can be found in Section 12.2. Adding a new EC point wire
format MUST be done through the SPECIFICATION REQUIRED method, as format MUST be done through the SPECIFICATION REQUIRED method, as
described in [RFC8126]. described in [RFC8126].
This document also requests IANA add a registry of wire formats that This document also requests IANA add a registry of wire formats that
represent scalars for use with elliptic curve cryptography. The represent scalars for use with elliptic curve cryptography. The
table's initial headings and values can be found in Section 13.3. table's initial headings and values can be found in Section 12.3.
Adding a new EC scalar wire format MUST be done through the Adding a new EC scalar wire format MUST be done through the
SPECIFICATION REQUIRED method, as described in [RFC8126]. SPECIFICATION REQUIRED method, as described in [RFC8126].
This document also requests that IANA add a registry mapping curve- This document also requests that IANA add a registry mapping curve-
specific MPI octet-string encoding conventions for ECDH and EdDSA. specific MPI octet-string encoding conventions for ECDH and EdDSA.
The table's initial headings and values can be found in The table's initial headings and values can be found in
Section 9.2.1. Adding a new elliptic curve algorithm to OpenPGP MUST Section 9.2.1. Adding a new elliptic curve algorithm to OpenPGP MUST
be done through the SPECIFICATION REQUIRED method, as described in be done through the SPECIFICATION REQUIRED method, as described in
[RFC8126], and requires adding an entry to this table if the curve is [RFC8126], and requires adding an entry to this table if the curve is
to be used with either EdDSA or ECDH. to be used with either EdDSA or ECDH.
skipping to change at page 101, line 35 skipping to change at page 107, line 49
And populate them with the values found in Section 9.1. And populate them with the values found in Section 9.1.
11. Packet Composition 11. Packet Composition
OpenPGP packets are assembled into sequences in order to create OpenPGP packets are assembled into sequences in order to create
messages and to transfer keys. Not all possible packet sequences are messages and to transfer keys. Not all possible packet sequences are
meaningful and correct. This section describes the rules for how meaningful and correct. This section describes the rules for how
packets should be placed into sequences. packets should be placed into sequences.
There are three distinct sequences of packets:
* Transferable Public Keys (Section 11.1) and its close counterpart,
Transferable Secret Keys (Section 11.2)
* OpenPGP Messages (Section 11.3)
* Detached Signatures (Section 11.4)
Each sequence has an explicit grammar of what packet types (Table 4)
can appear in what place. The presence of an unknown critical
packet, or a known but unexpected packet is a critical error,
invalidating the entire sequence (see Section 4.3.1). On the other
hand, unknown non-critical packets can appear anywhere within any
sequence. This provides a structured way to introduce new packets
into the protocol, while making sure that certain packets will be
handled strict.
An implementation may "recognize" a packet, but not implement it.
The purpose of Packet Criticality is to allow the producer to tell
the consumer whether it would prefer a new, unknown packet to
generate an error or be ignored.
Note that previous versions of this document did not have a concept
of Packet Criticality, and did not give clear guidance on what to do
when unknown packets are encountered. Therefore, a legacy
implementation may reject unknown non-critical packets, or accept
unknown critical packets.
When generating a sequence of OpenPGP packets according to one of the
three grammars, an implementation MUST NOT inject a critical packet
of a type that does not adhere to the grammar.
When consuming a sequence of OpenPGP packets according to one of the
three grammars, an implementation MUST reject the sequence with an
error if it encounters a critical packet of inappropriate type
according to the grammar.
11.1. Transferable Public Keys 11.1. Transferable Public Keys
OpenPGP users may transfer public keys. The essential elements of a OpenPGP users may transfer public keys. This section describes the
transferable public key are as follows: structure of public keys in transit to ensure interoperability.
* One Public-Key packet 11.1.1. OpenPGP v5 Key Structure
* Zero or more revocation signatures The format of an OpenPGP v5 key is as follows. Entries in square
brackets are optional and ellipses indicate repetition.
* Zero or more User ID packets Primary Key
[Revocation Signature...]
Direct-Key Signature...
[User ID or User Attribute
[Certification Revocation Signature...]
[Certification Signature...]]...
[Subkey [Subkey Revocation Signature...]
Subkey Binding Signature...]...
[Padding]
* After each User ID packet, zero or more Signature packets In addition to these rules, a marker packet (Section 5.8) can appear
(certifications) anywhere in the sequence.
* Zero or more User Attribute packets Note, that a v5 key uses a Direct-Key Signature to store algorithm
preferences.
* After each User Attribute packet, zero or more Signature packets Every subkey for a v5 primary key MUST be a v5 subkey.
(certifications)
* Zero or more Subkey packets When a primary v5 Public Key is revoked, it is sometimes distributed
with only the revocation signature:
* After each Subkey packet, one Signature packet, plus optionally a Primary Key
revocation Revocation Signature
* An optional Padding packet In this case, the direct-key signature is no longer necessary, since
the primary key itself has been marked as unusable.
The Public-Key packet occurs first. Each of the following User ID 11.1.2. OpenPGP v4 Key Structure
packets provides the identity of the owner of this public key. If
there are multiple User ID packets, this corresponds to multiple The format of an OpenPGP v4 key is as follows.
means of identifying the same unique individual user; for example, a
user may have more than one email address, and construct a User ID Primary Key
for each one. A transferable public key SHOULD include at least one [Revocation Signature]
User ID packet unless storage requirements prohibit this. [Direct-Key Signature...]
[User ID or User Attribute [Signature...]]...
[Subkey [Subkey Revocation Signature...]
Subkey Binding Signature...]...
In addition to these rules, a marker packet (Section 5.8) can appear
anywhere in the sequence.
A subkey always has at least one subkey binding signature after it
that is issued using the primary key to tie the two keys together.
These binding signatures may be in either v3 or v4 format, but SHOULD
be v4. Subkeys that can issue signatures MUST have a v4 binding
signature due to the REQUIRED embedded primary key binding signature.
Every subkey for a v4 primary key MUST be a v4 subkey.
When a primary v4 Public Key is revoked, the revocation signature is
sometimes distributed by itself, without the primary key packet it
applies to. This is referred to as a "revocation certificate".
Instead, a v5 revocation certificate MUST include the primary key
packet, as described above.
11.1.3. OpenPGP v3 Key Structure
The format of an OpenPGP v3 key is as follows.
RSA Public Key
[Revocation Signature]
User ID [Signature...]
[User ID [Signature...]]...
In addition to these rules, a marker packet (Section 5.8) can appear
anywhere in the sequence.
Each signature certifies the RSA public key and the preceding User
ID. The RSA public key can have many User IDs and each User ID can
have many signatures. V3 keys are deprecated. Implementations MUST
NOT generate new v3 keys, but MAY continue to use existing ones.
V3 keys MUST NOT have subkeys.
11.1.4. Common requirements
The Public-Key packet occurs first.
In order to create self-signatures (see Section 5.2.3.7), the primary
key MUST be an algorithm capable of making signatures (that is, not
an encryption-only algorithm). The subkeys may be keys of any type.
For example, there may be a single-key RSA key, an EdDSA primary key
with an RSA encryption key, or an EdDSA primary key with an ECDH
subkey, etc.
Each of the following User ID packets provides the identity of the
owner of this public key. If there are multiple User ID packets,
this corresponds to multiple means of identifying the same unique
individual user; for example, a user may have more than one email
address, and construct a User ID for each one. A transferable public
key SHOULD include at least one User ID packet unless storage
requirements prohibit this.
Immediately following each User ID packet, there are zero or more Immediately following each User ID packet, there are zero or more
Signature packets. Each Signature packet is calculated on the Signature packets. Each Signature packet is calculated on the
immediately preceding User ID packet and the initial Public-Key immediately preceding User ID packet and the initial Public-Key
packet. The signature serves to certify the corresponding public key packet. The signature serves to certify the corresponding public key
and User ID. In effect, the signer is testifying to his or her and User ID. In effect, the signer is testifying to his or her
belief that this public key belongs to the user identified by this belief that this public key belongs to the user identified by this
User ID. User ID.
Within the same section as the User ID packets, there are zero or Within the same section as the User ID packets, there are zero or
skipping to change at page 102, line 40 skipping to change at page 111, line 20
Attribute packet is followed by zero or more Signature packets Attribute packet is followed by zero or more Signature packets
calculated on the immediately preceding User Attribute packet and the calculated on the immediately preceding User Attribute packet and the
initial Public-Key packet. initial Public-Key packet.
User Attribute packets and User ID packets may be freely intermixed User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet. maintained on the proper User Attribute or User ID packet.
After the User ID packet or Attribute packet, there may be zero or After the User ID packet or Attribute packet, there may be zero or
more Subkey packets. In general, subkeys are provided in cases where more Subkey packets. In general, subkeys are provided in cases where
the top-level public key is a signature-only key. However, any V4 or the top-level public key is a certification-only key. However, any
V5 key may have subkeys, and the subkeys may be encryption-only keys, v4 or v5 key may have subkeys, and the subkeys may be encryption
signature-only keys, or general-purpose keys. V3 keys MUST NOT have keys, signing keys, authentication keys, etc. It is good practice to
subkeys. use separate subkeys for every operation (i.e. signature-only,
encryption-only, authentication-only keys, etc.).
Each Subkey packet MUST be followed by one Signature packet, which Each Subkey packet MUST be followed by one Signature packet, which
should be a subkey binding signature issued by the top-level key. should be a subkey binding signature issued by the top-level key.
For subkeys that can issue signatures, the subkey binding signature For subkeys that can issue signatures, the subkey binding signature
MUST contain an Embedded Signature subpacket with a primary key MUST contain an Embedded Signature subpacket with a primary key
binding signature (0x19) issued by the subkey on the top-level key. binding signature (0x19) issued by the subkey on the top-level key.
Subkey and Key packets may each be followed by a revocation Signature Subkey and Key packets may each be followed by a revocation Signature
packet to indicate that the key is revoked. Revocation signatures packet to indicate that the key is revoked. Revocation signatures
are only accepted if they are issued by the key itself, or by a key are only accepted if they are issued by the key itself, or by a key
that is authorized to issue revocations via a Revocation Key that is authorized to issue revocations via a Revocation Key
subpacket in a self-signature by the top-level key. subpacket in a self-signature by the top-level key.
The optional trailing Padding packet is a mechanism to defend against The optional trailing Padding packet is a mechanism to defend against
traffic analysis (see Section 15.4). For maximum interoperability, traffic analysis (see Section 14.10). For maximum interoperability,
if the Public-Key packet is a V4 key, the optional Padding packet if the Public-Key packet is a v4 key, the optional Padding packet
SHOULD NOT be present unless the recipient has indicated that they SHOULD NOT be present unless the recipient has indicated that they
are capable of ignoring it successfully. An implementation that is are capable of ignoring it successfully. An implementation that is
capable of receiving a transferable public key with a V5 Public-Key capable of receiving a transferable public key with a v5 Public-Key
primary key MUST be able to accept (and ignore) the trailing optional primary key MUST be able to accept (and ignore) the trailing optional
Padding packet. Padding packet.
Transferable public-key packet sequences may be concatenated to allow Transferable public-key packet sequences may be concatenated to allow
transferring multiple public keys in one operation. transferring multiple public keys in one operation (see Section 3.6).
11.2. Transferable Secret Keys 11.2. Transferable Secret Keys
OpenPGP users may transfer secret keys. The format of a transferable OpenPGP users may transfer secret keys. The format of a transferable
secret key is the same as a transferable public key except that secret key is the same as a transferable public key except that
secret-key and secret-subkey packets are used instead of the public secret-key and secret-subkey packets can be used in addition to the
key and public-subkey packets. Implementations SHOULD include self- public key and public-subkey packets. If a single secret-key or
signatures on any User IDs and subkeys, as this allows for a complete secret-subkey packet is included in a packet sequence, it is a
public key to be automatically extracted from the transferable secret transferable secret key and should be handled and marked as such (see
key. Implementations MAY choose to omit the self-signatures, Section 6.2). Implementations SHOULD include self-signatures on any
especially if a transferable public key accompanies the transferable User IDs and subkeys, as this allows for a complete public key to be
secret key. automatically extracted from the transferable secret key.
Implementations MAY choose to omit the self-signatures, especially if
a transferable public key accompanies the transferable secret key.
11.3. OpenPGP Messages 11.3. OpenPGP Messages
An OpenPGP message is a packet or sequence of packets that An OpenPGP message is a packet or sequence of packets that
corresponds to the following grammatical rules (comma represents corresponds to the following grammatical rules (comma represents
sequential composition, and vertical bar separates alternatives): sequential composition, and vertical bar separates alternatives):
OpenPGP Message :- Encrypted Message | Signed Message | Compressed OpenPGP Message :- Encrypted Message | Signed Message | Compressed
Message | Literal Message. Message | Literal Message.
skipping to change at page 104, line 19 skipping to change at page 112, line 51
One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP
Message, Corresponding Signature Packet. Message, Corresponding Signature Packet.
Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message :- Signature Packet, OpenPGP Message | One-Pass
Signed Message. Signed Message.
Optionally Padded Message :- OpenPGP Message | OpenPGP Message, Optionally Padded Message :- OpenPGP Message | OpenPGP Message,
Padding Packet. Padding Packet.
In addition to these rules, a marker packet (Section 5.8) can appear
anywhere in the sequence.
11.3.1. Unwrapping Encrypted and Compressed Messages 11.3.1. Unwrapping Encrypted and Compressed Messages
In addition to the above grammar, certain messages can be "unwrapped" In addition to the above grammar, certain messages can be "unwrapped"
to yield new messages. In particular: to yield new messages. In particular:
* Decrypting a version 2 Symmetrically Encrypted and Integrity * Decrypting a version 2 Symmetrically Encrypted and Integrity
Protected Data packet must yield a valid Optionally Padded Protected Data packet must yield a valid Optionally Padded
Message. Message.
* Decrypting a version 1 Symmetrically Encrypted and Integrity * Decrypting a version 1 Symmetrically Encrypted and Integrity
Protected Data packet or --- for historic data --- a Symmetrically Protected Data packet or --- for historic data --- a Symmetrically
Encrypted Data packet must yield a valid OpenPGP Message. Encrypted Data packet must yield a valid OpenPGP Message.
* Decompressing a Compressed Data packet must also yield a valid * Decompressing a Compressed Data packet must also yield a valid
OpenPGP Message. OpenPGP Message.
When either such unwrapping is performed, the resulting stream of When any unwrapping is performed, the resulting stream of octets is
octets is parsed into a series OpenPGP packets like any other stream parsed into a series OpenPGP packets like any other stream of octets.
of octets. The packet boundaries found in the series of octets are The packet boundaries found in the series of octets are expected to
expected to align with the length of the unwrapped octet stream. An align with the length of the unwrapped octet stream. An
implementation MUST NOT interpret octets beyond the boundaries of the implementation MUST NOT interpret octets beyond the boundaries of the
unwrapped octet stream as part of any OpenPGP packet. If an unwrapped octet stream as part of any OpenPGP packet. If an
implementation encounters a packet whose header length indicates that implementation encounters a packet whose header length indicates that
it would extend beyond the boundaries of the unwrapped octet stream, it would extend beyond the boundaries of the unwrapped octet stream,
the implementation MUST reject that packet as malformed and unusable. the implementation MUST reject that packet as malformed and unusable.
11.3.2. Additional Constraints on Packet Sequences 11.3.2. Additional Constraints on Packet Sequences
Note that some subtle combinations that are formally acceptable by Note that some subtle combinations that are formally acceptable by
this grammar are nonetheless unacceptable. this grammar are nonetheless unacceptable.
11.3.2.1. Packet Versions in Encrypted Messages 11.3.2.1. Packet Versions in Encrypted Messages
As noted above, an Encrypted Message is a sequence of zero or more As noted above, an Encrypted Message is a sequence of zero or more
PKESKs (Section 5.1) and SKESKs (Section 5.3), followed by an SEIPD PKESKs (Section 5.1) and SKESKs (Section 5.3), followed by an SEIPD
(Section 5.14) payload. In some historic data, the payload may be a (Section 5.13) payload. In some historic data, the payload may be a
deprecated SED (Section 5.8) packet instead of SEIPD, though deprecated SED (Section 5.7) packet instead of SEIPD, though
implementations MUST NOT generate SED packets (see Section 15.1). implementations MUST NOT generate SED packets (see Section 14.7).
The versions of the preceding ESK packets within an Encrypted Message The versions of the preceding ESK packets within an Encrypted Message
MUST align with the version of the payload SEIPD packet, as described MUST align with the version of the payload SEIPD packet, as described
in this section. in this section.
v3 PKESK and v4 SKESK packets both contain in their cleartext the v3 PKESK and v4 SKESK packets both contain in their cleartext the
symmetric cipher algorithm identifier in addition to the session key symmetric cipher algorithm identifier in addition to the session key
for the subsequent SEIPD packet. Since a v1 SEIPD does not contain a for the subsequent SEIPD packet. Since a v1 SEIPD does not contain a
symmetric algorithm identifier, so all ESK packets preceding a v1 symmetric algorithm identifier, so all ESK packets preceding a v1
SEIPD payload MUST be either v3 PKESK or v4 SKESK. SEIPD payload MUST be either v3 PKESK or v4 SKESK.
skipping to change at page 105, line 44 skipping to change at page 114, line 27
+======================+======================+===================+ +======================+======================+===================+
| Version of Encrypted | Version of preceding | Version of | | Version of Encrypted | Version of preceding | Version of |
| Data payload | Symmetric-Key ESK | preceding Public- | | Data payload | Symmetric-Key ESK | preceding Public- |
| | (if any) | Key ESK (if any) | | | (if any) | Key ESK (if any) |
+======================+======================+===================+ +======================+======================+===================+
| v1 SEIPD | v4 SKESK | v3 PKESK | | v1 SEIPD | v4 SKESK | v3 PKESK |
+----------------------+----------------------+-------------------+ +----------------------+----------------------+-------------------+
| v2 SEIPD | v5 SKESK | v5 PKESK | | v2 SEIPD | v5 SKESK | v5 PKESK |
+----------------------+----------------------+-------------------+ +----------------------+----------------------+-------------------+
Table 26: Encrypted Message Packet Version Alignment Table 28: Encrypted Message Packet Version Alignment
An implementation processing an Encrypted Message MUST discard any An implementation processing an Encrypted Message MUST discard any
preceding ESK packet with a version that does not align with the preceding ESK packet with a version that does not align with the
version of the payload. version of the payload.
11.4. Detached Signatures 11.4. Detached Signatures
Some OpenPGP applications use so-called "detached signatures". For Some OpenPGP applications use so-called "detached signatures". For
example, a program bundle may contain a file, and with it a second example, a program bundle may contain a file, and with it a second
file that is a detached signature of the first file. These detached file that is a detached signature of the first file. These detached
signatures are simply a Signature packet stored separately from the signatures are simply one or more Signature packets stored separately
data for which they are a signature. from the data for which they are a signature.
12. Enhanced Key Formats
12.1. Key Structures
The format of an OpenPGP V3 key is as follows. Entries in square
brackets are optional and ellipses indicate repetition.
RSA Public Key
[Revocation Self Signature]
User ID [Signature ...]
[User ID [Signature ...] ...]
Each signature certifies the RSA public key and the preceding User
ID. The RSA public key can have many User IDs and each User ID can
have many signatures. V3 keys are deprecated. Implementations MUST
NOT generate new V3 keys, but MAY continue to use existing ones.
The format of an OpenPGP V4 key that uses multiple public keys is
similar except that the other keys are added to the end as "subkeys"
of the primary key.
Primary-Key
[Revocation Self Signature]
[Direct Key Signature...]
[User ID [Signature ...] ...]
[User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation ...]
Subkey-Binding-Signature ...] ...]
A subkey always has at least one subkey binding signature after it
that is issued using the primary key to tie the two keys together.
These binding signatures may be in either V3 or V4 format, but SHOULD
be V4. Subkeys that can issue signatures MUST have a V4 binding
signature due to the REQUIRED embedded primary key binding signature.
In order to create self-signatures (see Section 5.2.3.7), the primary
key MUST be an algorithm capable of making signatures (that is, not
an encryption-only algorithm). The subkeys may be keys of any type.
For example, there may be a single-key RSA key, an EdDSA primary key
with an RSA encryption key, or an EdDSA primary key with an ECDH
subkey, etc.
It is also possible to have a signature-only subkey. This permits a
primary key that collects certifications (key signatures), but is
used only for certifying subkeys that are used for encryption and
signatures.
12.2. Key IDs and Fingerprints
For a V3 key, the eight-octet Key ID consists of the low 64 bits of
the public modulus of the RSA key.
The fingerprint of a V3 key is formed by hashing the body (but not
the two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5. Note that both V3 keys
and MD5 are deprecated.
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
followed by the two-octet packet length, followed by the entire
Public-Key packet starting with the version field. The Key ID is the
low-order 64 bits of the fingerprint. Here are the fields of the
hash material, with the example of an EdDSA key:
a.1) 0x99 (1 octet)
a.2) two-octet, big-endian scalar octet count of (b)-(e)
b) version number = 4 (1 octet);
c) timestamp of key creation (4 octets);
d) algorithm (1 octet): 22 = EdDSA (example);
e) Algorithm-specific fields.
Algorithm-Specific Fields for EdDSA keys (example):
e.1) A one-octet size of the following field;
e.2) The octets representing a curve OID, defined in Section 9.2;
e.3) An MPI of an EC point representing a public key Q in prefixed
native form (see Section 13.2.2).
A V5 fingerprint is the 256-bit SHA2-256 hash of the octet 0x9A,
followed by the four-octet packet length, followed by the entire
Public-Key packet starting with the version field. The Key ID is the
high-order 64 bits of the fingerprint. Here are the fields of the
hash material, with the example of an EdDSA key:
a.1) 0x9A (1 octet)
a.2) four-octet scalar octet count of (b)-(f)
b) version number = 5 (1 octet);
c) timestamp of key creation (4 octets);
d) algorithm (1 octet): 22 = EdDSA (example);
e) four-octet scalar octet count for the following key material;
f) algorithm-specific fields.
Algorithm-Specific Fields for EdDSA keys (example):
f.1) A one-octet size of the following field;
f.2) The octets representing a curve OID, defined in Section 9.2;
f.3) An MPI of an EC point representing a public key Q in prefixed
native form (see Section 13.2.2).
Note that it is possible for there to be collisions of Key IDs ---
two different keys with the same Key ID. Note that there is a much
smaller, but still non-zero, probability that two different keys have
the same fingerprint.
Also note that if V3, V4, and V5 format keys share the same RSA key
material, they will have different Key IDs as well as different
fingerprints.
Finally, the Key ID and fingerprint of a subkey are calculated in the In addition, a marker packet (Section 5.8 and a padding packet
same way as for a primary key, including the 0x99 (V4 key) or 0x9A (Section 5.14) can appear anywhere in the sequence.
(V5 key) as the first octet (even though this is not a valid packet
ID for a public subkey).
13. Elliptic Curve Cryptography 12. Elliptic Curve Cryptography
This section describes algorithms and parameters used with Elliptic This section describes algorithms and parameters used with Elliptic
Curve Cryptography (ECC) keys. A thorough introduction to ECC can be Curve Cryptography (ECC) keys. A thorough introduction to ECC can be
found in [KOBLITZ]. found in [KOBLITZ].
None of the ECC methods described in this document are allowed with None of the ECC methods described in this document are allowed with
deprecated V3 keys. Refer to [FIPS186], B.4.1, for the method to deprecated v3 keys. Refer to [FIPS186], B.4.1, for the method to
generate a uniformly distributed ECC private key. generate a uniformly distributed ECC private key.
13.1. Supported ECC Curves 12.1. Supported ECC Curves
This document references three named prime field curves defined in This document references three named prime field curves defined in
[FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521". These [FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521". These
three [FIPS186] curves can be used with ECDSA and ECDH public key three [FIPS186] curves can be used with ECDSA and ECDH public key
algorithms. Additionally, curve "Curve25519" and "Curve448" are algorithms. Additionally, curve "Curve25519" and "Curve448" are
referenced for use with Ed25519 and Ed448 (EdDSA signing, see referenced for use with Ed25519 and Ed448 (EdDSA signing, see
[RFC8032]); and X25519 and X448 (ECDH encryption, see [RFC7748]). [RFC8032]); and X25519 and X448 (ECDH encryption, see [RFC7748]).
The named curves are referenced as a sequence of octets in this The named curves are referenced as a sequence of octets in this
document, called throughout, curve OID. Section 9.2 describes in document, called throughout, curve OID. Section 9.2 describes in
detail how this sequence of octets is formed. detail how this sequence of octets is formed.
13.2. EC Point Wire Formats 12.2. EC Point Wire Formats
A point on an elliptic curve will always be represented on the wire A point on an elliptic curve will always be represented on the wire
as an MPI. Each curve uses a specific point format for the data as an MPI. Each curve uses a specific point format for the data
within the MPI itself. Each format uses a designated prefix octet to within the MPI itself. Each format uses a designated prefix octet to
ensure that the high octet has at least one bit set to make the MPI a ensure that the high octet has at least one bit set to make the MPI a
constant size. constant size.
+=================+================+================+ +=================+================+================+
| Name | Wire Format | Reference | | Name | Wire Format | Reference |
+=================+================+================+ +=================+================+================+
| SEC1 | 0x04 || x || y | Section 13.2.1 | | SEC1 | 0x04 || x || y | Section 12.2.1 |
+-----------------+----------------+----------------+ +-----------------+----------------+----------------+
| Prefixed native | 0x40 || native | Section 13.2.2 | | Prefixed native | 0x40 || native | Section 12.2.2 |
+-----------------+----------------+----------------+ +-----------------+----------------+----------------+
Table 27: Elliptic Curve Point Wire Formats Table 29: Elliptic Curve Point Wire Formats
13.2.1. SEC1 EC Point Wire Format 12.2.1. SEC1 EC Point Wire Format
For a SEC1-encoded (uncompressed) point the content of the MPI is: For a SEC1-encoded (uncompressed) point the content of the MPI is:
B = 04 || x || y B = 04 || x || y
where x and y are coordinates of the point P = (x, y), and each is where x and y are coordinates of the point P = (x, y), and each is
encoded in the big-endian format and zero-padded to the adjusted encoded in the big-endian format and zero-padded to the adjusted
underlying field size. The adjusted underlying field size is the underlying field size. The adjusted underlying field size is the
underlying field size rounded up to the nearest 8-bit boundary, as underlying field size rounded up to the nearest 8-bit boundary, as
noted in the "fsize" column in Section 9.2. This encoding is noted in the "fsize" column in Section 9.2. This encoding is
compatible with the definition given in [SEC1]. compatible with the definition given in [SEC1].
13.2.2. Prefixed Native EC Point Wire Format 12.2.2. Prefixed Native EC Point Wire Format
For a custom compressed point the content of the MPI is: For a custom compressed point the content of the MPI is:
B = 40 || p B = 40 || p
where p is the public key of the point encoded using the rules where p is the public key of the point encoded using the rules
defined for the specified curve. This format is used for ECDH keys defined for the specified curve. This format is used for ECDH keys
based on curves expressed in Montgomery form, and for points when based on curves expressed in Montgomery form, and for points when
using EdDSA. using EdDSA.
13.2.3. Notes on EC Point Wire Formats 12.2.3. Notes on EC Point Wire Formats
Given the above definitions, the exact size of the MPI payload for an Given the above definitions, the exact size of the MPI payload for an
encoded point is 515 bits for "Curve P-256", 771 for "Curve P-384", encoded point is 515 bits for "Curve P-256", 771 for "Curve P-384",
1059 for "Curve P-521", 263 for both "Curve25519" and "Ed25519", 463 1059 for "Curve P-521", 263 for both "Curve25519" and "Ed25519", 463
for "Ed448", and 455 for "X448". For example, the length of a EdDSA for "Ed448", and 455 for "X448". For example, the length of a EdDSA
public key for the curve Ed25519 is 263 bits: 7 bits to represent the public key for the curve Ed25519 is 263 bits: 7 bits to represent the
0x40 prefix octet and 32 octets for the native value of the public 0x40 prefix octet and 32 octets for the native value of the public
key. key.
Even though the zero point, also called the point at infinity, may Even though the zero point, also called the point at infinity, may
occur as a result of arithmetic operations on points of an elliptic occur as a result of arithmetic operations on points of an elliptic
curve, it SHALL NOT appear in data structures defined in this curve, it SHALL NOT appear in data structures defined in this
document. document.
Each particular curve uses a designated wire format for the point Each particular curve uses a designated wire format for the point
found in its public key or ECDH data structure. An implementation found in its public key or ECDH data structure. An implementation
MUST NOT use a different wire format for a point than the wire format MUST NOT use a different wire format for a point than the wire format
associated with the curve. associated with the curve.
13.3. EC Scalar Wire Formats 12.3. EC Scalar Wire Formats
Some non-curve values in elliptic curve cryptography (for example, Some non-curve values in elliptic curve cryptography (for example,
secret keys and signature components) are not points on a curve, but secret keys and signature components) are not points on a curve, but
are also encoded on the wire in OpenPGP as an MPI. are also encoded on the wire in OpenPGP as an MPI.
Because of different patterns of deployment, some curves treat these Because of different patterns of deployment, some curves treat these
values as opaque bit strings with the high bit set, while others are values as opaque bit strings with the high bit set, while others are
treated as actual integers, encoded in the standard OpenPGP big- treated as actual integers, encoded in the standard OpenPGP big-
endian form. The choice of encoding is specific to the public key endian form. The choice of encoding is specific to the public key
algorithm in use. algorithm in use.
+==========+=====================================+===========+ +==========+=====================================+===========+
| Type | Description | Reference | | Type | Description | Reference |
+==========+=====================================+===========+ +==========+=====================================+===========+
| integer | An integer, big-endian encoded as a | Section | | integer | An integer, big-endian encoded as a | Section |
| | standard OpenPGP MPI | 3.2 | | | standard OpenPGP MPI | 3.2 |
+----------+-------------------------------------+-----------+ +----------+-------------------------------------+-----------+
| octet | An octet string of fixed length, | Section | | octet | An octet string of fixed length, | Section |
| string | that may be shorter on the wire due | 13.3.1 | | string | that may be shorter on the wire due | 12.3.1 |
| | to leading zeros being stripped by | | | | to leading zeros being stripped by | |
| | the MPI encoding, and may need to | | | | the MPI encoding, and may need to | |
| | be zero-padded before usage | | | | be zero-padded before usage | |
+----------+-------------------------------------+-----------+ +----------+-------------------------------------+-----------+
| prefixed | An octet string of fixed length N, | Section | | prefixed | An octet string of fixed length N, | Section |
| N octets | prefixed with octet 0x40 to ensure | 13.3.2 | | N octets | prefixed with octet 0x40 to ensure | 12.3.2 |
| | no leading zero octet | | | | no leading zero octet | |
+----------+-------------------------------------+-----------+ +----------+-------------------------------------+-----------+
Table 28: Elliptic Curve Scalar Encodings Table 30: Elliptic Curve Scalar Encodings
13.3.1. EC Octet String Wire Format 12.3.1. EC Octet String Wire Format
Some opaque strings of octets are represented on the wire as an MPI Some opaque strings of octets are represented on the wire as an MPI
by simply stripping the leading zeros and counting the remaining by simply stripping the leading zeros and counting the remaining
bits. These strings are of known, fixed length. They are bits. These strings are of known, fixed length. They are
represented in this document as MPI(N octets of X) where N is the represented in this document as MPI(N octets of X) where N is the
expected length in octets of the octet string. expected length in octets of the octet string.
For example, a five-octet opaque string (MPI(5 octets of X)) where X For example, a five-octet opaque string (MPI(5 octets of X)) where X
has the value 00 02 ee 19 00 would be represented on the wire as an has the value 00 02 ee 19 00 would be represented on the wire as an
MPI like so: 00 1a 02 ee 19 00. MPI like so: 00 1a 02 ee 19 00.
skipping to change at page 112, line 5 skipping to change at page 118, line 5
an expected length of 5 octets can take the following steps: an expected length of 5 octets can take the following steps:
* ensure that the MPI's two-octet bitcount is less than or equal to * ensure that the MPI's two-octet bitcount is less than or equal to
40 (5 octets of 8 bits) 40 (5 octets of 8 bits)
* allocate 5 octets, setting all to zero initially * allocate 5 octets, setting all to zero initially
* copy the MPI data octets (without the two count octets) into the * copy the MPI data octets (without the two count octets) into the
lower octets of the allocated space lower octets of the allocated space
13.3.2. Elliptic Curve Prefixed Octet String Wire Format 12.3.2. Elliptic Curve Prefixed Octet String Wire Format
Another way to ensure that a fixed-length bytestring is encoded Another way to ensure that a fixed-length bytestring is encoded
simply to the wire while remaining in MPI format is to prefix the simply to the wire while remaining in MPI format is to prefix the
bytestring with a dedicated non-zero octet. This specification uses bytestring with a dedicated non-zero octet. This specification uses
0x40 as the prefix octet. This is represented in this standard as 0x40 as the prefix octet. This is represented in this standard as
MPI(prefixed N octets of X), where N is the known bytestring length. MPI(prefixed N octets of X), where N is the known bytestring length.
For example, a five-octet opaque string using MPI(prefixed 5 octets For example, a five-octet opaque string using MPI(prefixed 5 octets
of X) where X has the value 00 02 ee 19 00 would be written to the of X) where X has the value 00 02 ee 19 00 would be written to the
wire form as: 00 2f 40 00 02 ee 19 00. wire form as: 00 2f 40 00 02 ee 19 00.
skipping to change at page 112, line 30 skipping to change at page 118, line 30
To decode the string from the wire, an implementation that knows that To decode the string from the wire, an implementation that knows that
the variable is formed in this way can: the variable is formed in this way can:
* ensure that the first three octets of the MPI (the two bit-count * ensure that the first three octets of the MPI (the two bit-count
octets plus the prefix octet) are 00 2f 40, and octets plus the prefix octet) are 00 2f 40, and
* use the remainder of the MPI directly off the wire. * use the remainder of the MPI directly off the wire.
Note that this is a similar approach to that used in the EC point Note that this is a similar approach to that used in the EC point
encodings found in Section 13.2.2. encodings found in Section 12.2.2.
13.4. Key Derivation Function 12.4. Key Derivation Function
A key derivation function (KDF) is necessary to implement EC A key derivation function (KDF) is necessary to implement EC
encryption. The Concatenation Key Derivation Function (Approved encryption. The Concatenation Key Derivation Function (Approved
Alternative 1) [SP800-56A] with the KDF hash function that is Alternative 1) [SP800-56A] with the KDF hash function that is
SHA2-256 [FIPS180] or stronger is REQUIRED. SHA2-256 [FIPS180] or stronger is REQUIRED.
For convenience, the synopsis of the encoding method is given below For convenience, the synopsis of the encoding method is given below
with significant simplifications attributable to the restricted with significant simplifications attributable to the restricted
choice of hash functions in this document. However, [SP800-56A] is choice of hash functions in this document. However, [SP800-56A] is
the normative source of the definition. the normative source of the definition.
skipping to change at page 113, line 21 skipping to change at page 119, line 21
// Convert the point X to the octet string: // Convert the point X to the octet string:
// ZB' = 04 || x || y // ZB' = 04 || x || y
// and extract the x portion from ZB' // and extract the x portion from ZB'
ZB = x; ZB = x;
MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param ); MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param );
return oBits leftmost bits of MB. return oBits leftmost bits of MB.
Note that ZB in the KDF description above is the compact Note that ZB in the KDF description above is the compact
representation of X as defined in Section 4.2 of [RFC6090]. representation of X as defined in Section 4.2 of [RFC6090].
13.5. EC DH Algorithm (ECDH) 12.5. EC DH Algorithm (ECDH)
The method is a combination of an ECC Diffie-Hellman method to The method is a combination of an ECC Diffie-Hellman method to
establish a shared secret, a key derivation method to process the establish a shared secret, a key derivation method to process the
shared secret into a derived key, and a key wrapping method that uses shared secret into a derived key, and a key wrapping method that uses
the derived key to protect a session key used to encrypt a message. the derived key to protect a session key used to encrypt a message.
The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [SP800-56A] MUST The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [SP800-56A] MUST
be implemented with the following restrictions: the ECC CDH primitive be implemented with the following restrictions: the ECC CDH primitive
employed by this method is modified to always assume the cofactor is employed by this method is modified to always assume the cofactor is
1, the KDF specified in Section 13.4 is used, and the KDF parameters 1, the KDF specified in Section 12.4 is used, and the KDF parameters
specified below are used. specified below are used.
The KDF parameters are encoded as a concatenation of the following 5 The KDF parameters are encoded as a concatenation of the following 5
variable-length and fixed-length fields, which are compatible with variable-length and fixed-length fields, which are compatible with
the definition of the OtherInfo bitstring [SP800-56A]: the definition of the OtherInfo bitstring [SP800-56A]:
* A variable-length field containing a curve OID, which is formatted * A variable-length field containing a curve OID, which is formatted
as follows: as follows:
- A one-octet size of the following field, - A one-octet size of the following field,
skipping to change at page 114, line 10 skipping to change at page 120, line 10
are formatted as follows: are formatted as follows:
- A one-octet size of the following fields; values 0 and 0xFF are - A one-octet size of the following fields; values 0 and 0xFF are
reserved for future extensions, reserved for future extensions,
- A one-octet value 0x01, reserved for future extensions, - A one-octet value 0x01, reserved for future extensions,
- A one-octet hash function ID used with the KDF, - A one-octet hash function ID used with the KDF,
- A one-octet algorithm ID for the symmetric algorithm used to - A one-octet algorithm ID for the symmetric algorithm used to
wrap the symmetric key for message encryption; see Section 13.5 wrap the symmetric key for message encryption; see Section 12.5
for details; for details;
* 20 octets representing the UTF-8 encoding of the string Anonymous * 20 octets representing the UTF-8 encoding of the string Anonymous
Sender , which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 Sender , which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73
20 53 65 6E 64 65 72 20 20 20 20; 20 53 65 6E 64 65 72 20 20 20 20;
* A variable-length field containing the fingerprint of the * A variable-length field containing the fingerprint of the
recipient encryption subkey or a primary key fingerprint recipient encryption subkey or a primary key fingerprint
identifying the key material that is needed for decryption. For identifying the key material that is needed for decryption. For
version 4 keys, this field is 20 octets. For version 5 keys, this version 4 keys, this field is 20 octets. For version 5 keys, this
field is 32 octets. field is 32 octets.
The size in octets of the KDF parameters sequence, defined above, for The size in octets of the KDF parameters sequence, defined above, for
encrypting to a v4 key is either 54 for curve P-256, 51 for curves encrypting to a v4 key is either 54 for curve P-256, 51 for curves
P-384 and P-521, 56 for Curve25519, or 49 for X448. For encrypting P-384 and P-521, 56 for Curve25519, or 49 for X448. For encrypting
to a v5 key, the size of the sequence is either 66 for curve P-256, to a v5 key, the size of the sequence is either 66 for curve P-256,
63 for curves P-384 and P-521, 68 for Curve25519, or 61 for X448. 63 for curves P-384 and P-521, 68 for Curve25519, or 61 for X448.
The key wrapping method is described in [RFC3394]. The KDF produces The key wrapping method is described in [RFC3394]. The KDF produces
a symmetric key that is used as a key-encryption key (KEK) as a symmetric key that is used as a key-encryption key (KEK) as
specified in [RFC3394]. Refer to Section 15 for the details specified in [RFC3394]. Refer to Section 12.5.1 for the details
regarding the choice of the KEK algorithm, which SHOULD be one of regarding the choice of the KEK algorithm, which SHOULD be one of
three AES algorithms. Key wrapping and unwrapping is performed with three AES algorithms. Key wrapping and unwrapping is performed with
the default initial value of [RFC3394]. the default initial value of [RFC3394].
The input to the key wrapping method is the plaintext described in The input to the key wrapping method is the plaintext described in
Section 5.1, "Public-Key Encrypted Session Key Packets (Tag 1)", Section 5.1, "Public-Key Encrypted Session Key Packets (Tag 1)",
padded using the method described in [PKCS5] to an 8-octet padded using the method described in [PKCS5] to an 8-octet
granularity. granularity.
For example, in a V4 Public-Key Encrypted Session Key packet, the For example, in a v4 Public-Key Encrypted Session Key packet, the
following AES-256 session key, in which 32 octets are denoted from k0 following AES-256 session key, in which 32 octets are denoted from k0
to k31, is composed to form the following 40 octet sequence: to k31, is composed to form the following 40 octet sequence:
09 k0 k1 ... k31 s0 s1 05 05 05 05 05 09 k0 k1 ... k31 s0 s1 05 05 05 05 05
The octets s0 and s1 above denote the checksum of the session key The octets s0 and s1 above denote the checksum of the session key
octets. This encoding allows the sender to obfuscate the size of the octets. This encoding allows the sender to obfuscate the size of the
symmetric encryption key used to encrypt the data. For example, symmetric encryption key used to encrypt the data. For example,
assuming that an AES algorithm is used for the session key, the assuming that an AES algorithm is used for the session key, the
sender MAY use 21, 13, and 5 octets of padding for AES-128, AES-192, sender MAY use 21, 13, and 5 octets of padding for AES-128, AES-192,
and AES-256, respectively, to provide the same number of octets, 40 and AES-256, respectively, to provide the same number of octets, 40
total, as an input to the key wrapping method. total, as an input to the key wrapping method.
In a V5 Public-Key Encrypted Session Key packet, the symmetric In a v5 Public-Key Encrypted Session Key packet, the symmetric
algorithm is not included, as described in Section 5.1. For example, algorithm is not included, as described in Section 5.1. For example,
an AES-256 session key would be composed as follows: an AES-256 session key would be composed as follows:
k0 k1 ... k31 s0 s1 06 06 06 06 06 06 k0 k1 ... k31 s0 s1 06 06 06 06 06 06
The octets k0 to k31 above again denote the session key, and the The octets k0 to k31 above again denote the session key, and the
octets s0 and s1 denote the checksum. In this case, assuming that an octets s0 and s1 denote the checksum. In this case, assuming that an
AES algorithm is used for the session key, the sender MAY use 22, 14, AES algorithm is used for the session key, the sender MAY use 22, 14,
and 6 octets of padding for AES-128, AES-192, and AES-256, and 6 octets of padding for AES-128, AES-192, and AES-256,
respectively, to provide the same number of octets, 40 total, as an respectively, to provide the same number of octets, 40 total, as an
skipping to change at page 116, line 25 skipping to change at page 122, line 25
* VB = convert point V to the octet string * VB = convert point V to the octet string
* Output (MPI(VB) || len(C) || C). * Output (MPI(VB) || len(C) || C).
The decryption is the inverse of the method given. Note that the The decryption is the inverse of the method given. Note that the
recipient obtains the shared secret by calculating recipient obtains the shared secret by calculating
S = rV = rvG, where (r,R) is the recipient's key pair. S = rV = rvG, where (r,R) is the recipient's key pair.
Consistent with Section 5.14, AEAD encryption or a Modification Consistent with Section 5.13, AEAD encryption or a Modification
Detection Code (MDC) MUST be used anytime the symmetric key is Detection Code (MDC) MUST be used anytime the symmetric key is
protected by ECDH. protected by ECDH.
14. Notes on Algorithms 12.5.1. ECDH Parameters
14.1. PKCS#1 Encoding in OpenPGP ECDH keys have a hash algorithm parameter for key derivation and a
symmetric algorithm for key encapsulation.
For v5 keys, the following algorithms MUST be used depending on the
curve. An implementation MUST NOT generate a v5 ECDH key over any
listed curve that uses different KDF or KEK parameters. An
implementation MUST NOT encrypt any message to a v5 ECDH key over a
listed curve that announces a different KDF or KEK parameter.
For v4 keys, the following algorithms SHOULD be used depending on the
curve. An implementation SHOULD only use an AES algorithm as a KEK
algorithm.
+============+================+=====================+
| Curve | Hash algorithm | Symmetric algorithm |
+============+================+=====================+
| NIST P-256 | SHA2-256 | AES-128 |
+------------+----------------+---------------------+
| NIST P-384 | SHA2-384 | AES-192 |
+------------+----------------+---------------------+
| NIST P-521 | SHA2-512 | AES-256 |
+------------+----------------+---------------------+
| Curve25519 | SHA2-256 | AES-128 |
+------------+----------------+---------------------+
| X448 | SHA2-512 | AES-256 |
+------------+----------------+---------------------+
Table 31: ECDH KDF and KEK parameters
13. Notes on Algorithms
13.1. PKCS#1 Encoding in OpenPGP
This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and
EMSA-PKCS1-v1_5. However, the calling conventions of these functions EMSA-PKCS1-v1_5. However, the calling conventions of these functions
has changed in the past. To avoid potential confusion and has changed in the past. To avoid potential confusion and
interoperability problems, we are including local copies in this interoperability problems, we are including local copies in this
document, adapted from those in PKCS#1 v2.1 [RFC8017]. [RFC8017] document, adapted from those in PKCS#1 v2.1 [RFC8017]. [RFC8017]
should be treated as the ultimate authority on PKCS#1 for OpenPGP. should be treated as the ultimate authority on PKCS#1 for OpenPGP.
Nonetheless, we believe that there is value in having a self- Nonetheless, we believe that there is value in having a self-
contained document that avoids problems in the future with needed contained document that avoids problems in the future with needed
changes in the conventions. changes in the conventions.
14.1.1. EME-PKCS1-v1_5-ENCODE 13.1.1. EME-PKCS1-v1_5-ENCODE
Input: Input:
k = the length in octets of the key modulus. k = the length in octets of the key modulus.
M = message to be encoded, an octet string of length mLen, where M = message to be encoded, an octet string of length mLen, where
mLen <= k - 11. mLen <= k - 11.
Output: Output:
skipping to change at page 117, line 25 skipping to change at page 124, line 16
pseudo-randomly generated nonzero octets. The length of PS will pseudo-randomly generated nonzero octets. The length of PS will
be at least eight octets. be at least eight octets.
3. Concatenate PS, the message M, and other padding to form an 3. Concatenate PS, the message M, and other padding to form an
encoded message EM of length k octets as encoded message EM of length k octets as
EM = 0x00 || 0x02 || PS || 0x00 || M. EM = 0x00 || 0x02 || PS || 0x00 || M.
4. Output EM. 4. Output EM.
14.1.2. EME-PKCS1-v1_5-DECODE 13.1.2. EME-PKCS1-v1_5-DECODE
Input: Input:
EM = encoded message, an octet string EM = encoded message, an octet string
Output: Output:
M = message, an octet string. M = message, an octet string.
Error: "decryption error". Error: "decryption error".
skipping to change at page 117, line 47 skipping to change at page 124, line 38
To decode an EME-PKCS1_v1_5 message, separate the encoded message EM To decode an EME-PKCS1_v1_5 message, separate the encoded message EM
into an octet string PS consisting of nonzero octets and a message M into an octet string PS consisting of nonzero octets and a message M
as follows as follows
EM = 0x00 || 0x02 || PS || 0x00 || M. EM = 0x00 || 0x02 || PS || 0x00 || M.
If the first octet of EM does not have hexadecimal value 0x00, if the If the first octet of EM does not have hexadecimal value 0x00, if the
second octet of EM does not have hexadecimal value 0x02, if there is second octet of EM does not have hexadecimal value 0x02, if there is
no octet with hexadecimal value 0x00 to separate PS from M, or if the no octet with hexadecimal value 0x00 to separate PS from M, or if the
length of PS is less than 8 octets, output "decryption error" and length of PS is less than 8 octets, output "decryption error" and
stop. See also the security note in Section 15 regarding differences stop. See also Section 14.5 regarding differences in reporting
in reporting between a decryption error and a padding error. between a decryption error and a padding error.
14.1.3. EMSA-PKCS1-v1_5 13.1.3. EMSA-PKCS1-v1_5
This encoding method is deterministic and only has an encoding This encoding method is deterministic and only has an encoding
operation. operation.
Option: Option:
Hash - a hash function in which hLen denotes the length in octets of Hash - a hash function in which hLen denotes the length in octets of
the hash function output. the hash function output.
Input: Input:
skipping to change at page 119, line 9 skipping to change at page 126, line 5
with hexadecimal value 0xFF. The length of PS will be at least 8 with hexadecimal value 0xFF. The length of PS will be at least 8
octets. octets.
5. Concatenate PS, the hash prefix T, and other padding to form the 5. Concatenate PS, the hash prefix T, and other padding to form the
encoded message EM as encoded message EM as
EM = 0x00 || 0x01 || PS || 0x00 || T. EM = 0x00 || 0x01 || PS || 0x00 || T.
6. Output EM. 6. Output EM.
14.2. Symmetric Algorithm Preferences 13.2. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature, that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have multiple, different it is possible that a keyholder may have multiple, different
preferences. For example, Alice may have AES-128 only specified for preferences. For example, Alice may have AES-128 only specified for
"alice@work.com" but Camellia-256, Twofish, and AES-128 specified for "alice@work.com" but Camellia-256, Twofish, and AES-128 specified for
"alice@home.org". Note that it is also possible for preferences to "alice@home.org". Note that it is also possible for preferences to
be in a subkey's binding signature. be in a subkey's binding signature.
Since AES-128 is the MUST-implement algorithm, if it is not Since AES-128 is the MUST-implement algorithm, if it is not
skipping to change at page 119, line 45 skipping to change at page 126, line 41
If an implementation can decrypt a message that a keyholder doesn't If an implementation can decrypt a message that a keyholder doesn't
have in their preferences, the implementation SHOULD decrypt the have in their preferences, the implementation SHOULD decrypt the
message anyway, but MUST warn the keyholder that the protocol has message anyway, but MUST warn the keyholder that the protocol has
been violated. For example, suppose that Alice, above, has software been violated. For example, suppose that Alice, above, has software
that implements all algorithms in this specification. Nonetheless, that implements all algorithms in this specification. Nonetheless,
she prefers subsets for work or home. If she is sent a message she prefers subsets for work or home. If she is sent a message
encrypted with IDEA, which is not in her preferences, the software encrypted with IDEA, which is not in her preferences, the software
warns her that someone sent her an IDEA-encrypted message, but it warns her that someone sent her an IDEA-encrypted message, but it
would ideally decrypt it anyway. would ideally decrypt it anyway.
14.2.1. Plaintext 13.2.1. Plaintext
Algorithm 0, "plaintext", may only be used to denote secret keys that Algorithm 0, "plaintext", may only be used to denote secret keys that
are stored in the clear. Implementations MUST NOT use plaintext in are stored in the clear. Implementations MUST NOT use plaintext in
encrypted data packets; they must use Literal Data packets to encode encrypted data packets; they must use Literal Data packets to encode
unencrypted literal data. unencrypted literal data.
14.3. Other Algorithm Preferences 13.3. Other Algorithm Preferences
Other algorithm preferences work similarly to the symmetric algorithm Other algorithm preferences work similarly to the symmetric algorithm
preference, in that they specify which algorithms the keyholder preference, in that they specify which algorithms the keyholder
accepts. There are two interesting cases that other comments need to accepts. There are two interesting cases that other comments need to
be made about, though, the compression preferences and the hash be made about, though, the compression preferences and the hash
preferences. preferences.
14.3.1. Compression Preferences 13.3.1. Compression Preferences
Like the algorithm preferences, an implementation MUST NOT use an Like the algorithm preferences, an implementation MUST NOT use an
algorithm that is not in the preference vector. If Uncompressed (0) algorithm that is not in the preference vector. If Uncompressed (0)
is not explicitly in the list, it is tacitly at the end. That is, is not explicitly in the list, it is tacitly at the end. That is,
uncompressed messages may always be sent. uncompressed messages may always be sent.
Note that earlier implementations may assume that the absence of Note that earlier implementations may assume that the absence of
compression preferences means that [ZIP(1), Uncompressed(0)] are compression preferences means that [ZIP(1), Uncompressed(0)] are
preferred, and default to ZIP compression. Therefore, an preferred, and default to ZIP compression. Therefore, an
implementation that prefers uncompressed data SHOULD explicitly state implementation that prefers uncompressed data SHOULD explicitly state
this in the preferred compression algorithms. this in the preferred compression algorithms.
14.3.1.1. Uncompressed 13.3.1.1. Uncompressed
Algorithm 0, "uncompressed", may only be used to denote a preference Algorithm 0, "uncompressed", may only be used to denote a preference
for uncompressed data. Implementations MUST NOT use uncompressed in for uncompressed data. Implementations MUST NOT use uncompressed in
Compressed Data packets; they must use Literal Data packets to encode Compressed Data packets; they must use Literal Data packets to encode
uncompressed literal data. uncompressed literal data.
14.3.2. Hash Algorithm Preferences 13.3.2. Hash Algorithm Preferences
Typically, the choice of a hash algorithm is something the signer Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer rarely knows who is does, rather than the verifier, because a signer rarely knows who is
going to be verifying the signature. This preference, though, allows going to be verifying the signature. This preference, though, allows
a protocol based upon digital signatures ease in negotiation. a protocol based upon digital signatures ease in negotiation.
Thus, if Alice is authenticating herself to Bob with a signature, it Thus, if Alice is authenticating herself to Bob with a signature, it
makes sense for her to use a hash algorithm that Bob's software uses. makes sense for her to use a hash algorithm that Bob's software uses.
This preference allows Bob to state in his key which algorithms Alice This preference allows Bob to state in his key which algorithms Alice
may use. may use.
Since SHA2-256 is the MUST-implement hash algorithm, if it is not Since SHA2-256 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly. good form to place it there explicitly.
14.4. RSA 13.4. RSA
The PKCS1-v1_5 padding scheme, used by the RSA algorithms defined in
this document, is no longer recommended, and its use is deprecated by
[SP800-131A]. Therefore, an implementation SHOULD NOT generate RSA
keys.
There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
keys. These types are deprecated. The "key flags" subpacket in a keys. These types are deprecated. The "key flags" subpacket in a
signature is a much better way to express the same idea, and signature is a much better way to express the same idea, and
generalizes it to all algorithms. An implementation SHOULD NOT generalizes it to all algorithms. An implementation MUST NOT create
create such a key, but MAY interpret it. such a key, but MAY interpret it.
An implementation SHOULD NOT implement RSA keys of size less than
1024 bits.
14.5. DSA
An implementation SHOULD NOT implement DSA keys of size less than
1024 bits. It MUST NOT implement a DSA key with a q size of less
than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the
q size MUST be a multiple of 8 bits. The Digital Signature Standard
(DSS) [FIPS186] specifies that DSA be used in one of the following
ways:
* 1024-bit key, 160-bit q, SHA-1, SHA2-224, SHA2-256, SHA2-384, or
SHA2-512 hash
* 2048-bit key, 224-bit q, SHA2-224, SHA2-256, SHA2-384, or SHA2-512 An implementation MUST NOT generate RSA keys of size less than 3072
hash bits. An implementation SHOULD NOT encrypt, sign or verify using RSA
keys of size less than 3072 bits. An implementation MUST NOT
encrypt, sign or verify using RSA keys of size less than 2048 bits.
An implementation that decrypts a message using an RSA secret key of
size less than 3072 bits SHOULD generate a deprecation warning that
the key is too weak for modern use.
* 2048-bit key, 256-bit q, SHA2-256, SHA2-384, or SHA2-512 hash 13.5. DSA
* 3072-bit key, 256-bit q, SHA2-256, SHA2-384, or SHA2-512 hash DSA is expected to be deprecated in [FIPS186-5]. Therefore, an
implementation MUST NOT generate DSA keys.
The above key and q size pairs were chosen to best balance the An implementation MUST NOT sign or verify using DSA keys.
strength of the key with the strength of the hash. Implementations
SHOULD use one of the above key and q size pairs when generating DSA
keys. If DSS compliance is desired, one of the specified SHA hashes
must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160-bit q 13.6. Elgamal
with no truncation allowed, so earlier implementations may not be
able to handle signatures with a different q size or a truncated
hash.
14.6. Elgamal The PKCS1-v1_5 padding scheme, used by the Elgamal algorithm defined
in this document, is no longer recommended, and its use is deprecated
by [SP800-131A]. Therefore, an implementation MUST NOT generate
Elgamal keys.
An implementation SHOULD NOT implement Elgamal keys of size less than An implementation MUST NOT encrypt using Elgamal keys. An
1024 bits. implementation that decrypts a message using an Elgamal secret key
SHOULD generate a deprecation warning that the key is too weak for
modern use.
14.7. EdDSA 13.7. EdDSA
Although the EdDSA algorithm allows arbitrary data as input, its use Although the EdDSA algorithm allows arbitrary data as input, its use
with OpenPGP requires that a digest of the message is used as input with OpenPGP requires that a digest of the message is used as input
(pre-hashed). See Section 5.2.4 for details. Truncation of the (pre-hashed). See Section 5.2.4 for details. Truncation of the
resulting digest is never applied; the resulting digest value is used resulting digest is never applied; the resulting digest value is used
verbatim as input to the EdDSA algorithm. verbatim as input to the EdDSA algorithm.
For clarity: while [RFC8032] describes different variants of EdDSA, For clarity: while [RFC8032] describes different variants of EdDSA,
OpenPGP uses the "pure" variant (PureEdDSA). The hashing that OpenPGP uses the "pure" variant (PureEdDSA). The hashing that
happens with OpenPGP is done as part of the standard OpenPGP happens with OpenPGP is done as part of the standard OpenPGP
signature process, and that hash itself is fed as the input message signature process, and that hash itself is fed as the input message
to the PureEdDSA algorithm. to the PureEdDSA algorithm.
As specified in [RFC8032], Ed448 also expects a "context string". In As specified in [RFC8032], Ed448 also expects a "context string". In
OpenPGP, Ed448 is used with the empty string as a context string. OpenPGP, Ed448 is used with the empty string as a context string.
14.8. Reserved Algorithm Numbers 13.8. Reserved Algorithm Numbers
A number of algorithm IDs have been reserved for algorithms that A number of algorithm IDs have been reserved for algorithms that
would be useful to use in an OpenPGP implementation, yet there are would be useful to use in an OpenPGP implementation, yet there are
issues that prevent an implementer from actually implementing the issues that prevent an implementer from actually implementing the
algorithm. These are marked in Section 9.1 as "reserved for". algorithm. These are marked in Section 9.1 as "reserved for".
The reserved public-key algorithm X9.42 (21) does not have the The reserved public-key algorithm X9.42 (21) does not have the
necessary parameters, parameter order, or semantics defined. The necessary parameters, parameter order, or semantics defined. The
same is currently true for reserved public-key algorithms AEDH (23) same is currently true for reserved public-key algorithms AEDH (23)
and AEDSA (24). and AEDSA (24).
Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
with a public-key identifier of 20. These are no longer permitted. with a public-key identifier of 20. These are no longer permitted.
An implementation MUST NOT generate such keys. An implementation An implementation MUST NOT generate such keys. An implementation
MUST NOT generate Elgamal signatures. See [BLEICHENBACHER]. MUST NOT generate Elgamal signatures. See [BLEICHENBACHER].
14.9. OpenPGP CFB Mode 13.9. OpenPGP CFB Mode
When using a version 1 Symmetrically Encrypted Integrity Protected When using a version 1 Symmetrically Encrypted Integrity Protected
Data packet (Section 5.14.1) or --- for historic data --- a Data packet (Section 5.13.1) or --- for historic data --- a
Symmetrically Encrypted Data packet (Section 5.8), OpenPGP does Symmetrically Encrypted Data packet (Section 5.7), OpenPGP does
symmetric encryption using a variant of Cipher Feedback mode (CFB symmetric encryption using a variant of Cipher Feedback mode (CFB
mode). This section describes the procedure it uses in detail. This mode). This section describes the procedure it uses in detail. This
mode is what is used for Symmetrically Encrypted Integrity Protected mode is what is used for Symmetrically Encrypted Integrity Protected
Data Packets (and the dangerously malleable --- and deprecated --- Data Packets (and the dangerously malleable --- and deprecated ---
Symmetrically Encrypted Data Packets). Some mechanisms for Symmetrically Encrypted Data Packets). Some mechanisms for
encrypting secret-key material also use CFB mode, as described in encrypting secret-key material also use CFB mode, as described in
Section 3.7.2.1. Section 3.7.2.1.
In the description below, the value BS is the block size in octets of In the description below, the value BS is the block size in octets of
the cipher. Most ciphers have a block size of 8 octets. The AES and the cipher. Most ciphers have a block size of 8 octets. The AES and
skipping to change at page 124, line 14 skipping to change at page 131, line 9
10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
for an 8-octet block). for an 8-octet block).
11. FR is encrypted to produce FRE. 11. FR is encrypted to produce FRE.
12. FRE is xored with the next BS octets of plaintext, to produce 12. FRE is xored with the next BS octets of plaintext, to produce
the next BS octets of ciphertext. These are loaded into FR, and the next BS octets of ciphertext. These are loaded into FR, and
the process is repeated until the plaintext is used up. the process is repeated until the plaintext is used up.
14.10. Private or Experimental Parameters 13.10. Private or Experimental Parameters
S2K specifiers, Signature subpacket types, User Attribute types, S2K specifiers, Signature subpacket types, User Attribute types,
image format types, and algorithms described in Section 9 all reserve image format types, and algorithms described in Section 9 all reserve
the range 100 to 110 for private and experimental use. Packet types the range 100 to 110 for private and experimental use. Packet types
reserve the range 60 to 63 for private and experimental use. These reserve the range 60 to 63 for private and experimental use. These
are intentionally managed with the PRIVATE USE method, as described are intentionally managed with the PRIVATE USE method, as described
in [RFC8126]. in [RFC8126].
However, implementations need to be careful with these and promote However, implementations need to be careful with these and promote
them to full IANA-managed parameters when they grow beyond the them to full IANA-managed parameters when they grow beyond the
original, limited system. original, limited system.
14.11. Meta-Considerations for Expansion 13.11. Meta-Considerations for Expansion
If OpenPGP is extended in a way that is not backwards-compatible, If OpenPGP is extended in a way that is not backwards-compatible,
meaning that old implementations will not gracefully handle their meaning that old implementations will not gracefully handle their
absence of a new feature, the extension proposal can be declared in absence of a new feature, the extension proposal can be declared in
the key holder's self-signature as part of the Features signature the key holder's self-signature as part of the Features signature
subpacket. subpacket.
We cannot state definitively what extensions will not be upwards- We cannot state definitively what extensions will not be upwards-
compatible, but typically new algorithms are upwards-compatible, compatible, but typically new algorithms are upwards-compatible,
whereas new packets are not. whereas new packets are not.
If an extension proposal does not update the Features system, it If an extension proposal does not update the Features system, it
SHOULD include an explanation of why this is unnecessary. If the SHOULD include an explanation of why this is unnecessary. If the
proposal contains neither an extension to the Features system nor an proposal contains neither an extension to the Features system nor an
explanation of why such an extension is unnecessary, the proposal explanation of why such an extension is unnecessary, the proposal
SHOULD be rejected. SHOULD be rejected.
15. Security Considerations 14. Security Considerations
* As with any technology involving cryptography, you should check * As with any technology involving cryptography, you should check
the current literature to determine if any algorithms used here the current literature to determine if any algorithms used here
have been found to be vulnerable to attack. have been found to be vulnerable to attack.
* This specification uses Public-Key Cryptography technologies. It * This specification uses Public-Key Cryptography technologies. It
is assumed that the private key portion of a public-private key is assumed that the private key portion of a public-private key
pair is controlled and secured by the proper party or parties. pair is controlled and secured by the proper party or parties.
* The MD5 hash algorithm has been found to have weaknesses, with * The MD5 hash algorithm has been found to have weaknesses, with
skipping to change at page 125, line 24 skipping to change at page 132, line 20
* SHA2-224 and SHA2-384 require the same work as SHA2-256 and * SHA2-224 and SHA2-384 require the same work as SHA2-256 and
SHA2-512, respectively. In general, there are few reasons to use SHA2-512, respectively. In general, there are few reasons to use
them outside of DSS compatibility. You need a situation where one them outside of DSS compatibility. You need a situation where one
needs more security than smaller hashes, but does not want to have needs more security than smaller hashes, but does not want to have
the full 256-bit or 512-bit data length. the full 256-bit or 512-bit data length.
* Many security protocol designers think that it is a bad idea to * Many security protocol designers think that it is a bad idea to
use a single key for both privacy (encryption) and integrity use a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces (signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption behind the v4 key format with separate signature and encryption
keys. If you as an implementer promote dual-use keys, you should keys. If you as an implementer promote dual-use keys, you should
at least be aware of this controversy. at least be aware of this controversy.
* The DSA algorithm will work with any hash, but is sensitive to the * The DSA algorithm will work with any hash, but is sensitive to the
quality of the hash algorithm. Verifiers should be aware that quality of the hash algorithm. Verifiers should be aware that
even if the signer used a strong hash, an attacker could have even if the signer used a strong hash, an attacker could have
modified the signature to use a weak one. Only signatures using modified the signature to use a weak one. Only signatures using
acceptably strong hash algorithms should be accepted as valid. acceptably strong hash algorithms should be accepted as valid.
* As OpenPGP combines many different asymmetric, symmetric, and hash * As OpenPGP combines many different asymmetric, symmetric, and hash
skipping to change at page 126, line 19 skipping to change at page 132, line 52
+---------------------+-----------+--------------------+ +---------------------+-----------+--------------------+
| 2048 | 224 | 112 | | 2048 | 224 | 112 |
+---------------------+-----------+--------------------+ +---------------------+-----------+--------------------+
| 3072 | 256 | 128 | | 3072 | 256 | 128 |
+---------------------+-----------+--------------------+ +---------------------+-----------+--------------------+
| 7680 | 384 | 192 | | 7680 | 384 | 192 |
+---------------------+-----------+--------------------+ +---------------------+-----------+--------------------+
| 15360 | 512 | 256 | | 15360 | 512 | 256 |
+---------------------+-----------+--------------------+ +---------------------+-----------+--------------------+
Table 29: Key length equivalences Table 32: Key length equivalences
* There is a somewhat-related potential security problem in * There is a somewhat-related potential security problem in
signatures. If an attacker can find a message that hashes to the signatures. If an attacker can find a message that hashes to the
same hash with a different algorithm, a bogus signature structure same hash with a different algorithm, a bogus signature structure
can be constructed that evaluates correctly. can be constructed that evaluates correctly.
For example, suppose Alice DSA signs message M using hash For example, suppose Alice DSA signs message M using hash
algorithm H. Suppose that Mallet finds a message M' that has the algorithm H. Suppose that Mallet finds a message M' that has the
same hash value as M with H'. Mallet can then construct a same hash value as M with H'. Mallet can then construct a
signature block that verifies as Alice's signature of M' with H'. signature block that verifies as Alice's signature of M' with H'.
skipping to change at page 127, line 10 skipping to change at page 133, line 34
been analyzed less than others. For example, although CAST5 is been analyzed less than others. For example, although CAST5 is
presently considered strong, it has been analyzed less than presently considered strong, it has been analyzed less than
TripleDES. Other algorithms may have other controversies TripleDES. Other algorithms may have other controversies
surrounding them. surrounding them.
* In late summer 2002, Jallad, Katz, and Schneier published an * In late summer 2002, Jallad, Katz, and Schneier published an
interesting attack on older versions of the OpenPGP protocol and interesting attack on older versions of the OpenPGP protocol and
some of its implementations [JKS02]. In this attack, the attacker some of its implementations [JKS02]. In this attack, the attacker
modifies a message and sends it to a user who then returns the modifies a message and sends it to a user who then returns the
erroneously decrypted message to the attacker. The attacker is erroneously decrypted message to the attacker. The attacker is
thus using the user as a random oracle, and can often decrypt the thus using the user as a decryption oracle, and can often decrypt
message. This attack is a particular form of ciphertext the message. This attack is a particular form of ciphertext
malleability. See Section 15.1 for information on how to defend malleability. See Section 14.7 for information on how to defend
against such an attack using more recent versions of OpenPGP. against such an attack using more recent versions of OpenPGP.
* PKCS#1 has been found to be vulnerable to attacks in which a
system that reports errors in padding differently from errors in
decryption becomes a random oracle that can leak the private key
in mere millions of queries. Implementations must be aware of
this attack and prevent it from happening. The simplest solution
is to report a single error code for all variants of decryption
errors so as not to leak information to an attacker.
* Some technologies mentioned here may be subject to government * Some technologies mentioned here may be subject to government
control in some countries. control in some countries.
* In winter 2005, Serge Mister and Robert Zuccherato from Entrust 14.1. SHA-1 Collision Detection
released a paper describing a way that the "quick check" in
OpenPGP CFB mode can be used with a random oracle to decrypt two
octets of every cipher block [MZ05]. They recommend as prevention
not using the quick check at all.
Many implementers have taken this advice to heart for any data As described in [SHAMBLES], the SHA-1 digest algorithm is not
that is symmetrically encrypted and for which the session key is collision-resistant. However, an OpenPGP implementation cannot
public-key encrypted. In this case, the quick check is not needed completely discard the SHA-1 algorithm, because it is required for
as the public-key encryption of the session key should guarantee implementing and reasoning about v4 public keys. In particular, the
that it is the right session key. In other cases, the v4 fingerprint derivation uses SHA-1. So as long as an OpenPGP
implementation should use the quick check with care. implementation supports v4 public keys, it will need to implement
SHA-1 in at least some scenarios.
On the one hand, there is a danger to using it if there is a To avoid the risk of uncertain breakage from a maliciously introduced
random oracle that can leak information to an attacker. In SHA-1 collision, an OpenPGP implementation MAY attempt to detect when
plainer language, there is a danger to using the quick check if a hash input is likely from a known collision attack, and then either
timing information about the check can be exposed to an attacker, deliberately reject the hash input or modify the hash output. This
particularly via an automated service that allows rapidly repeated should convert an uncertain breakage (where it is unclear what the
queries. effect of a collision will be) to an explicit breakage, which is more
desirable for a robust implementation.
On the other hand, it is inconvenient to the user to be informed [STEVENS2013] describes a method for detecting indicators of well-
that they typed in the wrong passphrase only after a petabyte of known SHA-1 collision attacks. Some example C code implementing this
data is decrypted. There are many cases in cryptographic technique can be found at [SHA1CD].
engineering where the implementer must use care and wisdom, and
this is one.
* An implementation SHOULD only use an AES algorithm as a KEK 14.2. Advantages of Salted Signatures
algorithm, since backward compatibility of the ECDH format is not
a concern. The KEK algorithm is only used within the scope of a
Public-Key Encrypted Session Key Packet, which represents an ECDH
key recipient of a message. Compare this with the algorithm used
for the session key of the message, which MAY be different from a
KEK algorithm.
Side channel attacks are a concern when a compliant application's V5 signatures include a 128 bit salt that is hashed first. This
use of the OpenPGP format can be modeled by a decryption or makes v5 OpenPGP signatures non-deterministic and protects against a
signing oracle, for example, when an application is a network broad class of attacks that depend on creating a signature over a
service performing decryption to unauthenticated remote users. predictable message. By selecting a new random salt for each
ECC scalar multiplication operations used in ECDSA and ECDH are signature made, signatures are not predictable.
vulnerable to side channel attacks. Countermeasures can often be
taken at the higher protocol level, such as limiting the number of
allowed failures or time-blinding of the operations associated
with each network interface. Mitigations at the scalar
multiplication level seek to eliminate any measurable distinction
between the ECC point addition and doubling operations.
* V5 signatures include a 128 bit salt that is hashed first. This When the material to be signed may be attacker-controlled, hashing
makes OpenPGP signatures non-deterministic and protects against a the salt first means that there is no attacker controlled hashed
broad class of attacks that depend on creating a signature over a prefix. An example of this kind of attack is described in the paper
predictable message. Hashing the salt first means that there is SHA-1 Is A Shambles (see [SHAMBLES]), which leverages a chosen prefix
no attacker controlled hashed prefix. An example of this kind of collision attack against SHA-1.
attack is described in the paper SHA-1 Is A Shambles (see
[SHAMBLES]), which leverages a chosen prefix collision attack
against SHA-1.
15.1. Avoiding Ciphertext Malleability In some cases, an attacker may be able to induce a signature to be
made, even if they do not control the content of the message. In
some scenarios, a repeated signature over the exact same message may
risk leakage of part or all of the signing key, for example see
discussion of hardware faults over EdDSA and deterministic ECDSA in
[PSSLR17]. Choosing a new random salt for each signature ensures
that no repeated signatures are produced, and mitigates this risk.
14.3. Elliptic Curve Side Channels
Side channel attacks are a concern when a compliant application's use
of the OpenPGP format can be modeled by a decryption or signing
oracle, for example, when an application is a network service
performing decryption to unauthenticated remote users. ECC scalar
multiplication operations used in ECDSA and ECDH are vulnerable to
side channel attacks. Countermeasures can often be taken at the
higher protocol level, such as limiting the number of allowed
failures or time-blinding of the operations associated with each
network interface. Mitigations at the scalar multiplication level
seek to eliminate any measurable distinction between the ECC point
addition and doubling operations.
14.4. Risks of a Quick Check Oracle
In winter 2005, Serge Mister and Robert Zuccherato from Entrust
released a paper describing a way that the "quick check" in OpenPGP
CFB mode (used by v1 SEIPD and SED packets) can be as an oracle to
decrypt two octets of every cipher block [MZ05]. This check was
intended for early detection of session key decryption errors,
particularly to detect a wrong passphrase, since v4 SKESK packets do
not include an integrity check.
There is a danger to using the quick check if timing or error
information about the check can be exposed to an attacker,
particularly via an automated service that allows rapidly repeated
queries.
Disabling the quick check prevents the attack.
For very large legacy encrypted data whose session key is protected
by a passphrase (v4 SKESK), while the quick check may be convenient
to the user to be informed early on that they typed the wrong
passphrase, the implementation should use the quick check with care.
The recommended approach for secure and early detection of decryption
failure is to encrypt data using v2 SEIPD. If the session key is
public-key encrypted, the quick check is not useful as the public-key
encryption of the session key should guarantee that it is the right
session key.
The quick check oracle attack is a particular type of attack that
exploits ciphertext malleability. For information about other
similar attacks, see Section 14.7.
14.5. Avoiding Leaks From PKCS#1 Errors
The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted
PKESK) has been found to be vulnerable to attacks in which a system
that allows distinguishing padding errors from other decryption
errors can act as a decryption and/or signing oracle that can leak
the session key or allow signing arbitrary data, respectively
[BLEICHENBACHER-PKCS1]. The number of queries required to carry out
an attack can range from thousands to millions, depending on how
strict and careful an implementation is in processing the padding.
To make the attack more difficult, an implementation SHOULD implement
strict, robust, constant time padding checks.
To prevent the attack, in settings where the attacker does not have
access to timing information concerning message decryption, the
simplest solution is to report a single error code for all variants
of PKESK processing errors as well as SEIPD integrity errors (this
includes also session key parsing errors, such as on invalid cipher
algorithm for v3 PKESK, or session key size mismatch for v5 PKESK).
If the attacker may have access to timing information, then a
constant time solution is also needed. This requires careful design,
especially for v3 PKESK, where session key size and cipher
information is typically not known in advance, as it is part of the
PKESK encrypted payload.
14.6. Fingerprint Usability
This specification uses fingerprints in several places on the wire
(e.g., Section 5.2.3.20, Section 5.2.3.32, and Section 5.2.3.33), and
in processing (e.g., in ECDH KDF Section 12.5). An implementation
may also use the fingerprint internally, for example as an index to a
keystore.
Additionally, some OpenPGP users have historically used manual
fingerprint comparison to verify the public key of a peer. For a
version 4 fingerprint, this has typically been done with the
fingerprint represented as 40 hexadecimal digits, often broken into
groups of four digits with whitespace between each group.
When a human is actively involved, the result of such a verification
is dubious. We have little evidence that most humans are good at
precise comparison of high-entropy data, particularly when that data
is represented in compact textual form like a hexadecimal
fingerprint.
The version 5 fingerprint makes the challenge for a human verifier
even worse. At 256 bits (compared to v4's 160 bit fingerprint), a v5
fingerprint is even harder for a human to successfully compare.
An OpenPGP implementation should prioritize mechanical fingerprint
transfer and comparison where possible, and SHOULD NOT promote manual
transfer or comparison of full fingerprints by a human unless there
is no other way to achieve the desired result.
While this subsection acknowledges existing practice for human-
representable v4 fingerprints, this document does not attempt to
standardize any specific human-readable form of v5 fingerprint for
this discouraged use case.
NOTE: the topic of interoperable human-in-the-loop key verification
needs more work, probably in a separate document.
14.7. Avoiding Ciphertext Malleability
If ciphertext can be modified by an attacker but still subsequently If ciphertext can be modified by an attacker but still subsequently
decrypted to some new plaintext, it is considered "malleable". A decrypted to some new plaintext, it is considered "malleable". A
number of attacks can arise in any cryptosystem that uses malleable number of attacks can arise in any cryptosystem that uses malleable
encryption, so modern OpenPGP offers mechanisms to defend against it. encryption, so modern OpenPGP offers mechanisms to defend against it.
However, legacy OpenPGP data may have been created before these However, legacy OpenPGP data may have been created before these
mechanisms were available. Because OpenPGP implementations deal with mechanisms were available. Because OpenPGP implementations deal with
historic stored data, they may encounter malleable ciphertexts. historic stored data, they may encounter malleable ciphertexts.
When an OpenPGP implementation discovers that it is decrypting data When an OpenPGP implementation discovers that it is decrypting data
that appears to be malleable, it MUST indicate a clear error message that appears to be malleable, it MUST indicate a clear error message
that the integrity of the message is suspect, SHOULD NOT release that the integrity of the message is suspect, SHOULD NOT attempt to
decrypted data to the user, and SHOULD halt with an error. An parse nor release decrypted data to the user, and SHOULD halt with an
implementation that encounters malleable ciphertext MAY choose to error. Parsing or releasing decrypted data before having confirmed
its integrity can leak the decrypted data [EFAIL], [MRLG15].
An implementation that encounters malleable ciphertext MAY choose to
release cleartext to the user if it is known to be dealing with release cleartext to the user if it is known to be dealing with
historic archived legacy data, and the user is aware of the risks. historic archived legacy data, and the user is aware of the risks.
Any of the following OpenPGP data elements indicate that malleable Any of the following OpenPGP data elements indicate that malleable
ciphertext is present: ciphertext is present:
* all Symmetrically Encrypted Data packets (Section 5.8). * all Symmetrically Encrypted Data packets (Section 5.7).
* within any encrypted container, any Compressed Data packet * within any encrypted container, any Compressed Data packet
(Section 5.7) where there is a decompression failure. (Section 5.6) where there is a decompression failure.
* any version 1 Symmetrically Encrypted Integrity Protected Data * any version 1 Symmetrically Encrypted Integrity Protected Data
packet (Section 5.14.1) where the internal Modification Detection packet (Section 5.13.1) where the internal Modification Detection
Code does not validate. Code does not validate.
* any version 2 Symmetrically Encrypted Integrity Protected Data * any version 2 Symmetrically Encrypted Integrity Protected Data
packet (Section 5.14.2) where the authentication tag of any chunk packet (Section 5.13.2) where the authentication tag of any chunk
fails, or where there is no final zero-octet chunk. fails, or where there is no final zero-octet chunk.
* any Secret Key packet with encrypted secret key material * any Secret Key packet with encrypted secret key material
(Section 3.7.2.1) where there is an integrity failure, based on (Section 3.7.2.1) where there is an integrity failure, based on
the value of the secret key protection octet: the value of the secret key protection octet:
- value 255 or raw cipher algorithm: where the trailing 2-octet - value 255 or raw cipher algorithm: where the trailing 2-octet
checksum does not match. checksum does not match.
- value 254: where the SHA1 checksum is mismatched. - value 254: where the SHA1 checksum is mismatched.
skipping to change at page 130, line 5 skipping to change at page 138, line 24
- all recipient keys indicate support for version 2 of the - all recipient keys indicate support for version 2 of the
Symmetrically Encrypted Integrity Protected Data packet in Symmetrically Encrypted Integrity Protected Data packet in
their Features subpacket (Section 5.2.3.29), or are v5 keys their Features subpacket (Section 5.2.3.29), or are v5 keys
without a Features subpacket, or the implementation can without a Features subpacket, or the implementation can
otherwise infer that all recipients support v2 SEIPD packets, otherwise infer that all recipients support v2 SEIPD packets,
the implementation MUST encrypt using a v2 SEIPD packet. the implementation MUST encrypt using a v2 SEIPD packet.
- If one of the recipients does not support v2 SEIPD packets, - If one of the recipients does not support v2 SEIPD packets,
then the message generator MAY use a v1 SEIPD packet instead. then the message generator MAY use a v1 SEIPD packet instead.
* Password-protected secret key material in a V5 Secret Key or V5 * Password-protected secret key material in a v5 Secret Key or v5
Secret Subkey packet SHOULD be protected with AEAD encryption (S2K Secret Subkey packet SHOULD be protected with AEAD encryption (S2K
usage octet 253) unless it will be transferred to an usage octet 253) unless it will be transferred to an
implementation that is known to not support AEAD. implementation that is known to not support AEAD. Implementations
should be aware that, in scenarios where an attacker has access to
encrypted private keys, CFB-encrypted keys (S2K usage octet 254 or
255) are vulnerable to corruption attacks that can cause leakage
of secret data when the secret key is used [KOPENPGP], [KR02].
Implementers should implement AEAD (v2 SEIPD and S2K usage octet 253) Implementers should implement AEAD (v2 SEIPD and S2K usage octet 253)
promptly and encourage its spread. promptly and encourage its spread.
Users should migrate to AEAD with all due speed. Users should migrate to AEAD with all due speed.
15.2. Escrowed Revocation Signatures 14.8. Escrowed Revocation Signatures
A keyholder Alice may wish to designate a third party to be able to A keyholder Alice may wish to designate a third party to be able to
revoke Alice's own key. revoke Alice's own key.
The preferred way for her to do this is produce a specific Revocation The preferred way for her to do this is produce a specific Revocation
Signature (signature types 0x20, 0x28, or 0x30) and distribute it Signature (signature types 0x20, 0x28, or 0x30) and distribute it
securely to her preferred revoker who can hold it in escrow. The securely to her preferred revoker who can hold it in escrow. The
preferred revoker can then publish the escrowed Revocation Signature preferred revoker can then publish the escrowed Revocation Signature
at whatever time is deemed appropriate, rather than generating a at whatever time is deemed appropriate, rather than generating a
revocation signature themselves. revocation signature themselves.
skipping to change at page 131, line 10 skipping to change at page 139, line 29
authorized Revocation Key subpacket is uneven and unreliable. authorized Revocation Key subpacket is uneven and unreliable.
* If the fingerprint mechanism suffers a cryptanalytic flaw, the * If the fingerprint mechanism suffers a cryptanalytic flaw, the
escrowed Revocation Signature is not affected. escrowed Revocation Signature is not affected.
A Revocation Signature may also be split up into shares and A Revocation Signature may also be split up into shares and
distributed among multiple parties, requiring some subset of those distributed among multiple parties, requiring some subset of those
parties to collaborate before the escrowed Revocation Signature is parties to collaborate before the escrowed Revocation Signature is
recreated. recreated.
15.3. Random Number Generation and Seeding 14.9. Random Number Generation and Seeding
OpenPGP requires a cryptographically secure pseudorandom number OpenPGP requires a cryptographically secure pseudorandom number
generator (CSPRNG). In most cases, the operating system provides an generator (CSPRNG). In most cases, the operating system provides an
appropriate facility such as a getrandom() syscall, which should be appropriate facility such as a getrandom() syscall, which should be
used absent other (for example, performance) concerns. It is used absent other (for example, performance) concerns. It is
RECOMMENDED to use an existing CSPRNG implementation in preference to RECOMMENDED to use an existing CSPRNG implementation in preference to
crafting a new one. Many adequate cryptographic libraries are crafting a new one. Many adequate cryptographic libraries are
already available under favorable license terms. Should those prove already available under favorable license terms. Should those prove
unsatisfactory, [RFC4086] provides guidance on the generation of unsatisfactory, [RFC4086] provides guidance on the generation of
random values. random values.
skipping to change at page 131, line 43 skipping to change at page 140, line 16
problem, as it is not feasible to determine the CSPRNG state from its problem, as it is not feasible to determine the CSPRNG state from its
output. However, with a broken CSPRNG, it may be possible for an output. However, with a broken CSPRNG, it may be possible for an
attacker to use visible output to determine the CSPRNG internal state attacker to use visible output to determine the CSPRNG internal state
and thereby predict less-visible data like keying material, as and thereby predict less-visible data like keying material, as
documented in [CHECKOWAY]. documented in [CHECKOWAY].
An implementation can provide extra security against this form of An implementation can provide extra security against this form of
attack by using separate CSPRNGs to generate random data with attack by using separate CSPRNGs to generate random data with
different levels of visibility.