--- 1/draft-ietf-openpgp-rfc4880bis-01.txt 2017-06-30 05:15:19.522705673 -0700 +++ 2/draft-ietf-openpgp-rfc4880bis-02.txt 2017-06-30 05:15:19.770711542 -0700 @@ -1,19 +1,19 @@ Network Working Group W. Koch Internet-Draft -Updates: 4880 (if approved) January 2, 2017 +Updates: 4880 (if approved) June 30, 2017 Intended status: Standards Track -Expires: July 6, 2017 +Expires: January 1, 2018 OpenPGP Message Format - draft-ietf-openpgp-rfc4880bis-01 + draft-ietf-openpgp-rfc4880bis-02 Abstract { Work in progress to update the OpenPGP specification from RFC4880 } This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,143 +60,150 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. {1} Introduction . . . . . . . . . . . . . . . . . . . . . . 5 1.1. {1.1} Terms . . . . . . . . . . . . . . . . . . . . . . . 5 2. {2} General functions . . . . . . . . . . . . . . . . . . . . 6 2.1. {2.1} Confidentiality via Encryption . . . . . . . . . . 6 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.5. {2.5} Signature-Only Applications . . . . . . . . . . . . 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.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.6. {3.6} Keyrings . . . . . . . . . . . . . . . . . . . . . 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.2. {3.7.2} String-to-Key Usage . . . . . . . . . . . . . 12 4. {4} Packet Syntax . . . . . . . . . . . . . . . . . . . . . . 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.2. {4.2.2} New Format Packet Lengths . . . . . . . . . . 15 4.2.3. {4.2.3} Packet Length Examples . . . . . . . . . . . 16 4.3. {4.3} Packet Tags . . . . . . . . . . . . . . . . . . . . 17 5. {5} Packet Types . . . . . . . . . . . . . . . . . . . . . . 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.1. {5.2.1} Signature Types . . . . . . . . . . . . . . . 19 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.4. {5.2.4} Computing Signatures . . . . . . . . . . . . 40 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.5. {5.5} Key Material Packet . . . . . . . . . . . . . . . . 43 5.5.1. {5.5.1} Key Packet Variants . . . . . . . . . . . . . 43 5.5.2. {5.5.2} Public-Key Packet Formats . . . . . . . . . . 44 - 5.5.3. {5.5.3} Secret-Key Packet Formats . . . . . . . . . . 47 - 5.6. {5.6} Compressed Data Packet (Tag 8) . . . . . . . . . . 49 - 5.7. {5.7} Symmetrically Encrypted Data Packet (Tag 9) . . . . 49 - 5.8. {5.8} Marker Packet (Obsolete Literal Packet) (Tag 10) . 50 - 5.9. {5.9} Literal Data Packet (Tag 11) . . . . . . . . . . . 51 - 5.10. {5.10} Trust Packet (Tag 12) . . . . . . . . . . . . . . 52 - 5.11. {5.11} User ID Packet (Tag 13) . . . . . . . . . . . . . 52 - 5.12. {5.12} User Attribute Packet (Tag 17) . . . . . . . . . . 52 - 5.12.1. {5.12.1} The Image Attribute Subpacket . . . . . . . 53 - 5.12.2. User ID Attribute Subpacket . . . . . . . . . . . . 53 - 5.13. {5.13} Sym. Encrypted Integrity Protected Data Packet - (Tag 18) . . . . . . . . . . . . . . . . . . . . . . . . 54 - 5.14. {5.14} Modification Detection Code Packet (Tag 19) . . . 57 - 6. {6} Radix-64 Conversions . . . . . . . . . . . . . . . . . . 58 - 6.1. {6.1} An Implementation of the CRC-24 in "C" . . . . . . 58 - 6.2. {6.2} Forming ASCII Armor . . . . . . . . . . . . . . . . 59 - 6.3. {6.3} Encoding Binary in Radix-64 . . . . . . . . . . . . 61 - 6.4. {6.4} Decoding Radix-64 . . . . . . . . . . . . . . . . . 63 - 6.5. {6.5} Examples of Radix-64 . . . . . . . . . . . . . . . 63 - 6.6. {6.6} Example of an ASCII Armored Message . . . . . . . . 64 - 7. {7} Cleartext Signature Framework . . . . . . . . . . . . . . 64 - 7.1. {7.1} Dash-Escaped Text . . . . . . . . . . . . . . . . . 65 - 8. {8} Regular Expressions . . . . . . . . . . . . . . . . . . . 66 - 9. {9} Constants . . . . . . . . . . . . . . . . . . . . . . . . 66 - 9.1. {9.1} Public-Key Algorithms . . . . . . . . . . . . . . . 67 - 9.2. ECC Curve OID . . . . . . . . . . . . . . . . . . . . . . 67 - 9.3. {9.2} Symmetric-Key Algorithms . . . . . . . . . . . . . 68 - 9.4. {9.3} Compression Algorithms . . . . . . . . . . . . . . 69 - 9.5. {9.4} Hash Algorithms . . . . . . . . . . . . . . . . . . 69 - 10. {10} IANA Considerations . . . . . . . . . . . . . . . . . . 70 - 10.1. {10.1} New String-to-Key Specifier Types . . . . . . . . 70 - 10.2. {10.2} New Packets . . . . . . . . . . . . . . . . . . . 70 - 10.2.1. {10.2.1} User Attribute Types . . . . . . . . . . . 70 - 10.2.2. {10.2.1.1} Image Format Subpacket Types . . . . . . 71 - 10.2.3. {10.2.2} New Signature Subpackets . . . . . . . . . 71 - 10.2.4. {10.2.3} New Packet Versions . . . . . . . . . . . . 73 - 10.3. {10.3} New Algorithms . . . . . . . . . . . . . . . . . 73 - 10.3.1. {10.3.1} Public-Key Algorithms . . . . . . . . . . . 74 - 10.3.2. {10.3.2} Symmetric-Key Algorithms . . . . . . . . . 74 - 10.3.3. {10.3.3} Hash Algorithms . . . . . . . . . . . . . . 74 - 10.3.4. {10.3.4} Compression Algorithms . . . . . . . . . . 75 - 11. {11} Packet Composition . . . . . . . . . . . . . . . . . . . 75 - 11.1. {11.1} Transferable Public Keys . . . . . . . . . . . . 75 - 11.2. {11.2} Transferable Secret Keys . . . . . . . . . . . . 76 - 11.3. {11.3} OpenPGP Messages . . . . . . . . . . . . . . . . 77 - 11.4. {11.4} Detached Signatures . . . . . . . . . . . . . . . 77 - 12. {12} Enhanced Key Formats . . . . . . . . . . . . . . . . . . 78 - 12.1. {12.1} Key Structures . . . . . . . . . . . . . . . . . 78 - 12.2. {12.2} Key IDs and Fingerprints . . . . . . . . . . . . 79 - 13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 80 - 13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 80 - 13.2. ECDSA and ECDH Conversion Primitives . . . . . . . . . . 81 - 13.3. EdDSA Point Format . . . . . . . . . . . . . . . . . . . 81 - 13.4. Key Derivation Function . . . . . . . . . . . . . . . . 82 - 13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 82 - 14. {13} Notes on Algorithms . . . . . . . . . . . . . . . . . . 85 - 14.1. {13.1} PKCS#1 Encoding in OpenPGP . . . . . . . . . . . 85 - 14.1.1. {13.1.1} EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . 85 - 14.1.2. {13.1.2} EME-PKCS1-v1_5-DECODE . . . . . . . . . . . 86 - 14.1.3. {13.1.3} EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . 87 - 14.2. {13.2} Symmetric Algorithm Preferences . . . . . . . . . 88 - 14.3. {13.3} Other Algorithm Preferences . . . . . . . . . . . 89 - 14.3.1. {13.3.1} Compression Preferences . . . . . . . . . . 89 - 14.3.2. {13.3.2} Hash Algorithm Preferences . . . . . . . . 90 - 14.4. {13.4} Plaintext . . . . . . . . . . . . . . . . . . . . 90 - 14.5. {13.5} RSA . . . . . . . . . . . . . . . . . . . . . . . 90 - 14.6. {13.6} DSA . . . . . . . . . . . . . . . . . . . . . . . 90 - 14.7. {13.7} Elgamal . . . . . . . . . . . . . . . . . . . . . 91 - 14.8. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 91 - 14.9. {13.8} Reserved Algorithm Numbers . . . . . . . . . . . 91 - 14.10. {13.9} OpenPGP CFB Mode . . . . . . . . . . . . . . . . 92 - 14.11. {13.10} Private or Experimental Parameters . . . . . . . 93 - 14.12. {13.11} Extension of the MDC System . . . . . . . . . . 93 - 14.13. {13.12} Meta-Considerations for Expansion . . . . . . . 94 - 15. {14} Security Considerations . . . . . . . . . . . . . . . . 94 - 16. Compatibility Profiles . . . . . . . . . . . . . . . . . . . 101 - 16.1. OpenPGP ECC Profile . . . . . . . . . . . . . . . . . . 101 - 16.2. Suite-B Profile . . . . . . . . . . . . . . . . . . . . 102 - 16.3. Security Strength at 192 Bits . . . . . . . . . . . . . 102 - 16.4. Security Strength at 128 Bits . . . . . . . . . . . . . 102 - 17. {15} Implementation Nits . . . . . . . . . . . . . . . . . . 102 - 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 - 18.1. Normative References . . . . . . . . . . . . . . . . . . 104 - 18.2. Informative References . . . . . . . . . . . . . . . . . 106 - Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 107 - A.1. Sample EdDSA key . . . . . . . . . . . . . . . . . . . . 107 - A.2. Sample EdDSA signature . . . . . . . . . . . . . . . . . 108 - Appendix B. ECC Point compression flag bytes . . . . . . . . . . 108 - Appendix C. Changes since RFC-4880 . . . . . . . . . . . . . . . 109 - Appendix D. The principal authors of RFC-4880 are as follows: . 109 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 109 + 5.5.3. {5.5.3} Secret-Key Packet Formats . . . . . . . . . . 46 + 5.6. Algorithm-specific Parts of Keys . . . . . . . . . . . . 47 + 5.6.1. Algorithm-Specific Part for RSA Keys . . . . . . . . 47 + 5.6.2. Algorithm-Specific Part for DSA Keys . . . . . . . . 48 + 5.6.3. Algorithm-Specific Part for Elgamal Keys . . . . . . 48 + 5.6.4. Algorithm-Specific Part for ECDSA Keys . . . . . . . 48 + 5.6.5. Algorithm-Specific Part for EdDSA Keys . . . . . . . 49 + 5.6.6. Algorithm-Specific Part for ECDH Keys . . . . . . . . 49 + 5.7. {5.6} Compressed Data Packet (Tag 8) . . . . . . . . . . 50 + 5.8. {5.7} Symmetrically Encrypted Data Packet (Tag 9) . . . . 51 + 5.9. {5.8} Marker Packet (Obsolete Literal Packet) (Tag 10) . 52 + 5.10. {5.9} Literal Data Packet (Tag 11) . . . . . . . . . . . 52 + 5.11. {5.10} Trust Packet (Tag 12) . . . . . . . . . . . . . . 53 + 5.12. {5.11} User ID Packet (Tag 13) . . . . . . . . . . . . . 53 + 5.13. {5.12} User Attribute Packet (Tag 17) . . . . . . . . . . 53 + 5.13.1. {5.12.1} The Image Attribute Subpacket . . . . . . . 54 + 5.13.2. User ID Attribute Subpacket . . . . . . . . . . . . 55 + 5.14. {5.13} Sym. Encrypted Integrity Protected Data Packet + (Tag 18) . . . . . . . . . . . . . . . . . . . . . . . . 55 + 5.15. {5.14} Modification Detection Code Packet (Tag 19) . . . 58 + 6. {6} Radix-64 Conversions . . . . . . . . . . . . . . . . . . 59 + 6.1. {6.1} An Implementation of the CRC-24 in "C" . . . . . . 60 + 6.2. {6.2} Forming ASCII Armor . . . . . . . . . . . . . . . . 60 + 6.3. {6.3} Encoding Binary in Radix-64 . . . . . . . . . . . . 63 + 6.4. {6.4} Decoding Radix-64 . . . . . . . . . . . . . . . . . 64 + 6.5. {6.5} Examples of Radix-64 . . . . . . . . . . . . . . . 64 + 6.6. {6.6} Example of an ASCII Armored Message . . . . . . . . 65 + 7. {7} Cleartext Signature Framework . . . . . . . . . . . . . . 65 + 7.1. {7.1} Dash-Escaped Text . . . . . . . . . . . . . . . . . 66 + 8. {8} Regular Expressions . . . . . . . . . . . . . . . . . . . 67 + 9. {9} Constants . . . . . . . . . . . . . . . . . . . . . . . . 67 + 9.1. {9.1} Public-Key Algorithms . . . . . . . . . . . . . . . 68 + 9.2. ECC Curve OID . . . . . . . . . . . . . . . . . . . . . . 68 + 9.3. {9.2} Symmetric-Key Algorithms . . . . . . . . . . . . . 69 + 9.4. {9.3} Compression Algorithms . . . . . . . . . . . . . . 70 + 9.5. {9.4} Hash Algorithms . . . . . . . . . . . . . . . . . . 70 + 10. {10} IANA Considerations . . . . . . . . . . . . . . . . . . 71 + 10.1. {10.1} New String-to-Key Specifier Types . . . . . . . . 71 + 10.2. {10.2} New Packets . . . . . . . . . . . . . . . . . . . 71 + 10.2.1. {10.2.1} User Attribute Types . . . . . . . . . . . 72 + 10.2.2. {10.2.1.1} Image Format Subpacket Types . . . . . . 72 + 10.2.3. {10.2.2} New Signature Subpackets . . . . . . . . . 72 + 10.2.4. {10.2.3} New Packet Versions . . . . . . . . . . . . 75 + 10.3. {10.3} New Algorithms . . . . . . . . . . . . . . . . . 75 + 10.3.1. {10.3.1} Public-Key Algorithms . . . . . . . . . . . 76 + 10.3.2. {10.3.2} Symmetric-Key Algorithms . . . . . . . . . 76 + 10.3.3. {10.3.3} Hash Algorithms . . . . . . . . . . . . . . 76 + 10.3.4. {10.3.4} Compression Algorithms . . . . . . . . . . 77 + 11. {11} Packet Composition . . . . . . . . . . . . . . . . . . . 77 + 11.1. {11.1} Transferable Public Keys . . . . . . . . . . . . 77 + 11.2. {11.2} Transferable Secret Keys . . . . . . . . . . . . 79 + 11.3. {11.3} OpenPGP Messages . . . . . . . . . . . . . . . . 79 + 11.4. {11.4} Detached Signatures . . . . . . . . . . . . . . . 80 + 12. {12} Enhanced Key Formats . . . . . . . . . . . . . . . . . . 80 + 12.1. {12.1} Key Structures . . . . . . . . . . . . . . . . . 80 + 12.2. {12.2} Key IDs and Fingerprints . . . . . . . . . . . . 82 + 13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 83 + 13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 84 + 13.2. ECDSA and ECDH Conversion Primitives . . . . . . . . . . 84 + 13.3. EdDSA Point Format . . . . . . . . . . . . . . . . . . . 84 + 13.4. Key Derivation Function . . . . . . . . . . . . . . . . 85 + 13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 85 + 14. {13} Notes on Algorithms . . . . . . . . . . . . . . . . . . 88 + 14.1. {13.1} PKCS#1 Encoding in OpenPGP . . . . . . . . . . . 88 + 14.1.1. {13.1.1} EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . 88 + 14.1.2. {13.1.2} EME-PKCS1-v1_5-DECODE . . . . . . . . . . . 89 + 14.1.3. {13.1.3} EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . 90 + 14.2. {13.2} Symmetric Algorithm Preferences . . . . . . . . . 91 + 14.3. {13.3} Other Algorithm Preferences . . . . . . . . . . . 92 + 14.3.1. {13.3.1} Compression Preferences . . . . . . . . . . 92 + 14.3.2. {13.3.2} Hash Algorithm Preferences . . . . . . . . 93 + 14.4. {13.4} Plaintext . . . . . . . . . . . . . . . . . . . . 93 + 14.5. {13.5} RSA . . . . . . . . . . . . . . . . . . . . . . . 93 + 14.6. {13.6} DSA . . . . . . . . . . . . . . . . . . . . . . . 93 + 14.7. {13.7} Elgamal . . . . . . . . . . . . . . . . . . . . . 94 + 14.8. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 94 + 14.9. {13.8} Reserved Algorithm Numbers . . . . . . . . . . . 94 + 14.10. {13.9} OpenPGP CFB Mode . . . . . . . . . . . . . . . . 95 + 14.11. {13.10} Private or Experimental Parameters . . . . . . . 96 + 14.12. {13.11} Extension of the MDC System . . . . . . . . . . 96 + 14.13. {13.12} Meta-Considerations for Expansion . . . . . . . 97 + 15. {14} Security Considerations . . . . . . . . . . . . . . . . 97 + 16. Compatibility Profiles . . . . . . . . . . . . . . . . . . . 104 + 16.1. OpenPGP ECC Profile . . . . . . . . . . . . . . . . . . 104 + 16.2. Suite-B Profile . . . . . . . . . . . . . . . . . . . . 105 + 16.3. Security Strength at 192 Bits . . . . . . . . . . . . . 105 + 16.4. Security Strength at 128 Bits . . . . . . . . . . . . . 105 + 17. {15} Implementation Nits . . . . . . . . . . . . . . . . . . 105 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 + 18.1. Normative References . . . . . . . . . . . . . . . . . . 107 + 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 { This is work in progress to update OpenPGP. Editorial notes are enclosed in curly braces. The section numbers from RFC4880 are also indicated in curly braces. } This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, and key management functions. It is a revision of RFC 2440, "OpenPGP @@ -1026,69 +1033,69 @@ structure. The object identifier for the type of hash being used is included in the structure. The hexadecimal representations for the currently defined hash algorithms are as follows: - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - 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: - MD5: 1.2.840.113549.2.5 - RIPEMD-160: 1.3.36.3.2.1 - 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: - MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x04, 0x10 - RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 - SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, 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, 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, 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, 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, 0x00, 0x04, 0x40 DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used @@ -1447,22 +1454,25 @@ Used in conjunction with trust Signature packets (of level > 0) to limit the scope of trust that is extended. Only signatures by the target key on User IDs that match the regular expression in the body of this packet have trust extended by the trust Signature subpacket. The regular expression uses the same syntax as the Henry Spencer's "almost public domain" regular expression [REGEX] package. A description of the syntax is found in Section 8 below. 5.2.3.15. {5.2.3.15} Revocation Key - (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of - fingerprint) + (1 octet of class, 1 octet of public-key algorithm ID, 20 or 25 + 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 key. Class octet must have bit 0x80 set. If the bit 0x40 is set, then this means that the revocation information is sensitive. Other bits are for future expansion to other kinds of authorizations. This is found on a self-signature. If the "sensitive" flag is set, the keyholder feels this subpacket contains private trust information that describes a real-world sensitive relationship. If this flag is set, implementations SHOULD @@ -1801,21 +1811,22 @@ (1 octet key version number, N octets of fingerprint) The OpenPGP Key fingerprint of the key issuing the signature. This subpacket SHOULD be included in all signatures. If the version of the issuing key is 4 and an Issuer subpacket is also included in the signature, the key ID of the Issuer subpacket MUST match the low 64 bits of the fingerprint. Note that the length N of the fingerprint for a version 4 key is 20 - octets. + 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 All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm. For binary document signatures (type 0x00), the document data is hashed directly. For text document signatures (type 0x01), the document is canonicalized by converting line endings to , and the resulting data is hashed. @@ -1826,50 +1837,56 @@ a key packet with two-octet length.) A subkey binding signature (type 0x18) or primary key binding signature (type 0x19) then hashes the subkey using the same format as the main key (also using 0x99 as the first octet). Primary key revocation signatures (type 0x20) hash only the key being revoked. Subkey revocation signature (type 0x28) hash first the primary key and then the subkey being revoked. A certification signature (type 0x10 through 0x13) hashes the User ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the User ID or attribute - packet packet, without any header. A V4 certification hashes the - constant 0xB4 for User ID certifications or the constant 0xD1 for + packet packet, without any header. A V4 or V5 certification hashes + the constant 0xB4 for User ID certifications or the constant 0xD1 for User Attribute certifications, followed by a four-octet number giving the length of the User ID or User Attribute data, and then the User ID or User Attribute data. When a signature is made over a Signature packet (type 0x50), the hash data starts with the octet 0x88, followed by the four-octet length of the signature, and then the body of the Signature packet. (Note that this is an old-style packet header for a Signature packet with the length-of-length set to zero.) The unhashed subpacket data of the Signature packet being hashed is not included in the hash, and the unhashed subpacket data length value is set to zero. Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by - the four-octet signature time. A V4 signature hashes the packet body - starting from its first field, the version number, through the end of - the hashed subpacket data. Thus, the fields hashed are the signature - version, the signature type, the public-key algorithm, the hash - algorithm, the hashed subpacket length, and the hashed subpacket - body. + the four-octet signature time. A V4 or V5 signature hashes the + packet body starting from its first field, the version number, + through the end of the hashed subpacket data. Thus, the fields + hashed are the signature version, the signature type, the public-key + algorithm, the hash algorithm, the hashed subpacket length, and the + hashed subpacket body. V4 signatures also hash in a final trailer of six octets: the version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, big- endian number that is the length of the hashed data from the Signature packet (note that this number does not include these final six octets). + 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 resulting hash field is used in the signature algorithm and placed at the end of the Signature packet. 5.2.4.1. {5.2.4.1} Subpacket Hints It is certainly possible for a signature to contain conflicting information in subpackets. For example, a signature may contain multiple copies of a preference or multiple expiration times. In most cases, an implementation SHOULD use the last subpacket in the @@ -2055,203 +2072,256 @@ section "Enhanced Key Formats". A version 4 packet contains: o A one-octet version number (4). 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 series of multiprecision integers comprising the key material. - This algorithm-specific portion is: - - 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, + o A series of values comprising the key material. This is + algorithm-specific and described in section XXXX. - + the octets representing a curve OID, defined in - Section 11{FIXME}; + The version 5 format is similar to the version 4 format except for + the addition of a count for the key material. This count helps + parsing secret key packets (which are an extension of the public key + packet format) in the case of an unknown algoritm. In addition, + fingerprints of version 5 keys are calculated differently from + version 4 keys, as described in the section "Enhanced Key Formats". - * a MPI of an EC point representing a public key; + A version 5 packet contains: - * a variable-length field containing KDF parameters, formatted as - follows: + o A one-octet version number (5). - + a one-octet size of the following fields; values 0 and 0xff - are reserved for future extensions; + o A four-octet number denoting the time that the key was created. - + 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; - + 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. + o A four-octet scalar octet count for the following key material. - Observe that an ECDH public key is composed of the same sequence of - fields that define an ECDSA key, plus the KDF parameters field. + o A series of values comprising the key material. This is + algorithm-specific and described in section XXXX. 5.5.3. {5.5.3} Secret-Key Packet Formats The Secret-Key and Secret-Subkey packets contain all the data of the Public-Key and Public-Subkey packets, with additional algorithm- specific secret-key data appended, usually in encrypted form. The packet contains: o A Public-Key or Public-Subkey packet, as described above. o One octet indicating string-to-key usage conventions. Zero indicates that the secret-key data is not encrypted. 255 or 254 indicates that a string-to-key specifier is being given. Any - other value is a symmetric-key encryption algorithm identifier. + 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- octet symmetric encryption algorithm. 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 implied by its type, as described above. o [Optional] If secret data is encrypted (string-to-key usage octet not zero), an Initial Vector (IV) of the same length as the cipher's block size. - o Plain or encrypted multiprecision integers comprising the secret - key data. These algorithm-specific fields are as described below. + o Only for a version 5 packet, a four-octet scalar octet count for + 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 checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536). If the string-to-key usage octet was 254, then a 20-octet SHA-1 hash of the plaintext of the algorithm- specific portion. This checksum or hash is encrypted together with the algorithm-specific fields (if string-to-key usage octet is not zero). Note that for all other values, a two-octet checksum is required. - Algorithm-Specific Fields for RSA secret keys: - - * 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. + Note that the version 5 packet format adds two count values to help + parsing packets with unknown S2K or public key algorithms. Secret MPI values can be encrypted using a passphrase. If a string- to-key specifier is given, that describes the algorithm for converting the passphrase to a key, else a simple MD5 hash of the passphrase is used. Implementations MUST use a string-to-key specifier; the simple hash is for backward compatibility and is deprecated, though implementations MAY continue to use existing private keys in the old format. The cipher for encrypting the MPIs is specified in the Secret-Key packet. Encryption/decryption of the secret data is done in CFB mode using the key created from the passphrase and the Initial Vector from the packet. A different mode is used with V3 keys (which are only RSA) than with other key formats. With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non- prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block boundary is aligned with the start of the MPI data. - With V4 keys, a simpler method is used. All secret MPI values are - encrypted in CFB mode, including the MPI bitcount prefix. + With V4 and V5 keys, a simpler method is used. All secret MPI values + are encrypted in CFB mode, including the MPI bitcount prefix. The two-octet checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm- specific octets (including MPI prefix and data). With V3 keys, the checksum is stored in the clear. With V4 keys, the checksum is encrypted like the algorithm-specific data. This value is used to check that the passphrase was correct. However, this checksum is deprecated; an implementation SHOULD NOT use it, but should rather use the SHA-1 hash denoted with a usage octet of 254. The reason for this is that there are some attacks that involve undetectably modifying the secret key. -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 packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains a literal data packet. The body of this packet consists of: o One octet that gives the algorithm used to compress the packet. @@ -2265,21 +2335,21 @@ DEFLATE blocks. Note that PGP V2.6 uses 13 bits of compression. If an implementation uses more bits of compression, PGP V2.6 cannot decompress it. ZLIB-compressed packets are compressed with RFC 1950 [RFC1950] ZLIB- style blocks. BZip2-compressed packets are compressed using the BZip2 [BZ2] 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 a symmetric-key algorithm. When it has been decrypted, it contains other packets (usually a literal data packet or compressed data packet, but in theory other Symmetrically Encrypted Data packets or sequences of packets that form whole OpenPGP messages). The body of this packet consists of: o Encrypted data, the output of the selected symmetric-key cipher @@ -2307,37 +2377,37 @@ After encrypting the first block-size-plus-two octets, the CFB state is resynchronized. The last block-size octets of ciphertext are passed through the cipher and the block boundary is reset. The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. See the "Security Considerations" section for hints on the proper use of this "quick check". -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 packet, but no released version of PGP generated Literal packets with this tag. With PGP 5.x, this packet has been reassigned and is reserved for use as the Marker packet. The body of this packet consists of: 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 beginning of a message that uses features not available in PGP 2.6.x in order to cause that version to report that newer software is necessary to process the message. -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 not to be further interpreted. The body of this packet consists of: o A one-octet field that describes how the data is formatted. If it is a 'b' (0x62), then the Literal packet contains binary data. If it is a 't' (0x74), then it contains text data, and thus @@ -2367,42 +2437,42 @@ literal data. Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time. o The remainder of the packet is literal data. Text data is stored with text endings (i.e., network- normal line endings). These should be converted to native line 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 exported. Trust packets contain data that record the user's specifications of which key holders are trustworthy introducers, along with other information that implementing software uses for trust information. The format of Trust packets is defined by a given implementation. Trust packets SHOULD NOT be emitted to output streams that are transferred to other users, and they SHOULD be ignored on any input other than local keyring files. -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 the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID. -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 is capable of storing more types of data than the User ID packet, which is limited to text. Like the User ID packet, a User Attribute packet may be certified by the key owner ("self-signed") or any other key owner who cares to certify it. Except as noted, a User Attribute packet may be used anywhere that a User ID packet may be used. While User Attribute packets are not a required part of the OpenPGP standard, implementations SHOULD provide at least enough @@ -2427,21 +2497,21 @@ | Type | Attribute Subpacket | +----------+------------------------------+ | 1 | Image Attribute Subpacket | | [TBD1] | User ID Attribute Subpacket | | 100-110 | Private/Experimental Use | +----------+------------------------------+ An implementation SHOULD ignore any subpacket of a type that it does 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 (but not required to be) that of the key owner. The Image Attribute subpacket begins with an image header. The first two octets of the image header contain the length of the image header. Note that unlike other multi-octet numerical values in this document, due to a historical accident this value is encoded as a little-endian number. The image header length is followed by a single octet for the image header version. The only currently @@ -2459,37 +2529,37 @@ The rest of the image subpacket contains the image itself. As the only currently defined image type is JPEG, the image is encoded in the JPEG File Interchange Format (JFIF), a standard file format for JPEG images [JFIF]. An implementation MAY try to determine the type of an image by examination of the image data if it is unable to handle a particular version of the image header or if a specified encoding format value is not recognized. -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, just like a User ID packet, consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 2822 [RFC2822] mail name-addr, but there are no restrictions on its content. For devices using OpenPGP for device certificates, it may just be the device identifier. The packet length in the header specifies the length of the 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 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 variant of the Symmetrically Encrypted Data packet. It is a new feature created for OpenPGP that addresses the problem of detecting a modification to encrypted data. It is used in combination with a Modification Detection Code packet. There is a corresponding feature in the features Signature subpacket that denotes that an implementation can properly use this packet type. An implementation MUST support decrypting these packets and @@ -2620,30 +2690,30 @@ intercepted from Bob. (Note also that if Bob wishes to communicate secretly with Alice, but without authentication or identification and with a threat model that includes forgers, he has a problem that transcends mere cryptography.) Note also that unlike nearly every other OpenPGP subsystem, there are no parameters in the MDC system. It hard-defines SHA-1 as its hash function. This is not an accident. It is an intentional choice to avoid downgrade and cross-grade attacks while making a simple, fast system. (A downgrade attack would - be an attack that replaced SHA-256 with SHA-1, for example. A + be an attack that replaced SHA2-256 with SHA-1, for example. A cross-grade attack would replace SHA-1 with another 160-bit hash, such as RIPE-MD/160, for example.) However, given the present state of hash function cryptanalysis and cryptography, it may be desirable to upgrade the MDC system to a new hash function. See Section 13.11 in the "IANA Considerations" for guidance. -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 plaintext data, which is used to detect message modification. It is only used with a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data that is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place. A Modification Detection Code packet MUST have a length of 20 octets. @@ -3063,60 +3134,64 @@ +-----------+----------------------------------------------------+ | ID | Algorithm | +-----------+----------------------------------------------------+ | 1 | RSA (Encrypt or Sign) [HAC] | | 2 | RSA Encrypt-Only [HAC] | | 3 | RSA Sign-Only [HAC] | | 16 | Elgamal (Encrypt-Only) [ELGAMAL] [HAC] | | 17 | DSA (Digital Signature Algorithm) [FIPS186] [HAC] | | 18 | ECDH public key algorithm | - | 19 | ECDSA public key algorithm [FIPS186-3] | + | 19 | ECDSA public key algorithm [FIPS186] | | 20 | Reserved (formerly Elgamal Encrypt or Sign) | | 21 | Reserved for Diffie-Hellman | | | (X9.42, as defined for IETF-S/MIME) | | 22 | EdDSA [I-D.irtf-cfrg-eddsa] | | 100--110 | Private/Experimental algorithm | +-----------+----------------------------------------------------+ Implementations MUST implement DSA and ECDSA for signatures, and Elgamal and ECDH for encryption. Implementations SHOULD implement RSA keys (1). RSA Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be generated, but may be interpreted. See - Section 13.5. See Section 13.8 for notes 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 algorithm. A compatible specification of ECDSA is given in [RFC6090] as "KT-I Signatures" and in [SEC1]; ECDH is defined in Section 13.5 this document. 9.2. ECC Curve OID The parameter curve OID is an array of octets that define a named curve. The table below specifies the exact sequence of bytes for each named curve referenced in this document: - +------------------------+-----+----------------------+-------------+ - | ASN.1 Object | OID | Curve OID bytes in | Curve name | - | Identifier | len | hexadecimal | | + +------------------------+-----+------------------+-----------------+ + | ASN.1 Object | OID | Curve OID bytes | Curve name | + | Identifier | len | in hexadecimal | | | | | representation | | - +------------------------+-----+----------------------+-------------+ - | 1.2.840.10045.3.1.7 | 8 | 2A 86 48 CE 3D 03 01 | NIST curve | - | | | 07 | P-256 | - | 1.3.132.0.34 | 5 | 2B 81 04 00 22 | NIST curve | - | | | | P-384 | - | 1.3.132.0.35 | 5 | 2B 81 04 00 23 | NIST curve | - | | | | P-521 | - | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 | - | | | 0F 01 | | - +------------------------+-----+----------------------+-------------+ + +------------------------+-----+------------------+-----------------+ + | 1.2.840.10045.3.1.7 | 8 | 2A 86 48 CE 3D | NIST P-256 | + | | | 03 01 07 | | + | 1.3.132.0.34 | 5 | 2B 81 04 00 22 | NIST P-384 | + | 1.3.132.0.35 | 5 | 2B 81 04 00 23 | NIST P-521 | + | 1.3.36.3.3.2.8.1.1.7 | 9 | 2B 24 03 03 02 | brainpoolP256r1 | + | | | 08 01 01 07 | | + | 1.3.36.3.3.2.8.1.1.13 | 9 | 2B 24 03 03 02 | brainpoolP512r1 | + | | | 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 Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier with subsequent truncation. The truncation removes the two fields of encoded Object Identifier. The first omitted field is one octet representing the Object Identifier tag, and the second omitted field 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 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 @@ -3172,29 +3245,35 @@ +-----------+---------------------------------+--------------+ | ID | Algorithm | Text Name | +-----------+---------------------------------+--------------+ | 1 | MD5 [HAC] | "MD5" | | 2 | SHA-1 [FIPS180] | "SHA1" | | 3 | RIPE-MD/160 [HAC] | "RIPEMD160" | | 4 | Reserved | | | 5 | Reserved | | | 6 | Reserved | | | 7 | Reserved | | - | 8 | SHA256 [FIPS180] | "SHA256" | - | 9 | SHA384 [FIPS180] | "SHA384" | - | 10 | SHA512 [FIPS180] | "SHA512" | - | 11 | SHA224 [FIPS180] | "SHA224" | + | 8 | SHA2-256 [FIPS180] | "SHA256" | + | 9 | SHA2-384 [FIPS180] | "SHA384" | + | 10 | SHA2-512 [FIPS180] | "SHA512" | + | 11 | SHA2-224 [FIPS180] | "SHA224" | + | 12 | SHA3-256 [FIPS202] | "SHA3-256" | + | 13 | Reserved | | + | 14 | SHA3-512 [FIPS202] | "SHA3-512" | | 100--110 | Private/Experimental algorithm | | +-----------+---------------------------------+--------------+ - Implementations MUST implement SHA-1. Implementations MAY implement - other algorithms. MD5 is deprecated. + Implementations MUST implement SHA2-256. Implementations MAY + 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 OpenPGP is highly parameterized, and consequently there are a number of considerations for allocating parameters for extensions. This section describes how IANA should look at extensions to the protocol as described in this document. 10.1. {10.1} New String-to-Key Specifier Types @@ -3414,20 +3493,36 @@ OpenPGP specifies a number of hash algorithms. This specification creates a registry of hash algorithm identifiers. The registry includes the algorithm name, a text representation of that name, its block size, an OID hash prefix, and a reference to the defining specification. The initial values for this registry can be found in Section 9 for the algorithm identifiers and text names, and Section 5.2.2 for the OIDs and expanded signature prefixes. Adding a new hash algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. + 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 OpenPGP specifies a number of compression algorithms. This specification creates a registry of compression algorithm identifiers. The registry includes the algorithm name and a reference to the defining specification. The initial values for this registry can be found in Section 9.3. Adding a new compression key algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. @@ -3634,66 +3728,95 @@ and MD5 are deprecated. A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field. The Key ID is the low-order 64 bits of the fingerprint. Here are the fields of the hash material, with the example of a DSA key: a.1) 0x99 (1 octet) - a.2) high-order length octet of (b)-(e) (1 octet) - - a.3) low-order length octet of (b)-(e) (1 octet) + a.2) two-octet scalar octet count of (b)-(e) b) version number = 4 (1 octet); c) timestamp of key creation (4 octets); d) algorithm (1 octet): 17 = DSA (example); e) Algorithm-specific fields. Algorithm-Specific Fields for DSA keys (example): e.1) MPI of DSA prime p; 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.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 different keys with the same Key ID. Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint. - Also note that if V3 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 fingerprints. Finally, the Key ID and fingerprint of a subkey are calculated in the - same way as for a primary key, including the 0x99 as the first octet - (even though this is not a valid packet ID for a public subkey). + same way as for a primary key, including the 0x99 (V3 and V4 key) or + 0x9A (V5 key) as the first octet (even though this is not a valid + packet ID for a public subkey). 13. Elliptic Curve Cryptography This section descripes algorithms and parameters used with Elliptic Curve Cryptography (ECC) keys. A thorough introduction to ECC can be found in [KOBLITZ]. 13.1. Supported ECC Curves - This document references three named prime field curves, defined in - [FIPS186-3] as "Curve P-256", "Curve P-384", and "Curve P-521". - + This document references five named prime field curves, defined in + [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 referenced for use with the EdDSA algorithm. The named curves are referenced as a sequence of bytes in this document, called throughout, curve OID. Section 9.2 describes in detail how this sequence of bytes is formed. 13.2. ECDSA and ECDH Conversion Primitives This document only defines the uncompressed point format for ECDSA @@ -3736,21 +3859,21 @@ For example, the length of a public key for the curve Ed25519 is 263 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the native value of the public key. 13.4. Key Derivation Function A key derivation function (KDF) is necessary to implement the EC encryption. The Concatenation Key Derivation Function (Approved 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 convenience, the synopsis of the encoding method is given below with significant simplifications attributable to the restricted choice of hash functions in this document. However, [SP800-56A] is the normative source of the definition. // Implements KDF( X, oBits, Param ); // Input: point X = (x,y) // oBits - the desired size of output @@ -3807,21 +3930,22 @@ * a one-octet algorithm ID for the symmetric algorithm used to wrap the symmetric key for message encryption; see Section 8 for details 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 20 53 65 6E 64 65 72 20 20 20 20 o 20 octets representing a recipient encryption subkey or a master 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 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 symmetric key that is used as a key-encryption key (KEK) as specified in [RFC3394]. Refer to Section 13{FIXME} for the details regarding the choice of the KEK algorithm, which SHOULD be one of three AES algorithms. Key wrapping and unwrapping is performed with the default initial value of [RFC3394]. @@ -4078,21 +4202,21 @@ Typically, the choice of a hash algorithm is something the signer does, rather than the verifier, because a signer rarely knows who is going to be verifying the signature. This preference, though, allows a protocol based upon digital signatures ease in negotiation. Thus, if Alice is authenticating herself to Bob with a signature, it makes sense for her to use a hash algorithm that Bob's software uses. This preference allows Bob to state in his key which algorithms Alice may use. - 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 good form to place it there explicitly. 14.4. {13.4} Plaintext Algorithm 0, "plaintext", may only be used to denote secret keys that are stored in the clear. Implementations MUST NOT use plaintext in Symmetrically Encrypted Data packets; they must use Literal Data packets to encode unencrypted or literal data. @@ -4109,29 +4233,29 @@ 14.6. {13.6} DSA An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. It MUST NOT implement a DSA key with a q size of less than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the q size MUST be a multiple of 8 bits. The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: - o 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or - SHA-512 hash + o 1024-bit key, 160-bit q, SHA-1, SHA2--224, SHA2-256, SHA2-384, or + 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 - 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 strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be @@ -4255,21 +4379,21 @@ downgrade and cross-grade attacks. One simple way to do this is to create new packets for a new MDC. For example, instead of the MDC system using packets 18 and 19, a new MDC could use 20 and 21. This has obvious drawbacks (it uses two packet numbers for each new hash function in a space that is limited to a maximum of 60). Another simple way to extend the MDC system is to create new versions of packet 18, and reflect this in packet 19. For example, suppose - that V2 of packet 18 implicitly used SHA-256. This would require + 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 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 using the version number of a packet to carry algorithm information is not tidy from a protocol-design standpoint. It is possible that there might be several versions of the MDC system in common use, but this untidiness would reflect untidiness in cryptographic consensus about hash function security. The second is that different versions of packet 19 would have to have unique sizes. If there were two @@ -4315,23 +4439,23 @@ o Certain operations in this specification involve the use of random numbers. An appropriate entropy source should be used to generate these numbers (see [RFC4086]). o The MD5 hash algorithm has been found to have weaknesses, with collisions found in a number of cases. MD5 is deprecated for use in OpenPGP. Implementations MUST NOT generate new signatures using MD5 as a hash function. They MAY continue to consider old signatures that used MD5 as valid. - o SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512, - respectively. In general, there are few reasons to use them - outside of DSS compatibility. You need a situation where one + o SHA2-224 and SHA2-384 require the same work as SHA2-256 and + SHA2-512, respectively. In general, there are few reasons to use + them outside of DSS compatibility. You need a situation where one needs more security than smaller hashes, but does not want to have the full 256-bit or 512-bit data length. o Many security protocol designers think that it is a bad idea to use a single key for both privacy (encryption) and integrity (signatures). In fact, this was one of the motivating forces behind the V4 key format with separate signature and encryption keys. If you as an implementer promote dual-use keys, you should at least be aware of this controversy. @@ -4453,22 +4577,22 @@ timing information about the check can be exposed to an attacker, particularly via an automated service that allows rapidly repeated queries. On the other hand, it is inconvenient to the user to be informed that they typed in the wrong passphrase only after a petabyte of data is decrypted. There are many cases in cryptographic engineering where the implementer must use care and wisdom, and this is one. - o Refer to [FIPS186-3], B.4.1, for the method to generate a - uniformly distributed ECC private key. + o Refer to [FIPS186], B.4.1, for the method to generate a uniformly + distributed ECC private key. o The curves proposed in this document correspond to the symmetric key sizes 128 bits, 192 bits, and 256 bits, as described in the table below. This allows a compliant application to offer balanced public key security, which is compatible with the symmetric key strength for each AES algorithm defined here. The following table defines the hash and the symmetric encryption algorithm that SHOULD be used with a given curve for ECDSA or ECDH. A stronger hash algorithm or a symmetric key algorithm MAY @@ -4559,21 +4683,21 @@ network service performing decryption to unauthenticated remote users. ECC scalar multiplication operations used in ECDSA and ECDH are vulnerable to side channel attacks. Countermeasures can often be taken at the higher protocol level, such as limiting the number of allowed failures or time-blinding of the operations associated with each network interface. Mitigations at the scalar multiplication level seek to eliminate any measurable distinction between the ECC point addition and doubling operations. 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, intelligent people spending a lot of time thinking about the ramifications of their decisions. Removing the requirement for self- certifying User ID (and User Attribute) packets on a key means that someone could surreptitiously add an unwanted ID to a key and sign it. If enough "trusted" people sign that surreptitious identity then other people might believe it. The attack could wind up sending encrypted mail destined for alice to some other target, bob, because someone added "alice" to bob's key without bob's consent. @@ -4615,32 +4739,35 @@ 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 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 with a single signature. 16. Compatibility Profiles 16.1. OpenPGP ECC Profile - A compliant application MUST implement NIST curve P-256, MAY - implement NIST curve P-384, and SHOULD implement NIST curve P-521, 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 MUST implement NIST curve P-256, SHOULD + implement NIST curve P-521, SHOULD implemend Ed25519, SHOULD + implement Curve25519, MAY implement NIST curve P-384, MAY implement + brainpoolP256r1, MAY implement brainpoolP512r1, and MAY implement + 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 choice of the following algorithms for each curve: o the KDF hash algorithm, - o the KEK algorithm, + o the message digest algorithm and the hash algorithm used in the key certifications, o the symmetric algorithm used for message encryption. It is recommended that the chosen symmetric algorithm for message encryption be no less secure than the KEK algorithm. 16.2. Suite-B Profile @@ -4654,21 +4781,21 @@ this document. 16.3. Security Strength at 192 Bits To achieve the security strength of 192 bits, [SuiteB] requires NIST curve P-384, AES-256, and SHA2-384. The symmetric algorithm restriction means that the algorithm of KEK used for key wrapping in Section 8 and an OpenPGP session key used for message encryption must be AES-256. The hash algorithm restriction means that the hash algorithms of KDF and the OpenPGP message digest calculation must be - SHA-384. + SHA2-384. 16.4. Security Strength at 128 Bits The set of algorithms in Section 12.2.1{FIXME} is extended to allow NIST curve P-256, AES-128, and SHA2-256. 17. {15} Implementation Nits This section is a collection of comments to help an implementer, particularly with an eye to backward compatibility. Previous @@ -4753,37 +4880,34 @@ 1994, pp191-204, December 1993, . [BZ2] Seward, J., "The Bzip2 and libbzip2 home page", . [ELGAMAL] Elgamal, T., "A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms,", IEEE Transactions on Information Theory v. IT-31, n. 4, 1985, pp. 469-472, . - [FIPS180] NIST, "Secure Hash Signature Standard (SHS) (FIPS PUB - 180-2)", . - - [FIPS180-3] - National Institute of Standards and Technology, U.S. + [FIPS180] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard (SHS), FIPS - 180-3", October 2008. + 180-4", August 2015, + . - [FIPS186] NIST, "Digital Signature Standard (DSS) (FIPS PUB 186-2)", - . + [FIPS186] National Institute of Standards and Technology, U.S. + Department of Commerce, "Digital Signature Standard (DSS), + FIPS 186-4", July 2013, + . - [FIPS186-3] - National Institute of Standards and Technology, U.S. - Department of Commerce, "Digital Signature Standard, FIPS - 186-3", June 2009. + [FIPS202] National Institute of Standards and Technology, U.S. + Department of Commerce, "SHA-3 Standard: Permutation-Based + Hash and Extendable-Output Functions, FIPS 202", August + 2015, . [HAC] Menezes, A., Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", 1996. [I-D.irtf-cfrg-eddsa] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-02 (work in progress), January 2016. [IDEA] Lai, X., "On the design and security of block ciphers", @@ -4838,20 +4962,25 @@ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 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, + . + [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, DOI 10.17487/RFC5870, June 2010, . [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996. [SP800-56A] @@ -4928,21 +5057,21 @@ 43 ee 3b 24 06 A.2. Sample EdDSA signature The signature is created using the sample key over the input data "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash function is: m: 4f70656e504750040016080006050255f95f9504ff0000000c - Using the SHA-256 hash algorithm yields the digest: + Using the SHA2-256 hash algorithm yields the digest: d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280 Which is fed into the EdDSA signature function and yields this signature: r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366 s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404 @@ -4976,20 +5105,32 @@ o Added Camellia cipher from RFC 5581. o Incorporated RFC 6637 (ECC for OpenPGP) o Added draft-atkins-openpgp-device-certificates o Added draft-koch-eddsa-for-openpgp-04 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] } Appendix D. The principal authors of RFC-4880 are as follows: Jon Callas EMail: jon@callas.org Lutz Donnerhacke EMail: lutz@iks-jena.de