PEM WG Meeting at the Toronto IETF (7/26/94)
The major focus of this meeting was review of two very recent
Internet Drafts: "Security Multiparts for MIME: Multipart/Signed
and Multipart/Encrypted," and "PEM Security Services and MIME."
Presentations on both I-Ds were made by Jim Galvin, who is a co-
author on both documents.
The first I-D, 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 I-D also contains brief
specifications for two control body parts, one for keys and one
for signature information. However, the authors concluded that
these body parts proved to be insufficiently general to be
included in this I-D, and thus they will part of the protocol-
specific documents.
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 I-D 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 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
approached in the current I-Ds allows for recursive application
of PEM processing, but does not include syntax for semantics such
as serial vs. parallel signatures. There was no substantive
discussion on this question.
- The current I-D 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 I-D 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 question
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 I-D. It was
observed that some public-key certificates provide key
identifiers that do not fit the model presented in this I-D and
that the model proposed in this I-D 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 in the current PEM 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 that 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 I-D. 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 I-D text.
- It was noted that the format for use of email 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 email names as distinguished names is incompatible
with most X.500 directory schema conventions, even though it is
syntactically feasible. One of the I-D 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 I-D.
- 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 I-D mixes
certificates and CRLs in certificate lists, while there 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.
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 I-Ds 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" I-D
calls for making obsolete) and would also require that the new
PEM-MIME I-D be more self-contained, i.e., not expressed as
changes relative to 1421.