Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/pem/pem-minutes-94jul.txt

Text File | 1994-11-02 | 11KB | 191 lines

CURRENT_MEETING_REPORT_

Reported by Steve Kent/BBN

Minutes of the Privacy Enhanced Mail Working Group (PEM)

The major focus of this meeting was review of two very recent Internet
Drafts:  ``Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted'' (draft-ietf-pem-sigenc), and ``PEM Security
Services and MIME'' (draft-ietf-pem-mime).  Presentations on both
Internet-Drafts were made by Jim Galvin, who is a co-author on both
documents.


``Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted''

The first Internet-Draft, defines two multipart content types:  one for
use when encrypting body parts, and one for use when signing body parts.
The intent is that these generic multipart content types can then be
customized for use with different security protocols that would operate
in the MIME environment, not just PEM. For each such protocol, a
separate RFC will be required to specify the details of how that
protocol makes use of these basic context types.  The current form of
this Internet-Draft also contains brief specifications for two control
body parts, one for keys and one for signature information.  However,
the authors concluded that it would be better to move these two body
parts to the second Internet-Draft to facilitate management of the
application-specific parameters of these body parts.  Thus the
definitions of these body parts for each application will be relegated
to the documents describing the rest of the parameters for the
application-specific multipart construct.  (The working group chair also
believes that these body parts were insufficiently general, as currently
described, to be included in this Internet-Draft.)


PEM Security Services and MIME

Most of the discussion centered on the second ID, that provides a PEM
specification of how to employ the encryption and signature content
types.  The discussion highlighted major differences between the
previous draft and the current draft:

MIME headers are included in the signature, to be consistent with the
inclusion of headers in encrypted contents.

The hash algorithm ID is included in the header of the (signed) data
body part to facilitate one-pass processing of signed messages, but the
rest of the signature data is retained in the control body part to make
display of signed but not encrypted data easy for non-PEM users.

To retain an ability for non-PEM users to read signed messages, and to
avoid the canonicalization problems that have plagued previous attempts
at PEM-MIME integration, this Internet-Draft calls for 7bit encoding for
all data that is signed.  There is an additional requirement for
canonical line delineation, and this is addressed by requiring use of
CRLF for computation of the signature hash value, although the CRLF
transformed body part is not transmitted.  Instead, recipients are
required to re-encode received, signed body parts to this format when
checking the hash.  There is general agreement that this is a painful
approach (e.g., it will entail multiple encodings when a message is both
signed and encrypted), but it is the only means developed so far to
address the canonicalization problem in a fashion that is consistent
with existing MIME conventions.  There also was agreement that
additional details are required to completely nail down the
canonicalization step, e.g., conventions for representation of tabs.

A question was raised as to whether the complexity of the resulting
system is worthwhile, e.g., relative to the simpler proposal put forth
over 6 months ago by Jeff Schiller.  The approach in the current
Internet-Drafts allows for recursive application of PEM processing, but
does not include syntax for semantics such as serial versus parallel
signatures.  There was no substantive discussion on this question.

The current Internet-Draft does not include support for symmetric key
management, unlike RFC 1421.  The rationale provided for dropping this
facility was a lack of implementations including this facility.  It was
observed, however, that many of the independent implementations (if not
the more widely distributed TIS implementation) have included symmetric
key management support and that these implementations have bootstrapped
interoperability testing using that form of key management.
Nonetheless, the PEM RFCs have clearly expressed a strong preference for
public-key key management, and no RFC comparable to 1422 has been
published for symmetric key management.  However, an Internet-Draft for
use of PEM with X9.17 key management, for support of authenticated (not
encrypted) messaging, is in preparation, as a result of interest from a
member of the banking community.  (X9.17 is an ANSI standard, and there
is a corresponding Federal Information Processing Standard, for DES key
management in the wholesale financial banking community.  However, one
attendee questioned whether the banking community had a substantial
X9.17 infrastructure in place.)  It was suggested that it may suffice to
revise 1421 to accommodate this requested change, not propagating it to
MIME-PEM.

There was extensive discussion of the ``name form'' and ``key
identifier'' concepts presented in the new Internet-Draft.  It was
observed that some public-key certificates provide key identifiers that
do not fit the model presented in this Internet-Draft and that the model
proposed in this Internet-Draft required a much less efficient
representation for such an identifier than is necessary in some cases.

