[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OpenPGP agenda for Dec 7
From: "John W. Noerenberg" <jwn2@xxxxxxxxxxxx>
Subject: OpenPGP agenda for Dec 7
Date: Mon, 30 Nov 1998 11:47:13 -0800
> It is too late for it to appear in the I-D directory, however, I've
> suggested Kazu send it to the mailing list in advance of the meeting,
> so you have a chance to see it.
Attached is a OpenPGP/MIME ID. Since this ID has not been submitted,
you should refer this as #rev 00.00.
Many things, including the author list, are tentative. (Some ideas
came from Thomas Roessler.)
--Kazu
#rev 00.00
Internet-Draft K. Yamamoto
IIJ Research Laboratory
Expires in six months December, 1998
MIME Security with OpenPGP (OpenPGP/MIME)
<draft-ietf-openpgp-pgpmime-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
working 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 learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
This memo specifies how to protect a MIME object within an OpenPGP
object and how to embed the OpenPGP object to 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.
This memo aims to specify how to protect a MIME object within an
OpenPGP object and how to embed the OpenPGP object to 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 object
presented in the format define in [OldPGP] and in [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
This memo uses terms which are in capital letters. When the terms
"MUST", "SHOULD", "MUST NOT", "SHOULD NOT", "MAY", "REQUIRED" and
"RECOMMENDED" appear capitalized, they are being used to indicate
particular requirements, whose definitions are found 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 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 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 conforms the spec defined in this memo are called
OpenPGP/MIME composer. An OpenPGP/MIME composer consists of a MIME
composer and an OpenPGP engine.
The MIME composer creates MIME objects, which consist of a content
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 are also careless 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 an
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 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 follows 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 conforms the spec defined in this memo are called
OpenPGP/MIME viewer. An OpenPGP/MIME composer 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 are also careless 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
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 follows 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
wherever PGP or OpenPGP objects are used.
However, ASCII Armor is not so efficient to maintain backward
compatibility with "MIME-unaware but PGP-aware" viewers as it is
expected. Moreover, MIME encodings are more suitable than ASCII
Armor in the context of MIME. So, OpenPGP/MIME should prepare the
migration from ASCII Armor to native raw binary octets encoded with
a MIME encoding (such as base64).
To achieve this, throughout this memo, the followings are required
wherever PGP or OpenPGP objects are used.
(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 SIGNATUREE-----" string.
OpenPGP/MIME composer SHOULD generate the latter and MAY
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 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
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 spec 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.
(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.
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 OpenPGP/MIME viewers.
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 operation can be implemented for multiple hashes in
MIME level. However, hash calculation is closed in 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 are actually used in an OpenPGP
object produced by the OpenPGP engine. Remember that OpenPGP
objects are opaque for the MIME composer.
The author believes that the micalg parameter should be optional
and the spec 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 a ElGamal/DSS
secret key for OpenPGP. OpenPGP/MIME composers SHOULD create a
detached signature of OpenPGP (excluding PGP) by default.
OpenPGP/MIME composers MAY create a detached signature of PGP
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.
NOTE:
Multipart/Signed requires to convert a MIME object to 7bit
before calculating a signature. This is because, at the time of
the standardization of security multipart, several message
transfer agents(MTA) converts 8bit messages into 7bit in some
cases during deliveries.
Most MTAs are 8bit clean nowadays. The 7bit restriction is too
strong since there is strong demand for 8bit messages without
any encoding, typically to transfer European charcter sets.
Moreover, the 7bit restriction makes OpenPGP/MIME composers very
complicated. Consider this scenario. There is a MIME message
whose body contains an 8bit European character set. A user want
to attach it onto a new message and to signed it with
OpenPGP/MIME. If the 7bit restriction should be applied,
OpenPGP/MIME composers must analyze the 8bit MIME message first,
then convert the body (not the entire message) into 7bit with an
appropriate MIME encoding.
A worse senario it that, if a message is deeply recursed and one
part is 8bit, OpenPGP/MIME composers must analyze the message
and encode the 8bit MIME object.
If 8bit is allowed, such complicated procedures can be omitted.
Even if 8bit is allowed, "binary" MIME objects must be converted
into 7bit when signed. However, such binary objects are rare
cases.
The author believes that 8bit MIME objects should be allowed in
multipart/signed.
7. The Encryption Service
For the encryption service of OpenPGP/MIME, multipart/encrypted is
used. 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
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 an MIME encoding. The content body
MAY be encoded with an appropriate MIME encoding(line delimiters
are converted by 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 encryptes 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.
IMPLEMENATION NOTE:
The OpenPGP engine selects 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 two 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 for the signed-then-encrypted service.
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
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) considering as if the multipart/signed
object is 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 extract 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 analyze the MIME object in the context of MIME.
OpenPGP/MIME viewers MUST ignore the first part even if it doesn't
conform to the format defined in Section 7.
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 extract 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 verify the signature with the former MIME
object and the OpenPGP object. A resulting report (on
verification) is passed to the MIME viewer.
(5) The MIME viewer analyze the latter MIME object in the context of
MIME.
OpenPGP/MIME viewers MUST ignore objects in literal packets if 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 exists.
IMPLEMENTATION NOTE:
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 that this object is 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 success. 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
(2) 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.
# How about raw binary data?
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
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 is signs or
encrypts or signs-then-encrypts 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.
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";
--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--
(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;
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
To be written.
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@xxxxxxxxxx
Open Problems
RFC 1847:
- Should make the micalg parameter optional?
- Should allow 8bit objects for the signature service?
- Clearly say that the protocol parameter is case-insensitive.
Misc:
- Should define error handlings when parameter mismatch
(e.g. the protocol parameter vs. the first/second part)
- Multiple signatures.
Changes from RFC 2015
To be written.