Internet DRAFT - draft-bray-pgp-message
draft-bray-pgp-message
Network Working Group T. Bray, Ed.
Internet-Draft Textuality
Intended status: Standards Track October 16, 2014
Expires: April 19, 2015
The OpenPGP Message Format
draft-bray-pgp-message-00
Abstract
RFC 4880 specifies the encoding for encrypted OpenPGP messages. This
document registers an Internet Media Type for these messages.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
Bray Expires April 19, 2015 [Page 1]
Internet-Draft PGP Message October 2014
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. OpenPGP Message . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Interoperability Considerations . . . . . . . . . . . . . . . 5
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The OpenPGP message format, specified in [RFC4880], is widely
supported, with implementations in many programming languages.
[RFC3156] specifies the "multipart/encrypted" media type to describe
these messages; the "application/pgp-encrypted", "application/pgp-
signature", and "application/pgp-keys" media types are specified for
use as protocol parameter values and the content type of the MIME
body parts.
Currently, there exist popular applications which specialize in the
interchange of pure text payloads. These can be used for the
transport of OpenPGP messages (perhaps on a copy-and-paste basis),
but they typically do not support multipart messages and thus would
have difficulty with RFC3156-style packaging. It would be
advantageous if these "naked" OpenPGP messages could be labeled with
a media type to facilitate dispatch to software which can decrypt
them.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Bray Expires April 19, 2015 [Page 2]
Internet-Draft PGP Message October 2014
The grammatical rules in this document are to be interpreted as
described in [RFC5234].
2. OpenPGP Message
The format of OpenPGP Messages is described in [RFC4880]. Messages
can be encoded in one of two formats: binary (section 11.3) or
textual "ASCII-armored" (sections 2.4 and 6).
A single media type serves to identify both, since they are trivially
distinguishable.
A binary message is a sequence of "packets", each of which has a
header (see section 4 of RFC4880) beginning with a "tag" byte, which
must have the high-order bit set.
The syntax of an ASCII-armored message is specified in detail in
RFC4880 Section 6. This specification will not create ABNF to
replicate that specification, since it is widely understood and there
are many successful software implementations which consume it.
However, it begins with a leading hyphen ("-", U+002D HYPHEN-MINUS).
For flexibiity and better support of copy/paste operation, this
specification alows the body of an application/pgp-message to have
insignificant white space ("ws" in the production below) surrounding
the ASCII-Armored form of the message. Popular implementations are
observed to ignore such white space.
ws = *(
%x20 / ; Space
%x09 / ; Horizontal tab
%x0A / ; Line feed or New line
%x0D ) ; Carriage return
Thus, software receiving a message labeled with the application/pgp-
message media type can straightforwardly decide how to parse it. If
the high-order bit of the first byte is set, then such software MUST
attempt to parse it as a binary OpenPGP message as specified in
RFC4880 section 11.3. Otherwise, if the first byte is a hyphen, or
matches the "ws" production above, such software MUST attempt to
parse it as an ASCII-Armored OpenPGP message as specified in RFC4880
section 6. If the first byte meets neither condition, the payload is
malformed and no parsing is possible.
Bray Expires April 19, 2015 [Page 3]
Internet-Draft PGP Message October 2014
3. IANA Considerations
The MIME media type for an OpenPGP Message is application/pgp-
message.
Type name: application
Subtype name: pgp-message
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: binary
Security considerations: This document.
Interoperability considerations: Described in this document
Published specification: This document
Additional information: Magic number(s): n/a
File extension(s): .asc for ASCII-armored, none for binary
Macintosh file type code(s): TEXT
Person & email address to contact for further information: IESG
<iesg@ietf.org>
Intended usage: COMMON
Restrictions on usage: none
Author: Tim Bray
<tbray@textuality.com>
Change controller: IESG
<iesg@ietf.org>
4. Security Considerations
The presence of an OpenPGP message serves as notice that the sender
(and probably the receiver) have a strong desire to keep its contents
private. It is widely believed that messages encoded using modern
cryptography are extremely difficult for an adversary to decrypt.
Therefore, adversaries typically focus their attacks on end-point
software that may inadvertantly expose either the decryption key or
the payload of the message.
Bray Expires April 19, 2015 [Page 4]
Internet-Draft PGP Message October 2014
It is therefore RECOMMENDED that software which recognizes the
application/pgp media type dispatch the encrypted payload as-is to
other software which is known to be trusted by the user for purposes
of decryption. It is further RECOMMENDED that software which
recognizes the application/pgp-message media type actively try to
avoid storing the decrypted form of such messages or the keys used
for decryption, and furthermore actively avoid providing the user
interface used for interaction with the decryption software.
Implementers should also consult and pay careful attention to the
Security Considerations section of RFC4880.
5. Interoperability Considerations
RFC4880 notes that implementations SHOULD support the ASCII-Armored
representation of OpenPGP messages; this format has proven reasonably
resiliant to damage during transition over a variety of network
channels and, while it occupies more bytes of storage, is often
preferred for interchange over general-purpose messaging channels.
6. Example
This is an ASCII-Armored OpenPGP Message:
-----BEGIN PGP MESSAGE-----
Version: OpenPrivacy 0.99
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA==
=njUN
-----END PGP MESSAGE-----
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Bray Expires April 19, 2015 [Page 5]
Internet-Draft PGP Message October 2014
Author's Address
Tim Bray (editor)
Textuality
Email: tbray@textuality.com
Bray Expires April 19, 2015 [Page 6]
