PEM WG Meeting Minutes
A show of hands indicated that about 70-75% of the attendees were
new, i.e., have not previously attended a PEM WG meeting. A
number of MIME WG members attended, probably because of the agenda
topic #1.
1. MIME_PEM Integration
The primary agenda topic for this meeting was a review of the
latest MIME-PEM ID, published about 2 weeks prior to this meeting.
Steve Crocker (TIS) lead the discussion of this new draft,
explaining the major features of this proposal, in particular,
noting differences between this proposal and the features provided
by the PEM format defined by RFC 1421.
These features include:
- optional use of separate keys for encryption and signature
- protection of any content type, through recursive use of
the MIME multipart construct
- use of MIME transfer encoding (e.g., "quoted-printable") to
eliminate the need for the MIC-CLEAR processing type
- encryption and signature control info separate from the
message body
- encryption and signature control info placed at the end of
the message
- CRLs, certificates, etc., all supported in a message via
separate body parts, removing the need for separate message types
for management functions, e.g, CRL distribution and requests,
etc.
- optional inclusion of message header info within protected
boundary, e.g., if message/RFC822 is the encapsulated body part
type
Some of these features precipitated some discussion. For example,
it was noted that placing encryption (vs. signature) control info
at the end of the message precludes one-pass message processing.
The primary motivation for placing encryption and signature
control info at the end of the message is to reduce visual
clutter, especially for non-PEM recipients. However, this
rationale does not apply to encrypted messages (which, by
definition, are not directed to non-PEM users), so there appears
to be much less motivation to place encryption data at the end of
a message. The discussion suggested that review of this aspect of
the design is in order.
The only significant problem uncovered during the review relates
to forwarding of signed messages, especially ones that contain
other than just text. The problem here is that the proposal
relies on use of MIME context transfer encoding (CTE) to produce a
canonical representation for content. Canonicalization is
critical for the transmission of signed data, to ensure that a
recipient can verify the signature. However, the CTE is only
pairwise between an originator and the "original" set of
recipients for a message. If one of these recipients forwards a
signed message to a third party, a different CTE may be employed,
resulting in a different representation for the content, and a
consequent failure of the signature on the forwarded message.
This discussion suggested that the proposal be modified so that an
originator can specify a fixed, canonical encoding for a content,
enabling forwarding of signed messages that preserves the original
encoding.
The authors of this MIME-PEM proposal agreed to go back and work
on this last problem, producing a new proposal that addresses this
rather critical problem.
One last issue was briefly discussed under this agenda topic, but
a decision was deferred. The issue is whether a MIME-PEM RFC
should supersede RFC 1421, or whether we should have parallel MIME
and vanilla 822 versions of PEM. There was some sentiment
expressed for maintaining these as parallel RFCs, but the decision
has been deferred pending availability a MIME-PEM RFC.
2. Changes in Working Group Organization
In consultation with the outgoing and incoming Security Area
Directors, it has been decided to reorganize the PEM WG, as
described below.
The PEM WG will soon be redefined to encompass a limited scope,
namely the syntax and top-level processing of PEM messages. One
or more new WGs will soon be created to address the topic of
certification management. One of these WGs will address design of
a certification system that is not hierarchic (in contrast to the
one defined in RFC 1422), and a second WG may be created to
continue to refine the sort of hierarchic certification system
currently described in 1422.
3. Discussion of Certification System Parameters
The remainder of the WG session was devoted to a brief review of
various characteristics of certification systems that have been
the focus of recent debate on the PEM-DEV list, e.g., the form of
names in certificates, self-signed certificates, etc. Since this
discussion was just a brief, top-level review of the more detailed
discussions that have taken place on the mail list, no detailed
minutes are provided on this portion of the meeting.