As per Relevance of the word services, we have this rfc below:
Network Working Group S.
Request For Comments: 1848 CyberCash, Inc
Category: Standards Track N.
Innosoft International, Inc
J.
S.
Trusted Information
October 1995
MIME Object Security
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document defines MIME Object Security Services (MOSS),
protocol that uses the multipart/signed and multipart/
framework [7] to apply digital signature and encryption services
MIME objects. The services are offered through the use of end-to-
cryptography between an originator and a recipient at the
layer. Asymmetric (public key) cryptography is used in support
the digital signature service and encryption key management
Symmetric (secret key) cryptography is used in support of
encryption service. The procedures are intended to be
with a wide range of public key management approaches, including
ad hoc and certificate-based schemes. Mechanisms are provided
support many public key management approaches
Table of
1. Introduction ............................................. 3
2. Applying MIME Object Security Services ................... 4
2.1 Digital Signature Service ............................... 4
2.1.1 Canonicalization ...................................... 5
2.1.2 Digital Signature Control Information ................. 7
2.1.2.1 Version: ............................................ 8
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
Crocker, et al Standards Track [Page 1]
RFC 1848 MIME Object Security Services October 1995
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
Crocker, et al Standards Track [Page 2]
RFC 1848 MIME Object Security Services October 1995
1.
MIME [2], an acronym for "Multipurpose Internet Mail Extensions",
defines the format of the contents of Internet mail messages
provides for multi-part textual and non-textual message bodies.
Internet electronic mail message consists of two parts: the
and the body. The headers form a collection of field/value
structured according to STD 11, RFC 822 [1], whilst the body,
structured, is defined according to MIME. MIME does not provide
the application of security services
PEM [3-6], an acronym for "Privacy Enhanced Mail", defines
encryption and message authentication procedures for text-
electronic mail messages using a certificate-based key
mechanism. The specifications include several features that
easily and more naturally supported by MIME, for example,
transfer encoding operation, the Content-Domain header, and
support services specified by its Part IV [6]. The specification
limited by specifying the application of security services to
messages only
MOSS is based in large part on the PEM protocol as defined by
1421. Many of PEMs features and most of its protocol
are included here. A comparison of MOSS and PEM may be found
Section 8.
In order to make use of the MOSS services, a user (where user is
limited to being a human, e.g., it could be a process or a role)
required to have at least one public/private key pair. The
key must be made available to other users with whom
communication is desired. The private key must not be disclosed
any other user
An originator's private key is used to digitally sign MIME objects;
recipient would use the originator's public key to verify the
signature. A recipient's public key is used to encrypt the
encrypting key that is used to encrypt the MIME object; a
would use the corresponding private key to decrypt the
encrypting key so that the MIME object can be decrypted
As long as the private keys are protected from disclosure, i.e.,
private keys are accessible only to the user to whom they have
assigned, the recipient of a digitally signed message will know
whom the message was sent and the originator of an encrypted
will know that only the intended recipient is able to read it.
assurance, the ownership of the public keys used in verifying
signatures and encrypting messages should be verified. A
public key should be protected from modification
Crocker, et al Standards Track [Page 3]
RFC 1848 MIME Object Security Services October 1995
The framework defined in [7] provides an embodiment of a MIME
and its digital signature or encryption keys. When used by MOSS
framework provides digital signature and encryption services
single and multi-part textual and non-textual MIME objects
2. Applying MIME Object Security
The application of the MOSS digital signature service requires
following components
(1) The data to be signed
(2) The private key of the originator
The data to be signed is prepared according to the description below
The digital signature is created by generating a hash of the data
encrypting the hash value with the private key of the originator
The digital signature, some additional ancillary
described below, and the data are then embodied in a multipart/
body part. Finally, the multipart/signed body part may
transferred to a recipient or processed further, for example, it
be encrypted
The application of the MOSS encryption service requires the
components
(1) The data to be encrypted
(2) A data encrypting key to encrypt the data
(3) The public key of the recipient
The data to be encrypted is prepared according to the
below. The originator creates a data encrypting key and encrypts
data. The recipient's public key is used to encrypt the
encrypting key. The encrypted data, the encrypted data
key, and some additional ancillary information described below
then embodied in a multipart/encrypted body part, ready to
transferred to a recipient or processed further, for example, it
be signed
The next two sections describe the digital signature and
services, respectively, in detail
2.1. Digital Signature
The MOSS digital signature service is applied to MIME objects
specifically a MIME body part. The MIME body part is
Crocker, et al Standards Track [Page 4]
RFC 1848 MIME Object Security Services October 1995
according to a local convention and then made available to
digital signature service
The following sequence of steps comprises the application of
digital signature service
(1) The body part to be signed must be canonicalized
(2) The digital signature and other control information must be gen
erated
(3) The control information must be embodied in an appropriate
content type
(4) The control information body part and the data body part must
embodied in a multipart/signed content type
Each of these steps is described below
2.1.1.
The body part must be converted to a canonical form that is
and unambiguously representable in at least the environment where
digital signature is created and the environment where the
signature will be verified, i.e., the originator and recipient'
environment, respectively. This is required in order to ensure
both the originator and recipient have the same data with which
calculate the digital signature; the originator needs to be able
create the digital signature value while the recipient needs to
able to compare a re-computed value with the received value. If
canonical form is representable on many different host computers,
signed data may be forwarded by recipients to additional recipients
who will also be able to verify the original signature. This
is called forwardable authentication
The canonicalization transformation is a two step process. First
the body part must be converted to a form that is
representable on as many different host computers as possible
Second, the body part must have its line delimiters converted to
unique and unambiguous representation
The representation chosen to satisfy the first step is 7bit,
defined by MIME; the high order bit of each octet of the data to
Crocker, et al Standards Track [Page 5]
RFC 1848 MIME Object Security Services October 1995
signed must be zero. A MIME body part is comprised of two parts
headers and content. Since the headers of body parts are
required to be represented in 7bit, this step does not
changes to the headers. This step requires that if the content
not already 7bit then it must be encoded with an appropriate
content transfer encoding and a Content-Transfer-Encoding:
must be added to the headers. For example, if the content to
signed contains 8bit or binary data, the content must be encoded
either the quoted-printable or base64 encoding as defined by MIME
IMPLEMENTORS NOTE: Since the MIME standard explicitly
nested content transfer encodings, i.e., the content
multipart and message may not themselves be encoded, the 7
transformation requires each nested body part to be
encoded in a 7bit representation. Any valid MIME encoding, e.g.,
quoted-printable or base64, may be used and, in fact, a
encoding may be used on each of the non-7bit body parts
Representing all content types in a 7bit format transforms them
text-based content types. However, text-based content types
a unique problem. In particular, the line delimiter used for
text-based content type is specific to a local environment;
environments use the single character carriage-return (),
single character line-feed (), or the two character
"carriage-return line-feed ()".
The application of the digital signature service requires that
same line delimiter be used by both the originator and the recipient
This document specifies that the two character sequence ""
must be used as the line delimiter. Thus, the second step of
canonicalization transformation includes the conversion of the
line delimiter to the two character sequence "".
The conversion to the canonical line delimiter is only required
the purposes of computing the digital signature. Thus,
must apply the line delimiter conversion before computing the
signature but must transfer the data without the line
conversion. Similarly, recipients must apply the line
conversion before computing the digital signature
NOTE: An originator can not transfer the content with the
delimiter conversion intact because the conversion process is
idempotent. In particular, SMTP servers may themselves
the line delimiter to a local line delimiter, prior to the
being delivered to the recipient. Thus, a recipient has no way
knowing if the conversion is present or not. If the
applies the conversion to a content in which it is
present, the resulting content may have two line
Crocker, et al Standards Track [Page 6]
RFC 1848 MIME Object Security Services October 1995
present, which would cause the verification of the signature
fail
IMPLEMENTORS NOTE: Implementors should be aware that
conversion to a 7bit representation is a function that is
in a minimally compliant MIME user agent. Further, the
delimiter conversion required here is distinct from the
conversion included in that function. Specifically, the
delimiter conversion applied when a body part is converted to
7bit representation (transfer encoded) is performed prior to
application of the transfer encoding. The line
conversion applied when a body part is signed is performed
the body part is converted to 7bit (transfer encoded). Both
delimiter conversions are required
2.1.2. Digital Signature Control
The application of the digital signature service generates
information which includes the digital signature itself. The
of the control information is that of a set of RFC 822 headers
except that the folding of header values onto continuation lines
explicitly forbidden. Each header and value pair generated by
digital signature service must be output on exactly one line
The complete set of headers generated by the digital
service is as follows
Version
indicates which version of the MOSS protocol the remaining
represent
Originator-ID
indicates the private key used to create the digital signature
the corresponding public key to be used to verify it
MIC-Info
contains the digital signature value
Each invocation of the digital signature service must emit
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
in the order indicated. This specification allows an originator
generate multiple signatures of the data, presumably with
signature algorithms, and to include them all in the
information. The interpretation of the presence of
signatures is outside the scope of this specification except that
MIC-Info: header is always interpreted in the context of
Crocker, et al Standards Track [Page 7]
RFC 1848 MIME Object Security Services October 1995
immediately preceding Originator-ID: header
2.1.2.1. Version
The version header is defined by the grammar token
follows
::= "Version:" "5"
Its value is constant and MOSS implementations compliant with
specification must recognize only this value and generate an error
any other value is found
2.1.2.2. Originator-ID
The purpose of the originator header is two-fold: to
identify the public key to be used to verify the digital
and to indirectly identify the user who owns both it and
corresponding private key. Typically, a recipient is less
in the actual public key value, although obviously the
needs the value to verify the signature, and more interested
identifying its owner. Thus, the originator header may convey
or both pieces of information
the public key to be used to verify the
the name of the owner and which of the owner's public keys to
to verify the
The decision as to what information to place in the value
entirely with the originator. The suggested value is to
both. Recipients with whom the originator has
communicated will have to verify that the information presented
consistent with what is already known. New recipients will want
of the information, which they will need to verify prior to
in their local database
The originator header is defined by the grammar token
follows
::= "Originator-ID:"
The grammar token is defined in Section 4.
2.1.2.3. MIC-Info
The purpose of the Message Integrity Check (MIC) header is to
the digital signature value. Its value is a comma separated list
Crocker, et al Standards Track [Page 8]
RFC 1848 MIME Object Security Services October 1995
three arguments: the hash (or MIC) algorithm identifier,
signature algorithm identifier, and the digital signature
The MIC header is defined by the grammar token as follows
::= "MIC-Info:" "," ","
The grammar tokens for the MIC algorithms and
(), signature algorithms and identifiers (),
signed MIC formats () are defined by RFC 1423. They
also reprinted in Appendix B
IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol
which includes support for symmetric signatures and
management. As a result, some of the grammar tokens
there, for example, , will include options that are
legal for this protocol. These options must be ignored and
not been included in the appendix
2.1.3. application/moss-signature Content Type
(1) MIME type name:
(2) MIME subtype name: moss-
(3) Required parameters:
(4) Optional parameters:
(5) Encoding considerations: quoted-printable is always
(6) Security considerations:
The "application/moss-signature" content type is used on the
body part of an enclosing multipart/signed. Its content is
of the digital signature of the data in the first body part of
enclosing multipart/signed and other control information required
verify that signature, as defined by Section 2.1.2. The
"application/moss-signature" must be used as the value of
protocol parameter of the enclosing multipart/signed; the
parameter must be present
Part of the signature verification information will be the
Integrity Check (MIC) algorithm(s) used during the signature
process. The MIC algorithm(s) identified in this body part
match the MIC algorithm(s) identified in the micalg parameter of
enclosing multipart/signed. If it does (they do) not, a user
Crocker, et al Standards Track [Page 9]
RFC 1848 MIME Object Security Services October 1995
should identify the discrepancy to a user and it may choose to
halt or continue processing, giving precedence to the algorithm(s
identified in this body part
An application/moss-signature body part is constructed as follows
Content-Type: application/moss-
where the grammar token is defined as follows
::= ( 1* )
::= "Version:" "5"
::=
::= "Originator-ID:"
::= "MIC-Info:" "," ","
The token is defined in Section 4. All other tokens are
in Section 2.1.2.3.
2.1.4. Use of multipart/signed Content
The definition of the multipart/signed content type in [7]
three steps for creating the body part
(1) The body part to be digitally signed is created according to
local convention, for example, with a text editor or a mail
agent
(2) The body part is prepared for the digital signature
according to the protocol parameter, in this case according
Section 2.1.1.
(3) The prepared body part is digitally signed according to
protocol parameter, in this case according to Section 2.1.2.
The multipart/signed content type is constructed as follows
Crocker, et al Standards Track [Page 10]
RFC 1848 MIME Object Security Services October 1995
(1) The value of its required parameter "protocol" is set
"application/moss-signature".
(2) The signed body part becomes its first body part
(3) Its second body part is labeled "application/moss-signature"
is filled with the control information generated by the
signature service
(4) The value of its required parameter "micalg" is set to the
value used in the MIC-Info: header in the control information
If there is more than one MIC-Info: header present the value
set to a comma separated list of values from the MIC-
headers. The interpretation of the order of the list of
is outside the scope of this specification
A multipart/signed content type with the MOSS protocol might look
follows
Content-Type: multipart/signed
protocol="application/moss-signature";
micalg="rsa-md5"; boundary="Signed Message
--Signed
Content-Type: text/
This is some example text
--Signed
Content-Type: application/moss-
Version: 5
Originator-ID: ID-
MIC-Info: RSA-MD5,RSA,SIGNATURE-
--Signed Message--
where ID-INFORMATION and SIGNATURE-INFORMATION are descriptive of
content that would appear in a real body part
2.2. Encryption
The MOSS encryption service is applied to MIME objects,
a MIME body part. The MIME body part is created according to a
convention and then made available to the encryption service
Crocker, et al Standards Track [Page 11]
RFC 1848 MIME Object Security Services October 1995
The following sequence of steps comprises the application of
encryption service
(1) The body part to be encrypted must be in MIME canonical form
(2) The data encrypting key and other control information must
generated
(3) The control information must be embodied in an appropriate
content type
(4) The control information body part and the encrypted data
part must be embodied in a multipart/encrypted content type
The first step is defined by MIME. The latter three steps
described below
2.2.1. Encryption Control
The application of the encryption service generates
information which includes the data encrypting key used to
the data itself. The syntax of the control information is that of
set of RFC 822 headers, except that the folding of header values
continuation lines is explicitly forbidden. Each header and
pair generated by the encryption service must be output on
one line
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
the specification, although Section 5 defines one possible mechanism
With the public key, the originator encrypts the data encrypting
according to the Key-Info: header defined below. The complete set
headers generated by the encryption service is as follows
Version
indicates which version of the MOSS protocol the remaining
represent and is defined in Section 2.1.2.1.
DEK-Info
indicates the algorithm and mode used to encrypt the data
Crocker, et al Standards Track [Page 12]
RFC 1848 MIME Object Security Services October 1995
Recipient-ID
indicates the public key used to encrypt the data encrypting
that was used to encrypt the data
Key-Info
contains data encrypting key encrypted with the recipient's
key
Each invocation of the encryption service must emit exactly
Version: header, exactly one DEK-Info: header, and at least one
of Recipient-ID: and Key-Info: headers. Headers are always
in the order indicated. The Recipient-ID: and Key-Info: headers
always emitted in pairs in the order indicated, one pair for
recipient of the encrypted data. A Key-Info: header is
interpreted in the context of the immediately preceding Recipient-ID
header
IMPLEMENTORS NOTE: Implementors should always generate
Recipient-ID: and Key-Info header pair representing the
of the encrypted data. By doing so, if an originator sends
message to a recipient that is returned undelivered,
originator will be able to decrypt the message and determine
appropriate course of action based on its content. If not,
originator will not be able to review the message that was sent
2.2.1.1. DEK-Info
The purpose of the data encrypting key information header is
indicate the algorithm and mode used to encrypt the data, along
any cryptographic parameters that may be required, e.g.,
initialization vectors. Its value is either a single
indicating the algorithm and mode or a comma separated pair
arguments where the second argument carries any
parameters required by the algorithm and mode indicated in the
argument
The data encrypting key information header is defined by the
token as follows
::= "DEK-Info" ":"
[ "," ]
The grammar tokens for the encryption algorithm and mode
() and the optional cryptographic
() are defined by RFC 1423. They are also
in Appendix B
Crocker, et al Standards Track [Page 13]
RFC 1848 MIME Object Security Services October 1995
2.2.1.2. Recipient-ID
The purpose of the recipient header is to identify the private
that must be used to decrypt the data encrypting key that will
used to decrypt the data. Presumably the recipient owns the
key and thus is less interested in identifying the owner of the
and more interested in the private key value itself. Nonetheless
the recipient header may convey either or both pieces of information
the public key corresponding to the private key to be used
decrypt the data encrypting
the name of the owner and which of the owner's private keys to
to decrypt the data encrypting
The decision as to what information to place in the value
entirely with the originator. The suggested choice is to
just the public key. However, some recipients may prefer
originators not include their public key. How this preference
conveyed to and managed by the originator is outside the scope
this specification
The recipient header is defined by the grammar token
follows
::= "Recipient-ID:"
The grammar token is defined in Section 4.
2.2.1.3. Key-Info
The purpose of the key information header is to convey the
data encrypting key. Its value is a comma separated list of
arguments: the algorithm and mode identifier in which the
encrypting key is encrypted and the encrypted data encrypting key
The key information header is defined by the grammar
as follows
::= "Key-Info" ":" ","
The grammar tokens for the encryption algorithm and mode
() and the encrypted data encrypting key
() are defined by RFC 1423. They are also reprinted
Appendix B
IMPLEMENTORS NOTE: RFC 1423 is referenced by the PEM protocol
which includes support for symmetric signatures and
Crocker, et al Standards Track [Page 14]
RFC 1848 MIME Object Security Services October 1995
management. As a result, some of the grammar tokens
there, for example, , will include options that are
legal for this protocol. These options must be ignored and
not been included in the appendix
2.2.2. application/moss-keys Content Type
(1) MIME type name:
(2) MIME subtype name: moss-
(3) Required parameters:
(4) Optional parameters:
(5) Encoding considerations: quoted-printable is always
(6) Security considerations:
The "application/moss-keys" content type is used on the first
part of an enclosing multipart/encrypted. Its content is
of the data encryption key used to encrypt the data in the
body part and other control information required to decrypt the data
as defined by Section 2.2.1. The label "application/moss-keys"
be used as the value of the protocol parameter of the
multipart/encrypted; the protocol parameter must be present
An application/moss-keys body part is constructed as follows
Content-Type: application/moss-
where the token is defined as follows
::= 1*
::= "Version:" "5"
::= "DEK-Info" ":"
[ "," ]
::=
::= "Recipient-ID:"
::= "Key-Info" ":" ","
Crocker, et al Standards Track [Page 15]
RFC 1848 MIME Object Security Services October 1995
The token is defined in Section 4. The token
defined in Section 2.1.2.1. All other tokens are defined in
2.2.1.3.
2.2.3. Use of multipart/encrypted Content
The definition of the multipart/encrypted body part in [7]
three steps for creating the body part
(1) The body part to be encrypted is created according to a
convention, for example, with a text editor or a mail
agent
(2) The body part is prepared for encryption according to
protocol parameter, in this case the body part must be in
canonical form
(3) The prepared body part is encrypted according to the
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
"application/moss-keys".
(2) The first body part is labeled "application/moss-keys" and
filled with the control information generated by the
service
(3) The encrypted body part becomes the content of its second
part, which is labeled "application/octet-stream".
A multipart/encrypted content type with the MOSS protocol might
as follows
Crocker, et al Standards Track [Page 16]
RFC 1848 MIME Object Security Services October 1995
Content-Type: multipart/encrypted
protocol="application/moss-keys";
boundary="Encrypted Message
--Encrypted
Content-Type: application/moss-
Version: 5
DEK-Info: DES-CBC,DEK-
Recipient-ID: ID-
Key-Info: RSA,KEY-
--Encrypted
Content-Type: application/octet-
ENCRYPTED-
--Encrypted Message--
where DEK-INFORMATION, ID-INFORMATION, and KEY-INFORMATION
descriptive of the content that would appear in a real body part
3. Removing MIME Object Security
The verification of the MOSS digital signature service requires
following components
(1) A recipient to verify the digital signature
(2) A multipart/signed body part with two body parts: the
data and the control information
(3) The public key of the originator
The signed data and control information of the
multipart/signed are prepared according to the description below
The digital signature is verified by re-computing the hash of
data, decrypting the hash value in the control information with
originator's public key, and comparing the two hash values. If
two hash values are equal, the signature is valid
The decryption of the MOSS encryption service requires the
components
Crocker, et al Standards Track [Page 17]
RFC 1848 MIME Object Security Services October 1995
(1) A recipient to decrypt the data
(2) A multipart/encrypted body part with two body parts:
encrypted data and the control information
(3) The private key of the recipient
The encrypted data and control information of the
multipart/encrypted are prepared according to the description below
The data encrypting key is decrypted with the recipient's private
and used to decrypt the data
The next two sections describe the digital signature and
services in detail, respectively
3.1. Digital Signature
This section describes the processing steps necessary to verify
MOSS digital signature service. The definition of
multipart/signed body part in [7] specifies three steps for
it
(1) The digitally signed body part and the control information
part are prepared for processing
(2) The prepared body parts are made available to the
signature verification process
(3) The results of the digital signature verification process
made available to the user and processing continues with
digitally signed body part, as returned by the digital
verification process
Each of these steps is described below
3.1.1.
The digitally signed body part (the data) and the control
body part are separated from the enclosing multipart/signed
part
Crocker, et al Standards Track [Page 18]
RFC 1848 MIME Object Security Services October 1995
The control information is prepared by removing any content
encodings that may be present
The digitally signed body part is prepared by leaving the
transfer encodings intact and canonicalizing the line
according to Step 2 of Section 2.1.1.
3.1.2.
First, the recipient must obtain the public key of the originator
The public key may be contained in the control information or it
be necessary for the recipient to retrieve the public key based
information present in the control information. The retrieval may
from a local database or from a remote service. The acquisition
the originator's public key is outside the scope of
specification, although Section 5 defines one possible mechanism
With the public key, the recipient decrypts the hash value
in the control information. Then, a new hash value is computed
the body part purported to have been digitally signed
Finally, the two hash values are compared to determine the
of the digital signature
3.1.3.
There are two required components of the results of the
process. The first is an indication as to whether a public key
be found that allows the hash values in the previous step to
equal. Such an indication verifies only that the data received
the same data that was digitally signed
The second indication identifies the owner of the public key who
presumably the holder of the private key that created the
signature. The indication must include a testament as to
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
signed the message, the binding between the owner's name and
public key must have been verified by the recipient prior to
verification of the digital signature. The verification of
binding may have been completed offline and stored in a trusted
local database or, if the owner's name and public key are embodied
a certificate, it may be possible to complete it in realtime.
Section 5 for more information
Crocker, et al Standards Track [Page 19]
RFC 1848 MIME Object Security Services October 1995
3.2. Encryption
This section describes the processing steps necessary to decrypt
MOSS encryption service. The definition of the multipart/
body part in [7] specifies three steps for receiving it
(1) The encrypted body part and the control information body
are prepared for processing
(2) The prepared body parts are made available to the
process
(3) The results of the decryption process are made available to
user and processing continues with the decrypted body part,
returned by the decryption process
Each of these steps is described below
3.2.1.
The encrypted body part (the data) and the control information
part are separated from the enclosing multipart/encrypted body part
The body parts are prepared for the decryption process by
any content transfer encodings that may be present
3.2.2.
First, the recipient must locate the encrypted data encrypting key
the control information. Each Recipient-ID: header is checked
order to see if it identifies the recipient or a public key of
recipient
If it does, the immediately following Key-Info: header will
the data encrypting key encrypted with the public key of
recipient. The recipient must use the corresponding private key
decrypt the data encrypting key
The data is decrypted with the data encrypting key. The
data will be a MIME object, a body part, ready to be processed by
MIME agent
Crocker, et al Standards Track [Page 20]
RFC 1848 MIME Object Security Services October 1995
3.2.3.
If the recipient is able to locate and decrypt a data encrypting key
from the point of view of MOSS the decryption should be
successful. An indication of the owner of the private key used
decrypt the data encrypting key must be made available to the user
Ultimately, the success of the decryption is dependent on the
of a MIME agent to continue processing with the decrypted body part
4. Identifying Originators, Recipients, and Their
In the PEM specifications, public keys are required to be embodied
certificates, an object that binds each public key with
distinguished name. A distinguished name is a name form
identifies the owner of the public key. The embodiment is issued
a certification authority, a role that is expected to be
insofar as the certification authority would have procedures
verify the identity of the owner prior to issuing the certificate
In MOSS, a user is not required to have a certificate. The
services require that the user have at least one public/private
pair. The MOSS protocol requires the digital signature
encryption services to emit Originator-ID: and Recipient-ID: headers
as appropriate. In the discussion above the actual value of
headers was omitted, having been relegated to this section.
the value of each of these headers serves a distinct purpose,
simplicity the single grammar token represents the value
may be assigned to either header
One possible value for the Originator-ID: and Recipient-ID:
is the public key values themselves. However, while it is true
the public keys alone could be exchanged and used by users
communicate, the values are, in fact, large and cumbersome.
addition, public keys would appear as a random sequence of
and, as a result, would not be immediately consumable by human users
NOTE: It should be pointed out that a feature of being able
specify the public key explicitly is that it allows users
exchange encrypted, anonymous mail. In particular,
users will always know a message comes from the same
user even if the real identity of the originating user is unknown
Recognizing that the use of public keys is, in general,
for use by humans, MOSS allows other identifiers in Originator-ID
and Recipient-ID: headers. These other identifiers are comprised
two parts: a name form and a key selector
Crocker, et al Standards Track [Page 21]
RFC 1848 MIME Object Security Services October 1995
The name form is chosen and asserted by the user who owns
public/private key pair. Three name forms are specified by
document. The use of a distinguished name is retained
compatibility with PEM (and compatibility with the X.500
should it become a ubiquitous service). However, the
community has a great deal of experience with the use of
mail addresses as a name form. Also, arbitrary strings are useful
identify the owners of public keys when private name forms are used
Hence, email addresses and arbitrary strings are included as
forms to increase flexibility
Since a user may have more than one public key and may wish to
the same name form for each public key, a name form is
for uniquely identifying a public key. A unique "key selector"
be assigned to each public key. The combination of a name form
the key selector uniquely identifies a public key. Throughout
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
owners of the public/private key pairs. This works best
users generate their own key pairs for personal use, from
they distribute their public key to others asserting
declaration that the public key belongs to them. When
assertion that the public key belongs to them is made by a
party, for example when a certification authority issues
certificate to a user according to [4], the key selector may
assigned by that third party
The value of the key selector must be unique with respect to the
form with which it forms an identifier. Although the same
selector value may be used by more than one name form it must not
used for two different keys with the same name form. When
separately, neither a name form nor a key selector is sufficient
identifying the public key to be used. Either could be used
determine a set of public keys that may be tried in turn until
desired public key is identified
With a public/private key pair for one's self and software that
MOSS aware, an originating user may digitally sign arbitrary data
send it to one or more recipients. With the public keys of
recipients, a user may encrypt the data so that only the
recipients can decrypt and read it. With the name forms assigned
the public keys, originators and recipients can easily
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
Crocker, et al Standards Track [Page 22]
RFC 1848 MIME Object Security Services October 1995
4.1. Name
There are 3 name forms specified by this document: email addresses
distinguished names, and arbitrary strings
4.1.1. Email
The email address (grammar token ) used must be a
RFC822 address, which is defined in terms of one of the two
tokens or . The grammar for these two
is included in the Appendix as a convenience; the definitive
for these tokens is necessarily RFC822 [1].
::= /
; an electronic mail address as defined
; 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
The arbitrary string (grammar token ) must have a length
at least 1. There are no other restrictions on the value chosen
::= ; a non-null sequence of
For example, the
the SAAG mailing list
is an arbitrary string
4.1.3. Distinguished
The distinguished name (grammar token ) must be
according to the guidelines of the X.500 Directory. The
syntax of the distinguished name is outside the scope of
specification. However, RFC1422, for example, specifies
restrictions based on its choice of a certification hierarchy
certificates
For the purposes of conveying a distinguished name from an
to a recipient, it must be ASN.1 encoded and then printably
according to the base64 encoding defined by MIME
Crocker, et al Standards Track [Page 23]
RFC 1848 MIME Object Security Services October 1995
::=
; a printably encoded, ASN.1
; distinguished name (as defined by the 'Name
; production specified in X.501 [8])
For example
/Country Name=
/State or Province Name=
/Organization Name=Trusted Information
/Organizational Unit Name=
/Common Name=James M. Galvin
is a distinguished name in a user friendly format (line breaks
leading spaces present only to improve readability). When encoded
it would appear as follows (line breaks present only to
readability):
MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1
SmFtZXMgTS4gR2
4.2.
There are 5 types of identifiers specified by this document
email address
arbitrary string
distinguished name
the public keys
issuer name serial number pairs from a
All of these have approximately the same structure (except
name and serial number which has 'TYPE, STRING, KEYSEL'
historical reasons):
TYPE, KEYSEL,
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
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
Crocker, et al Standards Track [Page 24]
RFC 1848 MIME Object Security Services October 1995
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
according to the value of the TYPE field
The identifier used in each of the originator and recipient fields
described by the following grammar. The definition of the
selector token is included here since it used by several of
identifiers below
::= / /
/ /
::= 1*
; hex dump of a non-null sequence of
Each of the identifier name forms is described below
4.2.1. Email
The email address identifier has the following syntax
::= "EN" "," ","
The syntax of the token is defined in Section 4.1.1.
For example
EN,1,galvin@tis.
is an email address identifier
4.2.2. Arbitrary
The arbitrary string identifier has the following syntax
::= "STR" "," ","
The syntax of the token is defined in Section 4.1.2.
For example
STR,1,The SAAG mailing list
is an arbitrary string identifier
Crocker, et al Standards Track [Page 25]
RFC 1848 MIME Object Security Services October 1995
4.2.3. Distinguished
The distinguished name identifier has the following syntax
::= "DN" "," ","
The syntax of the token is defined in Section 4.1.3.
For example (line breaks present only to improve readability):
DN,1,MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3
lZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1
EAxMPSmFtZXMgTS4gR2
is a distinguished name identifier
4.2.4. Public
The public key identifier has the following syntax
::= "PK" "," [ "," ]
::=
; a printably encoded, ASN.1 encoded
; key (as defined by
; 'SubjectPublicKeyInfo' production
; in X.509 [9])
::= / /
The production SubjectPublicKeyInfo is imported from the X.500
Directory from the certificate object. It is currently the
choice for a general purpose public key encoding
For example, (line breaks present only to improve readability):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3
is a public key identifier without the optional .
In normal usage, the token is expected to be present.
represents a mechanism by which an identifier (name form and
selector) can be associated with a public key. Recipients of
public key identifier must take care to verify the accuracy of
purported association. If they do not, it may be possible for
malicious originator to assert an identifier that accords
Crocker, et al Standards Track [Page 26]
RFC 1848 MIME Object Security Services October 1995
originator unauthorized privileges. See Section 5.2 for
details
For example, (line breaks present only to improve readability):
PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6
4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4
0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.
is a public key identifier with the optional .
4.2.5. Issuer Name and Serial
The issuer name and serial number identifier has the
syntax
::= "IS" "," ","
::= 1*
; hex dump of a certificate serial
The identifier is included for compatibility with
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
to this new form by prefixing the old value with "IS" (and
the field name of [3] with an appropriate new ID field name).
example, (line breaks present only to improve readability):
IS,MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02
is an issuer name and serial number identifier according to MOSS
MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c
RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA==,02
is an issuer name and serial number identifier according to PEM
5. Key Management Content
This document defines two key management content types: one
requesting cryptographic key material and one for
cryptographic key material. Since MOSS depends only on the
of public/private key pairs, these content types provide a means
conveying public keys and an assertion as to the identity of
owner. In addition, in order to be compatible with the certificate
Crocker, et al Standards Track [Page 27]
RFC 1848 MIME Object Security Services October 1995
base key management system proposed by RFC 1422, the content
may also be used to convey certificate and certificate
list material
The functions defined here are based on the exchange of body parts
In particular, a user would send a message containing at least
application/mosskey-request content, as defined below. In response
a user would expect to receive a message containing at least
application/mosskey-data content, as defined below. MIME provides
convenient framework for a user to send several request body
and to receive several data (response) body parts in one message
5.1. application/mosskey-request Content Type
(1) MIME type name:
(2) MIME subtype name: mosskey-
(3) Required parameters:
(4) Optional parameters:
(5) Encoding considerations: quoted-printable is always
(6) Security Considerations:
The content of this body part corresponds to the
production
::=
( / / <certification> )
::= "Version:" "5"
::= "Subject:"
::= "Issuer:"
<certification> ::= "Certification:"
A user would use this content type to specify needed
key information. The message containing this content type might
directed towards an automatic or manual responder, which may
mail-based, depending on the local implementation and environment
The application/mosskey-request content type is an independent
part because it is entirely independent of any other body part
Crocker, et al Standards Track [Page 28]
RFC 1848 MIME Object Security Services October 1995
If the application/mosskey-request content contains a Certification
field it requests certification of the self-signed certificate in
field value. If the content contains an Issuer: field it
the Certificate Revocation List (CRL) chain beginning with the CRL
the issuer identified in the field value. If the content contains
Subject: field it requests either the public key of the subject or
certificate chain beginning with the subject identified in the
value, or both if both exist
The Subject: and Issuer: fields each contain a value of type ,
which is defined in Section 4.
One possible response to receiving an application/mosskey-
body part is to construct and return an application/mosskey-data
part. When returning public keys, certificate chains,
certificate revocation list chains, if there exists more than one
several application/mosskey-data body parts are to be returned in
reply message, one for each
5.2. application/mosskey-data Content Type
The principal objective of this content type is to
cryptographic keying