Here is the suggested text which I outlined in my last message. I
suggest you get a copy of "PEM Part I" in front of you so you can see
what changes.
Again, I want to stress that the number of changes you have to make to
an existing PEM implementations is very, very small. Check out section
4.3.5 below on conformance.
Thanks,
/mtr
///////
<<Editor's Note: replace Section 4.3 and 4.4 with this text>>
4.3 Representation and Transmission of Privacy-Enhanced Messages
4.3.1 Constraints
An electronic mail encryption mechanism must be compatible with the
transparency constraints of its underlying electronic mail
facilities. These constraints are generally established based on
expected user requirements and on the characteristics of anticipated
endpoint and transport facilities. An encryption mechanism must also
be compatible with the local conventions of the computer systems
which it interconnects. Our approach uses a canonicalization step to
abstract out local conventions and a subsequent encoding step to
conform to the characteristics of the underlying mail transport
medium. This is accomplished by defining a MIME content-type for use
with privacy-enhanced mail.
4.3.2 Definition of message/pem Content-type
The message/pem content-type is used to represent a privacy-enhanced
message. The content value is formatted using the conventions of
RFC-822. In particular, a content value consists of one or more
headers, possibly followed by a body. Each header takes the form of a
keyword, a colon (`:'), a structured value, and a terminating CR-LF
pair. As with RFC-822, to allow for the value to span multiple lines,
a linear white-space (LWSP) convention is used--continuation lines begin
with a sequence of one or more space or tab characters which are
syntactically equivalent to a single space.
Section 9 defines the syntax of the message/pem content, using the
extended BNF notation introduced in RFC-822.
If the Proc-Type: header is either ENCRYPTED, MIC-ONLY, or MIC-CLEAR,
then the Content-Type: header is present and is used to indicate the
type of information object which has been privacy-enhanced. This is
typically "message/rfc822", an RFC-822 formatted message. Note that
this information object shall be placed in a canonical form prior to
applying cryptographic techniques such as encipherment or generating a
message-digest. The definition of the canonical form for each type of
information object can be found in the MIME definition of its
content-type. For example, for any content-type of message, the
information object is represented using the NVT ASCII repertoire using
the CR-LF pair to signal line-termination.
NOTE: A Proc-Type: header of MIC-CLEAR shall be used only for those
information objects whose canonical form is represented
using the NVT ASCII repertoire. Otherwise, only the ENCRYPTED
or MIC-ONLY privacy-enhancements shall be used on the
information object.
If the Proc-Type: header is either ENCRYPTED or MIC-ONLY, then the
Content-Transfer-Encoding: header is present and has the value base64.
Otherwise this header shall not be present. Use of the base64 encoding
allows the privacy-enhanced information object to be transmitted through
the message transfer system with a relatively high degree of immunity to
undesirable translations. Otherwise, if the Proc-Type: header is MIC-CLEAR,
then 7bit encoding shall be used.
4.3.3 Generation of Privacy-Enhanced Messages
NOTE: Processing of Certificate Revocation Lists is covered in Part II.
These procededures apply only to ENCRYPTED, MIC-ONLY, and
MIC-CLEAR privacy-enhanced messages.
The process begins when the user wishes to send an information type
(e.g., an RFC-822 message) using privacy-enhanced mail facilities.
Initially, the information type is represented in a local form, which is
specific to the user's environment.
4.3.3.1 Translation to Canonical Form
The information type is transformed into the appropriate canonical form.
4.3.3.2 Authentication and Encryption
Authentication processing occurs when the canonical form is input to the
selected MIC computation algorithm in order to compute an integrity
check quanity for the message. No padding is added to the canonical
form before submission to the MIC computation algorithm, although
certain MIC algorithms will apply their own padding in the course of
computing a MIC.
Encryption processing is applicable only to ENCRYPTED privacy-enhanced
messages. Part III defines the padding technique used to support
encryption of the canonically-encoded message text.
4.3.3.3 Printable Encoding
Processing differs depending on the type of privacy-enhanced message:
- ENCRYPTED: the ciphertext is encoded using the base64
content-transfer-encoding of MIME.
- MIC-ONLY: the canonical form is encoded using the base64
content-transfer-encoding of MIME.
- MIC-CLEAR: the canonical form is encoded using the 7bit
content-transfer-encoding of MIME.
4.3.4 Encapsulation of Privacy-Enhanced Messages
Once a message/pem content-type is generated, it is placed inside an
RFC-822 message and submitted to the local message transfer agent.
If the message/pem content-type is the sole value of the outer message,
then the other message has the header
Content-Type: message/pem
and the content value starts as the first line of the body. However,
the message/pem content may be part of a larger structure. In this
case, it is likely that the multipart/mixed content will be used to
provide automatic delimiting of the message/pem content.
4.3.4.1 Caveats
<<Editor's note: this is verbatim text>>
If a user wishes PEM-provided confidentiality protection for
transmitted information, such information must occur in the
encapsulated text of an ENCRYPTED PEM message, not in the enclosing
MTS header or PEM encapsulated header. If a user wishes to avoid
disclosing the actual subject of a message to unintended parties, it
is suggested that the enclosing MTS header contain a "Subject:" field
indicating that "Encrypted Mail Follows".
If an integrity-protected representation of information which occurs
within an enclosing header (not necessarily in the same format as
that in which it occurs within that header) is desired, that data can
be included within the encapsulated text portion in addition to its
inclusion in the enclosing MTS header. For example, an originator
wishing to provide recipients with a protected indication of a
message's position in a series of messages could include within the
encapsulated text a copy of a timestamp or message counter value
possessing end-to-end significance and extracted from an enclosing
MTS header field. (Note: mailbox specifiers as entered by end users
incorporate local conventions and are subject to modification at
intermediaries, so inclusion of such specifiers within encapsulated
text should not be regarded as a suitable alternative to the
authentication semantics defined in RFC [1114F] and based on X.500
Distinguished Names.) The set of header information (if any) included
within the encapsulated text of messages is a local matter, and this
RFC does not specify formatting conventions to distinguish replicated
header fields from other encapsulated text.
4.3.5 Conformance
Any implementation which claims conforms to this document will be able
to generate and receive a message/pem content as specified in Sections
4.3.2 and 4.3.3 of this document.
A minimally conforming implementation will be able to generate and
recognize a message/pem content which is the sole value of an RFC-822
message.
<<Editor's Note: figures 2, 3, and 4, will need to be redone: simply
remove the encapsulation boundaries and add these two headers:
Content-Type: message/rfc822
Content-Transfer-Encoding: base64
<<Editor's Note: replace the beginning of Section 9 with this text>>
9 Descriptive Grammar
This section provides a grammar describing the construction of a PEM
message.
; PEM BNF representation, using RFC 822 notation.
; imports field meta-syntax (field, field-name, field-body,
; field-body-contents) from RFC-822, sec. 3.2
; imports DIGIT, ALPHA, CRLF, text from RFC-822
; imports Content-Type, Content-Transfer-Encoding from MIME
; Note: algorithm and mode specifiers are officially defined in RFC-1115.
<message/pem> ::= <pemhdr>
[CRLF <pemtext>] ; absent for CRL message
<pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages
/ *(<text> CRLF) ; for MIC-CLEAR
<pemhdr> ::= <normalhdr> / <crlhdr>
<normalhdr> ::= <proctype>
[<dekinfo>] ; needed if ENCRYPTED
(1*(<origflds> *<recipflds>)) ; symmetric case --
; recipflds included for all proc types
/ ((1*<origflds>) *(<recipflds>)) ; asymmetric case --
; recipflds included for ENCRYPTED proc type
<contentinfo>
<contentinfo> ::=
"Content-Type" ":" <Content-Type> ; usually message/rfc822
; only for ENCRYPTED or
; MIC-ONLY
["Content-Transfer-Encoding" ":" "base64"]
<crlhdr> ::= <proctype>
1*(<crl> [<cert>] *(<issuercert>))
///////
That's it!
/mtr