Network Working Group                                       Steve Crocker
INTERNET DRAFT                                                  Ned Freed
draft-ietf-pem-mime-05.txt
draft-ietf-pem-mime-06.txt                                     Jim Galvin
                                                             Sandy Murphy
                     PEM Security Services and MIME

1.  Status of this Memo

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups.  Note that other groups may also distribute working
documents as Internet Drafts.

Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time.  It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as ``work in progress''.

To learn the current status of any Internet Draft, please check the
1id-abstracts.txt listing contained in one of the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), venera.isi.edu (US West
Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe).

2.  Abstract

This document specifies how the services of MIME and PEM can be used in
a complementary fashion.  MIME, an acronym for "Multipurpose Internet
Mail Extensions", defines the format of the contents of Internet mail
messages and provides for multi-part textual and non-textual message
bodies.  PEM, an acronym for "Privacy Enhanced Mail", provides message
authentication/integrity and message encryption services for Internet
mail messages.

An Internet electronic mail message consists of two parts: the headers
and the body.  The headers form a collection of field/value pairs
structured according to RFC 822 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
services to the contents of a textual electronic mail message but does
not provide message structuring or type labelling facilities.  This
document specifies how to use PEM with the multipart/signed and
multipart/encrypted MIME content types to provide
authentication/integrity and encryption services.  We refer to the
authentication/integrity service as a digital signature service.

This document specifies a number of changes to the message encryption
and signature procedures of PEM and broadens the name forms that may be
used to identify public keys.  Many of the changes represent a departure
in mechanism, not in effect.

3.  Introduction

This document updates the message encryption and signature procedures
defined by [3] and obsoletes the key certification and related services
defined by [6].  The changes to [3] include the separation of the
encryption and signature services, the removal of the limitation to
enhance only text-based messages, the removal of the transfer encoding
operation, the deprecation of the Content-Domain: and Proc-Type:
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 ??. 10.

In addition, this document proposes specifies three technical changes: in [3] changes to PEM:
symmetric key management is deprecated, also in [3] is deprecated, the canonicalization
operation in [3] is generalized, and in [4] the allowable name forms for the
subjects
identification of certificates public keys is broadened to include arbitrary strings
and email addresses, and users may distribute their public keys directly
in lieu of certificates.

