< draft-ietf-openpgp-crypto-refresh-02.txt   draft-ietf-openpgp-crypto-refresh-03.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 22 February 2021 Intended status: Standards Track No Hats
Expires: 26 August 2021 Expires: 3 November 2021 2 May 2021
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-crypto-refresh-02 draft-ietf-openpgp-crypto-refresh-03
Abstract Abstract
{ Work in progress to update the OpenPGP specification from RFC4880 } { Work in progress to update the OpenPGP specification from RFC4880 }
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
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 26 August 2021. This Internet-Draft will expire on 3 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. General functions . . . . . . . . . . . . . . . . . . . . . . 7 2. General functions . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Confidentiality via Encryption . . . . . . . . . . . . . 7 2.1. Confidentiality via Encryption . . . . . . . . . . . . . 7
2.2. Authentication via Digital Signature . . . . . . . . . . 8 2.2. Authentication via Digital Signature . . . . . . . . . . 8
2.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Conversion to Radix-64 . . . . . . . . . . . . . . . . . 9 2.4. Conversion to Radix-64 . . . . . . . . . . . . . . . . . 9
2.5. Signature-Only Applications . . . . . . . . . . . . . . . 9 2.5. Signature-Only Applications . . . . . . . . . . . . . . . 9
3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 9 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 9
3.1. Scalar Numbers . . . . . . . . . . . . . . . . . . . . . 9 3.1. Scalar Numbers . . . . . . . . . . . . . . . . . . . . . 9
3.2. Multiprecision Integers . . . . . . . . . . . . . . . . . 9 3.2. Multiprecision Integers . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 6 skipping to change at page 3, line 6
4.2.2.2. Two-Octet Lengths . . . . . . . . . . . . . . . . 16 4.2.2.2. Two-Octet Lengths . . . . . . . . . . . . . . . . 16
4.2.2.3. Five-Octet Lengths . . . . . . . . . . . . . . . 16 4.2.2.3. Five-Octet Lengths . . . . . . . . . . . . . . . 16
4.2.2.4. Partial Body Lengths . . . . . . . . . . . . . . 17 4.2.2.4. Partial Body Lengths . . . . . . . . . . . . . . 17
4.2.3. Packet Length Examples . . . . . . . . . . . . . . . 17 4.2.3. Packet Length Examples . . . . . . . . . . . . . . . 17
4.3. Packet Tags . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Packet Tags . . . . . . . . . . . . . . . . . . . . . . . 18
5. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Public-Key Encrypted Session Key Packets (Tag 1) . . . . 20 5.1. Public-Key Encrypted Session Key Packets (Tag 1) . . . . 20
5.2. Signature Packet (Tag 2) . . . . . . . . . . . . . . . . 21 5.2. Signature Packet (Tag 2) . . . . . . . . . . . . . . . . 21
5.2.1. Signature Types . . . . . . . . . . . . . . . . . . . 21 5.2.1. Signature Types . . . . . . . . . . . . . . . . . . . 21
5.2.2. Version 3 Signature Packet Format . . . . . . . . . . 24 5.2.2. Version 3 Signature Packet Format . . . . . . . . . . 24
5.2.3. Version 4 Signature Packet Format . . . . . . . . . . 27 5.2.3. Version 4 and 5 Signature Packet Formats . . . . . . 27
5.2.3.1. Signature Subpacket Specification . . . . . . . . 29 5.2.3.1. Signature Subpacket Specification . . . . . . . . 29
5.2.3.2. Signature Subpacket Types . . . . . . . . . . . . 31 5.2.3.2. Signature Subpacket Types . . . . . . . . . . . . 32
5.2.3.3. Notes on Self-Signatures . . . . . . . . . . . . 32 5.2.3.3. Notes on Self-Signatures . . . . . . . . . . . . 32
5.2.3.4. Signature Creation Time . . . . . . . . . . . . . 33 5.2.3.4. Signature Creation Time . . . . . . . . . . . . . 33
5.2.3.5. Issuer . . . . . . . . . . . . . . . . . . . . . 33 5.2.3.5. Issuer . . . . . . . . . . . . . . . . . . . . . 34
5.2.3.6. Key Expiration Time . . . . . . . . . . . . . . . 33 5.2.3.6. Key Expiration Time . . . . . . . . . . . . . . . 34
5.2.3.7. Preferred Symmetric Algorithms . . . . . . . . . 33 5.2.3.7. Preferred Symmetric Algorithms . . . . . . . . . 34
5.2.3.8. Preferred Hash Algorithms . . . . . . . . . . . . 33 5.2.3.8. Preferred Hash Algorithms . . . . . . . . . . . . 34
5.2.3.9. Preferred Compression Algorithms . . . . . . . . 34 5.2.3.9. Preferred Compression Algorithms . . . . . . . . 34
5.2.3.10. Signature Expiration Time . . . . . . . . . . . . 34 5.2.3.10. Signature Expiration Time . . . . . . . . . . . . 35
5.2.3.11. Exportable Certification . . . . . . . . . . . . 34 5.2.3.11. Exportable Certification . . . . . . . . . . . . 35
5.2.3.12. Revocable . . . . . . . . . . . . . . . . . . . . 35 5.2.3.12. Revocable . . . . . . . . . . . . . . . . . . . . 35
5.2.3.13. Trust Signature . . . . . . . . . . . . . . . . . 35 5.2.3.13. Trust Signature . . . . . . . . . . . . . . . . . 36
5.2.3.14. Regular Expression . . . . . . . . . . . . . . . 35 5.2.3.14. Regular Expression . . . . . . . . . . . . . . . 36
5.2.3.15. Revocation Key . . . . . . . . . . . . . . . . . 36 5.2.3.15. Revocation Key . . . . . . . . . . . . . . . . . 36
5.2.3.16. Notation Data . . . . . . . . . . . . . . . . . . 36 5.2.3.16. Notation Data . . . . . . . . . . . . . . . . . . 37
5.2.3.17. Key Server Preferences . . . . . . . . . . . . . 37 5.2.3.17. Key Server Preferences . . . . . . . . . . . . . 38
5.2.3.18. Preferred Key Server . . . . . . . . . . . . . . 38 5.2.3.18. Preferred Key Server . . . . . . . . . . . . . . 38
5.2.3.19. Primary User ID . . . . . . . . . . . . . . . . . 38 5.2.3.19. Primary User ID . . . . . . . . . . . . . . . . . 38
5.2.3.20. Policy URI . . . . . . . . . . . . . . . . . . . 38 5.2.3.20. Policy URI . . . . . . . . . . . . . . . . . . . 39
5.2.3.21. Key Flags . . . . . . . . . . . . . . . . . . . . 39 5.2.3.21. Key Flags . . . . . . . . . . . . . . . . . . . . 39
5.2.3.22. Signer's User ID . . . . . . . . . . . . . . . . 40 5.2.3.22. Signer's User ID . . . . . . . . . . . . . . . . 41
5.2.3.23. Reason for Revocation . . . . . . . . . . . . . . 40 5.2.3.23. Reason for Revocation . . . . . . . . . . . . . . 41
5.2.3.24. Features . . . . . . . . . . . . . . . . . . . . 42 5.2.3.24. Features . . . . . . . . . . . . . . . . . . . . 43
5.2.3.25. Signature Target . . . . . . . . . . . . . . . . 42 5.2.3.25. Signature Target . . . . . . . . . . . . . . . . 43
5.2.3.26. Embedded Signature . . . . . . . . . . . . . . . 43 5.2.3.26. Embedded Signature . . . . . . . . . . . . . . . 44
5.2.4. Computing Signatures . . . . . . . . . . . . . . . . 43 5.2.3.27. Issuer Fingerprint . . . . . . . . . . . . . . . 44
5.2.4.1. Subpacket Hints . . . . . . . . . . . . . . . . . 45 5.2.4. Computing Signatures . . . . . . . . . . . . . . . . 44
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) . . . 45 5.2.4.1. Subpacket Hints . . . . . . . . . . . . . . . . . 47
5.4. One-Pass Signature Packets (Tag 4) . . . . . . . . . . . 46 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) . . . 47
5.5. Key Material Packet . . . . . . . . . . . . . . . . . . . 47 5.4. One-Pass Signature Packets (Tag 4) . . . . . . . . . . . 48
5.5.1. Key Packet Variants . . . . . . . . . . . . . . . . . 47 5.5. Key Material Packet . . . . . . . . . . . . . . . . . . . 49
5.5.1.1. Public-Key Packet (Tag 6) . . . . . . . . . . . . 47 5.5.1. Key Packet Variants . . . . . . . . . . . . . . . . . 49
5.5.1.2. Public-Subkey Packet (Tag 14) . . . . . . . . . . 47 5.5.1.1. Public-Key Packet (Tag 6) . . . . . . . . . . . . 49
5.5.1.3. Secret-Key Packet (Tag 5) . . . . . . . . . . . . 47 5.5.1.2. Public-Subkey Packet (Tag 14) . . . . . . . . . . 49
5.5.1.4. Secret-Subkey Packet (Tag 7) . . . . . . . . . . 48 5.5.1.3. Secret-Key Packet (Tag 5) . . . . . . . . . . . . 49
5.5.2. Public-Key Packet Formats . . . . . . . . . . . . . . 48 5.5.1.4. Secret-Subkey Packet (Tag 7) . . . . . . . . . . 50
5.5.3. Secret-Key Packet Formats . . . . . . . . . . . . . . 49 5.5.2. Public-Key Packet Formats . . . . . . . . . . . . . . 50
5.6. Algorithm-specific Parts of Keys . . . . . . . . . . . . 50 5.5.3. Secret-Key Packet Formats . . . . . . . . . . . . . . 51
5.6.1. Algorithm-Specific Part for RSA Keys . . . . . . . . 51 5.6. Algorithm-specific Parts of Keys . . . . . . . . . . . . 53
5.6.2. Algorithm-Specific Part for DSA Keys . . . . . . . . 51 5.6.1. Algorithm-Specific Part for RSA Keys . . . . . . . . 53
5.6.3. Algorithm-Specific Part for Elgamal Keys . . . . . . 51 5.6.2. Algorithm-Specific Part for DSA Keys . . . . . . . . 54
5.6.4. Algorithm-Specific Part for ECDSA Keys . . . . . . . 52 5.6.3. Algorithm-Specific Part for Elgamal Keys . . . . . . 54
5.6.5. Algorithm-Specific Part for ECDH Keys . . . . . . . . 52 5.6.4. Algorithm-Specific Part for ECDSA Keys . . . . . . . 54
5.7. Compressed Data Packet (Tag 8) . . . . . . . . . . . . . 53 5.6.5. Algorithm-Specific Part for EdDSA Keys . . . . . . . 55
5.8. Symmetrically Encrypted Data Packet (Tag 9) . . . . . . . 53 5.6.6. Algorithm-Specific Part for ECDH Keys . . . . . . . . 55
5.9. Marker Packet (Obsolete Literal Packet) (Tag 10) . . . . 54 5.7. Compressed Data Packet (Tag 8) . . . . . . . . . . . . . 56
5.10. Literal Data Packet (Tag 11) . . . . . . . . . . . . . . 55 5.8. Symmetrically Encrypted Data Packet (Tag 9) . . . . . . . 57
5.11. Trust Packet (Tag 12) . . . . . . . . . . . . . . . . . . 56 5.9. Marker Packet (Obsolete Literal Packet) (Tag 10) . . . . 58
5.12. User ID Packet (Tag 13) . . . . . . . . . . . . . . . . . 56 5.10. Literal Data Packet (Tag 11) . . . . . . . . . . . . . . 58
5.13. User Attribute Packet (Tag 17) . . . . . . . . . . . . . 56 5.11. Trust Packet (Tag 12) . . . . . . . . . . . . . . . . . . 59
5.13.1. The Image Attribute Subpacket . . . . . . . . . . . 57 5.12. User ID Packet (Tag 13) . . . . . . . . . . . . . . . . . 59
5.13. User Attribute Packet (Tag 17) . . . . . . . . . . . . . 59
5.13.1. The Image Attribute Subpacket . . . . . . . . . . . 60
5.14. Sym. Encrypted Integrity Protected Data Packet (Tag 5.14. Sym. Encrypted Integrity Protected Data Packet (Tag
18) . . . . . . . . . . . . . . . . . . . . . . . . . . 58 18) . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.15. Modification Detection Code Packet (Tag 19) . . . . . . . 61 5.15. Modification Detection Code Packet (Tag 19) . . . . . . . 64
6. Radix-64 Conversions . . . . . . . . . . . . . . . . . . . . 61 6. Radix-64 Conversions . . . . . . . . . . . . . . . . . . . . 65
6.1. An Implementation of the CRC-24 in "C" . . . . . . . . . 62 6.1. An Implementation of the CRC-24 in "C" . . . . . . . . . 65
6.2. Forming ASCII Armor . . . . . . . . . . . . . . . . . . . 63 6.2. Forming ASCII Armor . . . . . . . . . . . . . . . . . . . 66
6.3. Encoding Binary in Radix-64 . . . . . . . . . . . . . . . 65 6.3. Encoding Binary in Radix-64 . . . . . . . . . . . . . . . 69
6.4. Decoding Radix-64 . . . . . . . . . . . . . . . . . . . . 68 6.4. Decoding Radix-64 . . . . . . . . . . . . . . . . . . . . 71
6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 68 6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 71
6.6. Example of an ASCII Armored Message . . . . . . . . . . . 69 6.6. Example of an ASCII Armored Message . . . . . . . . . . . 72
7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 69 7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 72
7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 70 7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 73
8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 71 8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 74
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 71 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 74
9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 72 9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 75
9.2. ECC Curve OID . . . . . . . . . . . . . . . . . . . . . . 73 9.2. ECC Curve OID . . . . . . . . . . . . . . . . . . . . . . 76
9.3. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 73 9.3. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 76
9.4. Compression Algorithms . . . . . . . . . . . . . . . . . 74 9.4. Compression Algorithms . . . . . . . . . . . . . . . . . 77
9.5. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 75 9.5. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 78
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
10.1. New String-to-Key Specifier Types . . . . . . . . . . . 76 10.1. New String-to-Key Specifier Types . . . . . . . . . . . 79
10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 76 10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 79
10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 76 10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 79
10.2.1.1. Image Format Subpacket Types . . . . . . . . . . 76 10.2.1.1. Image Format Subpacket Types . . . . . . . . . . 79
10.2.2. New Signature Subpackets . . . . . . . . . . . . . . 77 10.2.2. New Signature Subpackets . . . . . . . . . . . . . . 80
10.2.2.1. Signature Notation Data Subpackets . . . . . . . 77 10.2.2.1. Signature Notation Data Subpackets . . . . . . . 80
10.2.2.2. Signature Notation Data Subpacket Notation 10.2.2.2. Signature Notation Data Subpacket Notation
Flags . . . . . . . . . . . . . . . . . . . . . . . 77 Flags . . . . . . . . . . . . . . . . . . . . . . . 80
10.2.2.3. Key Server Preference Extensions . . . . . . . . 77 10.2.2.3. Key Server Preference Extensions . . . . . . . . 81
10.2.2.4. Key Flags Extensions . . . . . . . . . . . . . . 78 10.2.2.4. Key Flags Extensions . . . . . . . . . . . . . . 81
10.2.2.5. Reason for Revocation Extensions . . . . . . . . 78 10.2.2.5. Reason for Revocation Extensions . . . . . . . . 81
10.2.2.6. Implementation Features . . . . . . . . . . . . 78 10.2.2.6. Implementation Features . . . . . . . . . . . . 81
10.2.3. New Packet Versions . . . . . . . . . . . . . . . . 78 10.2.3. New Packet Versions . . . . . . . . . . . . . . . . 82
10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 79 10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 82
10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 79 10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 82
10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 79 10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 83
10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 79 10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 83
10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 80 10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 84
11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 80 11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 84
11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 80 11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 84
11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 82 11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 85
11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 82 11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 86
11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 83 11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 86
12. Enhanced Key Formats . . . . . . . . . . . . . . . . . . . . 83 12. Enhanced Key Formats . . . . . . . . . . . . . . . . . . . . 86
12.1. Key Structures . . . . . . . . . . . . . . . . . . . . . 83 12.1. Key Structures . . . . . . . . . . . . . . . . . . . . . 87
12.2. Key IDs and Fingerprints . . . . . . . . . . . . . . . . 84 12.2. Key IDs and Fingerprints . . . . . . . . . . . . . . . . 88
13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 85 13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 89
13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 85 13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 89
13.2. ECDSA and ECDH Conversion Primitives . . . . . . . . . . 86 13.2. ECDSA and ECDH Conversion Primitives . . . . . . . . . . 90
13.3. Key Derivation Function . . . . . . . . . . . . . . . . 86 13.3. EdDSA Point Format . . . . . . . . . . . . . . . . . . . 91
13.4. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 87 13.4. Key Derivation Function . . . . . . . . . . . . . . . . 91
14. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 90 13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 91
14.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 90 14. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 94
14.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 90 14.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 94
14.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 91 14.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 94
14.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 91 14.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 95
14.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 92 14.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 96
14.3. Other Algorithm Preferences . . . . . . . . . . . . . . 93 14.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 97
14.3.1. Compression Preferences . . . . . . . . . . . . . . 93 14.3. Other Algorithm Preferences . . . . . . . . . . . . . . 97
14.3.2. Hash Algorithm Preferences . . . . . . . . . . . . . 94 14.3.1. Compression Preferences . . . . . . . . . . . . . . 98
14.4. Plaintext . . . . . . . . . . . . . . . . . . . . . . . 94 14.3.2. Hash Algorithm Preferences . . . . . . . . . . . . . 98
14.5. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 94 14.4. Plaintext . . . . . . . . . . . . . . . . . . . . . . . 98
14.6. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . 95 14.5. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 99
14.7. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 95 14.6. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . 99
14.8. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 95 14.7. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 99
14.9. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 96 14.8. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 100
14.10. Private or Experimental Parameters . . . . . . . . . . . 97 14.9. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 100
14.11. Extension of the MDC System . . . . . . . . . . . . . . 97 14.10. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 100
14.12. Meta-Considerations for Expansion . . . . . . . . . . . 98 14.11. Private or Experimental Parameters . . . . . . . . . . . 102
15. Security Considerations . . . . . . . . . . . . . . . . . . . 99 14.12. Extension of the MDC System . . . . . . . . . . . . . . 102
16. Compatibility Profiles . . . . . . . . . . . . . . . . . . . 105 14.13. Meta-Considerations for Expansion . . . . . . . . . . . 103
16.1. OpenPGP ECC Profile . . . . . . . . . . . . . . . . . . 105 15. Security Considerations . . . . . . . . . . . . . . . . . . . 103
16.2. Suite-B Profile . . . . . . . . . . . . . . . . . . . . 105 16. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 109
16.2.1. Security Strength at 192 Bits . . . . . . . . . . . 106 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 111
16.2.2. Security Strength at 128 Bits . . . . . . . . . . . 106 17.1. Normative References . . . . . . . . . . . . . . . . . . 111
17. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 106 17.2. Informative References . . . . . . . . . . . . . . . . . 114
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 115
18.1. Normative References . . . . . . . . . . . . . . . . . . 107 A.1. Sample EdDSA key . . . . . . . . . . . . . . . . . . . . 115
18.2. Informative References . . . . . . . . . . . . . . . . . 110 A.2. Sample EdDSA signature . . . . . . . . . . . . . . . . . 116
Appendix A. Document Workflow . . . . . . . . . . . . . . . . . 111 Appendix B. Document Workflow . . . . . . . . . . . . . . . . . 116
Appendix B. ECC Point compression flag bytes . . . . . . . . . . 112 Appendix C. ECC Point compression flag bytes . . . . . . . . . . 117
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 112 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 117
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117
1. Introduction 1. Introduction
{ This is work in progress to update OpenPGP. Editorial notes are { This is work in progress to update OpenPGP. Editorial notes are
enclosed in curly braces. } enclosed in curly braces. }
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].
This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia
cipher) and RFC 6637 (ECC for OpenPGP). cipher) and RFC 6637 (ECC for OpenPGP).
skipping to change at page 13, line 32 skipping to change at page 13, line 32
Then the salt, followed by the passphrase data, is repeatedly hashed Then the salt, followed by the passphrase data, is repeatedly hashed
until the number of octets specified by the octet count has been until the number of octets specified by the octet count has been
hashed. The one exception is that if the octet count is less than hashed. The one exception is that if the octet count is less than
the size of the salt plus passphrase, the full salt plus passphrase the size of the salt plus passphrase, the full salt plus passphrase
will be hashed even though that is greater than the octet count. will be hashed even though that is greater than the octet count.
After the hashing is done, the data is unloaded from the hash After the hashing is done, the data is unloaded from the hash
context(s) as with the other S2K algorithms. context(s) as with the other S2K algorithms.
3.7.2. String-to-Key Usage 3.7.2. String-to-Key Usage
Implementations SHOULD use salted or iterated-and-salted S2K Simple S2K and Salted S2K specifiers are not particularly secure when
specifiers, as simple S2K specifiers are more vulnerable to used with a low-entropy secret, such as those typically provided by
dictionary attacks. users. Implementations SHOULD NOT use these methods on encryption of
either keys and messages.
3.7.2.1. Secret-Key Encryption 3.7.2.1. Secret-Key Encryption
An S2K specifier can be stored in the secret keyring to specify how An S2K specifier can be stored in the secret keyring to specify how
to convert the passphrase to a key that unlocks the secret data. to convert the passphrase to a key that unlocks the secret data.
Older versions of PGP just stored a cipher algorithm octet preceding Older versions of PGP just stored a cipher algorithm octet preceding
the secret data or a zero to indicate that the secret data was the secret data or a zero to indicate that the secret data was
unencrypted. The MD5 hash function was always used to convert the unencrypted. The MD5 hash function was always used to convert the
passphrase to a key for the specified cipher algorithm. passphrase to a key for the specified cipher algorithm.
skipping to change at page 20, line 50 skipping to change at page 20, line 50
- 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.
Algorithm-Specific Fields for ECDH encryption: Algorithm-Specific Fields for ECDH encryption:
- MPI of an EC point representing an ephemeral public key. - MPI of an EC point representing an ephemeral public key.
- 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.4. method described in Section 13.5.
The value "m" in the above formulas is derived from the session key The value "m" in the above formulas is derived from the session key
as follows. First, the session key is prefixed with a one-octet as follows. First, the session key is prefixed with a one-octet
algorithm identifier that specifies the symmetric encryption algorithm identifier that specifies the symmetric encryption
algorithm used to encrypt the following Symmetrically Encrypted Data algorithm used to encrypt the following Symmetrically Encrypted Data
Packet. Then a two-octet checksum is appended, which is equal to the Packet. Then a two-octet checksum is appended, which is equal to the
sum of the preceding session key octets, not including the algorithm sum of the preceding session key octets, not including the algorithm
identifier, modulo 65536. This value is then encoded as described in identifier, modulo 65536. This value is then encoded as described in
PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to
form the "m" value used in the formulas above. See Section 14.1 in form the "m" value used in the formulas above. See Section 14.1 in
skipping to change at page 21, line 31 skipping to change at page 21, line 31
or "speculative" Key ID. In this case, the receiving implementation or "speculative" Key ID. In this case, the receiving implementation
would try all available private keys, checking for a valid decrypted would try all available private keys, checking for a valid decrypted
session key. This format helps reduce traffic analysis of messages. session key. This format helps reduce traffic analysis of messages.
5.2. Signature Packet (Tag 2) 5.2. Signature Packet (Tag 2)
A Signature packet describes a binding between some public key and A Signature packet describes a binding between some public key and
some data. The most common signatures are a signature of a file or a some data. The most common signatures are a signature of a file or a
block of text, and a signature that is a certification of a User ID. block of text, and a signature that is a certification of a User ID.
Two versions of Signature packets are defined. Version 3 provides Three versions of Signature packets are defined. Version 3 provides
basic signature information, while version 4 provides an expandable basic signature information, while versions 4 and 5 provide an
format with subpackets that can specify more information about the expandable format with subpackets that can specify more information
signature. PGP 2.6.x only accepts version 3 signatures. about the signature. PGP 2.6.x only accepts version 3 signatures.
Implementations SHOULD generate V4 signatures. Implementations MUST Implementations MUST generate version 5 signatures when using a
NOT create version 3 signatures; they MAY accept version 3 version 5 key. Implementations SHOULD generate V4 signatures with
signatures. version 4 keys. Implementations MUST NOT create version 3
signatures; they MAY accept version 3 signatures.
5.2.1. Signature Types 5.2.1. Signature Types
There are a number of possible meanings for a signature, which are There are a number of possible meanings for a signature, which are
indicated in a signature type octet in any given signature. Please indicated in a signature type octet in any given signature. Please
note that the vagueness of these meanings is not a flaw, but a note that the vagueness of these meanings is not a flaw, but a
feature of the system. Because OpenPGP places final authority for feature of the system. Because OpenPGP places final authority for
validity upon the receiver of a signature, it may be that one validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other signer's casual act might be more rigorous than some other
authority's positive act. See Section 5.2.4 for detailed information authority's positive act. See Section 5.2.4 for detailed information
skipping to change at page 27, line 48 skipping to change at page 27, line 48
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 Signature Packet Format 5.2.3. Version 4 and 5 Signature Packet Formats
The body of a version 4 Signature packet contains: The body of a V4 or V5 Signature packet contains:
* One-octet version number (4). * One-octet version number. This is 4 for V4 signatures and 5 for
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.
* Two-octet scalar octet count for following hashed subpacket data. * Two-octet scalar octet count for following hashed subpacket data.
Note that this is the length in octets of all of the hashed Note that this is the length in octets of all of the hashed
subpackets; a pointer incremented by this number will skip over subpackets; a pointer incremented by this number will skip over
skipping to change at page 28, line 40 skipping to change at page 28, line 43
Algorithm-Specific Fields for RSA signatures: 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.
Algorithm-Specific Fields for DSA or ECDSA signatures: 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.
Algorithm-Specific Fields for EdDSA signatures:
- MPI of an EC point r.
- EdDSA value s, in MPI, in the little endian representation.
The format of R and S for use with EdDSA is described in [RFC8032].
A version 3 signature MUST NOT be created and MUST NOT be used with
EdDSA.
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 difference between a V4 and V5 signature is that the latter
includes additional meta data.
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 a section below. are described in a section below.
5.2.3.1. Signature Subpacket Specification 5.2.3.1. 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 scalar count of the length in octets of all the subpackets. A octet scalar count of the length in octets of all the subpackets. A
pointer incremented by this number will skip over the subpacket data pointer incremented by this number will skip over the subpacket data
set. set.
skipping to change at page 31, line 7 skipping to change at page 31, line 31
| 28 | Signer's User ID | | 28 | Signer's User ID |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 29 | Reason for Revocation | | 29 | Reason for Revocation |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 30 | Features | | 30 | Features |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 31 | Signature Target | | 31 | Signature Target |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 32 | Embedded Signature | | 32 | Embedded Signature |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 33 | Reserved (Issuer Fingerprint) | | 33 | Issuer Fingerprint |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 34 | Reserved (Preferred AEAD Algorithms) | | 34 | Reserved (Preferred AEAD Algorithms) |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 35 | Reserved (Intended Recipient Fingerprint) | | 35 | Reserved (Intended Recipient Fingerprint) |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 37 | Reserved (Attested Certifications) | | 37 | Reserved (Attested Certifications) |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 38 | Reserved (Key Block) | | 38 | Reserved (Key Block) |
+------------+-------------------------------------------+ +------------+-------------------------------------------+
| 100 to 110 | Private or experimental | | 100 to 110 | Private or experimental |
skipping to change at page 32, line 27 skipping to change at page 33, line 8
signature, and thus different subpackets in those self-signatures. signature, and thus different subpackets in those self-signatures.
For subkey binding signatures, each subkey in fact has a self- For subkey binding signatures, each subkey in fact has a self-
signature. Subpackets that appear in a certification self-signature signature. Subpackets that appear in a certification self-signature
apply to the user name, and subpackets that appear in the subkey apply to the user name, and subpackets that appear in the subkey
self-signature apply to the subkey. Lastly, subpackets on the self-signature apply to the subkey. Lastly, subpackets on the
direct-key signature apply to the entire key. direct-key signature apply to the entire key.
Implementing software should interpret a self-signature's preference Implementing software should interpret a self-signature's preference
subpackets as narrowly as possible. For example, suppose a key has subpackets as narrowly as possible. For example, suppose a key has
two user names, Alice and Bob. Suppose that Alice prefers the two user names, Alice and Bob. Suppose that Alice prefers the
symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the symmetric algorithm AES-256, and Bob prefers Camellia-256 or AES-128.
software locates this key via Alice's name, then the preferred If the software locates this key via Alice's name, then the preferred
algorithm is CAST5; if software locates the key via Bob's name, then algorithm is AES-256; if software locates the key via Bob's name,
the preferred algorithm is IDEA. If the key is located by Key ID, then the preferred algorithm is Camellia-256. If the key is located
the algorithm of the primary User ID of the key provides the by Key ID, the algorithm of the primary User ID of the key provides
preferred symmetric algorithm. the preferred symmetric algorithm.
Revoking a self-signature or allowing it to expire has a semantic Revoking a self-signature or allowing it to expire has a semantic
meaning that varies with the signature type. Revoking the self- meaning that varies with the signature type. Revoking the self-
signature on a User ID effectively retires that user name. The self- signature on a User ID effectively retires that user name. The self-
signature is a statement, "My name X is tied to my signing key K" and signature is a statement, "My name X is tied to my signing key K" and
is corroborated by other users' certifications. If another user is corroborated by other users' certifications. If another user
revokes their certification, they are effectively saying that they no revokes their certification, they are effectively saying that they no
longer believe that name and that key are tied together. Similarly, longer believe that name and that key are tied together. Similarly,
if the users themselves revoke their self-signature, then the users if the users themselves revoke their self-signature, then the users
no longer go by that name, no longer have that email address, etc. no longer go by that name, no longer have that email address, etc.
skipping to change at page 33, line 26 skipping to change at page 34, line 9
(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.5. Issuer 5.2.3.5. Issuer
(8-octet Key ID) (8-octet Key ID)
The OpenPGP Key ID of the key issuing the signature. 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
the signature.
5.2.3.6. Key Expiration Time 5.2.3.6. 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. If this is not present the key creation time that the key expires. If this is not present
or has a value of zero, the key never expires. This is found only on or has a value of zero, the key never expires. This is found only on
a self-signature. a self-signature.
skipping to change at page 36, line 4 skipping to change at page 36, line 25
it is a "meta introducer". Generally, a level n trust signature it is a "meta introducer". Generally, a level n trust signature
asserts that a key is trusted to issue level n-1 trust signatures. asserts that a key is trusted to issue level n-1 trust signatures.
The trust amount is in a range from 0-255, interpreted such that The trust amount is in a range from 0-255, interpreted such that
values less than 120 indicate partial trust and values of 120 or values less than 120 indicate partial trust and values of 120 or
greater indicate complete trust. Implementations SHOULD emit values greater indicate complete trust. Implementations SHOULD emit values
of 60 for partial trust and 120 for complete trust. of 60 for partial trust and 120 for complete trust.
5.2.3.14. Regular Expression 5.2.3.14. Regular Expression
(null-terminated regular expression) (null-terminated regular expression)
Used in conjunction with trust Signature packets (of level > 0) to Used in conjunction with trust Signature packets (of level > 0) to
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.15. Revocation Key 5.2.3.15. 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 or 32
fingerprint) octets of fingerprint)
V4 keys use the full 20 octet fingerprint; V5 keys use the full 32
octet fingerprint
Authorizes the specified key to issue revocation signatures for this Authorizes the specified key to issue revocation signatures for this
key. Class octet must have bit 0x80 set. If the bit 0x40 is set, key. Class octet must have bit 0x80 set. If the bit 0x40 is set,
then this means that the revocation information is sensitive. Other then this means that the revocation information is sensitive. Other
bits are for future expansion to other kinds of authorizations. This bits are for future expansion to other kinds of authorizations. This
is found on a self-signature. is only found on a direct-key self-signature (type 0x1f). The use on
other types of self-signatures is unspecified.
If the "sensitive" flag is set, the keyholder feels this subpacket If the "sensitive" flag is set, the keyholder feels this subpacket
contains private trust information that describes a real-world contains private trust information that describes a real-world
sensitive relationship. If this flag is set, implementations SHOULD sensitive relationship. If this flag is set, implementations SHOULD
NOT export this signature to other users except in cases where the NOT export this signature to other users except in cases where the
data needs to be available: when the signature is being sent to the data needs to be available: when the signature is being sent to the
designated revoker, or when it is accompanied by a revocation designated revoker, or when it is accompanied by a revocation
signature from that revoker. Note that it may be appropriate to signature from that revoker. Note that it may be appropriate to
isolate this subpacket within a separate signature so that it is not isolate this subpacket within a separate signature so that it is not
combined with other subpackets that need to be exported. combined with other subpackets that need to be exported.
skipping to change at page 42, line 32 skipping to change at page 43, line 32
First octet: First octet:
+=========+============================================+ +=========+============================================+
| feature | definition | | feature | definition |
+=========+============================================+ +=========+============================================+
| 0x01 | Modification Detection (packets 18 and 19) | | 0x01 | Modification Detection (packets 18 and 19) |
+---------+--------------------------------------------+ +---------+--------------------------------------------+
| 0x02 | Reserved (AEAD Data & v5 SKESK) | | 0x02 | Reserved (AEAD Data & v5 SKESK) |
+---------+--------------------------------------------+ +---------+--------------------------------------------+
| 0x04 | Reserved (v5 pubkey & fingerprint) | | 0x04 | Version 5 Public-Key Packet format and |
| | corresponding new fingerprint format |
+---------+--------------------------------------------+ +---------+--------------------------------------------+
Table 12: Features registry Table 12: 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.
skipping to change at page 43, line 17 skipping to change at page 44, line 17
have 20 octets of hash data. have 20 octets of hash data.
5.2.3.26. Embedded Signature 5.2.3.26. Embedded Signature
(1 signature packet body) (1 signature packet body)
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.27. Issuer Fingerprint
(1 octet key version number, N octets of fingerprint)
The OpenPGP Key fingerprint of the key issuing the signature. This
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
signature, the key ID of the Issuer 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
octets; for a version 5 key N is 32.
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.
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 document is canonicalized by converting line endings to <CR><LF>, and
the resulting data is hashed. the resulting data is hashed.
When a 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. (Note that this is an old-style packet header for of the key packet; when a V5 signature is made over a key, the hash
a key packet with two-octet length.) A subkey binding signature data starts with the octet 0x9a, followed by a four-octet length of
the key, and then body of the key packet. A subkey binding signature
(type 0x18) or primary key binding signature (type 0x19) then hashes (type 0x18) or primary key binding signature (type 0x19) then hashes
the subkey using the same format as the main key (also using 0x99 as the subkey using the same format as the main key (also using 0x99 or
the first octet). Primary key revocation signatures (type 0x20) hash 0x9a as the first octet). Primary key revocation signatures (type
only the key being revoked. Subkey revocation signature (type 0x28) 0x20) hash only the key being revoked. Subkey revocation signature
hash first the primary key and then the subkey being revoked. (type 0x28) hash first the 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 certification hashes the packet packet, without any header. A V4 or V5 certification hashes
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 an old-style the body of the Signature packet. (Note that this is an old-style
packet header for a Signature packet with the length-of-length field packet header for a Signature packet with the length-of-length field
set to zero.) The unhashed subpacket data of the Signature packet set to zero.) The unhashed subpacket data of the Signature packet
skipping to change at page 44, line 43 skipping to change at page 46, line 5
- the hashed subpacket length, - the hashed subpacket length,
- the hashed subpacket body, - the hashed subpacket body,
- the two octets 0x04 and 0xFF, - the two octets 0x04 and 0xFF,
- a four-octet big-endian number that is the length of the hashed - a four-octet big-endian number that is the length of the hashed
data from the Signature packet stopping right before the 0x04, data from the Signature packet stopping right before the 0x04,
0xff octets. 0xff octets.
The four-octet big-endian number is considered to be an
unsigned integer modulo 2^32.
* A V5 signature hashes the packet body starting from its first
field, the version number, through the end of the hashed subpacket
data and a final extra trailer. Thus, the hashed fields are:
- the signature version (0x05),
- the signature type,
- the public-key algorithm,
- the hash algorithm,
- the hashed subpacket length,
- the hashed subpacket body,
- Only for document signatures (type 0x00 or 0x01) the following
three data items are hashed here:
o the one-octet content format,
o the file name as a string (one octet length, followed by the
file name),
o a four-octet number that indicates a date,
- the two octets 0x05 and 0xFF,
- a eight-octet big-endian number that is the length of the
hashed data from the Signature packet stopping right before the
0x05, 0xff octets.
The three data items hashed for document signatures need to
mirror the values of the Literal Data packet. For detached and
cleartext signatures 6 zero bytes are hashed instead.
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
skipping to change at page 48, line 12 skipping to change at page 50, line 12
Public-Key packet, including the public-key material, but also Public-Key packet, including the public-key material, but also
includes the secret-key material after all the public-key fields. includes the secret-key material after all the public-key fields.
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 two versions of key-material packets. Version 3 packets There are three versions of key-material packets. Version 3 packets
were first generated by PGP version 2.6. Version 4 keys first were first generated by PGP version 2.6. Version 4 keys first
appeared in PGP 5 and are the preferred key version for OpenPGP. appeared in PGP 5 and are the preferred key version for OpenPGP.
OpenPGP implementations MUST create keys with version 4 format. V3 OpenPGP implementations MUST create keys with version 4 format. V3
keys are deprecated; an implementation MUST NOT generate a V3 key, keys are deprecated; an implementation MUST NOT generate a V3 key,
but MAY accept it. 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).
skipping to change at page 49, line 22 skipping to change at page 51, line 22
* 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 multiprecision integers comprising the key material. * A series of multiprecision integers comprising the key material.
This is algorithm-specific and described in Section 5.6. This is algorithm-specific and described in Section 5.6.
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
parsing secret key packets (which are an extension of the public key
packet format) in the case of an unknown algoritm. In addition,
fingerprints of version 5 keys are calculated differently from
version 4 keys, as described in the section "Enhanced Key Formats".
A version 5 packet contains:
* A one-octet version number (5).
* 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 four-octet scalar octet count for the following public key
material.
* A series of values comprising the public key material. This is
algorithm-specific and described in Section 5.6.
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:
* A Public-Key or Public-Subkey packet, as described above. * A Public-Key or Public-Subkey packet, as described 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 or 254 indicates that the secret-key data is not encrypted. 255 or 254
indicates that a string-to-key specifier is being given. Any indicates that a string-to-key specifier is being given. Any
other value is a symmetric-key encryption algorithm identifier. other value is a symmetric-key encryption algorithm identifier. A
version 5 packet MUST NOT use the value 255.
* Only for a version 5 packet, a one-octet scalar octet count of the
next 4 optional fields.
* [Optional] If string-to-key usage octet was 255 or 254, a one- * [Optional] If string-to-key usage octet was 255 or 254, a one-
octet symmetric encryption algorithm. octet symmetric encryption algorithm.
* [Optional] If string-to-key usage octet was 255 or 254, a string- * [Optional] If string-to-key usage octet was 255 or 254, a string-
to-key specifier. The length of the string-to-key specifier is to-key specifier. The length of the string-to-key specifier is
implied by its type, as described above. implied by its type, as described above.
* [Optional] If secret data is encrypted (string-to-key usage octet * [Optional] If secret data is encrypted (string-to-key usage octet
not zero), an Initial Vector (IV) of the same length as the not zero), an Initial Vector (IV) of the same length as the
cipher's block size. cipher's block size.
* Only for a version 5 packet, a four-octet scalar octet count for
the following secret key material. This includes the encrypted
SHA-1 hash or AEAD tag if the string-to-key usage octet is 254 or
253.
* 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 section key data. This is algorithm-specific and described in section
Section 5.6. Section 5.6.
* If the string-to-key usage octet is zero or 255, then a two-octet * If the string-to-key usage octet is zero or 255, then a two-octet
checksum of the plaintext of the algorithm-specific portion (sum checksum of the plaintext of the algorithm-specific portion (sum
of all octets, mod 65536). If the string-to-key usage octet was of all octets, mod 65536). If the string-to-key usage octet was
254, then a 20-octet SHA-1 hash of the plaintext of the algorithm- 254, then a 20-octet SHA-1 hash of the plaintext of the algorithm-
specific portion. This checksum or hash is encrypted together specific portion. This checksum or hash is encrypted together
with the algorithm-specific fields (if string-to-key usage octet with the algorithm-specific fields (if string-to-key usage octet
is not zero). Note that for all other values, a two-octet is not zero). Note that for all other values, a two-octet
checksum is required. checksum is required.
Note that the version 5 packet format adds two count values to help
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 in CFB mode using Encryption/decryption of the secret data is done in CFB mode using
the key created from the passphrase and the Initial Vector from the the key created from the passphrase and the Initial Vector from the
packet. A different mode is used with V3 keys (which are only RSA) packet. A different mode is used with V3 keys (which are only RSA)
than with other key formats. With V3 keys, the MPI bit count prefix than with other key formats. With V3 keys, the MPI bit count prefix
(i.e., the first two octets) is not encrypted. Only the MPI non- (i.e., 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 keys, a simpler method is used. All secret MPI values are With V4 and V5 keys, a simpler method is used. All secret MPI values
encrypted in CFB mode, including the MPI bitcount prefix. are encrypted in CFB mode, including the MPI bitcount prefix.
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
skipping to change at page 52, line 24 skipping to change at page 55, line 12
- the octets representing a curve OID, defined in Section 9.2; - the octets representing a curve OID, defined in Section 9.2;
* a MPI of an EC point representing a public key. * a 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 ECDH Keys 5.6.5. Algorithm-Specific Part for EdDSA Keys
The public key is this series of values:
* a variable-length field containing a curve OID, formatted as
follows:
- a one-octet size of the following field; values 0 and 0xFF are
reserved for future extensions,
- the octets representing a curve OID, defined in Section 9.2;
* a MPI of an EC point representing a public key Q as described
under EdDSA Point Format below.
The secret key is this single multiprecision integer:
* MPI of an integer representing the secret key, which is a scalar
of the public EC point.
5.6.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, 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;
skipping to change at page 52, line 45 skipping to change at page 56, line 4
* a MPI of an EC point representing a public key; * a MPI of an EC point representing a public key;
* a variable-length field containing KDF parameters, formatted as * a variable-length field containing KDF parameters, formatted as
follows: 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 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.4 for details. Section 13.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:
* 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.7. Compressed Data Packet (Tag 8) 5.7. Compressed Data Packet (Tag 8)
skipping to change at page 56, line 9 skipping to change at page 59, line 16
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 (i.e., network- Text data is stored with <CR><LF> text endings (i.e., network-
normal line endings). These should be converted to native line normal line endings). These should be converted to native line
endings by the receiving software. endings by the receiving software.
Note that V3 and V4 signatures do not include the formatting octet,
the file name, and the date field of the literal packet in a
signature hash and thus are not protected against tampering in a
signed document. In contrast V5 signatures include them.
5.11. Trust Packet (Tag 12) 5.11. 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
skipping to change at page 59, line 17 skipping to change at page 62, line 39
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 14.10 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.
The plaintext of the data to be encrypted is passed through the SHA-1 The plaintext of the data to be encrypted is passed through the SHA-1
hash function, and the result of the hash is appended to the hash function, and the result of the hash is appended to the
plaintext in a Modification Detection Code packet. The input to the plaintext in a Modification Detection Code packet. The input to the
hash function includes the prefix data described above; it includes hash function includes the prefix data described above; it includes
all of the plaintext, and then also includes two octets of values all of the plaintext, and then also includes two octets of values
skipping to change at page 61, line 4 skipping to change at page 64, line 21
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 RIPE-
MD/160, for example.) MD/160, for example.)
However, given the present state of hash function cryptanalysis However, given the present state of hash function cryptanalysis
and cryptography, it may be desirable to upgrade the MDC system to and cryptography, it may be desirable to upgrade the MDC system to
a new hash function. See Section 14.11 for guidance. a new hash function. See Section 14.12 for guidance.
5.15. Modification Detection Code Packet (Tag 19) 5.15. Modification Detection Code Packet (Tag 19)
The Modification Detection Code packet contains a SHA-1 hash of The Modification Detection Code packet contains a SHA-1 hash of
plaintext data, which is used to detect message modification. It is plaintext data, which is used to detect message modification. It is
only used with a Symmetrically Encrypted Integrity Protected Data only used with a Symmetrically Encrypted Integrity Protected Data
packet. The Modification Detection Code packet MUST be the last packet. The Modification Detection Code packet MUST be the last
packet in the plaintext data that is encrypted in the Symmetrically packet in the plaintext data that is encrypted in the Symmetrically
Encrypted Integrity Protected Data packet, and MUST appear in no Encrypted Integrity Protected Data packet, and MUST appear in no
other place. other place.
skipping to change at page 62, line 12 skipping to change at page 65, line 26
systems desire these objects to be immune to damage caused by systems desire these objects to be immune to damage caused by
character set translation, data conversions, etc. character set translation, data conversions, etc.
In principle, any printable encoding scheme that met the requirements In principle, any printable encoding scheme that met the requirements
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 a checksum. The base64 encoding is encoding of the binary data and an optional checksum. The base64
identical to the MIME base64 content-transfer-encoding [RFC2045]. encoding is identical to the MIME base64 content-transfer-encoding
[RFC2045].
The checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to The optional checksum is a 24-bit Cyclic Redundancy Check (CRC)
four characters of radix-64 encoding by the same MIME base64 converted to four characters of radix-64 encoding by the same MIME
transformation, preceded by an equal sign (=). The CRC is computed base64 transformation, preceded by an equal sign (=). The CRC is
by using the generator 0x864CFB and an initialization of 0xB704CE. computed by using the generator 0x864CFB and an initialization of
The accumulation is done on the data before it is converted to radix- 0xB704CE. The accumulation is done on the data before it is
64, rather than on the converted data. A sample implementation of converted to radix-64, rather than on the converted data. A sample
this algorithm is in the next section. implementation of this algorithm is in the next section.
The checksum with its leading equal sign MAY appear on the first line If present, the checksum with its leading equal sign MUST appear on
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 Rationale for CRC-24: The size of 24 bits fits evenly into printable
base64. The nonzero initialization can detect more errors than a base64. The nonzero initialization can detect more errors than a
zero initialization. zero initialization.
6.1. An Implementation of the CRC-24 in "C" 6.1. An Implementation of the CRC-24 in "C"
#define CRC24_INIT 0xB704CEL #define CRC24_INIT 0xB704CEL
#define CRC24_POLY 0x1864CFBL #define CRC24_GENERATOR 0x864CFBL
typedef 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--) {
crc ^= (*octets++) << 16; crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) { for (i = 0; i < 8; i++) {
crc <<= 1; crc <<= 1;
if (crc & 0x1000000) if (crc & 0x1000000) {
crc ^= CRC24_POLY; crc &= 0xffffff; /* Clear bit 25 to avoid overflow */
crc ^= CRC24_GENERATOR;
}
} }
} }
return crc & 0xFFFFFFL; return crc & 0xFFFFFFL;
} }
6.2. Forming ASCII Armor 6.2. Forming ASCII Armor
When OpenPGP encodes data into ASCII Armor, it puts specific headers When OpenPGP encodes data into ASCII Armor, it puts specific headers
around the Radix-64 encoded data, so OpenPGP can reconstruct the data around the Radix-64 encoded data, so OpenPGP can reconstruct the data
later. An OpenPGP implementation MAY use ASCII armor to protect raw later. An OpenPGP implementation MAY use ASCII armor to protect raw
skipping to change at page 72, line 31 skipping to change at page 75, line 31
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 18 | ECDH public key algorithm | | 18 | ECDH public key algorithm |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 19 | ECDSA public key algorithm [FIPS186] | | 19 | ECDSA public key algorithm [FIPS186] |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 20 | Reserved (formerly Elgamal Encrypt or Sign) | | 20 | Reserved (formerly Elgamal Encrypt or Sign) |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 21 | Reserved for Diffie-Hellman (X9.42, as defined | | 21 | Reserved for Diffie-Hellman (X9.42, as defined |
| | for IETF-S/MIME) | | | for IETF-S/MIME) |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 22 | Reserved (EdDSA) | | 22 | EdDSA [RFC8032] |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 23 | Reserved (AEDH) | | 23 | Reserved (AEDH) |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 24 | Reserved (AEDSA) | | 24 | Reserved (AEDSA) |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 100 to | Private/Experimental algorithm | | 100 to | Private/Experimental algorithm |
| 110 | | | 110 | |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
Table 15: Public-key algorithm registry Table 15: Public-key algorithm registry
Implementations MUST implement DSA for signatures, and Elgamal for Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys (1). RSA encryption. Implementations SHOULD implement RSA keys (1). RSA
Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and SHOULD NOT Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and SHOULD NOT
be generated, but may be interpreted. See Section 14.5. See be generated, but may be interpreted. See Section 14.5. See
Section 14.8 for notes on Elgamal Encrypt or Sign (20), and X9.42 Section 14.9 for notes on Elgamal Encrypt or Sign (20), and X9.42
(21). Implementations MAY implement any other algorithm. (21). Implementations MAY implement any other algorithm.
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.4 this Signatures" and in [SEC1]; ECDH is defined in Section 13.5 this
document. document.
9.2. ECC Curve OID 9.2. ECC Curve OID
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. The table below specifies the exact sequence of bytes for curve. The table below specifies the exact sequence of bytes for
each named curve referenced in this document: each named curve referenced in this document:
+========================+=====+=================+============+ +========================+=====+=================+============+
| ASN.1 Object | OID | Curve OID bytes | Curve name | | ASN.1 Object | OID | Curve OID bytes | Curve name |
| Identifier | len | in hexadecimal | | | Identifier | len | in hexadecimal | |
| | | representation | | | | | representation | |
+========================+=====+=================+============+ +========================+=====+=================+============+
| 1.2.840.10045.3.1.7 | 8 | 2A 86 48 CE 3D | NIST P-256 | | 1.2.840.10045.3.1.7 | 8 | 2A 86 48 CE 3D | NIST P-256 |
| | | 03 01 07 | | | | | 03 01 07 | |
+------------------------+-----+-----------------+------------+ +------------------------+-----+-----------------+------------+
| 1.3.132.0.34 | 5 | 2B 81 04 00 22 | NIST P-384 | | 1.3.132.0.34 | 5 | 2B 81 04 00 22 | NIST P-384 |
+------------------------+-----+-----------------+------------+ +------------------------+-----+-----------------+------------+
| 1.3.132.0.35 | 5 | 2B 81 04 00 23 | NIST P-521 | | 1.3.132.0.35 | 5 | 2B 81 04 00 23 | NIST P-521 |
+------------------------+-----+-----------------+------------+ +------------------------+-----+-----------------+------------+
| 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 | Ed25519 |
| | | DA 47 0F 01 | |
+------------------------+-----+-----------------+------------+
| 1.3.6.1.4.1.3029.1.5.1 | 10 | 2B 06 01 04 01 | Curve25519 | | 1.3.6.1.4.1.3029.1.5.1 | 10 | 2B 06 01 04 01 | Curve25519 |
| | | 97 55 01 05 01 | | | | | 97 55 01 05 01 | |
+------------------------+-----+-----------------+------------+ +------------------------+-----+-----------------+------------+
Table 16: ECC Curve OID registry Table 16: ECC Curve OID registry
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
encoded Object Identifier. The first omitted field is one octet encoded Object Identifier. The first omitted field is one octet
skipping to change at page 77, line 37 skipping to change at page 80, line 40
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.16. Adding a new Signature registry can be found in Section 5.2.3.16. 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 "Description", "Security Recommended", "Interoperability
Recommended", and "Reference". Adding a new item MUST be done Recommended", and "Reference". The initial values for this registry
can be found in Section 5.2.3.16. 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
defining specification. The initial values for this registry can be defining specification. The initial values for this registry can be
found in Section 5.2.3.17. Adding a new key server preference MUST found in Section 5.2.3.17. Adding a new key server preference MUST
skipping to change at page 78, line 36 skipping to change at page 81, line 47
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.24. initial values for this registry can be found in Section 5.2.3.24.
Adding a new feature-implementation flag MUST be done through the 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.12 for more information about when feature flags Also see Section 14.13 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 79, line 28 skipping to change at page 82, line 38
10.3.1. Public-Key Algorithms 10.3.1. Public-Key Algorithms
OpenPGP specifies a number of public-key algorithms. This OpenPGP specifies a number of public-key algorithms. This
specification creates a registry of public-key algorithm identifiers. specification creates a registry of public-key algorithm identifiers.
The registry includes the algorithm name, its key sizes and The registry includes the algorithm name, its key sizes and
parameters, and a reference to the defining specification. The parameters, and a reference to the defining specification. The
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
algorithm:
+====+============================+========================+
| ID | Algorithm | Reference |
+====+============================+========================+
| 22 | EdDSA public key algorithm | This doc, Section 14.8 |
+----+----------------------------+------------------------+
Table 20: New public-Key algorithms registered
[ Note to RFC-Editor: Please remove the table above on publication. ]
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 80, line 15 skipping to change at page 83, line 39
+====+===========+===========+ +====+===========+===========+
| 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 20: New hash Table 21: 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 81, line 44 skipping to change at page 85, line 25
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 the top-level public key is a signature-only key. However, any V4 or
key may have subkeys, and the subkeys may be encryption-only keys, V5 key may have subkeys, and the subkeys may be encryption-only keys,
signature-only keys, or general-purpose keys. V3 keys MUST NOT have signature-only keys, or general-purpose keys. V3 keys MUST NOT have
subkeys. subkeys.
Each Subkey packet MUST be followed by one Signature packet, which Each Subkey packet MUST be followed by one Signature packet, which
should be a subkey binding signature issued by the top-level key. should be a subkey binding signature issued by the top-level key.
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
skipping to change at page 85, line 4 skipping to change at page 88, line 24
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
followed by the two-octet packet length, followed by the entire followed by the two-octet packet length, followed by the entire
Public-Key packet starting with the version field. The Key ID is the 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 low-order 64 bits of the fingerprint. Here are the fields of the
hash material, with the example of a DSA key: hash material, with the example of a DSA key:
a.1) 0x99 (1 octet) a.1) 0x99 (1 octet)
a.2) two-octet scalar octet count of (b)-(e) a.2) two-octet scalar octet count of (b)-(e)
b) version number = 4 (1 octet); b) version number = 4 (1 octet);
c) timestamp of key creation (4 octets); c) timestamp of key creation (4 octets);
d) algorithm (1 octet): 17 = DSA (example); d) algorithm (1 octet): 17 = DSA (example);
e) Algorithm-specific fields. e) Algorithm-specific fields.
Algorithm-Specific Fields for DSA keys (example): Algorithm-Specific Fields for DSA keys (example):
e.1) MPI of DSA prime p; e.1) MPI of DSA prime p;
e.2) MPI of DSA group order q (q is a prime divisor of p-1); e.2) MPI of DSA group order q (q is a prime divisor of p-1);
e.3) MPI of DSA group generator g; e.3) MPI of DSA group generator g;
e.4) MPI of DSA public-key value y (= g**x mod p where x is secret). e.4) MPI of DSA public-key value y (= g**x mod p where x is secret).
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 a DSA 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): 17 = DSA (example);
e) four-octet scalar octet count for the following key material;
f) algorithm-specific fields.
Algorithm-Specific Fields for DSA keys (example):
f.1) MPI of DSA prime p;
f.2) MPI of DSA group order q (q is a prime divisor of p-1);
f.3) MPI of DSA group generator g;
f.4) MPI of DSA public-key value y (= g**x mod p where x is secret).
Note that it is possible for there to be collisions of Key IDs -- two 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 different keys with the same Key ID. Note that there is a much
smaller, but still non-zero, probability that two different keys have smaller, but still non-zero, probability that two different keys have
the same fingerprint. the same fingerprint.
Also note that if V3 and V4 format keys share the same RSA key 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 material, they will have different Key IDs as well as different
fingerprints. fingerprints.
Finally, the Key ID and fingerprint of a subkey are calculated in the Finally, the Key ID and fingerprint of a subkey are calculated in the
same way as for a primary key, including the 0x99 as the first octet same way as for a primary key, including the 0x99 (V3 and V4 key) or
(even though this is not a valid packet ID for a public subkey). 0x9A (V5 key) as the first octet (even though this is not a valid
packet ID for a public subkey).
13. Elliptic Curve Cryptography 13. Elliptic Curve Cryptography
This section descripes algorithms and parameters used with Elliptic This section descripes 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].
13.1. Supported ECC Curves 13.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". [FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521".
Further curve "Curve25519", defined in [RFC7748] is referenced for Further curve "Curve25519", defined in [RFC7748] is referenced for
use with X25519 (ECDH encryption). use with Ed25519 (EdDSA signing) and X25519 (encryption).
The named curves are referenced as a sequence of bytes in this The named curves are referenced as a sequence of bytes 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 bytes is formed. detail how this sequence of bytes is formed.
13.2. ECDSA and ECDH Conversion Primitives 13.2. ECDSA and ECDH Conversion Primitives
This document defines the uncompressed point format for ECDSA and This document defines the uncompressed point format for ECDSA and
ECDH and a custom compression format for certain curves. The point ECDH and a custom compression format for certain curves. The point
is encoded in the Multiprecision Integer (MPI) format. is encoded in the Multiprecision Integer (MPI) format.
skipping to change at page 86, line 42 skipping to change at page 90, line 46
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.
If other conversion methods are defined in the future, a compliant If other conversion methods are defined in the future, a compliant
application MUST NOT use a new format when in doubt that any application MUST NOT use a new format when in doubt that any
recipient can support it. Consider, for example, that while both the recipient can support it. Consider, for example, that while both the
public key and the per-recipient ECDH data structure, respectively public key and the per-recipient ECDH data structure, respectively
defined in Section 5.6.5 and Section 5.1, contain an encoded point defined in Section 5.6.6 and Section 5.1, contain an encoded point
field, the format changes to the field in Section 5.1 only affect a field, the format changes to the field in Section 5.1 only affect a
given recipient of a given message. given recipient of a given message.
13.3. Key Derivation Function 13.3. EdDSA Point Format
The EdDSA algorithm defines a specific point compression format. To
indicate the use of this compression format and to make sure that the
key can be represented in the Multiprecision Integer (MPI) format the
octet string specifying the point is prefixed with the octet 0x40.
This encoding is an extension of the encoding given in [SEC1] which
uses 0x04 to indicate an uncompressed point.
For example, the length of a public key for the curve Ed25519 is 263
bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the
native value of the public key.
13.4. Key Derivation Function
A key derivation function (KDF) is necessary to implement the EC A key derivation function (KDF) is necessary to implement the 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. See Section 16 for the SHA2-256 [FIPS180] or stronger is REQUIRED.
details regarding the choice of the hash function.
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.
// Implements KDF( X, oBits, Param ); // Implements KDF( X, oBits, Param );
// Input: point X = (x,y) // Input: point X = (x,y)
// oBits - the desired size of output // oBits - the desired size of output
// hBits - the size of output of hash function Hash // hBits - the size of output of hash function Hash
skipping to change at page 87, line 26 skipping to change at page 91, line 46
// 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, defined in Section 4.2 of [RFC6090]. representation of X, defined in Section 4.2 of [RFC6090].
13.4. EC DH Algorithm (ECDH) 13.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 as employed by this method is modified to always assume the cofactor as
1, the KDF specified in Section 13.3 is used, and the KDF parameters 1, the KDF specified in Section 13.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, compatible with the variable-length and fixed-length fields, compatible with the
definition of the OtherInfo bitstring [SP800-56A]: definition of the OtherInfo bitstring [SP800-56A]:
* 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 - a one-octet size of the following field
skipping to change at page 88, line 4 skipping to change at page 92, line 23
definition of the OtherInfo bitstring [SP800-56A]: definition of the OtherInfo bitstring [SP800-56A]:
* 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 - a one-octet size of the following field
- the octets representing a curve OID, defined in Section 9.2 - the octets representing a curve OID, defined in Section 9.2
* a one-octet public key algorithm ID defined in Section 9.1 * a one-octet public key algorithm ID defined in Section 9.1
* a variable-length field containing KDF parameters, identical to * a variable-length field containing KDF parameters, identical to
the corresponding field in the ECDH public key, formatted as the corresponding field in the ECDH public key, formatted as
follows: 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 01, reserved for future extensions - a one-octet value 01, 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.4 wrap the symmetric key for message encryption; see Section 13.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 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 73 20 53 65 6E 64 65 72 20 20 20 20
* 20 octets representing a recipient encryption subkey or a master * 20 octets representing a recipient encryption subkey or a master
key fingerprint, identifying the key material that is needed for key fingerprint, identifying the key material that is needed for
the decryption. For version 5 keys the 20 leftmost octets of the the decryption. For version 5 keys the 20 leftmost octets of the
fingerprint are used. fingerprint are used.
skipping to change at page 88, line 47 skipping to change at page 93, line 20
default initial value of [RFC3394]. default initial value of [RFC3394].
The input to the key wrapping method is the value "m" derived from The input to the key wrapping method is the value "m" derived from
the session key, as described in Section 5.1, "Public-Key Encrypted the session key, as described in Section 5.1, "Public-Key Encrypted
Session Key Packets (Tag 1)", except that the PKCS #1.5 padding step Session Key Packets (Tag 1)", except that the PKCS #1.5 padding step
is omitted. The result is padded using the method described in is omitted. The result is padded using the method described in
[PKCS5] to the 8-byte granularity. For example, the following [PKCS5] to the 8-byte granularity. For example, the following
AES-256 session key, in which 32 octets are denoted from k0 to k31, AES-256 session key, in which 32 octets are denoted from k0 to k31,
is composed to form the following 40 octet sequence: is composed to form the following 40 octet sequence:
09 k0 k1 ... k31 c0 c1 05 05 05 05 05 09 k0 k1 ... k31 s0 s1 05 05 05 05 05
The octets c0 and c1 above denote the checksum. This encoding allows The octets s0 and s1 above denote the checksum. This encoding allows
the sender to obfuscate the size of the symmetric encryption key used the sender to obfuscate the size of the symmetric encryption key used
to encrypt the data. For example, assuming that an AES algorithm is to encrypt the data. For example, assuming that an AES algorithm is
used for the session key, the sender MAY use 21, 13, and 5 bytes of used for the session key, the sender MAY use 21, 13, and 5 bytes of
padding for AES-128, AES-192, and AES-256, respectively, to provide padding for AES-128, AES-192, and AES-256, respectively, to provide
the same number of octets, 40 total, as an input to the key wrapping the same number of octets, 40 total, as an input to the key wrapping
method. method.
The output of the method consists of two fields. The first field is The output of the method consists of two fields. The first field is
the MPI containing the ephemeral key used to establish the shared the MPI containing the ephemeral key used to establish the shared
secret. The second field is composed of the following two fields: secret. The second field is composed of the following two fields:
skipping to change at page 92, line 41 skipping to change at page 97, line 14
EM = 0x00 || 0x01 || PS || 0x00 || T. EM = 0x00 || 0x01 || PS || 0x00 || T.
6. Output EM. 6. Output EM.
14.2. Symmetric Algorithm Preferences 14.2. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature, that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have multiple, different it is possible that a keyholder may have multiple, different
preferences. For example, Alice may have TripleDES only specified preferences. For example, Alice may have AES-128 only specified for
for "alice@work.com" but CAST5, Blowfish, and TripleDES 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 TripleDES is the MUST-implement algorithm, if it is not Since TripleDES is the MUST-implement 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. Note also that if an good form to place it there explicitly. Note also that if an
implementation does not implement the preference, then it is implementation does not implement the preference, then it is
implicitly a TripleDES-only implementation. implicitly a TripleDES-only implementation.
An implementation MUST NOT use a symmetric algorithm that is not in An implementation MUST NOT use a symmetric algorithm that is not in
skipping to change at page 95, line 41 skipping to change at page 100, line 5
Note that earlier versions of this standard only allowed a 160-bit q Note that earlier versions of this standard only allowed a 160-bit q
with no truncation allowed, so earlier implementations may not be with no truncation allowed, so earlier implementations may not be
able to handle signatures with a different q size or a truncated able to handle signatures with a different q size or a truncated
hash. hash.
14.7. Elgamal 14.7. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less than An implementation SHOULD NOT implement Elgamal keys of size less than
1024 bits. 1024 bits.
14.8. Reserved Algorithm Numbers 14.8. EdDSA
Although the EdDSA algorithm allows arbitrary data as input, its use
with OpenPGP requires that a digest of the message is used as input
(pre-hashed). See section Section 5.2.4, "Computing Signatures" for
details. Truncation of the resulting digest is never applied; the
resulting digest value is used verbatim as input to the EdDSA
algorithm.
14.9. 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 14.10. OpenPGP CFB Mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback OpenPGP does symmetric encryption using a variant of Cipher Feedback
mode (CFB mode). This section describes the procedure it uses in mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Encrypted Data detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret-key material is Packets; the mechanism used for encrypting secret-key material is
similar, and is described in the sections above. similar, and is described in the sections above.
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
Twofish have a block size of 16 octets. Also note that the Twofish have a block size of 16 octets. Also note that the
skipping to change at page 97, line 28 skipping to change at page 102, line 5
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 14.11. 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. Extension of the MDC System 14.12. Extension of the MDC System
As described in the non-normative explanation in Section 5.14, the As described in the non-normative explanation in Section 5.14, the
MDC system is uniquely unparameterized in OpenPGP. This was an MDC system is uniquely unparameterized in OpenPGP. This was an
intentional decision to avoid cross-grade attacks. If the MDC system intentional decision to avoid cross-grade attacks. If the MDC system
is extended to a stronger hash function, care must be taken to avoid is extended to a stronger hash function, care must be taken to avoid
downgrade and cross-grade attacks. downgrade and cross-grade attacks.
One simple way to do this is to create new packets for a new MDC. One simple way to do this is to create new packets for a new MDC.
For example, instead of the MDC system using packets 18 and 19, a new For example, instead of the MDC system using packets 18 and 19, a new
MDC could use 20 and 21. This has obvious drawbacks (it uses two MDC could use 20 and 21. This has obvious drawbacks (it uses two
skipping to change at page 98, line 35 skipping to change at page 103, line 8
packet 19s without admitting the chance of a cross-grade attack. packet 19s without admitting the chance of a cross-grade attack.
Yet another, complex approach to extend the MDC system would be a Yet another, complex approach to extend the MDC system would be a
hybrid of the two above -- create a new pair of MDC packets that are hybrid of the two above -- create a new pair of MDC packets that are
fully parameterized, and yet protected from downgrade and cross- fully parameterized, and yet protected from downgrade and cross-
grade. grade.
Any change to the MDC system MUST be done through the IETF CONSENSUS Any change to the MDC system MUST be done through the IETF CONSENSUS
method, as described in [RFC8126]. method, as described in [RFC8126].
14.12. Meta-Considerations for Expansion 14.13. 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.
skipping to change at page 100, line 19 skipping to change at page 104, line 40
+---------------------+-----------+--------------------+ +---------------------+-----------+--------------------+
| 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 21: Key length equivalences Table 22: 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 103, line 16 skipping to change at page 107, line 39
| Curve name | ECC | RSA | Hash size strength, | Symmetric | | Curve name | ECC | RSA | Hash size strength, | Symmetric |
| | | strength | informative | key size | | | | strength | informative | key size |
+============+=====+==============+=====================+===========+ +============+=====+==============+=====================+===========+
| NIST P-256 | 256 | 3072 | 256 | 128 | | NIST P-256 | 256 | 3072 | 256 | 128 |
+------------+-----+--------------+---------------------+-----------+ +------------+-----+--------------+---------------------+-----------+
| NIST P-384 | 384 | 7680 | 384 | 192 | | NIST P-384 | 384 | 7680 | 384 | 192 |
+------------+-----+--------------+---------------------+-----------+ +------------+-----+--------------+---------------------+-----------+
| NIST P-521 | 521 | 15360 | 512 | 256 | | NIST P-521 | 521 | 15360 | 512 | 256 |
+------------+-----+--------------+---------------------+-----------+ +------------+-----+--------------+---------------------+-----------+
Table 22: Elliptic Curve cryptographic guidance Table 23: Elliptic Curve cryptographic guidance
* Requirement levels indicated elsewhere in this document lead to * Requirement levels indicated elsewhere in this document lead to
the following combinations of algorithms in the OpenPGP profile: the following combinations of algorithms in the OpenPGP profile:
MUST implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD MUST implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD
implement NIST curve P-521 / SHA2-512 / AES-256, MAY implement implement NIST curve P-521 / SHA2-512 / AES-256, MAY implement
NIST curve P-384 / SHA2-384 / AES-256, among other allowed NIST curve P-384 / SHA2-384 / AES-256, among other allowed
combinations. combinations.
Consistent with the table above, the following table defines the Consistent with the table above, the following table defines the
KDF hash algorithm and the AES KEK encryption algorithm that KDF hash algorithm and the AES KEK encryption algorithm that
skipping to change at page 103, line 41 skipping to change at page 108, line 16
| Curve name | Recommended KDF | Recommended KEK | | Curve name | Recommended KDF | Recommended KEK |
| | hash algorithm | encryption algorithm | | | hash algorithm | encryption algorithm |
+============+=================+======================+ +============+=================+======================+
| NIST P-256 | SHA2-256 | AES-128 | | NIST P-256 | SHA2-256 | AES-128 |
+------------+-----------------+----------------------+ +------------+-----------------+----------------------+
| NIST P-384 | SHA2-384 | AES-192 | | NIST P-384 | SHA2-384 | AES-192 |
+------------+-----------------+----------------------+ +------------+-----------------+----------------------+
| NIST P-521 | SHA2-512 | AES-256 | | NIST P-521 | SHA2-512 | AES-256 |
+------------+-----------------+----------------------+ +------------+-----------------+----------------------+
Table 23: Elliptic Curve KDF and KEK recommendations Table 24: Elliptic Curve KDF and KEK recommendations
* This document explicitly discourages the use of algorithms other * This document explicitly discourages the use of algorithms other
than AES as a KEK algorithm because backward compatibility of the than AES as a KEK algorithm because backward compatibility of the
ECDH format is not a concern. The KEK algorithm is only used ECDH format is not a concern. The KEK algorithm is only used
within the scope of a Public-Key Encrypted Session Key Packet, within the scope of a Public-Key Encrypted Session Key Packet,
which represents an ECDH key recipient of a message. Compare this which represents an ECDH key recipient of a message. Compare this
with the algorithm used for the session key of the message, which with the algorithm used for the session key of the message, which
MAY be different from a KEK algorithm. MAY be different from a KEK algorithm.
Compliant applications SHOULD implement, advertise through key Compliant applications SHOULD implement, advertise through key
skipping to change at page 104, line 42 skipping to change at page 109, line 14
that can implement every algorithm defined in this document. Most that can implement every algorithm defined in this document. Most
applications are expected to fall into either of two categories. applications are expected to fall into either of two categories.
A compliant application in the second, or strongest, category A compliant application in the second, or strongest, category
SHOULD prefer AES-256 to AES-192. SHOULD prefer AES-256 to AES-192.
SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH
method. method.
MDC MUST be used when a symmetric encryption key is protected by MDC MUST be used when a symmetric encryption key is protected by
ECDH. None of the ECC methods described in this document are ECDH. None of the ECC methods described in this document are
allowed with deprecated V3 keys. A compliant application MUST allowed with deprecated V3 keys.
only use iterated and salted S2K to protect private keys, as
defined in Section 3.7.1.3, "Iterated and Salted S2K".
Side channel attacks are a concern when a compliant application's Side channel attacks are a concern when a compliant application's
use of the OpenPGP format can be modeled by a decryption or use of the OpenPGP format can be modeled by a decryption or
signing oracle model, for example, when an application is a signing oracle model, for example, when an application is a
network service performing decryption to unauthenticated remote network service performing decryption to unauthenticated remote
users. ECC scalar multiplication operations used in ECDSA and users. ECC scalar multiplication operations used in ECDSA and
ECDH are vulnerable to side channel attacks. Countermeasures can ECDH are vulnerable to side channel attacks. Countermeasures can
often be taken at the higher protocol level, such as limiting the often be taken at the higher protocol level, such as limiting the
number of allowed failures or time-blinding of the operations number of allowed failures or time-blinding of the operations
associated with each network interface. Mitigations at the scalar associated with each network interface. Mitigations at the scalar
multiplication level seek to eliminate any measurable distinction multiplication level seek to eliminate any measurable distinction
between the ECC point addition and doubling operations. between the ECC point addition and doubling operations.
16. Compatibility Profiles 16. Implementation Nits
16.1. OpenPGP ECC Profile
A compliant application MUST implement NIST curve P-256, SHOULD
implement NIST curve P-521, and SHOULD implement Curve25519 as
defined in Section 9.2. A compliant application MUST implement
SHA2-256 and SHOULD implement SHA2-384 and SHA2-512. A compliant
application MUST implement AES-128 and SHOULD implement AES-256.
A compliant application SHOULD follow Section 15 regarding the choice
of the following algorithms for each curve:
* the KDF hash algorithm,
* the KEK algorithm,
* the message digest algorithm and the hash algorithm used in the
key certifications,
* the symmetric algorithm used for message encryption.
It is recommended that the chosen symmetric algorithm for message
encryption be no less secure than the KEK algorithm.
16.2. Suite-B Profile
A subset of algorithms allowed by this document can be used to
achieve [SuiteB] compatibility. The references to [SuiteB] in this
document are informative. This document is primarily concerned with
format specification, leaving additional security restrictions
unspecified, such as matching the assigned security level of
information to authorized recipients or interoperability concerns
arising from fewer allowed algorithms in [SuiteB] than allowed by
this document.
16.2.1. Security Strength at 192 Bits
To achieve the security strength of 192 bits, [SuiteB] requires NIST
curve P-384, AES-256, and SHA2-384. The symmetric algorithm
restriction means that the algorithm of KEK used for key wrapping in
Section 13.4 and an OpenPGP session key used for message encryption
must be AES-256. The hash algorithm restriction means that the hash
algorithms of KDF and the OpenPGP message digest calculation must be
SHA2-384.
16.2.2. Security Strength at 128 Bits
The set of algorithms in Section 16.2.1 is extended to allow NIST
curve P-256, AES-128, and SHA2-256.
17. Implementation Nits
This section is a collection of comments to help an implementer, This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous particularly with an eye to backward compatibility. Previous
implementations of PGP are not OpenPGP compliant. Often the implementations of PGP are not OpenPGP compliant. Often the
differences are small, but small differences are frequently more differences are small, but small differences are frequently more
vexing than large differences. Thus, this is a non-comprehensive vexing than large differences. Thus, this is a non-comprehensive
list of potential problems and gotchas for a developer who is trying list of potential problems and gotchas for a developer who is trying
to be backward-compatible. to be backward-compatible.
* The IDEA algorithm is patented, and yet it is required for PGP 2 * The IDEA algorithm is patented, and yet it is required for PGP 2
skipping to change at page 107, line 41 skipping to change at page 111, line 21
unnecessary. OpenPGP permits an implementation to declare what unnecessary. OpenPGP permits an implementation to declare what
features it does and does not support, but ASCII armor is not one features it does and does not support, but ASCII armor is not one
of these. Since most implementations allow binary and armored of these. Since most implementations allow binary and armored
objects to be used indiscriminately, an implementation that does objects to be used indiscriminately, an implementation that does
not implement ASCII armor may find itself with compatibility not implement ASCII armor may find itself with compatibility
issues with general-purpose implementations. Moreover, issues with general-purpose implementations. Moreover,
implementations of OpenPGP-MIME [RFC3156] already have a implementations of OpenPGP-MIME [RFC3156] already have a
requirement for ASCII armor so those implementations will requirement for ASCII armor so those implementations will
necessarily have support. necessarily have support.
18. References 17. References
18.1. Normative References 17.1. Normative References
[AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)", [AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)",
November 2001, November 2001,
<http://csrc.nist.gov/publications/fips/fips197/fips- <http://csrc.nist.gov/publications/fips/fips197/fips-
197.{ps,pdf}>. 197.{ps,pdf}>.
[BLOWFISH] Schneier, B., "Description of a New Variable-Length Key, [BLOWFISH] Schneier, B., "Description of a New Variable-Length Key,
64-Bit Block Cipher (Blowfish)", Fast Software Encryption, 64-Bit Block Cipher (Blowfish)", Fast Software Encryption,
Cambridge Security Workshop Proceedings Springer-Verlag, Cambridge Security Workshop Proceedings Springer-Verlag,
1994, pp191-204, December 1993, 1994, pp191-204, December 1993,
skipping to change at page 110, line 19 skipping to change at page 113, line 41
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996. protocols, algorithms, and source code in C", 1996.
[SP800-56A] [SP800-56A]
Barker, E., Johnson, D., and M. Smid, "Recommendation for Barker, E., Johnson, D., and M. Smid, "Recommendation for
Pair-Wise Key Establishment Schemes Using Discrete Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography", NIST Special Publication 800-56A Logarithm Cryptography", NIST Special Publication 800-56A
Revision 1, March 2007. Revision 1, March 2007.
[SuiteB] National Security Agency, "NSA Suite B Cryptography", 11
March 2010,
<http://www.nsa.gov/ia/programs/suiteb_cryptography/>.
[TWOFISH] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall, [TWOFISH] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall,
C., and N. Ferguson, "The Twofish Encryption Algorithm", C., and N. Ferguson, "The Twofish Encryption Algorithm",
1999. 1999.
18.2. Informative References 17.2. Informative References
[BLEICHENBACHER] [BLEICHENBACHER]
Bleichenbacher, D., "Generating ElGamal Signatures Without Bleichenbacher, D., "Generating ElGamal Signatures Without
Knowing the Secret Key", Lecture Notes in Computer Knowing the Secret Key", Lecture Notes in Computer
Science Volume 1070, pp. 10-18, 1996. Science Volume 1070, pp. 10-18, 1996.
[JKS02] Jallad, K., Katz, J., and B. Schneier, "Implementation of [JKS02] Jallad, K., Katz, J., and B. Schneier, "Implementation of
Chosen-Ciphertext Attacks against PGP and GnuPG", 2002, Chosen-Ciphertext Attacks against PGP and GnuPG", 2002,
<http://www.counterpane.com/pgp-attack.html>. <http://www.counterpane.com/pgp-attack.html>.
skipping to change at page 111, line 42 skipping to change at page 115, line 18
<https://www.rfc-editor.org/info/rfc6090>. <https://www.rfc-editor.org/info/rfc6090>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1: [SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", September 2000. Elliptic Curve Cryptography", September 2000.
[SP800-57] NIST, "Recommendation on Key Management", NIST Special [SP800-57] NIST, "Recommendation on Key Management", NIST Special
Publication 800-57, March 2007, Publication 800-57, March 2007,
<http://csrc.nist.gov/publications/nistpubs/800-57/ <http://csrc.nist.gov/publications/nistpubs/800-57/
SP800-57-Part{1,2}.pdf>. SP800-57-Part{1,2}.pdf>.
Appendix A. Document Workflow Appendix A. Test vectors
To help implementing this specification a non-normative example for
the EdDSA algorithm is given.
A.1. Sample EdDSA key
The secret key used for this example is:
D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2
Note that this is the raw secret key used as input to the EdDSA
signing operation. The key was created on 2014-08-19 14:28:27 and
thus the fingerprint of the OpenPGP key is:
C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A
The algorithm specific input parameters without the MPI length
headers are:
oid: 2b06010401da470f01
q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406
The entire public key packet is thus:
98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47
0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19
79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e
43 ee 3b 24 06
A.2. Sample EdDSA signature
The signature is created using the sample key over the input data
"OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash
function is:
m: 4f70656e504750040016080006050255f95f9504ff0000000c
Using the SHA2-256 hash algorithm yields the digest:
d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
Which is fed into the EdDSA signature function and yields this
signature:
r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366
s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404
The entire signature packet is thus:
88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a
09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9
0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2
7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00
d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e
a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04
Appendix B. Document Workflow
This document is built from markdown using ruby-kramdown-rfc2629 This document is built from markdown using ruby-kramdown-rfc2629
(https://rubygems.org/gems/kramdown-rfc2629), and tracked using git (https://rubygems.org/gems/kramdown-rfc2629), and tracked using git
(https://git-scm.com/). The markdown source under development can be (https://git-scm.com/). The markdown source under development can be
found in the file "crypto-refresh.md" in the "main" branch of the git found in the file "crypto-refresh.md" in the "main" branch of the git
repository (https://gitlab.com/openpgp-wg/rfc4880bis). Discussion of repository (https://gitlab.com/openpgp-wg/rfc4880bis). Discussion of
this document should take place on the openpgp@ietf.org mailing list this document should take place on the openpgp@ietf.org mailing list
(https://www.ietf.org/mailman/listinfo/openpgp). (https://www.ietf.org/mailman/listinfo/openpgp).
A non-substantive editorial nit can be submitted directly as a merge A non-substantive editorial nit can be submitted directly as a merge
skipping to change at page 112, line 18 skipping to change at page 117, line 7
request, but should simultaneously be sent to the mailing list for request, but should simultaneously be sent to the mailing list for
discussion. discussion.
An open problem can be recorded and tracked as an issue An open problem can be recorded and tracked as an issue
(https://gitlab.com/openpgp-wg/rfc4880bis/-/issues) in the gitlab (https://gitlab.com/openpgp-wg/rfc4880bis/-/issues) in the gitlab
issue tracker, but discussion of the issue should take place on the issue tracker, but discussion of the issue should take place on the
mailing list. mailing list.
[Note to RFC-Editor: Please remove this section on publication.] [Note to RFC-Editor: Please remove this section on publication.]
Appendix B. ECC Point compression flag bytes Appendix C. ECC Point compression flag bytes
This specification introduces the new flag byte 0x40 to indicate the This specification introduces the new flag byte 0x40 to indicate the
point compression format. The value has been chosen so that the high point compression format. The value has been chosen so that the high
bit is not cleared and thus to avoid accidental sign extension. Two bit is not cleared and thus to avoid accidental sign extension. Two
other values might also be interesting for other ECC specifications: other values might also be interesting for other ECC specifications:
Flag Description Flag Description
---- ----------- ---- -----------
0x04 Standard flag for uncompressed format 0x04 Standard flag for uncompressed format
0x40 Native point format of the curve follows 0x40 Native point format of the curve follows
0x41 Only X coordinate follows. 0x41 Only X coordinate follows.
0x42 Only Y coordinate follows. 0x42 Only Y coordinate follows.
Appendix C. Acknowledgements Appendix D. Acknowledgements
This memo also draws on much previous work from a number of other This memo also draws on much previous work from a number of other
authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc
Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie,
Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings,
Mark Weaver, and Philip R. Zimmermann. Mark Weaver, and Philip R. Zimmermann.
Authors' Addresses Authors' Addresses
Werner Koch (editor) Werner Koch (editor)
skipping to change at page 113, line 4 skipping to change at page 117, line 39
Authors' Addresses Authors' Addresses
Werner Koch (editor) Werner Koch (editor)
GnuPG e.V. GnuPG e.V.
Rochusstr. 44 Rochusstr. 44
40479 Duesseldorf 40479 Duesseldorf
Germany Germany
Email: wk@gnupg.org Email: wk@gnupg.org
URI: https://gnupg.org/verein URI: https://gnupg.org/verein
Paul Wouters (editor) Paul Wouters (editor)
No Hats
Email: pwouters@redhat.com Email: paul@nohats.ca
 End of changes. 102 change blocks. 
286 lines changed or deleted 506 lines changed or added

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