Internet-Draft K. Yamamoto
IIJ Research Laboratory
Expires in six months January, 1998
MIME Security with OpenPGP (OpenPGP/MIME)
<draft-yamamoto-openpgp-mime-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
documents as Internet-Drafts.
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".
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This memo specifies how to protect a MIME object within an OpenPGP
object and how to embed the OpenPGP object into a MIME object based
on security multipart.
1. Introduction
Pretty Good Privacy (PGP)[PGP] version 2 was a de facto standard of
cipher programs in the Internet. So, PGP version 2 was a good
candidate for security services of e-mail messages.
PGP version 2 itself has the cleartext signature format and ASCII
Armor[OldPGP] to exchange protected objects by e-mail. However,
these formats themselves are not suitable to be used in the context
of MIME[MIME].
Several efforts were made to integrate MIME and PGP version 2. As a
result, PGP/MIME[OldPGPMIME] based on security multipart[SECMULTI]
was standardized.
PGP version 2 depends on patented and/or licensed cryptographic
technologies. To be free from these problems and to introduce
richer functionality, OpenPGP[OpenPGP] (aka PGP version 5 or 6) has
been standardized. It is, thus, necessary to synchronize PGP/MIME
with OpenPGP.
Yamamoto [Page 1]
Internet-Draft OpenPGP/MIME January 1999
This memo aims to specify how to protect a MIME object within an
OpenPGP object and how to embed the OpenPGP object into a MIME
object based on security multipart. With this format, signature,
encryption, decryption, verification, and/or combined services are
available to protect security of MIME objects.
Throughout this memo, PGP object and OpenPGP object refer to objects
presented in the format define in [OldPGP] and [OpenPGP],
respectively. Note that the OpenPGP format is a super set of the
PGP format, so OpenPGP objects includes PGP objects. Also, PGP/MIME
and OpenPGP/MIME indicate the format defined in [OldPGPMIME] and in
this memo, respectively.
Readers are assumed to be familiar to [OpenPGP] and [OldPGPMIME].
2. Standard Keywords
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 [KEYWORDS].
3. Design Goals
The design goals of OpenPGP/MIME are as follows:
(1) OpenPGP/MIME should bring a security mechanism to MIME
objects, whose security level is the same as OpenPGP itself.
(2) OpenPGP/MIME should be more friendly to MIME-aware
viewers/composers than to PGP-aware viewers/composers. This
is because the number of MIME-aware viewers/composers is much
larger than that of PGP-aware viewers/composers.
(3) For the signature service, it is more important to deliver a
signed object itself than to protect the object. In other
words, it is more important for MIME viewers to extract the
object than to verify the signature.
(4) It is important to maintain backward compatibility with
PGP/MIME and to encourage the migration from PGP to OpenPGP.
4. Conceptual Model
This section describes conceptual model of the OpenPGP/MIME composer
and viewer. This conceptual model is descriptive and does NOT
impose any restrictions or requirements on implementations.
4.1 OpenPGP/MIME composer
Composers that conform to the specification defined in this memo are
called OpenPGP/MIME composers. An OpenPGP/MIME composer consists of
a MIME composer and an OpenPGP engine.
The MIME composer creates MIME objects, which consist of a content
Yamamoto [Page 2]
Internet-Draft OpenPGP/MIME January 1999
header and a content body. The MIME composer cannot create PGP or
OpenPGP objects. So, PGP or OpenPGP objects are opaque to the MIME
composer. The MIME composer also does not care about version control
for PGP and OpenPGP. However, the MIME composer may give control
information to the OpenPGP engine.
The OpenPGP engine signs and/or encrypts input data (which is a
MIME object), then produces a PGP or OpenPGP object. Version
control for PGP and OpenPGP, including packet formats and versions
for each packet type, is carried out by the OpenPGP engine. The
OpenPGP engine cannot create MIME objects.
Figure 1 illustrates this conceptual model of the OpenPGP/MIME composer
for the signature service.
An object to be signed
|
v
+---------------+
| MIME composer |---------+
+---------------+ | A MIME object to be signed*
| v
A MIME object | +--------------------------+
to be signed* | | OpenPGP signature engine |
| +--------------------------+
v |
+---------------+ | An OpenPGP object of
| MIME composer |<--------+ a detached signature
+---------------+
|
v
An OpenPGP/MIME object
Figure 1, the conceptual model of OpenPGP/MIME composer
Note: Data flows illustrated by arrows are different
for the signature and encryption services.
The two objects marked with "*" are copies in the
signature service.
4.2 OpenPGP/MIME viewer
Viewers that conform to the spececification defined in this memo are
called OpenPGP/MIME viewers. An OpenPGP/MIME viewer consists of a
MIME viewer and the OpenPGP engine.
The MIME viewer analyzes MIME objects. The MIME viewer cannot
analyze PGP or OpenPGP objects. So, PGP or OpenPGP objects are
opaque to the MIME viewer. The MIME viewer also does not care about
version control for PGP and OpenPGP. However, the MIME viewer may
give control information to the OpenPGP engine.
The OpenPGP engine decrypts and/or verifies a PGP or OpenPGP object
(then extracts plain output data, which is a MIME object, for the
decryption service). The OpenPGP engine cannot analyze MIME
Yamamoto [Page 3]
Internet-Draft OpenPGP/MIME January 1999
objects.
Figure 2 illustrates this conceptual model of OpenPGP/MIME viewer
for the verification service.
An OpenPGP/MIME object
|
v
+---------------+
| MIME viewer |---------+ The MIME object in the first part*
+---------------+ | The PGP object in the second part
| v
The MIME object | +-----------------------------+
in the first part* | | OpenPGP verification engine |
| +-----------------------------+
v |
+---------------+ | A report on verification
| MIME viewer |<--------+
+---------------+
|
v
The MIME object in the first part*
Figure 2, the conceptual model of OpenPGP/MIME viewer
Note: Data flows illustrated by arrows are different
for the decryption and verification services.
The two objects marked with "*" are copies in the
verification service.
5. PGP or OpenPGP object
PGP or OpenPGP objects can be represented by native raw binary
octets or by ASCII Armor. ASCII Armor was required for
PGP/MIME[OldPGPMIME] wherever PGP objects are used. However, MIME
viewers must accept MIME-encoded objects anyway. So, the following
are required wherever PGP or OpenPGP objects are used throughout
this memo:
(1) OpenPGP/MIME composers SHOULD generate PGP or OpenPGP
objects encoded with ASCII Armor. They SHOULD NOT generate
OpenPGP objects encoded with a MIME encoding.
(2) OpenPGP/MIME viewers MUST accept PGP or OpenPGP objects
encoded both with ASCII Armor and with a MIME encoding.
This requirement affects all PGP or OpenPGP objects including the
detached signature, the encryption, and the public key distribution.
NOTE:
There are two kinds of ASCII Armor boundary for a detached
signature. PGP uses the "-----BEGIN PGP MESSAGE-----" string
while OpenPGP uses the "-----BEGIN PGP SIGNATURE-----" string.
OpenPGP/MIME composer SHOULD generate the latter and MAY
Yamamoto [Page 4]
Internet-Draft OpenPGP/MIME January 1999
generate the former for backward compatibility. OpenPGP/MIME
viewer MUST accept both.
6. The Signature Service
For the signature service of OpenPGP/MIME, multipart/signed is used.
The value of the protocol parameter is "application/pgp-signature".
OpenPGP/MIME composers MUST generate the OpenPGP/MIME object defined
as follows:
Top level:
Content-Type: multipart/signed
Required parameters: boundary
Required parameters: protocol=application/pgp-signature
(case-insensitive)
Optional parameters: micalg (see below)
Optional parameters: domain (see below)
Content body is defined as follows:
The first part:
An MIME object to be signed.
Content-Transfer-Encoding: MUST be other than "binary".
The second part:
Content-Type: application/pgp-signature
Required parameters: none
Optional parameters: none
Content body: an OpenPGP object which contains a detached
signature
A multipart/signed object of OpenPGP/MIME is created as follows:
(1) The MIME composer prepares an object to be signed according to a
local convention.
(2) The MIME composer converts the object to a MIME object according
to the MIME canonical form. That is, a content header is
created and the object becomes a content body. The content body
MUST be in 7bit or 8bit. So, if the object is "binary", an
appropriate MIME encoding MUST be applied(line delimiters are
converted by the MIME encoding). Note that this specification
allows an "8bit" content body.
(3) The MIME object is copied. One MIME object will be passed to
the OpenPGP engine while the other MIME object will be the first
part of multipart/signed.
(4) The MIME composer or the OpenPGP engine converts line delimiters
of the latter MIME object (including those of the content
header) to <CR><LF>.
(5) The OpenPGP engine calculates a signature over the latter MIME
object and creates an OpenPGP object which contains the detached
signature.
Yamamoto [Page 5]
Internet-Draft OpenPGP/MIME January 1999
(6) The MIME composer creates a multipart/signed object. The first
part is the former MIME object created in step (3). The MIME
composer treates this object as opaque. The second part is the
OpenPGP object created in step (5). If this OpenPGP object is
native raw binary octets, an appropriate MIME encoding is
applied to it.
The OpenPGP object for the detached signature MUST NOT include
literal packets.
For the protocol parameter, "application/pgp-signature" SHOULD be
lower-case. Since both [SECMULTI] and [OldPGPMIME] doesn't clearly
say this parameter is case-insensitive, some PGP/MIME viewers may
accept lower-case only.
The micalg parameter MAY be omitted. Just in case, the micalg
parameter MAY be specified for multipart/signed. If specified, the
value of the micalg parameter SHOULD be "pgp-md5" or "pgp-sha1",
which will be ignored by OpenPGP/MIME viewers.
The domain parameter specifies whether or not 8bit characters are
contained in the first part. If contained, "8bit" MUST be
specified. Otherwise, "7bit" MAY be specified. (If this parameter
is not present, OpenPGP/MIME viewers treats that the first part
consists of 7bit characters only.)
NOTE:
PGP/MIME requires conversion of a MIME object to a 7bit content
transfer encoding before calculating a signature. This is
because several message transfer agents(MTA) convert 8bit
messages into 7bit in some cases during delivery.
Since there is strong demand for 8bit messages without any
encoding, typically to transfer European charcter sets,
OpenPGP/MIME allows to sign 8bit MIME objects. The domain
parameter associates the original content transfer encoding, so
OpenPGP/MIME viewers can tell the possibility of modification by
MTAs when verification fails.
If the domain parameter is not present, it is treated as "7bit",
which is exactly the same as PGP/MIME.
NOTE:
The micalg parameter is mandatory for multipart/signed. And
PGP/MIME defined the values of the micalg parameter. However,
this memo doesn't require the micalg parameter for two reasons.
The first reason is that this parameter is not necessary for
OpenPGP/MIME. The micalg parameter was designed hoping that
one-pass operations could be implemented to calculate a hash
value in the MIME level. However, hash calculation is closed in
Yamamoto [Page 6]
Internet-Draft OpenPGP/MIME January 1999
the OpenPGP engine in the conceptual model.
The second reason is that there is no perfect way for the MIME
composer to know which hash was actually used in an OpenPGP
object produced by the OpenPGP engine. Remember that OpenPGP
objects are opaque for the MIME composer.
The micalg parameter should be optional and the specification of
multipart/signed should be revised in the future.
IMPLEMENTATION NOTE:
A user may have two or more secret keys. For instance, one is
for an RSA secret key for PGP and the other is an ElGamal/DSS
secret key for OpenPGP. OpenPGP/MIME composers SHOULD create an
OpenPGP detached signature (excluding PGP) by default.
OpenPGP/MIME composers MAY create a PGP detached signature
for backward compatibility. OpenPGP/MIME composers SHOULD
provide a user with a mechanism to select which secret key is
used for signature calculation.
There are two ways to support multiple signatures. One is storing
them in an OpenPGP object. The other is storing a multipart/*
object in the second part. Such functionality is outside the scope
of this memo.
7. The Encryption Service
For the encryption service of OpenPGP/MIME, the content type
multipart/encrypted is used. The value of the protocol parameter is
"application/pgp-encrypted". OpenPGP/MIME composers MUST generate
the OpenPGP/MIME object defined as follows:
Top level:
Content-Type: multipart/encrypted
Required parameters: boundary
Required parameters: protocol=application/pgp-encrypted
(case-insensitive)
Optional parameters: none
Content body is defined as follows:
The first part:
Content-Type: application/pgp-encrypted
Required parameters: none
Optional parameters: none
Content body: "Version: 1"
Note: existence of this part is for historical reason.
The content body is meaningless while it seems to
control versions.
The second part:
Content-Type: application/octet-stream
Required parameters: none
Optional parameters: none
Yamamoto [Page 7]
Internet-Draft OpenPGP/MIME January 1999
Content body: an OpenPGP object which encrypts an MIME object.
A multipart/encrypted object of OpenPGP/MIME is created as follows:
(1) The MIME composer prepares an object to be signed according to a
local convention.
(2) The MIME composer converts the object to a MIME object according
to the MIME canonical form. That is, a content header is
created and the object becomes a content body. The content body
need not to be encoded with a MIME encoding. The content body
MAY be encoded with an appropriate MIME encoding(line delimiters
are converted to the MIME encoding).
(3) The MIME composer or the OpenPGP engine converts line delimiters
of the MIME object (including those of the content header) to
<CR><LF>.
(4) The OpenPGP engine encrypts the MIME object and creates an
OpenPGP object according to user IDs specified by the MIME
composer.
(5) The MIME composer creates a multipart/encrypted object. The
first part is the application/pgp-encrypted object defined
above. The second part is the OpenPGP object created in step
(4) which is labeled as application/octet-stream.
For the protocol parameter, "application/pgp-encrypted" SHOULD be
lower-case. Since both [SECMULTI] and [OldPGPMIME] doesn't clearly
say this parameter is case-insensitive, some PGP/MIME viewers accept
lower-case only.
IMPLEMENATION NOTE:
The OpenPGP engine selects receiver's public keys according to
the specified user IDs. For example, if there are two public
keys for a user ID, the OpenPGP engine may encrypt a session key
with both keys.
8. Combined Services
This section describes two typical combined services for
OpenPGP/MIME.
8.1 Signed-then-Encrypted Service
There are two methods for the signed-then-encrypted service. Note
that the two methods are identical in the service point of view.
8.1.1 Signed-then-Encrypted Service with Security Multipart
Signed-then-Encrypted service can be implemented combining with
multipart/signed and multipart/encrypted. OpenPGP/MIME composers
MAY produce this format. OpenPGP/MIME viewers MUST accept this
Yamamoto [Page 8]
Internet-Draft OpenPGP/MIME January 1999
format.
OpenPGP/MIME composers first create a multipart/signed object
according to the procedures defined in Section 6. Then they creates
a multipart/encrypted object according to the procedures defined in
Section 7 from step (3) as if the multipart/signed object was
created in step (1) and (2).
8.1.2 Signed-then-Encrypted Service with Atomic OpenPGP
The OpenPGP engine itself can create an OpenPGP object which
signs-then-encrypts input data. OpenPGP/MIME composers MAY produce
this format. OpenPGP/MIME viewers MUST accept this format.
OpenPGP/MIME composers create this format according to the
procedures defined in Section 7.
8.2 Encrypted-then-Signed Service
Encrypted-then-signed service can be implemented combining with
multipart/encrypted and multipart/signed. OpenPGP/MIME composers
MAY produce this format. OpenPGP/MIME viewers MUST accept this
format.
OpenPGP/MIME composers first create a multipart/encrypted object
according to the procedures defined in Section 7. Then they creates
a multipart/signed object according to the procedures defined in
Section 6 from step (3) considering as if the multipart/encrypted
object is created in step (1) and (2).
9. The Decryption Service
OpenPGP/MIME viewers MUST be able to decrypt the OpenPGP/MIME object
defined in Section 7 and 8. The decryption procedures are as
follows:
(1) The MIME viewer extracts the first part and the second part from
the multipart/encrypted object. The first part, the
application/pgp-encrypted object, is ignored. The OpenPGP
object stored in the second part is extracted by removing its
content header and decoding according to the value of
content transfer encoding.
(2) The OpenPGP engine extracts the MIME object by decrypting (and
verifying, if necessary) the OpenPGP object. Both the MIME
object and a resulting report (on decryption and verification)
are passed to the MIME viewer.
(3) The MIME viewer or the PGP engine converts line delimiters of
the MIME object into the local form.
(4) The MIME viewer analyzes the MIME object in the context of MIME.
OpenPGP/MIME viewers MUST ignore the first part even if it doesn't
Yamamoto [Page 9]
Internet-Draft OpenPGP/MIME January 1999
conform to the format defined in Section 7.
Mismatch between the value of the protocol parameter and the value
of content type in the first part would happen. This error
handling is implementation dependent.
IMPLEMENTATION NOTE:
OpenPGP/MIME viewers SHOULD inform the resulting report of step
(2) to users.
10. The Verification Service
OpenPGP/MIME viewers MUST be able to verify the OpenPGP/MIME object
defined in Section 6 and 8. The verification procedures are as
follows:
(1) The MIME viewer extracts the first part and the second part of
the multipart/encrypted object. The first part is the signed
MIME object. The OpenPGP object stored in the second part is
extracted by removing its content header and decoding according
to the value of content transfer encoding.
(2) The signed MIME object is copied. One MIME object will be
passed to the OpenPGP engine while the other MIME object will be
analyzed in the context of MIME later.
(3) The MIME viewer converts line delimiters of the former MIME
object into <CR><LF>.
(4) The OpenPGP engine verifies the signature with the former MIME
object and the OpenPGP object. A resulting report (on
verification) is passed to the MIME viewer.
(5) If the verification fails, the MIME viewer checks whether or not
the domain parameter has a correct value. If the value is
"8bit" and the first part consists of 7bit characters only, the
first part may be alternated by MTAs.
(6) The MIME viewer analyzes the latter MIME object in the context of
MIME.
OpenPGP/MIME viewers MUST ignore objects in literal packets if they
exist and MUST accept the first part of the multipart/signed object
as the signed MIME object.
OpenPGP/MIME viewers MUST ignore the micalg parameter if it exists.
Mismatch between the value of the protocol parameter and the value
of content type in the second part would happen. This error
handling is implementation dependent.
IMPLEMENTATION NOTE:
Yamamoto [Page 10]
Internet-Draft OpenPGP/MIME January 1999
The PGP/OpenPGP signature packet specified has "canonical text
document" type and "binary document" type. PGP/MIME and
OpenPGP/MIME allows these two types for the signature service.
On signature calculation, for canonical text document, line
delimiters are converted into <CR><LF> by the OpenPGP engine,
then a signature is calculated. For binary document, a
signature is calculated over the original input.
On verification, for canonical text document, the line
delimiters are first converted into <CR><LF> by the OpenPGP
engine, then verified. For binary documnt, verification is
carried out over the original input.
Suppose that an OpenPGP/MIME composer itself converts line
delimiters of a MIME object into <CR><LF> then calls the OpenPGP
engine telling it that this object is a binary document, the
signature type will be binary document. Please note that this
signature is valid in the context of OpenPGP/MIME and signature
verification should succeed. If another OpenPGP/MIME viewer on
a system whose line delimiter is <LF> calls the OpenPGP engine
without line delimiter conversion, the verification fails
because the OpenPGP engine never converts line delimiters of
binary document.
So, to verify signatures, the MIME viewer MUST convert line
delimiters of the first part to <CR><LF> by itself.
IMPLEMENTATION NOTE:
OpenPGP/MIME viewers SHOULD inform the resulting report of step
(5) and (6) to users.
11. Distribution of PGP Transferable Public Keys
To distribute PGP public keys in the context of MIME, the following
content type is defined:
Content-Type: application/pgp-keys
Required parameters: none
Optional parameters: none
OpenPGP/MIME composers MUST embed PGP public keys in this MIME
object. For a filename contained in Content-Disposition:, the
".asc" suffix SHOULD be used when encoded with ASCII Armor.
OpenPGP/MIME viewers MUST accept this format. OpenPGP/MIME viewers
MUST NOT automatically add the PGP public keys in this MIME object
to a public keyring for security reasons. OpenPGP/MIME viewers
SHOULD interact with a user to decide how to treat the PGP public
keys.
12. Historical Note
Yamamoto [Page 11]
Internet-Draft OpenPGP/MIME January 1999
Many ideas were proposed to integrate MIME and PGP in the past.
The first trial was the applicaton/pgp content type. An
applicaton/pgp MIME object embeds a PGP object, which it signs or
encrypts or signs-then-encrypts into a MIME object. This approach is
against the design goal (2). That is, it is difficult to extract
the inside MIME object from the PGP object even if it is a clear
text signature.
Multipart/signed achieves the design goal (2). If a MIME-aware
viewer doesn't know multipart/signed, it is treated as
multipart/mixed. So, the MIME object in the first part is easily
extracted.
[OldPGPMIME] adopts multipart/encrypted for encrypted PGP objects to
align to the standard way, security multipart. Since PGP or OpenPGP
doesn't have functionality to separate encrypted data and its
control keys, the first part of multipart/encrypted defined in this
memo is mostly empty.
If all security mechanisms adopt multipart/encrypted for encryption
services, MIME viewers can abstract reporting routines (that tell
users MIME objects were encrypted). However, S/MIME[SMIME] doesn't
adopt multipart/encrypted but does adopt the applicaton/* approach
for the encryption service. Thus, this merit is being lost. The
reason why this memo uses multipart/encrypted is just for backward
compatibility.
Another approach proposed time to time is the text/pgp, which embeds
a cleartext signature PGP object, for MIME-unaware but PGP-aware
viewers. This approach is against the design goal (2) and (3).
Note that since lines started with "-" are escaped in a cleartext
signature, it is hard for MIME-aware viwers to extract the original
object.
Yamamoto [Page 12]
Internet-Draft OpenPGP/MIME January 1999
13. Examples
This section contains examples of OpenPGP/MIME objects.
(1) The following is a simple OpenPGP/MIME object for the signature
service.
Content-Type: Multipart/Signed; boundary="simple"
protocol="application/pgp-signature";
domain="7bit"
--simple
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This is a text object to be signed with OpenPGP/MIME.
--simple
Content-Type: Application/Pgp-Signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: M13gFu827jrvjz0U5rM0iWLMfKpt2PzB
iQA/AwUANmJ8V6eXeOJHtjA3EQKOugCfUKYA9iw3KssVncR3hW2oSKKGFDAAn27d
m8dNeZ0d4UO9MLuCITa0sAS1
=czIa
-----END PGP SIGNATURE-----
--simple--
Yamamoto [Page 13]
Internet-Draft OpenPGP/MIME January 1999
(2) The following is a simple OpenPGP/MIME object for the encryption
service.
Content-Type: Multipart/Encrypted; boundary="simple"
protocol="application/pgp-encrypted";
--simple
Content-Type: Application/Pgp-Encrypted
Content-Transfer-Encoding: 7bit
Version: 1
--simple
Content-Type: Application/Octet-Stream
Content-Transfer-Encoding: 7bit
-----BEGIN PGP MESSAGE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: vdnh0wRmUsog31/QvX620a0hlwLtD+m5
hQCMAw9kihyeT3RNAQP/fLxae4lOuvZxWoZN62cm/3/9K2BSg0OphyqSQu6WVV7u
IPgbvaRqPz7ejJITXEtr+GVR01OEAOENxYTKU/s+vv//XQ1AOljWCuXBJRU0K/L0
Qm9kCw6vprAF8Mwm0QjquOx7PRd/GhqjK5PVBBuXPfFFqlE5ARtQ+27qPYLck7WF
AQ4DYDI64N0KZe0QBACjjBbDgTtYKVPW2J53DxnmwnNTH4t7GuDQ14jfzCYNOeFa
2rpxdd54NgtB932Kh0lyAY7JCAJG2oaKedT7w6owAkdX6bUw4T9RkkWCytsKLPcM
S35OoiLajnS9LXvY7EEEIrmXB2D5AFdPsBLOg9nOJy9giB98hk/OiSYvVqPzigP/
RLmgCjQwlqCGuxAmp9mpqI76mMXfpR5ZN7zXd0hjI2nh9Vnu9/DSUTrzn6mNV/Gt
xN7Afl6YIW/16FbwHozwve2vyJyCRT5XHvFe294eBkJvcdCIIOsW/IMT99NvK3rQ
CK7cwxe1nml33e/QMTh9F3mRibk9fQBQDgS4XOXob5Ckg8JfJbFEA3w5HmwUWfPl
sG0iXQJB6/pSCtV8m1ZBEgJSPSvcwWfR0MCgZr7uyvaxTDgIKE7fcX3a/DzGuYwc
XEWAudEYYjGSWDL21iLMj1g7FehsfDqZZBAMpOr+l/iSxjOypeDhZKYzf/qKK73r
HmgY23tNmMJndoiePbHf7a4KNcUD
=SXzQ
-----END PGP MESSAGE-----
--simple--
14. Security Consideration
This memo brings a security mechanism to protect MIME objects. The
security level of OpenPGP/MIME is believed the same as that of
OpenPGP.
References
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[MIME] The primary definition of MIME. "MIME Part 1: Format of
Internet Message Bodies", RFC 2045; "MIME Part 2: Media Types",
RFC 2046; "MIME Part 3: Message Header Extensions for Non-ASCII
Text", RFC 2047; "MIME Part 4: Registration Procedures", RFC
2048; "MIME Part 5: Conformance Criteria and Examples", RFC 2049;
Yamamoto [Page 14]
Internet-Draft OpenPGP/MIME January 1999
November 1996.
[OldPGP] D. Atkins, W. Stallings, and P. Zimmerman, "PGP Message
Exchange Formats", RFC 1991, August 1996.
[OldPGPMIME] M. Elkins, "MIME Security with Pretty Good Privacy
(PGP)", RFC2015, October 1996.
[OpenPGP] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer,
"OpenPGP Message Format", RFC2440, November 1998.
[PGP] P. Zimmermann, "The Official PGP User's Guide", MIT Press,
1995.
[SECMULTI] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC1847, October 1995.
[SMIME] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, and
L. Repka, "S/MIME Version 2 Message Specification", RFC 2311,
March 1998.
Acknowledgement
The author would acknowledge Thomas Roessler for discussing on
technical issues and Tony Mione for reviewing the earlier version of
this draft.
Authors' Addresses
Kazuhiko YAMAMOTO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho Chiyoda-ku, Tokyo
101-0054 JAPAN
Phone: +81-3-5259-6350
FAX: +81-3-5259-6351
EMail: kazu@iijlab.net
Open Problems
RFC 1847:
- Should make the micalg parameter optional?
- Should allow 8bit objects for the signature service?
Changes from RFC 2015
To be written.
Yamamoto [Page 15]