idnits 2.17.1 draft-moscaritolo-openpgp-literal-01.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 date (April 08, 2011) is 4766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 214, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force V. Moscaritolo, Ed. 3 Internet-Draft PGP, part of Symantec 4 Intended status: Informational Corporation 5 Expires: October 10, 2011 April 08, 2011 7 Media type literal packet in OpenPGP 8 draft-moscaritolo-openpgp-literal-01 10 Abstract 12 This document describes an extension to the OpenPGP Message Format 13 that allows a Internet Media Type to be associated with the encoded 14 content. By providing more information beyond the existing binary 15 and text formats this extension can enable the automated selection of 16 an appropriate media viewer for the decoded content. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 10, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Literal Data packet . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Example of literal packet taged with a media type . . . . . . . 4 56 5. OpenPGP Implementation Considerations. . . . . . . . . . . . . 4 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 10.1. Normative References . . . . . . . . . . . . . . . . . . . 5 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 This document describes an extension to the OpenPGP Message Format 69 that allows a Internet Media Type (aka RFC-2046 MIME type) to be 70 associated with the encoded content. By providing more information 71 beyond the existing binary and text formats this extension and can 72 enable the automated selection of an appropriate media viewer for the 73 decoded content. 75 2. Terms 77 o OpenPGP - This is a term for security software that uses PGP 5.x 78 as a basis, formalized in RFC 4880 [RFC4880]. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 3. Literal Data packet 86 The OpenPGP RFC 4880 [RFC4880] currently specifies only a few formats 87 for encoded content: text, binary and UTF-8. The format itself of 88 the content is specified in section 5.9 as part of the Literal Data 89 packet (Tag 11). In addition to the body of the message being 90 encoded, this packet also contains a one-octet field that describes 91 how the data is formatted. 93 The current choices are 'b' (0x62), in which case the Literal packet 94 contains binary data and 't' (0x74) which describes text data and 'u' 95 (0x75) for UTF-8 Data. 97 This field is followed by a file name as a string (one-octet length, 98 followed by a file name). While not detailed in the RFC, most 99 implementations of PGP also add a trailing null at the end of the 100 file name but use the string length to skip to the next field. 102 We propose to add a new formatting type of 'm' (0x6d) to describe 103 that there is a RFC 2046 [RFC2046] Internet media type associated 104 with the literal data. In the case of a 'm' format type, the media 105 type is appended to the end of the null terminated file name, while 106 extending the file name length byte to accommodate this additional 107 information. 109 4. Example of literal packet taged with a media type 111 The following is an example of a Literal Data packet (Tag 11) that 112 specifies the media type format image/jpeg for a file named 113 'somedata.jpg' 115 0000 6d 17 73 6f 6d 65 64 61 74 61 2e 6a 70 67 00 69 |m.somedata.jpg.i| 116 0010 6d 61 67 65 2f 6a 70 65 67 |mage/jpeg | 118 5. OpenPGP Implementation Considerations. 120 OpenPGP implementations supporting the media literal data packet 121 format SHOULD use the media type string to select the appropriate 122 viewer for the encoded content. Implementations should consider the 123 following possibilities: 125 o As with the existing file name field, the string length can be 126 zero bytes long, indicating that there is no file name or media 127 type specified. 129 o There might be no null byte at the end of the file name, or no 130 additional bytes specified in the file name string length, 131 indicating that there is no media type specified. 133 o The file string could have bytes specified but start with a null 134 byte, this indicates that no file name is specified but that this 135 is a media type associated with the content. 137 o The media type MAY have an OPTIONAL null byte termination. Any 138 data that follows such a null byte should be discarded and not 139 considered part of the media type. 141 o While the one-octet length of the file name field does limit the 142 combined length of suggested file name and media type, it does 143 allow for some reasonable usage. In the case of combined length 144 of suggested file name and media type string that exceeds 255 145 bytes, priority should be given to the media type string, and 146 truncation of the filename is suggested. if such truncation should 147 occur it is suggested that the file name extension be preserved. 149 In the long run, a more correct method of associated media type with 150 content might employ one of the experimental tags mentioned in 151 RFC 4880 [RFC4880] section 13.10. 153 6. Acknowledgements 155 The author would like to acknowledge the help of many individuals who 156 helped in particular Derek Atkins, Jon Callas, David Shaw, Damon 157 Cokenias, David Finkelstein, Hal Finney and Will Price. 159 7. Contributors 161 Damon Cokenias, David Shaw, Derek Atkins and Jon Callas provided 162 important criticism on compliance with OpenPGP RFC 4880 [RFC4880]. 164 8. IANA Considerations 166 This memo includes no request to IANA. 168 9. Security Considerations 170 o The addition of a media type string increases the possibility of 171 truncation of a large file name field in the Literal Packet. 173 o The addition of media type string after the file name string null 174 termination does not add any hidden channels that didn't 175 potentially exist in the OpenPGP protocol. 177 o Since the signature hash of an RFC 4880 [RFC4880] OpenPGP message 178 does not cover the literal packet metadata, it is possible for an 179 attacker to modify both the filename and format field without 180 invalidating the signature. When using this media type extension 181 there is a possibility that an attacker to force a particular 182 content handler to run on the decoding implementation. 184 o In order to prevent modification of the media type, encrypting and 185 encapsulating the Literal Data packet using the Symmetrically 186 Encrypted Integrity Protected Data Packet (Tag 18) as specified in 187 OpenPGP RFC 4880 [RFC4880] is highly recommended. 189 10. References 191 10.1. Normative References 193 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 194 Extensions (MIME) Part Two: Media Types", RFC 2046, 195 November 1996. 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 201 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 203 10.2. Informative References 205 [I-D.narten-iana-considerations-rfc2434bis] 206 Narten, T. and H. Alvestrand, "Guidelines for Writing an 207 IANA Considerations Section in RFCs", 208 draft-narten-iana-considerations-rfc2434bis-09 (work in 209 progress), March 2008. 211 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 212 June 1999. 214 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 215 Text on Security Considerations", BCP 72, RFC 3552, 216 July 2003. 218 Author's Address 220 Vinnie Moscaritolo (editor) 221 PGP, part of Symantec Corporation 222 Mountain View, CA 223 US 225 Email: vinnie@pgp.com