draft-ietf-pem-mime-07.txt   rfc1848.txt 
Network Working Group Steve Crocker Network Working Group S. Crocker
INTERNET DRAFT Ned Freed Request For Comments: 1848 CyberCash, Inc.
draft-ietf-pem-mime-07.txt Jim Galvin Category: Standards Track N. Freed
Sandy Murphy Innosoft International, Inc.
November 1994 J. Galvin
S. Murphy
Trusted Information Systems
October 1995
PEM Security Services and MIME MIME Object Security Services
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its Areas, and Internet community, and requests discussion and suggestions for
its Working Groups. Note that other groups may also distribute working improvements. Please refer to the current edition of the "Internet
documents as Internet Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet Drafts are valid for a maximum of six months and may be Abstract
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 This document defines MIME Object Security Services (MOSS), a
1id-abstracts.txt listing contained in one of the Internet Drafts Shadow protocol that uses the multipart/signed and multipart/encrypted
Directories on ds.internic.net (US East Coast), venera.isi.edu (US West framework [7] to apply digital signature and encryption services to
Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). MIME objects. The services are offered through the use of end-to-end
cryptography between an originator and a recipient at the application
layer. Asymmetric (public key) cryptography is used in support of
the digital signature service and encryption key management.
Symmetric (secret key) cryptography is used in support of the
encryption service. The procedures are intended to be compatible
with a wide range of public key management approaches, including both
ad hoc and certificate-based schemes. Mechanisms are provided to
support many public key management approaches.
Abstract Table of Contents
This document specifies how the services of MIME and PEM can be used in 1. Introduction ............................................. 3
a complementary fashion. MIME, an acronym for "Multipurpose Internet 2. Applying MIME Object Security Services ................... 4
Mail Extensions", defines the format of the contents of Internet mail 2.1 Digital Signature Service ............................... 4
messages and provides for multi-part textual and non-textual message 2.1.1 Canonicalization ...................................... 5
bodies. PEM, an acronym for "Privacy Enhanced Mail", provides message 2.1.2 Digital Signature Control Information ................. 7
authentication/integrity and message encryption services for Internet 2.1.2.1 Version: ............................................ 8
mail messages. 2.1.2.2 Originator-ID: ...................................... 8
2.1.2.3 MIC-Info: ........................................... 8
2.1.3 application/moss-signature Content Type Definition .... 9
2.1.4 Use of multipart/signed Content Type .................. 10
2.2 Encryption Service ...................................... 11
2.2.1 Encryption Control Information ........................ 12
2.2.1.1 DEK-Info: ........................................... 13
2.2.1.2 Recipient-ID: ....................................... 14
2.2.1.3 Key-Info: ........................................... 14
2.2.2 application/moss-keys Content Type Definition ......... 15
2.2.3 Use of multipart/encrypted Content Type ............... 16
3. Removing MIME Object Security Services ................... 17
3.1 Digital Signature Service ............................... 18
3.1.1 Preparation ........................................... 18
3.1.2 Verification .......................................... 19
3.1.3 Results ............................................... 19
3.2 Encryption Service ...................................... 20
3.2.1 Preparation ........................................... 20
3.2.2 Decryption ............................................ 20
3.2.3 Results ............................................... 21
4. Identifying Originators, Recipients, and Their Keys ...... 21
4.1 Name Forms .............................................. 23
4.1.1 Email Addresses ....................................... 23
4.1.2 Arbitrary Strings ..................................... 23
4.1.3 Distinguished Names ................................... 23
4.2 Identifiers ............................................. 24
4.2.1 Email Address ......................................... 25
4.2.2 Arbitrary String ...................................... 25
4.2.3 Distinguished Name .................................... 26
4.2.4 Public Key ............................................ 26
4.2.5 Issuer Name and Serial Number ......................... 27
5. Key Management Content Types ............................. 27
5.1 application/mosskey-request Content Type Definition ..... 28
5.2 application/mosskey-data Content Type Definition ........ 29
6. Examples ................................................. 31
6.1 Original Message Prepared for Protection ................ 31
6.2 Sign Text of Original Message ........................... 32
6.3 Sign Headers and Text of Original Message ............... 32
6.4 Encrypt Text of a Message ............................... 33
6.5 Encrypt the Signed Text of a Message .................... 35
6.6 Protecting Audio Content ................................ 37
6.6.1 Sign Audio Content .................................... 37
6.6.2 Encrypt Audio Content ................................. 37
7. Observations ............................................. 38
8. Comparison of MOSS and PEM Protocols ..................... 39
9. Security Considerations .................................. 41
10. Acknowledgements ........................................ 41
11. References .............................................. 41
12. Authors' Addresses ...................................... 43
Appendix A: Collected Grammar .............................. 44
Appendix B: Imported Grammar ............................... 47
An Internet electronic mail message consists of two parts: the headers 1. Introduction
and the body. The headers form a collection of field/value pairs
structured according to RFC822 [1], whilst the body, if structured, is
defined according to MIME [2]. MIME does not provide for the
application of security services.
PEM [3-6] specifies how to apply encryption and authentication/integrity MIME [2], an acronym for "Multipurpose Internet Mail Extensions",
services to the contents of a textual electronic mail message but does defines the format of the contents of Internet mail messages and
not provide message structuring or type labelling facilities. This provides for multi-part textual and non-textual message bodies. An
document specifies how to use PEM with the multipart/signed and Internet electronic mail message consists of two parts: the headers
multipart/encrypted MIME content types to provide and the body. The headers form a collection of field/value pairs
authentication/integrity and encryption services. We refer to the structured according to STD 11, RFC 822 [1], whilst the body, if
authentication/integrity service as a digital signature service. structured, is defined according to MIME. MIME does not provide for
the application of security services.
This document specifies a number of changes to the message encryption PEM [3-6], an acronym for "Privacy Enhanced Mail", defines message
and signature procedures of PEM and broadens the name forms that may be encryption and message authentication procedures for text-based
used to identify public keys. Many of the changes represent a departure electronic mail messages using a certificate-based key management
in mechanism, not in effect. mechanism. The specifications include several features that are
easily and more naturally supported by MIME, for example, the
transfer encoding operation, the Content-Domain header, and the
support services specified by its Part IV [6]. The specification is
limited by specifying the application of security services to text
messages only.
1. Introduction MOSS is based in large part on the PEM protocol as defined by RFC
1421. Many of PEMs features and most of its protocol specification
are included here. A comparison of MOSS and PEM may be found in
Section 8.
This document updates the message encryption and signature procedures In order to make use of the MOSS services, a user (where user is not
defined by [3] and replaces the key certification and related services limited to being a human, e.g., it could be a process or a role) is
defined by [6]. The changes to [3] include the separation of the required to have at least one public/private key pair. The public
encryption and signature services, the removal of the limitation to key must be made available to other users with whom secure
enhance only text-based messages, the removal of the transfer encoding communication is desired. The private key must not be disclosed to
operation, the deprecation of the Content-Domain: and Proc-Type: any other user.
headers, and the separation of certificate and certificate revocation
list transmission from the security enhancements. These changes
represent a departure in mechanism, not in effect, and are detailed in
Section 8.
In addition, this document specifies four technical changes to PEM: An originator's private key is used to digitally sign MIME objects; a
symmetric key management in [3] is deprecated, the canonicalization recipient would use the originator's public key to verify the digital
operation in [3] is generalized, the allowable name forms for the signature. A recipient's public key is used to encrypt the data
identification of public keys is broadened to include arbitrary strings encrypting key that is used to encrypt the MIME object; a recipient
and email addresses, and users may distribute their public keys directly would use the corresponding private key to decrypt the data
in lieu of certificates. encrypting key so that the MIME object can be decrypted.
The key certification and related services are replaced by the As long as the private keys are protected from disclosure, i.e., the
specification of two new MIME content types: application/key-request and private keys are accessible only to the user to whom they have been
application/key-data. These new content types are used to transmit assigned, the recipient of a digitally signed message will know from
requests for key operations (storage, retrieval, certification, whom the message was sent and the originator of an encrypted message
revocation list retrieval, etc.) and the responses to those requests. will know that only the intended recipient is able to read it. For
These two content types are independent body parts and are not required assurance, the ownership of the public keys used in verifying digital
to be encapsulated in any other body part. These changes represent a signatures and encrypting messages should be verified. A stored
departure in mechanism, not in effect, and are detailed in Section 8. public key should be protected from modification.
In order to make use of the PEM services, a user is required to have at The framework defined in [7] provides an embodiment of a MIME object
least one public/private key pair. Prior to this specification, the and its digital signature or encryption keys. When used by MOSS the
public key was required to be embodied in a certificate, an object that framework provides digital signature and encryption services to
binds a public key with a distinguished name, a name form that single and multi-part textual and non-textual MIME objects.
identified the owner of the public key. The embodiment was issued by a
certification authority, a role that was expected to be trustworthy
insofar as it verified the identity of the owner prior to issuing the
certificate. However, the deployment of certificates and the creation
of the hierarchy of certification authorities has been problematic.
Instead, this specification bases the PEM services on a public/private 2. Applying MIME Object Security Services
key pair. Each key pair is required to belong to a user (where user is
not limited to being a human, e.g., it could be a process or a role)
which has a name. There are 3 name forms specified by this document.
For backward compatibility (and forward compatibility if the X.500
Directory becomes a ubiquitous service) one of the name forms is a
distinguished name. In addition, email addresses and arbitrary strings
are allowed.
Since a user may have more than one key pair, a name form is The application of the MOSS digital signature service requires the
insufficient for uniquely identifying a key pair. A unique key selector following components.
must be assigned to each key pair. The combination of a name form and a
key selector uniquely identifies a key pair and each key pair is
uniquely identified by a name form and key selector combination.
Throughout this document, this combination is called an identifier.
There are 5 identifiers specified by this document.
NOTE: In the simplest case, key selectors will be assigned by (1) The data to be signed.
the owners of the key pairs. This works best when users
generate their own key pairs for personal use, which they
distribute to others asserting by declaration that the public
key belongs to them. When the assertion that the public key
belongs to them is made by a third party, for example when a
certification authority issues a certificate to a user according
to [4], the key selector may be assigned by that third party.
With a key pair for one's self and software that is both MIME and PEM (2) The private key of the originator.
aware, an originating user may digitally sign arbitrary data and send it
to one or more recipients. With the public keys of the recipients, a
user may encrypt the data so that only the intended recipients can
decrypt and read it. This specification separates these two services so
that an originator may apply either or both, in either order.
The name forms and identifiers are described in detail in the next The data to be signed is prepared according to the description below.
section. Succeeding sections specify how PEM and MIME are used together The digital signature is created by generating a hash of the data and
and other ancillary details. encrypting the hash value with the private key of the originator.
The digital signature, some additional ancillary information
described below, and the data are then embodied in a multipart/signed
body part. Finally, the multipart/signed body part may be
transferred to a recipient or processed further, for example, it may
be encrypted.
2. Name Forms and Identifiers The application of the MOSS encryption service requires the following
components.
Currently, [3] requires the use of certificates to create and receive (1) The data to be encrypted.
PEM messages. Within certificates, [4] requires the use of
distinguished names as specified by the X.500 Series of Recommendations.
However, the Internet community has a great deal more experience with
the use of electronic mail addresses as a name form and there is a
desire to be able to use arbitrary strings to identify the owners of
public keys. Hence, there is a need to support name forms which do not
conform to the expected usage of distinguished names.
When receiving PEM messages it is necessary to be able to uniquely (2) A data encrypting key to encrypt the data.
identify the key pair used to create the message. A certificate is one
mechanism that accomplishes this, since it is uniquely identified by the
combination of its issuer's distinguished name and its serial number.
In any case, an identifier is required that consists of both a name form
and key selector.
In addition, users may distribute their public keys via mechanisms (3) The public key of the recipient.
outside the scope of the PEM specification, for example, in a file via
FTP. Users receiving such keys will probably assign name forms to them
to be displayed when receiving messages created with them. As a result,
it is desirable to be able to explicitly specify the public key used
rather than an identifier of the public key.
NOTE: A feature of being able to specify the public key The data to be encrypted is prepared according to the description
explicitly is that it allows users to exchange encrypted, below. The originator creates a data encrypting key and encrypts the
anonymous mail. In particular, receiving users will always know data. The recipient's public key is used to encrypt the data
a message comes from the same originating user. encrypting key. The encrypted data, the encrypted data encrypting
key, and some additional ancillary information described below are
then embodied in a multipart/encrypted body part, ready to be
transferred to a recipient or processed further, for example, it may
be signed.
The principal objective of the various Originator and Recipient fields The next two sections describe the digital signature and encryption
specified in [3] is to identify which public key has been used or is services, respectively, in detail.
required. This document reduces the set of fields by specifying exactly
two: Originator-ID: for originators and Recipient-ID: for recipients.
This specification defines 5 identifiers with which the public key used
may be indicated in each of these fields.
In the next section the 3 name forms are described in detail. Following 2.1. Digital Signature Service
that is the specification of the 5 identifiers.
2.1. Name Forms The MOSS digital signature service is applied to MIME objects,
specifically a MIME body part. The MIME body part is created
according to a local convention and then made available to the
digital signature service.
There are 3 name forms specified by this document: email addresses, The following sequence of steps comprises the application of the
distinguished names, and arbitrary strings. digital signature service.
2.1.1. Email Addresses (1) The body part to be signed must be canonicalized.
The email address (grammar token <emailstr>) used must be a valid RFC822 (2) The digital signature and other control information must be gen-
address, which is defined in terms of the two grammar tokens <addr-spec> erated.
and <route-addr>. The grammar for these two tokens is included in the
Appendix as a convenience; the definitive source for these tokens is
necessarily RFC822 [1].
<emailstr> ::= <addr-spec> / <route-addr> (3) The control information must be embodied in an appropriate MIME
; an electronic mail address as defined by content type.
; these two tokens from RFC822
For example, the strings "crocker@tis.com", "galvin@tis.com", (4) The control information body part and the data body part must be
"murphy@tis.com", and "ned@innosoft.com" are all email addresses. embodied in a multipart/signed content type.
2.1.2. Arbitrary Strings Each of these steps is described below.
The arbitrary string (grammar token <string>) must have a length of at 2.1.1. Canonicalization
least 1. There are no other restrictions on the value chosen.
<string> ::= ; a non-null sequence of characters The body part must be converted to a canonical form that is uniquely
and unambiguously representable in at least the environment where the
digital signature is created and the environment where the digital
signature will be verified, i.e., the originator and recipient's
environment, respectively. This is required in order to ensure that
both the originator and recipient have the same data with which to
calculate the digital signature; the originator needs to be able to
create the digital signature value while the recipient needs to be
able to compare a re-computed value with the received value. If the
canonical form is representable on many different host computers, the
signed data may be forwarded by recipients to additional recipients,
who will also be able to verify the original signature. This service
is called forwardable authentication.
For example, the string The canonicalization transformation is a two step process. First,
the body part must be converted to a form that is unambiguously
representable on as many different host computers as possible.
Second, the body part must have its line delimiters converted to a
unique and unambiguous representation.
Jim "the SAAG mailing list maintainer" Galvin The representation chosen to satisfy the first step is 7bit, as
defined by MIME; the high order bit of each octet of the data to be
signed must be zero. A MIME body part is comprised of two parts:
headers and content. Since the headers of body parts are already
required to be represented in 7bit, this step does not require
changes to the headers. This step requires that if the content is
not already 7bit then it must be encoded with an appropriate MIME
content transfer encoding and a Content-Transfer-Encoding: header
must be added to the headers. For example, if the content to be
signed contains 8bit or binary data, the content must be encoded with
either the quoted-printable or base64 encoding as defined by MIME.
is an arbitrary string. IMPLEMENTORS NOTE: Since the MIME standard explicitly disallows
nested content transfer encodings, i.e., the content types
multipart and message may not themselves be encoded, the 7bit
transformation requires each nested body part to be individually
encoded in a 7bit representation. Any valid MIME encoding, e.g.,
quoted-printable or base64, may be used and, in fact, a different
encoding may be used on each of the non-7bit body parts.
2.1.3. Distinguished Names Representing all content types in a 7bit format transforms them into
text-based content types. However, text-based content types present
a unique problem. In particular, the line delimiter used for a
text-based content type is specific to a local environment; different
environments use the single character carriage-return (<CR>), the
single character line-feed (<LF>), or the two character sequence
"carriage-return line-feed (<CR><LF>)".
The distinguished name (grammar token <dnamestr>) must be constructed The application of the digital signature service requires that the
according to the guidelines of the X.500 Directory. The actual syntax same line delimiter be used by both the originator and the recipient.
of the distinguished name is outside the scope of this specification. This document specifies that the two character sequence "<CR><LF>"
However, RFC1422, for example, specifies syntactic restrictions based on must be used as the line delimiter. Thus, the second step of the
a particular choice of a certification hierarchy for certificates. canonicalization transformation includes the conversion of the local
line delimiter to the two character sequence "<CR><LF>".
For the purposes of conveying a distinguished name from an originator to The conversion to the canonical line delimiter is only required for
a recipient, it must be ASN.1 encoded and then printably encoded the purposes of computing the digital signature. Thus, originators
according to the base64 encoding defined by MIME. must apply the line delimiter conversion before computing the digital
signature but must transfer the data without the line delimiter
conversion. Similarly, recipients must apply the line delimiter
conversion before computing the digital signature.
<dnamestr> ::= <encbin> NOTE: An originator can not transfer the content with the line
; a printably encoded, ASN.1 encoded delimiter conversion intact because the conversion process is not
; distinguished name (as defined by the 'Name' idempotent. In particular, SMTP servers may themselves convert
; production specified in X.501) the line delimiter to a local line delimiter, prior to the message
being delivered to the recipient. Thus, a recipient has no way of
knowing if the conversion is present or not. If the recipient
applies the conversion to a content in which it is already
present, the resulting content may have two line delimiters
present, which would cause the verification of the signature to
fail.
For example, IMPLEMENTORS NOTE: Implementors should be aware that the
conversion to a 7bit representation is a function that is required
in a minimally compliant MIME user agent. Further, the line
delimiter conversion required here is distinct from the same
conversion included in that function. Specifically, the line
delimiter conversion applied when a body part is converted to a
7bit representation (transfer encoded) is performed prior to the
application of the transfer encoding. The line delimiter
conversion applied when a body part is signed is performed after
the body part is converted to 7bit (transfer encoded). Both line
delimiter conversions are required.
/Country Name=US 2.1.2. Digital Signature Control Information
/State or Province Name=MD
/Organization Name=Trusted Information Systems
/Organizational Unit Name=Glenwood
/Common Name=James M. Galvin/
is a distinguished name in a user friendly format (line breaks and The application of the digital signature service generates control
leading spaces present only to improve readability). When encoded, it information which includes the digital signature itself. The syntax
would appear as follows (line breaks present only to improve of the control information is that of a set of RFC 822 headers,
readability): except that the folding of header values onto continuation lines is
explicitly forbidden. Each header and value pair generated by the
digital signature service must be output on exactly one line.
MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ The complete set of headers generated by the digital signature
bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP service is as follows.
SmFtZXMgTS4gR2Fsdmlu
2.2. Identifiers Version:
indicates which version of the MOSS protocol the remaining headers
represent.
There are 5 types of identifiers specified by this document: email Originator-ID:
address identifiers, arbitrary string identifiers, distinguished name indicates the private key used to create the digital signature and
identifiers, the public keys themselves, and issuer name serial number the corresponding public key to be used to verify it.
pairs from a certificate. All of these have approximately the same
structure (except issuer name and serial number which has 'TYPE, STRING,
KEYSEL' for historical reasons):
TYPE, KEYSEL, STRING MIC-Info:
contains the digital signature value.
The TYPE field is a literal string, one for each of the possible Each invocation of the digital signature service must emit exactly
identifiers. one Version: header and at least one pair of Originator-ID: and MIC-
Info: headers. The Version: header must always be emitted first.
The Originator-ID: and MIC-Info: headers are always emitted in pairs
in the order indicated. This specification allows an originator to
generate multiple signatures of the data, presumably with different
signature algorithms, and to include them all in the control
information. The interpretation of the presence of multiple
signatures is outside the scope of this specification except that a
MIC-Info: header is always interpreted in the context of the
immediately preceding Originator-ID: header.
The KEYSEL field is used to distinguish between the multiple public keys 2.1.2.1. Version:
that may be associated with the name form in the STRING field. Its
value must be distinct from all other KEYSELs assigned by whomever
assigned this KEYSEL. A suggested value is to use a portion (low-order
16 or 32 bits) or all of the actual public key used.
The STRING field is the name form and has a different syntax according The version header is defined by the grammar token <version> as
to the value of the TYPE field. follows.
The identifier used in each of the originator and recipient fields is <version> ::= "Version:" "5" CRLF
described by the following grammar. The definition of the key selector
token is included here since it used by several of the identifiers
below.
<id> ::= <id-email> / <id-string> / <id-dname> Its value is constant and MOSS implementations compliant with this
/ <id-publickey> / <id-issuer> specification must recognize only this value and generate an error if
any other value is found.
<keysel> ::= <encbin> 2.1.2.2. Originator-ID:
; a printably encoded non-null sequence of octets
Each of the identifier name forms is described below. The purpose of the originator header is two-fold: to directly
identify the public key to be used to verify the digital signature
and to indirectly identify the user who owns both it and its
corresponding private key. Typically, a recipient is less interested
in the actual public key value, although obviously the recipient
needs the value to verify the signature, and more interested in
identifying its owner. Thus, the originator header may convey either
or both pieces of information:
2.2.1. Email Address the public key to be used to verify the signature
The email address identifier has the following syntax. the name of the owner and which of the owner's public keys to use
to verify the signature
<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF The decision as to what information to place in the value rests
entirely with the originator. The suggested value is to include
both. Recipients with whom the originator has previously
communicated will have to verify that the information presented is
consistent with what is already known. New recipients will want all
of the information, which they will need to verify prior to storing
in their local database.
The syntax of the token <emailstr> is defined in Section 2.1.1. The originator header is defined by the grammar token <origid> as
follows.
2.2.2. Arbitrary String <origid> ::= "Originator-ID:" <id> CRLF
The arbitrary string identifier has the following syntax. The grammar token <id> is defined in Section 4.
<id-string> ::= "STR" "," <keysel> "," <string> CRLF 2.1.2.3. MIC-Info:
The syntax of the token <string> is defined in Section 2.1.2. The purpose of the Message Integrity Check (MIC) header is to convey
the digital signature value. Its value is a comma separated list of
three arguments: the hash (or MIC) algorithm identifier, the
signature algorithm identifier, and the digital signature.
2.2.3. Distinguished Name The MIC header is defined by the grammar token <micinfo> as follows.
The distinguished name identifier has the following syntax. <micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF The grammar tokens for the MIC algorithms and identifiers
(<micalgid>), signature algorithms and identifiers (<ikalgid>), and
signed MIC formats (<asymsignmic>) are defined by RFC 1423. They are
also reprinted in Appendix B.
The syntax of the token <dnamestr> is defined in Section 2.1.3. IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol,
which includes support for symmetric signatures and key
management. As a result, some of the grammar tokens defined
there, for example, <ikalgid>, will include options that are not
legal for this protocol. These options must be ignored and have
not been included in the appendix.
2.2.4. Public Key 2.1.3. application/moss-signature Content Type Definition
The public key identifier has the following syntax. (1) MIME type name: application
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF (2) MIME subtype name: moss-signature
<publickey> ::= <encbin> (3) Required parameters: none
; a printably encoded, ASN.1 encoded public key (as
; defined by the 'SubjectPublicKeyInfo' production
; specified in X.509)
<id-subset> ::= <id-email> / <id-string> / <id-dname> (4) Optional parameters: none
The object subjectPublicKeyInfo is imported from the X.500 Directory (5) Encoding considerations: quoted-printable is always sufficient
from the certificate object. It is currently the best choice for a
general purpose public key encoding.
In normal usage, the token <id-subset> is expected to be absent. When (6) Security considerations: none
present, it represents a mechanism by which an identifier (name form and
key selector) can be associated with a public key. Recipients of a
public key identifier must take care to verify the accuracy of the
purported association. If not, it may be possible for a malicious
originator to assert an identifier that accords the originator
unauthorized privileges. See Section 5.2 for more details.
2.2.5. Issuer Name and Serial Number The "application/moss-signature" content type is used on the second
body part of an enclosing multipart/signed. Its content is comprised
of the digital signature of the data in the first body part of the
enclosing multipart/signed and other control information required to
verify that signature, as defined by Section 2.1.2. The label
"application/moss-signature" must be used as the value of the
protocol parameter of the enclosing multipart/signed; the protocol
parameter must be present.
The issuer name and serial number identifier has the following syntax. Part of the signature verification information will be the Message
Integrity Check (MIC) algorithm(s) used during the signature creation
process. The MIC algorithm(s) identified in this body part must
match the MIC algorithm(s) identified in the micalg parameter of the
enclosing multipart/signed. If it does (they do) not, a user agent
should identify the discrepancy to a user and it may choose to either
halt or continue processing, giving precedence to the algorithm(s)
identified in this body part.
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF An application/moss-signature body part is constructed as follows:
<serial> ::= 1*<hexchar> Content-Type: application/moss-signature
; hex dump of the serial number of a certificate
The <id-issuer> identifier is included for backward compatibility (and <mosssig>
forward compatibility if X.500 Directory certificates become
ubiquitously available) with the ID-ASymmetric fields defined in [3].
Its syntax was chosen such that the older fields are easily converted to
this new form by prefixing the old value with "IS," and replacing the
field name with an appropriate new ID field name.
3. Applying PEM Security Services to MIME Body Parts where the grammar token <mosssig> is defined as follows.
The next section describes the processing steps necessary to prepare a <mosssig> ::= <version> ( 1*<origasymflds> )
MIME body part for the application of PEM security services. The
succeeding two sections describe the content of the multipart/signed and
multipart/encrypted body parts resulting from the application of PEM
security services to MIME body parts.
3.1. PEM Processing Steps <version> ::= "Version:" "5" CRLF
The definition of the multipart/signed and multipart/encrypted body <origasymflds> ::= <origid> <micinfo>
parts in [7] specifies three steps for creating both body parts.
(1) The body part to be protected is created according to a local <origid> ::= "Originator-ID:" <id> CRLF
convention.
(2) The body part is prepared for protection according to the protocol <micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
parameter. <asymsignmic> CRLF
(3) The prepared body part is protected according to the protocol The token <id> is defined in Section 4. All other tokens are defined
parameter. in Section 2.1.2.3.
This specification makes no changes to step one in the sequence. For 2.1.4. Use of multipart/signed Content Type
step two, there is no preparation necessary for the encryption service.
For the digital signature service, the body part must be canonicalized
as described below. This specification makes no changes to step three
in the sequence.
Prior to the application of the digital signature service, the body part The definition of the multipart/signed content type in [7] specifies
must be in a canonical form. Transforming the body part to be signed three steps for creating the body part.
into a canonical form is a necessary and essential step in the digital
signature process. The canonical form must satisfy the property that it
is uniquely and unambiguously representable in both the originator and
recipient's local environment. This is required in order to ensure that
both the originator and recipient have the same data with which to
calculate the digital signature; the originator needs to be able to
include the digital signature value when transferring the body part,
while the recipient needs to be able to compare a re-computed value with
the received value. Further, the canonical form should satisfy the
property that it is representable on as many different host computers as
possible. By satisfying this property, signed data may be forwarded by
recipients to additional recipients, who will also be able to verify the
original signature. This service is called forwardable authentication.
The canonicalization transformation is a two step process. First, the (1) The body part to be digitally signed is created according to a
body part must be converted to a form that is uniquely and unambiguously local convention, for example, with a text editor or a mail user
representable on as many different host computers as possible. Second, agent.
the body part must have its line delimiters converted to a unique and
unambigous representation prior to computing the digital signature and
prior to each verification of the digital signature.
The representation of all body parts in the first step is specified to (2) The body part is prepared for the digital signature service
be 7bit, as defined by [2]. Since the headers of body parts are already according to the protocol parameter, in this case according to
required to be representable in 7bit, this step requires that if the Section 2.1.1.
data to be signed is not already 7bit then it must be encoded with an
appropriate MIME content transfer encoding. Note: since the MIME
standard explicitly disallows nested content transfer encodings, i.e.,
the content types multipart and message may not themselves be encoded,
body parts enclosed within, for example, a multipart content type must
be encoded in a 7bit representation. Any valid MIME encoding may be
selected for encoding the content of each of the non-7bit body parts.
As may be required by MIME, an appropriate Content-Transfer-Encoding: (3) The prepared body part is digitally signed according to the
header is added and included with the data to be signed. Upon receipt, protocol parameter, in this case according to Section 2.1.2.
a MIME implementation would verify the signature of the data prior to
decoding the data and displaying it to the recipient.
Representing all complex content types as 7bit transforms them into The multipart/signed content type is constructed as follows.
text-based content types. However, text-based content types present a
unique problem. In particular, the line delimiter used for a text-based
content type is specific to a local environment; different environments
use the single character carriage-return (<CR>), the single character
line-feed (<LF>), or the two character sequence "carriage-return line-
feed (<CR><LF>)".
The application of the digital signature service requires that the same (1) The value of its required parameter "protocol" is set to
line delimiter be used by both the originator and the recipient. This "application/moss-signature".
document specifies that the two character sequence "<CR><LF>" must be
used as the line delimiter. Thus, the second step of the
canonicalization transformation includes the conversion of the local
line delimiter to the two character sequence "<CR><LF>".
The conversion to the canonical line delimiter is only required for the (2) The signed body part becomes its first body part.
purposes of computing the digital signature. Thus, originators must
apply the line delimiter conversion before computing the digital
signature but must transfer the data without the line delimiter
conversion. Similarly, recipients must apply the line delimiter
conversion before computing the digital signature.
NOTE: An originator can not transfer the content with the line (3) Its second body part is labeled "application/moss-signature" and
delimiter conversion intact because the conversion process is is filled with the control information generated by the digital
not idempotent. In particular, SMTP servers may themselves signature service.
convert the line delimiter to a local line delimiter, prior to
the message being delivered to the user. Thus, a recipient has
no way of knowing if the conversion is present or not. Thus, if
the recipient applies the conversion to a content in which it is
already present, the resulting content may have two line
delimiters present, which would cause the verification of the
signature to fail.
IMPLEMENTORS NOTE: Implementors should be aware that the (4) The value of its required parameter "micalg" is set to the same
conversion to a 7bit representation is a function that is value used in the MIC-Info: header in the control information.
available in a minimally compliant MIME user agent. Further, If there is more than one MIC-Info: header present the value is
the line delimiter conversion required here is distinct from the set to a comma separated list of values from the MIC-Info
same conversion included in that function. Specifically, the headers. The interpretation of the order of the list of values
line delimiter conversion applied when a body part is converted is outside the scope of this specification.
to a 7bit representation is performed prior to application of
the transfer encoding. The line delimiter conversion applied
when a body part is signed is performed after the body is
converted to 7bit.
3.2. Use of multipart/signed Content Type A multipart/signed content type with the MOSS protocol might look as
follows:
Using this content type requires the specification of a control Content-Type: multipart/signed;
information content type, the label of which is used as the value for protocol="application/moss-signature";
the required protocol parameter. Section 3.4 defines the control micalg="rsa-md5"; boundary="Signed Message"
information content type of application/pem-signature. The value of the
required parameter "protocol" is "application/pem-signature" and the
value of the required parameter "micalg" is one of the valid choices
from [5], for example:
Content-Type: multipart/signed; protocol="application/pem-signature"; --Signed Message
micalg="rsa-md5"; boundary="Signed Message" Content-Type: text/plain
--Signed Message This is some example text.
Content-Type: text/plain
This is some example text. --Signed Message
Content-Type: application/moss-signature
--Signed Message Version: 5
Content-Type: application/pem-signature Originator-ID: ID-INFORMATION
MIC-Info: RSA-MD5,RSA,SIGNATURE-INFORMATION
--Signed Message--
SIGNATURE INFORMATION where ID-INFORMATION and SIGNATURE-INFORMATION are descriptive of the
--Signed Message-- content that would appear in a real body part.
where SIGNATURE INFORMATION is descriptive of the content that would 2.2. Encryption Service
appear in a real body part.
3.3. Use of multipart/encrypted Content Type The MOSS encryption service is applied to MIME objects, specifically
a MIME body part. The MIME body part is created according to a local
convention and then made available to the encryption service.
Using this content type requires the specification of a control The following sequence of steps comprises the application of the
information content type, the label of which is used as the value for encryption service.
the required protocol parameter. Section 3.5 defines the control
information content type of application/pem-keys. The value of the
required parameter "protocol" is "application/pem-keys", for example:
Content-Type: multipart/encrypted; protocol="application/pem-keys"; (1) The body part to be encrypted must be in MIME canonical form.
boundary="Encrypted Message"
--Encrypted Message (2) The data encrypting key and other control information must be
Content-Type: application/pem-keys generated.
KEY DATA (3) The control information must be embodied in an appropriate MIME
content type.
--Encrypted Message (4) The control information body part and the encrypted data body
Content-Type: application/octet-stream part must be embodied in a multipart/encrypted content type.
ENCRYPTED DATA WOULD BE HERE The first step is defined by MIME. The latter three steps are
--Encrypted Message-- described below.
3.4. application/pem-signature Content Type Definition 2.2.1. Encryption Control Information
(1) MIME type name: application The application of the encryption service generates control
information which includes the data encrypting key used to encrypt
the data itself. The syntax of the control information is that of a
set of RFC 822 headers, except that the folding of header values onto
continuation lines is explicitly forbidden. Each header and value
pair generated by the encryption service must be output on exactly
one line.
(2) MIME subtype name: pem-signature First, the originator must retrieve the public key of the recipient.
The retrieval may be from a local database or from a remote service.
The acquisition of the recipient's public key is outside the scope of
the specification, although Section 5 defines one possible mechanism.
(3) Required parameters: none With the public key, the originator encrypts the data encrypting key
according to the Key-Info: header defined below. The complete set of
headers generated by the encryption service is as follows.
(4) Optional parameters: none Version:
indicates which version of the MOSS protocol the remaining headers
represent and is defined in Section 2.1.2.1.
(5) Encoding considerations: quoted-printable is always sufficient DEK-Info:
indicates the algorithm and mode used to encrypt the data.
(6) Security considerations: none Recipient-ID:
indicates the public key used to encrypt the data encrypting key
that was used to encrypt the data.
This content type is used on the second body part of an enclosing Key-Info:
multipart/signed when the protocol used is PEM. It is comprised of the contains data encrypting key encrypted with the recipient's public
digital signature of the data, which is the first body part of the key.
enclosing multipart/signed, and the information required to verify that
signature. The label application/pem-signature is used as the value of
the protocol parameter of the enclosing multipart/signed. It is an
error for the protocol parameter to be missing from the enclosing
multipart/signed body part or for its value to be different from
application/pem-signature when this body part is used.
Included in the signature verification information will be the Message Each invocation of the encryption service must emit exactly one
Integrity Check (MIC) algorithm used during the signature creation Version: header, exactly one DEK-Info: header, and at least one pair
process. The MIC algorithm identified in this body part must match the of Recipient-ID: and Key-Info: headers. Headers are always emitted
MIC algorithm identified in the micalg parameter of the enclosing in the order indicated. The Recipient-ID: and Key-Info: headers are
multipart/signed. If it does not, a user agent should identify the always emitted in pairs in the order indicated, one pair for each
discrepancy to a user and may choose to either halt or continue recipient of the encrypted data. A Key-Info: header is always
processing, giving precedence to the algorithm identified in this body interpreted in the context of the immediately preceding Recipient-ID:
part. header.
An application/pem-signature body part is constructed as follows: IMPLEMENTORS NOTE: Implementors should always generate a
Recipient-ID: and Key-Info header pair representing the originator
of the encrypted data. By doing so, if an originator sends a
message to a recipient that is returned undelivered, the
originator will be able to decrypt the message and determine an
appropriate course of action based on its content. If not, an
originator will not be able to review the message that was sent.
Content-Type: application/pem-signature 2.2.1.1. DEK-Info:
<pemsig> The purpose of the data encrypting key information header is to
indicate the algorithm and mode used to encrypt the data, along with
any cryptographic parameters that may be required, e.g.,
initialization vectors. Its value is either a single argument
indicating the algorithm and mode or a comma separated pair of
arguments where the second argument carries any cryptographic
parameters required by the algorithm and mode indicated in the first
argument.
where the <pemsig> token is defined as follows. The data encrypting key information header is defined by the grammar
token <dekinfo> as follows.
<pemsig> ::= <version> ( 1*<origasymflds> ) <dekinfo> ::= "DEK-Info" ":" <dekalgid>
[ "," <dekparameters> ] CRLF
<version> ::= "Version:" "5" CRLF The grammar tokens for the encryption algorithm and mode identifier
(<dekalgid>) and the optional cryptographic parameters
(<dekparameters>) are defined by RFC 1423. They are also reprinted
in Appendix B.
<origasymflds> ::= <origid> <micinfo> 2.2.1.2. Recipient-ID:
<origid> ::= "Originator-ID:" <id> CRLF The purpose of the recipient header is to identify the private key
that must be used to decrypt the data encrypting key that will be
used to decrypt the data. Presumably the recipient owns the private
key and thus is less interested in identifying the owner of the key
and more interested in the private key value itself. Nonetheless,
the recipient header may convey either or both pieces of information:
The token <id> is defined in Section 2.2. the public key corresponding to the private key to be used to
decrypt the data encrypting key
3.5. application/pem-keys Content Type Definition the name of the owner and which of the owner's private keys to use
to decrypt the data encrypting key
(1) MIME type name: application The decision as to what information to place in the value rests
entirely with the originator. The suggested choice is to include
just the public key. However, some recipients may prefer that
originators not include their public key. How this preference is
conveyed to and managed by the originator is outside the scope of
this specification.
(2) MIME subtype name: pem-keys The recipient header is defined by the grammar token <recipid> as
follows.
(3) Required parameters: none <recipid> ::= "Recipient-ID:" <id> CRLF
(4) Optional parameters: none The grammar token <id> is defined in Section 4.
(5) Encoding considerations: quoted-printable is always sufficient 2.2.1.3. Key-Info:
(6) Security considerations: none The purpose of the key information header is to convey the encrypted
This content type is used on the first body part of an enclosing data encrypting key. Its value is a comma separated list of two
multipart/encrypted. It is comprised of the data encryption key used to arguments: the algorithm and mode identifier in which the data
encrypt the data, located in the second body part of the enclosing encrypting key is encrypted and the encrypted data encrypting key.
multipart/encrypted, and the information required to perform the
decryption. The label application/pem-keys is used as the value of the
protocol parameter of the enclosing multipart/encrypted. It is an error
for the protocol parameter to be missing in the enclosing
multipart/encrypted body part or for its value to be different from
application/pem-keys when this body part is used.
An application/pem-keys body part is constructed as follows: The key information header is defined by the grammar token
<asymkeyinfo> as follows.
Content-Type: application/pem-keys <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
<pemkeys> The grammar tokens for the encryption algorithm and mode identifier
(<ikalgid>) and the encrypted data encrypting key format
(<asymsignmic>) are defined by RFC 1423. They are also reprinted in
Appendix B.
where the <pemkeys> token is defined as follows. IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol,
which includes support for symmetric signatures and key
management. As a result, some of the grammar tokens defined
there, for example, <ikalgid>, will include options that are not
legal for this protocol. These options must be ignored and have
not been included in the appendix.
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds> 2.2.2. application/moss-keys Content Type Definition
<version> ::= "Version:" "5" CRLF (1) MIME type name: application
<recipasymflds> ::= <recipid> <asymkeyinfo> (2) MIME subtype name: moss-keys
<recipid> ::= "Recipient-ID:" <id> CRLF (3) Required parameters: none
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF (4) Optional parameters: none
The token <id> is defined in Section 2.2. (5) Encoding considerations: quoted-printable is always sufficient
4. Removing PEM Security Services from PEM Body Parts (6) Security considerations: none
This section describes the processing steps necessary to verify or The "application/moss-keys" content type is used on the first body
decrypt the PEM security services that have been applied to MIME body part of an enclosing multipart/encrypted. Its content is comprised
parts. Outer layers of PEM security services must be processed prior to of the data encryption key used to encrypt the data in the second
processing inner layers of PEM security services. Processing includes a body part and other control information required to decrypt the data,
user choosing to display a content without removing the PEM security as defined by Section 2.2.1. The label "application/moss-keys" must
services. be used as the value of the protocol parameter of the enclosing
multipart/encrypted; the protocol parameter must be present.
The definition of the multipart/signed and multipart/encrypted body An application/moss-keys body part is constructed as follows:
parts in [7] specifies three steps for receiving both body parts.
(1) The protected body part and the control information body part are Content-Type: application/moss-keys
prepared for processing.
(2) The prepared body parts are made available to the protection <mosskeys>
removal process.
(3) The results of the protection removal process are made available to where the <mosskeys> token is defined as follows.
the user and processing continues with the unprotected body part,
as returned by the protection removal process.
For step one, the preparation for digitally signed and encrypted body <mosskeys> ::= <version> <dekinfo> 1*<recipasymflds>
parts is different, as described below. No changes are required to
steps two and three in the sequence.
For multipart/signed body parts, the control information is prepared by <version> ::= "Version:" "5" CRLF
removing any content transfer encodings that may be present. The
digitally signed body part is prepared by leaving the content transfer
encodings intact and converting the line delimiters according to Step 2
of Section 3.1.
Multipart/encrypted body parts are prepared by removing the content <dekinfo> ::= "DEK-Info" ":" <dekalgid>
transfer encodings, if present, from both the control information and [ "," <dekparameters> ] CRLF
the encrypted body part.
<recipasymflds> ::= <recipid> <asymkeyinfo>
<recipid> ::= "Recipient-ID:" <id> CRLF
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
The token <id> is defined in Section 4. The token <version> is
defined in Section 2.1.2.1. All other tokens are defined in Section
2.2.1.3.
2.2.3. Use of multipart/encrypted Content Type
The definition of the multipart/encrypted body part in [7] specifies
three steps for creating the body part.
(1) The body part to be encrypted is created according to a local
convention, for example, with a text editor or a mail user
agent.
(2) The body part is prepared for encryption according to the
protocol parameter, in this case the body part must be in MIME
canonical form.
(3) The prepared body part is encrypted according to the protocol
parameter, in this case according to Section 2.2.1.
The multipart/encrypted content type is constructed as follows.
(1) The value of its required parameter "protocol" is set to
"application/moss-keys".
(2) The first body part is labeled "application/moss-keys" and is
filled with the control information generated by the encryption
service.
(3) The encrypted body part becomes the content of its second body
part, which is labeled "application/octet-stream".
A multipart/encrypted content type with the MOSS protocol might look
as follows:
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Message"
--Encrypted Message
Content-Type: application/moss-keys
Version: 5
DEK-Info: DES-CBC,DEK-INFORMATION
Recipient-ID: ID-INFORMATION
Key-Info: RSA,KEY-INFORMATION
--Encrypted Message
Content-Type: application/octet-stream
ENCRYPTED-DATA
--Encrypted Message--
where DEK-INFORMATION, ID-INFORMATION, and KEY-INFORMATION are
descriptive of the content that would appear in a real body part.
3. Removing MIME Object Security Services
The verification of the MOSS digital signature service requires the
following components.
(1) A recipient to verify the digital signature.
(2) A multipart/signed body part with two body parts: the signed
data and the control information.
(3) The public key of the originator.
The signed data and control information of the enclosing
multipart/signed are prepared according to the description below.
The digital signature is verified by re-computing the hash of the
data, decrypting the hash value in the control information with the
originator's public key, and comparing the two hash values. If the
two hash values are equal, the signature is valid.
The decryption of the MOSS encryption service requires the following
components.
(1) A recipient to decrypt the data.
(2) A multipart/encrypted body part with two body parts: the
encrypted data and the control information.
(3) The private key of the recipient.
The encrypted data and control information of the enclosing
multipart/encrypted are prepared according to the description below.
The data encrypting key is decrypted with the recipient's private key
and used to decrypt the data.
The next two sections describe the digital signature and encryption
services in detail, respectively.
3.1. Digital Signature Service
This section describes the processing steps necessary to verify the
MOSS digital signature service. The definition of the
multipart/signed body part in [7] specifies three steps for receiving
it.
(1) The digitally signed body part and the control information body
part are prepared for processing.
(2) The prepared body parts are made available to the digital
signature verification process.
(3) The results of the digital signature verification process are
made available to the user and processing continues with the
digitally signed body part, as returned by the digital signature
verification process.
Each of these steps is described below.
3.1.1. Preparation
The digitally signed body part (the data) and the control information
body part are separated from the enclosing multipart/signed body
part.
The control information is prepared by removing any content transfer
encodings that may be present.
The digitally signed body part is prepared by leaving the content
transfer encodings intact and canonicalizing the line delimiters
according to Step 2 of Section 2.1.1.
3.1.2. Verification
First, the recipient must obtain the public key of the originator.
The public key may be contained in the control information or it may
be necessary for the recipient to retrieve the public key based on
information present in the control information. The retrieval may be
from a local database or from a remote service. The acquisition of
the originator's public key is outside the scope of the
specification, although Section 5 defines one possible mechanism.
With the public key, the recipient decrypts the hash value contained
in the control information. Then, a new hash value is computed over
the body part purported to have been digitally signed.
Finally, the two hash values are compared to determine the accuracy
of the digital signature.
3.1.3. Results
There are two required components of the results of the verification
process. The first is an indication as to whether a public key could
be found that allows the hash values in the previous step to compare
equal. Such an indication verifies only that the data received is
the same data that was digitally signed.
The second indication identifies the owner of the public key who is
presumably the holder of the private key that created the digital
signature. The indication must include a testament as to the
accuracy of the owner identification.
At issue is a recipient knowing who created the digital signature.
In order for the recipient to know with certainty who digitally
signed the message, the binding between the owner's name and the
public key must have been verified by the recipient prior to the
verification of the digital signature. The verification of the
binding may have been completed offline and stored in a trusted,
local database or, if the owner's name and public key are embodied in
a certificate, it may be possible to complete it in realtime. See
Section 5 for more information.
3.2. Encryption Service
This section describes the processing steps necessary to decrypt the
MOSS encryption service. The definition of the multipart/encrypted
body part in [7] specifies three steps for receiving it.
(1) The encrypted body part and the control information body part
are prepared for processing.
(2) The prepared body parts are made available to the decryption
process.
(3) The results of the decryption process are made available to the
user and processing continues with the decrypted body part, as
returned by the decryption process.
Each of these steps is described below.
3.2.1. Preparation
The encrypted body part (the data) and the control information body
part are separated from the enclosing multipart/encrypted body part.
The body parts are prepared for the decryption process by removing
any content transfer encodings that may be present.
3.2.2. Decryption
First, the recipient must locate the encrypted data encrypting key in
the control information. Each Recipient-ID: header is checked in
order to see if it identifies the recipient or a public key of the
recipient.
If it does, the immediately following Key-Info: header will contain
the data encrypting key encrypted with the public key of the
recipient. The recipient must use the corresponding private key to
decrypt the data encrypting key.
The data is decrypted with the data encrypting key. The decrypted
data will be a MIME object, a body part, ready to be processed by a
MIME agent.
3.2.3. Results
If the recipient is able to locate and decrypt a data encrypting key,
from the point of view of MOSS the decryption should be considered
successful. An indication of the owner of the private key used to
decrypt the data encrypting key must be made available to the user.
Ultimately, the success of the decryption is dependent on the ability
of a MIME agent to continue processing with the decrypted body part.
4. Identifying Originators, Recipients, and Their Keys
In the PEM specifications, public keys are required to be embodied in
certificates, an object that binds each public key with a
distinguished name. A distinguished name is a name form that
identifies the owner of the public key. The embodiment is issued by
a certification authority, a role that is expected to be trustworthy
insofar as the certification authority would have procedures to
verify the identity of the owner prior to issuing the certificate.
In MOSS, a user is not required to have a certificate. The MOSS
services require that the user have at least one public/private key
pair. The MOSS protocol requires the digital signature and
encryption services to emit Originator-ID: and Recipient-ID: headers,
as appropriate. In the discussion above the actual value of these
headers was omitted, having been relegated to this section. Although
the value of each of these headers serves a distinct purpose, for
simplicity the single grammar token <id> represents the value that
may be assigned to either header.
One possible value for the Originator-ID: and Recipient-ID: headers
is the public key values themselves. However, while it is true that
the public keys alone could be exchanged and used by users to
communicate, the values are, in fact, large and cumbersome. In
addition, public keys would appear as a random sequence of characters
and, as a result, would not be immediately consumable by human users.
NOTE: It should be pointed out that a feature of being able to
specify the public key explicitly is that it allows users to
exchange encrypted, anonymous mail. In particular, receiving
users will always know a message comes from the same originating
user even if the real identity of the originating user is unknown.
Recognizing that the use of public keys is, in general, unsuitable
for use by humans, MOSS allows other identifiers in Originator-ID:
and Recipient-ID: headers. These other identifiers are comprised of
two parts: a name form and a key selector.
The name form is chosen and asserted by the user who owns the
public/private key pair. Three name forms are specified by this
document. The use of a distinguished name is retained for
compatibility with PEM (and compatibility with the X.500 Directory
should it become a ubiquitous service). However, the Internet
community has a great deal of experience with the use of electronic
mail addresses as a name form. Also, arbitrary strings are useful to
identify the owners of public keys when private name forms are used.
Hence, email addresses and arbitrary strings are included as name
forms to increase flexibility.
Since a user may have more than one public key and may wish to use
the same name form for each public key, a name form is insufficient
for uniquely identifying a public key. A unique "key selector" must
be assigned to each public key. The combination of a name form and
the key selector uniquely identifies a public key. Throughout this
document, this combination is called an identifier. There are 5
identifiers specified by this document.
NOTE: In the simplest case, key selectors will be assigned by the
owners of the public/private key pairs. This works best when
users generate their own key pairs for personal use, from which
they distribute their public key to others asserting by
declaration that the public key belongs to them. When the
assertion that the public key belongs to them is made by a third
party, for example when a certification authority issues a
certificate to a user according to [4], the key selector may be
assigned by that third party.
The value of the key selector must be unique with respect to the name
form with which it forms an identifier. Although the same key
selector value may be used by more than one name form it must not be
used for two different keys with the same name form. When considered
separately, neither a name form nor a key selector is sufficient for
identifying the public key to be used. Either could be used to
determine a set of public keys that may be tried in turn until the
desired public key is identified.
With a public/private key pair for one's self and software that is
MOSS aware, an originating user may digitally sign arbitrary data and
send it to one or more recipients. With the public keys of the
recipients, a user may encrypt the data so that only the intended
recipients can decrypt and read it. With the name forms assigned to
the public keys, originators and recipients can easily recognize
their peers in a communication.
In the next section the 3 name forms are described in detail.
Following that is the specification of the 5 identifiers.
4.1. Name Forms
There are 3 name forms specified by this document: email addresses,
distinguished names, and arbitrary strings.
4.1.1. Email Addresses
The email address (grammar token <emailstr>) used must be a valid
RFC822 address, which is defined in terms of one of the two grammar
tokens <addr-spec> or <route-addr>. The grammar for these two tokens
is included in the Appendix as a convenience; the definitive source
for these tokens is necessarily RFC822 [1].
<emailstr> ::= <addr-spec> / <route-addr>
; an electronic mail address as defined by
; one of these two tokens from RFC822
For example, the strings "crocker@tis.com", "galvin@tis.com",
"murphy@tis.com", and "ned@innosoft.com" are all email addresses.
4.1.2. Arbitrary Strings
The arbitrary string (grammar token <string>) must have a length of
at least 1. There are no other restrictions on the value chosen.
<string> ::= ; a non-null sequence of characters
For example, the string
the SAAG mailing list maintainer
is an arbitrary string.
4.1.3. Distinguished Names
The distinguished name (grammar token <dnamestr>) must be constructed
according to the guidelines of the X.500 Directory. The actual
syntax of the distinguished name is outside the scope of this
specification. However, RFC1422, for example, specifies syntactic
restrictions based on its choice of a certification hierarchy for
certificates.
For the purposes of conveying a distinguished name from an originator
to a recipient, it must be ASN.1 encoded and then printably encoded
according to the base64 encoding defined by MIME.
<dnamestr> ::= <encbin>
; a printably encoded, ASN.1 encoded
; distinguished name (as defined by the 'Name'
; production specified in X.501 [8])
For example,
/Country Name=US
/State or Province Name=MD
/Organization Name=Trusted Information Systems
/Organizational Unit Name=Glenwood
/Common Name=James M. Galvin/
is a distinguished name in a user friendly format (line breaks and
leading spaces present only to improve readability). When encoded,
it would appear as follows (line breaks present only to improve
readability):
MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ
bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP
SmFtZXMgTS4gR2Fsdmlu
4.2. Identifiers
There are 5 types of identifiers specified by this document:
email address identifiers
arbitrary string identifiers
distinguished name identifiers
the public keys themselves
issuer name serial number pairs from a certificate
All of these have approximately the same structure (except issuer
name and serial number which has 'TYPE, STRING, KEYSEL' for
historical reasons):
TYPE, KEYSEL, STRING
The TYPE field is a literal string chosen from the set "EN", "STR",
"DN", "PK", and "IS", one for each of the possible identifiers.
The KEYSEL field is used to distinguish between the multiple public
keys that may be associated with the name form in the STRING field.
Its value must be unique with respect to all other key selectors used
with the same name form. An example would be to use a portion (low-
order 16 or 32 bits) or all of the actual public key used.
The STRING field is the name form and has a different syntax
according to the value of the TYPE field.
The identifier used in each of the originator and recipient fields is
described by the following grammar. The definition of the key
selector token is included here since it used by several of the
identifiers below.
<id> ::= <id-email> / <id-string> / <id-dname>
/ <id-publickey> / <id-issuer>
<keysel> ::= 1*<hexchar>
; hex dump of a non-null sequence of octets
Each of the identifier name forms is described below.
4.2.1. Email Address
The email address identifier has the following syntax.
<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF
The syntax of the token <emailstr> is defined in Section 4.1.1.
For example:
EN,1,galvin@tis.com
is an email address identifier.
4.2.2. Arbitrary String
The arbitrary string identifier has the following syntax.
<id-string> ::= "STR" "," <keysel> "," <string> CRLF
The syntax of the token <string> is defined in Section 4.1.2.
For example:
STR,1,The SAAG mailing list maintainer
is an arbitrary string identifier.
4.2.3. Distinguished Name
The distinguished name identifier has the following syntax.
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
The syntax of the token <dnamestr> is defined in Section 4.1.3.
For example (line breaks present only to improve readability):
DN,1,MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3R
lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1U
EAxMPSmFtZXMgTS4gR2Fsdmlu
is a distinguished name identifier.
4.2.4. Public Key
The public key identifier has the following syntax.
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded public
; key (as defined by the
; 'SubjectPublicKeyInfo' production specified
; in X.509 [9])
<id-subset> ::= <id-email> / <id-string> / <id-dname>
The production SubjectPublicKeyInfo is imported from the X.500
Directory from the certificate object. It is currently the best
choice for a general purpose public key encoding.
For example, (line breaks present only to improve readability):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB
is a public key identifier without the optional <id-subset>.
In normal usage, the token <id-subset> is expected to be present. It
represents a mechanism by which an identifier (name form and key
selector) can be associated with a public key. Recipients of a
public key identifier must take care to verify the accuracy of the
purported association. If they do not, it may be possible for a
malicious originator to assert an identifier that accords the
originator unauthorized privileges. See Section 5.2 for more
details.
For example, (line breaks present only to improve readability):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6BekJmG
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com
is a public key identifier with the optional <id-subset>.
4.2.5. Issuer Name and Serial Number
The issuer name and serial number identifier has the following
syntax.
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
<serial> ::= 1*<hexchar>
; hex dump of a certificate serial number
The <id-issuer> identifier is included for compatibility with the
ID-ASymmetric fields defined in [3] (and compatibility with X.500
Directory certificates should they become ubiquitously available).
Its syntax was chosen such that the older fields are easily converted
to this new form by prefixing the old value with "IS" (and replacing
the field name of [3] with an appropriate new ID field name). For
example, (line breaks present only to improve readability):
IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02
is an issuer name and serial number identifier according to MOSS,
while
MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02
is an issuer name and serial number identifier according to PEM.
5. Key Management Content Types 5. Key Management Content Types
This document defines two key management content types, the contents of This document defines two key management content types: one for
which comprise a replacement mechanism for those defined in [6]. The requesting cryptographic key material and one for sending
first content type is application/pemkey-request, which replaces the cryptographic key material. Since MOSS depends only on the existence
certification and CRL-retrieval request messages. The second content of public/private key pairs, these content types provide a means for
type is application/pemkey-data, which replaces the certification reply conveying public keys and an assertion as to the identity of the
message, the crl-storage request message, and the crl-retrieval reply owner. In addition, in order to be compatible with the certificate-
message. There are no requirements for a crl-storage reply message and base key management system proposed by RFC 1422, the content types
none are specified in this document. This document includes a may also be used to convey certificate and certificate revocation
specification for a public key and certificate request message, which list material.
were previously undefined.
5.1. application/pemkey-request Content Type Definition The functions defined here are based on the exchange of body parts.
In particular, a user would send a message containing at least one
application/mosskey-request content, as defined below. In response,
a user would expect to receive a message containing at least one
application/mosskey-data content, as defined below. MIME provides a
convenient framework for a user to send several request body parts
and to receive several data (response) body parts in one message.
(1) MIME type name: application 5.1. application/mosskey-request Content Type Definition
(2) MIME subtype name: pemkey-request (1) MIME type name: application
(3) Required parameters: none (2) MIME subtype name: mosskey-request
(4) Optional parameters: none
(5) Encoding considerations: quoted-printable is always sufficient (3) Required parameters: none
(6) Security Considerations: none (4) Optional parameters: none
The content of this body part corresponds to the following production. (5) Encoding considerations: quoted-printable is always sufficient
<request> ::= <version> (6) Security Considerations: none
( <subject> / <issuer> / <certification> )
<version> ::= "Version:" "5" CRLF
<subject> ::= "Subject:" <id> CRLF
<issuer> ::= "Issuer:" <id> CRLF
<certification> ::= "Certification:" <encbin> CRLF
This content type is used to provide for some of the request messages The content of this body part corresponds to the following
described in [6]. The information in the body part is entirely production.
independent of any other body part. As such, the application/pemkey-
request content type is an independent body part.
The certification request, certificate-retrieval request and crl- <request> ::= <version>
retrieval request are provided for directly. If the content contains a ( <subject> / <issuer> / <certification> )
Certification: field it requests certification of the self-signed
certificate in the field value. If the content contains an Issuer:
field it requests the Certificate Revocation List (CRL) chain beginning
with the CRL of the issuer identified in the field value. If the
content contains a Subject: field it requests either the public key of
the subject or a certificate chain beginning with the subject identified
in the field value, or both if both exist.
The Subject: and Issuer: fields each contain a value of type <id>, which <version> ::= "Version:" "5" CRLF
is defined in Section 2.2.
The crl-storage request is provided for by the application/pemkey-data <subject> ::= "Subject:" <id> CRLF
content type described in the Section 5.2.
In each case, the response is transmitted in an application/pemkey-data <issuer> ::= "Issuer:" <id> CRLF
content type. When returning public keys, certificate chains, and
certificate revocation list chains, if there exists more than one,
several application/pemkey-data body parts are to be returned in the
reply message, one for each.
5.2. application/pemkey-data Content Type Definition <certification> ::= "Certification:" <encbin> CRLF
The principal objective of this content type is to convey cryptographic A user would use this content type to specify needed cryptographic
keying material from a source to a destination. However, no explicit key information. The message containing this content type might be
provision is made for determining the authenticity or accuracy of the directed towards an automatic or manual responder, which may be
data being conveyed. In particular, when a public key and its mail-based, depending on the local implementation and environment.
identifier is conveyed, there is nothing to prevent the source or an The application/mosskey-request content type is an independent body
interloper along the path from the source to the destination from part because it is entirely independent of any other body part.
substituting alternate values for either the public key or the
identifier, thus setting up the destination such that when the data is
used sensitive information may be intercepted and disclosed
inappropriately.
It is incumbent upon a recipient to verify the authenticity and accuracy If the application/mosskey-request content contains a Certification:
of the data received prior to its use. The problem is addressed by the field it requests certification of the self-signed certificate in the
use of certificates, since a certification hierarchy is a well-defined field value. If the content contains an Issuer: field it requests
mechanism that conveniently supports the automatic verification of the the Certificate Revocation List (CRL) chain beginning with the CRL of
data. Alternatively, the application/key-data body part could be the issuer identified in the field value. If the content contains a
digitally signed by the source. In this way, if the destination Subject: field it requests either the public key of the subject or a
believes that a correct source's public key is available locally and if certificate chain beginning with the subject identified in the field
the destination believes the source would convey accurate data, then the value, or both if both exist.
key data received from the source can be believed.
NOTE: Insofar as a certificate represents a mechanism by which a The Subject: and Issuer: fields each contain a value of type <id>,
third party vouches for the binding between a name and a public which is defined in Section 4.
key, the signing of an application/pemkey-data body part is a
similar mechanism.
(1) MIME type name: application One possible response to receiving an application/mosskey-request
body part is to construct and return an application/mosskey-data body
part. When returning public keys, certificate chains, and
certificate revocation list chains, if there exists more than one,
several application/mosskey-data body parts are to be returned in the
reply message, one for each.
(2) MIME subtype name: pemkey-data 5.2. application/mosskey-data Content Type Definition
(3) Required parameters: none The principal objective of this content type is to convey
cryptographic keying material from a source to a destination. This
might be in response to the receipt of an application/mosskey-request
content type or it might be in anticipation of receiving an
application/mosskey-request if it is not sent, e.g., it may be
combined with a multipart/signed object by an originator to ensure
that a recipient has the cryptographic keying material necessary to
verify the signature. When combined with other content types, the
processing by a recipient is enhanced if the application/mosskey-data
content type is positioned in its enclosing content type prior to the
content types that will make use of its cryptographic keying
material.
(4) Optional parameters: none However, no explicit provision is made in this document for
determining the authenticity or accuracy of the data being conveyed.
In particular, when a public key and its identifier is conveyed,
there is nothing to prevent the source or an interloper along the
path from the source to the destination from substituting alternate
values for either the public key or the identifier.
(5) Encoding considerations: quoted-printable is always sufficient. It is incumbent upon a recipient to verify the authenticity and
accuracy of the data received in this way prior to its use. This
problem can be addressed by the use of certificates, since a
certification hierarchy is a well-defined mechanism that conveniently
supports the automatic verification of the data. Alternatively, the
source of the application/mosskey-data body part could digitally sign
it. In this way, if the destination believes that a correct source's
public key is available locally and if the destination believes the
source would convey accurate data, then the contents of the
application/mosskey-data from the source could be believed to be
accurate.
(6) Security Considerations: none NOTE: Insofar as a certificate represents a mechanism by which a
third party vouches for the binding between a name and a public
key, the signing of an application/mosskey-data body part is a
similar mechanism.
The content of this body part corresponds to the following production. (1) MIME type name: application
<keydata> ::= <version> (2) MIME subtype name: mosskey-data
( <publickeydata> / <certchain> / <crlchain> )
<version> ::= "Version:" "5" CRLF
<publickeydata> ::= "Key:" "PK" "," <publickey> "," <id-subset> CRLF
<certchain> ::= <cert> *( [ <crl> ] <cert> )
<crlchain> ::= 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLF
This content type is used to transfer public keys, certificate chains, (3) Required parameters: none
or Certificate Revocation List (CRL) chains. The information in the
body part is entirely independent of any other body part. (Note that
the converse is not true: the validity of a protected body part cannot
be determined without the proper public keys, certificates, or current
CRL information.) As such, the application/pemkey-data content type is
an independent body part.
The <publickeydata> production contains exactly one public key. It is (4) Optional parameters: none
used to bind a public key with its corresponding name form and key
selector. It is recommended that when responders are returning this
information that the enclosing body part be digitally signed by the
responder in order to protect the information. The <id-subset> token is
defined in Section 2.2.4.
The <certchain> production contains one certificate chain. A (5) Encoding considerations: quoted-printable is always sufficient.
certificate chain starts with a certificate and continues with the
certificates of subsequent issuers. Each issuer certificate included
must have issued the preceding certificate. For each issuer, a CRL may
be supplied. A CRL in the chain belongs to the immediately following
issuer. Therefore, it potentially contains the immediately preceding
certificate.
The <crlchain> production contains one certificate revocation list (6) Security Considerations: none
chain. The CRLs in the chain begin with the requested CRL and continue
with the CRLs of subsequent issuers. The issuer of each CRL is presumed
to have issued a certificate for the issuer of the preceding CRL. For
each CRL, the issuer's certificate may be supplied. A certificate in
the chain must belong to the issuer of the immediately preceding CRL.
The relationship between a certificate and an immediately preceding CRL The content of this body part corresponds to the following
is the same in both <certchain> and <crlchain>. In a <certchain> the production.
CRLs are optional. In a <crlchain> the certificates are optional.
6. Examples <mosskeydata> ::= <version>
( <publickeydata> / <certchain> / <crlchain> )
Given the following email message prepared for submission: <version> ::= "Version:" "5" CRLF
To: Ned Freed <ned@innosoft.com> <publickeydata> ::= "Key:" "PK" "," <publickey> ","
Subject: Hi Ned! <id-subset> CRLF
How do you like the new MIME/PEM? <certchain> ::= <cert> *( [ <crl> ] <cert> )
Jim <crlchain> ::= 1*( <crl> [ <cert> ] )
When the text of the message is signed, it will look like this (note the <cert> ::= "Certificate:" <encbin> CRLF
use of the public key identifier with the included email name
identifier):
To: Ned Freed <ned@innosoft.com> <crl> ::= "CRL:" <encbin> CRLF
Subject: Hi Ned!
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pem-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
--Signed Boundary This content type is used to transfer public keys, certificate
Content-Type: text/plain; charset="us-ascii" chains, or Certificate Revocation List (CRL) chains. The information
Content-ID: <21436.785186814.2@tis.com> in the body part is entirely independent of any other body part.
(Note that the converse is not true: the validity of a protected body
part cannot be determined without the proper public keys,
certificates, or current CRL information.) As such, the
application/mosskey-data content type is an independent body part.
How do you like the new MIME/PEM? The <publickeydata> production contains exactly one public key. It
is used to bind a public key with its corresponding name form and key
selector. It is recommended that when responders are returning this
information that the enclosing body part be digitally signed by the
responder in order to protect the information. The <id-subset> token
is defined in Section 4.2.4.
Jim The <certchain> production contains one certificate chain. A
certificate chain starts with the requested certificate and continues
with the certificates of subsequent issuers. Each issuer certificate
included must have issued the preceding certificate. For each
issuer, a CRL may be supplied. A CRL in the chain belongs to the
immediately following issuer. Therefore, it potentially contains the
immediately preceding certificate.
--Signed Boundary The <crlchain> production contains one certificate revocation list
Content-Type: application/pem-signature chain. The CRLs in the chain begin with the requested CRL and
Content-ID: <21436.785186814.1@tis.com> continue with the CRLs of subsequent issuers. The issuer of each CRL
Content-Transfer-Encoding: quoted-printable is presumed to have issued a certificate for the issuer of the
preceding CRL. For each CRL, the issuer's certificate may be
supplied. A certificate in the chain must belong to the issuer of
the immediately preceding CRL.
Version: 5 The relationship between a certificate and an immediately preceding
Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B= CRL is the same in both <certchain> and <crlchain>. In a <certchain>
ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g= the CRLs are optional. In a <crlchain> the certificates are
G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com optional.
MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERfMZXUKzFsHbmK=
tIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfbsOVJjleV7vTe9yoNp2P8mi/h=
s7
--Signed Boundary-- 6. Examples
If, instead, we choose to protect the headers with the text, it will Each example is included as a separate section for ease of reference.
look like this:
To: Ned Freed <ned@innosoft.com> 6.1. Original Message Prepared for Protection
Subject: Hi Ned!
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pem-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
--Signed Boundary Except as explicitly indicated, the following message is used as the
Content-Type: message/rfc822 message to be protected.
Content-ID: <21468.785187044.2@tis.com>
To: Ned Freed <ned@innosoft.com> To: Ned Freed <ned@innosoft.com>
Subject: Hi Ned! Subject: Hi Ned!
How do you like the new MIME/PEM? How do you like the new MOSS?
Jim Jim
--Signed Boundary 6.2. Sign Text of Original Message
Content-Type: application/pem-signature
Content-ID: <21468.785187044.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5 When the text of the original message is signed, it will look like
Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B= this, where lines with an ampersand '&' are digitally signed (note
ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g= the use of the public key identifier with the included email name
G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com identifier, on the lines marked with an asterisk '*'):
MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WTwjfxFBvAceVW=
fawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4Gd8dBBwMKvqMKTHAUxGXYxwNd=
bK
--Signed Boundary-- To: Ned Freed <ned@innosoft.com>
Subject: Hi Ned!
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
If we choose to encrypt the text of the following message, that is, --Signed Boundary
encrypt the lines marked with asterick (*): & Content-Type: text/plain; charset="us-ascii"
& Content-ID: <21436.785186814.2@tis.com>
&
& How do you like the new MOSS?
&
& Jim
To: Jim Galvin <galvin@tis.com> --Signed Boundary
Subject: an encrypted message Content-Type: application/moss-signature
Content-ID: <21436.785186814.1@tis.com>
Content-Transfer-Encoding: quoted-printable
* How do you like the new MIME/PEM? Version: 5
* * Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=
* Jim * qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=
* KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,=
* 2,galvin@tis.com
MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERf=
MZXUKzFsHbmKtIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfb=
sOVJjleV7vTe9yoNp2P8mi/hs7
the message would look as follows (note the use of the email name --Signed Boundary--
identifier):
To: Jim Galvin <galvin@tis.com> 6.3. Sign Headers and Text of Original Message
Subject: an encrypted message
MIME-Version: 1.0
Content-Type: multipart/encrypted; protocol="application/pem-keys";
boundary="Encrypted Boundary"
--Encrypted Boundary If, instead, we choose to protect the headers with the text of the
Content-Type: application/pem-keys original message, it will look like this, where lines with an
Content-ID: <21535.785187667.1@tis.com> ampersand '&' are encrypted:
Content-Transfer-Encoding: quoted-printable
Version: 5 To: Ned Freed <ned@innosoft.com>
DEK-Info: DES-CBC,D488AAAE271C8159 Subject: Hi Ned!
Recipient-ID: EN,2,galvin@tis.com MIME-Version: 1.0
Key-Info: RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/7NvSqqXSK/WZ= Content-Type: multipart/signed;
q05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT9P6jyzcV1NzZVwfp+u protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Boundary"
--Encrypted Boundary --Signed Boundary
Content-Type: application/octet-stream & Content-Type: message/rfc822
Content-Transfer-Encoding: base64 & Content-ID: <21468.785187044.2@tis.com>
&
& To: Ned Freed <ned@innosoft.com>
& Subject: Hi Ned!
&
&
& How do you like the new MOSS?
&
& Jim
AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynUd4jcJgRnQIQvIx --Signed Boundary
m2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4wonUUP265UvvMj23RSTguZ/nl/Oxn Content-Type: application/moss-signature
FM6SzDgV39V/i/RofqI= Content-ID: <21468.785187044.1@tis.com>
Content-Transfer-Encoding: quoted-printable
--Encrypted Boundary-- Version: 5
Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4f=
qQ61aoC1fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8=
KRGJ9wh1HU4TrghGdhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,=
2,galvin@tis.com
MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WT=
wjfxFBvAceVWfawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4G=
d8dBBwMKvqMKTHAUxGXYxwNdbK
If, instead, we choose to sign the text before we encrypt it, the --Signed Boundary--
structure would be as follows (where lines with an asterick '*' are
digitally signed and lines with an ampersand '&' are encrypted):
Content-Type: multipart/encrypted; boundary="Encrypted Boundary" 6.4. Encrypt Text of a Message
--Encrypted Boundary If we choose to encrypt the text of the following message, that is,
Content-Type: application/pem-keys encrypt the lines marked with asterisk '*':
KEY INFORMATION To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
--Encrypted Boundary * How do you like the new MOSS?
Content-Type: application/octet-stream *
* Jim
& Content-Type: multipart/signed; boundary="Signed Boundary" the message would look as follows (note the use of the email name
& identifier, on the line marked with an asterisk '*'):
& --Signed Boundary
& * Content-Type: text/plain
& *
& * How do you like the new MIME/PEM?
& *
& * Jim
&
& --Signed Boundary
& Content-Type: application/pem-signature
&
& SIGNATURE INFORMATION
&
& --Signed Boundary--
--Encrypted Boundary-- To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
where KEY INFORMATION and SIGNATURE INFORMATION are descriptive of the --Encrypted Boundary
actual content that would appear in a real body part. The actual Content-Type: application/moss-keys
message would be like this: Content-ID: <21535.785187667.1@tis.com>
Content-Transfer-Encoding: quoted-printable
To: Jim Galvin <galvin@tis.com> Version: 5
Subject: an encrypted message DEK-Info: DES-CBC,D488AAAE271C8159
MIME-Version: 1.0 * Recipient-ID: EN,2,galvin@tis.com
Content-Type: multipart/encrypted; protocol="application/pem-keys"; Key-Info: RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/=
7NvSqqXSK/WZq05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT=
9P6jyzcV1NzZVwfp+u
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynU
d4jcJgRnQIQvIxm2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4w
onUUP265UvvMj23RSTguZ/nl/OxnFM6SzDgV39V/i/RofqI=
--Encrypted Boundary--
6.5. Encrypt the Signed Text of a Message
If, instead, we choose to sign the text before we encrypt it, the
structure would be as follows, where lines with an asterisk '*' are
digitally signed and lines with an ampersand '&' are encrypted:
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary" boundary="Encrypted Boundary"
--Encrypted Boundary --Encrypted Boundary
Content-Type: application/pem-keys Content-Type: application/moss-keys
Content-ID: <21546.785188458.1@tis.com>
Content-Transfer-Encoding: quoted-printable
Version: 5 KEY INFORMATION
DEK-Info: DES-CBC,11CC89F8D90F1DFE
Recipient-ID: EN,2,galvin@tis.com
Key-Info: RSA,AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJzY8+vIfbh5B=
pR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rVjpb4EOUlwOXwRZ
--Encrypted Boundary --Encrypted Boundary
Content-Type: application/octet-stream Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ52V/wkxwMrum6 & Content-Type: multipart/signed;
xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2U6B13vzpE8wMSVefzaCTSpXR & protocol="application/moss-signature";
SCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpYLwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui & micalg="rsa-md5"; boundary="Signed Boundary"
49Xon1Gft+N5XDH/+wI9qxI9fkQvNZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+ &
nRCXcuO0Px3yKRyYg/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2Kr & --Signed Boundary
WhiF2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+tL4IgMjQ & * Content-Type: text/plain
qm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmkYjCxVviJP3zO2UzBvCoM & *
fADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9 & * How do you like the new MOSS?
Dixl8WCx3rxwN5g2QFLiyQVulzuNhimSD4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81Nc & *
pQJRPNAvF0IkN6ddwL4qvzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/ & * Jim
c/vpbunQUqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp+ymx &
hTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1fNkSRnc8BZswIoPyR & --Signed Boundary
etsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6ubygBqJiKPM4II2fCdNj7CptfQco & Content-Type: application/moss-signature
RTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhfzysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8 &
S2nLPCZl1hzdajsrqHFe8omQ & SIGNATURE INFORMATION
&
& --Signed Boundary--
--Encrypted Boundary-- --Encrypted Boundary--
In addition to text, the PEM services as defined here will protect where KEY INFORMATION and SIGNATURE INFORMATION are descriptive of
arbitrary body parts, for example, the following audio body part: the actual content that would appear in a real body part. The actual
message would be like this:
Content-Type: audio/basic To: Jim Galvin <galvin@tis.com>
Subject: an encrypted message
MIME-Version: 1.0
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
AUDIO DATA HERE --Encrypted Boundary
Content-Type: application/moss-keys
Content-ID: <21546.785188458.1@tis.com>
Content-Transfer-Encoding: quoted-printable
when signed would appear as follows: Version: 5
DEK-Info: DES-CBC,11CC89F8D90F1DFE
Recipient-ID: EN,2,galvin@tis.com
Key-Info: RSA,AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJz=
Y8+vIfbh5BpR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rV=
jpb4EOUlwOXwRZ
Content-Type: multipart/signed; protocol="application/pem-signature"; --Encrypted Boundary
micalg="rsa-md5"; boundary="Signed Boundary" Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
--Signed Boundary ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ5
Content-Type: audio/basic 2V/wkxwMrum6xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2
Content-Transfer-Encoding: base64 U6B13vzpE8wMSVefzaCTSpXRSCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpY
Lwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui49Xon1Gft+N5XDH/+wI9qxI9fkQv
NZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+nRCXcuO0Px3yKRyY
g/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2KrWhiF
2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+
tL4IgMjQqm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmk
YjCxVviJP3zO2UzBvCoMfADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m
04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9Dixl8WCx3rxwN5g2QFLiyQVulzuNhimS
D4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81NcpQJRPNAvF0IkN6ddwL4q
vzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/c/vpbunQ
UqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp
+ymxhTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1f
NkSRnc8BZswIoPyRetsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6
ubygBqJiKPM4II2fCdNj7CptfQcoRTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhf
zysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8S2nLPCZl1hzdajsrqHFe8omQ
base64(AUDIO DATA HERE) --Encrypted Boundary--
--Signed Boundary 6.6. Protecting Audio Content
Content-Type: application/pem-signature
SIGNATURE INFORMATION HERE In addition to text, the MOSS services as defined here will protect
arbitrary body parts, for example, the following audio body part:
and when encrypted would appear as follows: Content-Type: audio/basic
Content-Type: multipart/encrypted; protocol="application/pem-keys"; AUDIO DATA HERE
boundary="Encrypted Boundary"
--Encrypted Boundary 6.6.1. Sign Audio Content
Content-Type: application/pem-keys
KEY INFORMATION HERE When signed an audio content would appear as follows, where lines
with an ampersand '&' are digitally signed:
--Encrypted Boundary Content-Type: multipart/signed;
Content-Type: application/octet-stream protocol="application/moss-signature";
Content-Transfer-Encoding: base64 micalg="rsa-md5"; boundary="Signed Boundary"
base64(encrypted(AUDIO DATA HERE)) --Signed Boundary
& Content-Type: audio/basic
& Content-Transfer-Encoding: base64
&
& base64(AUDIO-DATA-HERE)
--Encrypted Boundary-- --Signed Boundary
Content-Type: application/moss-signature
SIGNATURE-INFORMATION-HERE
--Signed Boundary--
where AUDIO-DATA-HERE and SIGNATURE-INFORMATION-HERE are descriptive
of the content that would appear in a real body part.
6.6.2. Encrypt Audio Content
When encrypted an audio content would appear as follows, where lines
with an ampersand '&' are encrypted:
Content-Type: multipart/encrypted;
protocol="application/moss-keys";
boundary="Encrypted Boundary"
--Encrypted Boundary
Content-Type: application/moss-keys
KEY-INFORMATION-HERE
--Encrypted Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
& Content-Type: audio/basic
&
& base64(encrypted(AUDIO-DATA-HERE))
--Encrypted Boundary--
where KEY-INFORMATION-HERE and AUDIO-DATA-HERE are descriptive of the
content that would appear in a real body part.
7. Observations 7. Observations
The use of the pre-submission and post-delivery processing steps to The use of MIME and the framework defined by [7] exhibits several
combine PEM and MIME capabilities exhibits several properties: properties:
(1) It allows privacy-enhancement of an arbitrary content, not just the (1) It allows arbitrary content types to be protected, not just the
body of an RFC822 message. body of an RFC822 message.
(2) For a multipart or message content, it allows the user to specify (2) It allows a message to contain several body parts which may or
different privacy enhancements to be applied to different may not be protected.
components of the structure of the content.
(3) It provides for messages containing several privacy enhanced (3) It allows the components of a multipart or message content to be
contents, thereby removing the requirement for PEM software to be protected with different services.
able to generate or interpret a single content which intermixes
both unenhanced and enhanced components.
The use of a MIME-capable user agent makes complex nesting of enhanced The use of a MIME-capable user agent makes complex nesting of
message body parts much easier. For example, the user can separately protected message body parts much easier. For example, the user can
sign and encrypt a message. This motivates a complete separation of the separately sign and encrypt a message. This allows complete
confidentiality security service from the digital signature security separation of the confidentiality security service from the digital
service. That is, different key pairs could be used for the different signature security service. That is, different key pairs could be
services and could be protected separately. used for the different services and could be protected separately.
This is useful for at least two reasons. First, some public key This is useful for at least two reasons. First, some public key
algorithms do not support both digital signatures and encryption, for algorithms do not support both digital signatures and encryption; two
example, the way that the RSA algorithm does; two key pairs would be key pairs would be required in this case. Second, an employee's
required in this case. Second, an employee's company could be given company could be given access to the (private) decryption key but not
access to the (private) decryption key but not the (private) signature the (private) signature key, thereby granting the company the ability
key, thereby granting the company the ability to decrypt messages to decrypt messages addressed to the employee in emergencies without
addressed to the employee in emergencies without also granting the also granting the company the ability to sign messages as the
company the ability to sign messages as the employee. employee.
8. Summary of Changes to PEM Specification 8. Comparison of MOSS and PEM Protocols
This document updates the message encryption and signature procedures MOSS differs from PEM in the following ways.
defined by [3] and replaces the key certification and related services
defined by [6]. The changes are enumerated below.
(1) The PEM specification currently requires that encryption services (1) When using PEM, users are required to have certificates. When
be applied only to message bodies that have been signed. By using MOSS, users need only have a public/private key pair.
providing for each of the services separately, they may be applied
recursively in any order according to the needs of the requesting
application.
(2) PEM implementations are currently restricted to processing only (2) MOSS broadens the allowable name forms that users may use to
text-based electronic mail messages. In fact, the message text is identify their public keys, including arbitrary strings, email
required to be represented by the ASCII character set with addresses, or distinguished names.
"<CR><LF>" line delimiters. This restriction no longer applies.
(3) MIME includes transfer encoding operations to ensure the unmodified (3) PEM currently only supports text-based electronic mail messages
transfer of body parts, which obviates these services in PEM. and the message text is required to be represented by the ASCII
character set with "<CR><LF>" line delimiters. These
restrictions no longer apply.
(4) PEM specifies a Proc-Type: header field to identify the type of (4) The PEM specification currently requires that encryption
processing that was performed on the message. This functionality services be applied only to message bodies that have been
is subsumed by the MIME Content-Type: headers. The Proc-Type: signed. By providing for each of the services separately, they
header also included a decimal number that was used to distinguish may be applied in any order according to the needs of the
among incompatible encapsulated header field interpretations which requesting application.
may arise as changes are made to the PEM standard. This
functionality is replaced by the Version: header specified in this
document.
(5) PEM specifies a Content-Domain: header, the purpose of which is to (5) MIME includes transfer encoding operations to ensure the
describe the type of the content which is represented within a PEM unmodified transfer of body parts. Therefore, unlike PEM, MOSS
message's encapsulated text. This functionality is subsumed by the does not need to include these functions.
MIME Content-Type: headers.
(6) The PEM specifications include a document that defines new types of (6) PEM specifies a Proc-Type: header field to identify the type of
PEM messages, specified by unique values used in the Proc-Type: processing that was performed on the message. This
header, to be used to request certificate and certificate functionality is subsumed by the MIME Content-Type: headers.
revocation list information. This functionality is subsumed by two The Proc-Type: header also includes a decimal number that is
new content types specified in this document. used to distinguish among incompatible encapsulated header field
interpretations which may arise as changes are made to the PEM
standard. This functionality is replaced by the Version: header
specified in this document.
(7) The header fields having to do with certificates (Originator- (7) PEM specifies a Content-Domain: header, the purpose of which is
Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated to describe the type of the content which is represented within
for use only in the application/pemkey-data and a PEM message's encapsulated text. This functionality is
application/pemkey-request content types and are no longer allowed subsumed by the MIME Content-Type: headers.
in the header portion of a PEM signed or encrypted message.
(8) The grammar specified here explicitly separates the header fields (8) The PEM specifications include a document that defines new types
that may appear for the encryption and signature security services. of PEM messages, specified by unique values used in the Proc-
It is the intent of this document to specify a precise expression Type: header, to be used to request certificate and certificate
of the allowed header fields; there is no intent to disallow the revocation list information. This functionality is subsumed by
functionality of combinations of encryption and signature security two new content types specified in this document:
found in [3]. application/mosskey- request and application/mosskey-data.
(9) With the separation of the encryption and signature security (9) The header fields having to do with certificates (Originator-
services, there is no need for a MIC-Info: field in the headers Certificate: and Issuer-Certificate:) and CRLs (CRL:) are
associated with an encrypted message. relegated for use only in the application/mosskey-data and
application/mosskey-request content types and are no longer
allowed in the header portion of a PEM signed or encrypted
message. This separates key management services from the
digital signature and encryption services.
(10) In [3], when asymmetric key management is used, an Originator-ID (10) The grammar specified here explicitly separates the header
field is required in order to identify the private key used to sign fields that may appear for the encryption and signature security
the MIC argument in the MIC-Info: field. Because no MIC-Info: services. It is the intent of this document to specify a
field is associated with the encryption security service under precise expression of the allowed header fields; there is no
asymmetric key managment, there is no requirement in that case to intent to disallow the functionality of combinations of
include an Originator-ID field. encryption and signature security found in [3].
These changes represent a departure in mechanism, not in effect, from (11) With the separation of the encryption and signature security
those specified in [3] and [6]. The following technical changes to [3] services, there is no need for a MIC-Info: field in the headers
and [4] are also specified by this document. associated with an encrypted message.
(1) The grammar specified here explicitly excludes symmetric key (12) In [3], when asymmetric key management is used, an Originator-ID
management. Currently, there are no generally available field is required in order to identify the private key used to
implementations of symmetric key management nor are there any known sign the MIC argument in the MIC-Info: field. Because no MIC-
plans for implementing it. As a result, the IETF standards process Info: field is associated with the encryption security service
will require this feature to be dropped when the documents are under asymmetric key management, there is no requirement in that
promoted to draft standard status from proposed standard status. case to include an Originator-ID field.
(2) This document requires all data that is to be digitally signed to (13) The protocol specified here explicitly excludes symmetric key
be represented in 7bit form. management.
(3) This document broadens the allowable name forms that users may use (14) This document requires all data that is to be digitally signed
to identify their public keys. Users may use arbitrary strings and to be represented in 7bit form.
email addresses as their name. Further, users may distribute their
public key directly in lieu of using certificates. In support of
this change the Originator-ID-ASymmetric: and Recipient-ID-
ASymmetric: fields are deprecated in favor of Originator-ID: and
Recipient-ID: fields, respectively.
9. Collected Grammar 9. Security Considerations
The version of the grammar in this document is as follows: This entire document is about security.
<version> ::= "Version:" "5" CRLF 10. Acknowledgements
The content of an application/pem-signature body part is as follows: David H. Crocker suggested the use of a multipart structure for the
MIME and PEM interaction, which has evolved into the MOSS protocol.
<pemsig> ::= <version> ( 1*<origasymflds> ) The MOSS protocol is a direct descendant of the PEM protocol. The
authors gratefully acknowledge the editors of those specification,
especially John Linn and Steve Kent. This work would not have been
possible had it not been for all of the PEM developers, users, and
interested persons who are always present on the PEM developers
mailing list and at PEM working group meetings at IETF meetings,
especially, Amanda Walker, Bob Juenemann, Steve Dusse, Jeff Thomson,
and Rhys Weatherly.
<origasymflds> ::= <origid> <micinfo> 11. References
<origid> ::= "Originator-ID:" <id> CRLF [1] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.
The content of an application/pem-keys body part is as follows: [2] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
Extension) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies", RFC 1521, Bellcore and
Innosoft, September 1993.
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds> [3] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures", RFC 1421,
IAB IRTF PSRG, IETF PEM WG, February 1993.
<recipasymflds> ::= <recipid> <asymkeyinfo> [4] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
II: Certificate-Based Key Management", RFC 1422, BBN
Communications, February 1993.
<recipid> ::= "Recipient-ID:" <id> CRLF [5] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC 1423, Trusted
Information Systems, February 1993.
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF [6] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
Part IV: Key Certification and Related Services", RFC 1424, RSA
Laboratories, February 1993.
Identifiers are defined as follows: [7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, Trusted Information Systems and Innosoft, September
1995.
<id> ::= <id-subset> / <id-publickey> / <id-issuer> [8] The Directory -- Models. X.501, 1988. Developed in
collaboration, and technically aligned, with ISO 9594-2.
<id-subset> ::= <id-email> / <id-string> / <id-dname> [9] The Directory -- Authentication Framework. X.509, 1988.
Developed in collaboration, and technically aligned, with ISO
9594-8.
<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF 12. Authors' Addresses
<id-string> ::= "STR" "," <keysel> "," <string> CRLF Steve Crocker
CyberCash, Inc.
2086 Hunters Crest Way
Vienna, VA 22181
<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF Phone: +1 703 620 1222
Fax: +1 703 391 2651
EMail: crocker@cybercash.com
<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF James M. Galvin
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF Phone: +1 301 854 6889
Fax: +1 301 854 5363
EMail: galvin@tis.com
<keysel> ::= <encbin> Sandra Murphy
; a printably encoded non-null sequence of octets Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
<emailstr> ::= <addr-spec> / <route-addr> Phone: +1 301 854 6889
; an electronic mail address as defined by Fax: +1 301 854 5363
; these two tokens from RFC822 EMail: murphy@tis.com
<string> ::= ; a non-null sequence of characters Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
<dnamestr> ::= <encbin> Phone: +1 818 919 3600
; a printably encoded, ASN.1 encoded Fax: +1 818 919 3614
; distinguished name EMail: ned@innosoft.com
<publickey> ::= <encbin> Appendix A: Collected Grammar
; a printably encoded, ASN.1 encoded
; subjectPublicKeyInfo
<serial> ::= 1*<hexchar> The version of the grammar in this document is as follows:
; hex dump of the serial number of a certificate
The content of an application/pemkey-request body part is as follows: <version> ::= "Version:" "5" CRLF
<request> ::= <version> The following grammar tokens are used throughout this specification:
( <subject> / <issuer> / <certification> )
<subject> ::= "Subject:" <id> CRLF <encbin> ::= 1*<encbingrp>
<issuer> ::= "Issuer:" <id> CRLF <encbingrp> ::= 4*4<encbinchar>
<certification> ::= "Certification:" <encbin> CRLF <encbinchar> ::= <ALPHA> / <DIGIT> / "+" / "/" / "="
The content of an application/pemkey-data body part is as follows: <hexchar> ::= <DIGIT> / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
<keydata> ::= <version> The content of an application/moss-signature body part is as follows:
( <publickeydata> / <certchain> / <crlchain> )
<publickeydata> ::= "Key:" "PK" "," <publickey> "," <id-subset> CRLF <mosssig> ::= <version> ( 1*<origasymflds> )
<certchain> ::= <cert> *( [ <crl> ] <cert> ) <version> ::= "Version:" "5" CRLF
<crlchain> ::= 1*( <crl> [ <cert> ] ) <origasymflds> ::= <origid> <micinfo>
<cert> ::= "Certificate:" <encbin> CRLF <origid> ::= "Originator-ID:" <id> CRLF
<crl> ::= "CRL:" <encbin> CRLF <micinfo> ::= "MIC-Info:" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
10. Security Considerations The content of an application/moss-keys body part is as follows:
This entire document is about security. <mosskeys> ::= <version> <dekinfo> 1*<recipasymflds>
11. Acknowledgements <version> ::= "Version:" "5" CRLF
David H. Crocker suggested the use of a multipart structure for MIME-PEM <dekinfo> ::= "DEK-Info" ":" <dekalgid>
interaction. [ "," <dekparameters> ] CRLF
12. References <recipasymflds> ::= <recipid> <asymkeyinfo>
[1] David H. Crocker. Standard for the Format of ARPA Internet Text <recipid> ::= "Recipient-ID:" <id> CRLF
Messages. RFC 822, University of Delaware, August 1982.
[2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
Mail Extension) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies. RFC 1521, Bellcore and
Innosoft, September 1993. Obsoletes RFC 1341.
[3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part Identifiers are defined as follows:
I: Message Encryption and Authentication Procedures. RFC 1421,
February 1993. Obsoletes RFC 1113.
[4] Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part <id> ::= <id-subset> / <id-publickey> / <id-issuer>
II: Certificate-Based Key Management. RFC 1422, BBN
Communications, February 1993.
[5] David M. Balenson. Privacy Enhancement for Internet Electronic <id-subset> ::= <id-email> / <id-string> / <id-dname>
Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423,
Trusted Information Systems, February 1993.
[6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic <id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF
Mail: Part IV: Key Certification and Related Services. RFC 1424,
RSA Laboratories, February 1993.
[7] James Galvin, Sandy Murphy, Steve Crocker, and Ned Freed. Security <id-string> ::= "STR" "," <keysel> "," <string> CRLF
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.
RFC XXXX, Trusted Information Systems and Innosoft, XXXX 1994.
13. Authors' Addresses <id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
Steve Crocker <id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
email: crocker@tis.com
James M. Galvin <id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
email: galvin@tis.com
Sandra Murphy <keysel> ::= 1*<hexchar>
email: murphy@tis.com ; hex dump of a non-null sequence of octets
Trusted Information Systems <emailstr> ::= <addr-spec> / <route-addr>
3060 Washington Road ; an electronic mail address as defined by
Glenwood, MD 21738 ; these two tokens from RFC822
Tel: +1 301 854 6889
FAX: +1 301 854 5363
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
Tel: +1 818 919 3600
FAX: +1 818 919 3614
email: ned@innosoft.com
14. Appendix: Imported Grammar <string> ::= ; a non-null sequence of characters
The following productions are taken from [3]. The grammar presented in <dnamestr> ::= <encbin>
[3] remains the authoritative source for these productions; they are ; a printably encoded, ASN.1 encoded
repeated here for the convenience of the reader. ; distinguished name (as defined by the 'Name'
; production specified in X.501 [8])
<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF <publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded public
; key (as defined by the
; 'SubjectPublicKeyInfo' production specified
; in X.509 [9])
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> "," <serial> ::= 1*<hexchar>
<asymsignmic> CRLF ; hex dump of a certificate serial number
<encbin> ::= 1*<encbingrp> The content of an application/mosskey-request body part is as
<encbingrp> ::= 4*4<encbinchar> follows:
<encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
The following productions are taken from [5]. The grammar presented in <request> ::= <version>
[5] remains the authoritative source for these productions; they are ( <subject> / <issuer> / <certification> )
repeated here for the convenience of the reader.
<dekalgid> ::= "DES-CBC" <version> ::= "Version:" "5" CRLF
<ikalgid> ::= "DES-EDE" / "DES-ECB" / "RSA" <subject> ::= "Subject:" <id> CRLF
<micalgid> ::= "RSA-MD2" / "RSA-MD5"
<dekparameters> ::= <DESCBCparameters> <issuer> ::= "Issuer:" <id> CRLF
<DESCBCparameters> ::= <IV>
<IV> ::= <hexchar16>
<asymsignmic> ::= <RSAsignmic> <certification> ::= "Certification:" <encbin> CRLF
<RSAsignmic> ::= <encbin>
<asymencdek> ::= <RSAencdek> The content of an application/mosskey-data body part is as follows:
<RSAencdek> ::= <encbin>
<hexchar16> ::= 16*16<hexchar> <mosskeydata> ::= <version>
<hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F" ( <publickeydata> / <certchain> / <crlchain> )
; no lower case
The following productions are taken from [1]. The grammar presented in <version> ::= "Version:" "5" CRLF
[1] remains the authorative source for these productions; they are
repeated here for the convenience of the reader.
<addr-spec> ::= <local-part> "@" <domain> ; global address <publickeydata> ::= "Key:" "PK" "," <publickey> ","
<id-subset> CRLF
<local-part> ::= <word> *( "." <word> ) ; uninterpreted <certchain> ::= <cert> *( [ <crl> ] <cert> )
; case-preserved
<domain> ::= <sub-domain> *( "." <sub-domain> ) <crlchain> ::= 1*( <crl> [ <cert> ] )
<sub-domain> ::= <domain-ref> / <domain-literal> <cert> ::= "Certificate:" <encbin> CRLF
<domain-ref> ::= <atom> ; symbolic reference <crl> ::= "CRL:" <encbin> CRLF
<route-addr> ::= "<" [ <route> ] <addr-spec> ">" Appendix B: Imported Grammar
<route> ::= 1# ( "@" <domain> ) ":" ; path-relative Options normally present in the grammar reprinted here which are
illegal in MOSS are excluded in this reprinting, for the convenience
of the reader.
<word> ::= <atom> / <quoted-string> The following productions are taken from [5]. The grammar presented
in [5] remains the authoritative source for these productions; they
are repeated here for the convenience of the reader.
<quoted-string> ::= """ *( <qtext> / <quoted-pair> ) """ <dekalgid> ::= "DES-CBC"
<ikalgid> ::= "RSA"
<micalgid> ::= "RSA-MD2" / "RSA-MD5"
<qtext> ::= (any <CHAR> excepting """, " <dekparameters> ::= <DESCBCparameters>
and including <linear-white-space>) <DESCBCparameters> ::= <IV>
<IV> ::= <hexchar16>
<hexchar16> ::= 16*16<hexchar>
<quoted-pair> ::= " <asymsignmic> ::= <RSAsignmic>
<RSAsignmic> ::= <encbin>
<linear-white-space> ::= 1*( [ CRLF ] <LWSP-char> ) ; semantics = SPACE <asymencdek> ::= <RSAencdek>
; CRLF => folding <RSAencdek> ::= <encbin>
<LWSP-char> ::= SPACE / HTAB ; semantics = SPACE
<atom> ::= 1*(any <CHAR> except <specials>, SPACE and <CTL>s) The following productions are taken from [1]. The grammar presented
in [1] remains the authoritative source for these productions; they
are repeated here for the convenience of the reader.
<CHAR> ::= <any ASCII character> <route-addr> ::= "<" [ <route> ] <addr-spec> ">"
<CTL> ::= <any ASCII control character and DEL> <route> ::= 1# ( "@" <domain> ) ":" ; path-relative
<specials> ::= "(" / ")" / "<" / ">" / "@" ; Must be in quoted- <addr-spec> ::= <local-part> "@" <domain>; global address
/ "," / ";" / ":" / "
/ "." / "[" / "]" ; within a word.
Table of Contents <local-part> ::= <word> *( "." <word> ) ; uninterpreted
; case-preserved
Status of this Memo ............................................. 1 <domain> ::= <sub-domain> *( "." <sub-domain> )
Abstract ........................................................ 1
1 Introduction ................................................... 2 <sub-domain> ::= <domain-ref> / <domain-literal>
2 Name Forms and Identifiers ..................................... 4
2.1 Name Forms ................................................... 4 <domain-ref> ::= <atom> ; symbolic
2.1.1 Email Addresses ............................................ 5 ; reference
2.1.2 Arbitrary Strings .......................................... 5
2.1.3 Distinguished Names ........................................ 5 <domain-literal>::= "[" *( <dtext> / <quoted-pair> ) "]"
2.2 Identifiers .................................................. 6 <dtext> ::= <any CHAR excluding "[", "]",
2.2.1 Email Address .............................................. 7 "\" & <CR>, & including
2.2.2 Arbitrary String ........................................... 7 linear-white-space>
2.2.3 Distinguished Name ......................................... 7 ; => may be folded
2.2.4 Public Key ................................................. 7
2.2.5 Issuer Name and Serial Number .............................. 8 <word> ::= <atom> / <quoted-string>
3 Applying PEM Security Services to MIME Body Parts .............. 8
3.1 PEM Processing Steps ......................................... 9 <quoted-string> ::= """ *( <qtext> / <quoted-pair> ) """
3.2 Use of multipart/signed Content Type ......................... 11
3.3 Use of multipart/encrypted Content Type ...................... 12 <qtext> ::= (any <CHAR> excepting """, "\", and CR,
3.4 application/pem-signature Content Type Definition ............ 12 and including <linear-white-space>)
3.5 application/pem-keys Content Type Definition ................. 13
4 Removing PEM Security Services from PEM Body Parts ............. 14 <quoted-pair> ::= "\" <CHAR> ; may quote any
5 Key Management Content Types ................................... 15 ; char
5.1 application/pemkey-request Content Type Definition ........... 15
5.2 application/pemkey-data Content Type Definition .............. 17 <linear-white-space> ::= 1*( [ CRLF ] <LWSP-char> )
6 Examples ....................................................... 19 ; semantics = SPACE
7 Observations ................................................... 24 ; CRLF => folding
8 Summary of Changes to PEM Specification ........................ 25
9 Collected Grammar .............................................. 27 <LWSP-char> ::= SPACE / HTAB ; semantics = SPACE
10 Security Considerations ....................................... 29
11 Acknowledgements .............................................. 29 <atom> ::= 1*(any <CHAR>
12 References .................................................... 29 except <specials>, SPACE and <CTL>s)
13 Authors' Addresses ............................................ 30
14 Appendix: Imported Grammar .................................... 32 <CHAR> ::= <any ASCII character>
<CTL> ::= <any ASCII control character and DEL>
<specials> ::= "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "." / "[" / "]"
; Must be in quoted-
; string, to use
; within a word.
<ALPHA> ::= <any ASCII alphabetic character>
; (101-132, 65.-90.)
; (141-172, 97.-122.)
<DIGIT> ::= <any ASCII decimal digit>; (60-71, 48.-57.)
 End of changes. 357 change blocks. 
996 lines changed or deleted 1692 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/