I spent some time late last night going through some of the past PEM messages,
to try to see where and how we got to the present point.
One of the most relevant messages I found was a message from Steve Kent,
summarizing the PEM WG Meeting at the Toronto IETF (7/26/94), dated 1 Aug 94.
I'll include some of the more pertinent observations:
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.
[Discussion of multipart RFC deleted.]
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:
[Details of MIME headers, hash algoriothm ID, canonicalization, and symmetric
key management deleted.]
- 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.
[Discussion of TYPE-KEYID-STRING, STR and PGP2 deleted.]
- 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.
[Discussion of use of different certificates for signature and key management
and syntax for certificates and CRL lists deleted.]
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.
I'd like to address the point in the next to the last paragraph regarding
e-mail addresses and distinguished names, as I surmize that that is the single
most important and lasting issue that has historically divided us. But I'd like
to address in the context of a reply to Ned's recent note, so I will replicate
that paragraph in my reply to Ned.
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-282