idnits 2.17.1 draft-bray-pgp-message-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2014) is 3479 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Bray, Ed. 3 Internet-Draft Textuality 4 Intended status: Standards Track October 16, 2014 5 Expires: April 19, 2015 7 The OpenPGP Message Format 8 draft-bray-pgp-message-00 10 Abstract 12 RFC 4880 specifies the encoding for encrypted OpenPGP messages. This 13 document registers an Internet Media Type for these messages. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 19, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 63 2. OpenPGP Message . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 5. Interoperability Considerations . . . . . . . . . . . . . . . 5 67 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The OpenPGP message format, specified in [RFC4880], is widely 74 supported, with implementations in many programming languages. 76 [RFC3156] specifies the "multipart/encrypted" media type to describe 77 these messages; the "application/pgp-encrypted", "application/pgp- 78 signature", and "application/pgp-keys" media types are specified for 79 use as protocol parameter values and the content type of the MIME 80 body parts. 82 Currently, there exist popular applications which specialize in the 83 interchange of pure text payloads. These can be used for the 84 transport of OpenPGP messages (perhaps on a copy-and-paste basis), 85 but they typically do not support multipart messages and thus would 86 have difficulty with RFC3156-style packaging. It would be 87 advantageous if these "naked" OpenPGP messages could be labeled with 88 a media type to facilitate dispatch to software which can decrypt 89 them. 91 1.1. Conventions Used in This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 The grammatical rules in this document are to be interpreted as 98 described in [RFC5234]. 100 2. OpenPGP Message 102 The format of OpenPGP Messages is described in [RFC4880]. Messages 103 can be encoded in one of two formats: binary (section 11.3) or 104 textual "ASCII-armored" (sections 2.4 and 6). 106 A single media type serves to identify both, since they are trivially 107 distinguishable. 109 A binary message is a sequence of "packets", each of which has a 110 header (see section 4 of RFC4880) beginning with a "tag" byte, which 111 must have the high-order bit set. 113 The syntax of an ASCII-armored message is specified in detail in 114 RFC4880 Section 6. This specification will not create ABNF to 115 replicate that specification, since it is widely understood and there 116 are many successful software implementations which consume it. 117 However, it begins with a leading hyphen ("-", U+002D HYPHEN-MINUS). 119 For flexibiity and better support of copy/paste operation, this 120 specification alows the body of an application/pgp-message to have 121 insignificant white space ("ws" in the production below) surrounding 122 the ASCII-Armored form of the message. Popular implementations are 123 observed to ignore such white space. 125 ws = *( 126 %x20 / ; Space 127 %x09 / ; Horizontal tab 128 %x0A / ; Line feed or New line 129 %x0D ) ; Carriage return 131 Thus, software receiving a message labeled with the application/pgp- 132 message media type can straightforwardly decide how to parse it. If 133 the high-order bit of the first byte is set, then such software MUST 134 attempt to parse it as a binary OpenPGP message as specified in 135 RFC4880 section 11.3. Otherwise, if the first byte is a hyphen, or 136 matches the "ws" production above, such software MUST attempt to 137 parse it as an ASCII-Armored OpenPGP message as specified in RFC4880 138 section 6. If the first byte meets neither condition, the payload is 139 malformed and no parsing is possible. 141 3. IANA Considerations 143 The MIME media type for an OpenPGP Message is application/pgp- 144 message. 146 Type name: application 148 Subtype name: pgp-message 150 Required parameters: n/a 152 Optional parameters: n/a 154 Encoding considerations: binary 156 Security considerations: This document. 158 Interoperability considerations: Described in this document 160 Published specification: This document 162 Additional information: Magic number(s): n/a 163 File extension(s): .asc for ASCII-armored, none for binary 164 Macintosh file type code(s): TEXT 166 Person & email address to contact for further information: IESG 167 169 Intended usage: COMMON 171 Restrictions on usage: none 173 Author: Tim Bray 174 176 Change controller: IESG 177 179 4. Security Considerations 181 The presence of an OpenPGP message serves as notice that the sender 182 (and probably the receiver) have a strong desire to keep its contents 183 private. It is widely believed that messages encoded using modern 184 cryptography are extremely difficult for an adversary to decrypt. 185 Therefore, adversaries typically focus their attacks on end-point 186 software that may inadvertantly expose either the decryption key or 187 the payload of the message. 189 It is therefore RECOMMENDED that software which recognizes the 190 application/pgp media type dispatch the encrypted payload as-is to 191 other software which is known to be trusted by the user for purposes 192 of decryption. It is further RECOMMENDED that software which 193 recognizes the application/pgp-message media type actively try to 194 avoid storing the decrypted form of such messages or the keys used 195 for decryption, and furthermore actively avoid providing the user 196 interface used for interaction with the decryption software. 198 Implementers should also consult and pay careful attention to the 199 Security Considerations section of RFC4880. 201 5. Interoperability Considerations 203 RFC4880 notes that implementations SHOULD support the ASCII-Armored 204 representation of OpenPGP messages; this format has proven reasonably 205 resiliant to damage during transition over a variety of network 206 channels and, while it occupies more bytes of storage, is often 207 preferred for interchange over general-purpose messaging channels. 209 6. Example 211 This is an ASCII-Armored OpenPGP Message: 213 -----BEGIN PGP MESSAGE----- 214 Version: OpenPrivacy 0.99 216 yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS 217 vBSFjNSiVHsuAA== 218 =njUN 219 -----END PGP MESSAGE----- 221 7. Normative References 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, March 1997. 226 [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, 227 "MIME Security with OpenPGP", RFC 3156, August 2001. 229 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 230 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 232 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 233 Specifications: ABNF", STD 68, RFC 5234, January 2008. 235 Author's Address 237 Tim Bray (editor) 238 Textuality 240 Email: tbray@textuality.com