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.