PEM WG Meeting Minutes
11/18/92
Steve Kent, Chair
1. A review of document status was provided by Steve Crocker, the
Security Area director. Three of the four documents are ready for
progression, and the fourth (RFC 1115bis) needs to be edited to make
it clear that additional algorithm suites will be published via new
RFCs, but this is viewed as a minor edit and thus should not hold up
progression of the documents. Steve indicated that the documents will
be recommended for progression very soon, perhaps at the Friday IESG
meeting.
2. RFC 1115bis also needs to be revised to remove use of DES MAC as a
message integrity code. Recent work has indicated that use of DES MAC
is unsuitable with either symmetric or asymmetric key management
algorithms, even in the limited contexts already defined in 1115bis.
Only one party who might object to this removal of DES MAC was
identified and he will be promptly notified of the planned change.
here too, the change is considered minor as it involves removal of
what is viewed as an option which was not expected to see much, if
any, use.
3. The WG received a hardcopy handout of an I-D written by Steve
Crocker, Ned Freed, and Marshall Rose. The I-D proposes an
approach to integrating MIME and PEM.
4. Ned Freed presented this approach to the WG and discussion
ensued:
- There was agreement that the current processing description
for submission should not be proscriptive, i.e., alternative user
interface options for invoking PEM for a MIME message are
permitted. Thus section 5.1 needs to be revised to avoid any
implications that the pre-submission processing is a description
of a user interface requirement. The goal here is to convey what
needs to be done, but not to imply a required user interface form.
- It was suggested that additional formats could be defined
in MIME to transport certificates, exclusive of their transport in
the PEM header. This is not in conflict with the current
proposal, but was generally regarded as a very useful addition.
- There was a discussion of what 5.1.2 in the I-D implies.
The intent was that step would transform any input into MIME canonical
form. Discussion explored the use of the new (as of last IETF
meeting) PEM header field "Content-Domain" to represent the
canonicalization performed by PEM. This field was intended to allow
other than vanilla 822 canonicalization to be performed on the input
to PEM, in an effort to avoid redundant encoding steps.
- It was suggested that the PEM MIC-ONLY option is not
required in the MIME environment as MIME will employ a transfer
encoding that preserves the PEM message. Thus MIC-CLEAR could be used
in lieu of MIC-ONLY, avoiding a redundant encoding step. However,
MIC-CLEAR does pose real danger when "helpful" mail relays are
involved, i.e., if MIME is not available at all recipients, even if
some recipients do have (non-MIME) PEM. It also is suggested that
inclusion of a redundant, cleartext body part is a means of
accommodating the recipients for whom MIC-CLEAR was developed. Thus
this issue is unresolved.
- It is not clear that the canonical encoding options now
used in MIME preserve the reversibility required for signature
preservation in forwarded messages. This is a cause for some concern
and requires further examination.
- There was debate over whether the preferred approach here is
to define a new PEM Content-Domain for use with MIME, allowing any
(8-bit) input and avoiding possibly redundant base64 encoding, or to
use only the existing PEM 822 Content-Domain and impose the base64
encoding in all cases.
- The question was raised as to whether the PEM header needs
to indicate Content-Domain MIME when the PEM header is already within
a MIME message, or is it redundant? the issue was not resolved and
requires further study.
- - It is suggested by several attendees that the Content-Annotation
proposed in section 6, needs to be dropped or improved. It does not
provide enough information to preserve all of the security information
that PEM provides. There is considerable feeling that there is a
difference between what is displayed to the user as part of message
reading, vs. what is retained when the message is stored. The message
may be stored in enciphered form, in signed only form, or without any
cryptographic (PEM) protection. It was argued that the labeling of a
stored message which was previously protected by PEM is strictly a
local matter and thus should not be part of the MIME header (nor part
of the MIME-PEM specification).
- There was agreement to continue this discussion on the PEM-
DEV mailing list and at the next IETF meeting. The authors of the
I-D, which was the focal point of this discussion, agreed to work on a
successor version, taking into account the various issues raised and
discussed during this meeting. The PEM WG and MIME WG chairs agreed
to request that future PEM and MIME WG meetings during IETF be
explicitly scheduled to not conflict with one another.