It was suggested that the syntactic requirements for originator and
recipient asymmetric key management IDs need not be identical, as is
reflected currently in RFC 1421.  The originator ID is used to convey
information needed to select the public-key used by an originator to
sign a message and to identity the originator.  This selection may
involve directory access, or may be satisfied directly by conveying the
originator's certificate in the message header (an identification option
not accommodated by the proposed syntax).  For some encryption
algorithms, there is also a need to convey per-message parameters for
decryption; such parameters properly belong in the ``keys'' body part
but not necessarily as part of the originator ID. In contrast, a
recipient ID is used by a recipient to select the token in the message
header that matches a private key held by the recipient.  A recipient
may hold multiple sets of keying material, either under different
identities (including mail list identities), or serially under the same
identity.  So the recipient ID may be viewed as a means of selecting the
proper private key among those available to the recipient.  This
argument suggests that requiring an identical format for both originator
and recipient key identifiers may be inappropriate.

The ``TYPE-KEYID-STRING'' syntax was criticized as an attempt to over
generalize the concepts here, since (as noted above) not all legitimate
approaches to providing key selectors fit the mold very well.  The
``IS'' construct already deviates from the general model somewhat, and
the DN part of the construct is not the same DN as in the ``DN''
construct, which could lead to some confusion.  (In the latter case, the
distinguished name is that of the issuer of a certificate, whereas in
the former case it is the distinguished name of the user.)  As noted
earlier, there are much more efficient key identifier constructs for
some algorithms and certificates that also don't fit this model.

Discussion of the ``STR'' construct strongly suggested that it should be
renamed ``DS'' for ``domain specific,'' and that an explicit domain
identifier (registered with the IANA) should be employed to avoid the
ambiguity inherent in any domain-specific identifier form.  There also
was a suggestion that the US-ASCII restriction, which is present because
of MIME encoding concerns, be relaxed to 7bit and that a field be
included to indicate (explicitly) the ``native'' character set of this
string if it was encoded.

There was some discussion about the rationale for inclusion of the PGP2
construct here.  It was observed that PGP can be carried by MIME using
the constructs defined in the companion Internet-Draft.  One possible
explanation is that one may make use of the PGP key management and thus
this field should be present.  Alternatively, the inclusion of this key
identifier format may pave the way for a migration of PGP users to a
common format with PEM. It was suggested that these, and/or other
rationales, be explicitly included in the Internet-Draft text.

It was noted that the format for use of e-mail addresses as user names
(EN) does not have an accompanying certificate format defined.  The
rationale for not using X.509 certificates is that the use of e-mail
names as distinguished names is incompatible with most X.500 directory
schema conventions, even though it is syntactically feasible.  One of
the Internet-Draft authors indicated that use of signed body parts as
certificates was a possible remedy for this situation, but no mention of
this approach is cited in the Internet-Draft.

It was observed that the statement in the ID that calls for different
certificates for signature and key management public keys is not
strictly required, and is incompatible with X.509 certificates that
combine both.  This latter approach is more efficient than requiring
duplication of most of the certificate format just to change the
SubjectPublicKeyInfo field.

It also was observed that the syntax in the Internet-Draft mixes
certificates and CRLs in certificate lists, while there is also a
separate CRL list construct.  It was suggested that the certificate list
construct be simplified to eliminate CRLs, maintaining them only in the
latter, more appropriately named data structure.  This would require
changing the processing description of the latter structure, which
describes it as being used only for returning CRLs in response to
requests, as opposed to being provided unilaterally by a message
originator.


Conclusion

In general, a concern was voiced by several attendees about possible
combinatoric explosion of options adversely affecting interoperability
of the resulting protocol.  There also was a suggestion by the chair
that these Internet-Drafts should be viewed only as defining the use of
PEM with MIME, not as supplanting RFC 1421, which defines the use of PEM
with non-MIME messages.  This approach would retain RFC 1424 (which the
``PEM for MIME'' Internet-Draft calls for making obsolete) and would
also require that the new PEM-MIME Internet-Draft be more
self-contained, i.e., not expressed as changes relative to RFC 1421.