The key certification and related services document [6] is obsoleted by
the specification of two new MIME content types: application/key-request
and application/key-data.  These new content types are used to transmit
requests for key operations (retrieval, (storage, retrieval, certification,
revocation list retrieval, etc.)  and the responses to those requests.
These two content types are independent body parts and are not required
to be encapsulated in any other body part.  These changes represent a
departure in mechanism, not in effect, and are detailed in Section ??.

The relationship between MIME and PEM is described in terms 10.

In order to make use of two
functions: message composition and message delivery.

3.  Applying the PEM Security Services services, a user is required to MIME Body Parts

The next section describes have at
least one public/private key pair.  Prior to this specification, the processing steps necessary
public key was required to prepare be embodied in a
MIME body part for the application of PEM security services.  The
succeeding two sections describe certificate, an object that

binds a public key with a distinguished name, a name form that
identified the content owner 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 public key.  The following three steps describe the preparation of outbound PEM
messages.  These steps may embodiment was issued by a
certification authority, a role that was expected to be repeated trustworthy
insofar as necessary to prepare a message
for submission.

(1)  Local Form -- it verified the content identity of the message is prepared in the native
     format of owner prior to issuing the user's local environment

(2)  Canonical Form --
certificate.  However, the content deployment of certificates and the message is transformed to a
     canonical form for the digital signature service; no
     canonicalization is required for creation
of the encryption service

(3)  Security Form -- either hierarchy of certification authorities has been problematic.

Instead, this specification bases the signature or encryption PEM services may
     be applied on a public/private
key pair.  Each of these steps key pair is described in detail below.  Their relationship required to
message composition and delivery is described in Section ??.

3.1.1.  Step 1: Local Form

The message content belong to a user (where user is created in the native format of the user's local
environment.

3.1.2.  Step 2: Canonical Form

Prior
not limited to being a human, e.g., 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 application X.500 Directory becomes
a ubiquitous service) one of the digital signature service, the content
must be in a canonical form.  No canonicalization name forms is required for the
encryption service a distinguished name.  In
addition, email addresses and therefore processing continues with the next
step.

Transforming the content to be signed into arbitrary strings are allowed.

Since a canonical user may have more than one key pair, a name form is
insufficient for uniquely identifying a
necessary and essential step in the digital signature process. key pair.  The
canonical form owner of a key
pair must satisfy the property that it is assign a key identifier to each key pair.  The combination of
a name form and a key identifier uniquely identifies a key pair and
unambiguously representable on both the originator each
key pair is uniquely identified by a name form and recipient's local
environment.  This key identifier
combination.  Throughout this document, this combination is required in order to ensure called an
identifier.  There are 6 identifiers specified by this document.

With a key pair for one's self and software that is both the
originator MIME and recipient have the same PEM
aware, an originating user may digitally sign arbitrary data with which and send it
to calculate one or more recipients.  With the
digital signature; public keys of the originator needs to be able to include recipients, a
user may encrypt the
digital signature value when transferring data so that only the body part, while intended recipients can
decrypt and read the
recipient needs 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
section.  Succeeding sections specify how PEM and MIME are used together
and other ancillary details.

4.  Name Forms and Identifiers

Currently, [3] requires the use of certificates to be able identify the public
key (and corresponding private key) used to compare create a re-calculated value with PEM message.
Within certificates, [4] requires the
received value.  Further, use of distinguished names as
specified by the canonical form should satisfy X.500 Series of Recommendations.  However, the property
that it is representable on as many different host computers Internet
community has a great deal more experience with the use of electronic
mail addresses as
possible.  By satisfying this property, signed data may be forwarded by
recipients a name form and there is a desire to additional recipients, who will also be able to verify use
arbitrary strings to identify the
original signature.  This service is called forwardable authentication.

The canonical form owners of all content types public keys.  Hence, there
is defined a need to be 7bit.  The data support name forms which do not conform to be signed must be represented as 7bit.  Since the MIME standard
explicitly disallows nested encodings, the body parts enclosed in a
multipart content type, for example, must be encoded in a 7bit
representation.  Any valid MIME encoding may be selected.

The 7bit representation expected

usage of the data distinguished names.

When processing PEM messages it is transferred necessary to the recipient.  As
may be required by MIME, an appropriate Content-Transfer-Encoding:
header is included with able to uniquely
identify the data.  Upon receipt, a MIME implementation
would verify the signature of the data prior key pair used to decoding create the data message.  A certificate is
uniquely identified by the combination of its issuer's distinguished
name and
displaying it to its serial number.  Thus, the recipient.

Representing all complex content types as 7bit transforms them into
text-based content types.  However, text-based content types present issuer name and serial number
uniquely identifies a
unique problem.  In particular, there are far too many broken message
transfer agents key pair.  Since a user may have more than one key
pair, a name form is insufficient for this purpose.  An identifier is
required that make arbitrary changes to text-based messages as
they are relayed, including adding, deleting, or changing TAB and SPACE
characters, consists of both a name form and line delimiters are altered by message transfer agent
protocols.  These changes will make it impossible for recipients key identifier, a value
assigned to
verify the signature on a message.

The application of the digital signature service requires that the same
line delimiter be used key pair by both the originator and its owner.

In addition, users may distribute their public keys via mechanisms
outside the recipient.  This
document specifies that scope of the two character sequence "<CR><LF>" must PEM specification, for example, in a file via
FTP.  As a result, it is desirable to be
used as able to explicitly specify the line delimiter.  Thus,
public key used rather than an identifier of the canonicalization transformation public key.  A
significant benefit of this mechanism is to transform the local line delimiter ability to the two character sequence
"<CR><LF>". support
encrypted, anonymously signed mail.

The transformation to objective of the universal line delimiter various Originator and Recipient fields specified
in [3] is only required for to identify which public key has been used or is required.
This document simplifies the purposes set of computing the digital signature.  Thus, fields by specifying exactly two:
Originator-ID: for originators must
apply and Recipient-ID: for recipients.  This
specification defines six (6) identifiers with which the universal line delimiter transformation before calculating public key used
may be indicated in each of these fields.

In the
digital signature but must transfer next section the data without 3 name forms are described in detail.  Following
that is the universal line
delimiter transformation.  Similarly, recipients must apply specification of the
universal line delimiter transformation before calculating 6 identifiers.

4.1.  Name Forms

There are 3 name forms specified by this document: email address,
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 the digital
signature.

    NOTE: An originator can not transfer two grammar tokens <addr-spec>
and <route-addr>.  The grammar for these two tokens is included in the content with
Appendix as a convenience; the
    universal line delimiter transformation intact because definitive source for these tokens is
necessarily RFC822 [1].

    <emailstr>      ::= <addr-spec> / <route-addr>
                        ; an electronic mail address as defined by
                        ; these two tokens from RFC822

For example, the
    transformation process string "galvin@tis.com" is not idempotent.  In particular, SMTP
    servers may themselves convert an email address.

4.1.2.  Arbitrary Strings

The arbitrary string (grammar token <string>) must chosen from the universal line delimiter to us-
ascii character set and must have a
    local line delimiter, prior to the message being delivered length of at least 1.  It is
possible to encode the user.  Thus, actual string in such a recipient has no way of knowing if that only characters
from the
    transformation us-ascii character set are generated, but there is present or not.  Thus, if the no mechanism
for conveying to a recipient
    applies the transformation to encoding that was used.

    <string>        ::= ; a content in which it is already
    present, non-null sequence of us-ascii characters

For example, the resulting content may have two line delimiters
    present, which would cause string

    Jim "the SAAG mailing list maintainer" Galvin

is an arbitrary string.

4.1.3.  Distinguished Names

The distinguished name (grammar token <dname>) must be constructed
according to the verification guidelines of the signature to
    fail.

3.1.3.  Step 3: Security Form

Either of X.500 Directory.  For the digital signature or encryption services is applied to purposes of
conveying a
content.  The content distinguished name from an originator to be protected is prepared by a MIME
implementation recipient, it
must be ASN.1 encoded and made available to a PEM implementation then printably encoded according to the base64
encoding defined by MIME.

    <dnamestr>      ::= <encbin>
                        ; a
local convention.  The PEM implementation must produce two outputs: printably encoded, ASN.1 encoded
                        ; distinguished name

    ** EXAMPLE DISTINGUISHED NAME **

4.2.  Identifiers

There are 6 identifiers specified by this document: email address,
arbitrary string, distinguished name, PGP key identifier, the
data that has been protected public key
itself, and the control information necessary to
verify or remove the protection.  These outputs must be made available
to issuer name and serial number pair from a certificate.
All of these have approximately the MIME implementation which will construct same structure as follows:

    TYPE, KEYID, STRING

The TYPE field is a multipart/signed or
multipart/encrypted content, according to literal string, one for each of the service requested. possible
identifiers.

The
multipart content replaces KEYID field is used to distinguish between the content multiple public keys
that was selected for protection.

3.2.  Use may be associated with the name form in the STRING field.  In 3 of multipart/signed Content Type

When this content type is used,
the identifiers its value is arbitrary, chosen by the owner of the required parameter
"protocol" is "pem" and key
pair, except that it must be distinct from all the value other KEYIDs used by
the owner.  Suggested values include a portion (low-order 16 or 32 bits)
or all of the required parameter "hashalg" actual public key used.  In the other 3 identifiers the
value is
one still chosen by the owner of the valid choices public key and it must still
be unique, but its value is chosen from [5], for example:

    Content-Type: multipart/signed; protocol="pem"; hashalg="md5";
      boundary="Signed Message"

    --Signed Message
    Content-Type: text/plain

    This a more restricted alphabet.

The STRING field is some example text.

    --Signed Message
    Content-Type: application/signature

    <pemsig>
    --Signed Message--

where the <pemsig> 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
identifier token is defined as follows.

    <pemsig>             ::= <version> (1*<origasymflds>)

    <version> included here since it used by several of the
identifiers below.

    <id>            ::= "Version:" "5" CRLF

    <origasymflds> <nameid> / <id-publickey> / <id-issuer>

    <nameid>        ::= <origid> <micinfo>

    <origid> <id-email> / <id-string> / <id-dname> / <id-pgp>

    <keyid>         ::= "Originator-ID:" <id> CRLF

The token <id> is defined in Section ??.

The only valid value for <encbin>
                        ; a Content-Transfer-Encoding: header, if
included, is "7bit".

3.3.  Use printably encoded non-null sequence of multipart/encrypted Content Type

When this content type is used, the value octets

Each of the required parameter
"protocol" identifier name forms is "pem", for example:

    Content-Type: multipart/encrypted; protocol="pem";
      boundary="Encrypted Message"

    --Encrypted Message
    Content-Type: application/keys

    <pemkeys>

    --Encrypted Message
    Content-Type: application/octet-stream

    <encrypted data>
    --Encrypted Message--

where described below.

4.2.1.  Email Address

The email address identifier has the <pemkeys> token is defined as follows.

    <pemkeys>            ::= <version> <dekinfo> 1*<recipasymflds>

    <version> following syntax.

    <id-email>      ::= "Version:" "5" "EN"  "," <keyid> "," <emailstr> CRLF

    <recipasymflds>      ::= <recipid> <asymkeyinfo>

    <recipid>

4.2.2.  Arbitrary String

The arbitrary string identifier has the following syntax.

    <id-string>     ::= "Recipient-ID:" <id> "STR" "," <keyid> "," <string> CRLF

    <asymkeyinfo>

4.2.3.  Distinguished Name

The distinguished name identifier has the following syntax.

    <id-dname>      ::= "Key-Info" ":" <ikalgid> "DN"  "," <asymencdek> <keyid> "," <dnamestr> CRLF

The token <id> is defined in Section ??.

4.  Removing PEM Security Services from PEM Body Parts

Upon receipt actual form and syntax of a multipart/signed or multipart/encrypted body part, the
PEM security services are removed by reversing distinguished name is outside the sequence
scope of steps
specified in Section ??, modifying step 2 this specification.  RFC1422 specifies one possible form based
on a particular choice of a certification hierarchy for certificates.

4.2.4.  PGP Public Key

The PGP public key identifier has the following syntax.

    <id-pgp>        ::= "PGP2" ",0x" <pgp-keyid> "," <string> CRLF

    <pgp-keyid>     ::= ; a sequence from the following alphabet: {0-9, A-F}
                        ; which is either exactly six or eight characters long

4.2.5.  Public Key

The public key identifier has the following syntax.  This identifer, as follows.

(1)  All content types must have their line delimiters canonicalized
     prior
compared to removing the PEM security services.

(2)  Outer layers others, has the unique property that the STRING element
is optional and, when included, is not a string but rather one of PEM security services must be processed prior to
     processing inner layers four
of PEM security services.  Processing
     includes a user choosing to display the other identifiers.

    <id-publickey>  ::= "PK"  "," <publickey> [ "," <nameid> ] CRLF

    <publickey>     ::= <encbin>
                        ; a content without removing printably encoded, ASN.1 encoded
                        ; subjectPublicKeyInfo

In normal usage, the
     PEM security services.

5.  Definition of New Name Forms

    WARNING: This STRING element is the first draft of this section.  Although
    conceptually expected to be absent.  When
present, it represents a direction that will not change,
    while this document is mechanism by which an internet draft identifier (name form and
key identifier) can be associated with a public key.  Recipients of a
public key identifier must take care to verify the details accuracy of the
    specification are subject to change at any time, without notice,
    owing to comments and implementation experience.  Implementors
    are encouraged
purported association.  If not, it may be possible for a malicious
originator to contact assert an identifier that accords the authors originator
unauthorized privileges.  See Section 7.2 for more details.

The object subjectPublicKeyInfo is imported from the current status.

Currently, [3] requires X.500 Directory
from the use of certificates to specify certificate object.  It is currently the best choice for a

general purpose public key used to create a PEM message.  Within certificates, [4] requires encoding.

4.2.6.  Issuer Name and Serial Number

The issuer name and serial number identifier has the
use following syntax.

    <id-issuer>     ::= "IS"  "," <dnamestr>  "," <serial> CRLF

    <serial>        ::= 1*<hexchar>
                        ; hex dump of distinguished names as specified by the X.500 Series serial number of
Recommendations.  However, the Internet community has a great deal more
experience certificate

The <id-issuer> identifier is included for backward compatibility with
the use of electronic mail addresses as identifiers and
there is a desire to be able to use arbitrary strings ID-ASymmetric fields defined in [3].  The older fields are easily
converted to identify this new form by prefixing the
owners of public keys.  Hence, there is a need to support old value with "IS," and
replacing the field name forms
which do not conform with an appropriate new ID field.

5.  Applying PEM Security Services to MIME Body Parts

The next section describes the processing steps necessary to prepare a
MIME body part for the expected usage application of distinguished names.

In addition, users may distribute their public keys via mechanisms
outside PEM security services.  The
succeeding two sections describe the scope content of the PEM specification, for example, in a file via
FTP as opposed to in a certificate.  As a result, it is desirable to be
able to explicitly specify multipart/signed and
multipart/encrypted body parts resulting from the public key used rather than an identifier application of the public key. PEM
security services to MIME body parts.

5.1.  PEM Processing Steps

The objective definition of the various Originator multipart/signed and Recipient fields specified multipart/encrypted body
parts in [3] [7] specifies three steps for creating both body parts.

(1)  The body part is to indicate which public key has been used or is required. be protected is created according to a local
     convention.

(2)  The body part is prepared for protection according to the protocol
     parameter.

(3)  The prepared body part is protected according to the protocol
     parameter.

This document simplifies specification makes no changes to step one in the set of fields by specifying exactly two:
Originator-ID: sequence.  For
step two, there is no preparation necessary for originators 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
must be in a canonical form.  Transforming the body part to be signed
into a canonical form is a necessary and Recipient-ID: for recipients. essential step in the digital
signature process.  The

value of each of these fields canonical form must satisfy the property that it
is indicated by uniquely and unambiguously representable in both the token <id>, 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
defined representable on as follows.

    <id>           ::=   <id-email> / <id-string> / <id-dname>
                       / <id-publickey> / <id-issuer>

    <id-email>      ::= "EN"  "," <atstring>
                              "," <hashalgid> "," <hashpublickey>
    <id-string>     ::= "STR" "," <string>
                              "," <hashalgid> "," <hashpublickey>
    <id-dname>      ::= "DN"  "," <dname>
                              "," <hashalgid> "," <hashpublickey>
    <id-publickey>  ::= "PK"  ","
                              "," <pkalgid>   "," <publickey>
                              "," ( <string> / <atstring> )
    <id-issuer>     ::= "IS"  "," <dname>     "," <serial>

    <atstring>      ::= <encbin>
                        ; 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 printably encoded, ASN.1 encoded
                        ; string containing exactly one '@'
    <string>        ::= <encbin>
                        ; "a sequence two step process.  First, the
body part must be converted to canonical representation suitable for
transport between originators and recipients.  Second, the body part
must have its line delimiters canonicalized prior to computing the
digital signature and prior to each verification of characters excluding '@'"
                        ; a printably encoded, ASN.1 value

    <hashalgid>     ::= "to the digital
signature.

The canonical representation of all body parts is specified to be 7bit,
as defined by RFC 1423"
    <hashpublickey> ::= 1*<hexchar>
                        ; hex dump of [2].  Since the <hashalgid> hash headers of body parts are already required
to be representable in 7bit, this step requires that if the
                        ; public key

    <pkalgid>       ::= "to data to be
signed is not already 7bit it must be defined by RFC 1423"
    <publickey>     ::= <encbin>
                        ; a printably encoded, ASN.1 encoded public key

    <dname>         ::= <encbin>
                        ; a printably 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, ASN.1 body parts enclosed
within, for example, a multipart content type, must be encoded
                        ; distinguished name
    <serial>        ::= 1*<hexchar>
                        ; hex dump in a 7bit
representation.  Any valid MIME encoding may be selected.

The 7bit representation of the serial number data must be transferred to the
recipient.  As may be required by MIME, an appropriate Content-
Transfer-Encoding: header is included with the data.  Upon receipt, 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
text-based content types.  However, text-based content types present a certificate
unique problem.  In particular, the line delimiter used on 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 inclusion application of the hash digital signature service requires that the same
line delimiter be used by both the originator and the recipient.  This
document specifies that the two character sequence "<CR><LF>" must be
used as the line delimiter.  Thus, the canonicalization transformation
includes the transformation of the public key is intended local line delimiter to facilitate
the recognition of which public key among several that may be associated
with the string or distinguished name. two
character sequence "<CR><LF>".

The identifiers <id-email> and <id-string> are distinguished transformation to the canonical line delimiter is only by required for
the
presence or absence purposes of computing the character '@'. digital signature.  Thus, originators must
apply the canonical line delimiter transformation before computing the
digital signature but must transfer the data without the canonical line
delimiter transformation.  Similarly, recipients must apply the
canonical line delimiter transformation before computing the digital
signature.

    NOTE: An originator can not transfer the content with the
    canonical line delimiter transformation intact because the
    transformation process is not idempotent.  In all other respects they
are equivalent and are encoded strings that are to be used as particular, SMTP
    servers may themselves convert the
subject name in a certificate.  This distinguishing characteristic was
chosen as opposed canonical line delimiter to defining a new object identifier
    local line delimiter, prior to represent email
addresses because of the perceived difficulty in distributing and
implementing message being delivered to
    the definition of user.  Thus, a new object identifier.

The <id-publickey> identifier allows for the direct distribution and
indication recipient has no way of knowing if the public key that was
    transformation is present or not.  Thus, if the recipient
    applies the transformation 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 used aware that the
    transformation to process a canonical representation is a function that
    is available even in a minimally compliant MIME user agent.
    Further, the
message.

The <id-issuer> identifier canonical line delimiter transformation required
    here is distinct from the same transformation included for backward compatibility with in that
    function.  Specifically, the ID-ASymmetric fields defined line delimiter transformation in [3].  The older fields are easily
converted
    the former case is performed prior to this new form by prefixing the old value with "IS," and
replacing application of the field name with an appropriate new ID field.

6.  Definition
    canonical representation while it is performed after the
    application of New Content Types

This document defines two new content types, the contents canonical representation in the latter case.

5.2.  Use of which
comprise a replacement mechanism for [6].  The first multipart/signed Content Type

When this content type is
application/key-request, which replaces used, the certification and CRL-
retrieval request messages.  The second content type value of the required parameter
"protocol" is
application/key-data, which replaces "pem" and the certification reply message, value of the crl-storage request message, and required parameter "hashalg" is

one of the crl-retrieval reply message.
There were no requirements valid choices from [5], for a crl-storage reply message and none are
specified in this document. example:

    Content-Type: multipart/signed; protocol="pem"; hashalg="md5";
      boundary="Signed Message"

    --Signed Message
    Content-Type: text/plain

    This document includes a specification for
a certificate request message, which was previously undefined.

    NOTE: RFC1424 has is some descriptive text, especially for
    certification messages, that should probably be included.

6.1.  application/key-request Content Type Definition

(1)  MIME type name: application

(2)  MIME subtype name: key-request

(3)  Required parameters: none

(4)  Optional parameters: none

(5)  Encoding considerations: quoted-printable example text.

    --Signed Message
    Content-Type: application/signature

    <pemsig>
    --Signed Message--

where the <pemsig> token is defined as follows.

    <pemsig>             ::= <version> ( 1*<origasymflds> )

    <version>            ::= "Version:" "5" CRLF

    <origasymflds>       ::= <origid> <micinfo>

    <origid>             ::= "Originator-ID:" <id> CRLF

The token <id> is always sufficient

(6)  Security Considerations: none defined in Section 4.2.

The content only valid value for a Content-Transfer-Encoding: header, if
included, is "7bit".

5.3.  Use of multipart/encrypted Content Type

When this body part corresponds to content type is used, the following production.

    <request> value of the required parameter
"protocol" is "pem", for example:

    Content-Type: multipart/encrypted; protocol="pem";
      boundary="Encrypted Message"

    --Encrypted Message
    Content-Type: application/keys

    <pemkeys>

    --Encrypted Message
    Content-Type: application/octet-stream

    <encrypted data>
    --Encrypted Message--

where the <pemkeys> token is defined as follows.

    <pemkeys>            ::= <version>
                             ( <subject> / <issuer> / <certification> ) <dekinfo> 1*<recipasymflds>

    <version>            ::= "Version:" "5" CRLF
    <subject>

    <recipasymflds>      ::= "Subject:" <id> CRLF
    <issuer> <recipid> <asymkeyinfo>

    <recipid>            ::= "Issuer:" "Recipient-ID:" <id> CRLF
    <certification>

    <asymkeyinfo>        ::= "Certification:" <encbin> "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF

This content type

The token <id> is used defined in Section 4.2.

6.  Removing PEM Security Services from PEM Body Parts

This section describes the processing steps necessary to provide verify or
decrypt the PEM security services that have been applied to MIME body
parts.  Outer layers of PEM security services must be processed prior to
processing inner layers of PEM security services.  Processing includes a
user choosing to display a content without removing the PEM security
services.

The definition of the multipart/signed and multipart/encrypted body
parts in [7] specifies three steps for some receiving both body parts.

(1)  The protected body part and the control information body part are
     prepared for processing.

(2)  The prepared body parts are made available to the protection
     removal process.

(3)  The results of the requests protection removal process are made available to
     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
parts is different, as described
in [6].  The information below.  No changes are required to
steps two and three in the sequence.

For multipart/signed body part parts, the control information is entirely independent of prepared by
removing any
other content transfer encodings that may be present.  The
digitally signed body part.  As such, part is prepared by leaving the application/key-request content type is
an independent body part.

The certification request, certificate-retrieval request transfer
encodings intact and crl-
retrieval request are provided for directly.  If canonicalizing the content contains a
Certification: field it requests certification line delimiters according to
Step 2 of the self-signed
certificate in the field value.  If Section 5.1.

Multipart/encrypted body parts are prepared by removing the content contains an Issuer:
field it requests the certificate revocation list chain beginning with
the issuer identified in
transfer encodings, if present, from both the field value.  If control information and
the encrypted body part.

7.  Definition of New Content Types

This document defines two new content contains a
Subject: field it requests the certificate chain beginning with the
subject identified in types, the field value.

The Subject: and Issuer: fields each contain a value contents of type Name,
encoded according to the Basic Encoding Rules, then in ASCII, as which
comprise a replacement mechanism for the
Originator-ID-Asymmetric: field of [3]. [6].  The crl-storage request first content type is provided for by
application/key-request, which replaces the application/key-data certification and CRL-
retrieval request messages.  The second content type described in is
application/key-data, which replaces the next section.

In each case, certification reply message,
the response is transmitted in an application/key-data
content type.  When returning certificate and certificate revocation
list chains, if there exists more than one chain, several
application/key-data contents are to be returned in crl-storage request message, and the crl-retrieval reply message.
There were no requirements for a crl-storage reply message and none are
specified in this document.  This document includes a specification for
a public key and certificate request message,
one which were previously
undefined.

    NOTE: RFC1424 has some descriptive text, especially for each chain.

6.2.  application/key-data
    certification messages, that should probably be included.

7.1.  application/key-request Content Type Definition

(1)  MIME type name: application

(2)  MIME subtype name: key-data key-request

(3)  Required parameters: none

(4)  Optional parameters: none

(5)  Encoding considerations: quoted-printable is always sufficient. sufficient

(6)  Security Considerations: none

The content of this body part corresponds to the following production.

    <certdata>           ::= <certchain> / <crlchain>
    <certchain>

    <request>            ::= <version> <cert> *( [ <crl> ] <cert>
                             ( <subject> / <issuer> / <certification> )
    <crlchain>           ::=
    <version> 1*( <crl> [ <cert> ] )
    <cert>            ::= "Certificate:" <encbin> "Version:" "5" CRLF
    <crl>
    <subject>            ::= "CRL:" <encbin> "Subject:" <id> CRLF
    <version>
    <issuer>             ::= "Version:" "5" "Issuer:" <id> CRLF
    <certification>      ::= "Certification:" <encbin> CRLF

This content type is used to transfer certificate or Certificate
Revocation List (CRL) information.  The information in the body part is
entirely independent of any particular privacy enhanced message.  (Note
that the converse is not true: the validity of a privacy enhanced
message cannot be determined without the proper certificates or current
CRL information.)  As such, the application/key-data content type is an
independent body part.

The <certchain> production contains one certificate chain.  A
certificate chain starts with a certificate and continues with the
certificates provide for some 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
chain.  The CRLs requests described
in the chain begin with the requested CRL and continue
with the CRLs of subsequent issuers. [6].  The issuer information in the body part is entirely independent of each CRL any
other body part.  As such, the application/key-request content type is presumed
to have issued a certificate
an independent body part.

The certification request, certificate-retrieval request and crl-
retrieval request are provided for directly.  If the issuer content contains a
Certification: field it requests certification of the preceding CRL.  For
each CRL, the issuer's certificate may be supplied.  A self-signed
certificate in the chain must belong to field value.  If the issuer of content contains an Issuer:
field it requests the immediately preceding CRL.

The relationship between a certificate and an immediately preceding CRL
is revocation list chain beginning with
the same issuer identified in both cases.  In a <certchain> the crl's are optional.  In
a <crlchain> field value.  If the certificates are optional.

7.  Message Processing

When a user composes content contains a message,
Subject: field it is requests either the responsibility public key of the user
agent to construct a valid MIME message.  In particular, Content-Type:
and Content-Transfer-Encoding: headers should be used wherever they are
appropriate.  This allows the receiving user agent to unambiguously
interpret the message body and process it accordingly.

Each block of content headers associated with either an RFC822 <message> subject or the
certificate chain beginning with a MIME <body-part> represents a logical place where security
enhancement can be requested.  A security enhancement request associated
with a particular <message> or <body-part> content is taken to apply to the entire content; it is not possible to security-enhance only subject identified in the field
value, or both.

The Subject: and Issuer: fields each contain a
portion value of a body part. type <id>, which
is defined in Section 4.2.

The mechanism used to communicate security enhancement requests to the
pre-submission processor described below crl-storage request is strictly a local
implementation issue.  However, provided for by the application/key-data
content type described in the interface between next section.

In each case, the message
composer response is transmitted in an application/key-data
content type.  When returning public keys, certificate chains, and pre-submission processing MUST
certificate revocation list chains, if there exists more than one,
several application/key-data contents are to be trustworthy, since returned in the
message composer relies on pre-submission processing reply

message, one for each.

7.2.  application/key-data Content Type Definition

The principal objective of this content type is to either perform
the requested security enhancement operation or return convey cryptographic
keying material from an error.
Regardless of the mechanism chosen, great care should be taken originator to
safeguard against both the release of information that has not received a recipient.  However, no explicit
provision is made for determining the requested type authenticity or accuracy of security enhancement as well as tampering with the
enhancement request itself.

7.1.  Pre-Submission Algorithm

The user agent first composes
data being conveyed.  In particular, when a MIME-compliant message public key and then applies
this algorithm:

(1)  If the content at this (initially top) level has NOT been selected
identifier for security enhancement, the user agent sees if the content its owner is
     either multipart or message.  If so, it then recursively applies
     this algorithm conveyed, there is nothing to prevent an
originator or any interloper along the encapsulated body parts; if not, it
     terminates processing path from an originator to a
recipient from substituting alternate values for this content.

(2)  If either the content at this level has been selected for security
     enhancement, then public key
or the content, including its headers, constitutes identifier, thus setting up the object that is recipient to potentially send
sensitive information that may be made available intercepted and disclosed
inappropriately.

It is incumbent upon a recipient to verify the security enhancement
     process. authenticity and accuracy
of the data received prior to its use.  The headers at problem is addressed by the
use of certificates, since a minimum will include certification hierarchy is a Content-Type
     header, either explicit or implicit.  The object will eventually well-defined
mechanism that conveniently supports the automatic verification of the
data.  Alternatively, the application/key-data body part could be
     replaced with
digitally signed by the multipart content originator.  In this way, if a recipient
believes that correct originator's public key is produced by available locally and
if the
     security enhancement operation.

(3)  The selected security enhancement is performed.  This enhancement
     produces two recipient believes the originator would convey accurate data,
then the key data streams: received from the enhanced object and originator can be believed.

    NOTE: Insofar as a control stream
     comprised of certificate represents a set of headers as defined in mechanism by which
    an issuer vouches for the <pemsig> or
     <pemkeys> productions.

(4)  A new binding between the name and public
    key it embodies, the signing of an application/key-data body
    part is then constructed, a similar mechanism.

(1)  MIME type name: application

(2)  MIME subtype name: key-data

(3)  Required parameters: none

(4)  Optional parameters: none

(5)  Encoding considerations: quoted-printable is always sufficient.

(6)  Security Considerations: none

The content of this body part corresponds to the following production.

    <certdata>           ::= <version>
                             ( <keydata> / <certchain> / <crlchain> )
    <version>            ::= "Version:" "5" CRLF
    <keydata>            ::= "Key:" <id> "," <nameid> CRLF
    <certchain>          ::= <cert> *( [ <crl> ] <cert> )
    <crlchain>           ::= 1*( <crl> [ <cert> ] )
    <cert>               ::= "Certificate:" <encbin> CRLF
    <crl>                ::= "CRL:" <encbin> CRLF

This content type
     multipart/signed is used to transfer public keys, certificate chains,
or multipart/encrypted. Certificate Revocation List (CRL) chains.  The new information in the
body part
     contains two is entirely independent of any other body parts, whose content depends on the enhancement
     requested, which are constructed according to part.  (Note that
the specifications in
     this document.

(5)  This multipart content replaces converse is not true: the original object.

7.2.  Post-Delivery Algorithm

When a user receives a message containing validity of a multipart content, protected body part cannot
be determined without the user
agent may transform proper public keys, certificates, or current
CRL information.)  As such, the application/key-data content back into type is an
independent body part.

The <keydata> production contains exactly one public key.  It is used to
bind a public key with its original corresponding name form prior to
privacy-enhancement.  This operation, the post-delivery algorithm, and key identifier.
It is
performed recommended that when responders are returning this information
that the enclosing body part be digitally signed by reversing the steps performed during responder in
order to protect the pre-submission
algorithm.

When information.

The <certchain> production contains one certificate chain.  A
certificate chain starts with a certificate and continues with the original content is reconstituted, it may use octet values
outside
certificates of subsequent issuers.  Each issuer certificate included
must have issued the US-ASCII repertoire and preceding certificate.  For each issuer, a CRL may contain body parts without
line breaks.  If
be supplied.  A CRL in the user agent replaces chain belongs to the multipart content immediately following
issuer.  Therefore, it potentially contains the immediately preceding
certificate.

The <crlchain> production contains one certificate revocation list
chain.  The CRLs in the chain begin with the
original content, then it must select appropriate Content-Transfer-
Encodings for each body part requested CRL and add corresponding Content-Transfer-
Encoding: headers.

Upon successful completion of the post-delivery algorithm for each
content, continue
with the type CRLs of enhancement that was in effect for that content
must be communicated to the user. subsequent issuers.  The mechanism used to do this issuer of each CRL is presumed
to have issued a
local implementation issue.  As with requests certificate for enhancement 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
pre-submission algorithm, issuer of the path immediately preceding CRL.

The relationship between post-delivery processing a certificate and
actual display of an immediately preceding CRL
is the message must be same in both <certchain> and <crlchain>.  In a trusted one, lest <certchain> the
CRLs are optional.  In a message be
presented that purports to have undergone some form of enhancement it
did not in fact receive. <crlchain> the certificates are optional.

8.  Examples

    NOTE: To be included upon completion of implementation.

9.  Observations

The use of the pre-submission and post-delivery algorithms to combine
PEM and MIME capabilities exhibits several properties:

(1)  It allows privacy-enhancement of an arbitrary content, not just the
     body of an RFC 822 RFC822 message.

(2)  For a multipart or message content, it allows the user to specify
     different privacy enhancements to be applied to different
     components of the structure of the content.

(3)  It provides for messages containing several privacy enhanced
     contents, thereby removing the requirement for PEM software to be
     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
message body parts much easier.  For example, the user can separately
sign and encrypt a message.  This motivates a complete separation of the
confidentiality security service from the digital signature security
service.  That is, different keys key pairs could be used for the different
services and could be protected separately.  In the asymmetric case,
this  This means an employee's
company could be given access to the (private) decryption key but not
the (private) signature key, thereby granting the company the ability to
decrypt messages addressed to the employee in emergencies without also
granting the company the ability to sign messages as the employee.

The use of two private keys requires the ability to maintain multiple
certificates for each user.

10.  Summary of Changes to PEM Specification

This document updates the message encryption and signature procedures
defined by [3] and obsoletes the key certification and related services
defined by [6].  The changes are enumerated below.

(1)  The PEM specification currently requires that encryption services
     be applied only to message bodies that have been signed.  By
     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
     text-based electronic mail messages.  In fact, the message text is
     required to be represented by the ASCII character set with
     "<CR><LF>" line delimiters.  This restriction no longer applies.

(3)  With the removal of the text restriction it is not possible to
     specify a universal canonical form.  However, canonicalization is
     required for the digital signature service, so the content of each
     body part must be transformed into a canonical form according to
     its type.

(4)  MIME includes transfer encoding operations to ensure the unmodified
     transfer of body parts, which obviates these services in PEM.

(5)

(4)  PEM specifies a Proc-Type: header field to identify the type of
     processing that was performed on the message.  This functionality
     is subsumed by the MIME Content-Type: headers.  The Proc-Type:
     header also included a decimal number that was 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.

(6)

(5)  PEM specifies a Content-Domain: header, the purpose of which is to
     describe the type of the content which is represented within a PEM
     message's encapsulated text.  This functionality is subsumed by the
     MIME Content-Type: headers.

(7)

(6)  The PEM specifications include a document that defines new types of
     PEM messages, specified by unique values used in the Proc-Type:
     header, to be used to request certificate and certificate
     revocation list information.  This functionality is subsumed by two
     new content types specified in this document.

(8)

(7)  The header fields having to do with certificates (Originator-
     Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated
     for use only in the application/key-data and application/key-
     request content types and are no longer allowed in the header
     portion of a PEM signed or encrypted message.

(9)

(8)  The grammar specified here explicitly separates the header fields
     that may appear for the encryption and signature security services.
     It is the intent of this document to specify a precise expression
     of the allowed header fields; there is no intent to reduce the
     functionality of combinations of encryption and signature security
     from those of [3].

(10)

(9)  With the separation of the encryption and signature security
     services, there is no need for a MIC-Info: field in the headers
     associated with an encrypted message under asymmetric key
     management.

(11) message.

(10) In [3], when asymmetric key management is used, an Originator-ID
     field is required in order to identify the private key used to sign
     the MIC argument in the MIC-Info: field.  Because no MIC-Info:
     field is associated with the encryption security service under
     asymmetric key managment, there is no requirement in that case to
     include an Originator-ID field.

These changes represent a departure in mechanism, not in effect, from
those specified in [3] and [6].  The following technical changes to [3]
and [4] are also specified by this document.

(1)  The grammar specified here explicitly excludes symmetric key
     management.  Currently, there are no generally available
     implementations of symmetric key management nor are there any known
     plans for implementing it.  As a result, the IETF standards process
     will require this feature to be dropped when the documents are
     promoted to draft standard status from proposed standard status.

(2)  This document requires all data that is to be digitally signed to
     be represented in 7bit form.

(3)  This document relaxes the syntax of distinguished names.  In
     particular, distinguished names are not constrained to conform to broadens the X.500 Series of Recommendations.  Instead allowable name forms that users may use
     to identify their public keys.  Users may use arbitrary strings and
     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: Originator-ID-ASymmetric: and Recipient-ID-ASymmetric: Recipient-ID-
     ASymmetric: fields are deprecated in favor of Originator-ID: and
     Recipient-ID: fields, respectively.

11.  Collected Grammar

The following is a summary of the grammar presented in this document.

(1)  Signature headers
         <pemsig>             ::= <version> (1*<origasymflds>) ( 1*<origasymflds> )

         <version>            ::= "Version:" "5" CRLF

         <origasymflds>       ::= <origid> <micinfo>

         <origid>             ::= "Originator-ID:" <id> CRLF

(2)  Encryption Headers

         <pemkeys>            ::= <version> <dekinfo> 1*<recipasymflds>

         <version>            ::= "Version:" "5" CRLF

         <recipasymflds>      ::= <recipid> <asymkeyinfo>

         <recipid>            ::= "Recipient-ID:" <id> CRLF

         <asymkeyinfo>        ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF

(3)  Identifier Name Forms
         <id>            ::= <nameid> / <id-publickey> / <id-issuer>

         <nameid>        ::= <id-email> / <id-string> / <id-dname> / <id-pgp>

         <id-email>      ::= "EN"  "," <keyid> "," <emailstr> CRLF

         <id-string>     ::= "STR" "," <keyid> "," <string> CRLF

         <id-dname>      ::= "DN"  "," <keyid> "," <dnamestr> CRLF

         <id-pgp>        ::= "PGP2" ",0x" <pgp-keyid> "," <string> CRLF

         <id-publickey>  ::= "PK"  "," <publickey> [ "," <nameid> ] CRLF

         <id-issuer>     ::= "IS"  "," <dnamestr>  "," <serial> CRLF

         <keyid>         ::= <encbin>
                             ; a printably encoded non-null sequence of octets

         <emailstr>      ::= <addr-spec> / <route-addr>
                             ; an electronic mail address as defined by
                             ; these two tokens from RFC822

         <string>        ::= ; a non-null sequence of us-ascii characters

         <dnamestr>      ::= <encbin>
                             ; a printably encoded, ASN.1 encoded
                             ; distinguished name

         <pgp-keyid>     ::= ; a sequence from the following alphabet: {0-9, A-F}
                             ; which is either exactly six or eight characters long

         <publickey>     ::= <encbin>
                             ; a printably encoded, ASN.1 encoded
                             ; subjectPublicKeyInfo

         <serial>        ::= 1*<hexchar>
                             ; hex dump of the serial number of a certificate

(4)  Request Headers (certificate, certification, etc.)
         <request>            ::= <version>
                                  ( <subject> / <issuer> / <certification> )
         <version>            ::= "Version:" "5" CRLF
         <subject>            ::= "Subject:" <id> CRLF
         <issuer>             ::= "Issuer:" <id> CRLF
         <certification>      ::= "Certification:" <encbin> CRLF

(4)  Certificate

(5)  Data Headers (certificate, certification revocation list)

         <certdata>           ::= <certchain> / <crlchain>
         <certchain>          ::= <version> <cert> *( [ <crl> ] <cert> )
         <crlchain>           ::= <version> 1*( <crl> [ <cert> ] )
         <cert>               ::= "Certificate:" <encbin> CRLF
         <crl>                ::= "CRL:" <encbin> CRLF
         <version>            ::= "Version:" "5" CRLF

12.  Security Considerations

    NOTE: to be done

13.  Acknowledgements

David H. Crocker suggested the use of a multipart structure for MIME-PEM
interaction.

14.  References

[1]  David H. Crocker.  Standard for the Format of ARPA Internet Text
     Messages.  RFC 822, University of Delaware, August 1982.

[2]  Nathaniel Borenstein and Ned 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.  Obsoletes RFC 1341.

[3]  John Linn.  Privacy Enhancement for Internet Electronic Mail: Part
     I: Message Encryption and Authentication Procedures.  RFC 1421,
     February 1993.  Obsoletes RFC 1113.

[4]  Steve Kent.  Privacy Enhancement for Internet Electronic Mail: Part
     II: Certificate-Based Key Management.  RFC 1422, BBN
     Communications, February 1993.

[5]  David M. Balenson.  Privacy Enhancement for Internet Electronic
     Mail: Part III: Algorithms, Modes, and Identifiers.  RFC 1423,
     Trusted Information Systems, February 1993.

[6]  Burton S. Kaliski.  Privacy Enhancement for Internet Electronic
     Mail: Part IV: Key Certification and Related Services.  RFC 1424,
     RSA Laboratories, February 1993.

[7]  David Crocker.  Multipart/Family Content Types.  Work in progress.

[8]  James Galvin. Galvin, Sandy Murphy, Steve Crocker, and Ned Freed.  Security
     Multiparts for MIME: Multipart/Signed and
     Multipart/Encrypted.  Work in progress.

[9]  Jon Postel.  Simple Mail Transfer Protocol. Multipart/Encrypted.
     RFC 821, ISI, August
     1982. XXXX, Trusted Information Systems and Innosoft, XXXX 1994.

15.  Authors' Addresses

    Steve Crocker
    email:  crocker@tis.com

    James M. Galvin
    email:  galvin@tis.com

    Sandra Murphy
    email:  murphy@tis.com

    Trusted Information Systems
    3060 Washington Road
    Glenwood, MD  21738
    Tel:    +1 301 854 6889
    FAX:    +1 301 854 5363
    email:  crocker@tis.com

    Ned Freed
    Innosoft International, Inc.
    250 West First Street, Suite 240
    Claremont, CA 91711
    Tel:    +1 909 624 7907
    FAX:    +1 909 621 5319
    email:  ned@innosoft.com

    James M. Galvin
    Trusted Information Systems
    3060 Washington Road
    Glenwood, MD  21738
    Tel:    +1 301 854 6889
    FAX:    +1 301 854 5363
    email:  galvin@tis.com

    Sandra Murphy
    Trusted Information Systems
    3060 Washington Road
    Glenwood, MD  21738
    Tel:    +1 301 854 6889
    FAX:    +1 301 854 5363
    email:  murphy@tis.com

16.  Appendix: Imported Grammar

The following productions are taken from [3].  The grammar presented in
[3] remains the authoritative source for these productions; they are
repeated here for the convenience of the reader.

    <dekinfo>    ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF

    <micinfo>    ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
                     <asymsignmic> CRLF

    <encbin>     ::= 1*<encbingrp>
    <encbingrp>  ::= 4*4<encbinchar>
    <encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="

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.

    <dekalgid>         ::= "DES-CBC"
    <ikalgid>          ::= "DES-EDE" / "DES-ECB" / "RSA"
    <micalgid>         ::= "RSA-MD2" / "RSA-MD5"

    <dekparameters>    ::= <DESCBCparameters>
    <DESCBCparameters> ::= <IV>
    <IV>               ::= <hexchar16>

    <asymsignmic>      ::= <RSAsignmic>
    <RSAsignmic>       ::= <encbin>

    <asymencdek>       ::= <RSAencdek>
    <RSAencdek>        ::= <encbin>

    <hexchar16>        ::= 16*16<hexchar>
    <hexchar>          ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
                                                        ; no lower case

The following productions are taken from [1].  The grammar presented in
[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

    <local-part>    ::= <word> *( "." <word> )           ; uninterpreted
                                                         ; case-preserved

    <domain>        ::= <sub-domain> *( "." <sub-domain> )

    <sub-domain>    ::= <domain-ref> / <domain-literal>

    <domain-ref>    ::= <atom>                           ; symbolic reference

    <route-addr>    ::= "<" [ <route> ] <addr-spec> ">"

    <route>         ::=  1# ( "@" <domain> ) ":"         ; path-relative

    <word>          ::= <atom> / <quoted-string>

    <quoted-string> ::= """ *( <qtext> / <quoted-pair> ) """

    <qtext>         ::= (any <CHAR> excepting """, "
                         and including <linear-white-space>)

    <quoted-pair>   ::= "

    <linear-white-space> ::= 1*( [ CRLF ] <LWSP-char> )  ; semantics = SPACE
                                                         ; CRLF => folding
    <LWSP-char>     ::= SPACE / HTAB                     ; semantics = SPACE

    <atom>          ::= 1*(any <CHAR> except <specials>, SPACE and <CTL>s)

    <CHAR>          ::= <any ASCII character>

    <CTL>           ::= <any ASCII control character and DEL>

    <specials>      ::=  "(" / ")" / "<" / ">" / "@"     ; Must be in quoted-
                         /  "," / ";" / ":" / "
                         /  "." / "[" / "]"              ;  within a word.

Table of Contents

1 Status of this Memo .............................................    1
2 Abstract ........................................................    1
3 Introduction ....................................................    2
4 Name Forms and Identifiers ......................................    3
4.1 Name Forms ....................................................    4
4.1.1 Email Addresses .............................................    4
4.1.2 Arbitrary Strings ...........................................    5
4.1.3 Distinguished Names .........................................    5
4.2 Identifiers ...................................................    5
4.2.1 Email Address ...............................................    6
4.2.2 Arbitrary String ............................................    6
4.2.3 Distinguished Name ..........................................    7
4.2.4 PGP Public Key ..............................................    7
4.2.5 Public Key ..................................................    7
4.2.6 Issuer Name and Serial Number ...............................    8
5 Applying PEM Security Services to MIME Body Parts ...............    2
3.1    8
5.1 PEM Processing Steps ..........................................    3
3.1.1 Step 1: Local Form ..........................................    3
3.1.2 Step 2: Canonical Form ......................................    3
3.1.3 Step 3: Security Form .......................................    5
3.2    8
5.2 Use of multipart/signed Content Type ..........................    5
3.3   10
5.3 Use of multipart/encrypted Content Type .......................   11
6
4 Removing PEM Security Services from PEM Body Parts ..............   12
7
5 Definition of New Name Forms ....................................    7
6 Definition of New Content Types .................................    9
6.1   13
7.1 application/key-request Content Type Definition ...............    9
6.2   13
7.2 application/key-data Content Type Definition ..................   10
7 Message Processing ..............................................   12
7.1 Pre-Submission Algorithm ......................................   12
7.2 Post-Delivery Algorithm .......................................   13   15
8 Examples ........................................................   13   17
9 Observations ....................................................   14   17
10 Summary of Changes to PEM Specification ........................   14   17
11 Collected Grammar ..............................................   16   19
12 Security Considerations ........................................   18   22
13 Acknowledgements ...............................................   18   22
14 References .....................................................   18   22
15 Authors' Addresses .............................................   19   23
16 Appendix: Imported Grammar .....................................   20   24