< draft-ietf-pem-mime-06.txt		draft-ietf-pem-mime-07.txt >
	Network Working Group Steve Crocker		Network Working Group Steve Crocker
	INTERNET DRAFT Ned Freed		INTERNET DRAFT Ned Freed
	draft-ietf-pem-mime-06.txt Jim Galvin		draft-ietf-pem-mime-07.txt Jim Galvin
	Sandy Murphy		Sandy Murphy
	July 1994		November 1994
	PEM Security Services and MIME		PEM Security Services and MIME
	1. Status of this Memo		Status of this Memo
	This document is an Internet Draft. Internet Drafts are working		This document is an Internet Draft. Internet Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas, and		documents of the Internet Engineering Task Force (IETF), its Areas, and
	its Working Groups. Note that other groups may also distribute working		its Working Groups. Note that other groups may also distribute working
	documents as Internet Drafts.		documents as Internet Drafts.
	Internet Drafts are valid for a maximum of six months and may be		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		updated, replaced, or obsoleted by other documents at any time. It is
	inappropriate to use Internet Drafts as reference material or to cite		inappropriate to use Internet Drafts as reference material or to cite
	them other than as ``work in progress''.		them other than as ``work in progress''.
	To learn the current status of any Internet Draft, please check the		To learn the current status of any Internet Draft, please check the
	1id-abstracts.txt listing contained in one of the Internet Drafts Shadow		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		Directories on ds.internic.net (US East Coast), venera.isi.edu (US West
	Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe).		Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe).
	2. Abstract		Abstract
	This document specifies how the services of MIME and PEM can be used in		This document specifies how the services of MIME and PEM can be used in
	a complementary fashion. MIME, an acronym for "Multipurpose Internet		a complementary fashion. MIME, an acronym for "Multipurpose Internet
	Mail Extensions", defines the format of the contents of Internet mail		Mail Extensions", defines the format of the contents of Internet mail
	messages and provides for multi-part textual and non-textual message		messages and provides for multi-part textual and non-textual message
	bodies. PEM, an acronym for "Privacy Enhanced Mail", provides message		bodies. PEM, an acronym for "Privacy Enhanced Mail", provides message
	authentication/integrity and message encryption services for Internet		authentication/integrity and message encryption services for Internet
	mail messages.		mail messages.
	An Internet electronic mail message consists of two parts: the headers		An Internet electronic mail message consists of two parts: the headers
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	document specifies how to use PEM with the multipart/signed and		document specifies how to use PEM with the multipart/signed and
	multipart/encrypted MIME content types to provide		multipart/encrypted MIME content types to provide
	authentication/integrity and encryption services. We refer to the		authentication/integrity and encryption services. We refer to the
	authentication/integrity service as a digital signature service.		authentication/integrity service as a digital signature service.
	This document specifies a number of changes to the message encryption		This document specifies a number of changes to the message encryption
	and signature procedures of PEM and broadens the name forms that may be		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		used to identify public keys. Many of the changes represent a departure
	in mechanism, not in effect.		in mechanism, not in effect.
	3. Introduction		1. Introduction
	This document updates the message encryption and signature procedures		This document updates the message encryption and signature procedures
	defined by [3] and obsoletes the key certification and related services		defined by [3] and replaces the key certification and related services
	defined by [6]. The changes to [3] include the separation of the		defined by [6]. The changes to [3] include the separation of the
	encryption and signature services, the removal of the limitation to		encryption and signature services, the removal of the limitation to
	enhance only text-based messages, the removal of the transfer encoding		enhance only text-based messages, the removal of the transfer encoding
	operation, the deprecation of the Content-Domain: and Proc-Type:		operation, the deprecation of the Content-Domain: and Proc-Type:
	headers, and the separation of certificate and certificate revocation		headers, and the separation of certificate and certificate revocation
	list transmission from the security enhancements. These changes		list transmission from the security enhancements. These changes
	represent a departure in mechanism, not in effect, and are detailed in		represent a departure in mechanism, not in effect, and are detailed in
	Section 10.		Section 8.
	In addition, this document specifies three technical changes to PEM:		In addition, this document specifies four technical changes to PEM:
	symmetric key management in [3] is deprecated, the canonicalization		symmetric key management in [3] is deprecated, the canonicalization
	operation in [3] is generalized, and the allowable name forms for the		operation in [3] is generalized, the allowable name forms for the
	identification of public keys is broadened to include arbitrary strings		identification of public keys is broadened to include arbitrary strings
	and email addresses, and users may distribute their public keys directly		and email addresses, and users may distribute their public keys directly
	in lieu of certificates.		in lieu of certificates.
	The key certification and related services document [6] is obsoleted by		The key certification and related services are replaced by the
	the specification of two new MIME content types: application/key-request		specification of two new MIME content types: application/key-request and
	and application/key-data. These new content types are used to transmit		application/key-data. These new content types are used to transmit
	requests for key operations (storage, retrieval, certification,		requests for key operations (storage, retrieval, certification,
	revocation list retrieval, etc.) and the responses to those requests.		revocation list retrieval, etc.) and the responses to those requests.
	These two content types are independent body parts and are not required		These two content types are independent body parts and are not required
	to be encapsulated in any other body part. These changes represent a		to be encapsulated in any other body part. These changes represent a
	departure in mechanism, not in effect, and are detailed in Section 10.		departure in mechanism, not in effect, and are detailed in Section 8.
	In order to make use of the PEM services, a user is required to have at		In order to make use of the PEM services, a user is required to have at
	least one public/private key pair. Prior to this specification, the		least one public/private key pair. Prior to this specification, the
	public key was required to be embodied in a certificate, an object that		public key was required to be embodied in a certificate, an object that
	binds a public key with a distinguished name, a name form that		binds a public key with a distinguished name, a name form that
	identified the owner of the public key. The embodiment was issued by a		identified the owner of the public key. The embodiment was issued by a
	certification authority, a role that was expected to be trustworthy		certification authority, a role that was expected to be trustworthy
	insofar as it verified the identity of the owner prior to issuing the		insofar as it verified the identity of the owner prior to issuing the
	certificate. However, the deployment of certificates and the creation		certificate. However, the deployment of certificates and the creation
	of the hierarchy of certification authorities has been problematic.		of the hierarchy of certification authorities has been problematic.
	Instead, this specification bases the PEM services on a public/private		Instead, this specification bases the PEM services on a public/private
	key pair. Each key pair is required to belong to a user (where user is		key pair. Each key pair is required to belong to a user (where user is
	not limited to being a human, e.g., a process or a role) which has a		not limited to being a human, e.g., it could be a process or a role)
	name. There are 3 name forms specified by this document. For backward		which has a name. There are 3 name forms specified by this document.
	compatibility (and forward compatibility if the X.500 Directory becomes		For backward compatibility (and forward compatibility if the X.500
	a ubiquitous service) one of the name forms is a distinguished name. In		Directory becomes a ubiquitous service) one of the name forms is a
	addition, email addresses and arbitrary strings are allowed.		distinguished name. In addition, email addresses and arbitrary strings
			are allowed.
	Since a user may have more than one key pair, a name form is		Since a user may have more than one key pair, a name form is
	insufficient for uniquely identifying a key pair. The owner of a key		insufficient for uniquely identifying a key pair. A unique key selector
	pair must assign a key identifier to each key pair. The combination of		must be assigned to each key pair. The combination of a name form and a
	a name form and a key identifier uniquely identifies a key pair and each		key selector uniquely identifies a key pair and each key pair is
	key pair is uniquely identified by a name form and key identifier		uniquely identified by a name form and key selector combination.
	combination. Throughout this document, this combination is called an		Throughout this document, this combination is called an identifier.
	identifier. There are 6 identifiers specified by this document.		There are 5 identifiers specified by this document.
			NOTE: In the simplest case, key selectors will be assigned by
			the owners of the key pairs. This works best when users
			generate their own key pairs for personal use, which they
			distribute to others asserting by declaration that the public
			key belongs to them. When the assertion that the public key
			belongs to them is made by a third party, for example when a
			certification authority issues a certificate to a user according
			to [4], the key selector may be assigned by that third party.
	With a key pair for one's self and software that is both MIME and PEM		With a key pair for one's self and software that is both MIME and PEM
	aware, an originating user may digitally sign arbitrary data and send it		aware, an originating user may digitally sign arbitrary data and send it
	to one or more recipients. With the public keys of the recipients, a		to one or more recipients. With the public keys of the recipients, a
	user may encrypt the data so that only the intended recipients can		user may encrypt the data so that only the intended recipients can
	decrypt and read the it. This specification separates these two		decrypt and read it. This specification separates these two services so
	services so that an originator may apply either or both, in either		that an originator may apply either or both, in either order.
	order.
	The name forms and identifiers are described in detail in the next		The name forms and identifiers are described in detail in the next
	section. Succeeding sections specify how PEM and MIME are used together		section. Succeeding sections specify how PEM and MIME are used together
	and other ancillary details.		and other ancillary details.
	4. Name Forms and Identifiers		2. Name Forms and Identifiers
	Currently, [3] requires the use of certificates to identify the public		Currently, [3] requires the use of certificates to create and receive
	key (and corresponding private key) used to create a PEM message.		PEM messages. Within certificates, [4] requires the use of
	Within certificates, [4] requires the use of distinguished names as		distinguished names as specified by the X.500 Series of Recommendations.
	specified by the X.500 Series of Recommendations. However, the Internet		However, the Internet community has a great deal more experience with
	community has a great deal more experience with the use of electronic		the use of electronic mail addresses as a name form and there is a
	mail addresses as a name form and there is a desire to be able to use		desire to be able to use arbitrary strings to identify the owners of
	arbitrary strings to identify the owners of public keys. Hence, there		public keys. Hence, there is a need to support name forms which do not
	is a need to support name forms which do not conform to the expected		conform to the expected usage of distinguished names.
	usage of distinguished names.
	When processing PEM messages it is necessary to be able to uniquely		When receiving PEM messages it is necessary to be able to uniquely
	identify the key pair used to create the message. A certificate is		identify the key pair used to create the message. A certificate is one
	uniquely identified by the combination of its issuer's distinguished		mechanism that accomplishes this, since it is uniquely identified by the
	name and its serial number. Thus, the issuer name and serial number		combination of its issuer's distinguished name and its serial number.
	uniquely identifies a key pair. Since a user may have more than one key		In any case, an identifier is required that consists of both a name form
	pair, a name form is insufficient for this purpose. An identifier is		and key selector.
	required that consists of both a name form and key identifier, a value
	assigned to a key pair by its owner.
	In addition, users may distribute their public keys via mechanisms		In addition, users may distribute their public keys via mechanisms
	outside the scope of the PEM specification, for example, in a file via		outside the scope of the PEM specification, for example, in a file via
	FTP. As a result, it is desirable to be able to explicitly specify the		FTP. Users receiving such keys will probably assign name forms to them
	public key used rather than an identifier of the public key. A		to be displayed when receiving messages created with them. As a result,
	significant benefit of this mechanism is the ability to support		it is desirable to be able to explicitly specify the public key used
	encrypted, anonymously signed mail.		rather than an identifier of the public key.
	The objective of the various Originator and Recipient fields specified		NOTE: A feature of being able to specify the public key
	in [3] is to identify which public key has been used or is required.		explicitly is that it allows users to exchange encrypted,
	This document simplifies the set of fields by specifying exactly two:		anonymous mail. In particular, receiving users will always know
	Originator-ID: for originators and Recipient-ID: for recipients. This		a message comes from the same originating user.
	specification defines six (6) identifiers with which the public key used
			The principal objective of the various Originator and Recipient fields
			specified in [3] is to identify which public key has been used or is
			required. This document reduces the set of fields by specifying exactly
			two: Originator-ID: for originators and Recipient-ID: for recipients.
			This specification defines 5 identifiers with which the public key used
	may be indicated in each of these fields.		may be indicated in each of these fields.
	In the next section the 3 name forms are described in detail. Following		In the next section the 3 name forms are described in detail. Following
	that is the specification of the 6 identifiers.		that is the specification of the 5 identifiers.
	4.1. Name Forms		2.1. Name Forms
	There are 3 name forms specified by this document: email address,		There are 3 name forms specified by this document: email addresses,
	distinguished names, and arbitrary strings.		distinguished names, and arbitrary strings.
	4.1.1. Email Addresses		2.1.1. Email Addresses
	The email address (grammar token <emailstr>) used must be a valid RFC822		The email address (grammar token <emailstr>) used must be a valid RFC822
	address, which is defined in terms of the two grammar tokens <addr-spec>		address, which is defined in terms of the two grammar tokens <addr-spec>
	and <route-addr>. The grammar for these two tokens is included in the		and <route-addr>. The grammar for these two tokens is included in the
	Appendix as a convenience; the definitive source for these tokens is		Appendix as a convenience; the definitive source for these tokens is
	necessarily RFC822 [1].		necessarily RFC822 [1].
	<emailstr> ::= <addr-spec> / <route-addr>		<emailstr> ::= <addr-spec> / <route-addr>
	; an electronic mail address as defined by		; an electronic mail address as defined by
	; these two tokens from RFC822		; these two tokens from RFC822
	For example, the string "galvin@tis.com" is an email address.		For example, the strings "crocker@tis.com", "galvin@tis.com",
			"murphy@tis.com", and "ned@innosoft.com" are all email addresses.
	4.1.2. Arbitrary Strings		2.1.2. Arbitrary Strings
	The arbitrary string (grammar token <string>) must chosen from the us-		The arbitrary string (grammar token <string>) must have a length of at
	ascii character set and must have a length of at least 1. It is		least 1. There are no other restrictions on the value chosen.
	possible to encode the actual string in such a way that only characters
	from the us-ascii character set are generated, but there is no mechanism
	for conveying to a recipient the encoding that was used.
	<string> ::= ; a non-null sequence of us-ascii characters		<string> ::= ; a non-null sequence of characters
	For example, the string		For example, the string
	Jim "the SAAG mailing list maintainer" Galvin		Jim "the SAAG mailing list maintainer" Galvin
	is an arbitrary string.		is an arbitrary string.
	4.1.3. Distinguished Names		2.1.3. Distinguished Names
	The distinguished name (grammar token <dname>) must be constructed		The distinguished name (grammar token <dnamestr>) must be constructed
	according to the guidelines of the X.500 Directory. For the purposes of		according to the guidelines of the X.500 Directory. The actual syntax
	conveying a distinguished name from an originator to a recipient, it		of the distinguished name is outside the scope of this specification.
	must be ASN.1 encoded and then printably encoded according to the base64		However, RFC1422, for example, specifies syntactic restrictions based on
	encoding defined by MIME.		a particular choice of a certification hierarchy for certificates.
			For the purposes of conveying a distinguished name from an originator to
			a recipient, it must be ASN.1 encoded and then printably encoded
			according to the base64 encoding defined by MIME.
	<dnamestr> ::= <encbin>		<dnamestr> ::= <encbin>
	; a printably encoded, ASN.1 encoded		; a printably encoded, ASN.1 encoded
	; distinguished name		; distinguished name (as defined by the 'Name'
			; production specified in X.501)
	** EXAMPLE DISTINGUISHED NAME **		For example,
	4.2. Identifiers		/Country Name=US
			/State or Province Name=MD
			/Organization Name=Trusted Information Systems
			/Organizational Unit Name=Glenwood
			/Common Name=James M. Galvin/
	There are 6 identifiers specified by this document: email address,		is a distinguished name in a user friendly format (line breaks and
	arbitrary string, distinguished name, PGP key identifier, the public key		leading spaces present only to improve readability). When encoded, it
	itself, and the issuer name and serial number pair from a certificate.		would appear as follows (line breaks present only to improve
	All of these have approximately the same structure as follows:		readability):
	TYPE, KEYID, STRING		MG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEChMbVHJ1c3RlZCBJ
			bmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZDEYMBYGA1UEAxMP
			SmFtZXMgTS4gR2Fsdmlu
			2.2. Identifiers
			There are 5 types of identifiers specified by this document: email
			address identifiers, arbitrary string identifiers, distinguished name
			identifiers, the public keys themselves, and issuer name serial number
			pairs from a certificate. All of these have approximately the same
			structure (except issuer name and serial number which has 'TYPE, STRING,
			KEYSEL' for historical reasons):
			TYPE, KEYSEL, STRING
	The TYPE field is a literal string, one for each of the possible		The TYPE field is a literal string, one for each of the possible
	identifiers.		identifiers.
	The KEYID field is used to distinguish between the multiple public keys		The KEYSEL field is used to distinguish between the multiple public keys
	that may be associated with the name form in the STRING field. In 3 of		that may be associated with the name form in the STRING field. Its
	the identifiers its value is arbitrary, chosen by the owner of the key		value must be distinct from all other KEYSELs assigned by whomever
	pair, except that it must be distinct from all the other KEYIDs used by		assigned this KEYSEL. A suggested value is to use a portion (low-order
	the owner. Suggested values include a portion (low-order 16 or 32 bits)		16 or 32 bits) or all of the actual public key used.
	or all of the actual public key used. In the other 3 identifiers the
	value is still chosen by the owner of the public key and it must still
	be unique, but its value is chosen from a more restricted alphabet.
	The STRING field is the name form and has a different syntax according		The STRING field is the name form and has a different syntax according
	to the value of the TYPE field.		to the value of the TYPE field.
	The identifier used in each of the originator and recipient fields is		The identifier used in each of the originator and recipient fields is
	described by the following grammar. The definition of the key		described by the following grammar. The definition of the key selector
	identifier token is included here since it used by several of the		token is included here since it used by several of the identifiers
	identifiers below.		below.
	<id> ::= <nameid> / <id-publickey> / <id-issuer>
	<nameid> ::= <id-email> / <id-string> / <id-dname> / <id-pgp>		<id> ::= <id-email> / <id-string> / <id-dname>
			/ <id-publickey> / <id-issuer>
	<keyid> ::= <encbin>		<keysel> ::= <encbin>
	; a printably encoded non-null sequence of octets		; a printably encoded non-null sequence of octets
	Each of the identifier name forms is described below.		Each of the identifier name forms is described below.
	4.2.1. Email Address		2.2.1. Email Address
	The email address identifier has the following syntax.		The email address identifier has the following syntax.
	<id-email> ::= "EN" "," <keyid> "," <emailstr> CRLF		<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF
	4.2.2. Arbitrary String		The syntax of the token <emailstr> is defined in Section 2.1.1.
	The arbitrary string identifier has the following syntax.		2.2.2. Arbitrary String
	<id-string> ::= "STR" "," <keyid> "," <string> CRLF		The arbitrary string identifier has the following syntax.
	4.2.3. Distinguished Name		<id-string> ::= "STR" "," <keysel> "," <string> CRLF
	The distinguished name identifier has the following syntax.		The syntax of the token <string> is defined in Section 2.1.2.
	<id-dname> ::= "DN" "," <keyid> "," <dnamestr> CRLF		2.2.3. Distinguished Name
	The actual form and syntax of the distinguished name is outside the		The distinguished name identifier has the following syntax.
	scope of this specification. RFC1422 specifies one possible form based
	on a particular choice of a certification hierarchy for certificates.
	4.2.4. PGP Public Key		<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
	The PGP public key identifier has the following syntax.		The syntax of the token <dnamestr> is defined in Section 2.1.3.
	<id-pgp> ::= "PGP2" ",0x" <pgp-keyid> "," <string> CRLF		2.2.4. Public Key
	<pgp-keyid> ::= ; a sequence from the following alphabet: {0-9, A-F}		The public key identifier has the following syntax.
	; which is either exactly six or eight characters long
	4.2.5. Public Key		<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
	The public key identifier has the following syntax. This identifer, as		<publickey> ::= <encbin>
	compared to the others, has the unique property that the STRING element		; a printably encoded, ASN.1 encoded public key (as
	is optional and, when included, is not a string but rather one of four		; defined by the 'SubjectPublicKeyInfo' production
	of the other identifiers.		; specified in X.509)
	<id-publickey> ::= "PK" "," <publickey> [ "," <nameid> ] CRLF		<id-subset> ::= <id-email> / <id-string> / <id-dname>
	<publickey> ::= <encbin>		The object subjectPublicKeyInfo is imported from the X.500 Directory
	; a printably encoded, ASN.1 encoded		from the certificate object. It is currently the best choice for a
	; subjectPublicKeyInfo		general purpose public key encoding.
	In normal usage, the STRING element is expected to be absent. When		In normal usage, the token <id-subset> is expected to be absent. When
	present, it represents a mechanism by which an identifier (name form and		present, it represents a mechanism by which an identifier (name form and
	key identifier) can be associated with a public key. Recipients of a		key selector) can be associated with a public key. Recipients of a
	public key identifier must take care to verify the accuracy of the		public key identifier must take care to verify the accuracy of the
	purported association. If not, it may be possible for a malicious		purported association. If not, it may be possible for a malicious
	originator to assert an identifier that accords the originator		originator to assert an identifier that accords the originator
	unauthorized privileges. See Section 7.2 for more details.		unauthorized privileges. See Section 5.2 for more details.
	The object subjectPublicKeyInfo is imported from the X.500 Directory
	from the certificate object. It is currently the best choice for a
	general purpose public key encoding.
	4.2.6. Issuer Name and Serial Number		2.2.5. Issuer Name and Serial Number
	The issuer name and serial number identifier has the following syntax.		The issuer name and serial number identifier has the following syntax.
	<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF		<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
	<serial> ::= 1*<hexchar>		<serial> ::= 1*<hexchar>
	; hex dump of the serial number of a certificate		; hex dump of the serial number of a certificate
	The <id-issuer> identifier is included for backward compatibility with		The <id-issuer> identifier is included for backward compatibility (and
	the ID-ASymmetric fields defined in [3]. The older fields are easily		forward compatibility if X.500 Directory certificates become
	converted to this new form by prefixing the old value with "IS," and		ubiquitously available) with the ID-ASymmetric fields defined in [3].
	replacing the field name with an appropriate new ID field.		Its syntax was chosen such that the older fields are easily converted to
			this new form by prefixing the old value with "IS," and replacing the
			field name with an appropriate new ID field name.
	5. Applying PEM Security Services to MIME Body Parts		3. Applying PEM Security Services to MIME Body Parts
	The next section describes the processing steps necessary to prepare a		The next section describes the processing steps necessary to prepare a
	MIME body part for the application of PEM security services. The		MIME body part for the application of PEM security services. The
	succeeding two sections describe the content of the multipart/signed and		succeeding two sections describe the content of the multipart/signed and
	multipart/encrypted body parts resulting from the application of PEM		multipart/encrypted body parts resulting from the application of PEM
	security services to MIME body parts.		security services to MIME body parts.
	5.1. PEM Processing Steps		3.1. PEM Processing Steps
	The definition of the multipart/signed and multipart/encrypted body		The definition of the multipart/signed and multipart/encrypted body
	parts in [7] specifies three steps for creating both body parts.		parts in [7] specifies three steps for creating both body parts.
	(1) The body part is to be protected is created according to a local		(1) The body part to be protected is created according to a local
	convention.		convention.
	(2) The body part is prepared for protection according to the protocol		(2) The body part is prepared for protection according to the protocol
	parameter.		parameter.
	(3) The prepared body part is protected according to the protocol		(3) The prepared body part is protected according to the protocol
	parameter.		parameter.
	This specification makes no changes to step one in the sequence. For		This specification makes no changes to step one in the sequence. For
	step two, there is no preparation necessary for the encryption service.		step two, there is no preparation necessary for the encryption service.
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 43 ¶
	calculate the digital signature; the originator needs to be able to		calculate the digital signature; the originator needs to be able to
	include the digital signature value when transferring the body part,		include the digital signature value when transferring the body part,
	while the recipient needs to be able to compare a re-computed value with		while the recipient needs to be able to compare a re-computed value with
	the received value. Further, the canonical form should satisfy the		the received value. Further, the canonical form should satisfy the
	property that it is representable on as many different host computers as		property that it is representable on as many different host computers as
	possible. By satisfying this property, signed data may be forwarded by		possible. By satisfying this property, signed data may be forwarded by
	recipients to additional recipients, who will also be able to verify the		recipients to additional recipients, who will also be able to verify the
	original signature. This service is called forwardable authentication.		original signature. This service is called forwardable authentication.
	The canonicalization transformation is a two step process. First, the		The canonicalization transformation is a two step process. First, the
	body part must be converted to canonical representation suitable for		body part must be converted to a form that is uniquely and unambiguously
	transport between originators and recipients. Second, the body part		representable on as many different host computers as possible. Second,
	must have its line delimiters canonicalized prior to computing the		the body part must have its line delimiters converted to a unique and
	digital signature and prior to each verification of the digital		unambigous representation prior to computing the digital signature and
	signature.		prior to each verification of the digital signature.
	The canonical representation of all body parts is specified to be 7bit,		The representation of all body parts in the first step is specified to
	as defined by [2]. Since the headers of body parts are already required		be 7bit, as defined by [2]. Since the headers of body parts are already
	to be representable in 7bit, this step requires that if the data to be		required to be representable in 7bit, this step requires that if the
	signed is not already 7bit it must be encoded with an appropriate MIME		data to be signed is not already 7bit then it must be encoded with an
	content transfer encoding. Note, since the MIME standard explicitly		appropriate MIME content transfer encoding. Note: since the MIME
	disallows nested content transfer encodings, i.e., the content types		standard explicitly disallows nested content transfer encodings, i.e.,
	multipart and message may not themselves be encoded, body parts enclosed		the content types multipart and message may not themselves be encoded,
	within, for example, a multipart content type, must be encoded in a 7bit		body parts enclosed within, for example, a multipart content type must
	representation. Any valid MIME encoding may be selected.		be encoded in a 7bit representation. Any valid MIME encoding may be
			selected for encoding the content of each of the non-7bit body parts.
	The 7bit representation of the data must be transferred to the		As may be required by MIME, an appropriate Content-Transfer-Encoding:
	recipient. As may be required by MIME, an appropriate Content-		header is added and included with the data to be signed. Upon receipt,
	Transfer-Encoding: header is included with the data. Upon receipt, a		a MIME implementation would verify the signature of the data prior to
	MIME implementation would verify the signature of the data prior to
	decoding the data and displaying it to the recipient.		decoding the data and displaying it to the recipient.
	Representing all complex content types as 7bit transforms them into		Representing all complex content types as 7bit transforms them into
	text-based content types. However, text-based content types present a		text-based content types. However, text-based content types present a
	unique problem. In particular, the line delimiter used on a text-based		unique problem. In particular, the line delimiter used for a text-based
	content type is specific to a local environment; different environments		content type is specific to a local environment; different environments
	use the single character carriage-return (<CR>), the single character		use the single character carriage-return (<CR>), the single character
	line-feed (<LF>), or the two character sequence "carriage-return line-		line-feed (<LF>), or the two character sequence "carriage-return line-
	feed (<CR><LF>)."		feed (<CR><LF>)".
	The application of the digital signature service requires that the same		The application of the digital signature service requires that the same
	line delimiter be used by both the originator and the recipient. This		line delimiter be used by both the originator and the recipient. This
	document specifies that the two character sequence "<CR><LF>" must be		document specifies that the two character sequence "<CR><LF>" must be
	used as the line delimiter. Thus, the canonicalization transformation		used as the line delimiter. Thus, the second step of the
	includes the transformation of the local line delimiter to the two		canonicalization transformation includes the conversion of the local
	character sequence "<CR><LF>".		line delimiter to the two character sequence "<CR><LF>".
	The transformation to the canonical line delimiter is only required for		The conversion to the canonical line delimiter is only required for the
	the purposes of computing the digital signature. Thus, originators must		purposes of computing the digital signature. Thus, originators must
	apply the canonical line delimiter transformation before computing the		apply the line delimiter conversion before computing the digital
	digital signature but must transfer the data without the canonical line		signature but must transfer the data without the line delimiter
	delimiter transformation. Similarly, recipients must apply the		conversion. Similarly, recipients must apply the line delimiter
	canonical line delimiter transformation before computing the digital		conversion before computing the digital signature.
	signature.
	NOTE: An originator can not transfer the content with the		NOTE: An originator can not transfer the content with the line
	canonical line delimiter transformation intact because the		delimiter conversion intact because the conversion process is
	transformation process is not idempotent. In particular, SMTP		not idempotent. In particular, SMTP servers may themselves
	servers may themselves convert the canonical line delimiter to a		convert the line delimiter to a local line delimiter, prior to
	local line delimiter, prior to the message being delivered to		the message being delivered to the user. Thus, a recipient has
	the user. Thus, a recipient has no way of knowing if the		no way of knowing if the conversion is present or not. Thus, if
	transformation is present or not. Thus, if the recipient		the recipient applies the conversion to a content in which it is
	applies the transformation to a content in which it is already		already present, the resulting content may have two line
	present, the resulting content may have two line delimiters		delimiters present, which would cause the verification of the
	present, which would cause the verification of the signature to		signature to fail.
	fail.
	IMPLEMENTORS NOTE: Implementors should be aware that the		IMPLEMENTORS NOTE: Implementors should be aware that the
	transformation to a canonical representation is a function that		conversion to a 7bit representation is a function that is
	is available even in a minimally compliant MIME user agent.		available in a minimally compliant MIME user agent. Further,
	Further, the canonical line delimiter transformation required		the line delimiter conversion required here is distinct from the
	here is distinct from the same transformation included in that		same conversion included in that function. Specifically, the
	function. Specifically, the line delimiter transformation in		line delimiter conversion applied when a body part is converted
	the former case is performed prior to the application of the		to a 7bit representation is performed prior to application of
	canonical representation while it is performed after the		the transfer encoding. The line delimiter conversion applied
	application of the canonical representation in the latter case.		when a body part is signed is performed after the body is
			converted to 7bit.
	5.2. Use of multipart/signed Content Type		3.2. Use of multipart/signed Content Type
	When this content type is used, the value of the required parameter		Using this content type requires the specification of a control
	"protocol" is "pem" and the value of the required parameter "hashalg" is		information content type, the label of which is used as the value for
	one of the valid choices from [5], for example:		the required protocol parameter. Section 3.4 defines the control
			information content type of application/pem-signature. The value of the
			required parameter "protocol" is "application/pem-signature" and the
			value of the required parameter "micalg" is one of the valid choices
			from [5], for example:
	Content-Type: multipart/signed; protocol="pem"; hashalg="md5";		Content-Type: multipart/signed; protocol="application/pem-signature";
	boundary="Signed Message"		micalg="rsa-md5"; boundary="Signed Message"
	--Signed Message		--Signed Message
	Content-Type: text/plain		Content-Type: text/plain
	This is some example text.		This is some example text.
	--Signed Message		--Signed Message
	Content-Type: application/signature		Content-Type: application/pem-signature
	<pemsig>		SIGNATURE INFORMATION
	--Signed Message--		--Signed Message--
			where SIGNATURE INFORMATION is descriptive of the content that would
			appear in a real body part.
			3.3. Use of multipart/encrypted Content Type
			Using this content type requires the specification of a control
			information content type, the label of which is used as the value for
			the required protocol parameter. Section 3.5 defines the control
			information content type of application/pem-keys. The value of the
			required parameter "protocol" is "application/pem-keys", for example:
			Content-Type: multipart/encrypted; protocol="application/pem-keys";
			boundary="Encrypted Message"
			--Encrypted Message
			Content-Type: application/pem-keys
			KEY DATA
			--Encrypted Message
			Content-Type: application/octet-stream
			ENCRYPTED DATA WOULD BE HERE
			--Encrypted Message--
			3.4. application/pem-signature Content Type Definition
			(1) MIME type name: application
			(2) MIME subtype name: pem-signature
			(3) Required parameters: none
			(4) Optional parameters: none
			(5) Encoding considerations: quoted-printable is always sufficient
			(6) Security considerations: none
			This content type is used on the second body part of an enclosing
			multipart/signed when the protocol used is PEM. It is comprised of the
			digital signature of the data, which is the first body part of the
			enclosing multipart/signed, and the information required to verify that
			signature. The label application/pem-signature is used as the value of
			the protocol parameter of the enclosing multipart/signed. It is an
			error for the protocol parameter to be missing from the enclosing
			multipart/signed body part or for its value to be different from
			application/pem-signature when this body part is used.
			Included in the signature verification information will be the Message
			Integrity Check (MIC) algorithm used during the signature creation
			process. The MIC algorithm identified in this body part must match the
			MIC algorithm identified in the micalg parameter of the enclosing
			multipart/signed. If it does not, a user agent should identify the
			discrepancy to a user and may choose to either halt or continue
			processing, giving precedence to the algorithm identified in this body
			part.
			An application/pem-signature body part is constructed as follows:
			Content-Type: application/pem-signature
			<pemsig>
	where the <pemsig> token is defined as follows.		where the <pemsig> token is defined as follows.
	<pemsig> ::= <version> ( 1*<origasymflds> )		<pemsig> ::= <version> ( 1*<origasymflds> )
	<version> ::= "Version:" "5" CRLF		<version> ::= "Version:" "5" CRLF
	<origasymflds> ::= <origid> <micinfo>		<origasymflds> ::= <origid> <micinfo>
	<origid> ::= "Originator-ID:" <id> CRLF		<origid> ::= "Originator-ID:" <id> CRLF
	The token <id> is defined in Section 4.2.		The token <id> is defined in Section 2.2.
	The only valid value for a Content-Transfer-Encoding: header, if		3.5. application/pem-keys Content Type Definition
	included, is "7bit".
	5.3. Use of multipart/encrypted Content Type		(1) MIME type name: application
	When this content type is used, the value of the required parameter		(2) MIME subtype name: pem-keys
	"protocol" is "pem", for example:
	Content-Type: multipart/encrypted; protocol="pem";		(3) Required parameters: none
	boundary="Encrypted Message"
	--Encrypted Message		(4) Optional parameters: none
	Content-Type: application/keys
	<pemkeys>		(5) Encoding considerations: quoted-printable is always sufficient
	--Encrypted Message		(6) Security considerations: none
	Content-Type: application/octet-stream		This content type is used on the first body part of an enclosing
			multipart/encrypted. It is comprised of the data encryption key used to
			encrypt the data, located in the second body part of the enclosing
			multipart/encrypted, and the information required to perform the
			decryption. The label application/pem-keys is used as the value of the
			protocol parameter of the enclosing multipart/encrypted. It is an error
			for the protocol parameter to be missing in the enclosing
			multipart/encrypted body part or for its value to be different from
			application/pem-keys when this body part is used.
	<encrypted data>		An application/pem-keys body part is constructed as follows:
	--Encrypted Message--
			Content-Type: application/pem-keys
			<pemkeys>
	where the <pemkeys> token is defined as follows.		where the <pemkeys> token is defined as follows.
	<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>		<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
	<version> ::= "Version:" "5" CRLF		<version> ::= "Version:" "5" CRLF
	<recipasymflds> ::= <recipid> <asymkeyinfo>		<recipasymflds> ::= <recipid> <asymkeyinfo>
	<recipid> ::= "Recipient-ID:" <id> CRLF		<recipid> ::= "Recipient-ID:" <id> CRLF
	<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF		<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
	The token <id> is defined in Section 4.2.		The token <id> is defined in Section 2.2.
	6. Removing PEM Security Services from PEM Body Parts		4. Removing PEM Security Services from PEM Body Parts
	This section describes the processing steps necessary to verify or		This section describes the processing steps necessary to verify or
	decrypt the PEM security services that have been applied to MIME body		decrypt the PEM security services that have been applied to MIME body
	parts. Outer layers of PEM security services must be processed prior to		parts. Outer layers of PEM security services must be processed prior to
	processing inner layers of PEM security services. Processing includes a		processing inner layers of PEM security services. Processing includes a
	user choosing to display a content without removing the PEM security		user choosing to display a content without removing the PEM security
	services.		services.
	The definition of the multipart/signed and multipart/encrypted body		The definition of the multipart/signed and multipart/encrypted body
	parts in [7] specifies three steps for receiving both body parts.		parts in [7] specifies three steps for receiving both body parts.
	skipping to change at page 13, line 19 ¶		skipping to change at page 15, line 22 ¶
	the user and processing continues with the unprotected body part,		the user and processing continues with the unprotected body part,
	as returned by the protection removal process.		as returned by the protection removal process.
	For step one, the preparation for digitally signed and encrypted body		For step one, the preparation for digitally signed and encrypted body
	parts is different, as described below. No changes are required to		parts is different, as described below. No changes are required to
	steps two and three in the sequence.		steps two and three in the sequence.
	For multipart/signed body parts, the control information is prepared by		For multipart/signed body parts, the control information is prepared by
	removing any content transfer encodings that may be present. The		removing any content transfer encodings that may be present. The
	digitally signed body part is prepared by leaving the content transfer		digitally signed body part is prepared by leaving the content transfer
	encodings intact and canonicalizing the line delimiters according to		encodings intact and converting the line delimiters according to Step 2
	Step 2 of Section 5.1.		of Section 3.1.
	Multipart/encrypted body parts are prepared by removing the content		Multipart/encrypted body parts are prepared by removing the content
	transfer encodings, if present, from both the control information and		transfer encodings, if present, from both the control information and
	the encrypted body part.		the encrypted body part.
	7. Definition of New Content Types		5. Key Management Content Types
	This document defines two new content types, the contents of which
	comprise a replacement mechanism for [6]. The first content type is
	application/key-request, which replaces the certification and CRL-
	retrieval request messages. The second content type is
	application/key-data, which replaces the certification reply message,
	the 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, which were previously
	undefined.
	NOTE: RFC1424 has some descriptive text, especially for		This document defines two key management content types, the contents of
	certification messages, that should probably be included.		which comprise a replacement mechanism for those defined in [6]. The
			first content type is application/pemkey-request, which replaces the
			certification and CRL-retrieval request messages. The second content
			type is application/pemkey-data, which replaces the certification reply
			message, the crl-storage request message, and the crl-retrieval reply
			message. There are 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, which
			were previously undefined.
	7.1. application/key-request Content Type Definition		5.1. application/pemkey-request Content Type Definition
	(1) MIME type name: application		(1) MIME type name: application
	(2) MIME subtype name: key-request		(2) MIME subtype name: pemkey-request
	(3) Required parameters: none
			(3) Required parameters: none
	(4) Optional parameters: none		(4) Optional parameters: none
	(5) Encoding considerations: quoted-printable is always sufficient		(5) Encoding considerations: quoted-printable is always sufficient
	(6) Security Considerations: none		(6) Security Considerations: none
	The content of this body part corresponds to the following production.		The content of this body part corresponds to the following production.
	<request> ::= <version>		<request> ::= <version>
	( <subject> / <issuer> / <certification> )		( <subject> / <issuer> / <certification> )
	<version> ::= "Version:" "5" CRLF		<version> ::= "Version:" "5" CRLF
	<subject> ::= "Subject:" <id> CRLF		<subject> ::= "Subject:" <id> CRLF
	<issuer> ::= "Issuer:" <id> CRLF		<issuer> ::= "Issuer:" <id> CRLF
	<certification> ::= "Certification:" <encbin> CRLF		<certification> ::= "Certification:" <encbin> CRLF
	This content type is used to provide for some of the requests described		This content type is used to provide for some of the request messages
	in [6]. The information in the body part is entirely independent of any		described in [6]. The information in the body part is entirely
	other body part. As such, the application/key-request content type is		independent of any other body part. As such, the application/pemkey-
	an independent body part.		request content type is an independent body part.
	The certification request, certificate-retrieval request and crl-		The certification request, certificate-retrieval request and crl-
	retrieval request are provided for directly. If the content contains a		retrieval request are provided for directly. If the content contains a
	Certification: field it requests certification of the self-signed		Certification: field it requests certification of the self-signed
	certificate in the field value. If the content contains an Issuer:		certificate in the field value. If the content contains an Issuer:
	field it requests the certificate revocation list chain beginning with		field it requests the Certificate Revocation List (CRL) chain beginning
	the issuer identified in the field value. If the content contains a		with the CRL of the issuer identified in the field value. If the
	Subject: field it requests either the public key of the subject or the		content contains a Subject: field it requests either the public key of
	certificate chain beginning with the subject identified in the field		the subject or a certificate chain beginning with the subject identified
	value, or both.		in the field value, or both if both exist.
	The Subject: and Issuer: fields each contain a value of type <id>, which		The Subject: and Issuer: fields each contain a value of type <id>, which
	is defined in Section 4.2.		is defined in Section 2.2.
	The crl-storage request is provided for by the application/key-data		The crl-storage request is provided for by the application/pemkey-data
	content type described in the next section.		content type described in the Section 5.2.
	In each case, the response is transmitted in an application/key-data		In each case, the response is transmitted in an application/pemkey-data
	content type. When returning public keys, certificate chains, and		content type. When returning public keys, certificate chains, and
	certificate revocation list chains, if there exists more than one,		certificate revocation list chains, if there exists more than one,
	several application/key-data contents are to be returned in the reply		several application/pemkey-data body parts are to be returned in the
	message, one for each.		reply message, one for each.
	7.2. application/key-data Content Type Definition		5.2. application/pemkey-data Content Type Definition
	The principal objective of this content type is to convey cryptographic		The principal objective of this content type is to convey cryptographic
	keying material from an originator to a recipient. However, no explicit		keying material from a source to a destination. However, no explicit
	provision is made for determining the authenticity or accuracy of the		provision is made for determining the authenticity or accuracy of the
	data being conveyed. In particular, when a public key and the		data being conveyed. In particular, when a public key and its
	identifier for its owner is conveyed, there is nothing to prevent an		identifier is conveyed, there is nothing to prevent the source or an
	originator or any interloper along the path from an originator to a		interloper along the path from the source to the destination from
	recipient from substituting alternate values for either the public key		substituting alternate values for either the public key or the
	or the identifier, thus setting up the recipient to potentially send		identifier, thus setting up the destination such that when the data is
	sensitive information that may be intercepted and disclosed		used sensitive information may be intercepted and disclosed
	inappropriately.		inappropriately.
	It is incumbent upon a recipient to verify the authenticity and accuracy		It is incumbent upon a recipient to verify the authenticity and accuracy
	of the data received prior to its use. The problem is addressed by the		of the data received prior to its use. The problem is addressed by the
	use of certificates, since a certification hierarchy is a well-defined		use of certificates, since a certification hierarchy is a well-defined
	mechanism that conveniently supports the automatic verification of the		mechanism that conveniently supports the automatic verification of the
	data. Alternatively, the application/key-data body part could be		data. Alternatively, the application/key-data body part could be
	digitally signed by the originator. In this way, if a recipient		digitally signed by the source. In this way, if the destination
	believes that correct originator's public key is available locally and		believes that a correct source's public key is available locally and if
	if the recipient believes the originator would convey accurate data,		the destination believes the source would convey accurate data, then the
	then the key data received from the originator can be believed.		key data received from the source can be believed.
	NOTE: Insofar as a certificate represents a mechanism by which		NOTE: Insofar as a certificate represents a mechanism by which a
	an issuer vouches for the binding between the name and public		third party vouches for the binding between a name and a public
	key it embodies, the signing of an application/key-data body		key, the signing of an application/pemkey-data body part is a
	part is a similar mechanism.		similar mechanism.
	(1) MIME type name: application		(1) MIME type name: application
	(2) MIME subtype name: key-data		(2) MIME subtype name: pemkey-data
	(3) Required parameters: none		(3) Required parameters: none
	(4) Optional parameters: none		(4) Optional parameters: none
	(5) Encoding considerations: quoted-printable is always sufficient.		(5) Encoding considerations: quoted-printable is always sufficient.
	(6) Security Considerations: none		(6) Security Considerations: none
	The content of this body part corresponds to the following production.		The content of this body part corresponds to the following production.
	<certdata> ::= <version>		<keydata> ::= <version>
	( <keydata> / <certchain> / <crlchain> )		( <publickeydata> / <certchain> / <crlchain> )
	<version> ::= "Version:" "5" CRLF		<version> ::= "Version:" "5" CRLF
	<keydata> ::= "Key:" <id> "," <nameid> CRLF		<publickeydata> ::= "Key:" "PK" "," <publickey> "," <id-subset> CRLF
	<certchain> ::= <cert> *( [ <crl> ] <cert> )		<certchain> ::= <cert> *( [ <crl> ] <cert> )
	<crlchain> ::= 1*( <crl> [ <cert> ] )		<crlchain> ::= 1*( <crl> [ <cert> ] )
	<cert> ::= "Certificate:" <encbin> CRLF		<cert> ::= "Certificate:" <encbin> CRLF
	<crl> ::= "CRL:" <encbin> CRLF		<crl> ::= "CRL:" <encbin> CRLF
	This content type is used to transfer public keys, certificate chains,		This content type is used to transfer public keys, certificate chains,
	or Certificate Revocation List (CRL) chains. The information in the		or Certificate Revocation List (CRL) chains. The information in the
	body part is entirely independent of any other body part. (Note that		body part is entirely independent of any other body part. (Note that
	the converse is not true: the validity of a protected body part cannot		the converse is not true: the validity of a protected body part cannot
	be determined without the proper public keys, certificates, or current		be determined without the proper public keys, certificates, or current
	CRL information.) As such, the application/key-data content type is an		CRL information.) As such, the application/pemkey-data content type is
	independent body part.		an independent body part.
	The <keydata> production contains exactly one public key. It is used to		The <publickeydata> production contains exactly one public key. It is
	bind a public key with its corresponding name form and key identifier.		used to bind a public key with its corresponding name form and key
	It is recommended that when responders are returning this information		selector. It is recommended that when responders are returning this
	that the enclosing body part be digitally signed by the responder in		information that the enclosing body part be digitally signed by the
	order to protect the information.		responder in order to protect the information. The <id-subset> token is
			defined in Section 2.2.4.
	The <certchain> production contains one certificate chain. A		The <certchain> production contains one certificate chain. A
	certificate chain starts with a certificate and continues with the		certificate chain starts with a certificate and continues with the
	certificates of subsequent issuers. Each issuer certificate included		certificates of subsequent issuers. Each issuer certificate included
	must have issued the preceding certificate. For each issuer, a CRL may		must have issued the preceding certificate. For each issuer, a CRL may
	be supplied. A CRL in the chain belongs to the immediately following		be supplied. A CRL in the chain belongs to the immediately following
	issuer. Therefore, it potentially contains the immediately preceding		issuer. Therefore, it potentially contains the immediately preceding
	certificate.		certificate.
	The <crlchain> production contains one certificate revocation list		The <crlchain> production contains one certificate revocation list
	chain. The CRLs in the chain begin with the requested CRL and continue		chain. The CRLs in the chain begin with the requested CRL and continue
	with the CRLs of subsequent issuers. The issuer of each CRL is presumed		with the CRLs of subsequent issuers. The issuer of each CRL is presumed
	to have issued a certificate for the issuer of the preceding CRL. For		to have issued a certificate for the issuer of the preceding CRL. For
	each CRL, the issuer's certificate may be supplied. A certificate in		each CRL, the issuer's certificate may be supplied. A certificate in
	the chain must belong to the issuer of the immediately preceding CRL.		the chain must belong to the issuer of the immediately preceding CRL.
	The relationship between a certificate and an immediately preceding CRL		The relationship between a certificate and an immediately preceding CRL
	is the same in both <certchain> and <crlchain>. In a <certchain> the		is the same in both <certchain> and <crlchain>. In a <certchain> the
	CRLs are optional. In a <crlchain> the certificates are optional.		CRLs are optional. In a <crlchain> the certificates are optional.
	8. Examples		6. Examples
	NOTE: To be included upon completion of implementation.		Given the following email message prepared for submission:
	9. Observations		To: Ned Freed <ned@innosoft.com>
			Subject: Hi Ned!
	The use of the pre-submission and post-delivery algorithms to combine		How do you like the new MIME/PEM?
	PEM and MIME capabilities exhibits several properties:
			Jim
			When the text of the message is signed, it will look like this (note the
			use of the public key identifier with the included email name
			identifier):
			To: Ned Freed <ned@innosoft.com>
			Subject: Hi Ned!
			MIME-Version: 1.0
			Content-Type: multipart/signed; protocol="application/pem-signature";
			micalg="rsa-md5"; boundary="Signed Boundary"
			--Signed Boundary
			Content-Type: text/plain; charset="us-ascii"
			Content-ID: <21436.785186814.2@tis.com>
			How do you like the new MIME/PEM?
			Jim
			--Signed Boundary
			Content-Type: application/pem-signature
			Content-ID: <21436.785186814.1@tis.com>
			Content-Transfer-Encoding: quoted-printable
			Version: 5
			Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B=
			ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g=
			G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com
			MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERfMZXUKzFsHbmK=
			tIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfbsOVJjleV7vTe9yoNp2P8mi/h=
			s7
			--Signed Boundary--
			If, instead, we choose to protect the headers with the text, it will
			look like this:
			To: Ned Freed <ned@innosoft.com>
			Subject: Hi Ned!
			MIME-Version: 1.0
			Content-Type: multipart/signed; protocol="application/pem-signature";
			micalg="rsa-md5"; boundary="Signed Boundary"
			--Signed Boundary
			Content-Type: message/rfc822
			Content-ID: <21468.785187044.2@tis.com>
			To: Ned Freed <ned@innosoft.com>
			Subject: Hi Ned!
			How do you like the new MIME/PEM?
			Jim
			--Signed Boundary
			Content-Type: application/pem-signature
			Content-ID: <21468.785187044.1@tis.com>
			Content-Transfer-Encoding: quoted-printable
			Version: 5
			Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1fO6B=
			ekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghGdhn0Lw8g=
			G67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com
			MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WTwjfxFBvAceVW=
			fawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4Gd8dBBwMKvqMKTHAUxGXYxwNd=
			bK
			--Signed Boundary--
			If we choose to encrypt the text of the following message, that is,
			encrypt the lines marked with asterick (*):
			To: Jim Galvin <galvin@tis.com>
			Subject: an encrypted message
			* How do you like the new MIME/PEM?
			*
			* Jim
			the message would look as follows (note the use of the email name
			identifier):
			To: Jim Galvin <galvin@tis.com>
			Subject: an encrypted message
			MIME-Version: 1.0
			Content-Type: multipart/encrypted; protocol="application/pem-keys";
			boundary="Encrypted Boundary"
			--Encrypted Boundary
			Content-Type: application/pem-keys
			Content-ID: <21535.785187667.1@tis.com>
			Content-Transfer-Encoding: quoted-printable
			Version: 5
			DEK-Info: DES-CBC,D488AAAE271C8159
			Recipient-ID: EN,2,galvin@tis.com
			Key-Info: RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/7NvSqqXSK/WZ=
			q05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT9P6jyzcV1NzZVwfp+u
			--Encrypted Boundary
			Content-Type: application/octet-stream
			Content-Transfer-Encoding: base64
			AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynUd4jcJgRnQIQvIx
			m2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4wonUUP265UvvMj23RSTguZ/nl/Oxn
			FM6SzDgV39V/i/RofqI=
			--Encrypted Boundary--
			If, instead, we choose to sign the text before we encrypt it, the
			structure would be as follows (where lines with an asterick '*' are
			digitally signed and lines with an ampersand '&' are encrypted):
			Content-Type: multipart/encrypted; boundary="Encrypted Boundary"
			--Encrypted Boundary
			Content-Type: application/pem-keys
			KEY INFORMATION
			--Encrypted Boundary
			Content-Type: application/octet-stream
			& Content-Type: multipart/signed; boundary="Signed Boundary"
			&
			& --Signed Boundary
			& * Content-Type: text/plain
			& *
			& * How do you like the new MIME/PEM?
			& *
			& * Jim
			&
			& --Signed Boundary
			& Content-Type: application/pem-signature
			&
			& SIGNATURE INFORMATION
			&
			& --Signed Boundary--
			--Encrypted Boundary--
			where KEY INFORMATION and SIGNATURE INFORMATION are descriptive of the
			actual content that would appear in a real body part. The actual
			message would be like this:
			To: Jim Galvin <galvin@tis.com>
			Subject: an encrypted message
			MIME-Version: 1.0
			Content-Type: multipart/encrypted; protocol="application/pem-keys";
			boundary="Encrypted Boundary"
			--Encrypted Boundary
			Content-Type: application/pem-keys
			Content-ID: <21546.785188458.1@tis.com>
			Content-Transfer-Encoding: quoted-printable
			Version: 5
			DEK-Info: DES-CBC,11CC89F8D90F1DFE
			Recipient-ID: EN,2,galvin@tis.com
			Key-Info: RSA,AZTtlEc6xm0vjkvtVUITUh7sz+nOuOwP0tsym6CQozD9IwVIJzY8+vIfbh5B=
			pR0kS6prq3EGFBFR8gRMUvbgHtEKPD/4ICQ7b6ssZ7FmKhl/cJC5rVjpb4EOUlwOXwRZ
			--Encrypted Boundary
			Content-Type: application/octet-stream
			Content-Transfer-Encoding: base64
			ZvWvtosDzRBXJzkDFFRb9Qjrgm2nDWg3zotJ3ZpExpWUG/aRJ7Vwd+PWkSfrDPJ52V/wkxwMrum6
			xJHZonrtyd0AvaztvriMm2zXTefzwpGG1i5zK47PBqreLA3HDTK2U6B13vzpE8wMSVefzaCTSpXR
			SCh08ceVEZrIYS53/CKZV2/Sga71pGNlux8MsJpYLwdj5Q3NKocg1LMngMo8yrMAe+avMjfOnhui
			49Xon1Gft+N5XDH/+wI9qxI9fkQvNZVDlWIhCYEkxd5ke549tLkJjEqHQbgJW5C+K/uxdiD2dBt+
			nRCXcuO0Px3yKRyYg/9BgTf36padSHuv48xBg5YaqaEWpEzLI0Qd31vAyP23rqiPhfBn6sjhQ2Kr
			WhiF2l3TV8kQsIGHHZUkaUbqkXJe6PEdWWhwsqCFPDdkpjzQRrTuJH6xleNUFg+CG1V+tL4IgMjQ
			qm3KVojRXx8bG2auVN89NfwFswmoq4fXTrh3xyVS1VgxjKkcYI8SVVmkYjCxVviJP3zO2UzBvCoM
			fADtBVBz1njYETtVGDO97uT39MqL85uEgiF4E5TkOj/m04+88G0/vvN/RISKJiFQJ3FyVIB/ShX9
			Dixl8WCx3rxwN5g2QFLiyQVulzuNhimSD4ZxEo7smcTsAXUjwSLRtdjmTTutw2GmFESUaIrY81Nc
			pQJRPNAvF0IkN6ddwL4qvzUS99vjQp15g9FUv82lHtHwhM18a9GokVG8xYOjBBsn9anp9abh4Tp/
			c/vpbunQUqnpV29rF4wj+8OwUOMi9ymGabBXAjw7DhNH2RdRVr1upQO896OX81VWB0LsA0cp+ymx
			hTrEI+wCHcrsNMoRK/7zAeuAi0f1t9bN594EFlLoIrBnKEa1/OUAhMT7kG1fNkSRnc8BZswIoPyR
			etsTurQfD40nsVHvNwE9Jz7wbBo00gd6blPADOUYFxfW5zu6ubygBqJiKPM4II2fCdNj7CptfQco
			RTeguKMVPLVmFg/EINuWBFm10GqlYT7p4zhfzysV/3r5LVZ1E8armTCRJ2GoYG5h+SKcytaQ0IT8
			S2nLPCZl1hzdajsrqHFe8omQ
			--Encrypted Boundary--
			In addition to text, the PEM services as defined here will protect
			arbitrary body parts, for example, the following audio body part:
			Content-Type: audio/basic
			AUDIO DATA HERE
			when signed would appear as follows:
			Content-Type: multipart/signed; protocol="application/pem-signature";
			micalg="rsa-md5"; boundary="Signed Boundary"
			--Signed Boundary
			Content-Type: audio/basic
			Content-Transfer-Encoding: base64
			base64(AUDIO DATA HERE)
			--Signed Boundary
			Content-Type: application/pem-signature
			SIGNATURE INFORMATION HERE
			and when encrypted would appear as follows:
			Content-Type: multipart/encrypted; protocol="application/pem-keys";
			boundary="Encrypted Boundary"
			--Encrypted Boundary
			Content-Type: application/pem-keys
			KEY INFORMATION HERE
			--Encrypted Boundary
			Content-Type: application/octet-stream
			Content-Transfer-Encoding: base64
			base64(encrypted(AUDIO DATA HERE))
			--Encrypted Boundary--
			7. Observations
			The use of the pre-submission and post-delivery processing steps to
			combine PEM and MIME capabilities exhibits several properties:
	(1) It allows privacy-enhancement of an arbitrary content, not just the		(1) It allows privacy-enhancement of an arbitrary content, not just the
	body of an RFC822 message.		body of an RFC822 message.
	(2) For a multipart or message content, it allows the user to specify		(2) For a multipart or message content, it allows the user to specify
	different privacy enhancements to be applied to different		different privacy enhancements to be applied to different
	components of the structure of the content.		components of the structure of the content.
	(3) It provides for messages containing several privacy enhanced		(3) It provides for messages containing several privacy enhanced
	contents, thereby removing the requirement for PEM software to be		contents, thereby removing the requirement for PEM software to be
	able to generate or interpret a single content which intermixes		able to generate or interpret a single content which intermixes
	both unenhanced and enhanced components.		both unenhanced and enhanced components.
	The use of a MIME-capable user agent makes complex nesting of enhanced		The use of a MIME-capable user agent makes complex nesting of enhanced
	message body parts much easier. For example, the user can separately		message body parts much easier. For example, the user can separately
	sign and encrypt a message. This motivates a complete separation of the		sign and encrypt a message. This motivates a complete separation of the
	confidentiality security service from the digital signature security		confidentiality security service from the digital signature security
	service. That is, different key pairs could be used for the different		service. That is, different key pairs could be used for the different
	services and could be protected separately. This means an employee's		services and could be protected separately.
	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		This is useful for at least two reasons. First, some public key
	certificates for each user.		algorithms do not support both digital signatures and encryption, for
			example, the way that the RSA algorithm does; two key pairs would be
			required in this case. Second, 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.
	10. Summary of Changes to PEM Specification		8. Summary of Changes to PEM Specification
	This document updates the message encryption and signature procedures		This document updates the message encryption and signature procedures
	defined by [3] and obsoletes the key certification and related services		defined by [3] and replaces the key certification and related services
	defined by [6]. The changes are enumerated below.		defined by [6]. The changes are enumerated below.
	(1) The PEM specification currently requires that encryption services		(1) The PEM specification currently requires that encryption services
	be applied only to message bodies that have been signed. By		be applied only to message bodies that have been signed. By
	providing for each of the services separately, they may be applied		providing for each of the services separately, they may be applied
	recursively in any order according to the needs of the requesting		recursively in any order according to the needs of the requesting
	application.		application.
	(2) PEM implementations are currently restricted to processing only		(2) PEM implementations are currently restricted to processing only
	text-based electronic mail messages. In fact, the message text is		text-based electronic mail messages. In fact, the message text is
	skipping to change at page 18, line 37 ¶		skipping to change at page 26, line 30 ¶
	MIME Content-Type: headers.		MIME Content-Type: headers.
	(6) The PEM specifications include a document that defines new types of		(6) The PEM specifications include a document that defines new types of
	PEM messages, specified by unique values used in the Proc-Type:		PEM messages, specified by unique values used in the Proc-Type:
	header, to be used to request certificate and certificate		header, to be used to request certificate and certificate
	revocation list information. This functionality is subsumed by two		revocation list information. This functionality is subsumed by two
	new content types specified in this document.		new content types specified in this document.
	(7) The header fields having to do with certificates (Originator-		(7) The header fields having to do with certificates (Originator-
	Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated		Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated
	for use only in the application/key-data and application/key-		for use only in the application/pemkey-data and
	request content types and are no longer allowed in the header		application/pemkey-request content types and are no longer allowed
	portion of a PEM signed or encrypted message.		in the header portion of a PEM signed or encrypted message.
	(8) The grammar specified here explicitly separates the header fields		(8) The grammar specified here explicitly separates the header fields
	that may appear for the encryption and signature security services.		that may appear for the encryption and signature security services.
	It is the intent of this document to specify a precise expression		It is the intent of this document to specify a precise expression
	of the allowed header fields; there is no intent to reduce the		of the allowed header fields; there is no intent to disallow the
	functionality of combinations of encryption and signature security		functionality of combinations of encryption and signature security
	from those of [3].		found in [3].
	(9) With the separation of the encryption and signature security		(9) With the separation of the encryption and signature security
	services, there is no need for a MIC-Info: field in the headers		services, there is no need for a MIC-Info: field in the headers
	associated with an encrypted message.		associated with an encrypted message.
	(10) In [3], when asymmetric key management is used, an Originator-ID		(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		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:		the MIC argument in the MIC-Info: field. Because no MIC-Info:
	field is associated with the encryption security service under		field is associated with the encryption security service under
	asymmetric key managment, there is no requirement in that case to		asymmetric key managment, there is no requirement in that case to
	skipping to change at page 19, line 38 ¶		skipping to change at page 27, line 28 ¶
	be represented in 7bit form.		be represented in 7bit form.
	(3) This document broadens the allowable name forms that users may use		(3) This document broadens the allowable name forms that users may use
	to identify their public keys. Users may use arbitrary strings and		to identify their public keys. Users may use arbitrary strings and
	email addresses as their name. Further, users may distribute their		email addresses as their name. Further, users may distribute their
	public key directly in lieu of using certificates. In support of		public key directly in lieu of using certificates. In support of
	this change the Originator-ID-ASymmetric: and Recipient-ID-		this change the Originator-ID-ASymmetric: and Recipient-ID-
	ASymmetric: fields are deprecated in favor of Originator-ID: and		ASymmetric: fields are deprecated in favor of Originator-ID: and
	Recipient-ID: fields, respectively.		Recipient-ID: fields, respectively.
	11. Collected Grammar		9. Collected Grammar
	The following is a summary of the grammar presented in this document.		The version of the grammar in this document is as follows:
	(1) Signature headers		<version> ::= "Version:" "5" CRLF
	<pemsig> ::= <version> ( 1*<origasymflds> )
	<version> ::= "Version:" "5" CRLF		The content of an application/pem-signature body part is as follows:
	<origasymflds> ::= <origid> <micinfo>		<pemsig> ::= <version> ( 1*<origasymflds> )
	<origid> ::= "Originator-ID:" <id> CRLF		<origasymflds> ::= <origid> <micinfo>
	(2) Encryption Headers		<origid> ::= "Originator-ID:" <id> CRLF
	<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>		The content of an application/pem-keys body part is as follows:
	<version> ::= "Version:" "5" CRLF		<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
	<recipasymflds> ::= <recipid> <asymkeyinfo>		<recipasymflds> ::= <recipid> <asymkeyinfo>
	<recipid> ::= "Recipient-ID:" <id> CRLF		<recipid> ::= "Recipient-ID:" <id> CRLF
	<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF		<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
	(3) Identifier Name Forms		Identifiers are defined as follows:
	<id> ::= <nameid> / <id-publickey> / <id-issuer>
	<nameid> ::= <id-email> / <id-string> / <id-dname> / <id-pgp>		<id> ::= <id-subset> / <id-publickey> / <id-issuer>
	<id-email> ::= "EN" "," <keyid> "," <emailstr> CRLF		<id-subset> ::= <id-email> / <id-string> / <id-dname>
	<id-string> ::= "STR" "," <keyid> "," <string> CRLF		<id-email> ::= "EN" "," <keysel> "," <emailstr> CRLF
	<id-dname> ::= "DN" "," <keyid> "," <dnamestr> CRLF		<id-string> ::= "STR" "," <keysel> "," <string> CRLF
	<id-pgp> ::= "PGP2" ",0x" <pgp-keyid> "," <string> CRLF		<id-dname> ::= "DN" "," <keysel> "," <dnamestr> CRLF
	<id-publickey> ::= "PK" "," <publickey> [ "," <nameid> ] CRLF		<id-publickey> ::= "PK" "," <publickey> [ "," <id-subset> ] CRLF
	<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF		<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
	<keyid> ::= <encbin>		<keysel> ::= <encbin>
	; a printably encoded non-null sequence of octets		; a printably encoded non-null sequence of octets
	<emailstr> ::= <addr-spec> / <route-addr>		<emailstr> ::= <addr-spec> / <route-addr>
	; an electronic mail address as defined by		; an electronic mail address as defined by
	; these two tokens from RFC822		; these two tokens from RFC822
	<string> ::= ; a non-null sequence of us-ascii characters		<string> ::= ; a non-null sequence of characters
	<dnamestr> ::= <encbin>		<dnamestr> ::= <encbin>
	; a printably encoded, ASN.1 encoded		; a printably encoded, ASN.1 encoded
	; distinguished name		; distinguished name
	<pgp-keyid> ::= ; a sequence from the following alphabet: {0-9, A-F}		<publickey> ::= <encbin>
	; which is either exactly six or eight characters long		; a printably encoded, ASN.1 encoded
			; subjectPublicKeyInfo
	<publickey> ::= <encbin>		<serial> ::= 1*<hexchar>
	; a printably encoded, ASN.1 encoded		; hex dump of the serial number of a certificate
	; subjectPublicKeyInfo
	<serial> ::= 1*<hexchar>		The content of an application/pemkey-request body part is as follows:
	; hex dump of the serial number of a certificate
	(4) Request Headers (certificate, certification, etc.)		<request> ::= <version>
	<request> ::= <version>		( <subject> / <issuer> / <certification> )
	( <subject> / <issuer> / <certification> )
	<version> ::= "Version:" "5" CRLF
	<subject> ::= "Subject:" <id> CRLF
	<issuer> ::= "Issuer:" <id> CRLF
	<certification> ::= "Certification:" <encbin> CRLF
	(5) Data Headers (certificate, certification revocation list)		<subject> ::= "Subject:" <id> CRLF
	<certdata> ::= <certchain> / <crlchain>		<issuer> ::= "Issuer:" <id> CRLF
	<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		<certification> ::= "Certification:" <encbin> CRLF
	NOTE: to be done		The content of an application/pemkey-data body part is as follows:
	13. Acknowledgements		<keydata> ::= <version>
			( <publickeydata> / <certchain> / <crlchain> )
			<publickeydata> ::= "Key:" "PK" "," <publickey> "," <id-subset> CRLF
			<certchain> ::= <cert> *( [ <crl> ] <cert> )
			<crlchain> ::= 1*( <crl> [ <cert> ] )
			<cert> ::= "Certificate:" <encbin> CRLF
			<crl> ::= "CRL:" <encbin> CRLF
			10. Security Considerations
			This entire document is about security.
			11. Acknowledgements
	David H. Crocker suggested the use of a multipart structure for MIME-PEM		David H. Crocker suggested the use of a multipart structure for MIME-PEM
	interaction.		interaction.
	14. References		12. References
	[1] David H. Crocker. Standard for the Format of ARPA Internet Text		[1] David H. Crocker. Standard for the Format of ARPA Internet Text
	Messages. RFC 822, University of Delaware, August 1982.		Messages. RFC 822, University of Delaware, August 1982.
	[2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet		[2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet
	Mail Extension) Part One: Mechanisms for Specifying and Describing		Mail Extension) Part One: Mechanisms for Specifying and Describing
	the Format of Internet Message Bodies. RFC 1521, Bellcore and		the Format of Internet Message Bodies. RFC 1521, Bellcore and
	Innosoft, September 1993. Obsoletes RFC 1341.		Innosoft, September 1993. Obsoletes RFC 1341.
	[3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part		[3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part
	skipping to change at page 23, line 17 ¶		skipping to change at page 30, line 26 ¶
	Trusted Information Systems, February 1993.		Trusted Information Systems, February 1993.
	[6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic		[6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic
	Mail: Part IV: Key Certification and Related Services. RFC 1424,		Mail: Part IV: Key Certification and Related Services. RFC 1424,
	RSA Laboratories, February 1993.		RSA Laboratories, February 1993.
	[7] James Galvin, Sandy Murphy, Steve Crocker, and Ned Freed. Security		[7] James Galvin, Sandy Murphy, Steve Crocker, and Ned Freed. Security
	Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.		Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.
	RFC XXXX, Trusted Information Systems and Innosoft, XXXX 1994.		RFC XXXX, Trusted Information Systems and Innosoft, XXXX 1994.
	15. Authors' Addresses		13. Authors' Addresses
	Steve Crocker		Steve Crocker
	email: crocker@tis.com		email: crocker@tis.com
	James M. Galvin		James M. Galvin
	email: galvin@tis.com		email: galvin@tis.com
	Sandra Murphy		Sandra Murphy
	email: murphy@tis.com		email: murphy@tis.com
	skipping to change at page 23, line 33 ¶		skipping to change at page 31, line 4 ¶
	email: galvin@tis.com		email: galvin@tis.com
	Sandra Murphy		Sandra Murphy
	email: murphy@tis.com		email: murphy@tis.com
	Trusted Information Systems		Trusted Information Systems
	3060 Washington Road		3060 Washington Road
	Glenwood, MD 21738		Glenwood, MD 21738
	Tel: +1 301 854 6889		Tel: +1 301 854 6889
	FAX: +1 301 854 5363		FAX: +1 301 854 5363
	Ned Freed		Ned Freed
	Innosoft International, Inc.		Innosoft International, Inc.
	250 West First Street, Suite 240		1050 East Garvey Avenue South
	Claremont, CA 91711		West Covina, CA 91790
	Tel: +1 909 624 7907		Tel: +1 818 919 3600
	FAX: +1 909 621 5319		FAX: +1 818 919 3614
	email: ned@innosoft.com		email: ned@innosoft.com
	16. Appendix: Imported Grammar		14. Appendix: Imported Grammar
	The following productions are taken from [3]. The grammar presented in		The following productions are taken from [3]. The grammar presented in
	[3] remains the authoritative source for these productions; they are		[3] remains the authoritative source for these productions; they are
	repeated here for the convenience of the reader.		repeated here for the convenience of the reader.
	<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF		<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
	<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","		<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
	<asymsignmic> CRLF		<asymsignmic> CRLF
	skipping to change at page 26, line 7 ¶		skipping to change at page 34, line 7 ¶
	<CHAR> ::= <any ASCII character>		<CHAR> ::= <any ASCII character>
	<CTL> ::= <any ASCII control character and DEL>		<CTL> ::= <any ASCII control character and DEL>
	<specials> ::= "(" / ")" / "<" / ">" / "@" ; Must be in quoted-		<specials> ::= "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
	/ "," / ";" / ":" / "		/ "," / ";" / ":" / "
	/ "." / "[" / "]" ; within a word.		/ "." / "[" / "]" ; within a word.
	Table of Contents		Table of Contents
	1 Status of this Memo ............................................. 1		Status of this Memo ............................................. 1
	2 Abstract ........................................................ 1		Abstract ........................................................ 1
	3 Introduction .................................................... 2		1 Introduction ................................................... 2
	4 Name Forms and Identifiers ...................................... 3		2 Name Forms and Identifiers ..................................... 4
	4.1 Name Forms .................................................... 4		2.1 Name Forms ................................................... 4
	4.1.1 Email Addresses ............................................. 4		2.1.1 Email Addresses ............................................ 5
	4.1.2 Arbitrary Strings ........................................... 5		2.1.2 Arbitrary Strings .......................................... 5
	4.1.3 Distinguished Names ......................................... 5		2.1.3 Distinguished Names ........................................ 5
	4.2 Identifiers ................................................... 5		2.2 Identifiers .................................................. 6
	4.2.1 Email Address ............................................... 6		2.2.1 Email Address .............................................. 7
	4.2.2 Arbitrary String ............................................ 6		2.2.2 Arbitrary String ........................................... 7
	4.2.3 Distinguished Name .......................................... 7		2.2.3 Distinguished Name ......................................... 7
	4.2.4 PGP Public Key .............................................. 7		2.2.4 Public Key ................................................. 7
	4.2.5 Public Key .................................................. 7		2.2.5 Issuer Name and Serial Number .............................. 8
	4.2.6 Issuer Name and Serial Number ............................... 8		3 Applying PEM Security Services to MIME Body Parts .............. 8
	5 Applying PEM Security Services to MIME Body Parts ............... 8		3.1 PEM Processing Steps ......................................... 9
	5.1 PEM Processing Steps .......................................... 8		3.2 Use of multipart/signed Content Type ......................... 11
	5.2 Use of multipart/signed Content Type .......................... 10		3.3 Use of multipart/encrypted Content Type ...................... 12
	5.3 Use of multipart/encrypted Content Type ....................... 11		3.4 application/pem-signature Content Type Definition ............ 12
	6 Removing PEM Security Services from PEM Body Parts .............. 12		3.5 application/pem-keys Content Type Definition ................. 13
	7 Definition of New Content Types ................................. 13		4 Removing PEM Security Services from PEM Body Parts ............. 14
	7.1 application/key-request Content Type Definition ............... 13		5 Key Management Content Types ................................... 15
	7.2 application/key-data Content Type Definition .................. 15		5.1 application/pemkey-request Content Type Definition ........... 15
	8 Examples ........................................................ 17		5.2 application/pemkey-data Content Type Definition .............. 17
	9 Observations .................................................... 17		6 Examples ....................................................... 19
	10 Summary of Changes to PEM Specification ........................ 17		7 Observations ................................................... 24
	11 Collected Grammar .............................................. 19		8 Summary of Changes to PEM Specification ........................ 25
	12 Security Considerations ........................................ 22		9 Collected Grammar .............................................. 27
	13 Acknowledgements ............................................... 22		10 Security Considerations ....................................... 29
	14 References ..................................................... 22		11 Acknowledgements .............................................. 29
	15 Authors' Addresses ............................................. 23		12 References .................................................... 29
	16 Appendix: Imported Grammar ..................................... 24		13 Authors' Addresses ............................................ 30
			14 Appendix: Imported Grammar .................................... 32
End of changes. 170 change blocks.
	372 lines changed or deleted		702 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/