1*ebfedea0SLionel SambucNetwork Working Group Jon Callas 2*ebfedea0SLionel SambucInternet-Draft PGP Corporation 3*ebfedea0SLionel SambucIntended status: Standards Track 4*ebfedea0SLionel SambucExpires October 2007 Lutz Donnerhacke 5*ebfedea0SLionel SambucApr 2007 6*ebfedea0SLionel Sambuc 7*ebfedea0SLionel SambucObsoletes: 1991, 2440 Hal Finney 8*ebfedea0SLionel Sambuc PGP Corporation 9*ebfedea0SLionel Sambuc 10*ebfedea0SLionel Sambuc David Shaw 11*ebfedea0SLionel Sambuc 12*ebfedea0SLionel Sambuc Rodney Thayer 13*ebfedea0SLionel Sambuc 14*ebfedea0SLionel Sambuc OpenPGP Message Format 15*ebfedea0SLionel Sambuc draft-ietf-openpgp-rfc2440bis-22 16*ebfedea0SLionel Sambuc 17*ebfedea0SLionel Sambuc 18*ebfedea0SLionel SambucStatus of this Memo 19*ebfedea0SLionel Sambuc 20*ebfedea0SLionel Sambuc By submitting this Internet-Draft, each author represents that any 21*ebfedea0SLionel Sambuc applicable patent or other IPR claims of which he or she is aware 22*ebfedea0SLionel Sambuc have been or will be disclosed, and any of which he or she becomes 23*ebfedea0SLionel Sambuc aware will be disclosed, in accordance with Section 6 of BCP 79. 24*ebfedea0SLionel Sambuc 25*ebfedea0SLionel Sambuc Internet-Drafts are working documents of the Internet Engineering 26*ebfedea0SLionel Sambuc Task Force (IETF), its areas, and its working groups. Note that 27*ebfedea0SLionel Sambuc other groups may also distribute working documents as 28*ebfedea0SLionel Sambuc Internet-Drafts. 29*ebfedea0SLionel Sambuc 30*ebfedea0SLionel Sambuc Internet-Drafts are draft documents valid for a maximum of six 31*ebfedea0SLionel Sambuc months and may be updated, replaced, or obsoleted by other documents 32*ebfedea0SLionel Sambuc at any time. It is inappropriate to use Internet-Drafts as reference 33*ebfedea0SLionel Sambuc material or to cite them other than as "work in progress." 34*ebfedea0SLionel Sambuc 35*ebfedea0SLionel Sambuc The list of current Internet-Drafts can be accessed at 36*ebfedea0SLionel Sambuc http://www.ietf.org/1id-abstracts.html 37*ebfedea0SLionel Sambuc 38*ebfedea0SLionel Sambuc The list of Internet-Draft Shadow Directories can be accessed at 39*ebfedea0SLionel Sambuc http://www.ietf.org/shadow.html 40*ebfedea0SLionel Sambuc 41*ebfedea0SLionel SambucCopyright Notice 42*ebfedea0SLionel Sambuc 43*ebfedea0SLionel Sambuc Copyright (C) The IETF Trust (2007). 44*ebfedea0SLionel Sambuc 45*ebfedea0SLionel SambucAbstract 46*ebfedea0SLionel Sambuc 47*ebfedea0SLionel Sambuc This document is maintained in order to publish all necessary 48*ebfedea0SLionel Sambuc information needed to develop interoperable applications based on 49*ebfedea0SLionel Sambuc the OpenPGP format. It is not a step-by-step cookbook for writing an 50*ebfedea0SLionel Sambuc application. It describes only the format and methods needed to 51*ebfedea0SLionel Sambuc read, check, generate, and write conforming packets crossing any 52*ebfedea0SLionel Sambuc network. It does not deal with storage and implementation questions. 53*ebfedea0SLionel Sambuc It does, however, discuss implementation issues necessary to avoid 54*ebfedea0SLionel Sambuc security flaws. 55*ebfedea0SLionel Sambuc 56*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 1] 57*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 58*ebfedea0SLionel Sambuc 59*ebfedea0SLionel Sambuc OpenPGP software uses a combination of strong public-key and 60*ebfedea0SLionel Sambuc symmetric cryptography to provide security services for electronic 61*ebfedea0SLionel Sambuc communications and data storage. These services include 62*ebfedea0SLionel Sambuc confidentiality, key management, authentication, and digital 63*ebfedea0SLionel Sambuc signatures. This document specifies the message formats used in 64*ebfedea0SLionel Sambuc OpenPGP. 65*ebfedea0SLionel Sambuc 66*ebfedea0SLionel Sambuc 67*ebfedea0SLionel Sambuc 68*ebfedea0SLionel Sambuc 69*ebfedea0SLionel Sambuc 70*ebfedea0SLionel Sambuc 71*ebfedea0SLionel Sambuc 72*ebfedea0SLionel Sambuc 73*ebfedea0SLionel Sambuc 74*ebfedea0SLionel Sambuc 75*ebfedea0SLionel Sambuc 76*ebfedea0SLionel Sambuc 77*ebfedea0SLionel Sambuc 78*ebfedea0SLionel Sambuc 79*ebfedea0SLionel Sambuc 80*ebfedea0SLionel Sambuc 81*ebfedea0SLionel Sambuc 82*ebfedea0SLionel Sambuc 83*ebfedea0SLionel Sambuc 84*ebfedea0SLionel Sambuc 85*ebfedea0SLionel Sambuc 86*ebfedea0SLionel Sambuc 87*ebfedea0SLionel Sambuc 88*ebfedea0SLionel Sambuc 89*ebfedea0SLionel Sambuc 90*ebfedea0SLionel Sambuc 91*ebfedea0SLionel Sambuc 92*ebfedea0SLionel Sambuc 93*ebfedea0SLionel Sambuc 94*ebfedea0SLionel Sambuc 95*ebfedea0SLionel Sambuc 96*ebfedea0SLionel Sambuc 97*ebfedea0SLionel Sambuc 98*ebfedea0SLionel Sambuc 99*ebfedea0SLionel Sambuc 100*ebfedea0SLionel Sambuc 101*ebfedea0SLionel Sambuc 102*ebfedea0SLionel Sambuc 103*ebfedea0SLionel Sambuc 104*ebfedea0SLionel Sambuc 105*ebfedea0SLionel Sambuc 106*ebfedea0SLionel Sambuc 107*ebfedea0SLionel Sambuc 108*ebfedea0SLionel Sambuc 109*ebfedea0SLionel Sambuc 110*ebfedea0SLionel Sambuc 111*ebfedea0SLionel Sambuc 112*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 2] 113*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 114*ebfedea0SLionel Sambuc 115*ebfedea0SLionel SambucTable of Contents 116*ebfedea0SLionel Sambuc 117*ebfedea0SLionel Sambuc Status of this Memo 1 118*ebfedea0SLionel Sambuc Copyright Notice 1 119*ebfedea0SLionel Sambuc Abstract 1 120*ebfedea0SLionel Sambuc Table of Contents 3 121*ebfedea0SLionel Sambuc 1. Introduction 7 122*ebfedea0SLionel Sambuc 1.1. Terms 7 123*ebfedea0SLionel Sambuc 2. General functions 7 124*ebfedea0SLionel Sambuc 2.1. Confidentiality via Encryption 8 125*ebfedea0SLionel Sambuc 2.2. Authentication via Digital signature 9 126*ebfedea0SLionel Sambuc 2.3. Compression 9 127*ebfedea0SLionel Sambuc 2.4. Conversion to Radix-64 9 128*ebfedea0SLionel Sambuc 2.5. Signature-Only Applications 10 129*ebfedea0SLionel Sambuc 3. Data Element Formats 10 130*ebfedea0SLionel Sambuc 3.1. Scalar numbers 10 131*ebfedea0SLionel Sambuc 3.2. Multiprecision Integers 10 132*ebfedea0SLionel Sambuc 3.3. Key IDs 11 133*ebfedea0SLionel Sambuc 3.4. Text 11 134*ebfedea0SLionel Sambuc 3.5. Time fields 11 135*ebfedea0SLionel Sambuc 3.6. Keyrings 11 136*ebfedea0SLionel Sambuc 3.7. String-to-key (S2K) specifiers 11 137*ebfedea0SLionel Sambuc 3.7.1. String-to-key (S2K) specifier types 11 138*ebfedea0SLionel Sambuc 3.7.1.1. Simple S2K 12 139*ebfedea0SLionel Sambuc 3.7.1.2. Salted S2K 12 140*ebfedea0SLionel Sambuc 3.7.1.3. Iterated and Salted S2K 12 141*ebfedea0SLionel Sambuc 3.7.2. String-to-key usage 13 142*ebfedea0SLionel Sambuc 3.7.2.1. Secret key encryption 13 143*ebfedea0SLionel Sambuc 3.7.2.2. Symmetric-key message encryption 14 144*ebfedea0SLionel Sambuc 4. Packet Syntax 14 145*ebfedea0SLionel Sambuc 4.1. Overview 14 146*ebfedea0SLionel Sambuc 4.2. Packet Headers 14 147*ebfedea0SLionel Sambuc 4.2.1. Old-Format Packet Lengths 15 148*ebfedea0SLionel Sambuc 4.2.2. New-Format Packet Lengths 15 149*ebfedea0SLionel Sambuc 4.2.2.1. One-Octet Lengths 16 150*ebfedea0SLionel Sambuc 4.2.2.2. Two-Octet Lengths 16 151*ebfedea0SLionel Sambuc 4.2.2.3. Five-Octet Lengths 16 152*ebfedea0SLionel Sambuc 4.2.2.4. Partial Body Lengths 16 153*ebfedea0SLionel Sambuc 4.2.3. Packet Length Examples 17 154*ebfedea0SLionel Sambuc 4.3. Packet Tags 17 155*ebfedea0SLionel Sambuc 5. Packet Types 18 156*ebfedea0SLionel Sambuc 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 18 157*ebfedea0SLionel Sambuc 5.2. Signature Packet (Tag 2) 19 158*ebfedea0SLionel Sambuc 5.2.1. Signature Types 20 159*ebfedea0SLionel Sambuc 5.2.2. Version 3 Signature Packet Format 22 160*ebfedea0SLionel Sambuc 5.2.3. Version 4 Signature Packet Format 24 161*ebfedea0SLionel Sambuc 5.2.3.1. Signature Subpacket Specification 25 162*ebfedea0SLionel Sambuc 5.2.3.2. Signature Subpacket Types 27 163*ebfedea0SLionel Sambuc 5.2.3.3. Notes on Self-Signatures 27 164*ebfedea0SLionel Sambuc 5.2.3.4. Signature creation time 28 165*ebfedea0SLionel Sambuc 5.2.3.5. Issuer 28 166*ebfedea0SLionel Sambuc 5.2.3.6. Key expiration time 28 167*ebfedea0SLionel Sambuc 168*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 3] 169*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 170*ebfedea0SLionel Sambuc 171*ebfedea0SLionel Sambuc 5.2.3.7. Preferred symmetric algorithms 28 172*ebfedea0SLionel Sambuc 5.2.3.8. Preferred hash algorithms 29 173*ebfedea0SLionel Sambuc 5.2.3.9. Preferred compression algorithms 29 174*ebfedea0SLionel Sambuc 5.2.3.10.Signature expiration time 29 175*ebfedea0SLionel Sambuc 5.2.3.11.Exportable Certification 29 176*ebfedea0SLionel Sambuc 5.2.3.12.Revocable 30 177*ebfedea0SLionel Sambuc 5.2.3.13.Trust signature 30 178*ebfedea0SLionel Sambuc 5.2.3.14.Regular expression 30 179*ebfedea0SLionel Sambuc 5.2.3.15.Revocation key 31 180*ebfedea0SLionel Sambuc 5.2.3.16.Notation Data 31 181*ebfedea0SLionel Sambuc 5.2.3.17.Key server preferences 32 182*ebfedea0SLionel Sambuc 5.2.3.18.Preferred key server 32 183*ebfedea0SLionel Sambuc 5.2.3.19.Primary User ID 32 184*ebfedea0SLionel Sambuc 5.2.3.20.Policy URI 33 185*ebfedea0SLionel Sambuc 5.2.3.21.Key Flags 33 186*ebfedea0SLionel Sambuc 5.2.3.22.Signer's User ID 34 187*ebfedea0SLionel Sambuc 5.2.3.23.Reason for Revocation 34 188*ebfedea0SLionel Sambuc 5.2.3.24.Features 35 189*ebfedea0SLionel Sambuc 5.2.3.25.Signature Target 35 190*ebfedea0SLionel Sambuc 5.2.3.26.Embedded Signature 36 191*ebfedea0SLionel Sambuc 5.2.4. Computing Signatures 36 192*ebfedea0SLionel Sambuc 5.2.4.1. Subpacket Hints 37 193*ebfedea0SLionel Sambuc 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 37 194*ebfedea0SLionel Sambuc 5.4. One-Pass Signature Packets (Tag 4) 38 195*ebfedea0SLionel Sambuc 5.5. Key Material Packet 39 196*ebfedea0SLionel Sambuc 5.5.1. Key Packet Variants 39 197*ebfedea0SLionel Sambuc 5.5.1.1. Public Key Packet (Tag 6) 39 198*ebfedea0SLionel Sambuc 5.5.1.2. Public Subkey Packet (Tag 14) 39 199*ebfedea0SLionel Sambuc 5.5.1.3. Secret Key Packet (Tag 5) 39 200*ebfedea0SLionel Sambuc 5.5.1.4. Secret Subkey Packet (Tag 7) 40 201*ebfedea0SLionel Sambuc 5.5.2. Public Key Packet Formats 40 202*ebfedea0SLionel Sambuc 5.5.3. Secret Key Packet Formats 41 203*ebfedea0SLionel Sambuc 5.6. Compressed Data Packet (Tag 8) 43 204*ebfedea0SLionel Sambuc 5.7. Symmetrically Encrypted Data Packet (Tag 9) 44 205*ebfedea0SLionel Sambuc 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 44 206*ebfedea0SLionel Sambuc 5.9. Literal Data Packet (Tag 11) 45 207*ebfedea0SLionel Sambuc 5.10. Trust Packet (Tag 12) 46 208*ebfedea0SLionel Sambuc 5.11. User ID Packet (Tag 13) 46 209*ebfedea0SLionel Sambuc 5.12. User Attribute Packet (Tag 17) 46 210*ebfedea0SLionel Sambuc 5.12.1. The Image Attribute Subpacket 47 211*ebfedea0SLionel Sambuc 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 47 212*ebfedea0SLionel Sambuc 5.14. Modification Detection Code Packet (Tag 19) 50 213*ebfedea0SLionel Sambuc 6. Radix-64 Conversions 51 214*ebfedea0SLionel Sambuc 6.1. An Implementation of the CRC-24 in "C" 51 215*ebfedea0SLionel Sambuc 6.2. Forming ASCII Armor 52 216*ebfedea0SLionel Sambuc 6.3. Encoding Binary in Radix-64 54 217*ebfedea0SLionel Sambuc 6.4. Decoding Radix-64 55 218*ebfedea0SLionel Sambuc 6.5. Examples of Radix-64 56 219*ebfedea0SLionel Sambuc 6.6. Example of an ASCII Armored Message 56 220*ebfedea0SLionel Sambuc 7. Cleartext signature framework 56 221*ebfedea0SLionel Sambuc 7.1. Dash-Escaped Text 57 222*ebfedea0SLionel Sambuc 8. Regular Expressions 58 223*ebfedea0SLionel Sambuc 224*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 4] 225*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 226*ebfedea0SLionel Sambuc 227*ebfedea0SLionel Sambuc 9. Constants 58 228*ebfedea0SLionel Sambuc 9.1. Public Key Algorithms 59 229*ebfedea0SLionel Sambuc 9.2. Symmetric Key Algorithms 59 230*ebfedea0SLionel Sambuc 9.3. Compression Algorithms 60 231*ebfedea0SLionel Sambuc 9.4. Hash Algorithms 60 232*ebfedea0SLionel Sambuc 10. IANA Considerations 60 233*ebfedea0SLionel Sambuc 10.1. New String-to-Key specifier types 60 234*ebfedea0SLionel Sambuc 10.2. New Packets 61 235*ebfedea0SLionel Sambuc 10.2.1. User Attribute Types 61 236*ebfedea0SLionel Sambuc 10.2.1.1.Image Format Subpacket Types 61 237*ebfedea0SLionel Sambuc 10.2.2. New Signature Subpackets 61 238*ebfedea0SLionel Sambuc 10.2.2.1.Signature Notation Data Subpackets 61 239*ebfedea0SLionel Sambuc 10.2.2.2.Key Server Preference Extensions 62 240*ebfedea0SLionel Sambuc 10.2.2.3.Key Flags Extensions 62 241*ebfedea0SLionel Sambuc 10.2.2.4.Reason For Revocation Extensions 62 242*ebfedea0SLionel Sambuc 10.2.2.5.Implementation Features 62 243*ebfedea0SLionel Sambuc 10.2.3. New Packet Versions 62 244*ebfedea0SLionel Sambuc 10.3. New Algorithms 63 245*ebfedea0SLionel Sambuc 10.3.1. Public Key Algorithms 63 246*ebfedea0SLionel Sambuc 10.3.2. Symmetric Key Algorithms 63 247*ebfedea0SLionel Sambuc 10.3.3. Hash Algorithms 63 248*ebfedea0SLionel Sambuc 10.3.4. Compression Algorithms 64 249*ebfedea0SLionel Sambuc 11. Packet Composition 64 250*ebfedea0SLionel Sambuc 11.1. Transferable Public Keys 64 251*ebfedea0SLionel Sambuc 11.2. Transferable Secret Keys 65 252*ebfedea0SLionel Sambuc 11.3. OpenPGP Messages 65 253*ebfedea0SLionel Sambuc 11.4. Detached Signatures 66 254*ebfedea0SLionel Sambuc 12. Enhanced Key Formats 66 255*ebfedea0SLionel Sambuc 12.1. Key Structures 66 256*ebfedea0SLionel Sambuc 12.2. Key IDs and Fingerprints 67 257*ebfedea0SLionel Sambuc 13. Notes on Algorithms 68 258*ebfedea0SLionel Sambuc 13.1. PKCS#1 Encoding In OpenPGP 68 259*ebfedea0SLionel Sambuc 13.1.1. EME-PKCS1-v1_5-ENCODE 69 260*ebfedea0SLionel Sambuc 13.1.2. EME-PKCS1-v1_5-DECODE 69 261*ebfedea0SLionel Sambuc 13.1.3. EMSA-PKCS1-v1_5 70 262*ebfedea0SLionel Sambuc 13.2. Symmetric Algorithm Preferences 71 263*ebfedea0SLionel Sambuc 13.3. Other Algorithm Preferences 71 264*ebfedea0SLionel Sambuc 13.3.1. Compression Preferences 71 265*ebfedea0SLionel Sambuc 13.3.2. Hash Algorithm Preferences 72 266*ebfedea0SLionel Sambuc 13.4. Plaintext 72 267*ebfedea0SLionel Sambuc 13.5. RSA 72 268*ebfedea0SLionel Sambuc 13.6. DSA 73 269*ebfedea0SLionel Sambuc 13.7. Elgamal 73 270*ebfedea0SLionel Sambuc 13.8. Reserved Algorithm Numbers 73 271*ebfedea0SLionel Sambuc 13.9. OpenPGP CFB mode 74 272*ebfedea0SLionel Sambuc 13.10. Private or Experimental Parameters 75 273*ebfedea0SLionel Sambuc 13.11. Extension of the MDC System 75 274*ebfedea0SLionel Sambuc 13.12. Meta-Considerations for Expansion 76 275*ebfedea0SLionel Sambuc 14. Security Considerations 76 276*ebfedea0SLionel Sambuc 15. Implementation Nits 79 277*ebfedea0SLionel Sambuc 16. Authors' Addresses 80 278*ebfedea0SLionel Sambuc 17. References (Normative) 81 279*ebfedea0SLionel Sambuc 280*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 5] 281*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 282*ebfedea0SLionel Sambuc 283*ebfedea0SLionel Sambuc 18. References (Informative) 83 284*ebfedea0SLionel Sambuc 19. Full Copyright Statement 84 285*ebfedea0SLionel Sambuc 20. Intellectual Property 84 286*ebfedea0SLionel Sambuc 287*ebfedea0SLionel Sambuc 288*ebfedea0SLionel Sambuc 289*ebfedea0SLionel Sambuc 290*ebfedea0SLionel Sambuc 291*ebfedea0SLionel Sambuc 292*ebfedea0SLionel Sambuc 293*ebfedea0SLionel Sambuc 294*ebfedea0SLionel Sambuc 295*ebfedea0SLionel Sambuc 296*ebfedea0SLionel Sambuc 297*ebfedea0SLionel Sambuc 298*ebfedea0SLionel Sambuc 299*ebfedea0SLionel Sambuc 300*ebfedea0SLionel Sambuc 301*ebfedea0SLionel Sambuc 302*ebfedea0SLionel Sambuc 303*ebfedea0SLionel Sambuc 304*ebfedea0SLionel Sambuc 305*ebfedea0SLionel Sambuc 306*ebfedea0SLionel Sambuc 307*ebfedea0SLionel Sambuc 308*ebfedea0SLionel Sambuc 309*ebfedea0SLionel Sambuc 310*ebfedea0SLionel Sambuc 311*ebfedea0SLionel Sambuc 312*ebfedea0SLionel Sambuc 313*ebfedea0SLionel Sambuc 314*ebfedea0SLionel Sambuc 315*ebfedea0SLionel Sambuc 316*ebfedea0SLionel Sambuc 317*ebfedea0SLionel Sambuc 318*ebfedea0SLionel Sambuc 319*ebfedea0SLionel Sambuc 320*ebfedea0SLionel Sambuc 321*ebfedea0SLionel Sambuc 322*ebfedea0SLionel Sambuc 323*ebfedea0SLionel Sambuc 324*ebfedea0SLionel Sambuc 325*ebfedea0SLionel Sambuc 326*ebfedea0SLionel Sambuc 327*ebfedea0SLionel Sambuc 328*ebfedea0SLionel Sambuc 329*ebfedea0SLionel Sambuc 330*ebfedea0SLionel Sambuc 331*ebfedea0SLionel Sambuc 332*ebfedea0SLionel Sambuc 333*ebfedea0SLionel Sambuc 334*ebfedea0SLionel Sambuc 335*ebfedea0SLionel Sambuc 336*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 6] 337*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 338*ebfedea0SLionel Sambuc 339*ebfedea0SLionel Sambuc1. Introduction 340*ebfedea0SLionel Sambuc 341*ebfedea0SLionel Sambuc This document provides information on the message-exchange packet 342*ebfedea0SLionel Sambuc formats used by OpenPGP to provide encryption, decryption, signing, 343*ebfedea0SLionel Sambuc and key management functions. It is a revision of RFC 2440, "OpenPGP 344*ebfedea0SLionel Sambuc Message Format", which itself replaces RFC 1991, "PGP Message 345*ebfedea0SLionel Sambuc Exchange Formats." [RFC1991] [RFC2440] 346*ebfedea0SLionel Sambuc 347*ebfedea0SLionel Sambuc1.1. Terms 348*ebfedea0SLionel Sambuc 349*ebfedea0SLionel Sambuc * OpenPGP - This is a definition for security software that uses 350*ebfedea0SLionel Sambuc PGP 5.x as a basis, formalized in RFC 2440 and this document. 351*ebfedea0SLionel Sambuc 352*ebfedea0SLionel Sambuc * PGP - Pretty Good Privacy. PGP is a family of software systems 353*ebfedea0SLionel Sambuc developed by Philip R. Zimmermann from which OpenPGP is based. 354*ebfedea0SLionel Sambuc 355*ebfedea0SLionel Sambuc * PGP 2.6.x - This version of PGP has many variants, hence the 356*ebfedea0SLionel Sambuc term PGP 2.6.x. It used only RSA, MD5, and IDEA for its 357*ebfedea0SLionel Sambuc cryptographic transforms. An informational RFC, RFC 1991, was 358*ebfedea0SLionel Sambuc written describing this version of PGP. 359*ebfedea0SLionel Sambuc 360*ebfedea0SLionel Sambuc * PGP 5.x - This version of PGP is formerly known as "PGP 3" in 361*ebfedea0SLionel Sambuc the community and also in the predecessor of this document, RFC 362*ebfedea0SLionel Sambuc 1991. It has new formats and corrects a number of problems in 363*ebfedea0SLionel Sambuc the PGP 2.6.x design. It is referred to here as PGP 5.x because 364*ebfedea0SLionel Sambuc that software was the first release of the "PGP 3" code base. 365*ebfedea0SLionel Sambuc 366*ebfedea0SLionel Sambuc * GnuPG - GNU Privacy Guard, also called GPG. GnuPG is an OpenPGP 367*ebfedea0SLionel Sambuc implementation that avoids all encumbered algorithms. 368*ebfedea0SLionel Sambuc Consequently, early versions of GnuPG did not include RSA public 369*ebfedea0SLionel Sambuc keys. GnuPG may or may not have (depending on version) support 370*ebfedea0SLionel Sambuc for IDEA or other encumbered algorithms. 371*ebfedea0SLionel Sambuc 372*ebfedea0SLionel Sambuc "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of 373*ebfedea0SLionel Sambuc PGP Corporation and are used with permission. The term "OpenPGP" 374*ebfedea0SLionel Sambuc refers to the protocol described in this and related documents. 375*ebfedea0SLionel Sambuc 376*ebfedea0SLionel Sambuc The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 377*ebfedea0SLionel Sambuc "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 378*ebfedea0SLionel Sambuc document are to be interpreted as described in RFC 2119. 379*ebfedea0SLionel Sambuc 380*ebfedea0SLionel Sambuc The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 381*ebfedea0SLionel Sambuc FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 382*ebfedea0SLionel Sambuc APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 383*ebfedea0SLionel Sambuc this document when used to describe namespace allocation are to be 384*ebfedea0SLionel Sambuc interpreted as described in RFC 2434. 385*ebfedea0SLionel Sambuc 386*ebfedea0SLionel Sambuc2. General functions 387*ebfedea0SLionel Sambuc 388*ebfedea0SLionel Sambuc OpenPGP provides data integrity services for messages and data files 389*ebfedea0SLionel Sambuc by using these core technologies: 390*ebfedea0SLionel Sambuc 391*ebfedea0SLionel Sambuc 392*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 7] 393*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 394*ebfedea0SLionel Sambuc 395*ebfedea0SLionel Sambuc - digital signatures 396*ebfedea0SLionel Sambuc 397*ebfedea0SLionel Sambuc - encryption 398*ebfedea0SLionel Sambuc 399*ebfedea0SLionel Sambuc - compression 400*ebfedea0SLionel Sambuc 401*ebfedea0SLionel Sambuc - radix-64 conversion 402*ebfedea0SLionel Sambuc 403*ebfedea0SLionel Sambuc In addition, OpenPGP provides key management and certificate 404*ebfedea0SLionel Sambuc services, but many of these are beyond the scope of this document. 405*ebfedea0SLionel Sambuc 406*ebfedea0SLionel Sambuc2.1. Confidentiality via Encryption 407*ebfedea0SLionel Sambuc 408*ebfedea0SLionel Sambuc OpenPGP combines symmetric-key encryption and public key encryption 409*ebfedea0SLionel Sambuc to provide confidentiality. When made confidential, first the object 410*ebfedea0SLionel Sambuc is encrypted using a symmetric encryption algorithm. Each symmetric 411*ebfedea0SLionel Sambuc key is used only once, for a single object. A new "session key" is 412*ebfedea0SLionel Sambuc generated as a random number for each object (sometimes referred to 413*ebfedea0SLionel Sambuc as a session). Since it is used only once, the session key is bound 414*ebfedea0SLionel Sambuc to the message and transmitted with it. To protect the key, it is 415*ebfedea0SLionel Sambuc encrypted with the receiver's public key. The sequence is as 416*ebfedea0SLionel Sambuc follows: 417*ebfedea0SLionel Sambuc 418*ebfedea0SLionel Sambuc 1. The sender creates a message. 419*ebfedea0SLionel Sambuc 420*ebfedea0SLionel Sambuc 2. The sending OpenPGP generates a random number to be used as a 421*ebfedea0SLionel Sambuc session key for this message only. 422*ebfedea0SLionel Sambuc 423*ebfedea0SLionel Sambuc 3. The session key is encrypted using each recipient's public key. 424*ebfedea0SLionel Sambuc These "encrypted session keys" start the message. 425*ebfedea0SLionel Sambuc 426*ebfedea0SLionel Sambuc 4. The sending OpenPGP encrypts the message using the session key, 427*ebfedea0SLionel Sambuc which forms the remainder of the message. Note that the message 428*ebfedea0SLionel Sambuc is also usually compressed. 429*ebfedea0SLionel Sambuc 430*ebfedea0SLionel Sambuc 5. The receiving OpenPGP decrypts the session key using the 431*ebfedea0SLionel Sambuc recipient's private key. 432*ebfedea0SLionel Sambuc 433*ebfedea0SLionel Sambuc 6. The receiving OpenPGP decrypts the message using the session 434*ebfedea0SLionel Sambuc key. If the message was compressed, it will be decompressed. 435*ebfedea0SLionel Sambuc 436*ebfedea0SLionel Sambuc With symmetric-key encryption, an object may be encrypted with a 437*ebfedea0SLionel Sambuc symmetric key derived from a passphrase (or other shared secret), or 438*ebfedea0SLionel Sambuc a two-stage mechanism similar to the public-key method described 439*ebfedea0SLionel Sambuc above in which a session key is itself encrypted with a symmetric 440*ebfedea0SLionel Sambuc algorithm keyed from a shared secret. 441*ebfedea0SLionel Sambuc 442*ebfedea0SLionel Sambuc Both digital signature and confidentiality services may be applied 443*ebfedea0SLionel Sambuc to the same message. First, a signature is generated for the message 444*ebfedea0SLionel Sambuc and attached to the message. Then, the message plus signature is 445*ebfedea0SLionel Sambuc encrypted using a symmetric session key. Finally, the session key is 446*ebfedea0SLionel Sambuc encrypted using public-key encryption and prefixed to the encrypted 447*ebfedea0SLionel Sambuc 448*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 8] 449*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 450*ebfedea0SLionel Sambuc 451*ebfedea0SLionel Sambuc block. 452*ebfedea0SLionel Sambuc 453*ebfedea0SLionel Sambuc2.2. Authentication via Digital signature 454*ebfedea0SLionel Sambuc 455*ebfedea0SLionel Sambuc The digital signature uses a hash code or message digest algorithm, 456*ebfedea0SLionel Sambuc and a public-key signature algorithm. The sequence is as follows: 457*ebfedea0SLionel Sambuc 458*ebfedea0SLionel Sambuc 1. The sender creates a message. 459*ebfedea0SLionel Sambuc 460*ebfedea0SLionel Sambuc 2. The sending software generates a hash code of the message. 461*ebfedea0SLionel Sambuc 462*ebfedea0SLionel Sambuc 3. The sending software generates a signature from the hash code 463*ebfedea0SLionel Sambuc using the sender's private key. 464*ebfedea0SLionel Sambuc 465*ebfedea0SLionel Sambuc 4. The binary signature is attached to the message. 466*ebfedea0SLionel Sambuc 467*ebfedea0SLionel Sambuc 5. The receiving software keeps a copy of the message signature. 468*ebfedea0SLionel Sambuc 469*ebfedea0SLionel Sambuc 6. The receiving software generates a new hash code for the 470*ebfedea0SLionel Sambuc received message and verifies it using the message's signature. 471*ebfedea0SLionel Sambuc If the verification is successful, the message is accepted as 472*ebfedea0SLionel Sambuc authentic. 473*ebfedea0SLionel Sambuc 474*ebfedea0SLionel Sambuc2.3. Compression 475*ebfedea0SLionel Sambuc 476*ebfedea0SLionel Sambuc OpenPGP implementations SHOULD compress the message after applying 477*ebfedea0SLionel Sambuc the signature but before encryption. 478*ebfedea0SLionel Sambuc 479*ebfedea0SLionel Sambuc If an implementation does not implement compression, its authors 480*ebfedea0SLionel Sambuc should be aware that most OpenPGP messages in the world are 481*ebfedea0SLionel Sambuc compressed. Thus, it may even be wise for a space-constrained 482*ebfedea0SLionel Sambuc implementation to implement decompression, but not compression. 483*ebfedea0SLionel Sambuc 484*ebfedea0SLionel Sambuc Furthermore, compression has the added side-effect that some types 485*ebfedea0SLionel Sambuc of attacks can be thwarted by the fact that slightly altered, 486*ebfedea0SLionel Sambuc compressed data rarely uncompresses without severe errors. This is 487*ebfedea0SLionel Sambuc hardly rigorous, but it is operationally useful. These attacks can 488*ebfedea0SLionel Sambuc be rigorously prevented by implementing and using Modification 489*ebfedea0SLionel Sambuc Detection Codes as described in sections following. 490*ebfedea0SLionel Sambuc 491*ebfedea0SLionel Sambuc2.4. Conversion to Radix-64 492*ebfedea0SLionel Sambuc 493*ebfedea0SLionel Sambuc OpenPGP's underlying native representation for encrypted messages, 494*ebfedea0SLionel Sambuc signature certificates, and keys is a stream of arbitrary octets. 495*ebfedea0SLionel Sambuc Some systems only permit the use of blocks consisting of seven-bit, 496*ebfedea0SLionel Sambuc printable text. For transporting OpenPGP's native raw binary octets 497*ebfedea0SLionel Sambuc through channels that are not safe to raw binary data, a printable 498*ebfedea0SLionel Sambuc encoding of these binary octets is needed. OpenPGP provides the 499*ebfedea0SLionel Sambuc service of converting the raw 8-bit binary octet stream to a stream 500*ebfedea0SLionel Sambuc of printable ASCII characters, called Radix-64 encoding or ASCII 501*ebfedea0SLionel Sambuc Armor. 502*ebfedea0SLionel Sambuc 503*ebfedea0SLionel Sambuc 504*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 9] 505*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 506*ebfedea0SLionel Sambuc 507*ebfedea0SLionel Sambuc Implementations SHOULD provide Radix-64 conversions. 508*ebfedea0SLionel Sambuc 509*ebfedea0SLionel Sambuc2.5. Signature-Only Applications 510*ebfedea0SLionel Sambuc 511*ebfedea0SLionel Sambuc OpenPGP is designed for applications that use both encryption and 512*ebfedea0SLionel Sambuc signatures, but there are a number of problems that are solved by a 513*ebfedea0SLionel Sambuc signature-only implementation. Although this specification requires 514*ebfedea0SLionel Sambuc both encryption and signatures, it is reasonable for there to be 515*ebfedea0SLionel Sambuc subset implementations that are non-conformant only in that they 516*ebfedea0SLionel Sambuc omit encryption. 517*ebfedea0SLionel Sambuc 518*ebfedea0SLionel Sambuc3. Data Element Formats 519*ebfedea0SLionel Sambuc 520*ebfedea0SLionel Sambuc This section describes the data elements used by OpenPGP. 521*ebfedea0SLionel Sambuc 522*ebfedea0SLionel Sambuc3.1. Scalar numbers 523*ebfedea0SLionel Sambuc 524*ebfedea0SLionel Sambuc Scalar numbers are unsigned, and are always stored in big-endian 525*ebfedea0SLionel Sambuc format. Using n[k] to refer to the kth octet being interpreted, the 526*ebfedea0SLionel Sambuc value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a 527*ebfedea0SLionel Sambuc four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + 528*ebfedea0SLionel Sambuc n[3]). 529*ebfedea0SLionel Sambuc 530*ebfedea0SLionel Sambuc3.2. Multiprecision Integers 531*ebfedea0SLionel Sambuc 532*ebfedea0SLionel Sambuc Multiprecision Integers (also called MPIs) are unsigned integers 533*ebfedea0SLionel Sambuc used to hold large integers such as the ones used in cryptographic 534*ebfedea0SLionel Sambuc calculations. 535*ebfedea0SLionel Sambuc 536*ebfedea0SLionel Sambuc An MPI consists of two pieces: a two-octet scalar that is the length 537*ebfedea0SLionel Sambuc of the MPI in bits followed by a string of octets that contain the 538*ebfedea0SLionel Sambuc actual integer. 539*ebfedea0SLionel Sambuc 540*ebfedea0SLionel Sambuc These octets form a big-endian number; a big-endian number can be 541*ebfedea0SLionel Sambuc made into an MPI by prefixing it with the appropriate length. 542*ebfedea0SLionel Sambuc 543*ebfedea0SLionel Sambuc Examples: 544*ebfedea0SLionel Sambuc 545*ebfedea0SLionel Sambuc (all numbers are in hexadecimal) 546*ebfedea0SLionel Sambuc 547*ebfedea0SLionel Sambuc The string of octets [00 01 01] forms an MPI with the value 1. The 548*ebfedea0SLionel Sambuc string [00 09 01 FF] forms an MPI with the value of 511. 549*ebfedea0SLionel Sambuc 550*ebfedea0SLionel Sambuc Additional rules: 551*ebfedea0SLionel Sambuc 552*ebfedea0SLionel Sambuc The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. 553*ebfedea0SLionel Sambuc 554*ebfedea0SLionel Sambuc The length field of an MPI describes the length starting from its 555*ebfedea0SLionel Sambuc most significant non-zero bit. Thus, the MPI [00 02 01] is not 556*ebfedea0SLionel Sambuc formed correctly. It should be [00 01 01]. 557*ebfedea0SLionel Sambuc 558*ebfedea0SLionel Sambuc 559*ebfedea0SLionel Sambuc 560*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 10] 561*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 562*ebfedea0SLionel Sambuc 563*ebfedea0SLionel Sambuc Unused bits of an MPI MUST be zero. 564*ebfedea0SLionel Sambuc 565*ebfedea0SLionel Sambuc Also note that when an MPI is encrypted, the length refers to the 566*ebfedea0SLionel Sambuc plaintext MPI. It may be ill-formed in its ciphertext. 567*ebfedea0SLionel Sambuc 568*ebfedea0SLionel Sambuc3.3. Key IDs 569*ebfedea0SLionel Sambuc 570*ebfedea0SLionel Sambuc A Key ID is an eight-octet scalar that identifies a key. 571*ebfedea0SLionel Sambuc Implementations SHOULD NOT assume that Key IDs are unique. The 572*ebfedea0SLionel Sambuc section, "Enhanced Key Formats" below describes how Key IDs are 573*ebfedea0SLionel Sambuc formed. 574*ebfedea0SLionel Sambuc 575*ebfedea0SLionel Sambuc3.4. Text 576*ebfedea0SLionel Sambuc 577*ebfedea0SLionel Sambuc Unless otherwise specified, the character set for text is the UTF-8 578*ebfedea0SLionel Sambuc [RFC3629] encoding of Unicode [ISO10646]. 579*ebfedea0SLionel Sambuc 580*ebfedea0SLionel Sambuc3.5. Time fields 581*ebfedea0SLionel Sambuc 582*ebfedea0SLionel Sambuc A time field is an unsigned four-octet number containing the number 583*ebfedea0SLionel Sambuc of seconds elapsed since midnight, 1 January 1970 UTC. 584*ebfedea0SLionel Sambuc 585*ebfedea0SLionel Sambuc3.6. Keyrings 586*ebfedea0SLionel Sambuc 587*ebfedea0SLionel Sambuc A keyring is a collection of one or more keys in a file or database. 588*ebfedea0SLionel Sambuc Traditionally, a keyring is simply a sequential list of keys, but 589*ebfedea0SLionel Sambuc may be any suitable database. It is beyond the scope of this 590*ebfedea0SLionel Sambuc standard to discuss the details of keyrings or other databases. 591*ebfedea0SLionel Sambuc 592*ebfedea0SLionel Sambuc3.7. String-to-key (S2K) specifiers 593*ebfedea0SLionel Sambuc 594*ebfedea0SLionel Sambuc String-to-key (S2K) specifiers are used to convert passphrase 595*ebfedea0SLionel Sambuc strings into symmetric-key encryption/decryption keys. They are used 596*ebfedea0SLionel Sambuc in two places, currently: to encrypt the secret part of private keys 597*ebfedea0SLionel Sambuc in the private keyring, and to convert passphrases to encryption 598*ebfedea0SLionel Sambuc keys for symmetrically encrypted messages. 599*ebfedea0SLionel Sambuc 600*ebfedea0SLionel Sambuc3.7.1. String-to-key (S2K) specifier types 601*ebfedea0SLionel Sambuc 602*ebfedea0SLionel Sambuc There are three types of S2K specifiers currently supported, and 603*ebfedea0SLionel Sambuc some reserved values: 604*ebfedea0SLionel Sambuc 605*ebfedea0SLionel Sambuc ID S2K Type 606*ebfedea0SLionel Sambuc -- --- ---- 607*ebfedea0SLionel Sambuc 0 Simple S2K 608*ebfedea0SLionel Sambuc 1 Salted S2K 609*ebfedea0SLionel Sambuc 2 Reserved value 610*ebfedea0SLionel Sambuc 3 Iterated and Salted S2K 611*ebfedea0SLionel Sambuc 100 to 110 Private/Experimental S2K 612*ebfedea0SLionel Sambuc 613*ebfedea0SLionel Sambuc 614*ebfedea0SLionel Sambuc 615*ebfedea0SLionel Sambuc 616*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 11] 617*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 618*ebfedea0SLionel Sambuc 619*ebfedea0SLionel Sambuc These are described as follows: 620*ebfedea0SLionel Sambuc 621*ebfedea0SLionel Sambuc3.7.1.1. Simple S2K 622*ebfedea0SLionel Sambuc 623*ebfedea0SLionel Sambuc This directly hashes the string to produce the key data. See below 624*ebfedea0SLionel Sambuc for how this hashing is done. 625*ebfedea0SLionel Sambuc 626*ebfedea0SLionel Sambuc Octet 0: 0x00 627*ebfedea0SLionel Sambuc Octet 1: hash algorithm 628*ebfedea0SLionel Sambuc 629*ebfedea0SLionel Sambuc Simple S2K hashes the passphrase to produce the session key. The 630*ebfedea0SLionel Sambuc manner in which this is done depends on the size of the session key 631*ebfedea0SLionel Sambuc (which will depend on the cipher used) and the size of the hash 632*ebfedea0SLionel Sambuc algorithm's output. If the hash size is greater than the session key 633*ebfedea0SLionel Sambuc size, the high-order (leftmost) octets of the hash are used as the 634*ebfedea0SLionel Sambuc key. 635*ebfedea0SLionel Sambuc 636*ebfedea0SLionel Sambuc If the hash size is less than the key size, multiple instances of 637*ebfedea0SLionel Sambuc the hash context are created -- enough to produce the required key 638*ebfedea0SLionel Sambuc data. These instances are preloaded with 0, 1, 2, ... octets of 639*ebfedea0SLionel Sambuc zeros (that is to say, the first instance has no preloading, the 640*ebfedea0SLionel Sambuc second gets preloaded with 1 octet of zero, the third is preloaded 641*ebfedea0SLionel Sambuc with two octets of zeros, and so forth). 642*ebfedea0SLionel Sambuc 643*ebfedea0SLionel Sambuc As the data is hashed, it is given independently to each hash 644*ebfedea0SLionel Sambuc context. Since the contexts have been initialized differently, they 645*ebfedea0SLionel Sambuc will each produce different hash output. Once the passphrase is 646*ebfedea0SLionel Sambuc hashed, the output data from the multiple hashes is concatenated, 647*ebfedea0SLionel Sambuc first hash leftmost, to produce the key data, with any excess octets 648*ebfedea0SLionel Sambuc on the right discarded. 649*ebfedea0SLionel Sambuc 650*ebfedea0SLionel Sambuc3.7.1.2. Salted S2K 651*ebfedea0SLionel Sambuc 652*ebfedea0SLionel Sambuc This includes a "salt" value in the S2K specifier -- some arbitrary 653*ebfedea0SLionel Sambuc data -- that gets hashed along with the passphrase string, to help 654*ebfedea0SLionel Sambuc prevent dictionary attacks. 655*ebfedea0SLionel Sambuc 656*ebfedea0SLionel Sambuc Octet 0: 0x01 657*ebfedea0SLionel Sambuc Octet 1: hash algorithm 658*ebfedea0SLionel Sambuc Octets 2-9: 8-octet salt value 659*ebfedea0SLionel Sambuc 660*ebfedea0SLionel Sambuc Salted S2K is exactly like Simple S2K, except that the input to the 661*ebfedea0SLionel Sambuc hash function(s) consists of the 8 octets of salt from the S2K 662*ebfedea0SLionel Sambuc specifier, followed by the passphrase. 663*ebfedea0SLionel Sambuc 664*ebfedea0SLionel Sambuc3.7.1.3. Iterated and Salted S2K 665*ebfedea0SLionel Sambuc 666*ebfedea0SLionel Sambuc This includes both a salt and an octet count. The salt is combined 667*ebfedea0SLionel Sambuc with the passphrase and the resulting value is hashed repeatedly. 668*ebfedea0SLionel Sambuc This further increases the amount of work an attacker must do to try 669*ebfedea0SLionel Sambuc dictionary attacks. 670*ebfedea0SLionel Sambuc 671*ebfedea0SLionel Sambuc 672*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 12] 673*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 674*ebfedea0SLionel Sambuc 675*ebfedea0SLionel Sambuc Octet 0: 0x03 676*ebfedea0SLionel Sambuc Octet 1: hash algorithm 677*ebfedea0SLionel Sambuc Octets 2-9: 8-octet salt value 678*ebfedea0SLionel Sambuc Octet 10: count, a one-octet, coded value 679*ebfedea0SLionel Sambuc 680*ebfedea0SLionel Sambuc The count is coded into a one-octet number using the following 681*ebfedea0SLionel Sambuc formula: 682*ebfedea0SLionel Sambuc 683*ebfedea0SLionel Sambuc #define EXPBIAS 6 684*ebfedea0SLionel Sambuc count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); 685*ebfedea0SLionel Sambuc 686*ebfedea0SLionel Sambuc The above formula is in C, where "Int32" is a type for a 32-bit 687*ebfedea0SLionel Sambuc integer, and the variable "c" is the coded count, Octet 10. 688*ebfedea0SLionel Sambuc 689*ebfedea0SLionel Sambuc Iterated-Salted S2K hashes the passphrase and salt data multiple 690*ebfedea0SLionel Sambuc times. The total number of octets to be hashed is specified in the 691*ebfedea0SLionel Sambuc encoded count in the S2K specifier. Note that the resulting count 692*ebfedea0SLionel Sambuc value is an octet count of how many octets will be hashed, not an 693*ebfedea0SLionel Sambuc iteration count. 694*ebfedea0SLionel Sambuc 695*ebfedea0SLionel Sambuc Initially, one or more hash contexts are set up as with the other 696*ebfedea0SLionel Sambuc S2K algorithms, depending on how many octets of key data are needed. 697*ebfedea0SLionel Sambuc Then the salt, followed by the passphrase data is repeatedly hashed 698*ebfedea0SLionel Sambuc until the number of octets specified by the octet count has been 699*ebfedea0SLionel Sambuc hashed. The one exception is that if the octet count is less than 700*ebfedea0SLionel Sambuc the size of the salt plus passphrase, the full salt plus passphrase 701*ebfedea0SLionel Sambuc will be hashed even though that is greater than the octet count. 702*ebfedea0SLionel Sambuc After the hashing is done the data is unloaded from the hash 703*ebfedea0SLionel Sambuc context(s) as with the other S2K algorithms. 704*ebfedea0SLionel Sambuc 705*ebfedea0SLionel Sambuc3.7.2. String-to-key usage 706*ebfedea0SLionel Sambuc 707*ebfedea0SLionel Sambuc Implementations SHOULD use salted or iterated-and-salted S2K 708*ebfedea0SLionel Sambuc specifiers, as simple S2K specifiers are more vulnerable to 709*ebfedea0SLionel Sambuc dictionary attacks. 710*ebfedea0SLionel Sambuc 711*ebfedea0SLionel Sambuc3.7.2.1. Secret key encryption 712*ebfedea0SLionel Sambuc 713*ebfedea0SLionel Sambuc An S2K specifier can be stored in the secret keyring to specify how 714*ebfedea0SLionel Sambuc to convert the passphrase to a key that unlocks the secret data. 715*ebfedea0SLionel Sambuc Older versions of PGP just stored a cipher algorithm octet preceding 716*ebfedea0SLionel Sambuc the secret data or a zero to indicate that the secret data was 717*ebfedea0SLionel Sambuc unencrypted. The MD5 hash function was always used to convert the 718*ebfedea0SLionel Sambuc passphrase to a key for the specified cipher algorithm. 719*ebfedea0SLionel Sambuc 720*ebfedea0SLionel Sambuc For compatibility, when an S2K specifier is used, the special value 721*ebfedea0SLionel Sambuc 254 or 255 is stored in the position where the hash algorithm octet 722*ebfedea0SLionel Sambuc would have been in the old data structure. This is then followed 723*ebfedea0SLionel Sambuc immediately by a one-octet algorithm identifier, and then by the S2K 724*ebfedea0SLionel Sambuc specifier as encoded above. 725*ebfedea0SLionel Sambuc 726*ebfedea0SLionel Sambuc 727*ebfedea0SLionel Sambuc 728*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 13] 729*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 730*ebfedea0SLionel Sambuc 731*ebfedea0SLionel Sambuc Therefore, preceding the secret data there will be one of these 732*ebfedea0SLionel Sambuc possibilities: 733*ebfedea0SLionel Sambuc 734*ebfedea0SLionel Sambuc 0: secret data is unencrypted (no passphrase) 735*ebfedea0SLionel Sambuc 255 or 254: followed by algorithm octet and S2K specifier 736*ebfedea0SLionel Sambuc Cipher alg: use Simple S2K algorithm using MD5 hash 737*ebfedea0SLionel Sambuc 738*ebfedea0SLionel Sambuc This last possibility, the cipher algorithm number with an implicit 739*ebfedea0SLionel Sambuc use of MD5 and IDEA, is provided for backward compatibility; it MAY 740*ebfedea0SLionel Sambuc be understood, but SHOULD NOT be generated, and is deprecated. 741*ebfedea0SLionel Sambuc 742*ebfedea0SLionel Sambuc These are followed by an Initial Vector of the same length as the 743*ebfedea0SLionel Sambuc block size of the cipher for the decryption of the secret values, if 744*ebfedea0SLionel Sambuc they are encrypted, and then the secret key values themselves. 745*ebfedea0SLionel Sambuc 746*ebfedea0SLionel Sambuc3.7.2.2. Symmetric-key message encryption 747*ebfedea0SLionel Sambuc 748*ebfedea0SLionel Sambuc OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) 749*ebfedea0SLionel Sambuc packet at the front of a message. This is used to allow S2K 750*ebfedea0SLionel Sambuc specifiers to be used for the passphrase conversion or to create 751*ebfedea0SLionel Sambuc messages with a mix of symmetric-key ESKs and public-key ESKs. This 752*ebfedea0SLionel Sambuc allows a message to be decrypted either with a passphrase or a 753*ebfedea0SLionel Sambuc public key pair. 754*ebfedea0SLionel Sambuc 755*ebfedea0SLionel Sambuc PGP 2.X always used IDEA with Simple string-to-key conversion when 756*ebfedea0SLionel Sambuc encrypting a message with a symmetric algorithm. This is deprecated, 757*ebfedea0SLionel Sambuc but MAY be used for backward-compatibility. 758*ebfedea0SLionel Sambuc 759*ebfedea0SLionel Sambuc4. Packet Syntax 760*ebfedea0SLionel Sambuc 761*ebfedea0SLionel Sambuc This section describes the packets used by OpenPGP. 762*ebfedea0SLionel Sambuc 763*ebfedea0SLionel Sambuc4.1. Overview 764*ebfedea0SLionel Sambuc 765*ebfedea0SLionel Sambuc An OpenPGP message is constructed from a number of records that are 766*ebfedea0SLionel Sambuc traditionally called packets. A packet is a chunk of data that has a 767*ebfedea0SLionel Sambuc tag specifying its meaning. An OpenPGP message, keyring, 768*ebfedea0SLionel Sambuc certificate, and so forth consists of a number of packets. Some of 769*ebfedea0SLionel Sambuc those packets may contain other OpenPGP packets (for example, a 770*ebfedea0SLionel Sambuc compressed data packet, when uncompressed, contains OpenPGP 771*ebfedea0SLionel Sambuc packets). 772*ebfedea0SLionel Sambuc 773*ebfedea0SLionel Sambuc Each packet consists of a packet header, followed by the packet 774*ebfedea0SLionel Sambuc body. The packet header is of variable length. 775*ebfedea0SLionel Sambuc 776*ebfedea0SLionel Sambuc4.2. Packet Headers 777*ebfedea0SLionel Sambuc 778*ebfedea0SLionel Sambuc The first octet of the packet header is called the "Packet Tag." It 779*ebfedea0SLionel Sambuc determines the format of the header and denotes the packet contents. 780*ebfedea0SLionel Sambuc The remainder of the packet header is the length of the packet. 781*ebfedea0SLionel Sambuc 782*ebfedea0SLionel Sambuc 783*ebfedea0SLionel Sambuc 784*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 14] 785*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 786*ebfedea0SLionel Sambuc 787*ebfedea0SLionel Sambuc Note that the most significant bit is the left-most bit, called bit 788*ebfedea0SLionel Sambuc 7. A mask for this bit is 0x80 in hexadecimal. 789*ebfedea0SLionel Sambuc 790*ebfedea0SLionel Sambuc +---------------+ 791*ebfedea0SLionel Sambuc PTag |7 6 5 4 3 2 1 0| 792*ebfedea0SLionel Sambuc +---------------+ 793*ebfedea0SLionel Sambuc Bit 7 -- Always one 794*ebfedea0SLionel Sambuc Bit 6 -- New packet format if set 795*ebfedea0SLionel Sambuc 796*ebfedea0SLionel Sambuc PGP 2.6.x only uses old format packets. Thus, software that 797*ebfedea0SLionel Sambuc interoperates with those versions of PGP must only use old format 798*ebfedea0SLionel Sambuc packets. If interoperability is not an issue, the new packet format 799*ebfedea0SLionel Sambuc is RECOMMENDED. Note that old format packets have four bits of 800*ebfedea0SLionel Sambuc packet tags, and new format packets have six; some features cannot 801*ebfedea0SLionel Sambuc be used and still be backward-compatible. 802*ebfedea0SLionel Sambuc 803*ebfedea0SLionel Sambuc Also note that packets with a tag greater than or equal to 16 MUST 804*ebfedea0SLionel Sambuc use new format packets. The old format packets can only express tags 805*ebfedea0SLionel Sambuc less than or equal to 15. 806*ebfedea0SLionel Sambuc 807*ebfedea0SLionel Sambuc Old format packets contain: 808*ebfedea0SLionel Sambuc 809*ebfedea0SLionel Sambuc Bits 5-2 -- packet tag 810*ebfedea0SLionel Sambuc Bits 1-0 - length-type 811*ebfedea0SLionel Sambuc 812*ebfedea0SLionel Sambuc New format packets contain: 813*ebfedea0SLionel Sambuc 814*ebfedea0SLionel Sambuc Bits 5-0 -- packet tag 815*ebfedea0SLionel Sambuc 816*ebfedea0SLionel Sambuc4.2.1. Old-Format Packet Lengths 817*ebfedea0SLionel Sambuc 818*ebfedea0SLionel Sambuc The meaning of the length-type in old-format packets is: 819*ebfedea0SLionel Sambuc 820*ebfedea0SLionel Sambuc 0 - The packet has a one-octet length. The header is 2 octets long. 821*ebfedea0SLionel Sambuc 822*ebfedea0SLionel Sambuc 1 - The packet has a two-octet length. The header is 3 octets long. 823*ebfedea0SLionel Sambuc 824*ebfedea0SLionel Sambuc 2 - The packet has a four-octet length. The header is 5 octets long. 825*ebfedea0SLionel Sambuc 826*ebfedea0SLionel Sambuc 3 - The packet is of indeterminate length. The header is 1 octet 827*ebfedea0SLionel Sambuc long, and the implementation must determine how long the packet 828*ebfedea0SLionel Sambuc is. If the packet is in a file, this means that the packet 829*ebfedea0SLionel Sambuc extends until the end of the file. In general, an implementation 830*ebfedea0SLionel Sambuc SHOULD NOT use indeterminate length packets except where the end 831*ebfedea0SLionel Sambuc of the data will be clear from the context, and even then it is 832*ebfedea0SLionel Sambuc better to use a definite length, or a new-format header. The 833*ebfedea0SLionel Sambuc new-format headers described below have a mechanism for 834*ebfedea0SLionel Sambuc precisely encoding data of indeterminate length. 835*ebfedea0SLionel Sambuc 836*ebfedea0SLionel Sambuc4.2.2. New-Format Packet Lengths 837*ebfedea0SLionel Sambuc 838*ebfedea0SLionel Sambuc New format packets have four possible ways of encoding length: 839*ebfedea0SLionel Sambuc 840*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 15] 841*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 842*ebfedea0SLionel Sambuc 843*ebfedea0SLionel Sambuc 1. A one-octet Body Length header encodes packet lengths of up to 844*ebfedea0SLionel Sambuc 191 octets. 845*ebfedea0SLionel Sambuc 846*ebfedea0SLionel Sambuc 2. A two-octet Body Length header encodes packet lengths of 192 to 847*ebfedea0SLionel Sambuc 8383 octets. 848*ebfedea0SLionel Sambuc 849*ebfedea0SLionel Sambuc 3. A five-octet Body Length header encodes packet lengths of up to 850*ebfedea0SLionel Sambuc 4,294,967,295 (0xFFFFFFFF) octets in length. (This actually 851*ebfedea0SLionel Sambuc encodes a four-octet scalar number.) 852*ebfedea0SLionel Sambuc 853*ebfedea0SLionel Sambuc 4. When the length of the packet body is not known in advance by 854*ebfedea0SLionel Sambuc the issuer, Partial Body Length headers encode a packet of 855*ebfedea0SLionel Sambuc indeterminate length, effectively making it a stream. 856*ebfedea0SLionel Sambuc 857*ebfedea0SLionel Sambuc4.2.2.1. One-Octet Lengths 858*ebfedea0SLionel Sambuc 859*ebfedea0SLionel Sambuc A one-octet Body Length header encodes a length of from 0 to 191 860*ebfedea0SLionel Sambuc octets. This type of length header is recognized because the one 861*ebfedea0SLionel Sambuc octet value is less than 192. The body length is equal to: 862*ebfedea0SLionel Sambuc 863*ebfedea0SLionel Sambuc bodyLen = 1st_octet; 864*ebfedea0SLionel Sambuc 865*ebfedea0SLionel Sambuc4.2.2.2. Two-Octet Lengths 866*ebfedea0SLionel Sambuc 867*ebfedea0SLionel Sambuc A two-octet Body Length header encodes a length of from 192 to 8383 868*ebfedea0SLionel Sambuc octets. It is recognized because its first octet is in the range 192 869*ebfedea0SLionel Sambuc to 223. The body length is equal to: 870*ebfedea0SLionel Sambuc 871*ebfedea0SLionel Sambuc bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 872*ebfedea0SLionel Sambuc 873*ebfedea0SLionel Sambuc4.2.2.3. Five-Octet Lengths 874*ebfedea0SLionel Sambuc 875*ebfedea0SLionel Sambuc A five-octet Body Length header consists of a single octet holding 876*ebfedea0SLionel Sambuc the value 255, followed by a four-octet scalar. The body length is 877*ebfedea0SLionel Sambuc equal to: 878*ebfedea0SLionel Sambuc 879*ebfedea0SLionel Sambuc bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | 880*ebfedea0SLionel Sambuc (4th_octet << 8) | 5th_octet 881*ebfedea0SLionel Sambuc 882*ebfedea0SLionel Sambuc This basic set of one, two, and five-octet lengths is also used 883*ebfedea0SLionel Sambuc internally to some packets. 884*ebfedea0SLionel Sambuc 885*ebfedea0SLionel Sambuc4.2.2.4. Partial Body Lengths 886*ebfedea0SLionel Sambuc 887*ebfedea0SLionel Sambuc A Partial Body Length header is one octet long and encodes the 888*ebfedea0SLionel Sambuc length of only part of the data packet. This length is a power of 2, 889*ebfedea0SLionel Sambuc from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by 890*ebfedea0SLionel Sambuc its one octet value that is greater than or equal to 224, and less 891*ebfedea0SLionel Sambuc than 255. The partial body length is equal to: 892*ebfedea0SLionel Sambuc 893*ebfedea0SLionel Sambuc 894*ebfedea0SLionel Sambuc 895*ebfedea0SLionel Sambuc 896*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 16] 897*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 898*ebfedea0SLionel Sambuc 899*ebfedea0SLionel Sambuc partialBodyLen = 1 << (1st_octet & 0x1f); 900*ebfedea0SLionel Sambuc 901*ebfedea0SLionel Sambuc Each Partial Body Length header is followed by a portion of the 902*ebfedea0SLionel Sambuc packet body data. The Partial Body Length header specifies this 903*ebfedea0SLionel Sambuc portion's length. Another length header (one octet, two-octet, 904*ebfedea0SLionel Sambuc five-octet, or partial) follows that portion. The last length header 905*ebfedea0SLionel Sambuc in the packet MUST NOT be a partial Body Length header. Partial Body 906*ebfedea0SLionel Sambuc Length headers may only be used for the non-final parts of the 907*ebfedea0SLionel Sambuc packet. 908*ebfedea0SLionel Sambuc 909*ebfedea0SLionel Sambuc Note also that the last Body Length header can be a zero-length 910*ebfedea0SLionel Sambuc header. 911*ebfedea0SLionel Sambuc 912*ebfedea0SLionel Sambuc An implementation MAY use Partial Body Lengths for data packets, be 913*ebfedea0SLionel Sambuc they literal, compressed, or encrypted. The first partial length 914*ebfedea0SLionel Sambuc MUST be at least 512 octets long. Partial Body Lengths MUST NOT be 915*ebfedea0SLionel Sambuc used for any other packet types. 916*ebfedea0SLionel Sambuc 917*ebfedea0SLionel Sambuc4.2.3. Packet Length Examples 918*ebfedea0SLionel Sambuc 919*ebfedea0SLionel Sambuc These examples show ways that new-format packets might encode the 920*ebfedea0SLionel Sambuc packet lengths. 921*ebfedea0SLionel Sambuc 922*ebfedea0SLionel Sambuc A packet with length 100 may have its length encoded in one octet: 923*ebfedea0SLionel Sambuc 0x64. This is followed by 100 octets of data. 924*ebfedea0SLionel Sambuc 925*ebfedea0SLionel Sambuc A packet with length 1723 may have its length coded in two octets: 926*ebfedea0SLionel Sambuc 0xC5, 0xFB. This header is followed by the 1723 octets of data. 927*ebfedea0SLionel Sambuc 928*ebfedea0SLionel Sambuc A packet with length 100000 may have its length encoded in five 929*ebfedea0SLionel Sambuc octets: 0xFF, 0x00, 0x01, 0x86, 0xA0. 930*ebfedea0SLionel Sambuc 931*ebfedea0SLionel Sambuc It might also be encoded in the following octet stream: 0xEF, first 932*ebfedea0SLionel Sambuc 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one 933*ebfedea0SLionel Sambuc octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 934*ebfedea0SLionel Sambuc 1693 octets of data. This is just one possible encoding, and many 935*ebfedea0SLionel Sambuc variations are possible on the size of the Partial Body Length 936*ebfedea0SLionel Sambuc headers, as long as a regular Body Length header encodes the last 937*ebfedea0SLionel Sambuc portion of the data. 938*ebfedea0SLionel Sambuc 939*ebfedea0SLionel Sambuc Please note that in all of these explanations, the total length of 940*ebfedea0SLionel Sambuc the packet is the length of the header(s) plus the length of the 941*ebfedea0SLionel Sambuc body. 942*ebfedea0SLionel Sambuc 943*ebfedea0SLionel Sambuc4.3. Packet Tags 944*ebfedea0SLionel Sambuc 945*ebfedea0SLionel Sambuc The packet tag denotes what type of packet the body holds. Note that 946*ebfedea0SLionel Sambuc old format headers can only have tags less than 16, whereas new 947*ebfedea0SLionel Sambuc format headers can have tags as great as 63. The defined tags (in 948*ebfedea0SLionel Sambuc decimal) are: 949*ebfedea0SLionel Sambuc 950*ebfedea0SLionel Sambuc 951*ebfedea0SLionel Sambuc 952*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 17] 953*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 954*ebfedea0SLionel Sambuc 955*ebfedea0SLionel Sambuc 0 -- Reserved - a packet tag MUST NOT have this value 956*ebfedea0SLionel Sambuc 1 -- Public-Key Encrypted Session Key Packet 957*ebfedea0SLionel Sambuc 2 -- Signature Packet 958*ebfedea0SLionel Sambuc 3 -- Symmetric-Key Encrypted Session Key Packet 959*ebfedea0SLionel Sambuc 4 -- One-Pass Signature Packet 960*ebfedea0SLionel Sambuc 5 -- Secret Key Packet 961*ebfedea0SLionel Sambuc 6 -- Public Key Packet 962*ebfedea0SLionel Sambuc 7 -- Secret Subkey Packet 963*ebfedea0SLionel Sambuc 8 -- Compressed Data Packet 964*ebfedea0SLionel Sambuc 9 -- Symmetrically Encrypted Data Packet 965*ebfedea0SLionel Sambuc 10 -- Marker Packet 966*ebfedea0SLionel Sambuc 11 -- Literal Data Packet 967*ebfedea0SLionel Sambuc 12 -- Trust Packet 968*ebfedea0SLionel Sambuc 13 -- User ID Packet 969*ebfedea0SLionel Sambuc 14 -- Public Subkey Packet 970*ebfedea0SLionel Sambuc 17 -- User Attribute Packet 971*ebfedea0SLionel Sambuc 18 -- Sym. Encrypted and Integrity Protected Data Packet 972*ebfedea0SLionel Sambuc 19 -- Modification Detection Code Packet 973*ebfedea0SLionel Sambuc 60 to 63 -- Private or Experimental Values 974*ebfedea0SLionel Sambuc 975*ebfedea0SLionel Sambuc5. Packet Types 976*ebfedea0SLionel Sambuc 977*ebfedea0SLionel Sambuc5.1. Public-Key Encrypted Session Key Packets (Tag 1) 978*ebfedea0SLionel Sambuc 979*ebfedea0SLionel Sambuc A Public-Key Encrypted Session Key packet holds the session key used 980*ebfedea0SLionel Sambuc to encrypt a message. Zero or more Public-Key Encrypted Session Key 981*ebfedea0SLionel Sambuc packets and/or Symmetric-Key Encrypted Session Key packets may 982*ebfedea0SLionel Sambuc precede a Symmetrically Encrypted Data Packet, which holds an 983*ebfedea0SLionel Sambuc encrypted message. The message is encrypted with the session key, 984*ebfedea0SLionel Sambuc and the session key is itself encrypted and stored in the Encrypted 985*ebfedea0SLionel Sambuc Session Key packet(s). The Symmetrically Encrypted Data Packet is 986*ebfedea0SLionel Sambuc preceded by one Public-Key Encrypted Session Key packet for each 987*ebfedea0SLionel Sambuc OpenPGP key to which the message is encrypted. The recipient of the 988*ebfedea0SLionel Sambuc message finds a session key that is encrypted to their public key, 989*ebfedea0SLionel Sambuc decrypts the session key, and then uses the session key to decrypt 990*ebfedea0SLionel Sambuc the message. 991*ebfedea0SLionel Sambuc 992*ebfedea0SLionel Sambuc The body of this packet consists of: 993*ebfedea0SLionel Sambuc 994*ebfedea0SLionel Sambuc - A one-octet number giving the version number of the packet type. 995*ebfedea0SLionel Sambuc The currently defined value for packet version is 3. 996*ebfedea0SLionel Sambuc 997*ebfedea0SLionel Sambuc - An eight-octet number that gives the key ID of the public key 998*ebfedea0SLionel Sambuc that the session key is encrypted to. If the session key is 999*ebfedea0SLionel Sambuc encrypted to a subkey then the key ID of this subkey is used 1000*ebfedea0SLionel Sambuc here instead of the key ID of the primary key. 1001*ebfedea0SLionel Sambuc 1002*ebfedea0SLionel Sambuc - A one-octet number giving the public key algorithm used. 1003*ebfedea0SLionel Sambuc 1004*ebfedea0SLionel Sambuc - A string of octets that is the encrypted session key. This 1005*ebfedea0SLionel Sambuc string takes up the remainder of the packet, and its contents 1006*ebfedea0SLionel Sambuc are dependent on the public key algorithm used. 1007*ebfedea0SLionel Sambuc 1008*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 18] 1009*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1010*ebfedea0SLionel Sambuc 1011*ebfedea0SLionel Sambuc Algorithm Specific Fields for RSA encryption 1012*ebfedea0SLionel Sambuc 1013*ebfedea0SLionel Sambuc - multiprecision integer (MPI) of RSA encrypted value m**e mod n. 1014*ebfedea0SLionel Sambuc 1015*ebfedea0SLionel Sambuc Algorithm Specific Fields for Elgamal encryption: 1016*ebfedea0SLionel Sambuc 1017*ebfedea0SLionel Sambuc - MPI of Elgamal (Diffie-Hellman) value g**k mod p. 1018*ebfedea0SLionel Sambuc 1019*ebfedea0SLionel Sambuc - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. 1020*ebfedea0SLionel Sambuc 1021*ebfedea0SLionel Sambuc The value "m" in the above formulas is derived from the session key 1022*ebfedea0SLionel Sambuc as follows. First the session key is prefixed with a one-octet 1023*ebfedea0SLionel Sambuc algorithm identifier that specifies the symmetric encryption 1024*ebfedea0SLionel Sambuc algorithm used to encrypt the following Symmetrically Encrypted Data 1025*ebfedea0SLionel Sambuc Packet. Then a two-octet checksum is appended which is equal to the 1026*ebfedea0SLionel Sambuc sum of the preceding session key octets, not including the algorithm 1027*ebfedea0SLionel Sambuc identifier, modulo 65536. This value is then encoded as described in 1028*ebfedea0SLionel Sambuc PKCS#1 block encoding EME-PKCS1-v1_5 in Section 12.1 of RFC 3447 to 1029*ebfedea0SLionel Sambuc form the "m" value used in the formulas above. See Section 13.1 of 1030*ebfedea0SLionel Sambuc this document for notes on OpenPGP's use of PKCS#1. 1031*ebfedea0SLionel Sambuc 1032*ebfedea0SLionel Sambuc Note that when an implementation forms several PKESKs with one 1033*ebfedea0SLionel Sambuc session key, forming a message that can be decrypted by several 1034*ebfedea0SLionel Sambuc keys, the implementation MUST make a new PKCS#1 encoding for each 1035*ebfedea0SLionel Sambuc key. 1036*ebfedea0SLionel Sambuc 1037*ebfedea0SLionel Sambuc An implementation MAY accept or use a Key ID of zero as a "wild 1038*ebfedea0SLionel Sambuc card" or "speculative" Key ID. In this case, the receiving 1039*ebfedea0SLionel Sambuc implementation would try all available private keys, checking for a 1040*ebfedea0SLionel Sambuc valid decrypted session key. This format helps reduce traffic 1041*ebfedea0SLionel Sambuc analysis of messages. 1042*ebfedea0SLionel Sambuc 1043*ebfedea0SLionel Sambuc5.2. Signature Packet (Tag 2) 1044*ebfedea0SLionel Sambuc 1045*ebfedea0SLionel Sambuc A signature packet describes a binding between some public key and 1046*ebfedea0SLionel Sambuc some data. The most common signatures are a signature of a file or a 1047*ebfedea0SLionel Sambuc block of text, and a signature that is a certification of a User ID. 1048*ebfedea0SLionel Sambuc 1049*ebfedea0SLionel Sambuc Two versions of signature packets are defined. Version 3 provides 1050*ebfedea0SLionel Sambuc basic signature information, while version 4 provides an expandable 1051*ebfedea0SLionel Sambuc format with subpackets that can specify more information about the 1052*ebfedea0SLionel Sambuc signature. PGP 2.6.x only accepts version 3 signatures. 1053*ebfedea0SLionel Sambuc 1054*ebfedea0SLionel Sambuc Implementations SHOULD accept V3 signatures. Implementations SHOULD 1055*ebfedea0SLionel Sambuc generate V4 signatures. 1056*ebfedea0SLionel Sambuc 1057*ebfedea0SLionel Sambuc Note that if an implementation is creating an encrypted and signed 1058*ebfedea0SLionel Sambuc message that is encrypted to a V3 key, it is reasonable to create a 1059*ebfedea0SLionel Sambuc V3 signature. 1060*ebfedea0SLionel Sambuc 1061*ebfedea0SLionel Sambuc 1062*ebfedea0SLionel Sambuc 1063*ebfedea0SLionel Sambuc 1064*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 19] 1065*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1066*ebfedea0SLionel Sambuc 1067*ebfedea0SLionel Sambuc5.2.1. Signature Types 1068*ebfedea0SLionel Sambuc 1069*ebfedea0SLionel Sambuc There are a number of possible meanings for a signature, which are 1070*ebfedea0SLionel Sambuc indicated in a signature type octet in any given signature. Please 1071*ebfedea0SLionel Sambuc note that the vagueness of these meanings is not a flaw, but a 1072*ebfedea0SLionel Sambuc feature of the system. Because OpenPGP places final authority for 1073*ebfedea0SLionel Sambuc validity upon the receiver of a signature, it may be that one 1074*ebfedea0SLionel Sambuc signer's casual act might be more rigorous than some other 1075*ebfedea0SLionel Sambuc authority's positive act. See section 5.2.4, "Computing Signatures," 1076*ebfedea0SLionel Sambuc for detailed information on how to compute and verify signatures of 1077*ebfedea0SLionel Sambuc each type. 1078*ebfedea0SLionel Sambuc 1079*ebfedea0SLionel Sambuc These meanings are: 1080*ebfedea0SLionel Sambuc 1081*ebfedea0SLionel Sambuc 0x00: Signature of a binary document. 1082*ebfedea0SLionel Sambuc This means the signer owns it, created it, or certifies that it 1083*ebfedea0SLionel Sambuc has not been modified. 1084*ebfedea0SLionel Sambuc 1085*ebfedea0SLionel Sambuc 0x01: Signature of a canonical text document. 1086*ebfedea0SLionel Sambuc This means the signer owns it, created it, or certifies that it 1087*ebfedea0SLionel Sambuc has not been modified. The signature is calculated over the text 1088*ebfedea0SLionel Sambuc data with its line endings converted to <CR><LF>. 1089*ebfedea0SLionel Sambuc 1090*ebfedea0SLionel Sambuc 0x02: Standalone signature. 1091*ebfedea0SLionel Sambuc This signature is a signature of only its own subpacket 1092*ebfedea0SLionel Sambuc contents. It is calculated identically to a signature over a 1093*ebfedea0SLionel Sambuc zero-length binary document. Note that it doesn't make sense to 1094*ebfedea0SLionel Sambuc have a V3 standalone signature. 1095*ebfedea0SLionel Sambuc 1096*ebfedea0SLionel Sambuc 0x10: Generic certification of a User ID and Public Key packet. 1097*ebfedea0SLionel Sambuc The issuer of this certification does not make any particular 1098*ebfedea0SLionel Sambuc assertion as to how well the certifier has checked that the 1099*ebfedea0SLionel Sambuc owner of the key is in fact the person described by the User ID. 1100*ebfedea0SLionel Sambuc 1101*ebfedea0SLionel Sambuc 0x11: Persona certification of a User ID and Public Key packet. 1102*ebfedea0SLionel Sambuc The issuer of this certification has not done any verification 1103*ebfedea0SLionel Sambuc of the claim that the owner of this key is the User ID 1104*ebfedea0SLionel Sambuc specified. 1105*ebfedea0SLionel Sambuc 1106*ebfedea0SLionel Sambuc 0x12: Casual certification of a User ID and Public Key packet. 1107*ebfedea0SLionel Sambuc The issuer of this certification has done some casual 1108*ebfedea0SLionel Sambuc verification of the claim of identity. 1109*ebfedea0SLionel Sambuc 1110*ebfedea0SLionel Sambuc 0x13: Positive certification of a User ID and Public Key packet. 1111*ebfedea0SLionel Sambuc The issuer of this certification has done substantial 1112*ebfedea0SLionel Sambuc verification of the claim of identity. 1113*ebfedea0SLionel Sambuc 1114*ebfedea0SLionel Sambuc Most OpenPGP implementations make their "key signatures" as 0x10 1115*ebfedea0SLionel Sambuc certifications. Some implementations can issue 0x11-0x13 1116*ebfedea0SLionel Sambuc certifications, but few differentiate between the types. 1117*ebfedea0SLionel Sambuc 1118*ebfedea0SLionel Sambuc 1119*ebfedea0SLionel Sambuc 1120*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 20] 1121*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1122*ebfedea0SLionel Sambuc 1123*ebfedea0SLionel Sambuc 0x18: Subkey Binding Signature 1124*ebfedea0SLionel Sambuc This signature is a statement by the top-level signing key that 1125*ebfedea0SLionel Sambuc indicates that it owns the subkey. This signature is calculated 1126*ebfedea0SLionel Sambuc directly on the primary key and subkey, and not on any User ID 1127*ebfedea0SLionel Sambuc or other packets. A signature that binds a signing subkey MUST 1128*ebfedea0SLionel Sambuc have an embedded signature subpacket in this binding signature 1129*ebfedea0SLionel Sambuc which contains a 0x19 signature made by the signing subkey on 1130*ebfedea0SLionel Sambuc the primary key and subkey. 1131*ebfedea0SLionel Sambuc 1132*ebfedea0SLionel Sambuc 0x19 Primary Key Binding Signature 1133*ebfedea0SLionel Sambuc This signature is a statement by a signing subkey, indicating 1134*ebfedea0SLionel Sambuc that it is owned by the primary key and subkey. This signature 1135*ebfedea0SLionel Sambuc is calculated the same way as a 0x18 signature: directly on the 1136*ebfedea0SLionel Sambuc primary key and subkey, and not on any User ID or other packets. 1137*ebfedea0SLionel Sambuc 1138*ebfedea0SLionel Sambuc 0x1F: Signature directly on a key 1139*ebfedea0SLionel Sambuc This signature is calculated directly on a key. It binds the 1140*ebfedea0SLionel Sambuc information in the signature subpackets to the key, and is 1141*ebfedea0SLionel Sambuc appropriate to be used for subpackets that provide information 1142*ebfedea0SLionel Sambuc about the key, such as the revocation key subpacket. It is also 1143*ebfedea0SLionel Sambuc appropriate for statements that non-self certifiers want to make 1144*ebfedea0SLionel Sambuc about the key itself, rather than the binding between a key and 1145*ebfedea0SLionel Sambuc a name. 1146*ebfedea0SLionel Sambuc 1147*ebfedea0SLionel Sambuc 0x20: Key revocation signature 1148*ebfedea0SLionel Sambuc The signature is calculated directly on the key being revoked. A 1149*ebfedea0SLionel Sambuc revoked key is not to be used. Only revocation signatures by the 1150*ebfedea0SLionel Sambuc key being revoked, or by an authorized revocation key, should be 1151*ebfedea0SLionel Sambuc considered valid revocation signatures. 1152*ebfedea0SLionel Sambuc 1153*ebfedea0SLionel Sambuc 0x28: Subkey revocation signature 1154*ebfedea0SLionel Sambuc The signature is calculated directly on the subkey being 1155*ebfedea0SLionel Sambuc revoked. A revoked subkey is not to be used. Only revocation 1156*ebfedea0SLionel Sambuc signatures by the top-level signature key that is bound to this 1157*ebfedea0SLionel Sambuc subkey, or by an authorized revocation key, should be considered 1158*ebfedea0SLionel Sambuc valid revocation signatures. 1159*ebfedea0SLionel Sambuc 1160*ebfedea0SLionel Sambuc 0x30: Certification revocation signature 1161*ebfedea0SLionel Sambuc This signature revokes an earlier User ID certification 1162*ebfedea0SLionel Sambuc signature (signature class 0x10 through 0x13) or direct-key 1163*ebfedea0SLionel Sambuc signature (0x1F). It should be issued by the same key that 1164*ebfedea0SLionel Sambuc issued the revoked signature or an authorized revocation key. 1165*ebfedea0SLionel Sambuc The signature is computed over the same data as the certificate 1166*ebfedea0SLionel Sambuc that it revokes, and should have a later creation date than that 1167*ebfedea0SLionel Sambuc certificate. 1168*ebfedea0SLionel Sambuc 1169*ebfedea0SLionel Sambuc 0x40: Timestamp signature. 1170*ebfedea0SLionel Sambuc This signature is only meaningful for the timestamp contained in 1171*ebfedea0SLionel Sambuc it. 1172*ebfedea0SLionel Sambuc 1173*ebfedea0SLionel Sambuc 1174*ebfedea0SLionel Sambuc 1175*ebfedea0SLionel Sambuc 1176*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 21] 1177*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1178*ebfedea0SLionel Sambuc 1179*ebfedea0SLionel Sambuc 0x50: Third-Party Confirmation signature. 1180*ebfedea0SLionel Sambuc This signature is a signature over some other OpenPGP signature 1181*ebfedea0SLionel Sambuc packet(s). It is analogous to a notary seal on the signed data. 1182*ebfedea0SLionel Sambuc A third-party signature SHOULD include Signature Target 1183*ebfedea0SLionel Sambuc subpacket(s) to give easy identification. Note that we really do 1184*ebfedea0SLionel Sambuc mean SHOULD. There are plausible uses for this (such as a blind 1185*ebfedea0SLionel Sambuc party that only sees the signature, not the key nor source 1186*ebfedea0SLionel Sambuc document) that cannot include a target subpacket. 1187*ebfedea0SLionel Sambuc 1188*ebfedea0SLionel Sambuc5.2.2. Version 3 Signature Packet Format 1189*ebfedea0SLionel Sambuc 1190*ebfedea0SLionel Sambuc The body of a version 3 Signature Packet contains: 1191*ebfedea0SLionel Sambuc 1192*ebfedea0SLionel Sambuc - One-octet version number (3). 1193*ebfedea0SLionel Sambuc 1194*ebfedea0SLionel Sambuc - One-octet length of following hashed material. MUST be 5. 1195*ebfedea0SLionel Sambuc 1196*ebfedea0SLionel Sambuc - One-octet signature type. 1197*ebfedea0SLionel Sambuc 1198*ebfedea0SLionel Sambuc - Four-octet creation time. 1199*ebfedea0SLionel Sambuc 1200*ebfedea0SLionel Sambuc - Eight-octet key ID of signer. 1201*ebfedea0SLionel Sambuc 1202*ebfedea0SLionel Sambuc - One-octet public key algorithm. 1203*ebfedea0SLionel Sambuc 1204*ebfedea0SLionel Sambuc - One-octet hash algorithm. 1205*ebfedea0SLionel Sambuc 1206*ebfedea0SLionel Sambuc - Two-octet field holding left 16 bits of signed hash value. 1207*ebfedea0SLionel Sambuc 1208*ebfedea0SLionel Sambuc - One or more multiprecision integers comprising the signature. 1209*ebfedea0SLionel Sambuc This portion is algorithm specific, as described below. 1210*ebfedea0SLionel Sambuc 1211*ebfedea0SLionel Sambuc The concatenation of the data to be signed, the signature type and 1212*ebfedea0SLionel Sambuc creation time from the signature packet (5 additional octets) is 1213*ebfedea0SLionel Sambuc hashed. The resulting hash value is used in the signature algorithm. 1214*ebfedea0SLionel Sambuc The high 16 bits (first two octets) of the hash are included in the 1215*ebfedea0SLionel Sambuc signature packet to provide a quick test to reject some invalid 1216*ebfedea0SLionel Sambuc signatures. 1217*ebfedea0SLionel Sambuc 1218*ebfedea0SLionel Sambuc Algorithm Specific Fields for RSA signatures: 1219*ebfedea0SLionel Sambuc 1220*ebfedea0SLionel Sambuc - multiprecision integer (MPI) of RSA signature value m**d mod n. 1221*ebfedea0SLionel Sambuc 1222*ebfedea0SLionel Sambuc Algorithm Specific Fields for DSA signatures: 1223*ebfedea0SLionel Sambuc 1224*ebfedea0SLionel Sambuc - MPI of DSA value r. 1225*ebfedea0SLionel Sambuc 1226*ebfedea0SLionel Sambuc - MPI of DSA value s. 1227*ebfedea0SLionel Sambuc 1228*ebfedea0SLionel Sambuc The signature calculation is based on a hash of the signed data, as 1229*ebfedea0SLionel Sambuc described above. The details of the calculation are different for 1230*ebfedea0SLionel Sambuc DSA signatures than for RSA signatures. 1231*ebfedea0SLionel Sambuc 1232*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 22] 1233*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1234*ebfedea0SLionel Sambuc 1235*ebfedea0SLionel Sambuc With RSA signatures, the hash value is encoded as described in 1236*ebfedea0SLionel Sambuc PKCS#1 section 9.2.1 of RFC 3447 encoded using PKCS#1 encoding type 1237*ebfedea0SLionel Sambuc EMSA-PKCS1-v1_5 as described in section 12.1 of RFC 3447. This 1238*ebfedea0SLionel Sambuc requires inserting the hash value as an octet string into an ASN.1 1239*ebfedea0SLionel Sambuc structure. The object identifier for the type of hash being used is 1240*ebfedea0SLionel Sambuc included in the structure. The hexadecimal representations for the 1241*ebfedea0SLionel Sambuc currently defined hash algorithms are: 1242*ebfedea0SLionel Sambuc 1243*ebfedea0SLionel Sambuc - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 1244*ebfedea0SLionel Sambuc 1245*ebfedea0SLionel Sambuc - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 1246*ebfedea0SLionel Sambuc 1247*ebfedea0SLionel Sambuc - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A 1248*ebfedea0SLionel Sambuc 1249*ebfedea0SLionel Sambuc - SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04 1250*ebfedea0SLionel Sambuc 1251*ebfedea0SLionel Sambuc - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 1252*ebfedea0SLionel Sambuc 1253*ebfedea0SLionel Sambuc - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 1254*ebfedea0SLionel Sambuc 1255*ebfedea0SLionel Sambuc - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 1256*ebfedea0SLionel Sambuc 1257*ebfedea0SLionel Sambuc The ASN.1 OIDs are: 1258*ebfedea0SLionel Sambuc 1259*ebfedea0SLionel Sambuc - MD5: 1.2.840.113549.2.5 1260*ebfedea0SLionel Sambuc 1261*ebfedea0SLionel Sambuc - RIPEMD-160: 1.3.36.3.2.1 1262*ebfedea0SLionel Sambuc 1263*ebfedea0SLionel Sambuc - SHA-1: 1.3.14.3.2.26 1264*ebfedea0SLionel Sambuc 1265*ebfedea0SLionel Sambuc - SHA224: 2.16.840.1.101.3.4.2.4 1266*ebfedea0SLionel Sambuc 1267*ebfedea0SLionel Sambuc - SHA256: 2.16.840.1.101.3.4.2.1 1268*ebfedea0SLionel Sambuc 1269*ebfedea0SLionel Sambuc - SHA384: 2.16.840.1.101.3.4.2.2 1270*ebfedea0SLionel Sambuc 1271*ebfedea0SLionel Sambuc - SHA512: 2.16.840.1.101.3.4.2.3 1272*ebfedea0SLionel Sambuc 1273*ebfedea0SLionel Sambuc The full hash prefixes for these are: 1274*ebfedea0SLionel Sambuc 1275*ebfedea0SLionel Sambuc MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 1276*ebfedea0SLionel Sambuc 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 1277*ebfedea0SLionel Sambuc 0x04, 0x10 1278*ebfedea0SLionel Sambuc 1279*ebfedea0SLionel Sambuc RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, 1280*ebfedea0SLionel Sambuc 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 1281*ebfedea0SLionel Sambuc 1282*ebfedea0SLionel Sambuc SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, 1283*ebfedea0SLionel Sambuc 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 1284*ebfedea0SLionel Sambuc 1285*ebfedea0SLionel Sambuc 1286*ebfedea0SLionel Sambuc 1287*ebfedea0SLionel Sambuc 1288*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 23] 1289*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1290*ebfedea0SLionel Sambuc 1291*ebfedea0SLionel Sambuc SHA224: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 1292*ebfedea0SLionel Sambuc 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 1293*ebfedea0SLionel Sambuc 0x00, 0x04, 0x1C 1294*ebfedea0SLionel Sambuc 1295*ebfedea0SLionel Sambuc SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 1296*ebfedea0SLionel Sambuc 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 1297*ebfedea0SLionel Sambuc 0x00, 0x04, 0x20 1298*ebfedea0SLionel Sambuc 1299*ebfedea0SLionel Sambuc SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 1300*ebfedea0SLionel Sambuc 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 1301*ebfedea0SLionel Sambuc 0x00, 0x04, 0x30 1302*ebfedea0SLionel Sambuc 1303*ebfedea0SLionel Sambuc SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 1304*ebfedea0SLionel Sambuc 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 1305*ebfedea0SLionel Sambuc 0x00, 0x04, 0x40 1306*ebfedea0SLionel Sambuc 1307*ebfedea0SLionel Sambuc DSA signatures MUST use hashes that are equal in size to the number 1308*ebfedea0SLionel Sambuc of bits of q, the group generated by the DSA key's generator value. 1309*ebfedea0SLionel Sambuc If the output size of the chosen hash is larger than the number of 1310*ebfedea0SLionel Sambuc bits of q, the hash result is truncated to fit by taking the number 1311*ebfedea0SLionel Sambuc of leftmost bits equal to the number of bits of q. This (possibly 1312*ebfedea0SLionel Sambuc truncated) hash function result is treated as a number and used 1313*ebfedea0SLionel Sambuc directly in the DSA signature algorithm. 1314*ebfedea0SLionel Sambuc 1315*ebfedea0SLionel Sambuc5.2.3. Version 4 Signature Packet Format 1316*ebfedea0SLionel Sambuc 1317*ebfedea0SLionel Sambuc The body of a version 4 Signature Packet contains: 1318*ebfedea0SLionel Sambuc 1319*ebfedea0SLionel Sambuc - One-octet version number (4). 1320*ebfedea0SLionel Sambuc 1321*ebfedea0SLionel Sambuc - One-octet signature type. 1322*ebfedea0SLionel Sambuc 1323*ebfedea0SLionel Sambuc - One-octet public key algorithm. 1324*ebfedea0SLionel Sambuc 1325*ebfedea0SLionel Sambuc - One-octet hash algorithm. 1326*ebfedea0SLionel Sambuc 1327*ebfedea0SLionel Sambuc - Two-octet scalar octet count for following hashed subpacket 1328*ebfedea0SLionel Sambuc data. Note that this is the length in octets of all of the 1329*ebfedea0SLionel Sambuc hashed subpackets; a pointer incremented by this number will 1330*ebfedea0SLionel Sambuc skip over the hashed subpackets. 1331*ebfedea0SLionel Sambuc 1332*ebfedea0SLionel Sambuc - Hashed subpacket data set. (zero or more subpackets) 1333*ebfedea0SLionel Sambuc 1334*ebfedea0SLionel Sambuc - Two-octet scalar octet count for the following unhashed 1335*ebfedea0SLionel Sambuc subpacket data. Note that this is the length in octets of all of 1336*ebfedea0SLionel Sambuc the unhashed subpackets; a pointer incremented by this number 1337*ebfedea0SLionel Sambuc will skip over the unhashed subpackets. 1338*ebfedea0SLionel Sambuc 1339*ebfedea0SLionel Sambuc - Unhashed subpacket data set. (zero or more subpackets) 1340*ebfedea0SLionel Sambuc 1341*ebfedea0SLionel Sambuc 1342*ebfedea0SLionel Sambuc 1343*ebfedea0SLionel Sambuc 1344*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 24] 1345*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1346*ebfedea0SLionel Sambuc 1347*ebfedea0SLionel Sambuc - Two-octet field holding the left 16 bits of the signed hash 1348*ebfedea0SLionel Sambuc value. 1349*ebfedea0SLionel Sambuc 1350*ebfedea0SLionel Sambuc - One or more multiprecision integers comprising the signature. 1351*ebfedea0SLionel Sambuc This portion is algorithm specific, as described above. 1352*ebfedea0SLionel Sambuc 1353*ebfedea0SLionel Sambuc The concatenation of the data being signed and the signature data 1354*ebfedea0SLionel Sambuc from the version number through the hashed subpacket data 1355*ebfedea0SLionel Sambuc (inclusive) is hashed. The resulting hash value is what is signed. 1356*ebfedea0SLionel Sambuc The left 16 bits of the hash are included in the signature packet to 1357*ebfedea0SLionel Sambuc provide a quick test to reject some invalid signatures. 1358*ebfedea0SLionel Sambuc 1359*ebfedea0SLionel Sambuc There are two fields consisting of signature subpackets. The first 1360*ebfedea0SLionel Sambuc field is hashed with the rest of the signature data, while the 1361*ebfedea0SLionel Sambuc second is unhashed. The second set of subpackets is not 1362*ebfedea0SLionel Sambuc cryptographically protected by the signature and should include only 1363*ebfedea0SLionel Sambuc advisory information. 1364*ebfedea0SLionel Sambuc 1365*ebfedea0SLionel Sambuc The algorithms for converting the hash function result to a 1366*ebfedea0SLionel Sambuc signature are described in a section below. 1367*ebfedea0SLionel Sambuc 1368*ebfedea0SLionel Sambuc5.2.3.1. Signature Subpacket Specification 1369*ebfedea0SLionel Sambuc 1370*ebfedea0SLionel Sambuc A subpacket data set consists of zero or more signature subpackets. 1371*ebfedea0SLionel Sambuc In signature packets the subpacket data set is preceded by a 1372*ebfedea0SLionel Sambuc two-octet scalar count of the length in octets of all the 1373*ebfedea0SLionel Sambuc subpackets. A pointer incremented by this number will skip over the 1374*ebfedea0SLionel Sambuc subpacket data set. 1375*ebfedea0SLionel Sambuc 1376*ebfedea0SLionel Sambuc Each subpacket consists of a subpacket header and a body. The header 1377*ebfedea0SLionel Sambuc consists of: 1378*ebfedea0SLionel Sambuc 1379*ebfedea0SLionel Sambuc - the subpacket length (1, 2, or 5 octets) 1380*ebfedea0SLionel Sambuc 1381*ebfedea0SLionel Sambuc - the subpacket type (1 octet) 1382*ebfedea0SLionel Sambuc 1383*ebfedea0SLionel Sambuc and is followed by the subpacket specific data. 1384*ebfedea0SLionel Sambuc 1385*ebfedea0SLionel Sambuc The length includes the type octet but not this length. Its format 1386*ebfedea0SLionel Sambuc is similar to the "new" format packet header lengths, but cannot 1387*ebfedea0SLionel Sambuc have partial body lengths. That is: 1388*ebfedea0SLionel Sambuc 1389*ebfedea0SLionel Sambuc if the 1st octet < 192, then 1390*ebfedea0SLionel Sambuc lengthOfLength = 1 1391*ebfedea0SLionel Sambuc subpacketLen = 1st_octet 1392*ebfedea0SLionel Sambuc 1393*ebfedea0SLionel Sambuc if the 1st octet >= 192 and < 255, then 1394*ebfedea0SLionel Sambuc lengthOfLength = 2 1395*ebfedea0SLionel Sambuc subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 1396*ebfedea0SLionel Sambuc 1397*ebfedea0SLionel Sambuc 1398*ebfedea0SLionel Sambuc 1399*ebfedea0SLionel Sambuc 1400*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 25] 1401*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1402*ebfedea0SLionel Sambuc 1403*ebfedea0SLionel Sambuc if the 1st octet = 255, then 1404*ebfedea0SLionel Sambuc lengthOfLength = 5 1405*ebfedea0SLionel Sambuc subpacket length = [four-octet scalar starting at 2nd_octet] 1406*ebfedea0SLionel Sambuc 1407*ebfedea0SLionel Sambuc The value of the subpacket type octet may be: 1408*ebfedea0SLionel Sambuc 1409*ebfedea0SLionel Sambuc 0 = reserved 1410*ebfedea0SLionel Sambuc 1 = reserved 1411*ebfedea0SLionel Sambuc 2 = signature creation time 1412*ebfedea0SLionel Sambuc 3 = signature expiration time 1413*ebfedea0SLionel Sambuc 4 = exportable certification 1414*ebfedea0SLionel Sambuc 5 = trust signature 1415*ebfedea0SLionel Sambuc 6 = regular expression 1416*ebfedea0SLionel Sambuc 7 = revocable 1417*ebfedea0SLionel Sambuc 8 = reserved 1418*ebfedea0SLionel Sambuc 9 = key expiration time 1419*ebfedea0SLionel Sambuc 10 = placeholder for backward compatibility 1420*ebfedea0SLionel Sambuc 11 = preferred symmetric algorithms 1421*ebfedea0SLionel Sambuc 12 = revocation key 1422*ebfedea0SLionel Sambuc 13 = reserved 1423*ebfedea0SLionel Sambuc 14 = reserved 1424*ebfedea0SLionel Sambuc 15 = reserved 1425*ebfedea0SLionel Sambuc 16 = issuer key ID 1426*ebfedea0SLionel Sambuc 17 = reserved 1427*ebfedea0SLionel Sambuc 18 = reserved 1428*ebfedea0SLionel Sambuc 19 = reserved 1429*ebfedea0SLionel Sambuc 20 = notation data 1430*ebfedea0SLionel Sambuc 21 = preferred hash algorithms 1431*ebfedea0SLionel Sambuc 22 = preferred compression algorithms 1432*ebfedea0SLionel Sambuc 23 = key server preferences 1433*ebfedea0SLionel Sambuc 24 = preferred key server 1434*ebfedea0SLionel Sambuc 25 = primary User ID 1435*ebfedea0SLionel Sambuc 26 = policy URI 1436*ebfedea0SLionel Sambuc 27 = key flags 1437*ebfedea0SLionel Sambuc 28 = signer's User ID 1438*ebfedea0SLionel Sambuc 29 = reason for revocation 1439*ebfedea0SLionel Sambuc 30 = features 1440*ebfedea0SLionel Sambuc 31 = signature target 1441*ebfedea0SLionel Sambuc 32 = embedded signature 1442*ebfedea0SLionel Sambuc 1443*ebfedea0SLionel Sambuc 100 to 110 = private or experimental 1444*ebfedea0SLionel Sambuc 1445*ebfedea0SLionel Sambuc An implementation SHOULD ignore any subpacket of a type that it does 1446*ebfedea0SLionel Sambuc not recognize. 1447*ebfedea0SLionel Sambuc 1448*ebfedea0SLionel Sambuc Bit 7 of the subpacket type is the "critical" bit. If set, it 1449*ebfedea0SLionel Sambuc denotes that the subpacket is one that is critical for the evaluator 1450*ebfedea0SLionel Sambuc of the signature to recognize. If a subpacket is encountered that is 1451*ebfedea0SLionel Sambuc marked critical but is unknown to the evaluating software, the 1452*ebfedea0SLionel Sambuc evaluator SHOULD consider the signature to be in error. 1453*ebfedea0SLionel Sambuc 1454*ebfedea0SLionel Sambuc 1455*ebfedea0SLionel Sambuc 1456*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 26] 1457*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1458*ebfedea0SLionel Sambuc 1459*ebfedea0SLionel Sambuc An evaluator may "recognize" a subpacket, but not implement it. The 1460*ebfedea0SLionel Sambuc purpose of the critical bit is to allow the signer to tell an 1461*ebfedea0SLionel Sambuc evaluator that it would prefer a new, unknown feature to generate an 1462*ebfedea0SLionel Sambuc error than be ignored. 1463*ebfedea0SLionel Sambuc 1464*ebfedea0SLionel Sambuc Implementations SHOULD implement "preferences" and the "reason for 1465*ebfedea0SLionel Sambuc revocation" subpackets. Note, however, that if an implementation 1466*ebfedea0SLionel Sambuc chooses not to implement some of the preferences, it is required to 1467*ebfedea0SLionel Sambuc behave in a polite manner to respect the wishes of those users who 1468*ebfedea0SLionel Sambuc do implement these preferences. 1469*ebfedea0SLionel Sambuc 1470*ebfedea0SLionel Sambuc5.2.3.2. Signature Subpacket Types 1471*ebfedea0SLionel Sambuc 1472*ebfedea0SLionel Sambuc A number of subpackets are currently defined. Some subpackets apply 1473*ebfedea0SLionel Sambuc to the signature itself and some are attributes of the key. 1474*ebfedea0SLionel Sambuc Subpackets that are found on a self-signature are placed on a 1475*ebfedea0SLionel Sambuc certification made by the key itself. Note that a key may have more 1476*ebfedea0SLionel Sambuc than one User ID, and thus may have more than one self-signature, 1477*ebfedea0SLionel Sambuc and differing subpackets. 1478*ebfedea0SLionel Sambuc 1479*ebfedea0SLionel Sambuc A subpacket may be found either in the hashed or unhashed subpacket 1480*ebfedea0SLionel Sambuc sections of a signature. If a subpacket is not hashed, then the 1481*ebfedea0SLionel Sambuc information in it cannot be considered definitive because it is not 1482*ebfedea0SLionel Sambuc part of the signature proper. 1483*ebfedea0SLionel Sambuc 1484*ebfedea0SLionel Sambuc5.2.3.3. Notes on Self-Signatures 1485*ebfedea0SLionel Sambuc 1486*ebfedea0SLionel Sambuc A self-signature is a binding signature made by the key the 1487*ebfedea0SLionel Sambuc signature refers to. There are three types of self-signatures, the 1488*ebfedea0SLionel Sambuc certification signatures (types 0x10-0x13), the direct-key signature 1489*ebfedea0SLionel Sambuc (type 0x1f), and the subkey binding signature (type 0x18). For 1490*ebfedea0SLionel Sambuc certification self-signatures, each User ID may have a 1491*ebfedea0SLionel Sambuc self-signature, and thus different subpackets in those 1492*ebfedea0SLionel Sambuc self-signatures. For subkey binding signatures, each subkey in fact 1493*ebfedea0SLionel Sambuc has a self-signature. Subpackets that appear in a certification 1494*ebfedea0SLionel Sambuc self-signature apply to the username, and subpackets that appear in 1495*ebfedea0SLionel Sambuc the subkey self-signature apply to the subkey. Lastly, subpackets on 1496*ebfedea0SLionel Sambuc the direct-key signature apply to the entire key. 1497*ebfedea0SLionel Sambuc 1498*ebfedea0SLionel Sambuc Implementing software should interpret a self-signature's preference 1499*ebfedea0SLionel Sambuc subpackets as narrowly as possible. For example, suppose a key has 1500*ebfedea0SLionel Sambuc two usernames, Alice and Bob. Suppose that Alice prefers the 1501*ebfedea0SLionel Sambuc symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the 1502*ebfedea0SLionel Sambuc software locates this key via Alice's name, then the preferred 1503*ebfedea0SLionel Sambuc algorithm is CAST5, if software locates the key via Bob's name, then 1504*ebfedea0SLionel Sambuc the preferred algorithm is IDEA. If the key is located by key ID, 1505*ebfedea0SLionel Sambuc the algorithm of the primary User ID of the key provides the 1506*ebfedea0SLionel Sambuc preferred symmetric algorithm. 1507*ebfedea0SLionel Sambuc 1508*ebfedea0SLionel Sambuc Revoking a self-signature or allowing it to expire has a semantic 1509*ebfedea0SLionel Sambuc meaning that varies with the signature type. Revoking the 1510*ebfedea0SLionel Sambuc self-signature on a User ID effectively retires that user name. The 1511*ebfedea0SLionel Sambuc 1512*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 27] 1513*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1514*ebfedea0SLionel Sambuc 1515*ebfedea0SLionel Sambuc self-signature is a statement, "My name X is tied to my signing key 1516*ebfedea0SLionel Sambuc K" and is corroborated by other users' certifications. If another 1517*ebfedea0SLionel Sambuc user revokes their certification, they are effectively saying that 1518*ebfedea0SLionel Sambuc they no longer believe that name and that key are tied together. 1519*ebfedea0SLionel Sambuc Similarly, if the user themselves revokes their self-signature, it 1520*ebfedea0SLionel Sambuc means the user no longer goes by that name, no longer has that email 1521*ebfedea0SLionel Sambuc address, etc. Revoking a binding signature effectively retires that 1522*ebfedea0SLionel Sambuc subkey. Revoking a direct-key signature cancels that signature. 1523*ebfedea0SLionel Sambuc Please see the "Reason for Revocation" subpacket below for more 1524*ebfedea0SLionel Sambuc relevant detail. 1525*ebfedea0SLionel Sambuc 1526*ebfedea0SLionel Sambuc Since a self-signature contains important information about the 1527*ebfedea0SLionel Sambuc key's use, an implementation SHOULD allow the user to rewrite the 1528*ebfedea0SLionel Sambuc self-signature, and important information in it, such as preferences 1529*ebfedea0SLionel Sambuc and key expiration. 1530*ebfedea0SLionel Sambuc 1531*ebfedea0SLionel Sambuc It is good practice to verify that a self-signature imported into an 1532*ebfedea0SLionel Sambuc implementation doesn't advertise features that the implementation 1533*ebfedea0SLionel Sambuc doesn't support, rewriting the signature as appropriate. 1534*ebfedea0SLionel Sambuc 1535*ebfedea0SLionel Sambuc An implementation that encounters multiple self-signatures on the 1536*ebfedea0SLionel Sambuc same object may resolve the ambiguity in any way it sees fit, but it 1537*ebfedea0SLionel Sambuc is RECOMMENDED that priority be given to the most recent 1538*ebfedea0SLionel Sambuc self-signature. 1539*ebfedea0SLionel Sambuc 1540*ebfedea0SLionel Sambuc5.2.3.4. Signature creation time 1541*ebfedea0SLionel Sambuc 1542*ebfedea0SLionel Sambuc (4 octet time field) 1543*ebfedea0SLionel Sambuc 1544*ebfedea0SLionel Sambuc The time the signature was made. 1545*ebfedea0SLionel Sambuc 1546*ebfedea0SLionel Sambuc MUST be present in the hashed area. 1547*ebfedea0SLionel Sambuc 1548*ebfedea0SLionel Sambuc5.2.3.5. Issuer 1549*ebfedea0SLionel Sambuc 1550*ebfedea0SLionel Sambuc (8 octet key ID) 1551*ebfedea0SLionel Sambuc 1552*ebfedea0SLionel Sambuc The OpenPGP key ID of the key issuing the signature. 1553*ebfedea0SLionel Sambuc 1554*ebfedea0SLionel Sambuc5.2.3.6. Key expiration time 1555*ebfedea0SLionel Sambuc 1556*ebfedea0SLionel Sambuc (4 octet time field) 1557*ebfedea0SLionel Sambuc 1558*ebfedea0SLionel Sambuc The validity period of the key. This is the number of seconds after 1559*ebfedea0SLionel Sambuc the key creation time that the key expires. If this is not present 1560*ebfedea0SLionel Sambuc or has a value of zero, the key never expires. This is found only on 1561*ebfedea0SLionel Sambuc a self-signature. 1562*ebfedea0SLionel Sambuc 1563*ebfedea0SLionel Sambuc5.2.3.7. Preferred symmetric algorithms 1564*ebfedea0SLionel Sambuc 1565*ebfedea0SLionel Sambuc (array of one-octet values) 1566*ebfedea0SLionel Sambuc 1567*ebfedea0SLionel Sambuc 1568*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 28] 1569*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1570*ebfedea0SLionel Sambuc 1571*ebfedea0SLionel Sambuc Symmetric algorithm numbers that indicate which algorithms the key 1572*ebfedea0SLionel Sambuc holder prefers to use. The subpacket body is an ordered list of 1573*ebfedea0SLionel Sambuc octets with the most preferred listed first. It is assumed that only 1574*ebfedea0SLionel Sambuc algorithms listed are supported by the recipient's software. 1575*ebfedea0SLionel Sambuc Algorithm numbers are in section 9. This is only found on a 1576*ebfedea0SLionel Sambuc self-signature. 1577*ebfedea0SLionel Sambuc 1578*ebfedea0SLionel Sambuc5.2.3.8. Preferred hash algorithms 1579*ebfedea0SLionel Sambuc 1580*ebfedea0SLionel Sambuc (array of one-octet values) 1581*ebfedea0SLionel Sambuc 1582*ebfedea0SLionel Sambuc Message digest algorithm numbers that indicate which algorithms the 1583*ebfedea0SLionel Sambuc key holder prefers to receive. Like the preferred symmetric 1584*ebfedea0SLionel Sambuc algorithms, the list is ordered. Algorithm numbers are in section 9. 1585*ebfedea0SLionel Sambuc This is only found on a self-signature. 1586*ebfedea0SLionel Sambuc 1587*ebfedea0SLionel Sambuc5.2.3.9. Preferred compression algorithms 1588*ebfedea0SLionel Sambuc 1589*ebfedea0SLionel Sambuc (array of one-octet values) 1590*ebfedea0SLionel Sambuc 1591*ebfedea0SLionel Sambuc Compression algorithm numbers that indicate which algorithms the key 1592*ebfedea0SLionel Sambuc holder prefers to use. Like the preferred symmetric algorithms, the 1593*ebfedea0SLionel Sambuc list is ordered. Algorithm numbers are in section 9. If this 1594*ebfedea0SLionel Sambuc subpacket is not included, ZIP is preferred. A zero denotes that 1595*ebfedea0SLionel Sambuc uncompressed data is preferred; the key holder's software might have 1596*ebfedea0SLionel Sambuc no compression software in that implementation. This is only found 1597*ebfedea0SLionel Sambuc on a self-signature. 1598*ebfedea0SLionel Sambuc 1599*ebfedea0SLionel Sambuc5.2.3.10. Signature expiration time 1600*ebfedea0SLionel Sambuc 1601*ebfedea0SLionel Sambuc (4 octet time field) 1602*ebfedea0SLionel Sambuc 1603*ebfedea0SLionel Sambuc The validity period of the signature. This is the number of seconds 1604*ebfedea0SLionel Sambuc after the signature creation time that the signature expires. If 1605*ebfedea0SLionel Sambuc this is not present or has a value of zero, it never expires. 1606*ebfedea0SLionel Sambuc 1607*ebfedea0SLionel Sambuc5.2.3.11. Exportable Certification 1608*ebfedea0SLionel Sambuc 1609*ebfedea0SLionel Sambuc (1 octet of exportability, 0 for not, 1 for exportable) 1610*ebfedea0SLionel Sambuc 1611*ebfedea0SLionel Sambuc This subpacket denotes whether a certification signature is 1612*ebfedea0SLionel Sambuc "exportable," to be used by other users than the signature's issuer. 1613*ebfedea0SLionel Sambuc The packet body contains a Boolean flag indicating whether the 1614*ebfedea0SLionel Sambuc signature is exportable. If this packet is not present, the 1615*ebfedea0SLionel Sambuc certification is exportable; it is equivalent to a flag containing a 1616*ebfedea0SLionel Sambuc 1. 1617*ebfedea0SLionel Sambuc 1618*ebfedea0SLionel Sambuc Non-exportable, or "local," certifications are signatures made by a 1619*ebfedea0SLionel Sambuc user to mark a key as valid within that user's implementation only. 1620*ebfedea0SLionel Sambuc Thus, when an implementation prepares a user's copy of a key for 1621*ebfedea0SLionel Sambuc transport to another user (this is the process of "exporting" the 1622*ebfedea0SLionel Sambuc key), any local certification signatures are deleted from the key. 1623*ebfedea0SLionel Sambuc 1624*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 29] 1625*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1626*ebfedea0SLionel Sambuc 1627*ebfedea0SLionel Sambuc The receiver of a transported key "imports" it, and likewise trims 1628*ebfedea0SLionel Sambuc any local certifications. In normal operation, there won't be any, 1629*ebfedea0SLionel Sambuc assuming the import is performed on an exported key. However, there 1630*ebfedea0SLionel Sambuc are instances where this can reasonably happen. For example, if an 1631*ebfedea0SLionel Sambuc implementation allows keys to be imported from a key database in 1632*ebfedea0SLionel Sambuc addition to an exported key, then this situation can arise. 1633*ebfedea0SLionel Sambuc 1634*ebfedea0SLionel Sambuc Some implementations do not represent the interest of a single user 1635*ebfedea0SLionel Sambuc (for example, a key server). Such implementations always trim local 1636*ebfedea0SLionel Sambuc certifications from any key they handle. 1637*ebfedea0SLionel Sambuc 1638*ebfedea0SLionel Sambuc5.2.3.12. Revocable 1639*ebfedea0SLionel Sambuc 1640*ebfedea0SLionel Sambuc (1 octet of revocability, 0 for not, 1 for revocable) 1641*ebfedea0SLionel Sambuc 1642*ebfedea0SLionel Sambuc Signature's revocability status. The packet body contains a Boolean 1643*ebfedea0SLionel Sambuc flag indicating whether the signature is revocable. Signatures that 1644*ebfedea0SLionel Sambuc are not revocable have any later revocation signatures ignored. They 1645*ebfedea0SLionel Sambuc represent a commitment by the signer that he cannot revoke his 1646*ebfedea0SLionel Sambuc signature for the life of his key. If this packet is not present, 1647*ebfedea0SLionel Sambuc the signature is revocable. 1648*ebfedea0SLionel Sambuc 1649*ebfedea0SLionel Sambuc5.2.3.13. Trust signature 1650*ebfedea0SLionel Sambuc 1651*ebfedea0SLionel Sambuc (1 octet "level" (depth), 1 octet of trust amount) 1652*ebfedea0SLionel Sambuc 1653*ebfedea0SLionel Sambuc Signer asserts that the key is not only valid, but also trustworthy, 1654*ebfedea0SLionel Sambuc at the specified level. Level 0 has the same meaning as an ordinary 1655*ebfedea0SLionel Sambuc validity signature. Level 1 means that the signed key is asserted to 1656*ebfedea0SLionel Sambuc be a valid trusted introducer, with the 2nd octet of the body 1657*ebfedea0SLionel Sambuc specifying the degree of trust. Level 2 means that the signed key is 1658*ebfedea0SLionel Sambuc asserted to be trusted to issue level 1 trust signatures, i.e. that 1659*ebfedea0SLionel Sambuc it is a "meta introducer". Generally, a level n trust signature 1660*ebfedea0SLionel Sambuc asserts that a key is trusted to issue level n-1 trust signatures. 1661*ebfedea0SLionel Sambuc The trust amount is in a range from 0-255, interpreted such that 1662*ebfedea0SLionel Sambuc values less than 120 indicate partial trust and values of 120 or 1663*ebfedea0SLionel Sambuc greater indicate complete trust. Implementations SHOULD emit values 1664*ebfedea0SLionel Sambuc of 60 for partial trust and 120 for complete trust. 1665*ebfedea0SLionel Sambuc 1666*ebfedea0SLionel Sambuc5.2.3.14. Regular expression 1667*ebfedea0SLionel Sambuc 1668*ebfedea0SLionel Sambuc (null-terminated regular expression) 1669*ebfedea0SLionel Sambuc 1670*ebfedea0SLionel Sambuc Used in conjunction with trust signature packets (of level > 0) to 1671*ebfedea0SLionel Sambuc limit the scope of trust that is extended. Only signatures by the 1672*ebfedea0SLionel Sambuc target key on User IDs that match the regular expression in the body 1673*ebfedea0SLionel Sambuc of this packet have trust extended by the trust signature subpacket. 1674*ebfedea0SLionel Sambuc The regular expression uses the same syntax as the Henry Spencer's 1675*ebfedea0SLionel Sambuc "almost public domain" regular expression package. A description of 1676*ebfedea0SLionel Sambuc the syntax is found in a section below. 1677*ebfedea0SLionel Sambuc 1678*ebfedea0SLionel Sambuc 1679*ebfedea0SLionel Sambuc 1680*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 30] 1681*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1682*ebfedea0SLionel Sambuc 1683*ebfedea0SLionel Sambuc5.2.3.15. Revocation key 1684*ebfedea0SLionel Sambuc 1685*ebfedea0SLionel Sambuc (1 octet of class, 1 octet of PK algorithm ID, 20 octets of 1686*ebfedea0SLionel Sambuc fingerprint) 1687*ebfedea0SLionel Sambuc 1688*ebfedea0SLionel Sambuc Authorizes the specified key to issue revocation signatures for this 1689*ebfedea0SLionel Sambuc key. Class octet must have bit 0x80 set. If the bit 0x40 is set, 1690*ebfedea0SLionel Sambuc then this means that the revocation information is sensitive. Other 1691*ebfedea0SLionel Sambuc bits are for future expansion to other kinds of authorizations. This 1692*ebfedea0SLionel Sambuc is found on a self-signature. 1693*ebfedea0SLionel Sambuc 1694*ebfedea0SLionel Sambuc If the "sensitive" flag is set, the keyholder feels this subpacket 1695*ebfedea0SLionel Sambuc contains private trust information that describes a real-world 1696*ebfedea0SLionel Sambuc sensitive relationship. If this flag is set, implementations SHOULD 1697*ebfedea0SLionel Sambuc NOT export this signature to other users except in cases where the 1698*ebfedea0SLionel Sambuc data needs to be available: when the signature is being sent to the 1699*ebfedea0SLionel Sambuc designated revoker, or when it is accompanied by a revocation 1700*ebfedea0SLionel Sambuc signature from that revoker. Note that it may be appropriate to 1701*ebfedea0SLionel Sambuc isolate this subpacket within a separate signature so that it is not 1702*ebfedea0SLionel Sambuc combined with other subpackets that need to be exported. 1703*ebfedea0SLionel Sambuc 1704*ebfedea0SLionel Sambuc5.2.3.16. Notation Data 1705*ebfedea0SLionel Sambuc 1706*ebfedea0SLionel Sambuc (4 octets of flags, 2 octets of name length (M), 1707*ebfedea0SLionel Sambuc 2 octets of value length (N), 1708*ebfedea0SLionel Sambuc M octets of name data, 1709*ebfedea0SLionel Sambuc N octets of value data) 1710*ebfedea0SLionel Sambuc 1711*ebfedea0SLionel Sambuc This subpacket describes a "notation" on the signature that the 1712*ebfedea0SLionel Sambuc issuer wishes to make. The notation has a name and a value, each of 1713*ebfedea0SLionel Sambuc which are strings of octets. There may be more than one notation in 1714*ebfedea0SLionel Sambuc a signature. Notations can be used for any extension the issuer of 1715*ebfedea0SLionel Sambuc the signature cares to make. The "flags" field holds four octets of 1716*ebfedea0SLionel Sambuc flags. 1717*ebfedea0SLionel Sambuc 1718*ebfedea0SLionel Sambuc All undefined flags MUST be zero. Defined flags are: 1719*ebfedea0SLionel Sambuc 1720*ebfedea0SLionel Sambuc First octet: 0x80 = human-readable. This note value is text. 1721*ebfedea0SLionel Sambuc Other octets: none. 1722*ebfedea0SLionel Sambuc 1723*ebfedea0SLionel Sambuc Notation names are arbitrary strings encoded in UTF-8. They reside 1724*ebfedea0SLionel Sambuc two name spaces: The IETF name space and the user name space. 1725*ebfedea0SLionel Sambuc 1726*ebfedea0SLionel Sambuc The IETF name space is registered with IANA. These names MUST NOT 1727*ebfedea0SLionel Sambuc contain the "@" character (0x40). This this is a tag for the user 1728*ebfedea0SLionel Sambuc name space. 1729*ebfedea0SLionel Sambuc 1730*ebfedea0SLionel Sambuc Names in the user name space consist of a UTF-8 string tag followed 1731*ebfedea0SLionel Sambuc by "@" followed by a DNS domain name. Note that the tag MUST NOT 1732*ebfedea0SLionel Sambuc contain an "@" character. For example, the "sample" tag used by 1733*ebfedea0SLionel Sambuc Example Corporation could be "sample@example.com". 1734*ebfedea0SLionel Sambuc 1735*ebfedea0SLionel Sambuc 1736*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 31] 1737*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1738*ebfedea0SLionel Sambuc 1739*ebfedea0SLionel Sambuc Names in a user space are owned and controlled by the owners of that 1740*ebfedea0SLionel Sambuc domain. Obviously, it's of bad form to create a new name in a DNS 1741*ebfedea0SLionel Sambuc space that you don't own. 1742*ebfedea0SLionel Sambuc 1743*ebfedea0SLionel Sambuc Since the user name space is in the form of an email address, 1744*ebfedea0SLionel Sambuc implementers MAY wish to arrange for that address to reach a person 1745*ebfedea0SLionel Sambuc who can be consulted about the use of the named tag. Note that due 1746*ebfedea0SLionel Sambuc to UTF-8 encoding, not all valid user space name tags are valid 1747*ebfedea0SLionel Sambuc email addresses. 1748*ebfedea0SLionel Sambuc 1749*ebfedea0SLionel Sambuc If there is a critical notation, the criticality applies to that 1750*ebfedea0SLionel Sambuc specific notation and not to notations in general. 1751*ebfedea0SLionel Sambuc 1752*ebfedea0SLionel Sambuc5.2.3.17. Key server preferences 1753*ebfedea0SLionel Sambuc 1754*ebfedea0SLionel Sambuc (N octets of flags) 1755*ebfedea0SLionel Sambuc 1756*ebfedea0SLionel Sambuc This is a list of one-bit flags that indicate preferences that the 1757*ebfedea0SLionel Sambuc key holder has about how the key is handled on a key server. All 1758*ebfedea0SLionel Sambuc undefined flags MUST be zero. 1759*ebfedea0SLionel Sambuc 1760*ebfedea0SLionel Sambuc First octet: 0x80 = No-modify 1761*ebfedea0SLionel Sambuc the key holder requests that this key only be modified or 1762*ebfedea0SLionel Sambuc updated by the key holder or an administrator of the key server. 1763*ebfedea0SLionel Sambuc 1764*ebfedea0SLionel Sambuc This is found only on a self-signature. 1765*ebfedea0SLionel Sambuc 1766*ebfedea0SLionel Sambuc5.2.3.18. Preferred key server 1767*ebfedea0SLionel Sambuc 1768*ebfedea0SLionel Sambuc (String) 1769*ebfedea0SLionel Sambuc 1770*ebfedea0SLionel Sambuc This is a URI of a key server that the key holder prefers be used 1771*ebfedea0SLionel Sambuc for updates. Note that keys with multiple User IDs can have a 1772*ebfedea0SLionel Sambuc preferred key server for each User ID. Note also that since this is 1773*ebfedea0SLionel Sambuc a URI, the key server can actually be a copy of the key retrieved by 1774*ebfedea0SLionel Sambuc ftp, http, finger, etc. 1775*ebfedea0SLionel Sambuc 1776*ebfedea0SLionel Sambuc5.2.3.19. Primary User ID 1777*ebfedea0SLionel Sambuc 1778*ebfedea0SLionel Sambuc (1 octet, Boolean) 1779*ebfedea0SLionel Sambuc 1780*ebfedea0SLionel Sambuc This is a flag in a User ID's self signature that states whether 1781*ebfedea0SLionel Sambuc this User ID is the main User ID for this key. It is reasonable for 1782*ebfedea0SLionel Sambuc an implementation to resolve ambiguities in preferences, etc. by 1783*ebfedea0SLionel Sambuc referring to the primary User ID. If this flag is absent, its value 1784*ebfedea0SLionel Sambuc is zero. If more than one User ID in a key is marked as primary, the 1785*ebfedea0SLionel Sambuc implementation may resolve the ambiguity in any way it sees fit, but 1786*ebfedea0SLionel Sambuc it is RECOMMENDED that priority be given to the User ID with the 1787*ebfedea0SLionel Sambuc most recent self-signature. 1788*ebfedea0SLionel Sambuc 1789*ebfedea0SLionel Sambuc 1790*ebfedea0SLionel Sambuc 1791*ebfedea0SLionel Sambuc 1792*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 32] 1793*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1794*ebfedea0SLionel Sambuc 1795*ebfedea0SLionel Sambuc When appearing on a self-signature on a User ID packet, this 1796*ebfedea0SLionel Sambuc subpacket applies only to User ID packets. When appearing on a 1797*ebfedea0SLionel Sambuc self-signature on a User Attribute packet, this subpacket applies 1798*ebfedea0SLionel Sambuc only to User Attribute packets. That is to say, there are two 1799*ebfedea0SLionel Sambuc different and independent "primaries" - one for User IDs, and one 1800*ebfedea0SLionel Sambuc for User Attributes. 1801*ebfedea0SLionel Sambuc 1802*ebfedea0SLionel Sambuc5.2.3.20. Policy URI 1803*ebfedea0SLionel Sambuc 1804*ebfedea0SLionel Sambuc (String) 1805*ebfedea0SLionel Sambuc 1806*ebfedea0SLionel Sambuc This subpacket contains a URI of a document that describes the 1807*ebfedea0SLionel Sambuc policy that the signature was issued under. 1808*ebfedea0SLionel Sambuc 1809*ebfedea0SLionel Sambuc5.2.3.21. Key Flags 1810*ebfedea0SLionel Sambuc 1811*ebfedea0SLionel Sambuc (N octets of flags) 1812*ebfedea0SLionel Sambuc 1813*ebfedea0SLionel Sambuc This subpacket contains a list of binary flags that hold information 1814*ebfedea0SLionel Sambuc about a key. It is a string of octets, and an implementation MUST 1815*ebfedea0SLionel Sambuc NOT assume a fixed size. This is so it can grow over time. If a list 1816*ebfedea0SLionel Sambuc is shorter than an implementation expects, the unstated flags are 1817*ebfedea0SLionel Sambuc considered to be zero. The defined flags are: 1818*ebfedea0SLionel Sambuc 1819*ebfedea0SLionel Sambuc First octet: 1820*ebfedea0SLionel Sambuc 1821*ebfedea0SLionel Sambuc 0x01 - This key may be used to certify other keys. 1822*ebfedea0SLionel Sambuc 1823*ebfedea0SLionel Sambuc 0x02 - This key may be used to sign data. 1824*ebfedea0SLionel Sambuc 1825*ebfedea0SLionel Sambuc 0x04 - This key may be used to encrypt communications. 1826*ebfedea0SLionel Sambuc 1827*ebfedea0SLionel Sambuc 0x08 - This key may be used to encrypt storage. 1828*ebfedea0SLionel Sambuc 1829*ebfedea0SLionel Sambuc 0x10 - The private component of this key may have been split by 1830*ebfedea0SLionel Sambuc a secret-sharing mechanism. 1831*ebfedea0SLionel Sambuc 1832*ebfedea0SLionel Sambuc 0x20 - This key may be used for authentication. 1833*ebfedea0SLionel Sambuc 1834*ebfedea0SLionel Sambuc 0x80 - The private component of this key may be in the 1835*ebfedea0SLionel Sambuc possession of more than one person. 1836*ebfedea0SLionel Sambuc 1837*ebfedea0SLionel Sambuc Usage notes: 1838*ebfedea0SLionel Sambuc 1839*ebfedea0SLionel Sambuc The flags in this packet may appear in self-signatures or in 1840*ebfedea0SLionel Sambuc certification signatures. They mean different things depending on 1841*ebfedea0SLionel Sambuc who is making the statement -- for example, a certification 1842*ebfedea0SLionel Sambuc signature that has the "sign data" flag is stating that the 1843*ebfedea0SLionel Sambuc certification is for that use. On the other hand, the 1844*ebfedea0SLionel Sambuc "communications encryption" flag in a self-signature is stating a 1845*ebfedea0SLionel Sambuc preference that a given key be used for communications. Note 1846*ebfedea0SLionel Sambuc however, that it is a thorny issue to determine what is 1847*ebfedea0SLionel Sambuc 1848*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 33] 1849*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1850*ebfedea0SLionel Sambuc 1851*ebfedea0SLionel Sambuc "communications" and what is "storage." This decision is left wholly 1852*ebfedea0SLionel Sambuc up to the implementation; the authors of this document do not claim 1853*ebfedea0SLionel Sambuc any special wisdom on the issue, and realize that accepted opinion 1854*ebfedea0SLionel Sambuc may change. 1855*ebfedea0SLionel Sambuc 1856*ebfedea0SLionel Sambuc The "split key" (0x10) and "group key" (0x80) flags are placed on a 1857*ebfedea0SLionel Sambuc self-signature only; they are meaningless on a certification 1858*ebfedea0SLionel Sambuc signature. They SHOULD be placed only on a direct-key signature 1859*ebfedea0SLionel Sambuc (type 0x1f) or a subkey signature (type 0x18), one that refers to 1860*ebfedea0SLionel Sambuc the key the flag applies to. 1861*ebfedea0SLionel Sambuc 1862*ebfedea0SLionel Sambuc5.2.3.22. Signer's User ID 1863*ebfedea0SLionel Sambuc 1864*ebfedea0SLionel Sambuc (String) 1865*ebfedea0SLionel Sambuc 1866*ebfedea0SLionel Sambuc This subpacket allows a keyholder to state which User ID is 1867*ebfedea0SLionel Sambuc responsible for the signing. Many keyholders use a single key for 1868*ebfedea0SLionel Sambuc different purposes, such as business communications as well as 1869*ebfedea0SLionel Sambuc personal communications. This subpacket allows such a keyholder to 1870*ebfedea0SLionel Sambuc state which of their roles is making a signature. 1871*ebfedea0SLionel Sambuc 1872*ebfedea0SLionel Sambuc This subpacket is not appropriate to use to refer to a User 1873*ebfedea0SLionel Sambuc Attribute packet. 1874*ebfedea0SLionel Sambuc 1875*ebfedea0SLionel Sambuc5.2.3.23. Reason for Revocation 1876*ebfedea0SLionel Sambuc 1877*ebfedea0SLionel Sambuc (1 octet of revocation code, N octets of reason string) 1878*ebfedea0SLionel Sambuc 1879*ebfedea0SLionel Sambuc This subpacket is used only in key revocation and certification 1880*ebfedea0SLionel Sambuc revocation signatures. It describes the reason why the key or 1881*ebfedea0SLionel Sambuc certificate was revoked. 1882*ebfedea0SLionel Sambuc 1883*ebfedea0SLionel Sambuc The first octet contains a machine-readable code that denotes the 1884*ebfedea0SLionel Sambuc reason for the revocation: 1885*ebfedea0SLionel Sambuc 1886*ebfedea0SLionel Sambuc 0 - No reason specified (key revocations or cert revocations) 1887*ebfedea0SLionel Sambuc 1 - Key is superseded (key revocations) 1888*ebfedea0SLionel Sambuc 2 - Key material has been compromised (key revocations) 1889*ebfedea0SLionel Sambuc 3 - Key is retired and no longer used (key revocations) 1890*ebfedea0SLionel Sambuc 32 - User ID information is no longer valid (cert revocations) 1891*ebfedea0SLionel Sambuc 1892*ebfedea0SLionel Sambuc Following the revocation code is a string of octets which gives 1893*ebfedea0SLionel Sambuc information about the reason for revocation in human-readable form 1894*ebfedea0SLionel Sambuc (UTF-8). The string may be null, that is, of zero length. The length 1895*ebfedea0SLionel Sambuc of the subpacket is the length of the reason string plus one. 1896*ebfedea0SLionel Sambuc 1897*ebfedea0SLionel Sambuc An implementation SHOULD implement this subpacket, include it in all 1898*ebfedea0SLionel Sambuc revocation signatures, and interpret revocations appropriately. 1899*ebfedea0SLionel Sambuc There are important semantic differences between the reasons, and 1900*ebfedea0SLionel Sambuc there are thus important reasons for revoking signatures. 1901*ebfedea0SLionel Sambuc 1902*ebfedea0SLionel Sambuc 1903*ebfedea0SLionel Sambuc 1904*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 34] 1905*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1906*ebfedea0SLionel Sambuc 1907*ebfedea0SLionel Sambuc If a key has been revoked because of a compromise, all signatures 1908*ebfedea0SLionel Sambuc created by that key are suspect. However, if it was merely 1909*ebfedea0SLionel Sambuc superseded or retired, old signatures are still valid. If the 1910*ebfedea0SLionel Sambuc revoked signature is the self-signature for certifying a User ID, a 1911*ebfedea0SLionel Sambuc revocation denotes that that user name is no longer in use. Such a 1912*ebfedea0SLionel Sambuc revocation SHOULD include an 0x20 code. 1913*ebfedea0SLionel Sambuc 1914*ebfedea0SLionel Sambuc Note that any signature may be revoked, including a certification on 1915*ebfedea0SLionel Sambuc some other person's key. There are many good reasons for revoking a 1916*ebfedea0SLionel Sambuc certification signature, such as the case where the keyholder leaves 1917*ebfedea0SLionel Sambuc the employ of a business with an email address. A revoked 1918*ebfedea0SLionel Sambuc certification is no longer a part of validity calculations. 1919*ebfedea0SLionel Sambuc 1920*ebfedea0SLionel Sambuc5.2.3.24. Features 1921*ebfedea0SLionel Sambuc 1922*ebfedea0SLionel Sambuc (N octets of flags) 1923*ebfedea0SLionel Sambuc 1924*ebfedea0SLionel Sambuc The features subpacket denotes which advanced OpenPGP features a 1925*ebfedea0SLionel Sambuc user's implementation supports. This is so that as features are 1926*ebfedea0SLionel Sambuc added to OpenPGP that cannot be backwards-compatible, a user can 1927*ebfedea0SLionel Sambuc state that they can use that feature. The flags are single bits that 1928*ebfedea0SLionel Sambuc indicate that a given feature is supported. 1929*ebfedea0SLionel Sambuc 1930*ebfedea0SLionel Sambuc This subpacket is similar to a preferences subpacket, and only 1931*ebfedea0SLionel Sambuc appears in a self-signature. 1932*ebfedea0SLionel Sambuc 1933*ebfedea0SLionel Sambuc An implementation SHOULD NOT use a feature listed when sending to a 1934*ebfedea0SLionel Sambuc user who does not state that they can use it. 1935*ebfedea0SLionel Sambuc 1936*ebfedea0SLionel Sambuc Defined features are: 1937*ebfedea0SLionel Sambuc 1938*ebfedea0SLionel Sambuc First octet: 1939*ebfedea0SLionel Sambuc 1940*ebfedea0SLionel Sambuc 0x01 - Modification Detection (packets 18 and 19) 1941*ebfedea0SLionel Sambuc 1942*ebfedea0SLionel Sambuc If an implementation implements any of the defined features, it 1943*ebfedea0SLionel Sambuc SHOULD implement the features subpacket, too. 1944*ebfedea0SLionel Sambuc 1945*ebfedea0SLionel Sambuc An implementation may freely infer features from other suitable 1946*ebfedea0SLionel Sambuc implementation-dependent mechanisms. 1947*ebfedea0SLionel Sambuc 1948*ebfedea0SLionel Sambuc5.2.3.25. Signature Target 1949*ebfedea0SLionel Sambuc 1950*ebfedea0SLionel Sambuc (1 octet PK algorithm, 1 octet hash algorithm, N octets hash) 1951*ebfedea0SLionel Sambuc 1952*ebfedea0SLionel Sambuc This subpacket identifies a specific target signature that a 1953*ebfedea0SLionel Sambuc signature refers to. For revocation signatures, this subpacket 1954*ebfedea0SLionel Sambuc provides explicit designation of which signature is being revoked. 1955*ebfedea0SLionel Sambuc For a third-party or timestamp signature, this designates what 1956*ebfedea0SLionel Sambuc signature is signed. All arguments are an identifier of that target 1957*ebfedea0SLionel Sambuc signature. 1958*ebfedea0SLionel Sambuc 1959*ebfedea0SLionel Sambuc 1960*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 35] 1961*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 1962*ebfedea0SLionel Sambuc 1963*ebfedea0SLionel Sambuc The N octets of hash data MUST be the size of the hash of the 1964*ebfedea0SLionel Sambuc signature. For example, a target signature with a SHA-1 hash MUST 1965*ebfedea0SLionel Sambuc have 20 octets of hash data. 1966*ebfedea0SLionel Sambuc 1967*ebfedea0SLionel Sambuc5.2.3.26. Embedded Signature 1968*ebfedea0SLionel Sambuc 1969*ebfedea0SLionel Sambuc (1 signature packet body) 1970*ebfedea0SLionel Sambuc 1971*ebfedea0SLionel Sambuc This subpacket contains a complete signature packet body as 1972*ebfedea0SLionel Sambuc specified in section 5.2 above. It is useful when one signature 1973*ebfedea0SLionel Sambuc needs to refer to, or be incorporated in, another signature. 1974*ebfedea0SLionel Sambuc 1975*ebfedea0SLionel Sambuc5.2.4. Computing Signatures 1976*ebfedea0SLionel Sambuc 1977*ebfedea0SLionel Sambuc All signatures are formed by producing a hash over the signature 1978*ebfedea0SLionel Sambuc data, and then using the resulting hash in the signature algorithm. 1979*ebfedea0SLionel Sambuc 1980*ebfedea0SLionel Sambuc For binary document signatures (type 0x00), the document data is 1981*ebfedea0SLionel Sambuc hashed directly. For text document signatures (type 0x01), the 1982*ebfedea0SLionel Sambuc document is canonicalized by converting line endings to <CR><LF>, 1983*ebfedea0SLionel Sambuc and the resulting data is hashed. 1984*ebfedea0SLionel Sambuc 1985*ebfedea0SLionel Sambuc When a signature is made over a key, the hash data starts with the 1986*ebfedea0SLionel Sambuc octet 0x99, followed by a two-octet length of the key, and then body 1987*ebfedea0SLionel Sambuc of the key packet. (Note that this is an old-style packet header for 1988*ebfedea0SLionel Sambuc a key packet with two-octet length.) A subkey binding signature 1989*ebfedea0SLionel Sambuc (type 0x18) or primary key binding signature (type 0x19) then hashes 1990*ebfedea0SLionel Sambuc the subkey using the same format as the main key (also using 0x99 as 1991*ebfedea0SLionel Sambuc the first octet). Key revocation signatures (types 0x20 and 0x28) 1992*ebfedea0SLionel Sambuc hash only the key being revoked. 1993*ebfedea0SLionel Sambuc 1994*ebfedea0SLionel Sambuc A certification signature (type 0x10 through 0x13) hashes the User 1995*ebfedea0SLionel Sambuc ID being bound to the key into the hash context after the above 1996*ebfedea0SLionel Sambuc data. A V3 certification hashes the contents of the User ID or 1997*ebfedea0SLionel Sambuc attribute packet packet, without any header. A V4 certification 1998*ebfedea0SLionel Sambuc hashes the constant 0xb4 for User ID certifications or the constant 1999*ebfedea0SLionel Sambuc 0xd1 for User Attribute certifications, followed by a four-octet 2000*ebfedea0SLionel Sambuc number giving the length of the User ID or User Attribute data, and 2001*ebfedea0SLionel Sambuc then the User ID or User Attribute data. 2002*ebfedea0SLionel Sambuc 2003*ebfedea0SLionel Sambuc When a signature is made over a signature packet (type 0x50), the 2004*ebfedea0SLionel Sambuc hash data starts with the octet 0x88, followed by the four-octet 2005*ebfedea0SLionel Sambuc length of the signature, and then the body of the signature packet. 2006*ebfedea0SLionel Sambuc (Note that this is an old-style packet header for a signature packet 2007*ebfedea0SLionel Sambuc with the length-of-length set to zero). The unhashed subpacket data 2008*ebfedea0SLionel Sambuc of the signature packet being hashed is not included in the hash and 2009*ebfedea0SLionel Sambuc the unhashed subpacket data length value is set to zero. 2010*ebfedea0SLionel Sambuc 2011*ebfedea0SLionel Sambuc Once the data body is hashed, then a trailer is hashed. A V3 2012*ebfedea0SLionel Sambuc signature hashes five octets of the packet body, starting from the 2013*ebfedea0SLionel Sambuc signature type field. This data is the signature type, followed by 2014*ebfedea0SLionel Sambuc the four-octet signature time. A V4 signature hashes the packet body 2015*ebfedea0SLionel Sambuc 2016*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 36] 2017*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2018*ebfedea0SLionel Sambuc 2019*ebfedea0SLionel Sambuc starting from its first field, the version number, through the end 2020*ebfedea0SLionel Sambuc of the hashed subpacket data. Thus, the fields hashed are the 2021*ebfedea0SLionel Sambuc signature version, the signature type, the public key algorithm, the 2022*ebfedea0SLionel Sambuc hash algorithm, the hashed subpacket length, and the hashed 2023*ebfedea0SLionel Sambuc subpacket body. 2024*ebfedea0SLionel Sambuc 2025*ebfedea0SLionel Sambuc V4 signatures also hash in a final trailer of six octets: the 2026*ebfedea0SLionel Sambuc version of the signature packet, i.e. 0x04; 0xFF; a four-octet, 2027*ebfedea0SLionel Sambuc big-endian number that is the length of the hashed data from the 2028*ebfedea0SLionel Sambuc signature packet (note that this number does not include these final 2029*ebfedea0SLionel Sambuc six octets. 2030*ebfedea0SLionel Sambuc 2031*ebfedea0SLionel Sambuc After all this has been hashed in a single hash context the 2032*ebfedea0SLionel Sambuc resulting hash field is used in the signature algorithm, and placed 2033*ebfedea0SLionel Sambuc at the end of the signature packet. 2034*ebfedea0SLionel Sambuc 2035*ebfedea0SLionel Sambuc5.2.4.1. Subpacket Hints 2036*ebfedea0SLionel Sambuc 2037*ebfedea0SLionel Sambuc It is certainly possible for a signature to contain conflicting 2038*ebfedea0SLionel Sambuc information in subpackets. For example, a signature may contain 2039*ebfedea0SLionel Sambuc multiple copies of a preference or multiple expiration times. In 2040*ebfedea0SLionel Sambuc most cases, an implementation SHOULD use the last subpacket in the 2041*ebfedea0SLionel Sambuc signature, but MAY use any conflict resolution scheme that makes 2042*ebfedea0SLionel Sambuc more sense. Please note that we are intentionally leaving conflict 2043*ebfedea0SLionel Sambuc resolution to the implementer; most conflicts are simply syntax 2044*ebfedea0SLionel Sambuc errors, and the wishy-washy language here allows a receiver to be 2045*ebfedea0SLionel Sambuc generous in what they accept, while putting pressure on a creator to 2046*ebfedea0SLionel Sambuc be stingy in what they generate. 2047*ebfedea0SLionel Sambuc 2048*ebfedea0SLionel Sambuc Some apparent conflicts may actually make sense -- for example, 2049*ebfedea0SLionel Sambuc suppose a keyholder has an V3 key and a V4 key that share the same 2050*ebfedea0SLionel Sambuc RSA key material. Either of these keys can verify a signature 2051*ebfedea0SLionel Sambuc created by the other, and it may be reasonable for a signature to 2052*ebfedea0SLionel Sambuc contain an issuer subpacket for each key, as a way of explicitly 2053*ebfedea0SLionel Sambuc tying those keys to the signature. 2054*ebfedea0SLionel Sambuc 2055*ebfedea0SLionel Sambuc5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 2056*ebfedea0SLionel Sambuc 2057*ebfedea0SLionel Sambuc The Symmetric-Key Encrypted Session Key packet holds the 2058*ebfedea0SLionel Sambuc symmetric-key encryption of a session key used to encrypt a message. 2059*ebfedea0SLionel Sambuc Zero or more Public-Key Encrypted Session Key packets and/or 2060*ebfedea0SLionel Sambuc Symmetric-Key Encrypted Session Key packets may precede a 2061*ebfedea0SLionel Sambuc Symmetrically Encrypted Data Packet that holds an encrypted message. 2062*ebfedea0SLionel Sambuc The message is encrypted with a session key, and the session key is 2063*ebfedea0SLionel Sambuc itself encrypted and stored in the Encrypted Session Key packet or 2064*ebfedea0SLionel Sambuc the Symmetric-Key Encrypted Session Key packet. 2065*ebfedea0SLionel Sambuc 2066*ebfedea0SLionel Sambuc If the Symmetrically Encrypted Data Packet is preceded by one or 2067*ebfedea0SLionel Sambuc more Symmetric-Key Encrypted Session Key packets, each specifies a 2068*ebfedea0SLionel Sambuc passphrase that may be used to decrypt the message. This allows a 2069*ebfedea0SLionel Sambuc message to be encrypted to a number of public keys, and also to one 2070*ebfedea0SLionel Sambuc or more passphrases. This packet type is new, and is not generated 2071*ebfedea0SLionel Sambuc 2072*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 37] 2073*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2074*ebfedea0SLionel Sambuc 2075*ebfedea0SLionel Sambuc by PGP 2.x or PGP 5.0. 2076*ebfedea0SLionel Sambuc 2077*ebfedea0SLionel Sambuc The body of this packet consists of: 2078*ebfedea0SLionel Sambuc 2079*ebfedea0SLionel Sambuc - A one-octet version number. The only currently defined version 2080*ebfedea0SLionel Sambuc is 4. 2081*ebfedea0SLionel Sambuc 2082*ebfedea0SLionel Sambuc - A one-octet number describing the symmetric algorithm used. 2083*ebfedea0SLionel Sambuc 2084*ebfedea0SLionel Sambuc - A string-to-key (S2K) specifier, length as defined above. 2085*ebfedea0SLionel Sambuc 2086*ebfedea0SLionel Sambuc - Optionally, the encrypted session key itself, which is decrypted 2087*ebfedea0SLionel Sambuc with the string-to-key object. 2088*ebfedea0SLionel Sambuc 2089*ebfedea0SLionel Sambuc If the encrypted session key is not present (which can be detected 2090*ebfedea0SLionel Sambuc on the basis of packet length and S2K specifier size), then the S2K 2091*ebfedea0SLionel Sambuc algorithm applied to the passphrase produces the session key for 2092*ebfedea0SLionel Sambuc decrypting the file, using the symmetric cipher algorithm from the 2093*ebfedea0SLionel Sambuc Symmetric-Key Encrypted Session Key packet. 2094*ebfedea0SLionel Sambuc 2095*ebfedea0SLionel Sambuc If the encrypted session key is present, the result of applying the 2096*ebfedea0SLionel Sambuc S2K algorithm to the passphrase is used to decrypt just that 2097*ebfedea0SLionel Sambuc encrypted session key field, using CFB mode with an IV of all zeros. 2098*ebfedea0SLionel Sambuc The decryption result consists of a one-octet algorithm identifier 2099*ebfedea0SLionel Sambuc that specifies the symmetric-key encryption algorithm used to 2100*ebfedea0SLionel Sambuc encrypt the following Symmetrically Encrypted Data Packet, followed 2101*ebfedea0SLionel Sambuc by the session key octets themselves. 2102*ebfedea0SLionel Sambuc 2103*ebfedea0SLionel Sambuc Note: because an all-zero IV is used for this decryption, the S2K 2104*ebfedea0SLionel Sambuc specifier MUST use a salt value, either a Salted S2K or an 2105*ebfedea0SLionel Sambuc Iterated-Salted S2K. The salt value will insure that the decryption 2106*ebfedea0SLionel Sambuc key is not repeated even if the passphrase is reused. 2107*ebfedea0SLionel Sambuc 2108*ebfedea0SLionel Sambuc5.4. One-Pass Signature Packets (Tag 4) 2109*ebfedea0SLionel Sambuc 2110*ebfedea0SLionel Sambuc The One-Pass Signature packet precedes the signed data and contains 2111*ebfedea0SLionel Sambuc enough information to allow the receiver to begin calculating any 2112*ebfedea0SLionel Sambuc hashes needed to verify the signature. It allows the Signature 2113*ebfedea0SLionel Sambuc Packet to be placed at the end of the message, so that the signer 2114*ebfedea0SLionel Sambuc can compute the entire signed message in one pass. 2115*ebfedea0SLionel Sambuc 2116*ebfedea0SLionel Sambuc A One-Pass Signature does not interoperate with PGP 2.6.x or 2117*ebfedea0SLionel Sambuc earlier. 2118*ebfedea0SLionel Sambuc 2119*ebfedea0SLionel Sambuc The body of this packet consists of: 2120*ebfedea0SLionel Sambuc 2121*ebfedea0SLionel Sambuc - A one-octet version number. The current version is 3. 2122*ebfedea0SLionel Sambuc 2123*ebfedea0SLionel Sambuc - A one-octet signature type. Signature types are described in 2124*ebfedea0SLionel Sambuc section 5.2.1. 2125*ebfedea0SLionel Sambuc 2126*ebfedea0SLionel Sambuc 2127*ebfedea0SLionel Sambuc 2128*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 38] 2129*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2130*ebfedea0SLionel Sambuc 2131*ebfedea0SLionel Sambuc - A one-octet number describing the hash algorithm used. 2132*ebfedea0SLionel Sambuc 2133*ebfedea0SLionel Sambuc - A one-octet number describing the public key algorithm used. 2134*ebfedea0SLionel Sambuc 2135*ebfedea0SLionel Sambuc - An eight-octet number holding the key ID of the signing key. 2136*ebfedea0SLionel Sambuc 2137*ebfedea0SLionel Sambuc - A one-octet number holding a flag showing whether the signature 2138*ebfedea0SLionel Sambuc is nested. A zero value indicates that the next packet is 2139*ebfedea0SLionel Sambuc another One-Pass Signature packet that describes another 2140*ebfedea0SLionel Sambuc signature to be applied to the same message data. 2141*ebfedea0SLionel Sambuc 2142*ebfedea0SLionel Sambuc Note that if a message contains more than one one-pass signature, 2143*ebfedea0SLionel Sambuc then the signature packets bracket the message; that is, the first 2144*ebfedea0SLionel Sambuc signature packet after the message corresponds to the last one-pass 2145*ebfedea0SLionel Sambuc packet and the final signature packet corresponds to the first 2146*ebfedea0SLionel Sambuc one-pass packet. 2147*ebfedea0SLionel Sambuc 2148*ebfedea0SLionel Sambuc5.5. Key Material Packet 2149*ebfedea0SLionel Sambuc 2150*ebfedea0SLionel Sambuc A key material packet contains all the information about a public or 2151*ebfedea0SLionel Sambuc private key. There are four variants of this packet type, and two 2152*ebfedea0SLionel Sambuc major versions. Consequently, this section is complex. 2153*ebfedea0SLionel Sambuc 2154*ebfedea0SLionel Sambuc5.5.1. Key Packet Variants 2155*ebfedea0SLionel Sambuc 2156*ebfedea0SLionel Sambuc5.5.1.1. Public Key Packet (Tag 6) 2157*ebfedea0SLionel Sambuc 2158*ebfedea0SLionel Sambuc A Public Key packet starts a series of packets that forms an OpenPGP 2159*ebfedea0SLionel Sambuc key (sometimes called an OpenPGP certificate). 2160*ebfedea0SLionel Sambuc 2161*ebfedea0SLionel Sambuc5.5.1.2. Public Subkey Packet (Tag 14) 2162*ebfedea0SLionel Sambuc 2163*ebfedea0SLionel Sambuc A Public Subkey packet (tag 14) has exactly the same format as a 2164*ebfedea0SLionel Sambuc Public Key packet, but denotes a subkey. One or more subkeys may be 2165*ebfedea0SLionel Sambuc associated with a top-level key. By convention, the top-level key 2166*ebfedea0SLionel Sambuc provides signature services, and the subkeys provide encryption 2167*ebfedea0SLionel Sambuc services. 2168*ebfedea0SLionel Sambuc 2169*ebfedea0SLionel Sambuc Note: in PGP 2.6.x, tag 14 was intended to indicate a comment 2170*ebfedea0SLionel Sambuc packet. This tag was selected for reuse because no previous version 2171*ebfedea0SLionel Sambuc of PGP ever emitted comment packets but they did properly ignore 2172*ebfedea0SLionel Sambuc them. Public Subkey packets are ignored by PGP 2.6.x and do not 2173*ebfedea0SLionel Sambuc cause it to fail, providing a limited degree of backward 2174*ebfedea0SLionel Sambuc compatibility. 2175*ebfedea0SLionel Sambuc 2176*ebfedea0SLionel Sambuc5.5.1.3. Secret Key Packet (Tag 5) 2177*ebfedea0SLionel Sambuc 2178*ebfedea0SLionel Sambuc A Secret Key packet contains all the information that is found in a 2179*ebfedea0SLionel Sambuc Public Key packet, including the public key material, but also 2180*ebfedea0SLionel Sambuc includes the secret key material after all the public key fields. 2181*ebfedea0SLionel Sambuc 2182*ebfedea0SLionel Sambuc 2183*ebfedea0SLionel Sambuc 2184*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 39] 2185*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2186*ebfedea0SLionel Sambuc 2187*ebfedea0SLionel Sambuc5.5.1.4. Secret Subkey Packet (Tag 7) 2188*ebfedea0SLionel Sambuc 2189*ebfedea0SLionel Sambuc A Secret Subkey packet (tag 7) is the subkey analog of the Secret 2190*ebfedea0SLionel Sambuc Key packet, and has exactly the same format. 2191*ebfedea0SLionel Sambuc 2192*ebfedea0SLionel Sambuc5.5.2. Public Key Packet Formats 2193*ebfedea0SLionel Sambuc 2194*ebfedea0SLionel Sambuc There are two versions of key-material packets. Version 3 packets 2195*ebfedea0SLionel Sambuc were first generated by PGP 2.6. Version 4 keys first appeared in 2196*ebfedea0SLionel Sambuc PGP 5.0, and are the preferred key version for OpenPGP. 2197*ebfedea0SLionel Sambuc 2198*ebfedea0SLionel Sambuc OpenPGP implementations MUST create keys with version 4 format. V3 2199*ebfedea0SLionel Sambuc keys are deprecated; an implementation MUST NOT generate a V3 key, 2200*ebfedea0SLionel Sambuc but MAY accept it. 2201*ebfedea0SLionel Sambuc 2202*ebfedea0SLionel Sambuc A version 3 public key or public subkey packet contains: 2203*ebfedea0SLionel Sambuc 2204*ebfedea0SLionel Sambuc - A one-octet version number (3). 2205*ebfedea0SLionel Sambuc 2206*ebfedea0SLionel Sambuc - A four-octet number denoting the time that the key was created. 2207*ebfedea0SLionel Sambuc 2208*ebfedea0SLionel Sambuc - A two-octet number denoting the time in days that this key is 2209*ebfedea0SLionel Sambuc valid. If this number is zero, then it does not expire. 2210*ebfedea0SLionel Sambuc 2211*ebfedea0SLionel Sambuc - A one-octet number denoting the public key algorithm of this key 2212*ebfedea0SLionel Sambuc 2213*ebfedea0SLionel Sambuc - A series of multiprecision integers comprising the key material: 2214*ebfedea0SLionel Sambuc 2215*ebfedea0SLionel Sambuc - a multiprecision integer (MPI) of RSA public modulus n; 2216*ebfedea0SLionel Sambuc 2217*ebfedea0SLionel Sambuc - an MPI of RSA public encryption exponent e. 2218*ebfedea0SLionel Sambuc 2219*ebfedea0SLionel Sambuc V3 keys are deprecated. They contain three weaknesses in them. 2220*ebfedea0SLionel Sambuc First, it is relatively easy to construct a V3 key that has the same 2221*ebfedea0SLionel Sambuc key ID as any other key because the key ID is simply the low 64 bits 2222*ebfedea0SLionel Sambuc of the public modulus. Secondly, because the fingerprint of a V3 key 2223*ebfedea0SLionel Sambuc hashes the key material, but not its length, there is an increased 2224*ebfedea0SLionel Sambuc opportunity for fingerprint collisions. Third, there are weaknesses 2225*ebfedea0SLionel Sambuc in the MD5 hash algorithm that make developers prefer other 2226*ebfedea0SLionel Sambuc algorithms. See below for a fuller discussion of key IDs and 2227*ebfedea0SLionel Sambuc fingerprints. 2228*ebfedea0SLionel Sambuc 2229*ebfedea0SLionel Sambuc V2 keys are identical to the deprecated V3 keys except for the 2230*ebfedea0SLionel Sambuc version number. An implementation MUST NOT generate them and MAY 2231*ebfedea0SLionel Sambuc accept or reject them as it sees fit. 2232*ebfedea0SLionel Sambuc 2233*ebfedea0SLionel Sambuc The version 4 format is similar to the version 3 format except for 2234*ebfedea0SLionel Sambuc the absence of a validity period. This has been moved to the 2235*ebfedea0SLionel Sambuc signature packet. In addition, fingerprints of version 4 keys are 2236*ebfedea0SLionel Sambuc calculated differently from version 3 keys, as described in section 2237*ebfedea0SLionel Sambuc "Enhanced Key Formats." 2238*ebfedea0SLionel Sambuc 2239*ebfedea0SLionel Sambuc 2240*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 40] 2241*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2242*ebfedea0SLionel Sambuc 2243*ebfedea0SLionel Sambuc A version 4 packet contains: 2244*ebfedea0SLionel Sambuc 2245*ebfedea0SLionel Sambuc - A one-octet version number (4). 2246*ebfedea0SLionel Sambuc 2247*ebfedea0SLionel Sambuc - A four-octet number denoting the time that the key was created. 2248*ebfedea0SLionel Sambuc 2249*ebfedea0SLionel Sambuc - A one-octet number denoting the public key algorithm of this key 2250*ebfedea0SLionel Sambuc 2251*ebfedea0SLionel Sambuc - A series of multiprecision integers comprising the key material. 2252*ebfedea0SLionel Sambuc This algorithm-specific portion is: 2253*ebfedea0SLionel Sambuc 2254*ebfedea0SLionel Sambuc Algorithm Specific Fields for RSA public keys: 2255*ebfedea0SLionel Sambuc 2256*ebfedea0SLionel Sambuc - multiprecision integer (MPI) of RSA public modulus n; 2257*ebfedea0SLionel Sambuc 2258*ebfedea0SLionel Sambuc - MPI of RSA public encryption exponent e. 2259*ebfedea0SLionel Sambuc 2260*ebfedea0SLionel Sambuc Algorithm Specific Fields for DSA public keys: 2261*ebfedea0SLionel Sambuc 2262*ebfedea0SLionel Sambuc - MPI of DSA prime p; 2263*ebfedea0SLionel Sambuc 2264*ebfedea0SLionel Sambuc - MPI of DSA group order q (q is a prime divisor of p-1); 2265*ebfedea0SLionel Sambuc 2266*ebfedea0SLionel Sambuc - MPI of DSA group generator g; 2267*ebfedea0SLionel Sambuc 2268*ebfedea0SLionel Sambuc - MPI of DSA public key value y (= g**x mod p where x is 2269*ebfedea0SLionel Sambuc secret). 2270*ebfedea0SLionel Sambuc 2271*ebfedea0SLionel Sambuc Algorithm Specific Fields for Elgamal public keys: 2272*ebfedea0SLionel Sambuc 2273*ebfedea0SLionel Sambuc - MPI of Elgamal prime p; 2274*ebfedea0SLionel Sambuc 2275*ebfedea0SLionel Sambuc - MPI of Elgamal group generator g; 2276*ebfedea0SLionel Sambuc 2277*ebfedea0SLionel Sambuc - MPI of Elgamal public key value y (= g**x mod p where x is 2278*ebfedea0SLionel Sambuc secret). 2279*ebfedea0SLionel Sambuc 2280*ebfedea0SLionel Sambuc5.5.3. Secret Key Packet Formats 2281*ebfedea0SLionel Sambuc 2282*ebfedea0SLionel Sambuc The Secret Key and Secret Subkey packets contain all the data of the 2283*ebfedea0SLionel Sambuc Public Key and Public Subkey packets, with additional 2284*ebfedea0SLionel Sambuc algorithm-specific secret key data appended, usually in encrypted 2285*ebfedea0SLionel Sambuc form. 2286*ebfedea0SLionel Sambuc 2287*ebfedea0SLionel Sambuc The packet contains: 2288*ebfedea0SLionel Sambuc 2289*ebfedea0SLionel Sambuc - A Public Key or Public Subkey packet, as described above 2290*ebfedea0SLionel Sambuc 2291*ebfedea0SLionel Sambuc - One octet indicating string-to-key usage conventions. Zero 2292*ebfedea0SLionel Sambuc indicates that the secret key data is not encrypted. 255 or 254 2293*ebfedea0SLionel Sambuc indicates that a string-to-key specifier is being given. Any 2294*ebfedea0SLionel Sambuc other value is a symmetric-key encryption algorithm identifier. 2295*ebfedea0SLionel Sambuc 2296*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 41] 2297*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2298*ebfedea0SLionel Sambuc 2299*ebfedea0SLionel Sambuc - [Optional] If string-to-key usage octet was 255 or 254, a 2300*ebfedea0SLionel Sambuc one-octet symmetric encryption algorithm. 2301*ebfedea0SLionel Sambuc 2302*ebfedea0SLionel Sambuc - [Optional] If string-to-key usage octet was 255 or 254, a 2303*ebfedea0SLionel Sambuc string-to-key specifier. The length of the string-to-key 2304*ebfedea0SLionel Sambuc specifier is implied by its type, as described above. 2305*ebfedea0SLionel Sambuc 2306*ebfedea0SLionel Sambuc - [Optional] If secret data is encrypted (string-to-key usage 2307*ebfedea0SLionel Sambuc octet not zero), an Initial Vector (IV) of the same length as 2308*ebfedea0SLionel Sambuc the cipher's block size. 2309*ebfedea0SLionel Sambuc 2310*ebfedea0SLionel Sambuc - Plain or encrypted multiprecision integers comprising the secret 2311*ebfedea0SLionel Sambuc key data. These algorithm-specific fields are as described 2312*ebfedea0SLionel Sambuc below. 2313*ebfedea0SLionel Sambuc 2314*ebfedea0SLionel Sambuc - If the string-to-key usage octet is zero or 255, then a 2315*ebfedea0SLionel Sambuc two-octet checksum of the plaintext of the algorithm-specific 2316*ebfedea0SLionel Sambuc portion (sum of all octets, mod 65536). If the string-to-key 2317*ebfedea0SLionel Sambuc usage octet was 254, then a 20-octet SHA-1 hash of the plaintext 2318*ebfedea0SLionel Sambuc of the algorithm-specific portion. This checksum or hash is 2319*ebfedea0SLionel Sambuc encrypted together with the algorithm-specific fields (if 2320*ebfedea0SLionel Sambuc string-to-key usage octet is not zero). Note that for all other 2321*ebfedea0SLionel Sambuc values, a two-octet checksum is required. 2322*ebfedea0SLionel Sambuc 2323*ebfedea0SLionel Sambuc Algorithm Specific Fields for RSA secret keys: 2324*ebfedea0SLionel Sambuc 2325*ebfedea0SLionel Sambuc - multiprecision integer (MPI) of RSA secret exponent d. 2326*ebfedea0SLionel Sambuc 2327*ebfedea0SLionel Sambuc - MPI of RSA secret prime value p. 2328*ebfedea0SLionel Sambuc 2329*ebfedea0SLionel Sambuc - MPI of RSA secret prime value q (p < q). 2330*ebfedea0SLionel Sambuc 2331*ebfedea0SLionel Sambuc - MPI of u, the multiplicative inverse of p, mod q. 2332*ebfedea0SLionel Sambuc 2333*ebfedea0SLionel Sambuc Algorithm Specific Fields for DSA secret keys: 2334*ebfedea0SLionel Sambuc 2335*ebfedea0SLionel Sambuc - MPI of DSA secret exponent x. 2336*ebfedea0SLionel Sambuc 2337*ebfedea0SLionel Sambuc Algorithm Specific Fields for Elgamal secret keys: 2338*ebfedea0SLionel Sambuc 2339*ebfedea0SLionel Sambuc - MPI of Elgamal secret exponent x. 2340*ebfedea0SLionel Sambuc 2341*ebfedea0SLionel Sambuc Secret MPI values can be encrypted using a passphrase. If a 2342*ebfedea0SLionel Sambuc string-to-key specifier is given, that describes the algorithm for 2343*ebfedea0SLionel Sambuc converting the passphrase to a key, else a simple MD5 hash of the 2344*ebfedea0SLionel Sambuc passphrase is used. Implementations MUST use a string-to-key 2345*ebfedea0SLionel Sambuc specifier; the simple hash is for backward compatibility and is 2346*ebfedea0SLionel Sambuc deprecated, though implementations MAY continue to use existing 2347*ebfedea0SLionel Sambuc private keys in the old format. The cipher for encrypting the MPIs 2348*ebfedea0SLionel Sambuc is specified in the secret key packet. 2349*ebfedea0SLionel Sambuc 2350*ebfedea0SLionel Sambuc 2351*ebfedea0SLionel Sambuc 2352*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 42] 2353*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2354*ebfedea0SLionel Sambuc 2355*ebfedea0SLionel Sambuc Encryption/decryption of the secret data is done in CFB mode using 2356*ebfedea0SLionel Sambuc the key created from the passphrase and the Initial Vector from the 2357*ebfedea0SLionel Sambuc packet. A different mode is used with V3 keys (which are only RSA) 2358*ebfedea0SLionel Sambuc than with other key formats. With V3 keys, the MPI bit count prefix 2359*ebfedea0SLionel Sambuc (i.e., the first two octets) is not encrypted. Only the MPI 2360*ebfedea0SLionel Sambuc non-prefix data is encrypted. Furthermore, the CFB state is 2361*ebfedea0SLionel Sambuc resynchronized at the beginning of each new MPI value, so that the 2362*ebfedea0SLionel Sambuc CFB block boundary is aligned with the start of the MPI data. 2363*ebfedea0SLionel Sambuc 2364*ebfedea0SLionel Sambuc With V4 keys, a simpler method is used. All secret MPI values are 2365*ebfedea0SLionel Sambuc encrypted in CFB mode, including the MPI bitcount prefix. 2366*ebfedea0SLionel Sambuc 2367*ebfedea0SLionel Sambuc The two-octet checksum that follows the algorithm-specific portion 2368*ebfedea0SLionel Sambuc is the algebraic sum, mod 65536, of the plaintext of all the 2369*ebfedea0SLionel Sambuc algorithm-specific octets (including MPI prefix and data). With V3 2370*ebfedea0SLionel Sambuc keys, the checksum is stored in the clear. With V4 keys, the 2371*ebfedea0SLionel Sambuc checksum is encrypted like the algorithm-specific data. This value 2372*ebfedea0SLionel Sambuc is used to check that the passphrase was correct. However, this 2373*ebfedea0SLionel Sambuc checksum is deprecated; an implementation SHOULD NOT use it, but 2374*ebfedea0SLionel Sambuc should rather use the SHA-1 hash denoted with a usage octet of 254. 2375*ebfedea0SLionel Sambuc The reason for this is that there are some attacks that involve 2376*ebfedea0SLionel Sambuc undetectably modifying the secret key. 2377*ebfedea0SLionel Sambuc 2378*ebfedea0SLionel Sambuc5.6. Compressed Data Packet (Tag 8) 2379*ebfedea0SLionel Sambuc 2380*ebfedea0SLionel Sambuc The Compressed Data packet contains compressed data. Typically, this 2381*ebfedea0SLionel Sambuc packet is found as the contents of an encrypted packet, or following 2382*ebfedea0SLionel Sambuc a Signature or One-Pass Signature packet, and contains a literal 2383*ebfedea0SLionel Sambuc data packet. 2384*ebfedea0SLionel Sambuc 2385*ebfedea0SLionel Sambuc The body of this packet consists of: 2386*ebfedea0SLionel Sambuc 2387*ebfedea0SLionel Sambuc - One octet that gives the algorithm used to compress the packet. 2388*ebfedea0SLionel Sambuc 2389*ebfedea0SLionel Sambuc - The remainder of the packet is compressed data. 2390*ebfedea0SLionel Sambuc 2391*ebfedea0SLionel Sambuc A Compressed Data Packet's body contains an block that compresses 2392*ebfedea0SLionel Sambuc some set of packets. See section "Packet Composition" for details on 2393*ebfedea0SLionel Sambuc how messages are formed. 2394*ebfedea0SLionel Sambuc 2395*ebfedea0SLionel Sambuc ZIP-compressed packets are compressed with raw RFC 1951 DEFLATE 2396*ebfedea0SLionel Sambuc blocks. Note that PGP V2.6 uses 13 bits of compression. If an 2397*ebfedea0SLionel Sambuc implementation uses more bits of compression, PGP V2.6 cannot 2398*ebfedea0SLionel Sambuc decompress it. 2399*ebfedea0SLionel Sambuc 2400*ebfedea0SLionel Sambuc ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style 2401*ebfedea0SLionel Sambuc blocks. 2402*ebfedea0SLionel Sambuc 2403*ebfedea0SLionel Sambuc BZip2-compressed packets are compressed using the BZip2 [BZ2] 2404*ebfedea0SLionel Sambuc algorithm. 2405*ebfedea0SLionel Sambuc 2406*ebfedea0SLionel Sambuc 2407*ebfedea0SLionel Sambuc 2408*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 43] 2409*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2410*ebfedea0SLionel Sambuc 2411*ebfedea0SLionel Sambuc5.7. Symmetrically Encrypted Data Packet (Tag 9) 2412*ebfedea0SLionel Sambuc 2413*ebfedea0SLionel Sambuc The Symmetrically Encrypted Data packet contains data encrypted with 2414*ebfedea0SLionel Sambuc a symmetric-key algorithm. When it has been decrypted, it contains 2415*ebfedea0SLionel Sambuc other packets (usually a literal data packet or compressed data 2416*ebfedea0SLionel Sambuc packet, but in theory other Symmetrically Encrypted Data Packets or 2417*ebfedea0SLionel Sambuc sequences of packets that form whole OpenPGP messages). 2418*ebfedea0SLionel Sambuc 2419*ebfedea0SLionel Sambuc The body of this packet consists of: 2420*ebfedea0SLionel Sambuc 2421*ebfedea0SLionel Sambuc - Encrypted data, the output of the selected symmetric-key cipher 2422*ebfedea0SLionel Sambuc operating in OpenPGP's variant of Cipher Feedback (CFB) mode. 2423*ebfedea0SLionel Sambuc 2424*ebfedea0SLionel Sambuc The symmetric cipher used may be specified in an Public-Key or 2425*ebfedea0SLionel Sambuc Symmetric-Key Encrypted Session Key packet that precedes the 2426*ebfedea0SLionel Sambuc Symmetrically Encrypted Data Packet. In that case, the cipher 2427*ebfedea0SLionel Sambuc algorithm octet is prefixed to the session key before it is 2428*ebfedea0SLionel Sambuc encrypted. If no packets of these types precede the encrypted data, 2429*ebfedea0SLionel Sambuc the IDEA algorithm is used with the session key calculated as the 2430*ebfedea0SLionel Sambuc MD5 hash of the passphrase, though this use is deprecated. 2431*ebfedea0SLionel Sambuc 2432*ebfedea0SLionel Sambuc The data is encrypted in CFB mode, with a CFB shift size equal to 2433*ebfedea0SLionel Sambuc the cipher's block size. The Initial Vector (IV) is specified as all 2434*ebfedea0SLionel Sambuc zeros. Instead of using an IV, OpenPGP prefixes a string of length 2435*ebfedea0SLionel Sambuc equal to the block size of the cipher plus two to the data before it 2436*ebfedea0SLionel Sambuc is encrypted. The first block-size octets (for example, 8 octets for 2437*ebfedea0SLionel Sambuc a 64-bit block length) are random, and the following two octets are 2438*ebfedea0SLionel Sambuc copies of the last two octets of the IV. For example, in an 8 octet 2439*ebfedea0SLionel Sambuc block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of 2440*ebfedea0SLionel Sambuc octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15 2441*ebfedea0SLionel Sambuc and octet 18 is a repeat of octet 16. As a pedantic clarification, 2442*ebfedea0SLionel Sambuc in both these examples, we consider the first octet to be numbered 2443*ebfedea0SLionel Sambuc 1. 2444*ebfedea0SLionel Sambuc 2445*ebfedea0SLionel Sambuc After encrypting the first block-size-plus-two octets, the CFB state 2446*ebfedea0SLionel Sambuc is resynchronized. The last block-size octets of ciphertext are 2447*ebfedea0SLionel Sambuc passed through the cipher and the block boundary is reset. 2448*ebfedea0SLionel Sambuc 2449*ebfedea0SLionel Sambuc The repetition of 16 bits in the random data prefixed to the message 2450*ebfedea0SLionel Sambuc allows the receiver to immediately check whether the session key is 2451*ebfedea0SLionel Sambuc incorrect. See the Security Considerations section for hints on the 2452*ebfedea0SLionel Sambuc proper use of this "quick check." 2453*ebfedea0SLionel Sambuc 2454*ebfedea0SLionel Sambuc5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 2455*ebfedea0SLionel Sambuc 2456*ebfedea0SLionel Sambuc An experimental version of PGP used this packet as the Literal 2457*ebfedea0SLionel Sambuc packet, but no released version of PGP generated Literal packets 2458*ebfedea0SLionel Sambuc with this tag. With PGP 5.x, this packet has been re-assigned and is 2459*ebfedea0SLionel Sambuc reserved for use as the Marker packet. 2460*ebfedea0SLionel Sambuc 2461*ebfedea0SLionel Sambuc 2462*ebfedea0SLionel Sambuc 2463*ebfedea0SLionel Sambuc 2464*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 44] 2465*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2466*ebfedea0SLionel Sambuc 2467*ebfedea0SLionel Sambuc The body of this packet consists of: 2468*ebfedea0SLionel Sambuc 2469*ebfedea0SLionel Sambuc - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). 2470*ebfedea0SLionel Sambuc 2471*ebfedea0SLionel Sambuc Such a packet MUST be ignored when received. It may be placed at the 2472*ebfedea0SLionel Sambuc beginning of a message that uses features not available in PGP 2.6.x 2473*ebfedea0SLionel Sambuc in order to cause that version to report that newer software is 2474*ebfedea0SLionel Sambuc necessary to process the message. 2475*ebfedea0SLionel Sambuc 2476*ebfedea0SLionel Sambuc5.9. Literal Data Packet (Tag 11) 2477*ebfedea0SLionel Sambuc 2478*ebfedea0SLionel Sambuc A Literal Data packet contains the body of a message; data that is 2479*ebfedea0SLionel Sambuc not to be further interpreted. 2480*ebfedea0SLionel Sambuc 2481*ebfedea0SLionel Sambuc The body of this packet consists of: 2482*ebfedea0SLionel Sambuc 2483*ebfedea0SLionel Sambuc - A one-octet field that describes how the data is formatted. 2484*ebfedea0SLionel Sambuc 2485*ebfedea0SLionel Sambuc If it is a 'b' (0x62), then the literal packet contains binary data. 2486*ebfedea0SLionel Sambuc If it is a 't' (0x74), then it contains text data, and thus may need 2487*ebfedea0SLionel Sambuc line ends converted to local form, or other text-mode changes. The 2488*ebfedea0SLionel Sambuc tag 'u' (0x75) means the same as 't', but also indicates that 2489*ebfedea0SLionel Sambuc implementation believes that the literal data contains UTF-8 text. 2490*ebfedea0SLionel Sambuc 2491*ebfedea0SLionel Sambuc Early versions of PGP also defined a value of 'l' as a 'local' mode 2492*ebfedea0SLionel Sambuc for machine-local conversions. RFC 1991 incorrectly stated this 2493*ebfedea0SLionel Sambuc local mode flag as '1' (ASCII numeral one). Both of these local 2494*ebfedea0SLionel Sambuc modes are deprecated. 2495*ebfedea0SLionel Sambuc 2496*ebfedea0SLionel Sambuc - File name as a string (one-octet length, followed by a file 2497*ebfedea0SLionel Sambuc name). This may be a zero-length string. Commonly, if the source 2498*ebfedea0SLionel Sambuc of the encrypted data is a file, this will be the name of the 2499*ebfedea0SLionel Sambuc encrypted file. An implementation MAY consider the file name in 2500*ebfedea0SLionel Sambuc the literal packet to be a more authoritative name than the 2501*ebfedea0SLionel Sambuc actual file name. 2502*ebfedea0SLionel Sambuc 2503*ebfedea0SLionel Sambuc If the special name "_CONSOLE" is used, the message is considered to 2504*ebfedea0SLionel Sambuc be "for your eyes only". This advises that the message data is 2505*ebfedea0SLionel Sambuc unusually sensitive, and the receiving program should process it 2506*ebfedea0SLionel Sambuc more carefully, perhaps avoiding storing the received data to disk, 2507*ebfedea0SLionel Sambuc for example. 2508*ebfedea0SLionel Sambuc 2509*ebfedea0SLionel Sambuc - A four-octet number that indicates a date associated with the 2510*ebfedea0SLionel Sambuc literal data. Commonly, the date might be the modification date 2511*ebfedea0SLionel Sambuc of a file, or the time the packet was created, or a zero that 2512*ebfedea0SLionel Sambuc indicates no specific time. 2513*ebfedea0SLionel Sambuc 2514*ebfedea0SLionel Sambuc - The remainder of the packet is literal data. 2515*ebfedea0SLionel Sambuc 2516*ebfedea0SLionel Sambuc Text data is stored with <CR><LF> text endings (i.e. network-normal 2517*ebfedea0SLionel Sambuc line endings). These should be converted to native line endings by 2518*ebfedea0SLionel Sambuc the receiving software. 2519*ebfedea0SLionel Sambuc 2520*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 45] 2521*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2522*ebfedea0SLionel Sambuc 2523*ebfedea0SLionel Sambuc5.10. Trust Packet (Tag 12) 2524*ebfedea0SLionel Sambuc 2525*ebfedea0SLionel Sambuc The Trust packet is used only within keyrings and is not normally 2526*ebfedea0SLionel Sambuc exported. Trust packets contain data that record the user's 2527*ebfedea0SLionel Sambuc specifications of which key holders are trustworthy introducers, 2528*ebfedea0SLionel Sambuc along with other information that implementing software uses for 2529*ebfedea0SLionel Sambuc trust information. The format of trust packets is defined by a given 2530*ebfedea0SLionel Sambuc implementation. 2531*ebfedea0SLionel Sambuc 2532*ebfedea0SLionel Sambuc Trust packets SHOULD NOT be emitted to output streams that are 2533*ebfedea0SLionel Sambuc transferred to other users, and they SHOULD be ignored on any input 2534*ebfedea0SLionel Sambuc other than local keyring files. 2535*ebfedea0SLionel Sambuc 2536*ebfedea0SLionel Sambuc5.11. User ID Packet (Tag 13) 2537*ebfedea0SLionel Sambuc 2538*ebfedea0SLionel Sambuc A User ID packet consists of UTF-8 text that is intended to 2539*ebfedea0SLionel Sambuc represent the name and email address of the key holder. By 2540*ebfedea0SLionel Sambuc convention, it includes an RFC 2822 mail name-addr, but there are no 2541*ebfedea0SLionel Sambuc restrictions on its content. The packet length in the header 2542*ebfedea0SLionel Sambuc specifies the length of the User ID. 2543*ebfedea0SLionel Sambuc 2544*ebfedea0SLionel Sambuc5.12. User Attribute Packet (Tag 17) 2545*ebfedea0SLionel Sambuc 2546*ebfedea0SLionel Sambuc The User Attribute packet is a variation of the User ID packet. It 2547*ebfedea0SLionel Sambuc is capable of storing more types of data than the User ID packet 2548*ebfedea0SLionel Sambuc which is limited to text. Like the User ID packet, a User Attribute 2549*ebfedea0SLionel Sambuc packet may be certified by the key owner ("self-signed") or any 2550*ebfedea0SLionel Sambuc other key owner who cares to certify it. Except as noted, a User 2551*ebfedea0SLionel Sambuc Attribute packet may be used anywhere that a User ID packet may be 2552*ebfedea0SLionel Sambuc used. 2553*ebfedea0SLionel Sambuc 2554*ebfedea0SLionel Sambuc While User Attribute packets are not a required part of the OpenPGP 2555*ebfedea0SLionel Sambuc standard, implementations SHOULD provide at least enough 2556*ebfedea0SLionel Sambuc compatibility to properly handle a certification signature on the 2557*ebfedea0SLionel Sambuc User Attribute packet. A simple way to do this is by treating the 2558*ebfedea0SLionel Sambuc User Attribute packet as a User ID packet with opaque contents, but 2559*ebfedea0SLionel Sambuc an implementation may use any method desired. 2560*ebfedea0SLionel Sambuc 2561*ebfedea0SLionel Sambuc The User Attribute packet is made up of one or more attribute 2562*ebfedea0SLionel Sambuc subpackets. Each subpacket consists of a subpacket header and a 2563*ebfedea0SLionel Sambuc body. The header consists of: 2564*ebfedea0SLionel Sambuc 2565*ebfedea0SLionel Sambuc - the subpacket length (1, 2, or 5 octets) 2566*ebfedea0SLionel Sambuc 2567*ebfedea0SLionel Sambuc - the subpacket type (1 octet) 2568*ebfedea0SLionel Sambuc 2569*ebfedea0SLionel Sambuc and is followed by the subpacket specific data. 2570*ebfedea0SLionel Sambuc 2571*ebfedea0SLionel Sambuc The only currently defined subpacket type is 1, signifying an image. 2572*ebfedea0SLionel Sambuc An implementation SHOULD ignore any subpacket of a type that it does 2573*ebfedea0SLionel Sambuc not recognize. Subpacket types 100 through 110 are reserved for 2574*ebfedea0SLionel Sambuc private or experimental use. 2575*ebfedea0SLionel Sambuc 2576*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 46] 2577*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2578*ebfedea0SLionel Sambuc 2579*ebfedea0SLionel Sambuc5.12.1. The Image Attribute Subpacket 2580*ebfedea0SLionel Sambuc 2581*ebfedea0SLionel Sambuc The image attribute subpacket is used to encode an image, presumably 2582*ebfedea0SLionel Sambuc (but not required to be) that of the key owner. 2583*ebfedea0SLionel Sambuc 2584*ebfedea0SLionel Sambuc The image attribute subpacket begins with an image header. The first 2585*ebfedea0SLionel Sambuc two octets of the image header contain the length of the image 2586*ebfedea0SLionel Sambuc header. Note that unlike other multi-octet numerical values in this 2587*ebfedea0SLionel Sambuc document, due to an historical accident this value is encoded as a 2588*ebfedea0SLionel Sambuc little-endian number. The image header length is followed by a 2589*ebfedea0SLionel Sambuc single octet for the image header version. The only currently 2590*ebfedea0SLionel Sambuc defined version of the image header is 1, which is a 16 octet image 2591*ebfedea0SLionel Sambuc header. The first three octets of a version 1 image header are thus 2592*ebfedea0SLionel Sambuc 0x10 0x00 0x01. 2593*ebfedea0SLionel Sambuc 2594*ebfedea0SLionel Sambuc The fourth octet of a version 1 image header designates the encoding 2595*ebfedea0SLionel Sambuc format of the image. The only currently defined encoding format is 2596*ebfedea0SLionel Sambuc the value 1 to indicate JPEG. Image format types 100 through 110 are 2597*ebfedea0SLionel Sambuc reserved for private or experimental use. The rest of the version 1 2598*ebfedea0SLionel Sambuc image header is made up of 12 reserved octets, all of which MUST be 2599*ebfedea0SLionel Sambuc set to 0. 2600*ebfedea0SLionel Sambuc 2601*ebfedea0SLionel Sambuc The rest of the image subpacket contains the image itself. As the 2602*ebfedea0SLionel Sambuc only currently defined image type is JPEG, the image is encoded in 2603*ebfedea0SLionel Sambuc the JPEG File Interchange Format (JFIF), a standard file format for 2604*ebfedea0SLionel Sambuc JPEG images. [JFIF] 2605*ebfedea0SLionel Sambuc 2606*ebfedea0SLionel Sambuc An implementation MAY try and determine the type of an image by 2607*ebfedea0SLionel Sambuc examination of the image data if it is unable to handle a particular 2608*ebfedea0SLionel Sambuc version of the image header or if a specified encoding format value 2609*ebfedea0SLionel Sambuc is not recognized. 2610*ebfedea0SLionel Sambuc 2611*ebfedea0SLionel Sambuc5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 2612*ebfedea0SLionel Sambuc 2613*ebfedea0SLionel Sambuc The Symmetrically Encrypted Integrity Protected Data Packet is a 2614*ebfedea0SLionel Sambuc variant of the Symmetrically Encrypted Data Packet. It is a new 2615*ebfedea0SLionel Sambuc feature created for OpenPGP that addresses the problem of detecting 2616*ebfedea0SLionel Sambuc a modification to encrypted data. It is used in combination with a 2617*ebfedea0SLionel Sambuc Modification Detection Code Packet. 2618*ebfedea0SLionel Sambuc 2619*ebfedea0SLionel Sambuc There is a corresponding feature in the features signature subpacket 2620*ebfedea0SLionel Sambuc that denotes that an implementation can properly use this packet 2621*ebfedea0SLionel Sambuc type. An implementation MUST support decrypting these packets and 2622*ebfedea0SLionel Sambuc SHOULD prefer generating them to the older Symmetrically Encrypted 2623*ebfedea0SLionel Sambuc Data Packet when possible. Since this data packet protects against 2624*ebfedea0SLionel Sambuc modification attacks, this standard encourages its proliferation. 2625*ebfedea0SLionel Sambuc While blanket adoption of this data packet would create 2626*ebfedea0SLionel Sambuc interoperability problems, rapid adoption is nevertheless important. 2627*ebfedea0SLionel Sambuc An implementation SHOULD specifically denote support for this 2628*ebfedea0SLionel Sambuc packet, but it MAY infer it from other mechanisms. 2629*ebfedea0SLionel Sambuc 2630*ebfedea0SLionel Sambuc 2631*ebfedea0SLionel Sambuc 2632*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 47] 2633*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2634*ebfedea0SLionel Sambuc 2635*ebfedea0SLionel Sambuc For example, an implementation might infer from the use of a cipher 2636*ebfedea0SLionel Sambuc such as AES or Twofish that a user supports this feature. It might 2637*ebfedea0SLionel Sambuc place in the unhashed portion of another user's key signature a 2638*ebfedea0SLionel Sambuc features subpacket. It might also present a user with an opportunity 2639*ebfedea0SLionel Sambuc to regenerate their own self-signature with a features subpacket. 2640*ebfedea0SLionel Sambuc 2641*ebfedea0SLionel Sambuc This packet contains data encrypted with a symmetric-key algorithm 2642*ebfedea0SLionel Sambuc and protected against modification by the SHA-1 hash algorithm. When 2643*ebfedea0SLionel Sambuc it has been decrypted, it will typically contain other packets 2644*ebfedea0SLionel Sambuc (often a literal data packet or compressed data packet). The last 2645*ebfedea0SLionel Sambuc decrypted packet in this packet's payload MUST be a Modification 2646*ebfedea0SLionel Sambuc Detection Code packet. 2647*ebfedea0SLionel Sambuc 2648*ebfedea0SLionel Sambuc The body of this packet consists of: 2649*ebfedea0SLionel Sambuc 2650*ebfedea0SLionel Sambuc - A one-octet version number. The only currently defined value is 2651*ebfedea0SLionel Sambuc 1. 2652*ebfedea0SLionel Sambuc 2653*ebfedea0SLionel Sambuc - Encrypted data, the output of the selected symmetric-key cipher 2654*ebfedea0SLionel Sambuc operating in Cipher Feedback mode with shift amount equal to the 2655*ebfedea0SLionel Sambuc block size of the cipher (CFB-n where n is the block size). 2656*ebfedea0SLionel Sambuc 2657*ebfedea0SLionel Sambuc The symmetric cipher used MUST be specified in a Public-Key or 2658*ebfedea0SLionel Sambuc Symmetric-Key Encrypted Session Key packet that precedes the 2659*ebfedea0SLionel Sambuc Symmetrically Encrypted Data Packet. In either case, the cipher 2660*ebfedea0SLionel Sambuc algorithm octet is prefixed to the session key before it is 2661*ebfedea0SLionel Sambuc encrypted. 2662*ebfedea0SLionel Sambuc 2663*ebfedea0SLionel Sambuc The data is encrypted in CFB mode, with a CFB shift size equal to 2664*ebfedea0SLionel Sambuc the cipher's block size. The Initial Vector (IV) is specified as all 2665*ebfedea0SLionel Sambuc zeros. Instead of using an IV, OpenPGP prefixes an octet string to 2666*ebfedea0SLionel Sambuc the data before it is encrypted. The length of the octet string 2667*ebfedea0SLionel Sambuc equals the block size of the cipher in octets, plus two. The first 2668*ebfedea0SLionel Sambuc octets in the group, of length equal to the block size of the 2669*ebfedea0SLionel Sambuc cipher, are random; the last two octets are each copies of their 2nd 2670*ebfedea0SLionel Sambuc preceding octet. For example, with a cipher whose block size is 128 2671*ebfedea0SLionel Sambuc bits or 16 octets, the prefix data will contain 16 random octets, 2672*ebfedea0SLionel Sambuc then two more octets, which are copies of the 15th and 16th octets, 2673*ebfedea0SLionel Sambuc respectively. Unlike the Symmetrically Encrypted Data Packet, no 2674*ebfedea0SLionel Sambuc special CFB resynchronization is done after encrypting this prefix 2675*ebfedea0SLionel Sambuc data. See OpenPGP CFB Mode below for more details. 2676*ebfedea0SLionel Sambuc 2677*ebfedea0SLionel Sambuc The repetition of 16 bits in the random data prefixed to the message 2678*ebfedea0SLionel Sambuc allows the receiver to immediately check whether the session key is 2679*ebfedea0SLionel Sambuc incorrect. 2680*ebfedea0SLionel Sambuc 2681*ebfedea0SLionel Sambuc The plaintext of the data to be encrypted is passed through the 2682*ebfedea0SLionel Sambuc SHA-1 hash function, and the result of the hash is appended to the 2683*ebfedea0SLionel Sambuc plaintext in a Modification Detection Code packet. The input to the 2684*ebfedea0SLionel Sambuc hash function includes the prefix data described above; it includes 2685*ebfedea0SLionel Sambuc all of the plaintext, and then also includes two octets of values 2686*ebfedea0SLionel Sambuc 0xD3, 0x14. These represent the encoding of a Modification Detection 2687*ebfedea0SLionel Sambuc 2688*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 48] 2689*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2690*ebfedea0SLionel Sambuc 2691*ebfedea0SLionel Sambuc Code packet tag and length field of 20 octets. 2692*ebfedea0SLionel Sambuc 2693*ebfedea0SLionel Sambuc The resulting hash value is stored in a Modification Detection Code 2694*ebfedea0SLionel Sambuc packet which MUST use the two octet encoding just given to represent 2695*ebfedea0SLionel Sambuc its tag and length field. The body of the MDC packet is the 20 octet 2696*ebfedea0SLionel Sambuc output of the SHA-1 hash. 2697*ebfedea0SLionel Sambuc 2698*ebfedea0SLionel Sambuc The Modification Detection Code packet is appended to the plaintext 2699*ebfedea0SLionel Sambuc and encrypted along with the plaintext using the same CFB context. 2700*ebfedea0SLionel Sambuc 2701*ebfedea0SLionel Sambuc During decryption, the plaintext data should be hashed with SHA-1, 2702*ebfedea0SLionel Sambuc including the prefix data as well as the packet tag and length field 2703*ebfedea0SLionel Sambuc of the Modification Detection Code packet. The body of the MDC 2704*ebfedea0SLionel Sambuc packet, upon decryption, is compared with the result of the SHA-1 2705*ebfedea0SLionel Sambuc hash. 2706*ebfedea0SLionel Sambuc 2707*ebfedea0SLionel Sambuc Any failure of the MDC indicates that the message has been modified 2708*ebfedea0SLionel Sambuc and MUST be treated as a security problem. Failures include a 2709*ebfedea0SLionel Sambuc difference in the hash values, but also the absence of an MDC 2710*ebfedea0SLionel Sambuc packet, or an MDC packet in any position other than the end of the 2711*ebfedea0SLionel Sambuc plaintext. Any failure SHOULD be reported to the user. 2712*ebfedea0SLionel Sambuc 2713*ebfedea0SLionel Sambuc Note: future designs of new versions of this packet should consider 2714*ebfedea0SLionel Sambuc rollback attacks since it will be possible for an attacker to change 2715*ebfedea0SLionel Sambuc the version back to 1. 2716*ebfedea0SLionel Sambuc 2717*ebfedea0SLionel Sambuc NON-NORMATIVE EXPLANATION 2718*ebfedea0SLionel Sambuc 2719*ebfedea0SLionel Sambuc The MDC system, as packets 18 and 19 are called, were created to 2720*ebfedea0SLionel Sambuc provide an integrity mechanism that is less strong than a 2721*ebfedea0SLionel Sambuc signature, yet stronger than bare CFB encryption. 2722*ebfedea0SLionel Sambuc 2723*ebfedea0SLionel Sambuc It is a limitation of CFB encryption that damage to the 2724*ebfedea0SLionel Sambuc ciphertext will corrupt the affected cipher blocks and the block 2725*ebfedea0SLionel Sambuc following. Additionally, if data is removed from the end of a 2726*ebfedea0SLionel Sambuc CFB-encrypted block, that removal is undetectable. (Note also 2727*ebfedea0SLionel Sambuc that CBC mode has a similar limitation, but data removed from 2728*ebfedea0SLionel Sambuc the front of the block is undetectable.) 2729*ebfedea0SLionel Sambuc 2730*ebfedea0SLionel Sambuc The obvious way to protect or authenticate an encrypted block is 2731*ebfedea0SLionel Sambuc to digitally sign it. However, many people do not wish to 2732*ebfedea0SLionel Sambuc habitually sign data, for a large number of reasons beyond the 2733*ebfedea0SLionel Sambuc scope of this document. Suffice it to say that many people 2734*ebfedea0SLionel Sambuc consider properties such as deniability to be as valuable as 2735*ebfedea0SLionel Sambuc integrity. 2736*ebfedea0SLionel Sambuc 2737*ebfedea0SLionel Sambuc OpenPGP addresses this desire to have more security than raw 2738*ebfedea0SLionel Sambuc encryption and yet preserve deniability with the MDC system. An 2739*ebfedea0SLionel Sambuc MDC is intentionally not a MAC. Its name was not selected by 2740*ebfedea0SLionel Sambuc accident. It is analogous to a checksum. 2741*ebfedea0SLionel Sambuc 2742*ebfedea0SLionel Sambuc 2743*ebfedea0SLionel Sambuc 2744*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 49] 2745*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2746*ebfedea0SLionel Sambuc 2747*ebfedea0SLionel Sambuc Despite the fact that it is a relatively modest system, it has 2748*ebfedea0SLionel Sambuc proved itself in the real world. It is an effective defense to 2749*ebfedea0SLionel Sambuc several attacks that have surfaced since it has been created. It 2750*ebfedea0SLionel Sambuc has met its modest goals admirably. 2751*ebfedea0SLionel Sambuc 2752*ebfedea0SLionel Sambuc Consequently, because it is a modest security system, it has 2753*ebfedea0SLionel Sambuc modest requirements on the hash function(s) it employs. It does 2754*ebfedea0SLionel Sambuc not rely on a hash function being collision-free, it relies on a 2755*ebfedea0SLionel Sambuc hash function being one-way. If a forger, Frank, wishes to send 2756*ebfedea0SLionel Sambuc Alice a (digitally) unsigned message that says, "I've always 2757*ebfedea0SLionel Sambuc secretly loved you, signed Bob" it is far easier for him to 2758*ebfedea0SLionel Sambuc construct a new message than it is to modify anything 2759*ebfedea0SLionel Sambuc intercepted from Bob. (Note also that if Bob wishes to 2760*ebfedea0SLionel Sambuc communicate secretly with Alice, but without authentication nor 2761*ebfedea0SLionel Sambuc identification and with a threat model that includes forgers, he 2762*ebfedea0SLionel Sambuc has a problem that transcends mere cryptography.) 2763*ebfedea0SLionel Sambuc 2764*ebfedea0SLionel Sambuc Note also that unlike nearly every other OpenPGP subsystem, 2765*ebfedea0SLionel Sambuc there are no parameters in the MDC system. It hard-defines SHA-1 2766*ebfedea0SLionel Sambuc as its hash function. This is not an accident. It is an 2767*ebfedea0SLionel Sambuc intentional choice to avoid downgrade and cross-grade attacks 2768*ebfedea0SLionel Sambuc while making a simple, fast system. (A downgrade attack would be 2769*ebfedea0SLionel Sambuc an attack that replaced SHA-256 with SHA-1, for example. A 2770*ebfedea0SLionel Sambuc cross-grade attack would replace SHA-1 with another 160-bit 2771*ebfedea0SLionel Sambuc hash, such as RIPE-MD/160, for example.) 2772*ebfedea0SLionel Sambuc 2773*ebfedea0SLionel Sambuc However, given the present state of hash function cryptanalysis 2774*ebfedea0SLionel Sambuc and cryptography, it may be desirable to upgrade the MDC system 2775*ebfedea0SLionel Sambuc to a new hash function. See section 10.5 in the IANA 2776*ebfedea0SLionel Sambuc considerations for guidance. 2777*ebfedea0SLionel Sambuc 2778*ebfedea0SLionel Sambuc5.14. Modification Detection Code Packet (Tag 19) 2779*ebfedea0SLionel Sambuc 2780*ebfedea0SLionel Sambuc The Modification Detection Code packet contains a SHA-1 hash of 2781*ebfedea0SLionel Sambuc plaintext data which is used to detect message modification. It is 2782*ebfedea0SLionel Sambuc only used with a Symmetrically Encrypted Integrity Protected Data 2783*ebfedea0SLionel Sambuc packet. The Modification Detection Code packet MUST be the last 2784*ebfedea0SLionel Sambuc packet in the plaintext data which is encrypted in the Symmetrically 2785*ebfedea0SLionel Sambuc Encrypted Integrity Protected Data packet, and MUST appear in no 2786*ebfedea0SLionel Sambuc other place. 2787*ebfedea0SLionel Sambuc 2788*ebfedea0SLionel Sambuc A Modification Detection Code packet MUST have a length of 20 2789*ebfedea0SLionel Sambuc octets. 2790*ebfedea0SLionel Sambuc 2791*ebfedea0SLionel Sambuc The body of this packet consists of: 2792*ebfedea0SLionel Sambuc 2793*ebfedea0SLionel Sambuc - A 20-octet SHA-1 hash of the preceding plaintext data of the 2794*ebfedea0SLionel Sambuc Symmetrically Encrypted Integrity Protected Data packet, 2795*ebfedea0SLionel Sambuc including prefix data, the tag octet, and length octet of the 2796*ebfedea0SLionel Sambuc Modification Detection Code packet. 2797*ebfedea0SLionel Sambuc 2798*ebfedea0SLionel Sambuc 2799*ebfedea0SLionel Sambuc 2800*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 50] 2801*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2802*ebfedea0SLionel Sambuc 2803*ebfedea0SLionel Sambuc Note that the Modification Detection Code packet MUST always use a 2804*ebfedea0SLionel Sambuc new-format encoding of the packet tag, and a one-octet encoding of 2805*ebfedea0SLionel Sambuc the packet length. The reason for this is that the hashing rules for 2806*ebfedea0SLionel Sambuc modification detection include a one-octet tag and one-octet length 2807*ebfedea0SLionel Sambuc in the data hash. While this is a bit restrictive, it reduces 2808*ebfedea0SLionel Sambuc complexity. 2809*ebfedea0SLionel Sambuc 2810*ebfedea0SLionel Sambuc6. Radix-64 Conversions 2811*ebfedea0SLionel Sambuc 2812*ebfedea0SLionel Sambuc As stated in the introduction, OpenPGP's underlying native 2813*ebfedea0SLionel Sambuc representation for objects is a stream of arbitrary octets, and some 2814*ebfedea0SLionel Sambuc systems desire these objects to be immune to damage caused by 2815*ebfedea0SLionel Sambuc character set translation, data conversions, etc. 2816*ebfedea0SLionel Sambuc 2817*ebfedea0SLionel Sambuc In principle, any printable encoding scheme that met the 2818*ebfedea0SLionel Sambuc requirements of the unsafe channel would suffice, since it would not 2819*ebfedea0SLionel Sambuc change the underlying binary bit streams of the native OpenPGP data 2820*ebfedea0SLionel Sambuc structures. The OpenPGP standard specifies one such printable 2821*ebfedea0SLionel Sambuc encoding scheme to ensure interoperability. 2822*ebfedea0SLionel Sambuc 2823*ebfedea0SLionel Sambuc OpenPGP's Radix-64 encoding is composed of two parts: a base64 2824*ebfedea0SLionel Sambuc encoding of the binary data, and a checksum. The base64 encoding is 2825*ebfedea0SLionel Sambuc identical to the MIME base64 content-transfer-encoding [RFC2045]. 2826*ebfedea0SLionel Sambuc 2827*ebfedea0SLionel Sambuc The checksum is a 24-bit CRC converted to four characters of 2828*ebfedea0SLionel Sambuc radix-64 encoding by the same MIME base64 transformation, preceded 2829*ebfedea0SLionel Sambuc by an equals sign (=). The CRC is computed by using the generator 2830*ebfedea0SLionel Sambuc 0x864CFB and an initialization of 0xB704CE. The accumulation is done 2831*ebfedea0SLionel Sambuc on the data before it is converted to radix-64, rather than on the 2832*ebfedea0SLionel Sambuc converted data. A sample implementation of this algorithm is in the 2833*ebfedea0SLionel Sambuc next section. 2834*ebfedea0SLionel Sambuc 2835*ebfedea0SLionel Sambuc The checksum with its leading equal sign MAY appear on the first 2836*ebfedea0SLionel Sambuc line after the Base64 encoded data. 2837*ebfedea0SLionel Sambuc 2838*ebfedea0SLionel Sambuc Rationale for CRC-24: The size of 24 bits fits evenly into printable 2839*ebfedea0SLionel Sambuc base64. The nonzero initialization can detect more errors than a 2840*ebfedea0SLionel Sambuc zero initialization. 2841*ebfedea0SLionel Sambuc 2842*ebfedea0SLionel Sambuc6.1. An Implementation of the CRC-24 in "C" 2843*ebfedea0SLionel Sambuc 2844*ebfedea0SLionel Sambuc #define CRC24_INIT 0xb704ceL 2845*ebfedea0SLionel Sambuc #define CRC24_POLY 0x1864cfbL 2846*ebfedea0SLionel Sambuc 2847*ebfedea0SLionel Sambuc typedef long crc24; 2848*ebfedea0SLionel Sambuc crc24 crc_octets(unsigned char *octets, size_t len) 2849*ebfedea0SLionel Sambuc { 2850*ebfedea0SLionel Sambuc crc24 crc = CRC24_INIT; 2851*ebfedea0SLionel Sambuc int i; 2852*ebfedea0SLionel Sambuc 2853*ebfedea0SLionel Sambuc 2854*ebfedea0SLionel Sambuc 2855*ebfedea0SLionel Sambuc 2856*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 51] 2857*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2858*ebfedea0SLionel Sambuc 2859*ebfedea0SLionel Sambuc while (len--) { 2860*ebfedea0SLionel Sambuc crc ^= (*octets++) << 16; 2861*ebfedea0SLionel Sambuc for (i = 0; i < 8; i++) { 2862*ebfedea0SLionel Sambuc crc <<= 1; 2863*ebfedea0SLionel Sambuc if (crc & 0x1000000) 2864*ebfedea0SLionel Sambuc crc ^= CRC24_POLY; 2865*ebfedea0SLionel Sambuc } 2866*ebfedea0SLionel Sambuc } 2867*ebfedea0SLionel Sambuc return crc & 0xffffffL; 2868*ebfedea0SLionel Sambuc } 2869*ebfedea0SLionel Sambuc 2870*ebfedea0SLionel Sambuc6.2. Forming ASCII Armor 2871*ebfedea0SLionel Sambuc 2872*ebfedea0SLionel Sambuc When OpenPGP encodes data into ASCII Armor, it puts specific headers 2873*ebfedea0SLionel Sambuc around the Radix-64 encoded data, so OpenPGP can reconstruct the 2874*ebfedea0SLionel Sambuc data later. An OpenPGP implementation MAY use ASCII armor to protect 2875*ebfedea0SLionel Sambuc raw binary data. OpenPGP informs the user what kind of data is 2876*ebfedea0SLionel Sambuc encoded in the ASCII armor through the use of the headers. 2877*ebfedea0SLionel Sambuc 2878*ebfedea0SLionel Sambuc Concatenating the following data creates ASCII Armor: 2879*ebfedea0SLionel Sambuc 2880*ebfedea0SLionel Sambuc - An Armor Header Line, appropriate for the type of data 2881*ebfedea0SLionel Sambuc 2882*ebfedea0SLionel Sambuc - Armor Headers 2883*ebfedea0SLionel Sambuc 2884*ebfedea0SLionel Sambuc - A blank (zero-length, or containing only whitespace) line 2885*ebfedea0SLionel Sambuc 2886*ebfedea0SLionel Sambuc - The ASCII-Armored data 2887*ebfedea0SLionel Sambuc 2888*ebfedea0SLionel Sambuc - An Armor Checksum 2889*ebfedea0SLionel Sambuc 2890*ebfedea0SLionel Sambuc - The Armor Tail, which depends on the Armor Header Line. 2891*ebfedea0SLionel Sambuc 2892*ebfedea0SLionel Sambuc An Armor Header Line consists of the appropriate header line text 2893*ebfedea0SLionel Sambuc surrounded by five (5) dashes ('-', 0x2D) on either side of the 2894*ebfedea0SLionel Sambuc header line text. The header line text is chosen based upon the type 2895*ebfedea0SLionel Sambuc of data that is being encoded in Armor, and how it is being encoded. 2896*ebfedea0SLionel Sambuc Header line texts include the following strings: 2897*ebfedea0SLionel Sambuc 2898*ebfedea0SLionel Sambuc BEGIN PGP MESSAGE 2899*ebfedea0SLionel Sambuc Used for signed, encrypted, or compressed files. 2900*ebfedea0SLionel Sambuc 2901*ebfedea0SLionel Sambuc BEGIN PGP PUBLIC KEY BLOCK 2902*ebfedea0SLionel Sambuc Used for armoring public keys 2903*ebfedea0SLionel Sambuc 2904*ebfedea0SLionel Sambuc BEGIN PGP PRIVATE KEY BLOCK 2905*ebfedea0SLionel Sambuc Used for armoring private keys 2906*ebfedea0SLionel Sambuc 2907*ebfedea0SLionel Sambuc BEGIN PGP MESSAGE, PART X/Y 2908*ebfedea0SLionel Sambuc Used for multi-part messages, where the armor is split amongst Y 2909*ebfedea0SLionel Sambuc parts, and this is the Xth part out of Y. 2910*ebfedea0SLionel Sambuc 2911*ebfedea0SLionel Sambuc 2912*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 52] 2913*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2914*ebfedea0SLionel Sambuc 2915*ebfedea0SLionel Sambuc BEGIN PGP MESSAGE, PART X 2916*ebfedea0SLionel Sambuc Used for multi-part messages, where this is the Xth part of an 2917*ebfedea0SLionel Sambuc unspecified number of parts. Requires the MESSAGE-ID Armor 2918*ebfedea0SLionel Sambuc Header to be used. 2919*ebfedea0SLionel Sambuc 2920*ebfedea0SLionel Sambuc BEGIN PGP SIGNATURE 2921*ebfedea0SLionel Sambuc Used for detached signatures, OpenPGP/MIME signatures, and 2922*ebfedea0SLionel Sambuc cleartext signatures. Note that PGP 2.x uses BEGIN PGP MESSAGE 2923*ebfedea0SLionel Sambuc for detached signatures. 2924*ebfedea0SLionel Sambuc 2925*ebfedea0SLionel Sambuc Note that all these Armor Header Lines are to consist of a complete 2926*ebfedea0SLionel Sambuc line. That is to say, there is always a line ending preceding the 2927*ebfedea0SLionel Sambuc starting five dashes, and following the ending five dashes. The 2928*ebfedea0SLionel Sambuc header lines, therefore, MUST start at the beginning of a line, and 2929*ebfedea0SLionel Sambuc MUST NOT have text other than whitespace following them on the same 2930*ebfedea0SLionel Sambuc line. These line endings are considered a part of the Armor Header 2931*ebfedea0SLionel Sambuc Line for the purposes of determining the content they delimit. This 2932*ebfedea0SLionel Sambuc is particularly important when computing a cleartext signature (see 2933*ebfedea0SLionel Sambuc below). 2934*ebfedea0SLionel Sambuc 2935*ebfedea0SLionel Sambuc The Armor Headers are pairs of strings that can give the user or the 2936*ebfedea0SLionel Sambuc receiving OpenPGP implementation some information about how to 2937*ebfedea0SLionel Sambuc decode or use the message. The Armor Headers are a part of the 2938*ebfedea0SLionel Sambuc armor, not a part of the message, and hence are not protected by any 2939*ebfedea0SLionel Sambuc signatures applied to the message. 2940*ebfedea0SLionel Sambuc 2941*ebfedea0SLionel Sambuc The format of an Armor Header is that of a key-value pair. A colon 2942*ebfedea0SLionel Sambuc (':' 0x38) and a single space (0x20) separate the key and value. 2943*ebfedea0SLionel Sambuc OpenPGP should consider improperly formatted Armor Headers to be 2944*ebfedea0SLionel Sambuc corruption of the ASCII Armor. Unknown keys should be reported to 2945*ebfedea0SLionel Sambuc the user, but OpenPGP should continue to process the message. 2946*ebfedea0SLionel Sambuc 2947*ebfedea0SLionel Sambuc Note that some transport methods are sensitive to line length. While 2948*ebfedea0SLionel Sambuc there is a limit of 76 characters for the Radix-64 data (section 2949*ebfedea0SLionel Sambuc 6.3), there is no limit to the length of Armor Headers. Care should 2950*ebfedea0SLionel Sambuc be taken that the Armor Headers are short enough to survive 2951*ebfedea0SLionel Sambuc transport. One way to do this is to repeat an Armor Header key 2952*ebfedea0SLionel Sambuc multiple times with different values for each so that no one line is 2953*ebfedea0SLionel Sambuc overly long. 2954*ebfedea0SLionel Sambuc 2955*ebfedea0SLionel Sambuc Currently defined Armor Header Keys are: 2956*ebfedea0SLionel Sambuc 2957*ebfedea0SLionel Sambuc - "Version", that states the OpenPGP implementation and version 2958*ebfedea0SLionel Sambuc used to encode the message. 2959*ebfedea0SLionel Sambuc 2960*ebfedea0SLionel Sambuc - "Comment", a user-defined comment. OpenPGP defines all text to 2961*ebfedea0SLionel Sambuc be in UTF-8. A comment may be any UTF-8 string. However, the 2962*ebfedea0SLionel Sambuc whole point of armoring is to provide seven-bit-clean data. 2963*ebfedea0SLionel Sambuc Consequently, if a comment has characters that are outside the 2964*ebfedea0SLionel Sambuc US-ASCII range of UTF, they may very well not survive transport. 2965*ebfedea0SLionel Sambuc 2966*ebfedea0SLionel Sambuc 2967*ebfedea0SLionel Sambuc 2968*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 53] 2969*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 2970*ebfedea0SLionel Sambuc 2971*ebfedea0SLionel Sambuc - "MessageID", a 32-character string of printable characters. The 2972*ebfedea0SLionel Sambuc string must be the same for all parts of a multi-part message 2973*ebfedea0SLionel Sambuc that uses the "PART X" Armor Header. MessageID strings should be 2974*ebfedea0SLionel Sambuc unique enough that the recipient of the mail can associate all 2975*ebfedea0SLionel Sambuc the parts of a message with each other. A good checksum or 2976*ebfedea0SLionel Sambuc cryptographic hash function is sufficient. 2977*ebfedea0SLionel Sambuc 2978*ebfedea0SLionel Sambuc The MessageID SHOULD NOT appear unless it is in a multi-part 2979*ebfedea0SLionel Sambuc message. If it appears at all, it MUST be computed from the 2980*ebfedea0SLionel Sambuc finished (encrypted, signed, etc.) message in a deterministic 2981*ebfedea0SLionel Sambuc fashion, rather than contain a purely random value. This is to 2982*ebfedea0SLionel Sambuc allow the legitimate recipient to determine that the MessageID 2983*ebfedea0SLionel Sambuc cannot serve as a covert means of leaking cryptographic key 2984*ebfedea0SLionel Sambuc information. 2985*ebfedea0SLionel Sambuc 2986*ebfedea0SLionel Sambuc - "Hash", a comma-separated list of hash algorithms used in this 2987*ebfedea0SLionel Sambuc message. This is used only in cleartext signed messages. 2988*ebfedea0SLionel Sambuc 2989*ebfedea0SLionel Sambuc - "Charset", a description of the character set that the plaintext 2990*ebfedea0SLionel Sambuc is in. Please note that OpenPGP defines text to be in UTF-8. An 2991*ebfedea0SLionel Sambuc implementation will get best results by translating into and out 2992*ebfedea0SLionel Sambuc of UTF-8. However, there are many instances where this is easier 2993*ebfedea0SLionel Sambuc said than done. Also, there are communities of users who have no 2994*ebfedea0SLionel Sambuc need for UTF-8 because they are all happy with a character set 2995*ebfedea0SLionel Sambuc like ISO Latin-5 or a Japanese character set. In such instances, 2996*ebfedea0SLionel Sambuc an implementation MAY override the UTF-8 default by using this 2997*ebfedea0SLionel Sambuc header key. An implementation MAY implement this key and any 2998*ebfedea0SLionel Sambuc translations it cares to; an implementation MAY ignore it and 2999*ebfedea0SLionel Sambuc assume all text is UTF-8. 3000*ebfedea0SLionel Sambuc 3001*ebfedea0SLionel Sambuc The Armor Tail Line is composed in the same manner as the Armor 3002*ebfedea0SLionel Sambuc Header Line, except the string "BEGIN" is replaced by the string 3003*ebfedea0SLionel Sambuc "END". 3004*ebfedea0SLionel Sambuc 3005*ebfedea0SLionel Sambuc6.3. Encoding Binary in Radix-64 3006*ebfedea0SLionel Sambuc 3007*ebfedea0SLionel Sambuc The encoding process represents 24-bit groups of input bits as 3008*ebfedea0SLionel Sambuc output strings of 4 encoded characters. Proceeding from left to 3009*ebfedea0SLionel Sambuc right, a 24-bit input group is formed by concatenating three 8-bit 3010*ebfedea0SLionel Sambuc input groups. These 24 bits are then treated as four concatenated 3011*ebfedea0SLionel Sambuc 6-bit groups, each of which is translated into a single digit in the 3012*ebfedea0SLionel Sambuc Radix-64 alphabet. When encoding a bit stream with the Radix-64 3013*ebfedea0SLionel Sambuc encoding, the bit stream must be presumed to be ordered with the 3014*ebfedea0SLionel Sambuc most-significant-bit first. That is, the first bit in the stream 3015*ebfedea0SLionel Sambuc will be the high-order bit in the first 8-bit octet, and the eighth 3016*ebfedea0SLionel Sambuc bit will be the low-order bit in the first 8-bit octet, and so on. 3017*ebfedea0SLionel Sambuc 3018*ebfedea0SLionel Sambuc +--first octet--+-second octet--+--third octet--+ 3019*ebfedea0SLionel Sambuc |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| 3020*ebfedea0SLionel Sambuc +-----------+---+-------+-------+---+-----------+ 3021*ebfedea0SLionel Sambuc |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| 3022*ebfedea0SLionel Sambuc +--1.index--+--2.index--+--3.index--+--4.index--+ 3023*ebfedea0SLionel Sambuc 3024*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 54] 3025*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3026*ebfedea0SLionel Sambuc 3027*ebfedea0SLionel Sambuc Each 6-bit group is used as an index into an array of 64 printable 3028*ebfedea0SLionel Sambuc characters from the table below. The character referenced by the 3029*ebfedea0SLionel Sambuc index is placed in the output string. 3030*ebfedea0SLionel Sambuc 3031*ebfedea0SLionel Sambuc Value Encoding Value Encoding Value Encoding Value Encoding 3032*ebfedea0SLionel Sambuc 0 A 17 R 34 i 51 z 3033*ebfedea0SLionel Sambuc 1 B 18 S 35 j 52 0 3034*ebfedea0SLionel Sambuc 2 C 19 T 36 k 53 1 3035*ebfedea0SLionel Sambuc 3 D 20 U 37 l 54 2 3036*ebfedea0SLionel Sambuc 4 E 21 V 38 m 55 3 3037*ebfedea0SLionel Sambuc 5 F 22 W 39 n 56 4 3038*ebfedea0SLionel Sambuc 6 G 23 X 40 o 57 5 3039*ebfedea0SLionel Sambuc 7 H 24 Y 41 p 58 6 3040*ebfedea0SLionel Sambuc 8 I 25 Z 42 q 59 7 3041*ebfedea0SLionel Sambuc 9 J 26 a 43 r 60 8 3042*ebfedea0SLionel Sambuc 10 K 27 b 44 s 61 9 3043*ebfedea0SLionel Sambuc 11 L 28 c 45 t 62 + 3044*ebfedea0SLionel Sambuc 12 M 29 d 46 u 63 / 3045*ebfedea0SLionel Sambuc 13 N 30 e 47 v 3046*ebfedea0SLionel Sambuc 14 O 31 f 48 w (pad) = 3047*ebfedea0SLionel Sambuc 15 P 32 g 49 x 3048*ebfedea0SLionel Sambuc 16 Q 33 h 50 y 3049*ebfedea0SLionel Sambuc 3050*ebfedea0SLionel Sambuc The encoded output stream must be represented in lines of no more 3051*ebfedea0SLionel Sambuc than 76 characters each. 3052*ebfedea0SLionel Sambuc 3053*ebfedea0SLionel Sambuc Special processing is performed if fewer than 24 bits are available 3054*ebfedea0SLionel Sambuc at the end of the data being encoded. There are three possibilities: 3055*ebfedea0SLionel Sambuc 3056*ebfedea0SLionel Sambuc 1. The last data group has 24 bits (3 octets). No special 3057*ebfedea0SLionel Sambuc processing is needed. 3058*ebfedea0SLionel Sambuc 3059*ebfedea0SLionel Sambuc 2. The last data group has 16 bits (2 octets). The first two 6-bit 3060*ebfedea0SLionel Sambuc groups are processed as above. The third (incomplete) data group 3061*ebfedea0SLionel Sambuc has two zero-value bits added to it, and is processed as above. 3062*ebfedea0SLionel Sambuc A pad character (=) is added to the output. 3063*ebfedea0SLionel Sambuc 3064*ebfedea0SLionel Sambuc 3. The last data group has 8 bits (1 octet). The first 6-bit group 3065*ebfedea0SLionel Sambuc is processed as above. The second (incomplete) data group has 3066*ebfedea0SLionel Sambuc four zero-value bits added to it, and is processed as above. Two 3067*ebfedea0SLionel Sambuc pad characters (=) are added to the output. 3068*ebfedea0SLionel Sambuc 3069*ebfedea0SLionel Sambuc6.4. Decoding Radix-64 3070*ebfedea0SLionel Sambuc 3071*ebfedea0SLionel Sambuc In Radix-64 data, characters other than those in the table, line 3072*ebfedea0SLionel Sambuc breaks, and other white space probably indicate a transmission 3073*ebfedea0SLionel Sambuc error, about which a warning message or even a message rejection 3074*ebfedea0SLionel Sambuc might be appropriate under some circumstances. Decoding software 3075*ebfedea0SLionel Sambuc must ignore all white space. 3076*ebfedea0SLionel Sambuc 3077*ebfedea0SLionel Sambuc 3078*ebfedea0SLionel Sambuc 3079*ebfedea0SLionel Sambuc 3080*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 55] 3081*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3082*ebfedea0SLionel Sambuc 3083*ebfedea0SLionel Sambuc Because it is used only for padding at the end of the data, the 3084*ebfedea0SLionel Sambuc occurrence of any "=" characters may be taken as evidence that the 3085*ebfedea0SLionel Sambuc end of the data has been reached (without truncation in transit). No 3086*ebfedea0SLionel Sambuc such assurance is possible, however, when the number of octets 3087*ebfedea0SLionel Sambuc transmitted was a multiple of three and no "=" characters are 3088*ebfedea0SLionel Sambuc present. 3089*ebfedea0SLionel Sambuc 3090*ebfedea0SLionel Sambuc6.5. Examples of Radix-64 3091*ebfedea0SLionel Sambuc 3092*ebfedea0SLionel Sambuc Input data: 0x14fb9c03d97e 3093*ebfedea0SLionel Sambuc Hex: 1 4 f b 9 c | 0 3 d 9 7 e 3094*ebfedea0SLionel Sambuc 8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110 3095*ebfedea0SLionel Sambuc 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110 3096*ebfedea0SLionel Sambuc Decimal: 5 15 46 28 0 61 37 62 3097*ebfedea0SLionel Sambuc Output: F P u c A 9 l + 3098*ebfedea0SLionel Sambuc Input data: 0x14fb9c03d9 3099*ebfedea0SLionel Sambuc Hex: 1 4 f b 9 c | 0 3 d 9 3100*ebfedea0SLionel Sambuc 8-bit: 00010100 11111011 10011100 | 00000011 11011001 3101*ebfedea0SLionel Sambuc pad with 00 3102*ebfedea0SLionel Sambuc 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 3103*ebfedea0SLionel Sambuc Decimal: 5 15 46 28 0 61 36 3104*ebfedea0SLionel Sambuc pad with = 3105*ebfedea0SLionel Sambuc Output: F P u c A 9 k = 3106*ebfedea0SLionel Sambuc Input data: 0x14fb9c03 3107*ebfedea0SLionel Sambuc Hex: 1 4 f b 9 c | 0 3 3108*ebfedea0SLionel Sambuc 8-bit: 00010100 11111011 10011100 | 00000011 3109*ebfedea0SLionel Sambuc pad with 0000 3110*ebfedea0SLionel Sambuc 6-bit: 000101 001111 101110 011100 | 000000 110000 3111*ebfedea0SLionel Sambuc Decimal: 5 15 46 28 0 48 3112*ebfedea0SLionel Sambuc pad with = = 3113*ebfedea0SLionel Sambuc Output: F P u c A w = = 3114*ebfedea0SLionel Sambuc 3115*ebfedea0SLionel Sambuc6.6. Example of an ASCII Armored Message 3116*ebfedea0SLionel Sambuc 3117*ebfedea0SLionel Sambuc -----BEGIN PGP MESSAGE----- 3118*ebfedea0SLionel Sambuc Version: OpenPrivacy 0.99 3119*ebfedea0SLionel Sambuc 3120*ebfedea0SLionel Sambuc yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS 3121*ebfedea0SLionel Sambuc vBSFjNSiVHsuAA== 3122*ebfedea0SLionel Sambuc =njUN 3123*ebfedea0SLionel Sambuc -----END PGP MESSAGE----- 3124*ebfedea0SLionel Sambuc 3125*ebfedea0SLionel Sambuc Note that this example has extra indenting; an actual armored 3126*ebfedea0SLionel Sambuc message would have no leading whitespace. 3127*ebfedea0SLionel Sambuc 3128*ebfedea0SLionel Sambuc7. Cleartext signature framework 3129*ebfedea0SLionel Sambuc 3130*ebfedea0SLionel Sambuc It is desirable to be able to sign a textual octet stream without 3131*ebfedea0SLionel Sambuc ASCII armoring the stream itself, so the signed text is still 3132*ebfedea0SLionel Sambuc readable without special software. In order to bind a signature to 3133*ebfedea0SLionel Sambuc such a cleartext, this framework is used. (Note that this framework 3134*ebfedea0SLionel Sambuc is not intended to be reversible. RFC 3156 defines another way to 3135*ebfedea0SLionel Sambuc 3136*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 56] 3137*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3138*ebfedea0SLionel Sambuc 3139*ebfedea0SLionel Sambuc sign cleartext messages for environments that support MIME.) 3140*ebfedea0SLionel Sambuc 3141*ebfedea0SLionel Sambuc The cleartext signed message consists of: 3142*ebfedea0SLionel Sambuc 3143*ebfedea0SLionel Sambuc - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a 3144*ebfedea0SLionel Sambuc single line, 3145*ebfedea0SLionel Sambuc 3146*ebfedea0SLionel Sambuc - One or more "Hash" Armor Headers, 3147*ebfedea0SLionel Sambuc 3148*ebfedea0SLionel Sambuc - Exactly one empty line not included into the message digest, 3149*ebfedea0SLionel Sambuc 3150*ebfedea0SLionel Sambuc - The dash-escaped cleartext that is included into the message 3151*ebfedea0SLionel Sambuc digest, 3152*ebfedea0SLionel Sambuc 3153*ebfedea0SLionel Sambuc - The ASCII armored signature(s) including the '-----BEGIN PGP 3154*ebfedea0SLionel Sambuc SIGNATURE-----' Armor Header and Armor Tail Lines. 3155*ebfedea0SLionel Sambuc 3156*ebfedea0SLionel Sambuc If the "Hash" armor header is given, the specified message digest 3157*ebfedea0SLionel Sambuc algorithm(s) are used for the signature. If there are no such 3158*ebfedea0SLionel Sambuc headers, MD5 is used. If MD5 is the only hash used, then an 3159*ebfedea0SLionel Sambuc implementation MAY omit this header for improved V2.x compatibility. 3160*ebfedea0SLionel Sambuc If more than one message digest is used in the signature, the "Hash" 3161*ebfedea0SLionel Sambuc armor header contains a comma-delimited list of used message 3162*ebfedea0SLionel Sambuc digests. 3163*ebfedea0SLionel Sambuc 3164*ebfedea0SLionel Sambuc Current message digest names are described below with the algorithm 3165*ebfedea0SLionel Sambuc IDs. 3166*ebfedea0SLionel Sambuc 3167*ebfedea0SLionel Sambuc An implementation SHOULD add a line break after the cleartext, but 3168*ebfedea0SLionel Sambuc MAY omit it if the cleartext ends with a line break. This is for 3169*ebfedea0SLionel Sambuc visual clarity. 3170*ebfedea0SLionel Sambuc 3171*ebfedea0SLionel Sambuc7.1. Dash-Escaped Text 3172*ebfedea0SLionel Sambuc 3173*ebfedea0SLionel Sambuc The cleartext content of the message must also be dash-escaped. 3174*ebfedea0SLionel Sambuc 3175*ebfedea0SLionel Sambuc Dash escaped cleartext is the ordinary cleartext where every line 3176*ebfedea0SLionel Sambuc starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' 3177*ebfedea0SLionel Sambuc (0x2D) and space ' ' (0x20). This prevents the parser from 3178*ebfedea0SLionel Sambuc recognizing armor headers of the cleartext itself. An implementation 3179*ebfedea0SLionel Sambuc MAY dash escape any line, SHOULD dash escape lines commencing "From" 3180*ebfedea0SLionel Sambuc followed by a space, and MUST dash escape any line commencing in a 3181*ebfedea0SLionel Sambuc dash. The message digest is computed using the cleartext itself, not 3182*ebfedea0SLionel Sambuc the dash escaped form. 3183*ebfedea0SLionel Sambuc 3184*ebfedea0SLionel Sambuc As with binary signatures on text documents, a cleartext signature 3185*ebfedea0SLionel Sambuc is calculated on the text using canonical <CR><LF> line endings. The 3186*ebfedea0SLionel Sambuc line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP 3187*ebfedea0SLionel Sambuc SIGNATURE-----' line that terminates the signed text is not 3188*ebfedea0SLionel Sambuc considered part of the signed text. 3189*ebfedea0SLionel Sambuc 3190*ebfedea0SLionel Sambuc 3191*ebfedea0SLionel Sambuc 3192*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 57] 3193*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3194*ebfedea0SLionel Sambuc 3195*ebfedea0SLionel Sambuc When reversing dash-escaping, an implementation MUST strip the 3196*ebfedea0SLionel Sambuc string "- " if it occurs at the beginning of a line, and SHOULD warn 3197*ebfedea0SLionel Sambuc on "-" and any character other than a space at the beginning of a 3198*ebfedea0SLionel Sambuc line. 3199*ebfedea0SLionel Sambuc 3200*ebfedea0SLionel Sambuc Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at 3201*ebfedea0SLionel Sambuc the end of any line is removed when the cleartext signature is 3202*ebfedea0SLionel Sambuc generated. 3203*ebfedea0SLionel Sambuc 3204*ebfedea0SLionel Sambuc8. Regular Expressions 3205*ebfedea0SLionel Sambuc 3206*ebfedea0SLionel Sambuc A regular expression is zero or more branches, separated by '|'. It 3207*ebfedea0SLionel Sambuc matches anything that matches one of the branches. 3208*ebfedea0SLionel Sambuc 3209*ebfedea0SLionel Sambuc A branch is zero or more pieces, concatenated. It matches a match 3210*ebfedea0SLionel Sambuc for the first, followed by a match for the second, etc. 3211*ebfedea0SLionel Sambuc 3212*ebfedea0SLionel Sambuc A piece is an atom possibly followed by '*', '+', or '?'. An atom 3213*ebfedea0SLionel Sambuc followed by '*' matches a sequence of 0 or more matches of the atom. 3214*ebfedea0SLionel Sambuc An atom followed by '+' matches a sequence of 1 or more matches of 3215*ebfedea0SLionel Sambuc the atom. An atom followed by '?' matches a match of the atom, or 3216*ebfedea0SLionel Sambuc the null string. 3217*ebfedea0SLionel Sambuc 3218*ebfedea0SLionel Sambuc An atom is a regular expression in parentheses (matching a match for 3219*ebfedea0SLionel Sambuc the regular expression), a range (see below), '.' (matching any 3220*ebfedea0SLionel Sambuc single character), '^' (matching the null string at the beginning of 3221*ebfedea0SLionel Sambuc the input string), '$' (matching the null string at the end of the 3222*ebfedea0SLionel Sambuc input string), a '\' followed by a single character (matching that 3223*ebfedea0SLionel Sambuc character), or a single character with no other significance 3224*ebfedea0SLionel Sambuc (matching that character). 3225*ebfedea0SLionel Sambuc 3226*ebfedea0SLionel Sambuc A range is a sequence of characters enclosed in '[]'. It normally 3227*ebfedea0SLionel Sambuc matches any single character from the sequence. If the sequence 3228*ebfedea0SLionel Sambuc begins with '^', it matches any single character not from the rest 3229*ebfedea0SLionel Sambuc of the sequence. If two characters in the sequence are separated by 3230*ebfedea0SLionel Sambuc '-', this is shorthand for the full list of ASCII characters between 3231*ebfedea0SLionel Sambuc them (e.g. '[0-9]' matches any decimal digit). To include a literal 3232*ebfedea0SLionel Sambuc ']' in the sequence, make it the first character (following a 3233*ebfedea0SLionel Sambuc possible '^'). To include a literal '-', make it the first or last 3234*ebfedea0SLionel Sambuc character. 3235*ebfedea0SLionel Sambuc 3236*ebfedea0SLionel Sambuc9. Constants 3237*ebfedea0SLionel Sambuc 3238*ebfedea0SLionel Sambuc This section describes the constants used in OpenPGP. 3239*ebfedea0SLionel Sambuc 3240*ebfedea0SLionel Sambuc Note that these tables are not exhaustive lists; an implementation 3241*ebfedea0SLionel Sambuc MAY implement an algorithm not on these lists, so long as the 3242*ebfedea0SLionel Sambuc algorithm number(s) are chosen from the private or experimental 3243*ebfedea0SLionel Sambuc algorithm range. 3244*ebfedea0SLionel Sambuc 3245*ebfedea0SLionel Sambuc 3246*ebfedea0SLionel Sambuc 3247*ebfedea0SLionel Sambuc 3248*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 58] 3249*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3250*ebfedea0SLionel Sambuc 3251*ebfedea0SLionel Sambuc See the section "Notes on Algorithms" below for more discussion of 3252*ebfedea0SLionel Sambuc the algorithms. 3253*ebfedea0SLionel Sambuc 3254*ebfedea0SLionel Sambuc9.1. Public Key Algorithms 3255*ebfedea0SLionel Sambuc 3256*ebfedea0SLionel Sambuc ID Algorithm 3257*ebfedea0SLionel Sambuc -- --------- 3258*ebfedea0SLionel Sambuc 1 - RSA (Encrypt or Sign) [HAC] 3259*ebfedea0SLionel Sambuc 2 - RSA Encrypt-Only [HAC] 3260*ebfedea0SLionel Sambuc 3 - RSA Sign-Only [HAC] 3261*ebfedea0SLionel Sambuc 16 - Elgamal (Encrypt-Only), see [ELGAMAL] [HAC] 3262*ebfedea0SLionel Sambuc 17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC] 3263*ebfedea0SLionel Sambuc 18 - Reserved for Elliptic Curve 3264*ebfedea0SLionel Sambuc 19 - Reserved for ECDSA 3265*ebfedea0SLionel Sambuc 20 - Reserved (formerly Elgamal Encrypt or Sign) 3266*ebfedea0SLionel Sambuc 21 - Reserved for Diffie-Hellman (X9.42, 3267*ebfedea0SLionel Sambuc as defined for IETF-S/MIME) 3268*ebfedea0SLionel Sambuc 100 to 110 - Private/Experimental algorithm. 3269*ebfedea0SLionel Sambuc 3270*ebfedea0SLionel Sambuc Implementations MUST implement DSA for signatures, and Elgamal for 3271*ebfedea0SLionel Sambuc encryption. Implementations SHOULD implement RSA keys (1). RSA 3272*ebfedea0SLionel Sambuc Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be 3273*ebfedea0SLionel Sambuc generated, but may be interpreted. See Section 13.5. See Section 3274*ebfedea0SLionel Sambuc 13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt 3275*ebfedea0SLionel Sambuc or Sign (20), and X9.42 (21). Implementations MAY implement any 3276*ebfedea0SLionel Sambuc other algorithm. 3277*ebfedea0SLionel Sambuc 3278*ebfedea0SLionel Sambuc9.2. Symmetric Key Algorithms 3279*ebfedea0SLionel Sambuc 3280*ebfedea0SLionel Sambuc ID Algorithm 3281*ebfedea0SLionel Sambuc -- --------- 3282*ebfedea0SLionel Sambuc 0 - Plaintext or unencrypted data 3283*ebfedea0SLionel Sambuc 1 - IDEA [IDEA] 3284*ebfedea0SLionel Sambuc 2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] - 3285*ebfedea0SLionel Sambuc 168 bit key derived from 192) 3286*ebfedea0SLionel Sambuc 3 - CAST5 (128 bit key, as per RFC 2144) 3287*ebfedea0SLionel Sambuc 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] 3288*ebfedea0SLionel Sambuc 5 - Reserved 3289*ebfedea0SLionel Sambuc 6 - Reserved 3290*ebfedea0SLionel Sambuc 7 - AES with 128-bit key [AES] 3291*ebfedea0SLionel Sambuc 8 - AES with 192-bit key 3292*ebfedea0SLionel Sambuc 9 - AES with 256-bit key 3293*ebfedea0SLionel Sambuc 10 - Twofish with 256-bit key [TWOFISH] 3294*ebfedea0SLionel Sambuc 100 to 110 - Private/Experimental algorithm. 3295*ebfedea0SLionel Sambuc 3296*ebfedea0SLionel Sambuc Implementations MUST implement TripleDES. Implementations SHOULD 3297*ebfedea0SLionel Sambuc implement AES-128 and CAST5. Implementations that interoperate with 3298*ebfedea0SLionel Sambuc PGP 2.6 or earlier need to support IDEA, as that is the only 3299*ebfedea0SLionel Sambuc symmetric cipher those versions use. Implementations MAY implement 3300*ebfedea0SLionel Sambuc any other algorithm. 3301*ebfedea0SLionel Sambuc 3302*ebfedea0SLionel Sambuc 3303*ebfedea0SLionel Sambuc 3304*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 59] 3305*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3306*ebfedea0SLionel Sambuc 3307*ebfedea0SLionel Sambuc9.3. Compression Algorithms 3308*ebfedea0SLionel Sambuc 3309*ebfedea0SLionel Sambuc ID Algorithm 3310*ebfedea0SLionel Sambuc -- --------- 3311*ebfedea0SLionel Sambuc 0 - Uncompressed 3312*ebfedea0SLionel Sambuc 1 - ZIP [RFC 1951] 3313*ebfedea0SLionel Sambuc 2 - ZLIB [RFC 1950] 3314*ebfedea0SLionel Sambuc 3 - BZip2 [BZ2] 3315*ebfedea0SLionel Sambuc 100 to 110 - Private/Experimental algorithm. 3316*ebfedea0SLionel Sambuc 3317*ebfedea0SLionel Sambuc Implementations MUST implement uncompressed data. Implementations 3318*ebfedea0SLionel Sambuc SHOULD implement ZIP. Implementations MAY implement any other 3319*ebfedea0SLionel Sambuc algorithm. 3320*ebfedea0SLionel Sambuc 3321*ebfedea0SLionel Sambuc9.4. Hash Algorithms 3322*ebfedea0SLionel Sambuc 3323*ebfedea0SLionel Sambuc ID Algorithm Text Name 3324*ebfedea0SLionel Sambuc -- --------- ---- ---- 3325*ebfedea0SLionel Sambuc 1 - MD5 [HAC] "MD5" 3326*ebfedea0SLionel Sambuc 2 - SHA-1 [FIPS180] "SHA1" 3327*ebfedea0SLionel Sambuc 3 - RIPE-MD/160 [HAC] "RIPEMD160" 3328*ebfedea0SLionel Sambuc 4 - Reserved 3329*ebfedea0SLionel Sambuc 5 - Reserved 3330*ebfedea0SLionel Sambuc 6 - Reserved 3331*ebfedea0SLionel Sambuc 7 - Reserved 3332*ebfedea0SLionel Sambuc 8 - SHA256 [FIPS180] "SHA256" 3333*ebfedea0SLionel Sambuc 9 - SHA384 [FIPS180] "SHA384" 3334*ebfedea0SLionel Sambuc 10 - SHA512 [FIPS180] "SHA512" 3335*ebfedea0SLionel Sambuc 11 - SHA224 [FIPS180] "SHA224" 3336*ebfedea0SLionel Sambuc 100 to 110 - Private/Experimental algorithm. 3337*ebfedea0SLionel Sambuc 3338*ebfedea0SLionel Sambuc Implementations MUST implement SHA-1. Implementations MAY implement 3339*ebfedea0SLionel Sambuc other algorithms. MD5 is deprecated. 3340*ebfedea0SLionel Sambuc 3341*ebfedea0SLionel Sambuc10. IANA Considerations 3342*ebfedea0SLionel Sambuc 3343*ebfedea0SLionel Sambuc OpenPGP is highly parameterized and consequently there are a number 3344*ebfedea0SLionel Sambuc of considerations for allocating parameters for extensions. This 3345*ebfedea0SLionel Sambuc section describes how IANA should look at extensions to the protocol 3346*ebfedea0SLionel Sambuc as described in this document. 3347*ebfedea0SLionel Sambuc 3348*ebfedea0SLionel Sambuc10.1. New String-to-Key specifier types 3349*ebfedea0SLionel Sambuc 3350*ebfedea0SLionel Sambuc OpenPGP S2K specifiers contain a mechanism for new algorithms to 3351*ebfedea0SLionel Sambuc turn a string into a key. This specification creates a registry of 3352*ebfedea0SLionel Sambuc S2K specifier types. The registry includes the S2K type, the name of 3353*ebfedea0SLionel Sambuc the S2K and a reference to the defining specification. The initial 3354*ebfedea0SLionel Sambuc values for this registry can be found in 3.7.1. Adding a new S2K 3355*ebfedea0SLionel Sambuc specifier MUST be done through the IETF CONSENSUS method, as 3356*ebfedea0SLionel Sambuc described in [RFC2434]. 3357*ebfedea0SLionel Sambuc 3358*ebfedea0SLionel Sambuc 3359*ebfedea0SLionel Sambuc 3360*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 60] 3361*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3362*ebfedea0SLionel Sambuc 3363*ebfedea0SLionel Sambuc10.2. New Packets 3364*ebfedea0SLionel Sambuc 3365*ebfedea0SLionel Sambuc Major new features of OpenPGP are defined though new packet types. 3366*ebfedea0SLionel Sambuc This specification creates a registry of packet types. The registry 3367*ebfedea0SLionel Sambuc includes the packet type, the name of the packet and a reference to 3368*ebfedea0SLionel Sambuc the defining specification. The initial values for this registry can 3369*ebfedea0SLionel Sambuc be found in 4.3. Adding a new packet type MUST be done through the 3370*ebfedea0SLionel Sambuc IETF CONSENSUS method, as described in [RFC2434]. 3371*ebfedea0SLionel Sambuc 3372*ebfedea0SLionel Sambuc10.2.1. User Attribute Types 3373*ebfedea0SLionel Sambuc 3374*ebfedea0SLionel Sambuc The User Attribute packet permits an extensible mechanism for other 3375*ebfedea0SLionel Sambuc types of certificate identification. This specification creates a 3376*ebfedea0SLionel Sambuc registry of User Attribute types. The registry includes the User 3377*ebfedea0SLionel Sambuc Attribute type, the name of the User Attribute and a reference to 3378*ebfedea0SLionel Sambuc the defining specification. The initial values for this registry can 3379*ebfedea0SLionel Sambuc be found in 5.12. Adding a new User Attribute type MUST be done 3380*ebfedea0SLionel Sambuc through the IETF CONSENSUS method, as described in [RFC2434]. 3381*ebfedea0SLionel Sambuc 3382*ebfedea0SLionel Sambuc10.2.1.1. Image Format Subpacket Types 3383*ebfedea0SLionel Sambuc 3384*ebfedea0SLionel Sambuc Within User Attribute packets, there is an extensible mechanism for 3385*ebfedea0SLionel Sambuc other types of image-based user attributes. This specification 3386*ebfedea0SLionel Sambuc creates a registry of Image Attribute subpacket types. The registry 3387*ebfedea0SLionel Sambuc includes the Image Attribute subpacket type, the name of the Image 3388*ebfedea0SLionel Sambuc Attribute subpacket and a reference to the defining specification. 3389*ebfedea0SLionel Sambuc The initial values for this registry can be found in 5.12.1. Adding 3390*ebfedea0SLionel Sambuc a new Image Attribute subpacket type MUST be done through the IETF 3391*ebfedea0SLionel Sambuc CONSENSUS method, as described in [RFC2434]. 3392*ebfedea0SLionel Sambuc 3393*ebfedea0SLionel Sambuc10.2.2. New Signature Subpackets 3394*ebfedea0SLionel Sambuc 3395*ebfedea0SLionel Sambuc OpenPGP signatures contain a mechanism for signed (or unsigned) data 3396*ebfedea0SLionel Sambuc to be added to them for a variety of purposes in the signature 3397*ebfedea0SLionel Sambuc subpackets as discussed in section 5.2.3.1. This specification 3398*ebfedea0SLionel Sambuc creates a registry of signature subpacket types. The registry 3399*ebfedea0SLionel Sambuc includes the signature subpacket type, the name of the subpacket and 3400*ebfedea0SLionel Sambuc a reference to the defining specification. The initial values for 3401*ebfedea0SLionel Sambuc this registry can be found in 5.2.3.1. Adding a new signature 3402*ebfedea0SLionel Sambuc subpacket MUST be done through the IETF CONSENSUS method, as 3403*ebfedea0SLionel Sambuc described in [RFC2434]. 3404*ebfedea0SLionel Sambuc 3405*ebfedea0SLionel Sambuc10.2.2.1. Signature Notation Data Subpackets 3406*ebfedea0SLionel Sambuc 3407*ebfedea0SLionel Sambuc OpenPGP signatures further contain a mechanism for extensions in 3408*ebfedea0SLionel Sambuc signatures. These are the Notation Data subpackets, which contain a 3409*ebfedea0SLionel Sambuc key/value pair. Notations contain a user space which is completely 3410*ebfedea0SLionel Sambuc unmanaged and an IETF space. 3411*ebfedea0SLionel Sambuc 3412*ebfedea0SLionel Sambuc This specification creates a registry of Signature Notation Data 3413*ebfedea0SLionel Sambuc types. The registry includes the Signature Notation Data type, the 3414*ebfedea0SLionel Sambuc name of the Signature Notation Data, its allowed values, and a 3415*ebfedea0SLionel Sambuc 3416*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 61] 3417*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3418*ebfedea0SLionel Sambuc 3419*ebfedea0SLionel Sambuc reference to the defining specification. The initial values for this 3420*ebfedea0SLionel Sambuc registry can be found in 5.2.3.16. Adding a new Signature Notation 3421*ebfedea0SLionel Sambuc Data subpacket MUST be done through the EXPERT REVIEW method, as 3422*ebfedea0SLionel Sambuc described in [RFC2434]. 3423*ebfedea0SLionel Sambuc 3424*ebfedea0SLionel Sambuc10.2.2.2. Key Server Preference Extensions 3425*ebfedea0SLionel Sambuc 3426*ebfedea0SLionel Sambuc OpenPGP signatures contain a mechanism for preferences to be 3427*ebfedea0SLionel Sambuc specified about key servers. This specification creates a registry 3428*ebfedea0SLionel Sambuc of key server preferences. The registry includes the key server 3429*ebfedea0SLionel Sambuc preference, the name of the preference and a reference to the 3430*ebfedea0SLionel Sambuc defining specification. The initial values for this registry can be 3431*ebfedea0SLionel Sambuc found in 5.2.3.17. Adding a new key server preference MUST be done 3432*ebfedea0SLionel Sambuc through the IETF CONSENSUS method, as described in [RFC2434]. 3433*ebfedea0SLionel Sambuc 3434*ebfedea0SLionel Sambuc10.2.2.3. Key Flags Extensions 3435*ebfedea0SLionel Sambuc 3436*ebfedea0SLionel Sambuc OpenPGP signatures contain a mechanism for flags to be specified 3437*ebfedea0SLionel Sambuc about key usage. This specification creates a registry of key usage 3438*ebfedea0SLionel Sambuc flags. The registry includes the key flags value, the name of the 3439*ebfedea0SLionel Sambuc flag and a reference to the defining specification. The initial 3440*ebfedea0SLionel Sambuc values for this registry can be found in 5.2.3.21. Adding a new key 3441*ebfedea0SLionel Sambuc usage flag MUST be done through the IETF CONSENSUS method, as 3442*ebfedea0SLionel Sambuc described in [RFC2434]. 3443*ebfedea0SLionel Sambuc 3444*ebfedea0SLionel Sambuc10.2.2.4. Reason For Revocation Extensions 3445*ebfedea0SLionel Sambuc 3446*ebfedea0SLionel Sambuc OpenPGP signatures contain a mechanism for flags to be specified 3447*ebfedea0SLionel Sambuc about why a key was revoked. This specification creates a registry 3448*ebfedea0SLionel Sambuc of reason-for-revocation flags. The registry includes the 3449*ebfedea0SLionel Sambuc reason-for-revocation flags value, the name of the flag and a 3450*ebfedea0SLionel Sambuc reference to the defining specification. The initial values for this 3451*ebfedea0SLionel Sambuc registry can be found in 5.2.3.23. Adding a new feature flag MUST be 3452*ebfedea0SLionel Sambuc done through the IETF CONSENSUS method, as described in [RFC2434]. 3453*ebfedea0SLionel Sambuc 3454*ebfedea0SLionel Sambuc10.2.2.5. Implementation Features 3455*ebfedea0SLionel Sambuc 3456*ebfedea0SLionel Sambuc OpenPGP signatures contain a mechanism for flags to be specified 3457*ebfedea0SLionel Sambuc stating which optional features an implementation supports. This 3458*ebfedea0SLionel Sambuc specification creates a registry of feature-implementation flags. 3459*ebfedea0SLionel Sambuc The registry includes the feature-implementation flags value, the 3460*ebfedea0SLionel Sambuc name of the flag and a reference to the defining specification. The 3461*ebfedea0SLionel Sambuc initial values for this registry can be found in 5.2.3.24. Adding a 3462*ebfedea0SLionel Sambuc new feature-implementation flag MUST be done through the IETF 3463*ebfedea0SLionel Sambuc CONSENSUS method, as described in [RFC2434]. 3464*ebfedea0SLionel Sambuc 3465*ebfedea0SLionel Sambuc Also see section 10.6 for more information about when feature flags 3466*ebfedea0SLionel Sambuc are needed. 3467*ebfedea0SLionel Sambuc 3468*ebfedea0SLionel Sambuc10.2.3. New Packet Versions 3469*ebfedea0SLionel Sambuc 3470*ebfedea0SLionel Sambuc The core OpenPGP packets all have version numbers, and can be 3471*ebfedea0SLionel Sambuc 3472*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 62] 3473*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3474*ebfedea0SLionel Sambuc 3475*ebfedea0SLionel Sambuc revised by introducing a new version of an existing packet. This 3476*ebfedea0SLionel Sambuc specification creates a registry of packet types. The registry 3477*ebfedea0SLionel Sambuc includes the packet type, the number of the version and a reference 3478*ebfedea0SLionel Sambuc to the defining specification. The initial values for this registry 3479*ebfedea0SLionel Sambuc can be found in 5. Adding a new packet version MUST be done through 3480*ebfedea0SLionel Sambuc the IETF CONSENSUS method, as described in [RFC2434]. 3481*ebfedea0SLionel Sambuc 3482*ebfedea0SLionel Sambuc10.3. New Algorithms 3483*ebfedea0SLionel Sambuc 3484*ebfedea0SLionel Sambuc Chapter 9 lists the core algorithms that OpenPGP uses. Adding in a 3485*ebfedea0SLionel Sambuc new algorithm is usually simple. For example, adding in a new 3486*ebfedea0SLionel Sambuc symmetric cipher usually would not need anything more than 3487*ebfedea0SLionel Sambuc allocating a constant for that cipher. If that cipher had other than 3488*ebfedea0SLionel Sambuc a 64-bit or 128-bit block size, there might need to be additional 3489*ebfedea0SLionel Sambuc documentation describing how OpenPGP-CFB mode would be adjusted. 3490*ebfedea0SLionel Sambuc Similarly, when DSA was expanded from a maximum of 1024-bit public 3491*ebfedea0SLionel Sambuc keys to 3072-bit public keys, the revision of FIPS 186 contained 3492*ebfedea0SLionel Sambuc enough information itself to allow implementation. Changes to this 3493*ebfedea0SLionel Sambuc document were emphasis more than required. 3494*ebfedea0SLionel Sambuc 3495*ebfedea0SLionel Sambuc10.3.1. Public Key Algorithms 3496*ebfedea0SLionel Sambuc 3497*ebfedea0SLionel Sambuc OpenPGP specifies a number of public key algorithms. This 3498*ebfedea0SLionel Sambuc specification creates a registry of public key algorithm 3499*ebfedea0SLionel Sambuc identifiers. The registry includes the algorithm name, its key sizes 3500*ebfedea0SLionel Sambuc and parameters, and a reference to the defining specification. The 3501*ebfedea0SLionel Sambuc initial values for this registry can be found in section 9. Adding a 3502*ebfedea0SLionel Sambuc new public key algorithm MUST be done through the IETF CONSENSUS 3503*ebfedea0SLionel Sambuc method, as described in [RFC2434]. 3504*ebfedea0SLionel Sambuc 3505*ebfedea0SLionel Sambuc10.3.2. Symmetric Key Algorithms 3506*ebfedea0SLionel Sambuc 3507*ebfedea0SLionel Sambuc OpenPGP specifies a number of symmetric key algorithms. This 3508*ebfedea0SLionel Sambuc specification creates a registry of symmetric key algorithm 3509*ebfedea0SLionel Sambuc identifiers. The registry includes the algorithm name, its key sizes 3510*ebfedea0SLionel Sambuc and block size, and a reference to the defining specification. The 3511*ebfedea0SLionel Sambuc initial values for this registry can be found in section 9. Adding a 3512*ebfedea0SLionel Sambuc new symmetric key algorithm MUST be done through the IETF CONSENSUS 3513*ebfedea0SLionel Sambuc method, as described in [RFC2434]. 3514*ebfedea0SLionel Sambuc 3515*ebfedea0SLionel Sambuc10.3.3. Hash Algorithms 3516*ebfedea0SLionel Sambuc 3517*ebfedea0SLionel Sambuc OpenPGP specifies a number of hash algorithms. This specification 3518*ebfedea0SLionel Sambuc creates a registry of hash algorithm identifiers. The registry 3519*ebfedea0SLionel Sambuc includes the algorithm name, a text representation of that name, its 3520*ebfedea0SLionel Sambuc block size, an OID hash prefix, and a reference to the defining 3521*ebfedea0SLionel Sambuc specification. The initial values for this registry can be found in 3522*ebfedea0SLionel Sambuc section 9 for the algorithm identifiers and text names, and section 3523*ebfedea0SLionel Sambuc 5.2.2 for the OIDs and expanded signature prefixes. Adding a new 3524*ebfedea0SLionel Sambuc hash algorithm MUST be done through the IETF CONSENSUS method, as 3525*ebfedea0SLionel Sambuc described in [RFC2434]. 3526*ebfedea0SLionel Sambuc 3527*ebfedea0SLionel Sambuc 3528*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 63] 3529*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3530*ebfedea0SLionel Sambuc 3531*ebfedea0SLionel Sambuc10.3.4. Compression Algorithms 3532*ebfedea0SLionel Sambuc 3533*ebfedea0SLionel Sambuc OpenPGP specifies a number of compression algorithms. This 3534*ebfedea0SLionel Sambuc specification creates a registry of compression algorithm 3535*ebfedea0SLionel Sambuc identifiers. The registry includes the algorithm name, and a 3536*ebfedea0SLionel Sambuc reference to the defining specification. The initial values for this 3537*ebfedea0SLionel Sambuc registry can be found in section 9.3. Adding a new compression key 3538*ebfedea0SLionel Sambuc algorithm MUST be done through the IETF CONSENSUS method, as 3539*ebfedea0SLionel Sambuc described in [RFC2434]. 3540*ebfedea0SLionel Sambuc 3541*ebfedea0SLionel Sambuc11. Packet Composition 3542*ebfedea0SLionel Sambuc 3543*ebfedea0SLionel Sambuc OpenPGP packets are assembled into sequences in order to create 3544*ebfedea0SLionel Sambuc messages and to transfer keys. Not all possible packet sequences are 3545*ebfedea0SLionel Sambuc meaningful and correct. This section describes the rules for how 3546*ebfedea0SLionel Sambuc packets should be placed into sequences. 3547*ebfedea0SLionel Sambuc 3548*ebfedea0SLionel Sambuc11.1. Transferable Public Keys 3549*ebfedea0SLionel Sambuc 3550*ebfedea0SLionel Sambuc OpenPGP users may transfer public keys. The essential elements of a 3551*ebfedea0SLionel Sambuc transferable public key are: 3552*ebfedea0SLionel Sambuc 3553*ebfedea0SLionel Sambuc - One Public Key packet 3554*ebfedea0SLionel Sambuc 3555*ebfedea0SLionel Sambuc - Zero or more revocation signatures 3556*ebfedea0SLionel Sambuc 3557*ebfedea0SLionel Sambuc - One or more User ID packets 3558*ebfedea0SLionel Sambuc 3559*ebfedea0SLionel Sambuc - After each User ID packet, zero or more signature packets 3560*ebfedea0SLionel Sambuc (certifications) 3561*ebfedea0SLionel Sambuc 3562*ebfedea0SLionel Sambuc - Zero or more User Attribute packets 3563*ebfedea0SLionel Sambuc 3564*ebfedea0SLionel Sambuc - After each User Attribute packet, zero or more signature packets 3565*ebfedea0SLionel Sambuc (certifications) 3566*ebfedea0SLionel Sambuc 3567*ebfedea0SLionel Sambuc - Zero or more Subkey packets 3568*ebfedea0SLionel Sambuc 3569*ebfedea0SLionel Sambuc - After each Subkey packet, one signature packet, plus optionally 3570*ebfedea0SLionel Sambuc a revocation. 3571*ebfedea0SLionel Sambuc 3572*ebfedea0SLionel Sambuc The Public Key packet occurs first. Each of the following User ID 3573*ebfedea0SLionel Sambuc packets provides the identity of the owner of this public key. If 3574*ebfedea0SLionel Sambuc there are multiple User ID packets, this corresponds to multiple 3575*ebfedea0SLionel Sambuc means of identifying the same unique individual user; for example, a 3576*ebfedea0SLionel Sambuc user may have more than one email address, and construct a User ID 3577*ebfedea0SLionel Sambuc for each one. 3578*ebfedea0SLionel Sambuc 3579*ebfedea0SLionel Sambuc Immediately following each User ID packet, there are zero or more 3580*ebfedea0SLionel Sambuc signature packets. Each signature packet is calculated on the 3581*ebfedea0SLionel Sambuc immediately preceding User ID packet and the initial Public Key 3582*ebfedea0SLionel Sambuc packet. The signature serves to certify the corresponding public key 3583*ebfedea0SLionel Sambuc 3584*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 64] 3585*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3586*ebfedea0SLionel Sambuc 3587*ebfedea0SLionel Sambuc and User ID. In effect, the signer is testifying to his or her 3588*ebfedea0SLionel Sambuc belief that this public key belongs to the user identified by this 3589*ebfedea0SLionel Sambuc User ID. 3590*ebfedea0SLionel Sambuc 3591*ebfedea0SLionel Sambuc Within the same section as the User ID packets, there are zero or 3592*ebfedea0SLionel Sambuc more User Attribute packets. Like the User ID packets, a User 3593*ebfedea0SLionel Sambuc Attribute packet is followed by zero or more signature packets 3594*ebfedea0SLionel Sambuc calculated on the immediately preceding User Attribute packet and 3595*ebfedea0SLionel Sambuc the initial Public Key packet. 3596*ebfedea0SLionel Sambuc 3597*ebfedea0SLionel Sambuc User Attribute packets and User ID packets may be freely intermixed 3598*ebfedea0SLionel Sambuc in this section, so long as the signatures that follow them are 3599*ebfedea0SLionel Sambuc maintained on the proper User Attribute or User ID packet. 3600*ebfedea0SLionel Sambuc 3601*ebfedea0SLionel Sambuc After the User ID or Attribute packets there may be zero or more 3602*ebfedea0SLionel Sambuc Subkey packets. In general, subkeys are provided in cases where the 3603*ebfedea0SLionel Sambuc top-level public key is a signature-only key. However, any V4 key 3604*ebfedea0SLionel Sambuc may have subkeys, and the subkeys may be encryption-only keys, 3605*ebfedea0SLionel Sambuc signature-only keys, or general-purpose keys. V3 keys MUST NOT have 3606*ebfedea0SLionel Sambuc subkeys. 3607*ebfedea0SLionel Sambuc 3608*ebfedea0SLionel Sambuc Each Subkey packet MUST be followed by one Signature packet, which 3609*ebfedea0SLionel Sambuc should be a subkey binding signature issued by the top level key. 3610*ebfedea0SLionel Sambuc For subkeys that can issue signatures, the subkey binding signature 3611*ebfedea0SLionel Sambuc MUST contain an embedded signature subpacket with a primary key 3612*ebfedea0SLionel Sambuc binding signature (0x19) issued by the subkey on the top level key. 3613*ebfedea0SLionel Sambuc 3614*ebfedea0SLionel Sambuc Subkey and Key packets may each be followed by a revocation 3615*ebfedea0SLionel Sambuc Signature packet to indicate that the key is revoked. Revocation 3616*ebfedea0SLionel Sambuc signatures are only accepted if they are issued by the key itself, 3617*ebfedea0SLionel Sambuc or by a key that is authorized to issue revocations via a revocation 3618*ebfedea0SLionel Sambuc key subpacket in a self-signature by the top level key. 3619*ebfedea0SLionel Sambuc 3620*ebfedea0SLionel Sambuc Transferable public key packet sequences may be concatenated to 3621*ebfedea0SLionel Sambuc allow transferring multiple public keys in one operation. 3622*ebfedea0SLionel Sambuc 3623*ebfedea0SLionel Sambuc11.2. Transferable Secret Keys 3624*ebfedea0SLionel Sambuc 3625*ebfedea0SLionel Sambuc OpenPGP users may transfer secret keys. The format of a transferable 3626*ebfedea0SLionel Sambuc secret key is the same as a transferable public key except that 3627*ebfedea0SLionel Sambuc secret key and secret subkey packets are used instead of the public 3628*ebfedea0SLionel Sambuc key and public subkey packets. Implementations SHOULD include 3629*ebfedea0SLionel Sambuc self-signatures on any user IDs and subkeys, as this allows for a 3630*ebfedea0SLionel Sambuc complete public key to be automatically extracted from the 3631*ebfedea0SLionel Sambuc transferable secret key. Implementations MAY choose to omit the 3632*ebfedea0SLionel Sambuc self-signatures, especially if a transferable public key accompanies 3633*ebfedea0SLionel Sambuc the transferable secret key. 3634*ebfedea0SLionel Sambuc 3635*ebfedea0SLionel Sambuc11.3. OpenPGP Messages 3636*ebfedea0SLionel Sambuc 3637*ebfedea0SLionel Sambuc An OpenPGP message is a packet or sequence of packets that 3638*ebfedea0SLionel Sambuc corresponds to the following grammatical rules (comma represents 3639*ebfedea0SLionel Sambuc 3640*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 65] 3641*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3642*ebfedea0SLionel Sambuc 3643*ebfedea0SLionel Sambuc sequential composition, and vertical bar separates alternatives): 3644*ebfedea0SLionel Sambuc 3645*ebfedea0SLionel Sambuc OpenPGP Message :- Encrypted Message | Signed Message | 3646*ebfedea0SLionel Sambuc Compressed Message | Literal Message. 3647*ebfedea0SLionel Sambuc 3648*ebfedea0SLionel Sambuc Compressed Message :- Compressed Data Packet. 3649*ebfedea0SLionel Sambuc 3650*ebfedea0SLionel Sambuc Literal Message :- Literal Data Packet. 3651*ebfedea0SLionel Sambuc 3652*ebfedea0SLionel Sambuc ESK :- Public Key Encrypted Session Key Packet | 3653*ebfedea0SLionel Sambuc Symmetric-Key Encrypted Session Key Packet. 3654*ebfedea0SLionel Sambuc 3655*ebfedea0SLionel Sambuc ESK Sequence :- ESK | ESK Sequence, ESK. 3656*ebfedea0SLionel Sambuc 3657*ebfedea0SLionel Sambuc Encrypted Data :- Symmetrically Encrypted Data Packet | 3658*ebfedea0SLionel Sambuc Symmetrically Encrypted Integrity Protected Data Packet 3659*ebfedea0SLionel Sambuc 3660*ebfedea0SLionel Sambuc Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data. 3661*ebfedea0SLionel Sambuc 3662*ebfedea0SLionel Sambuc One-Pass Signed Message :- One-Pass Signature Packet, 3663*ebfedea0SLionel Sambuc OpenPGP Message, Corresponding Signature Packet. 3664*ebfedea0SLionel Sambuc 3665*ebfedea0SLionel Sambuc Signed Message :- Signature Packet, OpenPGP Message | 3666*ebfedea0SLionel Sambuc One-Pass Signed Message. 3667*ebfedea0SLionel Sambuc 3668*ebfedea0SLionel Sambuc In addition, decrypting a Symmetrically Encrypted Data Packet or a 3669*ebfedea0SLionel Sambuc Symmetrically Encrypted Integrity Protected Data Packet as well as 3670*ebfedea0SLionel Sambuc decompressing a Compressed Data packet must yield a valid OpenPGP 3671*ebfedea0SLionel Sambuc Message. 3672*ebfedea0SLionel Sambuc 3673*ebfedea0SLionel Sambuc11.4. Detached Signatures 3674*ebfedea0SLionel Sambuc 3675*ebfedea0SLionel Sambuc Some OpenPGP applications use so-called "detached signatures." For 3676*ebfedea0SLionel Sambuc example, a program bundle may contain a file, and with it a second 3677*ebfedea0SLionel Sambuc file that is a detached signature of the first file. These detached 3678*ebfedea0SLionel Sambuc signatures are simply a signature packet stored separately from the 3679*ebfedea0SLionel Sambuc data that they are a signature of. 3680*ebfedea0SLionel Sambuc 3681*ebfedea0SLionel Sambuc12. Enhanced Key Formats 3682*ebfedea0SLionel Sambuc 3683*ebfedea0SLionel Sambuc12.1. Key Structures 3684*ebfedea0SLionel Sambuc 3685*ebfedea0SLionel Sambuc The format of an OpenPGP V3 key is as follows. Entries in square 3686*ebfedea0SLionel Sambuc brackets are optional and ellipses indicate repetition. 3687*ebfedea0SLionel Sambuc 3688*ebfedea0SLionel Sambuc RSA Public Key 3689*ebfedea0SLionel Sambuc [Revocation Self Signature] 3690*ebfedea0SLionel Sambuc User ID [Signature ...] 3691*ebfedea0SLionel Sambuc [User ID [Signature ...] ...] 3692*ebfedea0SLionel Sambuc 3693*ebfedea0SLionel Sambuc 3694*ebfedea0SLionel Sambuc 3695*ebfedea0SLionel Sambuc 3696*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 66] 3697*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3698*ebfedea0SLionel Sambuc 3699*ebfedea0SLionel Sambuc Each signature certifies the RSA public key and the preceding User 3700*ebfedea0SLionel Sambuc ID. The RSA public key can have many User IDs and each User ID can 3701*ebfedea0SLionel Sambuc have many signatures. V3 keys are deprecated. Implementations MUST 3702*ebfedea0SLionel Sambuc NOT generate new V3 keys, but MAY continue to use existing ones. 3703*ebfedea0SLionel Sambuc 3704*ebfedea0SLionel Sambuc The format of an OpenPGP V4 key that uses multiple public keys is 3705*ebfedea0SLionel Sambuc similar except that the other keys are added to the end as "subkeys" 3706*ebfedea0SLionel Sambuc of the primary key. 3707*ebfedea0SLionel Sambuc 3708*ebfedea0SLionel Sambuc Primary-Key 3709*ebfedea0SLionel Sambuc [Revocation Self Signature] 3710*ebfedea0SLionel Sambuc [Direct Key Signature...] 3711*ebfedea0SLionel Sambuc User ID [Signature ...] 3712*ebfedea0SLionel Sambuc [User ID [Signature ...] ...] 3713*ebfedea0SLionel Sambuc [User Attribute [Signature ...] ...] 3714*ebfedea0SLionel Sambuc [[Subkey [Binding-Signature-Revocation] 3715*ebfedea0SLionel Sambuc Primary-Key-Binding-Signature] ...] 3716*ebfedea0SLionel Sambuc 3717*ebfedea0SLionel Sambuc A subkey always has a single signature after it that is issued using 3718*ebfedea0SLionel Sambuc the primary key to tie the two keys together. This binding signature 3719*ebfedea0SLionel Sambuc may be in either V3 or V4 format, but SHOULD be V4. Subkeys that can 3720*ebfedea0SLionel Sambuc issue signatures MUST have a V4 binding signature due to the 3721*ebfedea0SLionel Sambuc REQUIRED embedded primary key binding signature. 3722*ebfedea0SLionel Sambuc 3723*ebfedea0SLionel Sambuc In the above diagram, if the binding signature of a subkey has been 3724*ebfedea0SLionel Sambuc revoked, the revoked key may be removed, leaving only one key. 3725*ebfedea0SLionel Sambuc 3726*ebfedea0SLionel Sambuc In a V4 key, the primary key MUST be a key capable of certification. 3727*ebfedea0SLionel Sambuc The subkeys may be keys of any other type. There may be other 3728*ebfedea0SLionel Sambuc constructions of V4 keys, too. For example, there may be a 3729*ebfedea0SLionel Sambuc single-key RSA key in V4 format, a DSA primary key with an RSA 3730*ebfedea0SLionel Sambuc encryption key, or RSA primary key with an Elgamal subkey, etc. 3731*ebfedea0SLionel Sambuc 3732*ebfedea0SLionel Sambuc It is also possible to have a signature-only subkey. This permits a 3733*ebfedea0SLionel Sambuc primary key that collects certifications (key signatures) but is 3734*ebfedea0SLionel Sambuc used only used for certifying subkeys that are used for encryption 3735*ebfedea0SLionel Sambuc and signatures. 3736*ebfedea0SLionel Sambuc 3737*ebfedea0SLionel Sambuc12.2. Key IDs and Fingerprints 3738*ebfedea0SLionel Sambuc 3739*ebfedea0SLionel Sambuc For a V3 key, the eight-octet key ID consists of the low 64 bits of 3740*ebfedea0SLionel Sambuc the public modulus of the RSA key. 3741*ebfedea0SLionel Sambuc 3742*ebfedea0SLionel Sambuc The fingerprint of a V3 key is formed by hashing the body (but not 3743*ebfedea0SLionel Sambuc the two-octet length) of the MPIs that form the key material (public 3744*ebfedea0SLionel Sambuc modulus n, followed by exponent e) with MD5. Note that both V3 keys 3745*ebfedea0SLionel Sambuc and MD5 are deprecated. 3746*ebfedea0SLionel Sambuc 3747*ebfedea0SLionel Sambuc A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, 3748*ebfedea0SLionel Sambuc followed by the two-octet packet length, followed by the entire 3749*ebfedea0SLionel Sambuc Public Key packet starting with the version field. The key ID is the 3750*ebfedea0SLionel Sambuc low order 64 bits of the fingerprint. Here are the fields of the 3751*ebfedea0SLionel Sambuc 3752*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 67] 3753*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3754*ebfedea0SLionel Sambuc 3755*ebfedea0SLionel Sambuc hash material, with the example of a DSA key: 3756*ebfedea0SLionel Sambuc 3757*ebfedea0SLionel Sambuc a.1) 0x99 (1 octet) 3758*ebfedea0SLionel Sambuc 3759*ebfedea0SLionel Sambuc a.2) high order length octet of (b)-(f) (1 octet) 3760*ebfedea0SLionel Sambuc 3761*ebfedea0SLionel Sambuc a.3) low order length octet of (b)-(f) (1 octet) 3762*ebfedea0SLionel Sambuc 3763*ebfedea0SLionel Sambuc b) version number = 4 (1 octet); 3764*ebfedea0SLionel Sambuc 3765*ebfedea0SLionel Sambuc c) time stamp of key creation (4 octets); 3766*ebfedea0SLionel Sambuc 3767*ebfedea0SLionel Sambuc d) algorithm (1 octet): 17 = DSA (example); 3768*ebfedea0SLionel Sambuc 3769*ebfedea0SLionel Sambuc e) Algorithm specific fields. 3770*ebfedea0SLionel Sambuc 3771*ebfedea0SLionel Sambuc Algorithm Specific Fields for DSA keys (example): 3772*ebfedea0SLionel Sambuc 3773*ebfedea0SLionel Sambuc e.1) MPI of DSA prime p; 3774*ebfedea0SLionel Sambuc 3775*ebfedea0SLionel Sambuc e.2) MPI of DSA group order q (q is a prime divisor of p-1); 3776*ebfedea0SLionel Sambuc 3777*ebfedea0SLionel Sambuc e.3) MPI of DSA group generator g; 3778*ebfedea0SLionel Sambuc 3779*ebfedea0SLionel Sambuc e.4) MPI of DSA public key value y (= g**x mod p where x is secret). 3780*ebfedea0SLionel Sambuc 3781*ebfedea0SLionel Sambuc Note that it is possible for there to be collisions of key IDs -- 3782*ebfedea0SLionel Sambuc two different keys with the same key ID. Note that there is a much 3783*ebfedea0SLionel Sambuc smaller, but still non-zero probability that two different keys have 3784*ebfedea0SLionel Sambuc the same fingerprint. 3785*ebfedea0SLionel Sambuc 3786*ebfedea0SLionel Sambuc Also note that if V3 and V4 format keys share the same RSA key 3787*ebfedea0SLionel Sambuc material, they will have different key IDs as well as different 3788*ebfedea0SLionel Sambuc fingerprints. 3789*ebfedea0SLionel Sambuc 3790*ebfedea0SLionel Sambuc Finally, the key ID and fingerprint of a subkey are calculated in 3791*ebfedea0SLionel Sambuc the same way as for a primary key, including the 0x99 as the first 3792*ebfedea0SLionel Sambuc octet (even though this is not a valid packet ID for a public 3793*ebfedea0SLionel Sambuc subkey). 3794*ebfedea0SLionel Sambuc 3795*ebfedea0SLionel Sambuc13. Notes on Algorithms 3796*ebfedea0SLionel Sambuc 3797*ebfedea0SLionel Sambuc13.1. PKCS#1 Encoding In OpenPGP 3798*ebfedea0SLionel Sambuc 3799*ebfedea0SLionel Sambuc This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and 3800*ebfedea0SLionel Sambuc EMSA-PKCS1-v1_5. However, the calling conventions of these functions 3801*ebfedea0SLionel Sambuc has changed in the past. To avoid potential confusion and 3802*ebfedea0SLionel Sambuc interoperability problems, we are including local copies in this 3803*ebfedea0SLionel Sambuc document, adapted from those in PKCS#1 v2.1 [RFC3447]. RFC-3447 3804*ebfedea0SLionel Sambuc should be treated as the ultimate authority on PKCS#1 for OpenPGP. 3805*ebfedea0SLionel Sambuc Nonetheless, we believe that there is value in having a 3806*ebfedea0SLionel Sambuc self-contained document that avoids problems in the future with 3807*ebfedea0SLionel Sambuc 3808*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 68] 3809*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3810*ebfedea0SLionel Sambuc 3811*ebfedea0SLionel Sambuc needed changes in the conventions. 3812*ebfedea0SLionel Sambuc 3813*ebfedea0SLionel Sambuc13.1.1. EME-PKCS1-v1_5-ENCODE 3814*ebfedea0SLionel Sambuc 3815*ebfedea0SLionel Sambuc Input: 3816*ebfedea0SLionel Sambuc 3817*ebfedea0SLionel Sambuc k = the length in octets of the key modulus 3818*ebfedea0SLionel Sambuc 3819*ebfedea0SLionel Sambuc M = message to be encoded, an octet string of length mLen, where 3820*ebfedea0SLionel Sambuc mLen <= k - 11 3821*ebfedea0SLionel Sambuc 3822*ebfedea0SLionel Sambuc Output: 3823*ebfedea0SLionel Sambuc 3824*ebfedea0SLionel Sambuc EM = encoded message, an octet string of length k 3825*ebfedea0SLionel Sambuc 3826*ebfedea0SLionel Sambuc Error: "message too long" 3827*ebfedea0SLionel Sambuc 3828*ebfedea0SLionel Sambuc 1. Length checking: If mLen > k - 11, output "message too long" and 3829*ebfedea0SLionel Sambuc stop. 3830*ebfedea0SLionel Sambuc 3831*ebfedea0SLionel Sambuc 2. Generate an octet string PS of length k - mLen - 3 consisting of 3832*ebfedea0SLionel Sambuc pseudo-randomly generated nonzero octets. The length of PS will 3833*ebfedea0SLionel Sambuc be at least eight octets. 3834*ebfedea0SLionel Sambuc 3835*ebfedea0SLionel Sambuc 3. Concatenate PS, the message M, and other padding to form an 3836*ebfedea0SLionel Sambuc encoded message EM of length k octets as 3837*ebfedea0SLionel Sambuc 3838*ebfedea0SLionel Sambuc EM = 0x00 || 0x02 || PS || 0x00 || M. 3839*ebfedea0SLionel Sambuc 3840*ebfedea0SLionel Sambuc 4. Output EM. 3841*ebfedea0SLionel Sambuc 3842*ebfedea0SLionel Sambuc13.1.2. EME-PKCS1-v1_5-DECODE 3843*ebfedea0SLionel Sambuc 3844*ebfedea0SLionel Sambuc Input: 3845*ebfedea0SLionel Sambuc 3846*ebfedea0SLionel Sambuc EM = encoded message, an octet string 3847*ebfedea0SLionel Sambuc 3848*ebfedea0SLionel Sambuc Output: 3849*ebfedea0SLionel Sambuc 3850*ebfedea0SLionel Sambuc M = message, an octet string 3851*ebfedea0SLionel Sambuc 3852*ebfedea0SLionel Sambuc Error: "decryption error" 3853*ebfedea0SLionel Sambuc 3854*ebfedea0SLionel Sambuc To decode an EME-PKCS1_v1_5 message, separate the encoded message EM 3855*ebfedea0SLionel Sambuc into an octet string PS consisting of nonzero octets and a message M 3856*ebfedea0SLionel Sambuc as 3857*ebfedea0SLionel Sambuc 3858*ebfedea0SLionel Sambuc EM = 0x00 || 0x02 || PS || 0x00 || M. 3859*ebfedea0SLionel Sambuc 3860*ebfedea0SLionel Sambuc If the first octet of EM does not have hexadecimal value 0x00, if 3861*ebfedea0SLionel Sambuc the second octet of EM does not have hexadecimal value 0x02, if 3862*ebfedea0SLionel Sambuc there is no octet with hexadecimal value 0x00 to separate PS from M, 3863*ebfedea0SLionel Sambuc 3864*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 69] 3865*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3866*ebfedea0SLionel Sambuc 3867*ebfedea0SLionel Sambuc or if the length of PS is less than 8 octets, output "decryption 3868*ebfedea0SLionel Sambuc error" and stop. See also the security note in section 13 regarding 3869*ebfedea0SLionel Sambuc differences in reporting between a decryption error and a padding 3870*ebfedea0SLionel Sambuc error. 3871*ebfedea0SLionel Sambuc 3872*ebfedea0SLionel Sambuc13.1.3. EMSA-PKCS1-v1_5 3873*ebfedea0SLionel Sambuc 3874*ebfedea0SLionel Sambuc This encoding method is deterministic and only has an encoding 3875*ebfedea0SLionel Sambuc operation. 3876*ebfedea0SLionel Sambuc 3877*ebfedea0SLionel Sambuc Option: 3878*ebfedea0SLionel Sambuc 3879*ebfedea0SLionel Sambuc Hash hash function (hLen denotes the length in octets of the hash 3880*ebfedea0SLionel Sambuc function output) 3881*ebfedea0SLionel Sambuc 3882*ebfedea0SLionel Sambuc Input: 3883*ebfedea0SLionel Sambuc 3884*ebfedea0SLionel Sambuc M = message to be encoded 3885*ebfedea0SLionel Sambuc 3886*ebfedea0SLionel Sambuc mL = intended length in octets of the encoded message, at least tLen 3887*ebfedea0SLionel Sambuc + 11, where tLen is the octet length of the DER encoding T of a 3888*ebfedea0SLionel Sambuc certain value computed during the encoding operation 3889*ebfedea0SLionel Sambuc 3890*ebfedea0SLionel Sambuc Output: 3891*ebfedea0SLionel Sambuc 3892*ebfedea0SLionel Sambuc EM = encoded message, an octet string of length emLen 3893*ebfedea0SLionel Sambuc 3894*ebfedea0SLionel Sambuc Errors: "message too long"; "intended encoded message length too 3895*ebfedea0SLionel Sambuc short" 3896*ebfedea0SLionel Sambuc 3897*ebfedea0SLionel Sambuc Steps: 3898*ebfedea0SLionel Sambuc 3899*ebfedea0SLionel Sambuc 1. Apply the hash function to the message M to produce a hash value 3900*ebfedea0SLionel Sambuc H: 3901*ebfedea0SLionel Sambuc 3902*ebfedea0SLionel Sambuc H = Hash(M). 3903*ebfedea0SLionel Sambuc 3904*ebfedea0SLionel Sambuc If the hash function outputs "message too long," output "message 3905*ebfedea0SLionel Sambuc too long" and stop. 3906*ebfedea0SLionel Sambuc 3907*ebfedea0SLionel Sambuc 2. Using the list in section 5.2.2, produce an ASN.1 DER value for 3908*ebfedea0SLionel Sambuc the hash function used. Let T be the full hash prefix from 3909*ebfedea0SLionel Sambuc section 5.2.2, and let tLen be the length in octets of T. 3910*ebfedea0SLionel Sambuc 3911*ebfedea0SLionel Sambuc 3. If emLen < tLen + 11, output "intended encoded message length 3912*ebfedea0SLionel Sambuc too short" and stop. 3913*ebfedea0SLionel Sambuc 3914*ebfedea0SLionel Sambuc 4. Generate an octet string PS consisting of emLen - tLen - 3 3915*ebfedea0SLionel Sambuc octets with hexadecimal value 0xff. The length of PS will be at 3916*ebfedea0SLionel Sambuc least 8 octets. 3917*ebfedea0SLionel Sambuc 3918*ebfedea0SLionel Sambuc 3919*ebfedea0SLionel Sambuc 3920*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 70] 3921*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3922*ebfedea0SLionel Sambuc 3923*ebfedea0SLionel Sambuc 5. Concatenate PS, the hash prefix T, and other padding to form the 3924*ebfedea0SLionel Sambuc encoded message EM as 3925*ebfedea0SLionel Sambuc 3926*ebfedea0SLionel Sambuc EM = 0x00 || 0x01 || PS || 0x00 || T. 3927*ebfedea0SLionel Sambuc 3928*ebfedea0SLionel Sambuc 6. Output EM. 3929*ebfedea0SLionel Sambuc 3930*ebfedea0SLionel Sambuc13.2. Symmetric Algorithm Preferences 3931*ebfedea0SLionel Sambuc 3932*ebfedea0SLionel Sambuc The symmetric algorithm preference is an ordered list of algorithms 3933*ebfedea0SLionel Sambuc that the keyholder accepts. Since it is found on a self-signature, 3934*ebfedea0SLionel Sambuc it is possible that a keyholder may have multiple, different 3935*ebfedea0SLionel Sambuc preferences. For example, Alice may have TripleDES only specified 3936*ebfedea0SLionel Sambuc for "alice@work.com" but CAST5, Blowfish, and TripleDES specified 3937*ebfedea0SLionel Sambuc for "alice@home.org". Note that it is also possible for preferences 3938*ebfedea0SLionel Sambuc to be in a subkey's binding signature. 3939*ebfedea0SLionel Sambuc 3940*ebfedea0SLionel Sambuc Since TripleDES is the MUST-implement algorithm, if it is not 3941*ebfedea0SLionel Sambuc explicitly in the list, it is tacitly at the end. However, it is 3942*ebfedea0SLionel Sambuc good form to place it there explicitly. Note also that if an 3943*ebfedea0SLionel Sambuc implementation does not implement the preference, then it is 3944*ebfedea0SLionel Sambuc implicitly a TripleDES-only implementation. 3945*ebfedea0SLionel Sambuc 3946*ebfedea0SLionel Sambuc An implementation MUST NOT use a symmetric algorithm that is not in 3947*ebfedea0SLionel Sambuc the recipient's preference list. When encrypting to more than one 3948*ebfedea0SLionel Sambuc recipient, the implementation finds a suitable algorithm by taking 3949*ebfedea0SLionel Sambuc the intersection of the preferences of the recipients. Note that the 3950*ebfedea0SLionel Sambuc MUST-implement algorithm, TripleDES, ensures that the intersection 3951*ebfedea0SLionel Sambuc is not null. The implementation may use any mechanism to pick an 3952*ebfedea0SLionel Sambuc algorithm in the intersection. 3953*ebfedea0SLionel Sambuc 3954*ebfedea0SLionel Sambuc If an implementation can decrypt a message that a keyholder doesn't 3955*ebfedea0SLionel Sambuc have in their preferences, the implementation SHOULD decrypt the 3956*ebfedea0SLionel Sambuc message anyway, but MUST warn the keyholder that the protocol has 3957*ebfedea0SLionel Sambuc been violated. For example, suppose that Alice, above, has software 3958*ebfedea0SLionel Sambuc that implements all algorithms in this specification. Nonetheless, 3959*ebfedea0SLionel Sambuc she prefers subsets for work or home. If she is sent a message 3960*ebfedea0SLionel Sambuc encrypted with IDEA, which is not in her preferences, the software 3961*ebfedea0SLionel Sambuc warns her that someone sent her an IDEA-encrypted message, but it 3962*ebfedea0SLionel Sambuc would ideally decrypt it anyway. 3963*ebfedea0SLionel Sambuc 3964*ebfedea0SLionel Sambuc13.3. Other Algorithm Preferences 3965*ebfedea0SLionel Sambuc 3966*ebfedea0SLionel Sambuc Other algorithm preferences work similarly to the symmetric 3967*ebfedea0SLionel Sambuc algorithm preference, in that they specify which algorithms the 3968*ebfedea0SLionel Sambuc keyholder accepts. There are two interesting cases that other 3969*ebfedea0SLionel Sambuc comments need to be made about, though, the compression preferences 3970*ebfedea0SLionel Sambuc and the hash preferences. 3971*ebfedea0SLionel Sambuc 3972*ebfedea0SLionel Sambuc13.3.1. Compression Preferences 3973*ebfedea0SLionel Sambuc 3974*ebfedea0SLionel Sambuc Compression has been an integral part of PGP since its first days. 3975*ebfedea0SLionel Sambuc 3976*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 71] 3977*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 3978*ebfedea0SLionel Sambuc 3979*ebfedea0SLionel Sambuc OpenPGP and all previous versions of PGP have offered compression. 3980*ebfedea0SLionel Sambuc In this specification, the default is for messages to be compressed, 3981*ebfedea0SLionel Sambuc although an implementation is not required to do so. Consequently, 3982*ebfedea0SLionel Sambuc the compression preference gives a way for a keyholder to request 3983*ebfedea0SLionel Sambuc that messages not be compressed, presumably because they are using a 3984*ebfedea0SLionel Sambuc minimal implementation that does not include compression. 3985*ebfedea0SLionel Sambuc Additionally, this gives a keyholder a way to state that it can 3986*ebfedea0SLionel Sambuc support alternate algorithms. 3987*ebfedea0SLionel Sambuc 3988*ebfedea0SLionel Sambuc Like the algorithm preferences, an implementation MUST NOT use an 3989*ebfedea0SLionel Sambuc algorithm that is not in the preference vector. If the preferences 3990*ebfedea0SLionel Sambuc are not present, then they are assumed to be [ZIP(1), 3991*ebfedea0SLionel Sambuc UNCOMPRESSED(0)]. 3992*ebfedea0SLionel Sambuc 3993*ebfedea0SLionel Sambuc Additionally, an implementation MUST implement this preference to 3994*ebfedea0SLionel Sambuc the degree of recognizing when to send an uncompressed message. A 3995*ebfedea0SLionel Sambuc robust implementation would satisfy this requirement by looking at 3996*ebfedea0SLionel Sambuc the recipient's preference and acting accordingly. A minimal 3997*ebfedea0SLionel Sambuc implementation can satisfy this requirement by never generating a 3998*ebfedea0SLionel Sambuc compressed message, since all implementations can handle messages 3999*ebfedea0SLionel Sambuc that have not been compressed. 4000*ebfedea0SLionel Sambuc 4001*ebfedea0SLionel Sambuc13.3.2. Hash Algorithm Preferences 4002*ebfedea0SLionel Sambuc 4003*ebfedea0SLionel Sambuc Typically, the choice of a hash algorithm is something the signer 4004*ebfedea0SLionel Sambuc does, rather than the verifier, because a signer rarely knows who is 4005*ebfedea0SLionel Sambuc going to be verifying the signature. This preference, though, allows 4006*ebfedea0SLionel Sambuc a protocol based upon digital signatures ease in negotiation. 4007*ebfedea0SLionel Sambuc 4008*ebfedea0SLionel Sambuc Thus, if Alice is authenticating herself to Bob with a signature, it 4009*ebfedea0SLionel Sambuc makes sense for her to use a hash algorithm that Bob's software 4010*ebfedea0SLionel Sambuc uses. This preference allows Bob to state in his key which 4011*ebfedea0SLionel Sambuc algorithms Alice may use. 4012*ebfedea0SLionel Sambuc 4013*ebfedea0SLionel Sambuc Since SHA1 is the MUST-implement hash algorithm, if it is not 4014*ebfedea0SLionel Sambuc explicitly in the list, it is tacitly at the end. However, it is 4015*ebfedea0SLionel Sambuc good form to place it there explicitly. 4016*ebfedea0SLionel Sambuc 4017*ebfedea0SLionel Sambuc13.4. Plaintext 4018*ebfedea0SLionel Sambuc 4019*ebfedea0SLionel Sambuc Algorithm 0, "plaintext," may only be used to denote secret keys 4020*ebfedea0SLionel Sambuc that are stored in the clear. Implementations MUST NOT use plaintext 4021*ebfedea0SLionel Sambuc in Symmetrically Encrypted Data Packets; they must use Literal Data 4022*ebfedea0SLionel Sambuc Packets to encode unencrypted or literal data. 4023*ebfedea0SLionel Sambuc 4024*ebfedea0SLionel Sambuc13.5. RSA 4025*ebfedea0SLionel Sambuc 4026*ebfedea0SLionel Sambuc There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only 4027*ebfedea0SLionel Sambuc keys. These types are deprecated. The "key flags" subpacket in a 4028*ebfedea0SLionel Sambuc signature is a much better way to express the same idea, and 4029*ebfedea0SLionel Sambuc generalizes it to all algorithms. An implementation SHOULD NOT 4030*ebfedea0SLionel Sambuc create such a key, but MAY interpret it. 4031*ebfedea0SLionel Sambuc 4032*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 72] 4033*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4034*ebfedea0SLionel Sambuc 4035*ebfedea0SLionel Sambuc An implementation SHOULD NOT implement RSA keys of size less than 4036*ebfedea0SLionel Sambuc 1024 bits. 4037*ebfedea0SLionel Sambuc 4038*ebfedea0SLionel Sambuc13.6. DSA 4039*ebfedea0SLionel Sambuc 4040*ebfedea0SLionel Sambuc An implementation SHOULD NOT implement DSA keys of size less than 4041*ebfedea0SLionel Sambuc 1024 bits. It MUST NOT implement a DSA key with a q size of less 4042*ebfedea0SLionel Sambuc than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the 4043*ebfedea0SLionel Sambuc q size MUST be a multiple of 8 bits. The Digital Signature Standard 4044*ebfedea0SLionel Sambuc (DSS) [FIPS186] specifies that DSA be used in one of the following 4045*ebfedea0SLionel Sambuc ways: 4046*ebfedea0SLionel Sambuc 4047*ebfedea0SLionel Sambuc * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or 4048*ebfedea0SLionel Sambuc SHA-512 hash 4049*ebfedea0SLionel Sambuc 4050*ebfedea0SLionel Sambuc * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 4051*ebfedea0SLionel Sambuc hash 4052*ebfedea0SLionel Sambuc 4053*ebfedea0SLionel Sambuc * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash 4054*ebfedea0SLionel Sambuc 4055*ebfedea0SLionel Sambuc * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash 4056*ebfedea0SLionel Sambuc 4057*ebfedea0SLionel Sambuc The above key and q size pairs were chosen to best balance the 4058*ebfedea0SLionel Sambuc strength of the key with the strength of the hash. Implementations 4059*ebfedea0SLionel Sambuc SHOULD use one of the above key and q size pairs when generating DSA 4060*ebfedea0SLionel Sambuc keys. If DSS compliance is desired, one of the specified SHA hashes 4061*ebfedea0SLionel Sambuc must be used as well. [FIPS186] is the ultimate authority on DSS, 4062*ebfedea0SLionel Sambuc and should be consulted for all questions of DSS compliance. 4063*ebfedea0SLionel Sambuc 4064*ebfedea0SLionel Sambuc Note that earlier versions of this standard only allowed a 160-bit q 4065*ebfedea0SLionel Sambuc with no truncation allowed, so earlier implementations may not be 4066*ebfedea0SLionel Sambuc able to handle signatures with a different q size or a truncated 4067*ebfedea0SLionel Sambuc hash. 4068*ebfedea0SLionel Sambuc 4069*ebfedea0SLionel Sambuc13.7. Elgamal 4070*ebfedea0SLionel Sambuc 4071*ebfedea0SLionel Sambuc An implementation SHOULD NOT implement Elgamal keys of size less 4072*ebfedea0SLionel Sambuc than 1024 bits. 4073*ebfedea0SLionel Sambuc 4074*ebfedea0SLionel Sambuc13.8. Reserved Algorithm Numbers 4075*ebfedea0SLionel Sambuc 4076*ebfedea0SLionel Sambuc A number of algorithm IDs have been reserved for algorithms that 4077*ebfedea0SLionel Sambuc would be useful to use in an OpenPGP implementation, yet there are 4078*ebfedea0SLionel Sambuc issues that prevent an implementer from actually implementing the 4079*ebfedea0SLionel Sambuc algorithm. These are marked in the Public Algorithms section as 4080*ebfedea0SLionel Sambuc "(reserved for)". 4081*ebfedea0SLionel Sambuc 4082*ebfedea0SLionel Sambuc The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), 4083*ebfedea0SLionel Sambuc and X9.42 (21) do not have the necessary parameters, parameter 4084*ebfedea0SLionel Sambuc order, or semantics defined. 4085*ebfedea0SLionel Sambuc 4086*ebfedea0SLionel Sambuc 4087*ebfedea0SLionel Sambuc 4088*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 73] 4089*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4090*ebfedea0SLionel Sambuc 4091*ebfedea0SLionel Sambuc Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures 4092*ebfedea0SLionel Sambuc with a public key identifier of 20. These are no longer permitted. 4093*ebfedea0SLionel Sambuc An implementation MUST NOT generate such keys. An implementation 4094*ebfedea0SLionel Sambuc MUST NOT generate Elgamal signatures. See [BLEICHENBACHER]. 4095*ebfedea0SLionel Sambuc 4096*ebfedea0SLionel Sambuc13.9. OpenPGP CFB mode 4097*ebfedea0SLionel Sambuc 4098*ebfedea0SLionel Sambuc OpenPGP does symmetric encryption using a variant of Cipher Feedback 4099*ebfedea0SLionel Sambuc Mode (CFB mode). This section describes the procedure it uses in 4100*ebfedea0SLionel Sambuc detail. This mode is what is used for Symmetrically Encrypted Data 4101*ebfedea0SLionel Sambuc Packets; the mechanism used for encrypting secret key material is 4102*ebfedea0SLionel Sambuc similar, but described in those sections above. 4103*ebfedea0SLionel Sambuc 4104*ebfedea0SLionel Sambuc In the description below, the value BS is the block size in octets 4105*ebfedea0SLionel Sambuc of the cipher. Most ciphers have a block size of 8 octets. The AES 4106*ebfedea0SLionel Sambuc and Twofish have a block size of 16 octets. Also note that the 4107*ebfedea0SLionel Sambuc description below assumes that the IV and CFB arrays start with an 4108*ebfedea0SLionel Sambuc index of 1 (unlike the C language, which assumes arrays start with a 4109*ebfedea0SLionel Sambuc zero index). 4110*ebfedea0SLionel Sambuc 4111*ebfedea0SLionel Sambuc OpenPGP CFB mode uses an initialization vector (IV) of all zeros, 4112*ebfedea0SLionel Sambuc and prefixes the plaintext with BS+2 octets of random data, such 4113*ebfedea0SLionel Sambuc that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB 4114*ebfedea0SLionel Sambuc resynchronization after encrypting those BS+2 octets. 4115*ebfedea0SLionel Sambuc 4116*ebfedea0SLionel Sambuc Thus, for an algorithm that has a block size of 8 octets (64 bits), 4117*ebfedea0SLionel Sambuc the IV is 10 octets long and octets 7 and 8 of the IV are the same 4118*ebfedea0SLionel Sambuc as octets 9 and 10. For an algorithm with a block size of 16 octets 4119*ebfedea0SLionel Sambuc (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate 4120*ebfedea0SLionel Sambuc octets 15 and 16. Those extra two octets are an easy check for a 4121*ebfedea0SLionel Sambuc correct key. 4122*ebfedea0SLionel Sambuc 4123*ebfedea0SLionel Sambuc Step by step, here is the procedure: 4124*ebfedea0SLionel Sambuc 4125*ebfedea0SLionel Sambuc 1. The feedback register (FR) is set to the IV, which is all zeros. 4126*ebfedea0SLionel Sambuc 4127*ebfedea0SLionel Sambuc 2. FR is encrypted to produce FRE (FR Encrypted). This is the 4128*ebfedea0SLionel Sambuc encryption of an all-zero value. 4129*ebfedea0SLionel Sambuc 4130*ebfedea0SLionel Sambuc 3. FRE is xored with the first BS octets of random data prefixed to 4131*ebfedea0SLionel Sambuc the plaintext to produce C[1] through C[BS], the first BS octets 4132*ebfedea0SLionel Sambuc of ciphertext. 4133*ebfedea0SLionel Sambuc 4134*ebfedea0SLionel Sambuc 4. FR is loaded with C[1] through C[BS]. 4135*ebfedea0SLionel Sambuc 4136*ebfedea0SLionel Sambuc 5. FR is encrypted to produce FRE, the encryption of the first BS 4137*ebfedea0SLionel Sambuc octets of ciphertext. 4138*ebfedea0SLionel Sambuc 4139*ebfedea0SLionel Sambuc 6. The left two octets of FRE get xored with the next two octets of 4140*ebfedea0SLionel Sambuc data that were prefixed to the plaintext. This produces C[BS+1] 4141*ebfedea0SLionel Sambuc and C[BS+2], the next two octets of ciphertext. 4142*ebfedea0SLionel Sambuc 4143*ebfedea0SLionel Sambuc 4144*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 74] 4145*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4146*ebfedea0SLionel Sambuc 4147*ebfedea0SLionel Sambuc 7. (The resynchronization step) FR is loaded with C[3] through 4148*ebfedea0SLionel Sambuc C[BS+2]. 4149*ebfedea0SLionel Sambuc 4150*ebfedea0SLionel Sambuc 8. FR is encrypted to produce FRE. 4151*ebfedea0SLionel Sambuc 4152*ebfedea0SLionel Sambuc 9. FRE is xored with the first BS octets of the given plaintext, 4153*ebfedea0SLionel Sambuc now that we have finished encrypting the BS+2 octets of prefixed 4154*ebfedea0SLionel Sambuc data. This produces C[BS+3] through C[BS+(BS+2)], the next BS 4155*ebfedea0SLionel Sambuc octets of ciphertext. 4156*ebfedea0SLionel Sambuc 4157*ebfedea0SLionel Sambuc 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 4158*ebfedea0SLionel Sambuc for an 8-octet block). 4159*ebfedea0SLionel Sambuc 4160*ebfedea0SLionel Sambuc 11. FR is encrypted to produce FRE. 4161*ebfedea0SLionel Sambuc 4162*ebfedea0SLionel Sambuc 12. FRE is xored with the next BS octets of plaintext, to produce 4163*ebfedea0SLionel Sambuc the next BS octets of ciphertext. These are loaded into FR and 4164*ebfedea0SLionel Sambuc the process is repeated until the plaintext is used up. 4165*ebfedea0SLionel Sambuc 4166*ebfedea0SLionel Sambuc13.10. Private or Experimental Parameters 4167*ebfedea0SLionel Sambuc 4168*ebfedea0SLionel Sambuc S2K specifiers, Signature subpacket types, user attribute types, 4169*ebfedea0SLionel Sambuc image format types, and algorithms described in Section 9 all 4170*ebfedea0SLionel Sambuc reserve the range 100 to 110 for private and experimental use. 4171*ebfedea0SLionel Sambuc Packet types reserve the range 60 to 63 for private and experimental 4172*ebfedea0SLionel Sambuc use. These are intentionally managed with the PRIVATE USE method, as 4173*ebfedea0SLionel Sambuc described in [RFC2434]. 4174*ebfedea0SLionel Sambuc 4175*ebfedea0SLionel Sambuc However, implementations need to be careful with these and promote 4176*ebfedea0SLionel Sambuc them to full IANA-managed parameters when they grow beyond the 4177*ebfedea0SLionel Sambuc original, limited system. 4178*ebfedea0SLionel Sambuc 4179*ebfedea0SLionel Sambuc13.11. Extension of the MDC System 4180*ebfedea0SLionel Sambuc 4181*ebfedea0SLionel Sambuc As described in the non-normative explanation in section 5.13, the 4182*ebfedea0SLionel Sambuc MDC system is uniquely unparameterized in OpenPGP, and that this was 4183*ebfedea0SLionel Sambuc an intentional decision to avoid cross-grade attacks. If the MDC 4184*ebfedea0SLionel Sambuc system is extended to a stronger hash function, there must be care 4185*ebfedea0SLionel Sambuc given to avoiding downgrade and cross-grade attacks. 4186*ebfedea0SLionel Sambuc 4187*ebfedea0SLionel Sambuc One simple way to do this is to create new packets for a new MDC. 4188*ebfedea0SLionel Sambuc For example, instead of the MDC system using packets 18 and 19, a 4189*ebfedea0SLionel Sambuc new MDC could use 20 and 21. This has obvious drawbacks (it uses two 4190*ebfedea0SLionel Sambuc packet numbers for each new hash function in a space that is limited 4191*ebfedea0SLionel Sambuc to a maximum of 60). 4192*ebfedea0SLionel Sambuc 4193*ebfedea0SLionel Sambuc Another simple way to extend the MDC system is to create new 4194*ebfedea0SLionel Sambuc versions of packet 18, and reflect this in packet 19. For example, 4195*ebfedea0SLionel Sambuc suppose that V2 of packet 18 implicitly used SHA-256. This would 4196*ebfedea0SLionel Sambuc require packet 19 to have a length of 32 octets. The change in the 4197*ebfedea0SLionel Sambuc version in packet 18 and the size of packet 19 prevent a downgrade 4198*ebfedea0SLionel Sambuc attack. 4199*ebfedea0SLionel Sambuc 4200*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 75] 4201*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4202*ebfedea0SLionel Sambuc 4203*ebfedea0SLionel Sambuc There are two drawbacks to this latter approach. The first is that 4204*ebfedea0SLionel Sambuc using the version number of a packet to carry algorithm information 4205*ebfedea0SLionel Sambuc is not tidy from a protocol-design standpoint. it is possible that 4206*ebfedea0SLionel Sambuc there might be several versions of the MDC system in common use, but 4207*ebfedea0SLionel Sambuc this untidiness would reflect untidiness in cryptographic consensus 4208*ebfedea0SLionel Sambuc about hash function security. The second is that different versions 4209*ebfedea0SLionel Sambuc of packet 19 would have to have unique sizes. If there were two 4210*ebfedea0SLionel Sambuc versions each with 256-bit hashes, they could not both have 32-octet 4211*ebfedea0SLionel Sambuc packet 19s without admitting the chance of a cross-grade attack. 4212*ebfedea0SLionel Sambuc 4213*ebfedea0SLionel Sambuc Yet another, complex approach to extend the MDC system would be a 4214*ebfedea0SLionel Sambuc hybrid of the two above -- create a new pair of MDC packets that are 4215*ebfedea0SLionel Sambuc fully parameterized, and yet protected from downgrade and 4216*ebfedea0SLionel Sambuc cross-grade. 4217*ebfedea0SLionel Sambuc 4218*ebfedea0SLionel Sambuc Any change to the MDC system MUST be done through the IETF CONSENSUS 4219*ebfedea0SLionel Sambuc method, as described in [RFC2434]. 4220*ebfedea0SLionel Sambuc 4221*ebfedea0SLionel Sambuc13.12. Meta-Considerations for Expansion 4222*ebfedea0SLionel Sambuc 4223*ebfedea0SLionel Sambuc If OpenPGP is extended in a way that is not backwards-compatible, 4224*ebfedea0SLionel Sambuc meaning that old implementations will not gracefully handle their 4225*ebfedea0SLionel Sambuc absence of a new feature, the extension proposal can be declared in 4226*ebfedea0SLionel Sambuc the key holder's self-signature as part of the Features signature 4227*ebfedea0SLionel Sambuc subpacket. 4228*ebfedea0SLionel Sambuc 4229*ebfedea0SLionel Sambuc We cannot state definitively what extensions will not be 4230*ebfedea0SLionel Sambuc upwards-compatible, but typically new algorithms are 4231*ebfedea0SLionel Sambuc upwards-compatible, but new packets are not. 4232*ebfedea0SLionel Sambuc 4233*ebfedea0SLionel Sambuc If an extension proposal does not update the Features system, it 4234*ebfedea0SLionel Sambuc SHOULD include an explanation of why this is unnecessary. If the 4235*ebfedea0SLionel Sambuc proposal contains neither an extension to the Features system nor an 4236*ebfedea0SLionel Sambuc explanation of why such an extension is unnecessary, the proposal 4237*ebfedea0SLionel Sambuc SHOULD be rejected. 4238*ebfedea0SLionel Sambuc 4239*ebfedea0SLionel Sambuc14. Security Considerations 4240*ebfedea0SLionel Sambuc 4241*ebfedea0SLionel Sambuc * As with any technology involving cryptography, you should check 4242*ebfedea0SLionel Sambuc the current literature to determine if any algorithms used here 4243*ebfedea0SLionel Sambuc have been found to be vulnerable to attack. 4244*ebfedea0SLionel Sambuc 4245*ebfedea0SLionel Sambuc * This specification uses Public Key Cryptography technologies. It 4246*ebfedea0SLionel Sambuc is assumed that the private key portion of a public-private key 4247*ebfedea0SLionel Sambuc pair is controlled and secured by the proper party or parties. 4248*ebfedea0SLionel Sambuc 4249*ebfedea0SLionel Sambuc * Certain operations in this specification involve the use of 4250*ebfedea0SLionel Sambuc random numbers. An appropriate entropy source should be used to 4251*ebfedea0SLionel Sambuc generate these numbers. See RFC 4086. 4252*ebfedea0SLionel Sambuc 4253*ebfedea0SLionel Sambuc 4254*ebfedea0SLionel Sambuc 4255*ebfedea0SLionel Sambuc 4256*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 76] 4257*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4258*ebfedea0SLionel Sambuc 4259*ebfedea0SLionel Sambuc * The MD5 hash algorithm has been found to have weaknesses, with 4260*ebfedea0SLionel Sambuc collisions found in a number of cases. MD5 is deprecated for use 4261*ebfedea0SLionel Sambuc in OpenPGP. Implementations MUST NOT generate new signatures 4262*ebfedea0SLionel Sambuc using MD5 as a hash function. They MAY continue to consider old 4263*ebfedea0SLionel Sambuc signatures that used MD5 as valid. 4264*ebfedea0SLionel Sambuc 4265*ebfedea0SLionel Sambuc * SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512 4266*ebfedea0SLionel Sambuc respectively. In general, there are few reasons to use them 4267*ebfedea0SLionel Sambuc outside of DSS compatibility. You need a situation where one 4268*ebfedea0SLionel Sambuc needs more security than smaller hashes, but does not want to 4269*ebfedea0SLionel Sambuc have the full 256-bit or 512-bit data length. 4270*ebfedea0SLionel Sambuc 4271*ebfedea0SLionel Sambuc * Many security protocol designers think that it is a bad idea to 4272*ebfedea0SLionel Sambuc use a single key for both privacy (encryption) and integrity 4273*ebfedea0SLionel Sambuc (signatures). In fact, this was one of the motivating forces 4274*ebfedea0SLionel Sambuc behind the V4 key format with separate signature and encryption 4275*ebfedea0SLionel Sambuc keys. If you as an implementer promote dual-use keys, you should 4276*ebfedea0SLionel Sambuc at least be aware of this controversy. 4277*ebfedea0SLionel Sambuc 4278*ebfedea0SLionel Sambuc * The DSA algorithm will work with any hash, but is sensitive to 4279*ebfedea0SLionel Sambuc the quality of the hash algorithm. Verifiers should be aware 4280*ebfedea0SLionel Sambuc that even if the signer used a strong hash, an attacker could 4281*ebfedea0SLionel Sambuc have modified the signature to use a weak one. Only signatures 4282*ebfedea0SLionel Sambuc using acceptably strong hash algorithms should be accepted as 4283*ebfedea0SLionel Sambuc valid. 4284*ebfedea0SLionel Sambuc 4285*ebfedea0SLionel Sambuc * As OpenPGP combines many different asymmetric, symmetric, and 4286*ebfedea0SLionel Sambuc hash algorithms, each with different measures of strength, care 4287*ebfedea0SLionel Sambuc should be taken that the weakest element of an OpenPGP message 4288*ebfedea0SLionel Sambuc is still sufficiently strong for the purpose at hand. While 4289*ebfedea0SLionel Sambuc consensus about the the strength of a given algorithm may 4290*ebfedea0SLionel Sambuc evolve, NIST Special Publication 800-57 [SP800-57] recommends 4291*ebfedea0SLionel Sambuc the following list of equivalent strengths: 4292*ebfedea0SLionel Sambuc 4293*ebfedea0SLionel Sambuc Asymmetric | Hash | Symmetric 4294*ebfedea0SLionel Sambuc key size | size | key size 4295*ebfedea0SLionel Sambuc ------------+--------+----------- 4296*ebfedea0SLionel Sambuc 1024 160 80 4297*ebfedea0SLionel Sambuc 2048 224 112 4298*ebfedea0SLionel Sambuc 3072 256 128 4299*ebfedea0SLionel Sambuc 7680 384 192 4300*ebfedea0SLionel Sambuc 15360 512 256 4301*ebfedea0SLionel Sambuc 4302*ebfedea0SLionel Sambuc 4303*ebfedea0SLionel Sambuc * There is a somewhat-related potential security problem in 4304*ebfedea0SLionel Sambuc signatures. If an attacker can find a message that hashes to the 4305*ebfedea0SLionel Sambuc same hash with a different algorithm, a bogus signature 4306*ebfedea0SLionel Sambuc structure can be constructed that evaluates correctly. 4307*ebfedea0SLionel Sambuc 4308*ebfedea0SLionel Sambuc For example, suppose Alice DSA signs message M using hash 4309*ebfedea0SLionel Sambuc algorithm H. Suppose that Mallet finds a message M' that has the 4310*ebfedea0SLionel Sambuc same hash value as M with H'. Mallet can then construct a 4311*ebfedea0SLionel Sambuc 4312*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 77] 4313*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4314*ebfedea0SLionel Sambuc 4315*ebfedea0SLionel Sambuc signature block that verifies as Alice's signature of M' with 4316*ebfedea0SLionel Sambuc H'. However, this would also constitute a weakness in either H 4317*ebfedea0SLionel Sambuc or H' or both. Should this ever occur, a revision will have to 4318*ebfedea0SLionel Sambuc be made to this document to revise the allowed hash algorithms. 4319*ebfedea0SLionel Sambuc 4320*ebfedea0SLionel Sambuc * If you are building an authentication system, the recipient may 4321*ebfedea0SLionel Sambuc specify a preferred signing algorithm. However, the signer would 4322*ebfedea0SLionel Sambuc be foolish to use a weak algorithm simply because the recipient 4323*ebfedea0SLionel Sambuc requests it. 4324*ebfedea0SLionel Sambuc 4325*ebfedea0SLionel Sambuc * Some of the encryption algorithms mentioned in this document 4326*ebfedea0SLionel Sambuc have been analyzed less than others. For example, although CAST5 4327*ebfedea0SLionel Sambuc is presently considered strong, it has been analyzed less than 4328*ebfedea0SLionel Sambuc TripleDES. Other algorithms may have other controversies 4329*ebfedea0SLionel Sambuc surrounding them. 4330*ebfedea0SLionel Sambuc 4331*ebfedea0SLionel Sambuc * In late summer 2002, Jallad, Katz, and Schneier published an 4332*ebfedea0SLionel Sambuc interesting attack on the OpenPGP protocol and some of its 4333*ebfedea0SLionel Sambuc implementations [JKS02]. In this attack, the attacker modifies a 4334*ebfedea0SLionel Sambuc message and sends it to a user who then returns the erroneously 4335*ebfedea0SLionel Sambuc decrypted message to the attacker. The attacker is thus using 4336*ebfedea0SLionel Sambuc the user as a random oracle, and can often decrypt the message. 4337*ebfedea0SLionel Sambuc 4338*ebfedea0SLionel Sambuc Compressing data can ameliorate this attack. The incorrectly 4339*ebfedea0SLionel Sambuc decrypted data nearly always decompresses in ways that defeats 4340*ebfedea0SLionel Sambuc the attack. However, this is not a rigorous fix, and leaves open 4341*ebfedea0SLionel Sambuc some small vulnerabilities. For example, if an implementation 4342*ebfedea0SLionel Sambuc does not compress a message before encryption (perhaps because 4343*ebfedea0SLionel Sambuc it knows it was already compressed), then that message is 4344*ebfedea0SLionel Sambuc vulnerable. Because of this happenstance -- that modification 4345*ebfedea0SLionel Sambuc attacks can be thwarted by decompression errors, an 4346*ebfedea0SLionel Sambuc implementation SHOULD treat a decompression error as a security 4347*ebfedea0SLionel Sambuc problem, not merely a data problem. 4348*ebfedea0SLionel Sambuc 4349*ebfedea0SLionel Sambuc This attack can be defeated by the use of Modification 4350*ebfedea0SLionel Sambuc Detection, provided that the implementation does not let the 4351*ebfedea0SLionel Sambuc user naively return the data to the attacker. An implementation 4352*ebfedea0SLionel Sambuc MUST treat an MDC failure as a security problem, not merely a 4353*ebfedea0SLionel Sambuc data problem. 4354*ebfedea0SLionel Sambuc 4355*ebfedea0SLionel Sambuc In either case, the implementation MAY allow the user access to 4356*ebfedea0SLionel Sambuc the erroneous data, but MUST warn the user as to potential 4357*ebfedea0SLionel Sambuc security problems should that data be returned to the sender. 4358*ebfedea0SLionel Sambuc 4359*ebfedea0SLionel Sambuc While this attack is somewhat obscure, requiring a special set 4360*ebfedea0SLionel Sambuc of circumstances to create it, it is nonetheless quite serious 4361*ebfedea0SLionel Sambuc as it permits someone to trick a user to decrypt a message. 4362*ebfedea0SLionel Sambuc Consequently, it is important that: 4363*ebfedea0SLionel Sambuc 4364*ebfedea0SLionel Sambuc 1. Implementers treat MDC errors and decompression failures as 4365*ebfedea0SLionel Sambuc security problems. 4366*ebfedea0SLionel Sambuc 4367*ebfedea0SLionel Sambuc 4368*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 78] 4369*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4370*ebfedea0SLionel Sambuc 4371*ebfedea0SLionel Sambuc 2. Implementers implement Modification Detection with all due 4372*ebfedea0SLionel Sambuc speed and encourage its spread. 4373*ebfedea0SLionel Sambuc 4374*ebfedea0SLionel Sambuc 3. Users migrate to implementations that support Modification 4375*ebfedea0SLionel Sambuc Detection with all due speed. 4376*ebfedea0SLionel Sambuc 4377*ebfedea0SLionel Sambuc * PKCS#1 has been found to be vulnerable to attacks in which a 4378*ebfedea0SLionel Sambuc system that reports errors in padding differently from errors in 4379*ebfedea0SLionel Sambuc decryption becomes a random oracle that can leak the private key 4380*ebfedea0SLionel Sambuc in mere millions of queries. Implementations must be aware of 4381*ebfedea0SLionel Sambuc this attack and prevent it from happening. The simplest solution 4382*ebfedea0SLionel Sambuc is report a single error code for all variants of decryption 4383*ebfedea0SLionel Sambuc errors so as not to leak information to an attacker. 4384*ebfedea0SLionel Sambuc 4385*ebfedea0SLionel Sambuc * Some technologies mentioned here may be subject to government 4386*ebfedea0SLionel Sambuc control in some countries. 4387*ebfedea0SLionel Sambuc 4388*ebfedea0SLionel Sambuc * In winter 2005, Serge Mister and Robert Zuccherato from Entrust 4389*ebfedea0SLionel Sambuc released a paper describing a way that the "quick check" in 4390*ebfedea0SLionel Sambuc OpenPGP CFB mode can be used with a random oracle to decrypt two 4391*ebfedea0SLionel Sambuc octets of every cipher block [MZ05]. They recommend as 4392*ebfedea0SLionel Sambuc prevention not using the quick check at all. 4393*ebfedea0SLionel Sambuc 4394*ebfedea0SLionel Sambuc Many implementers have taken this advice to heart for any data 4395*ebfedea0SLionel Sambuc that is symmetrically encrypted and for which the session key is 4396*ebfedea0SLionel Sambuc public-key encrypted. In this case, the quick check is not 4397*ebfedea0SLionel Sambuc needed as the public key encryption of the session key should 4398*ebfedea0SLionel Sambuc guarantee that it is the right session key. In other cases, the 4399*ebfedea0SLionel Sambuc implementation should use the quick check with care. 4400*ebfedea0SLionel Sambuc 4401*ebfedea0SLionel Sambuc On the one hand, there is a danger to using it if there is a 4402*ebfedea0SLionel Sambuc random oracle that can leak information to an attacker. In 4403*ebfedea0SLionel Sambuc plainer language, there is a danger to using the quick check if 4404*ebfedea0SLionel Sambuc timing information about the check can be exposed to an 4405*ebfedea0SLionel Sambuc attacker, particularly via an automated service that allows 4406*ebfedea0SLionel Sambuc rapidly repeated queries. 4407*ebfedea0SLionel Sambuc 4408*ebfedea0SLionel Sambuc On the other hand, it is inconvenient to the user to be informed 4409*ebfedea0SLionel Sambuc that they typed in the wrong passphrase only after a petabyte of 4410*ebfedea0SLionel Sambuc data is decrypted. There are many cases in cryptographic 4411*ebfedea0SLionel Sambuc engineering where the implementer must use care and wisdom, and 4412*ebfedea0SLionel Sambuc this is one. 4413*ebfedea0SLionel Sambuc 4414*ebfedea0SLionel Sambuc15. Implementation Nits 4415*ebfedea0SLionel Sambuc 4416*ebfedea0SLionel Sambuc This section is a collection of comments to help an implementer, 4417*ebfedea0SLionel Sambuc particularly with an eye to backward compatibility. Previous 4418*ebfedea0SLionel Sambuc implementations of PGP are not OpenPGP-compliant. Often the 4419*ebfedea0SLionel Sambuc differences are small, but small differences are frequently more 4420*ebfedea0SLionel Sambuc vexing than large differences. Thus, this is a non-comprehensive 4421*ebfedea0SLionel Sambuc list of potential problems and gotchas for a developer who is trying 4422*ebfedea0SLionel Sambuc to be backward-compatible. 4423*ebfedea0SLionel Sambuc 4424*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 79] 4425*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4426*ebfedea0SLionel Sambuc 4427*ebfedea0SLionel Sambuc * The IDEA algorithm is patented, and yet it is required for PGP 4428*ebfedea0SLionel Sambuc 2.x interoperability. It is also the de-facto preferred 4429*ebfedea0SLionel Sambuc algorithm for a V3 key with a V3 self-signature (or no 4430*ebfedea0SLionel Sambuc self-signature). 4431*ebfedea0SLionel Sambuc 4432*ebfedea0SLionel Sambuc * When exporting a private key, PGP 2.x generates the header 4433*ebfedea0SLionel Sambuc "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY 4434*ebfedea0SLionel Sambuc BLOCK". All previous versions ignore the implied data type, and 4435*ebfedea0SLionel Sambuc look directly at the packet data type. 4436*ebfedea0SLionel Sambuc 4437*ebfedea0SLionel Sambuc * PGP 2.0 through 2.5 generated V2 Public Key Packets. These are 4438*ebfedea0SLionel Sambuc identical to the deprecated V3 keys except for the version 4439*ebfedea0SLionel Sambuc number. An implementation MUST NOT generate them and may accept 4440*ebfedea0SLionel Sambuc or reject them as it sees fit. Some older PGP versions generated 4441*ebfedea0SLionel Sambuc V2 PKESK packets (Tag 1) as well. An implementation may accept 4442*ebfedea0SLionel Sambuc or reject V2 PKESK packets as it sees fit, and MUST NOT generate 4443*ebfedea0SLionel Sambuc them. 4444*ebfedea0SLionel Sambuc 4445*ebfedea0SLionel Sambuc * PGP 2.6.x will not accept key-material packets with versions 4446*ebfedea0SLionel Sambuc greater than 3. 4447*ebfedea0SLionel Sambuc 4448*ebfedea0SLionel Sambuc * There are many ways possible for two keys to have the same key 4449*ebfedea0SLionel Sambuc material, but different fingerprints (and thus key IDs). Perhaps 4450*ebfedea0SLionel Sambuc the most interesting is an RSA key that has been "upgraded" to 4451*ebfedea0SLionel Sambuc V4 format, but since a V4 fingerprint is constructed by hashing 4452*ebfedea0SLionel Sambuc the key creation time along with other things, two V4 keys 4453*ebfedea0SLionel Sambuc created at different times, yet with the same key material will 4454*ebfedea0SLionel Sambuc have different fingerprints. 4455*ebfedea0SLionel Sambuc 4456*ebfedea0SLionel Sambuc * If an implementation is using zlib to interoperate with PGP 2.x, 4457*ebfedea0SLionel Sambuc then the "windowBits" parameter should be set to -13. 4458*ebfedea0SLionel Sambuc 4459*ebfedea0SLionel Sambuc * The 0x19 back signatures were not required for signing subkeys 4460*ebfedea0SLionel Sambuc until relatively recently. Consquently, there may be keys in the 4461*ebfedea0SLionel Sambuc wild that do not have these back signatures. Implementing 4462*ebfedea0SLionel Sambuc software may handle these keys as it sees fit. 4463*ebfedea0SLionel Sambuc 4464*ebfedea0SLionel Sambuc16. Authors' Addresses 4465*ebfedea0SLionel Sambuc 4466*ebfedea0SLionel Sambuc The working group can be contacted via the current chair: 4467*ebfedea0SLionel Sambuc 4468*ebfedea0SLionel Sambuc Derek Atkins 4469*ebfedea0SLionel Sambuc IHTFP Consulting, Inc. 4470*ebfedea0SLionel Sambuc 6 Farragut Ave 4471*ebfedea0SLionel Sambuc Somerville, MA 02144 USA 4472*ebfedea0SLionel Sambuc Email: derek@ihtfp.com 4473*ebfedea0SLionel Sambuc Tel: +1 617 623 3745 4474*ebfedea0SLionel Sambuc 4475*ebfedea0SLionel Sambuc The principal authors of this draft are: 4476*ebfedea0SLionel Sambuc 4477*ebfedea0SLionel Sambuc 4478*ebfedea0SLionel Sambuc 4479*ebfedea0SLionel Sambuc 4480*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 80] 4481*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4482*ebfedea0SLionel Sambuc 4483*ebfedea0SLionel Sambuc Jon Callas 4484*ebfedea0SLionel Sambuc Email: jon@callas.org 4485*ebfedea0SLionel Sambuc 4486*ebfedea0SLionel Sambuc Lutz Donnerhacke 4487*ebfedea0SLionel Sambuc IKS GmbH 4488*ebfedea0SLionel Sambuc Wildenbruchstr. 15 4489*ebfedea0SLionel Sambuc 07745 Jena, Germany 4490*ebfedea0SLionel Sambuc 4491*ebfedea0SLionel Sambuc EMail: lutz@iks-jena.de 4492*ebfedea0SLionel Sambuc 4493*ebfedea0SLionel Sambuc Hal Finney 4494*ebfedea0SLionel Sambuc Email: hal@finney.org 4495*ebfedea0SLionel Sambuc 4496*ebfedea0SLionel Sambuc David Shaw 4497*ebfedea0SLionel Sambuc Email: dshaw@jabberwocky.com 4498*ebfedea0SLionel Sambuc 4499*ebfedea0SLionel Sambuc Rodney Thayer 4500*ebfedea0SLionel Sambuc Email: rodney@canola-jones.com 4501*ebfedea0SLionel Sambuc 4502*ebfedea0SLionel Sambuc This memo also draws on much previous work from a number of other 4503*ebfedea0SLionel Sambuc authors who include: Derek Atkins, Charles Breed, Dave Del Torto, 4504*ebfedea0SLionel Sambuc Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben 4505*ebfedea0SLionel Sambuc Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William 4506*ebfedea0SLionel Sambuc Stallings, Mark Weaver, and Philip R. Zimmermann. 4507*ebfedea0SLionel Sambuc 4508*ebfedea0SLionel Sambuc17. References (Normative) 4509*ebfedea0SLionel Sambuc 4510*ebfedea0SLionel Sambuc 4511*ebfedea0SLionel Sambuc [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 4512*ebfedea0SLionel Sambuc (AES)," November 2001. 4513*ebfedea0SLionel Sambuc 4514*ebfedea0SLionel Sambuchttp://csrc.nist.gov/publications/fips/fips197/ 4515*ebfedea0SLionel Sambuc fips-197.{ps,pdf} 4516*ebfedea0SLionel Sambuc 4517*ebfedea0SLionel Sambuc [BLOWFISH] Schneier, B. "Description of a New Variable-Length 4518*ebfedea0SLionel Sambuc Key, 64-Bit Block Cipher (Blowfish)" Fast Software 4519*ebfedea0SLionel Sambuc Encryption, Cambridge Security Workshop Proceedings 4520*ebfedea0SLionel Sambuc (December 1993), Springer-Verlag, 1994, pp191-204 4521*ebfedea0SLionel Sambuc <http://www.counterpane.com/bfsverlag.html> 4522*ebfedea0SLionel Sambuc 4523*ebfedea0SLionel Sambuc [BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2 4524*ebfedea0SLionel Sambuc home page" <http://www.bzip.org/> 4525*ebfedea0SLionel Sambuc 4526*ebfedea0SLionel Sambuc [ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a 4527*ebfedea0SLionel Sambuc Signature Scheme Based on Discrete Logarithms," 4528*ebfedea0SLionel Sambuc IEEE Transactions on Information Theory, v. IT-31, 4529*ebfedea0SLionel Sambuc n. 4, 1985, pp. 469-472. 4530*ebfedea0SLionel Sambuc 4531*ebfedea0SLionel Sambuc [FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB 4532*ebfedea0SLionel Sambuc 180-2). 4533*ebfedea0SLionel Sambuc <http://csrc.nist.gov/publications/fips/ 4534*ebfedea0SLionel Sambuc fips180-2/fips180-2withchangenotice.pdf> 4535*ebfedea0SLionel Sambuc 4536*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 81] 4537*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4538*ebfedea0SLionel Sambuc 4539*ebfedea0SLionel Sambuc [FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2). 4540*ebfedea0SLionel Sambuc <http://csrc.nist.gov/publications/fips/fips186-2/ 4541*ebfedea0SLionel Sambuc fips186-2-change1.pdf> 4542*ebfedea0SLionel Sambuc FIPS 186-3 describes keys greater than 1024 bits. 4543*ebfedea0SLionel Sambuc The latest draft is at: 4544*ebfedea0SLionel Sambuc <http://csrc.nist.gov/publications/drafts/ 4545*ebfedea0SLionel Sambuc fips_186-3/Draft-FIPS-186-3%20_March2006.pdf> 4546*ebfedea0SLionel Sambuc 4547*ebfedea0SLionel Sambuc [HAC] Alfred Menezes, Paul van Oorschot, and Scott 4548*ebfedea0SLionel Sambuc Vanstone, "Handbook of Applied Cryptography," CRC 4549*ebfedea0SLionel Sambuc Press, 1996. 4550*ebfedea0SLionel Sambuc <http://www.cacr.math.uwaterloo.ca/hac/> 4551*ebfedea0SLionel Sambuc 4552*ebfedea0SLionel Sambuc [IDEA] Lai, X, "On the design and security of block 4553*ebfedea0SLionel Sambuc ciphers", ETH Series in Information Processing, 4554*ebfedea0SLionel Sambuc J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag 4555*ebfedea0SLionel Sambuc Knostanz, Technische Hochschule (Zurich), 1992 4556*ebfedea0SLionel Sambuc 4557*ebfedea0SLionel Sambuc [ISO10646] ISO/IEC 10646-1:1993. International Standard -- 4558*ebfedea0SLionel Sambuc Information technology -- Universal Multiple-Octet 4559*ebfedea0SLionel Sambuc Coded Character Set (UCS) -- Part 1: Architecture 4560*ebfedea0SLionel Sambuc and Basic Multilingual Plane. 4561*ebfedea0SLionel Sambuc 4562*ebfedea0SLionel Sambuc [JFIF] JPEG File Interchange Format (Version 1.02). 4563*ebfedea0SLionel Sambuc Eric Hamilton, C-Cube Microsystems, Milpitas, CA, 4564*ebfedea0SLionel Sambuc September 1, 1992. 4565*ebfedea0SLionel Sambuc 4566*ebfedea0SLionel Sambuc [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP 4567*ebfedea0SLionel Sambuc Message Exchange Formats", RFC 1991, August 1996. 4568*ebfedea0SLionel Sambuc 4569*ebfedea0SLionel Sambuc [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4570*ebfedea0SLionel Sambuc Requirement Level", BCP 14, RFC 2119, March 1997. 4571*ebfedea0SLionel Sambuc [RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet 4572*ebfedea0SLionel Sambuc Mail Extensions (MIME) Part One: Format of Internet 4573*ebfedea0SLionel Sambuc Message Bodies.", RFC 2045, November 1996. 4574*ebfedea0SLionel Sambuc 4575*ebfedea0SLionel Sambuc [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 4576*ebfedea0SLionel Sambuc 2144, May 1997. 4577*ebfedea0SLionel Sambuc 4578*ebfedea0SLionel Sambuc [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for 4579*ebfedea0SLionel Sambuc Writing an IANA Considerations Section in RFCs", 4580*ebfedea0SLionel Sambuc BCP 26, RFC 2434, October 1998. 4581*ebfedea0SLionel Sambuc [RFC2822] Resnick, P., "Internet Message Format", RFC 2822. 4582*ebfedea0SLionel Sambuc 4583*ebfedea0SLionel Sambuc [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, 4584*ebfedea0SLionel Sambuc "MIME Security with OpenPGP", RFC 3156, 4585*ebfedea0SLionel Sambuc August 2001. 4586*ebfedea0SLionel Sambuc 4587*ebfedea0SLionel Sambuc [RFC3447] B. Kaliski and J. Staddon, "PKCS #1: RSA 4588*ebfedea0SLionel Sambuc Cryptography Specifications Version 2.1", 4589*ebfedea0SLionel Sambuc RFC 3447, February 2003. 4590*ebfedea0SLionel Sambuc 4591*ebfedea0SLionel Sambuc 4592*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 82] 4593*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4594*ebfedea0SLionel Sambuc 4595*ebfedea0SLionel Sambuc [RFC3629] Yergeau., F., "UTF-8, a transformation format of 4596*ebfedea0SLionel Sambuc Unicode and ISO 10646", RFC 3629, November 2003. 4597*ebfedea0SLionel Sambuc 4598*ebfedea0SLionel Sambuc [RFC4086] Eastlake, D., Crocker, S. and J. Schiller, 4599*ebfedea0SLionel Sambuc "Randomness Recommendations for Security", RFC 4600*ebfedea0SLionel Sambuc 4086, June 2005. 4601*ebfedea0SLionel Sambuc 4602*ebfedea0SLionel Sambuc [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: 4603*ebfedea0SLionel Sambuc protocols, algorithms, and source code in C", 1996. 4604*ebfedea0SLionel Sambuc 4605*ebfedea0SLionel Sambuc [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. 4606*ebfedea0SLionel Sambuc Hall, and N. Ferguson, "The Twofish Encryption 4607*ebfedea0SLionel Sambuc Algorithm", John Wiley & Sons, 1999. 4608*ebfedea0SLionel Sambuc 4609*ebfedea0SLionel Sambuc 4610*ebfedea0SLionel Sambuc18. References (Informative) 4611*ebfedea0SLionel Sambuc 4612*ebfedea0SLionel Sambuc 4613*ebfedea0SLionel Sambuc [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal 4614*ebfedea0SLionel Sambuc signatures without knowing the secret key," 4615*ebfedea0SLionel Sambuc Eurocrypt 96. Note that the version in the 4616*ebfedea0SLionel Sambuc proceedings has an error. A revised version is 4617*ebfedea0SLionel Sambuc available at the time of writing from 4618*ebfedea0SLionel Sambuc <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti 4619*ebfedea0SLionel Sambuc /isc/ElGamal.ps> 4620*ebfedea0SLionel Sambuc 4621*ebfedea0SLionel Sambuc [JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier 4622*ebfedea0SLionel Sambuc "Implementation of Chosen-Ciphertext Attacks 4623*ebfedea0SLionel Sambuc against PGP and GnuPG" 4624*ebfedea0SLionel Sambuc http://www.counterpane.com/pgp-attack.html 4625*ebfedea0SLionel Sambuc 4626*ebfedea0SLionel Sambuc [MAURER] Ueli Maurer, "Modelling a Public-Key 4627*ebfedea0SLionel Sambuc Infrastructure", Proc. 1996 European Symposium on 4628*ebfedea0SLionel Sambuc Research in Computer Security (ESORICS' 96), 4629*ebfedea0SLionel Sambuc Lecture Notes in Computer Science, Springer-Verlag, 4630*ebfedea0SLionel Sambuc vol. 1146, pp. 325-350, Sep 1996. 4631*ebfedea0SLionel Sambuc 4632*ebfedea0SLionel Sambuc [MZ05] Serge Mister, Robert Zuccherato, "An Attack on 4633*ebfedea0SLionel Sambuc CFB Mode Encryption As Used By OpenPGP," IACR 4634*ebfedea0SLionel Sambuc ePrint Archive: Report 2005/033, 8 Feb 2005 4635*ebfedea0SLionel Sambuc http://eprint.iacr.org/2005/033 4636*ebfedea0SLionel Sambuc 4637*ebfedea0SLionel Sambuc [RFC1423] Balenson, D., "Privacy Enhancement for Internet 4638*ebfedea0SLionel Sambuc Electronic Mail: Part III: Algorithms, Modes, and 4639*ebfedea0SLionel Sambuc Identifiers", RFC 1423, October 1993. 4640*ebfedea0SLionel Sambuc 4641*ebfedea0SLionel Sambuc [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format 4642*ebfedea0SLionel Sambuc Specification version 1.3.", RFC 1951, May 1996. 4643*ebfedea0SLionel Sambuc 4644*ebfedea0SLionel Sambuc [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and 4645*ebfedea0SLionel Sambuc Thayer, R. "OpenPGP Message Format", RFC 2440, 4646*ebfedea0SLionel Sambuc November, 1998. 4647*ebfedea0SLionel Sambuc 4648*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 83] 4649*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4650*ebfedea0SLionel Sambuc 4651*ebfedea0SLionel Sambuc [SP800-57] NIST Special Publication 800-57, Recommendation on 4652*ebfedea0SLionel Sambuc Key Management 4653*ebfedea0SLionel Sambuc <http://csrc.nist.gov/publications/nistpubs/ 4654*ebfedea0SLionel Sambuc 800-57/SP800-57-Part1.pdf> 4655*ebfedea0SLionel Sambuc <http://csrc.nist.gov/publications/nistpubs/ 4656*ebfedea0SLionel Sambuc 800-57/SP800-57-Part2.pdf> 4657*ebfedea0SLionel Sambuc 4658*ebfedea0SLionel Sambuc 4659*ebfedea0SLionel Sambuc19. Full Copyright Statement 4660*ebfedea0SLionel Sambuc 4661*ebfedea0SLionel Sambuc Copyright (C) 2007 by The IETF Trust. 4662*ebfedea0SLionel Sambuc 4663*ebfedea0SLionel Sambuc This document is subject to the rights, licenses and restrictions 4664*ebfedea0SLionel Sambuc contained in BCP 78, and except as set forth therein, the authors 4665*ebfedea0SLionel Sambuc retain all their rights. 4666*ebfedea0SLionel Sambuc 4667*ebfedea0SLionel Sambuc This document and the information contained herein are provided on 4668*ebfedea0SLionel Sambuc an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 4669*ebfedea0SLionel Sambuc REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 4670*ebfedea0SLionel Sambuc IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 4671*ebfedea0SLionel Sambuc WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 4672*ebfedea0SLionel Sambuc WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 4673*ebfedea0SLionel Sambuc ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 4674*ebfedea0SLionel Sambuc FOR A PARTICULAR PURPOSE. 4675*ebfedea0SLionel Sambuc 4676*ebfedea0SLionel Sambuc This document and translations of it may be copied and furnished to 4677*ebfedea0SLionel Sambuc others, and derivative works that comment on or otherwise explain it 4678*ebfedea0SLionel Sambuc or assist in its implementation may be prepared, copied, published 4679*ebfedea0SLionel Sambuc and distributed, in whole or in part, without restriction of any 4680*ebfedea0SLionel Sambuc kind, provided that the above copyright notice and this paragraph 4681*ebfedea0SLionel Sambuc are included on all such copies and derivative works. However, this 4682*ebfedea0SLionel Sambuc document itself may not be modified in any way, such as by removing 4683*ebfedea0SLionel Sambuc the copyright notice or references to the Internet Society or other 4684*ebfedea0SLionel Sambuc Internet organizations, except as needed for the purpose of 4685*ebfedea0SLionel Sambuc developing Internet standards in which case the procedures for 4686*ebfedea0SLionel Sambuc copyrights defined in the Internet Standards process must be 4687*ebfedea0SLionel Sambuc followed, or as required to translate it into languages other than 4688*ebfedea0SLionel Sambuc English. 4689*ebfedea0SLionel Sambuc 4690*ebfedea0SLionel Sambuc The limited permissions granted above are perpetual and will not be 4691*ebfedea0SLionel Sambuc revoked by the Internet Society or its successors or assigns. 4692*ebfedea0SLionel Sambuc 4693*ebfedea0SLionel Sambuc20. Intellectual Property 4694*ebfedea0SLionel Sambuc 4695*ebfedea0SLionel Sambuc The IETF takes no position regarding the validity or scope of any 4696*ebfedea0SLionel Sambuc Intellectual Property Rights or other rights that might be claimed 4697*ebfedea0SLionel Sambuc to pertain to the implementation or use of the technology described 4698*ebfedea0SLionel Sambuc in this document or the extent to which any license under such 4699*ebfedea0SLionel Sambuc rights might or might not be available; nor does it represent that 4700*ebfedea0SLionel Sambuc it has made any independent effort to identify any such rights. 4701*ebfedea0SLionel Sambuc Information on the procedures with respect to rights in RFC 4702*ebfedea0SLionel Sambuc documents can be found in BCP 78 and BCP 79. 4703*ebfedea0SLionel Sambuc 4704*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 84] 4705*ebfedea0SLionel SambucINTERNET-DRAFT OpenPGP Message Format Apr 24, 2007 4706*ebfedea0SLionel Sambuc 4707*ebfedea0SLionel Sambuc Copies of IPR disclosures made to the IETF Secretariat and any 4708*ebfedea0SLionel Sambuc assurances of licenses to be made available, or the result of an 4709*ebfedea0SLionel Sambuc attempt made to obtain a general license or permission for the use 4710*ebfedea0SLionel Sambuc of such proprietary rights by implementers or users of this 4711*ebfedea0SLionel Sambuc specification can be obtained from the IETF on-line IPR repository 4712*ebfedea0SLionel Sambuc at http://www.ietf.org/ipr. 4713*ebfedea0SLionel Sambuc 4714*ebfedea0SLionel Sambuc The IETF invites any interested party to bring to its attention any 4715*ebfedea0SLionel Sambuc copyrights, patents or patent applications, or other proprietary 4716*ebfedea0SLionel Sambuc rights that may cover technology that may be required to implement 4717*ebfedea0SLionel Sambuc this standard. Please address the information to the IETF at 4718*ebfedea0SLionel Sambuc ietf-ipr@ietf.org. 4719*ebfedea0SLionel Sambuc 4720*ebfedea0SLionel Sambuc 4721*ebfedea0SLionel Sambuc 4722*ebfedea0SLionel Sambuc 4723*ebfedea0SLionel Sambuc 4724*ebfedea0SLionel Sambuc 4725*ebfedea0SLionel Sambuc 4726*ebfedea0SLionel Sambuc 4727*ebfedea0SLionel Sambuc 4728*ebfedea0SLionel Sambuc 4729*ebfedea0SLionel Sambuc 4730*ebfedea0SLionel Sambuc 4731*ebfedea0SLionel Sambuc 4732*ebfedea0SLionel Sambuc 4733*ebfedea0SLionel Sambuc 4734*ebfedea0SLionel Sambuc 4735*ebfedea0SLionel Sambuc 4736*ebfedea0SLionel Sambuc 4737*ebfedea0SLionel Sambuc 4738*ebfedea0SLionel Sambuc 4739*ebfedea0SLionel Sambuc 4740*ebfedea0SLionel Sambuc 4741*ebfedea0SLionel Sambuc 4742*ebfedea0SLionel Sambuc 4743*ebfedea0SLionel Sambuc 4744*ebfedea0SLionel Sambuc 4745*ebfedea0SLionel Sambuc 4746*ebfedea0SLionel Sambuc 4747*ebfedea0SLionel Sambuc 4748*ebfedea0SLionel Sambuc 4749*ebfedea0SLionel Sambuc 4750*ebfedea0SLionel Sambuc 4751*ebfedea0SLionel Sambuc 4752*ebfedea0SLionel Sambuc 4753*ebfedea0SLionel Sambuc 4754*ebfedea0SLionel Sambuc 4755*ebfedea0SLionel Sambuc 4756*ebfedea0SLionel Sambuc 4757*ebfedea0SLionel Sambuc 4758*ebfedea0SLionel Sambuc 4759*ebfedea0SLionel Sambuc 4760*ebfedea0SLionel SambucCallas, et al. Expires Oct 24, 2007 [Page 85] 4761*ebfedea0SLionel Sambuc 4762*ebfedea0SLionel Sambuc 4763