draft-ietf-openpgp-rfc4880bis-01.txt   draft-ietf-openpgp-rfc4880bis-02.txt 
Network Working Group W. Koch Network Working Group W. Koch
Internet-Draft Internet-Draft
Updates: 4880 (if approved) January 2, 2017 Updates: 4880 (if approved) June 30, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: July 6, 2017 Expires: January 1, 2018
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc4880bis-01 draft-ietf-openpgp-rfc4880bis-02
Abstract Abstract
{ Work in progress to update the OpenPGP specification from RFC4880 } { Work in progress to update the OpenPGP specification from RFC4880 }
This document is maintained in order to publish all necessary This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on the information needed to develop interoperable applications based on the
OpenPGP format. It is not a step-by-step cookbook for writing an OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any read, check, generate, and write conforming packets crossing any
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 6, 2017. This Internet-Draft will expire on January 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. {1} Introduction . . . . . . . . . . . . . . . . . . . . . . 5 1. {1} Introduction . . . . . . . . . . . . . . . . . . . . . . 5
1.1. {1.1} Terms . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. {1.1} Terms . . . . . . . . . . . . . . . . . . . . . . . 5
2. {2} General functions . . . . . . . . . . . . . . . . . . . . 6 2. {2} General functions . . . . . . . . . . . . . . . . . . . . 6
2.1. {2.1} Confidentiality via Encryption . . . . . . . . . . 6 2.1. {2.1} Confidentiality via Encryption . . . . . . . . . . 6
2.2. {2.2} Authentication via Digital Signature . . . . . . . 7 2.2. {2.2} Authentication via Digital Signature . . . . . . . 7
2.3. {2.3} Compression . . . . . . . . . . . . . . . . . . . . 7 2.3. {2.3} Compression . . . . . . . . . . . . . . . . . . . . 8
2.4. {2.4} Conversion to Radix-64 . . . . . . . . . . . . . . 8 2.4. {2.4} Conversion to Radix-64 . . . . . . . . . . . . . . 8
2.5. {2.5} Signature-Only Applications . . . . . . . . . . . . 8 2.5. {2.5} Signature-Only Applications . . . . . . . . . . . . 8
3. {3} Data Element Formats . . . . . . . . . . . . . . . . . . 8 3. {3} Data Element Formats . . . . . . . . . . . . . . . . . . 8
3.1. {3.1} Scalar Numbers . . . . . . . . . . . . . . . . . . 8 3.1. {3.1} Scalar Numbers . . . . . . . . . . . . . . . . . . 9
3.2. {3.2} Multiprecision Integers . . . . . . . . . . . . . . 9 3.2. {3.2} Multiprecision Integers . . . . . . . . . . . . . . 9
3.3. {3.3} Key IDs . . . . . . . . . . . . . . . . . . . . . . 9 3.3. {3.3} Key IDs . . . . . . . . . . . . . . . . . . . . . . 9
3.4. {3.4} Text . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. {3.4} Text . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. {3.5} Time Fields . . . . . . . . . . . . . . . . . . . . 10 3.5. {3.5} Time Fields . . . . . . . . . . . . . . . . . . . . 10
3.6. {3.6} Keyrings . . . . . . . . . . . . . . . . . . . . . 10 3.6. {3.6} Keyrings . . . . . . . . . . . . . . . . . . . . . 10
3.7. {3.7} String-to-Key (S2K) Specifiers . . . . . . . . . . 10 3.7. {3.7} String-to-Key (S2K) Specifiers . . . . . . . . . . 10
3.7.1. {3.7.1} String-to-Key (S2K) Specifier Types . . . . . 10 3.7.1. {3.7.1} String-to-Key (S2K) Specifier Types . . . . . 10
3.7.2. {3.7.2} String-to-Key Usage . . . . . . . . . . . . . 12 3.7.2. {3.7.2} String-to-Key Usage . . . . . . . . . . . . . 12
4. {4} Packet Syntax . . . . . . . . . . . . . . . . . . . . . . 13 4. {4} Packet Syntax . . . . . . . . . . . . . . . . . . . . . . 13
4.1. {4.1} Overview . . . . . . . . . . . . . . . . . . . . . 13 4.1. {4.1} Overview . . . . . . . . . . . . . . . . . . . . . 13
4.2. {4.2} Packet Headers . . . . . . . . . . . . . . . . . . 13 4.2. {4.2} Packet Headers . . . . . . . . . . . . . . . . . . 14
4.2.1. {4.2.1} Old Format Packet Lengths . . . . . . . . . . 14 4.2.1. {4.2.1} Old Format Packet Lengths . . . . . . . . . . 14
4.2.2. {4.2.2} New Format Packet Lengths . . . . . . . . . . 15 4.2.2. {4.2.2} New Format Packet Lengths . . . . . . . . . . 15
4.2.3. {4.2.3} Packet Length Examples . . . . . . . . . . . 16 4.2.3. {4.2.3} Packet Length Examples . . . . . . . . . . . 16
4.3. {4.3} Packet Tags . . . . . . . . . . . . . . . . . . . . 17 4.3. {4.3} Packet Tags . . . . . . . . . . . . . . . . . . . . 17
5. {5} Packet Types . . . . . . . . . . . . . . . . . . . . . . 17 5. {5} Packet Types . . . . . . . . . . . . . . . . . . . . . . 17
5.1. {5.1} Public-Key Encrypted Session Key Packets (Tag 1) . 17 5.1. {5.1} Public-Key Encrypted Session Key Packets (Tag 1) . 17
5.2. {5.2} Signature Packet (Tag 2) . . . . . . . . . . . . . 19 5.2. {5.2} Signature Packet (Tag 2) . . . . . . . . . . . . . 19
5.2.1. {5.2.1} Signature Types . . . . . . . . . . . . . . . 19 5.2.1. {5.2.1} Signature Types . . . . . . . . . . . . . . . 19
5.2.2. {5.2.2} Version 3 Signature Packet Format . . . . . . 21 5.2.2. {5.2.2} Version 3 Signature Packet Format . . . . . . 21
5.2.3. {5.2.3} Version 4 Signature Packet Format . . . . . . 24 5.2.3. {5.2.3} Version 4 Signature Packet Format . . . . . . 24
5.2.4. {5.2.4} Computing Signatures . . . . . . . . . . . . 40 5.2.4. {5.2.4} Computing Signatures . . . . . . . . . . . . 40
5.3. {5.3} Symmetric-Key Encrypted Session Key Packets (Tag 3) 41 5.3. {5.3} Symmetric-Key Encrypted Session Key Packets (Tag 3) 41
5.4. {5.4} One-Pass Signature Packets (Tag 4) . . . . . . . . 42 5.4. {5.4} One-Pass Signature Packets (Tag 4) . . . . . . . . 42
5.5. {5.5} Key Material Packet . . . . . . . . . . . . . . . . 43 5.5. {5.5} Key Material Packet . . . . . . . . . . . . . . . . 43
5.5.1. {5.5.1} Key Packet Variants . . . . . . . . . . . . . 43 5.5.1. {5.5.1} Key Packet Variants . . . . . . . . . . . . . 43
5.5.2. {5.5.2} Public-Key Packet Formats . . . . . . . . . . 44 5.5.2. {5.5.2} Public-Key Packet Formats . . . . . . . . . . 44
5.5.3. {5.5.3} Secret-Key Packet Formats . . . . . . . . . . 47 5.5.3. {5.5.3} Secret-Key Packet Formats . . . . . . . . . . 46
5.6. {5.6} Compressed Data Packet (Tag 8) . . . . . . . . . . 49 5.6. Algorithm-specific Parts of Keys . . . . . . . . . . . . 47
5.7. {5.7} Symmetrically Encrypted Data Packet (Tag 9) . . . . 49 5.6.1. Algorithm-Specific Part for RSA Keys . . . . . . . . 47
5.8. {5.8} Marker Packet (Obsolete Literal Packet) (Tag 10) . 50 5.6.2. Algorithm-Specific Part for DSA Keys . . . . . . . . 48
5.9. {5.9} Literal Data Packet (Tag 11) . . . . . . . . . . . 51 5.6.3. Algorithm-Specific Part for Elgamal Keys . . . . . . 48
5.10. {5.10} Trust Packet (Tag 12) . . . . . . . . . . . . . . 52 5.6.4. Algorithm-Specific Part for ECDSA Keys . . . . . . . 48
5.11. {5.11} User ID Packet (Tag 13) . . . . . . . . . . . . . 52 5.6.5. Algorithm-Specific Part for EdDSA Keys . . . . . . . 49
5.12. {5.12} User Attribute Packet (Tag 17) . . . . . . . . . . 52 5.6.6. Algorithm-Specific Part for ECDH Keys . . . . . . . . 49
5.12.1. {5.12.1} The Image Attribute Subpacket . . . . . . . 53 5.7. {5.6} Compressed Data Packet (Tag 8) . . . . . . . . . . 50
5.12.2. User ID Attribute Subpacket . . . . . . . . . . . . 53 5.8. {5.7} Symmetrically Encrypted Data Packet (Tag 9) . . . . 51
5.13. {5.13} Sym. Encrypted Integrity Protected Data Packet 5.9. {5.8} Marker Packet (Obsolete Literal Packet) (Tag 10) . 52
(Tag 18) . . . . . . . . . . . . . . . . . . . . . . . . 54 5.10. {5.9} Literal Data Packet (Tag 11) . . . . . . . . . . . 52
5.14. {5.14} Modification Detection Code Packet (Tag 19) . . . 57 5.11. {5.10} Trust Packet (Tag 12) . . . . . . . . . . . . . . 53
6. {6} Radix-64 Conversions . . . . . . . . . . . . . . . . . . 58 5.12. {5.11} User ID Packet (Tag 13) . . . . . . . . . . . . . 53
6.1. {6.1} An Implementation of the CRC-24 in "C" . . . . . . 58 5.13. {5.12} User Attribute Packet (Tag 17) . . . . . . . . . . 53
6.2. {6.2} Forming ASCII Armor . . . . . . . . . . . . . . . . 59 5.13.1. {5.12.1} The Image Attribute Subpacket . . . . . . . 54
6.3. {6.3} Encoding Binary in Radix-64 . . . . . . . . . . . . 61 5.13.2. User ID Attribute Subpacket . . . . . . . . . . . . 55
6.4. {6.4} Decoding Radix-64 . . . . . . . . . . . . . . . . . 63 5.14. {5.13} Sym. Encrypted Integrity Protected Data Packet
6.5. {6.5} Examples of Radix-64 . . . . . . . . . . . . . . . 63 (Tag 18) . . . . . . . . . . . . . . . . . . . . . . . . 55
6.6. {6.6} Example of an ASCII Armored Message . . . . . . . . 64 5.15. {5.14} Modification Detection Code Packet (Tag 19) . . . 58
7. {7} Cleartext Signature Framework . . . . . . . . . . . . . . 64 6. {6} Radix-64 Conversions . . . . . . . . . . . . . . . . . . 59
7.1. {7.1} Dash-Escaped Text . . . . . . . . . . . . . . . . . 65 6.1. {6.1} An Implementation of the CRC-24 in "C" . . . . . . 60
8. {8} Regular Expressions . . . . . . . . . . . . . . . . . . . 66 6.2. {6.2} Forming ASCII Armor . . . . . . . . . . . . . . . . 60
9. {9} Constants . . . . . . . . . . . . . . . . . . . . . . . . 66 6.3. {6.3} Encoding Binary in Radix-64 . . . . . . . . . . . . 63
9.1. {9.1} Public-Key Algorithms . . . . . . . . . . . . . . . 67 6.4. {6.4} Decoding Radix-64 . . . . . . . . . . . . . . . . . 64
9.2. ECC Curve OID . . . . . . . . . . . . . . . . . . . . . . 67 6.5. {6.5} Examples of Radix-64 . . . . . . . . . . . . . . . 64
9.3. {9.2} Symmetric-Key Algorithms . . . . . . . . . . . . . 68 6.6. {6.6} Example of an ASCII Armored Message . . . . . . . . 65
9.4. {9.3} Compression Algorithms . . . . . . . . . . . . . . 69 7. {7} Cleartext Signature Framework . . . . . . . . . . . . . . 65
9.5. {9.4} Hash Algorithms . . . . . . . . . . . . . . . . . . 69 7.1. {7.1} Dash-Escaped Text . . . . . . . . . . . . . . . . . 66
10. {10} IANA Considerations . . . . . . . . . . . . . . . . . . 70 8. {8} Regular Expressions . . . . . . . . . . . . . . . . . . . 67
10.1. {10.1} New String-to-Key Specifier Types . . . . . . . . 70 9. {9} Constants . . . . . . . . . . . . . . . . . . . . . . . . 67
10.2. {10.2} New Packets . . . . . . . . . . . . . . . . . . . 70 9.1. {9.1} Public-Key Algorithms . . . . . . . . . . . . . . . 68
10.2.1. {10.2.1} User Attribute Types . . . . . . . . . . . 70 9.2. ECC Curve OID . . . . . . . . . . . . . . . . . . . . . . 68
10.2.2. {10.2.1.1} Image Format Subpacket Types . . . . . . 71 9.3. {9.2} Symmetric-Key Algorithms . . . . . . . . . . . . . 69
10.2.3. {10.2.2} New Signature Subpackets . . . . . . . . . 71 9.4. {9.3} Compression Algorithms . . . . . . . . . . . . . . 70
10.2.4. {10.2.3} New Packet Versions . . . . . . . . . . . . 73 9.5. {9.4} Hash Algorithms . . . . . . . . . . . . . . . . . . 70
10.3. {10.3} New Algorithms . . . . . . . . . . . . . . . . . 73 10. {10} IANA Considerations . . . . . . . . . . . . . . . . . . 71
10.3.1. {10.3.1} Public-Key Algorithms . . . . . . . . . . . 74 10.1. {10.1} New String-to-Key Specifier Types . . . . . . . . 71
10.3.2. {10.3.2} Symmetric-Key Algorithms . . . . . . . . . 74 10.2. {10.2} New Packets . . . . . . . . . . . . . . . . . . . 71
10.3.3. {10.3.3} Hash Algorithms . . . . . . . . . . . . . . 74 10.2.1. {10.2.1} User Attribute Types . . . . . . . . . . . 72
10.3.4. {10.3.4} Compression Algorithms . . . . . . . . . . 75 10.2.2. {10.2.1.1} Image Format Subpacket Types . . . . . . 72
11. {11} Packet Composition . . . . . . . . . . . . . . . . . . . 75 10.2.3. {10.2.2} New Signature Subpackets . . . . . . . . . 72
11.1. {11.1} Transferable Public Keys . . . . . . . . . . . . 75 10.2.4. {10.2.3} New Packet Versions . . . . . . . . . . . . 75
11.2. {11.2} Transferable Secret Keys . . . . . . . . . . . . 76 10.3. {10.3} New Algorithms . . . . . . . . . . . . . . . . . 75
11.3. {11.3} OpenPGP Messages . . . . . . . . . . . . . . . . 77 10.3.1. {10.3.1} Public-Key Algorithms . . . . . . . . . . . 76
11.4. {11.4} Detached Signatures . . . . . . . . . . . . . . . 77 10.3.2. {10.3.2} Symmetric-Key Algorithms . . . . . . . . . 76
12. {12} Enhanced Key Formats . . . . . . . . . . . . . . . . . . 78 10.3.3. {10.3.3} Hash Algorithms . . . . . . . . . . . . . . 76
12.1. {12.1} Key Structures . . . . . . . . . . . . . . . . . 78 10.3.4. {10.3.4} Compression Algorithms . . . . . . . . . . 77
12.2. {12.2} Key IDs and Fingerprints . . . . . . . . . . . . 79 11. {11} Packet Composition . . . . . . . . . . . . . . . . . . . 77
13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 80 11.1. {11.1} Transferable Public Keys . . . . . . . . . . . . 77
13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 80 11.2. {11.2} Transferable Secret Keys . . . . . . . . . . . . 79
13.2. ECDSA and ECDH Conversion Primitives . . . . . . . . . . 81 11.3. {11.3} OpenPGP Messages . . . . . . . . . . . . . . . . 79
13.3. EdDSA Point Format . . . . . . . . . . . . . . . . . . . 81 11.4. {11.4} Detached Signatures . . . . . . . . . . . . . . . 80
13.4. Key Derivation Function . . . . . . . . . . . . . . . . 82 12. {12} Enhanced Key Formats . . . . . . . . . . . . . . . . . . 80
13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 82 12.1. {12.1} Key Structures . . . . . . . . . . . . . . . . . 80
14. {13} Notes on Algorithms . . . . . . . . . . . . . . . . . . 85 12.2. {12.2} Key IDs and Fingerprints . . . . . . . . . . . . 82
14.1. {13.1} PKCS#1 Encoding in OpenPGP . . . . . . . . . . . 85 13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 83
14.1.1. {13.1.1} EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . 85 13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 84
14.1.2. {13.1.2} EME-PKCS1-v1_5-DECODE . . . . . . . . . . . 86 13.2. ECDSA and ECDH Conversion Primitives . . . . . . . . . . 84
14.1.3. {13.1.3} EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . 87 13.3. EdDSA Point Format . . . . . . . . . . . . . . . . . . . 84
14.2. {13.2} Symmetric Algorithm Preferences . . . . . . . . . 88 13.4. Key Derivation Function . . . . . . . . . . . . . . . . 85
14.3. {13.3} Other Algorithm Preferences . . . . . . . . . . . 89 13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 85
14.3.1. {13.3.1} Compression Preferences . . . . . . . . . . 89 14. {13} Notes on Algorithms . . . . . . . . . . . . . . . . . . 88
14.3.2. {13.3.2} Hash Algorithm Preferences . . . . . . . . 90 14.1. {13.1} PKCS#1 Encoding in OpenPGP . . . . . . . . . . . 88
14.4. {13.4} Plaintext . . . . . . . . . . . . . . . . . . . . 90 14.1.1. {13.1.1} EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . 88
14.5. {13.5} RSA . . . . . . . . . . . . . . . . . . . . . . . 90 14.1.2. {13.1.2} EME-PKCS1-v1_5-DECODE . . . . . . . . . . . 89
14.6. {13.6} DSA . . . . . . . . . . . . . . . . . . . . . . . 90 14.1.3. {13.1.3} EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . 90
14.7. {13.7} Elgamal . . . . . . . . . . . . . . . . . . . . . 91 14.2. {13.2} Symmetric Algorithm Preferences . . . . . . . . . 91
14.8. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 91 14.3. {13.3} Other Algorithm Preferences . . . . . . . . . . . 92
14.9. {13.8} Reserved Algorithm Numbers . . . . . . . . . . . 91 14.3.1. {13.3.1} Compression Preferences . . . . . . . . . . 92
14.10. {13.9} OpenPGP CFB Mode . . . . . . . . . . . . . . . . 92 14.3.2. {13.3.2} Hash Algorithm Preferences . . . . . . . . 93
14.11. {13.10} Private or Experimental Parameters . . . . . . . 93 14.4. {13.4} Plaintext . . . . . . . . . . . . . . . . . . . . 93
14.12. {13.11} Extension of the MDC System . . . . . . . . . . 93 14.5. {13.5} RSA . . . . . . . . . . . . . . . . . . . . . . . 93
14.13. {13.12} Meta-Considerations for Expansion . . . . . . . 94 14.6. {13.6} DSA . . . . . . . . . . . . . . . . . . . . . . . 93
15. {14} Security Considerations . . . . . . . . . . . . . . . . 94 14.7. {13.7} Elgamal . . . . . . . . . . . . . . . . . . . . . 94
16. Compatibility Profiles . . . . . . . . . . . . . . . . . . . 101 14.8. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 94
16.1. OpenPGP ECC Profile . . . . . . . . . . . . . . . . . . 101 14.9. {13.8} Reserved Algorithm Numbers . . . . . . . . . . . 94
16.2. Suite-B Profile . . . . . . . . . . . . . . . . . . . . 102 14.10. {13.9} OpenPGP CFB Mode . . . . . . . . . . . . . . . . 95
16.3. Security Strength at 192 Bits . . . . . . . . . . . . . 102 14.11. {13.10} Private or Experimental Parameters . . . . . . . 96
16.4. Security Strength at 128 Bits . . . . . . . . . . . . . 102 14.12. {13.11} Extension of the MDC System . . . . . . . . . . 96
17. {15} Implementation Nits . . . . . . . . . . . . . . . . . . 102 14.13. {13.12} Meta-Considerations for Expansion . . . . . . . 97
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 15. {14} Security Considerations . . . . . . . . . . . . . . . . 97
18.1. Normative References . . . . . . . . . . . . . . . . . . 104 16. Compatibility Profiles . . . . . . . . . . . . . . . . . . . 104
18.2. Informative References . . . . . . . . . . . . . . . . . 106 16.1. OpenPGP ECC Profile . . . . . . . . . . . . . . . . . . 104
Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 107 16.2. Suite-B Profile . . . . . . . . . . . . . . . . . . . . 105
A.1. Sample EdDSA key . . . . . . . . . . . . . . . . . . . . 107 16.3. Security Strength at 192 Bits . . . . . . . . . . . . . 105
A.2. Sample EdDSA signature . . . . . . . . . . . . . . . . . 108 16.4. Security Strength at 128 Bits . . . . . . . . . . . . . 105
Appendix B. ECC Point compression flag bytes . . . . . . . . . . 108 17. {15} Implementation Nits . . . . . . . . . . . . . . . . . . 105
Appendix C. Changes since RFC-4880 . . . . . . . . . . . . . . . 109 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 107
Appendix D. The principal authors of RFC-4880 are as follows: . 109 18.1. Normative References . . . . . . . . . . . . . . . . . . 107
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 109 18.2. Informative References . . . . . . . . . . . . . . . . . 110
Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 110
A.1. Sample EdDSA key . . . . . . . . . . . . . . . . . . . . 110
A.2. Sample EdDSA signature . . . . . . . . . . . . . . . . . 111
Appendix B. ECC Point compression flag bytes . . . . . . . . . . 111
Appendix C. Changes since RFC-4880 . . . . . . . . . . . . . . . 112
Appendix D. The principal authors of RFC-4880 are as follows: . 112
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 113
1. {1} Introduction 1. {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. The section numbers from RFC4880 are also enclosed in curly braces. The section numbers from RFC4880 are also
indicated in curly braces. } indicated 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 2440, "OpenPGP and key management functions. It is a revision of RFC 2440, "OpenPGP
skipping to change at page 22, line 46 skipping to change at page 23, line 11
structure. The object identifier for the type of hash being used is structure. The object identifier for the type of hash being used is
included in the structure. The hexadecimal representations for the included in the structure. The hexadecimal representations for the
currently defined hash algorithms are as follows: currently defined hash algorithms are as follows:
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
- SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04 - SHA2-224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04
- SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - SHA2-256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
- SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 - SHA2-384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
- SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 - SHA2-512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
The ASN.1 Object Identifiers (OIDs) are as follows: The ASN.1 Object Identifiers (OIDs) are as follows:
- MD5: 1.2.840.113549.2.5 - MD5: 1.2.840.113549.2.5
- RIPEMD-160: 1.3.36.3.2.1 - RIPEMD-160: 1.3.36.3.2.1
- SHA-1: 1.3.14.3.2.26 - SHA-1: 1.3.14.3.2.26
- SHA224: 2.16.840.1.101.3.4.2.4 - SHA2-224: 2.16.840.1.101.3.4.2.4
- SHA256: 2.16.840.1.101.3.4.2.1 - SHA2-256: 2.16.840.1.101.3.4.2.1
- SHA384: 2.16.840.1.101.3.4.2.2 - SHA2-384: 2.16.840.1.101.3.4.2.2
- SHA512: 2.16.840.1.101.3.4.2.3 - SHA2-512: 2.16.840.1.101.3.4.2.3
The full hash prefixes for these are as follows: The full hash prefixes for these are as follows:
- MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, - MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
0x04, 0x10 0x04, 0x10
- RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, - RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
- SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, - SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
- SHA224: 0x30, 0x2D, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - SHA2-224: 0x30, 0x2D, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
0x00, 0x04, 0x1C 0x00, 0x04, 0x1C
- SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - SHA2-256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
0x00, 0x04, 0x20 0x00, 0x04, 0x20
- SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - SHA2-384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
0x00, 0x04, 0x30 0x00, 0x04, 0x30
- SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, - SHA2-512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
0x00, 0x04, 0x40 0x00, 0x04, 0x40
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
skipping to change at page 32, line 27 skipping to change at page 32, line 27
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 below. description of the syntax is found in Section 8 below.
5.2.3.15. {5.2.3.15} Revocation Key 5.2.3.15. {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 25
fingerprint) octets of fingerprint)
V4 keys use the full 20 octet fingerprint; V5 keys use the leftmost
25 octets of the 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 found on a self-signature.
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
skipping to change at page 40, line 8 skipping to change at page 40, line 8
(1 octet key version number, N octets of fingerprint) (1 octet key version number, N octets of fingerprint)
The OpenPGP Key fingerprint of the key issuing the signature. This The OpenPGP Key fingerprint of the key issuing the signature. This
subpacket SHOULD be included in all signatures. If the version of subpacket SHOULD be included in all signatures. If the version of
the issuing key is 4 and an Issuer subpacket is also included in the the issuing key is 4 and an Issuer subpacket is also included in the
signature, the key ID of the Issuer subpacket MUST match the low 64 signature, the key ID of the Issuer subpacket MUST match the low 64
bits of the fingerprint. bits of the fingerprint.
Note that the length N of the fingerprint for a version 4 key is 20 Note that the length N of the fingerprint for a version 4 key is 20
octets. octets. For a version 5 key the leftmost 25 octets of the
fingerprint are used (N=25).
5.2.4. {5.2.4} Computing Signatures 5.2.4. {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.
skipping to change at page 40, line 33 skipping to change at page 40, line 34
a key packet with two-octet length.) A subkey binding signature a key packet with two-octet length.) 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 as
the first octet). Primary key revocation signatures (type 0x20) hash the first octet). Primary key revocation signatures (type 0x20) hash
only the key being revoked. Subkey revocation signature (type 0x28) only the key being revoked. Subkey revocation signature (type 0x28)
hash first the primary key and then the subkey being revoked. 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), the When a signature is made over a Signature packet (type 0x50), the
hash data starts with the octet 0x88, followed by the four-octet hash data starts with the octet 0x88, followed by the four-octet
length of the signature, and then the body of the Signature packet. length of the signature, and then the body of the Signature packet.
(Note that this is an old-style packet header for a Signature packet (Note that this is an old-style packet header for a Signature packet
with the length-of-length set to zero.) The unhashed subpacket data with the length-of-length set to zero.) The unhashed subpacket data
of the Signature packet being hashed is not included in the hash, and of the Signature packet being hashed is not included in the hash, and
the unhashed subpacket data length value is set to zero. the unhashed subpacket data length value is set to zero.
Once the data body is hashed, then a trailer is hashed. A V3 Once the data body is hashed, then a trailer is hashed. A V3
signature hashes five octets of the packet body, starting from the signature hashes five octets of the packet body, starting from the
signature type field. This data is the signature type, followed by signature type field. This data is the signature type, followed by
the four-octet signature time. A V4 signature hashes the packet body the four-octet signature time. A V4 or V5 signature hashes the
starting from its first field, the version number, through the end of packet body starting from its first field, the version number,
the hashed subpacket data. Thus, the fields hashed are the signature through the end of the hashed subpacket data. Thus, the fields
version, the signature type, the public-key algorithm, the hash hashed are the signature version, the signature type, the public-key
algorithm, the hashed subpacket length, and the hashed subpacket algorithm, the hash algorithm, the hashed subpacket length, and the
body. hashed subpacket body.
V4 signatures also hash in a final trailer of six octets: the version V4 signatures also hash in a final trailer of six octets: the version
of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, big- of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, big-
endian number that is the length of the hashed data from the endian number that is the length of the hashed data from the
Signature packet (note that this number does not include these final Signature packet (note that this number does not include these final
six octets). six octets).
V5 signatures instead hash in a ten-octet trailer: the version of the
Signature packet, i.e., 0x05; 0xFF; and an eight-octet, big-endian
number that is the length of the hashed data from the Signature
packet (note that this number does not include these final ten
octets).
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. {5.2.4.1} Subpacket Hints 5.2.4.1. {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 45, line 23 skipping to change at page 45, line 32
section "Enhanced Key Formats". section "Enhanced Key Formats".
A version 4 packet contains: A version 4 packet contains:
o A one-octet version number (4). o A one-octet version number (4).
o A four-octet number denoting the time that the key was created. o A four-octet number denoting the time that the key was created.
o A one-octet number denoting the public-key algorithm of this key. o A one-octet number denoting the public-key algorithm of this key.
o A series of multiprecision integers comprising the key material. o A series of values comprising the key material. This is
This algorithm-specific portion is: algorithm-specific and described in section XXXX.
Algorithm-Specific Fields for RSA public keys:
* multiprecision integer (MPI) of RSA public modulus n;
* MPI of RSA public encryption exponent e.
Algorithm-Specific Fields for DSA public keys:
* MPI of DSA prime p;
* MPI of DSA group order q (q is a prime divisor of p-1);
* MPI of DSA group generator g;
* MPI of DSA public-key value y (= g**x mod p where x is secret).
Algorithm-Specific Fields for Elgamal public keys:
* MPI of Elgamal prime p;
* MPI of Elgamal group generator g;
* MPI of Elgamal public key value y (= g**x mod p where x is
secret).
Algorithm-Specific Fields for ECDSA keys:
* 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
11{FIXME};
* a MPI of an EC point representing a public key.
Algorithm-Specific Fields for EdDSA keys:
* 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
NN{FIXME};
* a MPI of an EC point representing a public key Q as described
under EdDSA Point Format below.
Algorithm-Specific Fields for ECDH keys:
* 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 The version 5 format is similar to the version 4 format except for
Section 11{FIXME}; 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 MPI of an EC point representing a public key; A version 5 packet contains:
* a variable-length field containing KDF parameters, formatted as o A one-octet version number (5).
follows:
+ a one-octet size of the following fields; values 0 and 0xff o A four-octet number denoting the time that the key was created.
are reserved for future extensions;
+ a one-octet value 1, reserved for future extensions; o A one-octet number denoting the public-key algorithm of this key.
+ a one-octet hash function ID used with a KDF; o A four-octet scalar octet count for the following key material.
+ a one-octet algorithm ID for the symmetric algorithm used to
wrap the symmetric key used for the message encryption; see
Section 8 for details.
Observe that an ECDH public key is composed of the same sequence of o A series of values comprising the key material. This is
fields that define an ECDSA key, plus the KDF parameters field. algorithm-specific and described in section XXXX.
5.5.3. {5.5.3} Secret-Key Packet Formats 5.5.3. {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:
o A Public-Key or Public-Subkey packet, as described above. o A Public-Key or Public-Subkey packet, as described above.
o One octet indicating string-to-key usage conventions. Zero o 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.
o Only for a version 5 packet, a one-octet scalar octet count of the
next 3 optional fields.
o [Optional] If string-to-key usage octet was 255 or 254, a one- o [Optional] If string-to-key usage octet was 255 or 254, a one-
octet symmetric encryption algorithm. octet symmetric encryption algorithm.
o [Optional] If string-to-key usage octet was 255 or 254, a string- o [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.
o [Optional] If secret data is encrypted (string-to-key usage octet o [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.
o Plain or encrypted multiprecision integers comprising the secret o Only for a version 5 packet, a four-octet scalar octet count for
key data. These algorithm-specific fields are as described below. the following key material.
o Plain or encrypted series of values comprising the secret key
material. This is algorithm-specific and described in section
XXXX.
o If the string-to-key usage octet is zero or 255, then a two-octet o 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.
Algorithm-Specific Fields for RSA secret keys: Note that the version 5 packet format adds two count values to help
parsing packets with unknown S2K or public key algorithms.
* multiprecision integer (MPI) of RSA secret exponent d.
* MPI of RSA secret prime value p.
* MPI of RSA secret prime value q (p < q).
* MPI of u, the multiplicative inverse of p, mod q.
Algorithm-Specific Fields for DSA secret keys:
* MPI of DSA secret exponent x.
Algorithm-Specific Fields for Elgamal secret keys:
* MPI of Elgamal secret exponent x.
Algorithm-Specific Fields for ECDH or ECDSA secret keys:
* MPI of an integer representing the secret key, which is a
scalar of the public EC point.
Algorithm-Specific Fields for EdDSA keys:
* MPI of an integer representing the secret key, which is a
scalar of the public EC point.
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
modifying the secret key. modifying the secret key.
5.6. {5.6} Compressed Data Packet (Tag 8) 5.6. Algorithm-specific Parts of Keys
The public and secret key format specifies algorithm-specific parts
of a key. The following sections describe them in detail.
5.6.1. Algorithm-Specific Part for RSA Keys
The public key is this series of multiprecision integers:
o MPI of RSA public modulus n;
o MPI of RSA public encryption exponent e.
The secret key is this series of multiprecision integers:
o MPI of RSA secret exponent d;
o MPI of RSA secret prime value p;
o MPI of RSA secret prime value q (p < q);
o MPI of u, the multiplicative inverse of p, mod q.
5.6.2. Algorithm-Specific Part for DSA Keys
The public key is this series of multiprecision integers:
o MPI of DSA prime p;
o MPI of DSA group order q (q is a prime divisor of p-1);
o MPI of DSA group generator g;
o MPI of DSA public-key value y (= g**x mod p where x is secret).
The secret key is this single multiprecision integer:
o MPI of DSA secret exponent x.
5.6.3. Algorithm-Specific Part for Elgamal Keys
The public key is this series of multiprecision integers:
o MPI of Elgamal prime p;
o MPI of Elgamal group generator g;
o MPI of Elgamal public key value y (= g**x mod p where x is
secret).
The secret key is this single multiprecision integer:
o MPI of Elgamal secret exponent x.
5.6.4. Algorithm-Specific Part for ECDSA Keys
The public key is this series of values:
o 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
11{FIXME};
o a MPI of an EC point representing a public key.
The secret key is this single multiprecision integer:
o MPI of an integer representing the secret key, which is a scalar
of the public EC point.
5.6.5. Algorithm-Specific Part for EdDSA Keys
The public key is this series of values:
o 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
NN{FIXME};
o 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:
o 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:
o 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 11{FIXME};
o a MPI of an EC point representing a public key;
o a variable-length field containing KDF parameters, formatted as
follows:
* a one-octet size of the following fields; values 0 and 0xff are
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 algorithm ID for the symmetric algorithm used to
wrap the symmetric key used for the message encryption; see
Section 8 for details.
Observe that an ECDH public key is composed of the same sequence of
fields that define an ECDSA key, plus the KDF parameters field.
The secret key is this single multiprecision integer:
o MPI of an integer representing the secret key, which is a scalar
of the public EC point.
5.7. {5.6} Compressed Data Packet (Tag 8)
The Compressed Data packet contains compressed data. Typically, this The Compressed Data packet contains compressed data. Typically, this
packet is found as the contents of an encrypted packet, or following packet is found as the contents of an encrypted packet, or following
a Signature or One-Pass Signature packet, and contains a literal data a Signature or One-Pass Signature packet, and contains a literal data
packet. packet.
The body of this packet consists of: The body of this packet consists of:
o One octet that gives the algorithm used to compress the packet. o One octet that gives the algorithm used to compress the packet.
skipping to change at page 49, line 40 skipping to change at page 51, line 8
DEFLATE blocks. Note that PGP V2.6 uses 13 bits of compression. If DEFLATE blocks. Note that PGP V2.6 uses 13 bits of compression. If
an implementation uses more bits of compression, PGP V2.6 cannot an implementation uses more bits of compression, PGP V2.6 cannot
decompress it. decompress it.
ZLIB-compressed packets are compressed with RFC 1950 [RFC1950] ZLIB- ZLIB-compressed packets are compressed with RFC 1950 [RFC1950] ZLIB-
style blocks. style blocks.
BZip2-compressed packets are compressed using the BZip2 [BZ2] BZip2-compressed packets are compressed using the BZip2 [BZ2]
algorithm. algorithm.
5.7. {5.7} Symmetrically Encrypted Data Packet (Tag 9) 5.8. {5.7} Symmetrically Encrypted Data Packet (Tag 9)
The Symmetrically Encrypted Data packet contains data encrypted with The Symmetrically Encrypted Data packet contains data encrypted with
a symmetric-key algorithm. When it has been decrypted, it contains a symmetric-key algorithm. When it has been decrypted, it contains
other packets (usually a literal data packet or compressed data other packets (usually a literal data packet or compressed data
packet, but in theory other Symmetrically Encrypted Data packets or packet, but in theory other Symmetrically Encrypted Data packets or
sequences of packets that form whole OpenPGP messages). sequences of packets that form whole OpenPGP messages).
The body of this packet consists of: The body of this packet consists of:
o Encrypted data, the output of the selected symmetric-key cipher o Encrypted data, the output of the selected symmetric-key cipher
skipping to change at page 50, line 34 skipping to change at page 52, line 5
After encrypting the first block-size-plus-two octets, the CFB state After encrypting the first block-size-plus-two octets, the CFB state
is resynchronized. The last block-size octets of ciphertext are is resynchronized. The last block-size octets of ciphertext are
passed through the cipher and the block boundary is reset. passed through the cipher and the block boundary is reset.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. See the "Security Considerations" section for hints on incorrect. See the "Security Considerations" section for hints on
the proper use of this "quick check". the proper use of this "quick check".
5.8. {5.8} Marker Packet (Obsolete Literal Packet) (Tag 10) 5.9. {5.8} Marker Packet (Obsolete Literal Packet) (Tag 10)
An experimental version of PGP used this packet as the Literal An experimental version of PGP used this packet as the Literal
packet, but no released version of PGP generated Literal packets with packet, but no released version of PGP generated Literal packets with
this tag. With PGP 5.x, this packet has been reassigned and is this tag. With PGP 5.x, this packet has been reassigned and is
reserved for use as the Marker packet. reserved for use as the Marker packet.
The body of this packet consists of: The body of this packet consists of:
o The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). o The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).
Such a packet MUST be ignored when received. It may be placed at the Such a packet MUST be ignored when received. It may be placed at the
beginning of a message that uses features not available in PGP 2.6.x beginning of a message that uses features not available in PGP 2.6.x
in order to cause that version to report that newer software is in order to cause that version to report that newer software is
necessary to process the message. necessary to process the message.
5.9. {5.9} Literal Data Packet (Tag 11) 5.10. {5.9} Literal Data Packet (Tag 11)
A Literal Data packet contains the body of a message; data that is A Literal Data packet contains the body of a message; data that is
not to be further interpreted. not to be further interpreted.
The body of this packet consists of: The body of this packet consists of:
o A one-octet field that describes how the data is formatted. o A one-octet field that describes how the data is formatted.
If it is a 'b' (0x62), then the Literal packet contains binary If it is a 'b' (0x62), then the Literal packet contains binary
data. If it is a 't' (0x74), then it contains text data, and thus data. If it is a 't' (0x74), then it contains text data, and thus
skipping to change at page 52, line 5 skipping to change at page 53, 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.
o The remainder of the packet is literal data. o 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.
5.10. {5.10} Trust Packet (Tag 12) 5.11. {5.10} Trust Packet (Tag 12)
The Trust packet is used only within keyrings and is not normally The Trust packet is used only within keyrings and is not normally
exported. Trust packets contain data that record the user's exported. Trust packets contain data that record the user's
specifications of which key holders are trustworthy introducers, specifications of which key holders are trustworthy introducers,
along with other information that implementing software uses for along with other information that implementing software uses for
trust information. The format of Trust packets is defined by a given trust information. The format of Trust packets is defined by a given
implementation. implementation.
Trust packets SHOULD NOT be emitted to output streams that are Trust packets SHOULD NOT be emitted to output streams that are
transferred to other users, and they SHOULD be ignored on any input transferred to other users, and they SHOULD be ignored on any input
other than local keyring files. other than local keyring files.
5.11. {5.11} User ID Packet (Tag 13) 5.12. {5.11} User ID Packet (Tag 13)
A User ID packet consists of UTF-8 text that is intended to represent A User ID packet consists of UTF-8 text that is intended to represent
the name and email address of the key holder. By convention, it the name and email address of the key holder. By convention, it
includes an RFC 2822 [RFC2822] mail name-addr, but there are no includes an RFC 2822 [RFC2822] mail name-addr, but there are no
restrictions on its content. The packet length in the header restrictions on its content. The packet length in the header
specifies the length of the User ID. specifies the length of the User ID.
5.12. {5.12} User Attribute Packet (Tag 17) 5.13. {5.12} User Attribute Packet (Tag 17)
The User Attribute packet is a variation of the User ID packet. It The User Attribute packet is a variation of the User ID packet. It
is capable of storing more types of data than the User ID packet, is capable of storing more types of data than the User ID packet,
which is limited to text. Like the User ID packet, a User Attribute which is limited to text. Like the User ID packet, a User Attribute
packet may be certified by the key owner ("self-signed") or any other packet may be certified by the key owner ("self-signed") or any other
key owner who cares to certify it. Except as noted, a User Attribute key owner who cares to certify it. Except as noted, a User Attribute
packet may be used anywhere that a User ID packet may be used. packet may be used anywhere that a User ID packet may be used.
While User Attribute packets are not a required part of the OpenPGP While User Attribute packets are not a required part of the OpenPGP
standard, implementations SHOULD provide at least enough standard, implementations SHOULD provide at least enough
skipping to change at page 53, line 16 skipping to change at page 54, line 28
| Type | Attribute Subpacket | | Type | Attribute Subpacket |
+----------+------------------------------+ +----------+------------------------------+
| 1 | Image Attribute Subpacket | | 1 | Image Attribute Subpacket |
| [TBD1] | User ID Attribute Subpacket | | [TBD1] | User ID Attribute Subpacket |
| 100-110 | Private/Experimental Use | | 100-110 | Private/Experimental Use |
+----------+------------------------------+ +----------+------------------------------+
An implementation SHOULD ignore any subpacket of a type that it does An implementation SHOULD ignore any subpacket of a type that it does
not recognize. not recognize.
5.12.1. {5.12.1} The Image Attribute Subpacket 5.13.1. {5.12.1} The Image Attribute Subpacket
The Image Attribute subpacket is used to encode an image, presumably The Image Attribute subpacket is used to encode an image, presumably
(but not required to be) that of the key owner. (but not required to be) that of the key owner.
The Image Attribute subpacket begins with an image header. The first The Image Attribute subpacket begins with an image header. The first
two octets of the image header contain the length of the image two octets of the image header contain the length of the image
header. Note that unlike other multi-octet numerical values in this header. Note that unlike other multi-octet numerical values in this
document, due to a historical accident this value is encoded as a document, due to a historical accident this value is encoded as a
little-endian number. The image header length is followed by a little-endian number. The image header length is followed by a
single octet for the image header version. The only currently single octet for the image header version. The only currently
skipping to change at page 53, line 48 skipping to change at page 55, line 12
The rest of the image subpacket contains the image itself. As the The rest of the image subpacket contains the image itself. As the
only currently defined image type is JPEG, the image is encoded in only currently defined image type is JPEG, the image is encoded in
the JPEG File Interchange Format (JFIF), a standard file format for the JPEG File Interchange Format (JFIF), a standard file format for
JPEG images [JFIF]. JPEG images [JFIF].
An implementation MAY try to determine the type of an image by An implementation MAY try to determine the type of an image by
examination of the image data if it is unable to handle a particular examination of the image data if it is unable to handle a particular
version of the image header or if a specified encoding format value version of the image header or if a specified encoding format value
is not recognized. is not recognized.
5.12.2. User ID Attribute Subpacket 5.13.2. User ID Attribute Subpacket
A User ID Attribute subpacket has type #[IANA -- assignment TBD1]. A User ID Attribute subpacket has type #[IANA -- assignment TBD1].
A User ID Attribute subpacket, just like a User ID packet, consists A User ID Attribute subpacket, just like a User ID packet, consists
of UTF-8 text that is intended to represent the name and email of UTF-8 text that is intended to represent the name and email
address of the key holder. By convention, it includes an RFC 2822 address of the key holder. By convention, it includes an RFC 2822
[RFC2822] mail name-addr, but there are no restrictions on its [RFC2822] mail name-addr, but there are no restrictions on its
content. For devices using OpenPGP for device certificates, it may content. For devices using OpenPGP for device certificates, it may
just be the device identifier. The packet length in the header just be the device identifier. The packet length in the header
specifies the length of the User ID. specifies the length of the User ID.
Because User Attribute subpackets can be used anywhere a User ID Because User Attribute subpackets can be used anywhere a User ID
packet can be used, implementations MAY choose to trust a signed User packet can be used, implementations MAY choose to trust a signed User
Attribute subpacket that includes a User ID Attribute subpacket. Attribute subpacket that includes a User ID Attribute subpacket.
5.13. {5.13} Sym. Encrypted Integrity Protected Data Packet (Tag 18) 5.14. {5.13} Sym. Encrypted Integrity Protected Data Packet (Tag 18)
The Symmetrically Encrypted Integrity Protected Data packet is a The Symmetrically Encrypted Integrity Protected Data packet is a
variant of the Symmetrically Encrypted Data packet. It is a new variant of the Symmetrically Encrypted Data packet. It is a new
feature created for OpenPGP that addresses the problem of detecting a feature created for OpenPGP that addresses the problem of detecting a
modification to encrypted data. It is used in combination with a modification to encrypted data. It is used in combination with a
Modification Detection Code packet. Modification Detection Code packet.
There is a corresponding feature in the features Signature subpacket There is a corresponding feature in the features Signature subpacket
that denotes that an implementation can properly use this packet that denotes that an implementation can properly use this packet
type. An implementation MUST support decrypting these packets and type. An implementation MUST support decrypting these packets and
skipping to change at page 57, line 19 skipping to change at page 58, line 30
intercepted from Bob. (Note also that if Bob wishes to intercepted from Bob. (Note also that if Bob wishes to
communicate secretly with Alice, but without authentication or communicate secretly with Alice, but without authentication or
identification and with a threat model that includes forgers, he identification and with a threat model that includes forgers, he
has a problem that transcends mere cryptography.) has a problem that transcends mere cryptography.)
Note also that unlike nearly every other OpenPGP subsystem, Note also that unlike nearly every other OpenPGP subsystem,
there are no parameters in the MDC system. It hard-defines there are no parameters in the MDC system. It hard-defines
SHA-1 as its hash function. This is not an accident. It is an SHA-1 as its hash function. This is not an accident. It is an
intentional choice to avoid downgrade and cross-grade attacks intentional choice to avoid downgrade and cross-grade attacks
while making a simple, fast system. (A downgrade attack would while making a simple, fast system. (A downgrade attack would
be an attack that replaced SHA-256 with SHA-1, for example. A be an attack that replaced SHA2-256 with SHA-1, for example. A
cross-grade attack would replace SHA-1 with another 160-bit cross-grade attack would replace SHA-1 with another 160-bit
hash, such as RIPE-MD/160, for example.) hash, such as RIPE-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 and cryptography, it may be desirable to upgrade the MDC system
to a new hash function. See Section 13.11 in the "IANA to a new hash function. See Section 13.11 in the "IANA
Considerations" for guidance. Considerations" for guidance.
5.14. {5.14} Modification Detection Code Packet (Tag 19) 5.15. {5.14} Modification Detection Code Packet (Tag 19)
The Modification Detection Code packet contains a SHA-1 hash of The Modification Detection Code packet contains a SHA-1 hash of
plaintext data, which is used to detect message modification. It is plaintext data, which is used to detect message modification. It is
only used with a Symmetrically Encrypted Integrity Protected Data only used with a Symmetrically Encrypted Integrity Protected Data
packet. The Modification Detection Code packet MUST be the last packet. The Modification Detection Code packet MUST be the last
packet in the plaintext data 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.
A Modification Detection Code packet MUST have a length of 20 octets. A Modification Detection Code packet MUST have a length of 20 octets.
skipping to change at page 67, line 19 skipping to change at page 68, line 19
+-----------+----------------------------------------------------+ +-----------+----------------------------------------------------+
| ID | Algorithm | | ID | Algorithm |
+-----------+----------------------------------------------------+ +-----------+----------------------------------------------------+
| 1 | RSA (Encrypt or Sign) [HAC] | | 1 | RSA (Encrypt or Sign) [HAC] |
| 2 | RSA Encrypt-Only [HAC] | | 2 | RSA Encrypt-Only [HAC] |
| 3 | RSA Sign-Only [HAC] | | 3 | RSA Sign-Only [HAC] |
| 16 | Elgamal (Encrypt-Only) [ELGAMAL] [HAC] | | 16 | Elgamal (Encrypt-Only) [ELGAMAL] [HAC] |
| 17 | DSA (Digital Signature Algorithm) [FIPS186] [HAC] | | 17 | DSA (Digital Signature Algorithm) [FIPS186] [HAC] |
| 18 | ECDH public key algorithm | | 18 | ECDH public key algorithm |
| 19 | ECDSA public key algorithm [FIPS186-3] | | 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 | | 21 | Reserved for Diffie-Hellman |
| | (X9.42, as defined for IETF-S/MIME) | | | (X9.42, as defined for IETF-S/MIME) |
| 22 | EdDSA [I-D.irtf-cfrg-eddsa] | | 22 | EdDSA [I-D.irtf-cfrg-eddsa] |
| 100--110 | Private/Experimental algorithm | | 100--110 | Private/Experimental algorithm |
+-----------+----------------------------------------------------+ +-----------+----------------------------------------------------+
Implementations MUST implement DSA and ECDSA for signatures, and Implementations MUST implement DSA and ECDSA for signatures, and
Elgamal and ECDH for encryption. Implementations SHOULD implement Elgamal and ECDH for encryption. Implementations SHOULD implement
RSA keys (1). RSA Encrypt-Only (2) and RSA Sign-Only are deprecated RSA keys (1). RSA Encrypt-Only (2) and RSA Sign-Only are deprecated
and SHOULD NOT be generated, but may be interpreted. See and SHOULD NOT be generated, but may be interpreted. See
Section 13.5. See Section 13.8 for notes Elgamal Encrypt or Sign Section 13.5. See Section 13.8 for notes on Elgamal Encrypt or Sign
(20), and X9.42 (21). Implementations MAY implement any other (20), and X9.42 (21). Implementations MAY implement any other
algorithm. 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.5 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 in | Curve name | | ASN.1 Object | OID | Curve OID bytes | Curve name |
| Identifier | len | hexadecimal | | | Identifier | len | in hexadecimal | |
| | | representation | | | | | representation | |
+------------------------+-----+----------------------+-------------+ +------------------------+-----+------------------+-----------------+
| 1.2.840.10045.3.1.7 | 8 | 2A 86 48 CE 3D 03 01 | NIST curve | | 1.2.840.10045.3.1.7 | 8 | 2A 86 48 CE 3D | NIST P-256 |
| | | 07 | P-256 | | | | 03 01 07 | |
| 1.3.132.0.34 | 5 | 2B 81 04 00 22 | NIST curve | | 1.3.132.0.34 | 5 | 2B 81 04 00 22 | NIST P-384 |
| | | | 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 curve | | 1.3.36.3.3.2.8.1.1.7 | 9 | 2B 24 03 03 02 | brainpoolP256r1 |
| | | | P-521 | | | | 08 01 01 07 | |
| 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 | | 1.3.36.3.3.2.8.1.1.13 | 9 | 2B 24 03 03 02 | brainpoolP512r1 |
| | | 0F 01 | | | | | 08 01 01 0D | |
+------------------------+-----+----------------------+-------------+ | 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 |
| | | 97 55 01 05 01 | |
+------------------------+-----+------------------+-----------------+
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
representing the Object Identifier tag, and the second omitted field representing the Object Identifier tag, and the second omitted field
is the length of the Object Identifier body. For example, the is the length of the Object Identifier body. For example, the
complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A
86 48 CE 3D 03 01 07", from which the first entry in the table above 86 48 CE 3D 03 01 07", from which the first entry in the table above
is constructed by omitting the first two octets. Only the truncated is constructed by omitting the first two octets. Only the truncated
skipping to change at page 69, line 39 skipping to change at page 71, line 14
+-----------+---------------------------------+--------------+ +-----------+---------------------------------+--------------+
| ID | Algorithm | Text Name | | ID | Algorithm | Text Name |
+-----------+---------------------------------+--------------+ +-----------+---------------------------------+--------------+
| 1 | MD5 [HAC] | "MD5" | | 1 | MD5 [HAC] | "MD5" |
| 2 | SHA-1 [FIPS180] | "SHA1" | | 2 | SHA-1 [FIPS180] | "SHA1" |
| 3 | RIPE-MD/160 [HAC] | "RIPEMD160" | | 3 | RIPE-MD/160 [HAC] | "RIPEMD160" |
| 4 | Reserved | | | 4 | Reserved | |
| 5 | Reserved | | | 5 | Reserved | |
| 6 | Reserved | | | 6 | Reserved | |
| 7 | Reserved | | | 7 | Reserved | |
| 8 | SHA256 [FIPS180] | "SHA256" | | 8 | SHA2-256 [FIPS180] | "SHA256" |
| 9 | SHA384 [FIPS180] | "SHA384" | | 9 | SHA2-384 [FIPS180] | "SHA384" |
| 10 | SHA512 [FIPS180] | "SHA512" | | 10 | SHA2-512 [FIPS180] | "SHA512" |
| 11 | SHA224 [FIPS180] | "SHA224" | | 11 | SHA2-224 [FIPS180] | "SHA224" |
| 12 | SHA3-256 [FIPS202] | "SHA3-256" |
| 13 | Reserved | |
| 14 | SHA3-512 [FIPS202] | "SHA3-512" |
| 100--110 | Private/Experimental algorithm | | | 100--110 | Private/Experimental algorithm | |
+-----------+---------------------------------+--------------+ +-----------+---------------------------------+--------------+
Implementations MUST implement SHA-1. Implementations MAY implement Implementations MUST implement SHA2-256. Implementations MAY
other algorithms. MD5 is deprecated. implement other algorithms. Implementations SHOULD NOT create
messages which require the use of SHA-1 with the exception of
computing version 4 key fingerprints and for purposes of the MDC
packet. Implementations SHOULD NOT use MD5 or RIPE-MD/160.
10. {10} IANA Considerations 10. {10} IANA Considerations
OpenPGP is highly parameterized, and consequently there are a number OpenPGP is highly parameterized, and consequently there are a number
of considerations for allocating parameters for extensions. This of considerations for allocating parameters for extensions. This
section describes how IANA should look at extensions to the protocol section describes how IANA should look at extensions to the protocol
as described in this document. as described in this document.
10.1. {10.1} New String-to-Key Specifier Types 10.1. {10.1} New String-to-Key Specifier Types
skipping to change at page 75, line 7 skipping to change at page 77, line 7
OpenPGP specifies a number of hash algorithms. This specification OpenPGP specifies a number of hash algorithms. This specification
creates a registry of hash algorithm identifiers. The registry creates a registry of hash algorithm identifiers. The registry
includes the algorithm name, a text representation of that name, its includes the algorithm name, a text representation of that name, its
block size, an OID hash prefix, and a reference to the defining block size, an OID hash prefix, and a reference to the defining
specification. The initial values for this registry can be found in specification. The initial values for this registry can be found in
Section 9 for the algorithm identifiers and text names, and Section 9 for the algorithm identifiers and text names, and
Section 5.2.2 for the OIDs and expanded signature prefixes. Adding a Section 5.2.2 for the OIDs and expanded signature prefixes. Adding a
new hash algorithm MUST be done through the IETF CONSENSUS method, as new hash algorithm MUST be done through the IETF CONSENSUS method, as
described in [RFC2434]. described in [RFC2434].
This document requests IANA register the following hash algorithms:
+-----+------------+------------+
| ID | Algorithm | Reference |
+-----+------------+------------+
| 12 | SHA3-256 | This doc |
| 13 | Reserved | |
| 14 | SHA3-512 | This doc |
+-----+------------+------------+
[Notes to RFC-Editor: Please remove the table above on publication.
It is desirable not to reuse old or reserved algorithms because some
existing tools might print a wrong description. The ID 13 has been
reserved so that the SHA3 algorithm IDs align nicely with their SHA2
counterparts.]
10.3.4. {10.3.4} Compression Algorithms 10.3.4. {10.3.4} Compression Algorithms
OpenPGP specifies a number of compression algorithms. This OpenPGP specifies a number of compression algorithms. This
specification creates a registry of compression algorithm specification creates a registry of compression algorithm
identifiers. The registry includes the algorithm name and a identifiers. The registry includes the algorithm name and a
reference to the defining specification. The initial values for this reference to the defining specification. The initial values for this
registry can be found in Section 9.3. Adding a new compression key registry can be found in Section 9.3. Adding a new compression key
algorithm MUST be done through the IETF CONSENSUS method, as algorithm MUST be done through the IETF CONSENSUS method, as
described in [RFC2434]. described in [RFC2434].
skipping to change at page 80, line 7 skipping to change at page 82, line 23
and MD5 are deprecated. and MD5 are deprecated.
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
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) high-order length octet of (b)-(e) (1 octet) a.2) two-octet scalar octet count of (b)-(e)
a.3) low-order length octet of (b)-(e) (1 octet)
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 0x99,
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 five named prime field curves, defined in
[FIPS186-3] as "Curve P-256", "Curve P-384", and "Curve P-521". [FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521"; and
defined in [RFC5639] as "brainpoolP256r1", and "brainpoolP512r1".
Further curve "Ed25519", defined in [I-D.irtf-cfrg-eddsa] is Further curve "Ed25519", defined in [I-D.irtf-cfrg-eddsa] is
referenced for use with the EdDSA algorithm. referenced for use with the EdDSA algorithm.
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 only defines the uncompressed point format for ECDSA This document only defines the uncompressed point format for ECDSA
skipping to change at page 82, line 14 skipping to change at page 85, line 17
For example, the length of a public key for the curve Ed25519 is 263 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 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the
native value of the public key. native value of the public key.
13.4. Key Derivation Function 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-3] or stronger is REQUIRED. See Section 12{FIXME} SHA2-256 [FIPS180] or stronger is REQUIRED. See Section 12{FIXME}
for the details regarding the choice of the hash function. for the 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
skipping to change at page 83, line 39 skipping to change at page 86, line 41
* 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 8 wrap the symmetric key for message encryption; see Section 8
for details for details
o 20 octets representing the UTF-8 encoding of the string "Anonymous o 20 octets representing the UTF-8 encoding of the string "Anonymous
Sender ", which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 Sender ", which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73
20 53 65 6E 64 65 72 20 20 20 20 20 53 65 6E 64 65 72 20 20 20 20
o 20 octets representing a recipient encryption subkey or a master o 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. the decryption. For version 5 keys the 20 leftmost octets of the
fingerprint are used.
The size of the KDF parameters sequence, defined above, is either 54 The size of the KDF parameters sequence, defined above, is either 54
for the NIST curve P-256 or 51 for the curves P-384 and P-521. for the NIST curve P-256 or 51 for the curves P-384 and P-521.
The key wrapping method is described in [RFC3394]. KDF produces a The key wrapping method is described in [RFC3394]. KDF produces a
symmetric key that is used as a key-encryption key (KEK) as specified symmetric key that is used as a key-encryption key (KEK) as specified
in [RFC3394]. Refer to Section 13{FIXME} for the details regarding in [RFC3394]. Refer to Section 13{FIXME} for the details regarding
the choice of the KEK algorithm, which SHOULD be one of three AES the choice of the KEK algorithm, which SHOULD be one of three AES
algorithms. Key wrapping and unwrapping is performed with the algorithms. Key wrapping and unwrapping is performed with the
default initial value of [RFC3394]. default initial value of [RFC3394].
skipping to change at page 90, line 17 skipping to change at page 93, line 17
Typically, the choice of a hash algorithm is something the signer Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer rarely knows who is does, rather than the verifier, because a signer rarely knows who is
going to be verifying the signature. This preference, though, allows going to be verifying the signature. This preference, though, allows
a protocol based upon digital signatures ease in negotiation. a protocol based upon digital signatures ease in negotiation.
Thus, if Alice is authenticating herself to Bob with a signature, it Thus, if Alice is authenticating herself to Bob with a signature, it
makes sense for her to use a hash algorithm that Bob's software uses. makes sense for her to use a hash algorithm that Bob's software uses.
This preference allows Bob to state in his key which algorithms Alice This preference allows Bob to state in his key which algorithms Alice
may use. may use.
Since SHA1 is the MUST-implement hash algorithm, if it is not Since SHA2-256 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly. good form to place it there explicitly.
14.4. {13.4} Plaintext 14.4. {13.4} Plaintext
Algorithm 0, "plaintext", may only be used to denote secret keys that Algorithm 0, "plaintext", may only be used to denote secret keys that
are stored in the clear. Implementations MUST NOT use plaintext in are stored in the clear. Implementations MUST NOT use plaintext in
Symmetrically Encrypted Data packets; they must use Literal Data Symmetrically Encrypted Data packets; they must use Literal Data
packets to encode unencrypted or literal data. packets to encode unencrypted or literal data.
skipping to change at page 90, line 48 skipping to change at page 93, line 48
14.6. {13.6} DSA 14.6. {13.6} DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
1024 bits. It MUST NOT implement a DSA key with a q size of less 1024 bits. It MUST NOT implement a DSA key with a q size of less
than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the
q size MUST be a multiple of 8 bits. The Digital Signature Standard q size MUST be a multiple of 8 bits. The Digital Signature Standard
(DSS) [FIPS186] specifies that DSA be used in one of the following (DSS) [FIPS186] specifies that DSA be used in one of the following
ways: ways:
o 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or o 1024-bit key, 160-bit q, SHA-1, SHA2--224, SHA2-256, SHA2-384, or
SHA-512 hash SHA2-512 hash
o 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 o 2048-bit key, 224-bit q, SHA2-224, SHA2-256, SHA2-384, or SHA2-512
hash hash
o 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash o 2048-bit key, 256-bit q, SHA2-256, SHA2-384, or SHA2-512 hash
o 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash o 3072-bit key, 256-bit q, SHA2-256, SHA2-384, or SHA2-512 hash
The above key and q size pairs were chosen to best balance the The above key and q size pairs were chosen to best balance the
strength of the key with the strength of the hash. Implementations strength of the key with the strength of the hash. Implementations
SHOULD use one of the above key and q size pairs when generating DSA SHOULD use one of the above key and q size pairs when generating DSA
keys. If DSS compliance is desired, one of the specified SHA hashes keys. If DSS compliance is desired, one of the specified SHA hashes
must be used as well. [FIPS186] is the ultimate authority on DSS, must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance. and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160-bit q Note that earlier versions of this standard only allowed a 160-bit q
with no truncation allowed, so earlier implementations may not be with no truncation allowed, so earlier implementations may not be
skipping to change at page 94, line 4 skipping to change at page 97, line 4
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
packet numbers for each new hash function in a space that is limited packet numbers for each new hash function in a space that is limited
to a maximum of 60). to a maximum of 60).
Another simple way to extend the MDC system is to create new versions Another simple way to extend the MDC system is to create new versions
of packet 18, and reflect this in packet 19. For example, suppose of packet 18, and reflect this in packet 19. For example, suppose
that V2 of packet 18 implicitly used SHA-256. This would require that V2 of packet 18 implicitly used SHA2-256. This would require
packet 19 to have a length of 32 octets. The change in the version packet 19 to have a length of 32 octets. The change in the version
in packet 18 and the size of packet 19 prevent a downgrade attack. in packet 18 and the size of packet 19 prevent a downgrade attack.
There are two drawbacks to this latter approach. The first is that There are two drawbacks to this latter approach. The first is that
using the version number of a packet to carry algorithm information using the version number of a packet to carry algorithm information
is not tidy from a protocol-design standpoint. It is possible that is not tidy from a protocol-design standpoint. It is possible that
there might be several versions of the MDC system in common use, but there might be several versions of the MDC system in common use, but
this untidiness would reflect untidiness in cryptographic consensus this untidiness would reflect untidiness in cryptographic consensus
about hash function security. The second is that different versions about hash function security. The second is that different versions
of packet 19 would have to have unique sizes. If there were two of packet 19 would have to have unique sizes. If there were two
skipping to change at page 95, line 19 skipping to change at page 98, line 19
o Certain operations in this specification involve the use of random o Certain operations in this specification involve the use of random
numbers. An appropriate entropy source should be used to generate numbers. An appropriate entropy source should be used to generate
these numbers (see [RFC4086]). these numbers (see [RFC4086]).
o The MD5 hash algorithm has been found to have weaknesses, with o The MD5 hash algorithm has been found to have weaknesses, with
collisions found in a number of cases. MD5 is deprecated for use collisions found in a number of cases. MD5 is deprecated for use
in OpenPGP. Implementations MUST NOT generate new signatures in OpenPGP. Implementations MUST NOT generate new signatures
using MD5 as a hash function. They MAY continue to consider old using MD5 as a hash function. They MAY continue to consider old
signatures that used MD5 as valid. signatures that used MD5 as valid.
o SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512, o SHA2-224 and SHA2-384 require the same work as SHA2-256 and
respectively. In general, there are few reasons to use them SHA2-512, respectively. In general, there are few reasons to use
outside of DSS compatibility. You need a situation where one them outside of DSS compatibility. You need a situation where one
needs more security than smaller hashes, but does not want to have needs more security than smaller hashes, but does not want to have
the full 256-bit or 512-bit data length. the full 256-bit or 512-bit data length.
o Many security protocol designers think that it is a bad idea to o Many security protocol designers think that it is a bad idea to
use a single key for both privacy (encryption) and integrity use a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces (signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption behind the V4 key format with separate signature and encryption
keys. If you as an implementer promote dual-use keys, you should keys. If you as an implementer promote dual-use keys, you should
at least be aware of this controversy. at least be aware of this controversy.
skipping to change at page 98, line 20 skipping to change at page 101, line 20
timing information about the check can be exposed to an attacker, timing information about the check can be exposed to an attacker,
particularly via an automated service that allows rapidly repeated particularly via an automated service that allows rapidly repeated
queries. queries.
On the other hand, it is inconvenient to the user to be informed On the other hand, it is inconvenient to the user to be informed
that they typed in the wrong passphrase only after a petabyte of that they typed in the wrong passphrase only after a petabyte of
data is decrypted. There are many cases in cryptographic data is decrypted. There are many cases in cryptographic
engineering where the implementer must use care and wisdom, and engineering where the implementer must use care and wisdom, and
this is one. this is one.
o Refer to [FIPS186-3], B.4.1, for the method to generate a o Refer to [FIPS186], B.4.1, for the method to generate a uniformly
uniformly distributed ECC private key. distributed ECC private key.
o The curves proposed in this document correspond to the symmetric o The curves proposed in this document correspond to the symmetric
key sizes 128 bits, 192 bits, and 256 bits, as described in the key sizes 128 bits, 192 bits, and 256 bits, as described in the
table below. This allows a compliant application to offer table below. This allows a compliant application to offer
balanced public key security, which is compatible with the balanced public key security, which is compatible with the
symmetric key strength for each AES algorithm defined here. symmetric key strength for each AES algorithm defined here.
The following table defines the hash and the symmetric encryption The following table defines the hash and the symmetric encryption
algorithm that SHOULD be used with a given curve for ECDSA or algorithm that SHOULD be used with a given curve for ECDSA or
ECDH. A stronger hash algorithm or a symmetric key algorithm MAY ECDH. A stronger hash algorithm or a symmetric key algorithm MAY
skipping to change at page 100, line 30 skipping to change at page 103, line 30
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.
o Although technically possible, the EdDSA algorithm MUST NOT be o Although technically possible, the EdDSA algorithm MUST NOT be
used with a digest algorithms weaker than SHA-256. used with a digest algorithms weaker than SHA2-256.
OpenPGP was designed with security in mind, with many smart, OpenPGP was designed with security in mind, with many smart,
intelligent people spending a lot of time thinking about the intelligent people spending a lot of time thinking about the
ramifications of their decisions. Removing the requirement for self- ramifications of their decisions. Removing the requirement for self-
certifying User ID (and User Attribute) packets on a key means that certifying User ID (and User Attribute) packets on a key means that
someone could surreptitiously add an unwanted ID to a key and sign someone could surreptitiously add an unwanted ID to a key and sign
it. If enough "trusted" people sign that surreptitious identity then it. If enough "trusted" people sign that surreptitious identity then
other people might believe it. The attack could wind up sending other people might believe it. The attack could wind up sending
encrypted mail destined for alice to some other target, bob, because encrypted mail destined for alice to some other target, bob, because
someone added "alice" to bob's key without bob's consent. someone added "alice" to bob's key without bob's consent.
skipping to change at page 101, line 38 skipping to change at page 104, line 38
Combining the User ID with the User Attribute means that an ID and Combining the User ID with the User Attribute means that an ID and
image would not be separable. For a person this is probably not image would not be separable. For a person this is probably not
good, but for a device it's unlikely the image will change so it good, but for a device it's unlikely the image will change so it
makes sense to combine the ID and image into a single signed packet makes sense to combine the ID and image into a single signed packet
with a single signature. with a single signature.
16. Compatibility Profiles 16. Compatibility Profiles
16.1. OpenPGP ECC Profile 16.1. OpenPGP ECC Profile
A compliant application MUST implement NIST curve P-256, MAY A compliant application MUST implement NIST curve P-256, SHOULD
implement NIST curve P-384, and SHOULD implement NIST curve P-521, as implement NIST curve P-521, SHOULD implemend Ed25519, SHOULD
defined in Section 11. A compliant application MUST implement implement Curve25519, MAY implement NIST curve P-384, MAY implement
SHA2-256 and SHOULD implement SHA2-384 and SHA2-512. A compliant brainpoolP256r1, MAY implement brainpoolP512r1, and MAY implement
application MUST implement AES-128 and SHOULD implement AES-256. Curve25519, as defined in Section 11. 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 13{FIXME} regarding the A compliant application SHOULD follow Section 13{FIXME} regarding the
choice of the following algorithms for each curve: choice of the following algorithms for each curve:
o the KDF hash algorithm, o the KDF hash algorithm,
o the KEK algorithm, o the KEK algorithm,
o the message digest algorithm and the hash algorithm used in the o the message digest algorithm and the hash algorithm used in the
key certifications, key certifications,
o the symmetric algorithm used for message encryption. o the symmetric algorithm used for message encryption.
It is recommended that the chosen symmetric algorithm for message It is recommended that the chosen symmetric algorithm for message
encryption be no less secure than the KEK algorithm. encryption be no less secure than the KEK algorithm.
16.2. Suite-B Profile 16.2. Suite-B Profile
skipping to change at page 102, line 31 skipping to change at page 105, line 33
this document. this document.
16.3. Security Strength at 192 Bits 16.3. Security Strength at 192 Bits
To achieve the security strength of 192 bits, [SuiteB] requires NIST To achieve the security strength of 192 bits, [SuiteB] requires NIST
curve P-384, AES-256, and SHA2-384. The symmetric algorithm curve P-384, AES-256, and SHA2-384. The symmetric algorithm
restriction means that the algorithm of KEK used for key wrapping in restriction means that the algorithm of KEK used for key wrapping in
Section 8 and an OpenPGP session key used for message encryption must Section 8 and an OpenPGP session key used for message encryption must
be AES-256. The hash algorithm restriction means that the hash be AES-256. The hash algorithm restriction means that the hash
algorithms of KDF and the OpenPGP message digest calculation must be algorithms of KDF and the OpenPGP message digest calculation must be
SHA-384. SHA2-384.
16.4. Security Strength at 128 Bits 16.4. Security Strength at 128 Bits
The set of algorithms in Section 12.2.1{FIXME} is extended to allow The set of algorithms in Section 12.2.1{FIXME} is extended to allow
NIST curve P-256, AES-128, and SHA2-256. NIST curve P-256, AES-128, and SHA2-256.
17. {15} Implementation Nits 17. {15} Implementation Nits
This section is a collection of comments to help an implementer, This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous particularly with an eye to backward compatibility. Previous
skipping to change at page 104, line 34 skipping to change at page 107, line 38
1994, pp191-204, December 1993, 1994, pp191-204, December 1993,
<http://www.counterpane.com/bfsverlag.html>. <http://www.counterpane.com/bfsverlag.html>.
[BZ2] Seward, J., "The Bzip2 and libbzip2 home page", [BZ2] Seward, J., "The Bzip2 and libbzip2 home page",
<http://www.bzip.org/>. <http://www.bzip.org/>.
[ELGAMAL] Elgamal, T., "A Public-Key Cryptosystem and a Signature [ELGAMAL] Elgamal, T., "A Public-Key Cryptosystem and a Signature
Scheme Based on Discrete Logarithms,", IEEE Transactions Scheme Based on Discrete Logarithms,", IEEE Transactions
on Information Theory v. IT-31, n. 4, 1985, pp. 469-472, . on Information Theory v. IT-31, n. 4, 1985, pp. 469-472, .
[FIPS180] NIST, "Secure Hash Signature Standard (SHS) (FIPS PUB [FIPS180] National Institute of Standards and Technology, U.S.
180-2)", <http://csrc.nist.gov/publications/fips/fips180-
2/fips180-2withchangenotice.pdf>.
[FIPS180-3]
National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard (SHS), FIPS Department of Commerce, "Secure Hash Standard (SHS), FIPS
180-3", October 2008. 180-4", August 2015,
<http://dx.doi.org/10.6028/NIST.FIPS.180-4>.
[FIPS186] NIST, "Digital Signature Standard (DSS) (FIPS PUB 186-2)", [FIPS186] National Institute of Standards and Technology, U.S.
<http://csrc.nist.gov/publications/fips/fips186-2/ Department of Commerce, "Digital Signature Standard (DSS),
fips186-2-change1.pdf>. FIPS 186-4", July 2013,
<http://dx.doi.org/10.6028/NIST.FIPS.186-4>.
[FIPS186-3] [FIPS202] National Institute of Standards and Technology, U.S.
National Institute of Standards and Technology, U.S. Department of Commerce, "SHA-3 Standard: Permutation-Based
Department of Commerce, "Digital Signature Standard, FIPS Hash and Extendable-Output Functions, FIPS 202", August
186-3", June 2009. 2015, <http://dx.doi.org/10.6028/NIST.FIPS.202>.
[HAC] Menezes, A., Oorschot, P., and S. Vanstone, "Handbook of [HAC] Menezes, A., Oorschot, P., and S. Vanstone, "Handbook of
Applied Cryptography", 1996. Applied Cryptography", 1996.
[I-D.irtf-cfrg-eddsa] [I-D.irtf-cfrg-eddsa]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-02 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-02
(work in progress), January 2016. (work in progress), January 2016.
[IDEA] Lai, X., "On the design and security of block ciphers", [IDEA] Lai, X., "On the design and security of block ciphers",
skipping to change at page 106, line 24 skipping to change at page 109, line 24
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of
the Camellia Encryption Algorithm", RFC 3713, April 2004. the Camellia Encryption Algorithm", RFC 3713, April 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation", RFC
5639, DOI 10.17487/RFC5639, March 2010,
<http://www.rfc-editor.org/info/rfc5639>.
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
Identifier for Geographic Locations ('geo' URI)", RFC Identifier for Geographic Locations ('geo' URI)", RFC
5870, DOI 10.17487/RFC5870, June 2010, 5870, DOI 10.17487/RFC5870, June 2010,
<http://www.rfc-editor.org/info/rfc5870>. <http://www.rfc-editor.org/info/rfc5870>.
[SCHNEIER] [SCHNEIER]
Schneier, B., "Applied Cryptography Second Edition: 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]
skipping to change at page 108, line 18 skipping to change at page 111, line 24
43 ee 3b 24 06 43 ee 3b 24 06
A.2. Sample EdDSA signature A.2. Sample EdDSA signature
The signature is created using the sample key over the input data 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 "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash
function is: function is:
m: 4f70656e504750040016080006050255f95f9504ff0000000c m: 4f70656e504750040016080006050255f95f9504ff0000000c
Using the SHA-256 hash algorithm yields the digest: Using the SHA2-256 hash algorithm yields the digest:
d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280 d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
Which is fed into the EdDSA signature function and yields this Which is fed into the EdDSA signature function and yields this
signature: signature:
r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366 r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366
s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404 s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404
skipping to change at page 109, line 19 skipping to change at page 112, line 26
o Added Camellia cipher from RFC 5581. o Added Camellia cipher from RFC 5581.
o Incorporated RFC 6637 (ECC for OpenPGP) o Incorporated RFC 6637 (ECC for OpenPGP)
o Added draft-atkins-openpgp-device-certificates o Added draft-atkins-openpgp-device-certificates
o Added draft-koch-eddsa-for-openpgp-04 o Added draft-koch-eddsa-for-openpgp-04
o Added Issuer Fingerprint signature subpacket. o Added Issuer Fingerprint signature subpacket.
o Added a V5 key and fingerprint format.
o Added OIDs for brainpool curves and Curve25519.
o Marked SHA2-256 as MUST implement.
o Marked Curve25519 and Ed25519 as SHOULD implement.
o Marked SHA-1 as SHOULD NOT be used to create messages.
o Marked MD5 as SHOULD NOT implement.
{ Informational rfcs: [RFC1423] } { Informational rfcs: [RFC1423] }
Appendix D. The principal authors of RFC-4880 are as follows: Appendix D. The principal authors of RFC-4880 are as follows:
Jon Callas Jon Callas
EMail: jon@callas.org EMail: jon@callas.org
Lutz Donnerhacke Lutz Donnerhacke
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
 End of changes. 87 change blocks. 
314 lines changed or deleted 457 lines changed or added

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