The Internet community desperately needs good security mechanisms defined for
MIME. This is not a good reason to release a flawed specification on the
world. The draft-ietf-pem-mime-07.txt document provides a loosely written set
of mechanisms that do not include adequate recommendations for the development
of truly interoperable systems. Holding back the progression of this
specification is the only way to ensure that changes are made to fix this
document.
The PEM-MIME specification is akin to a standard for a railroad engine that
allows five different widths of track. Any single vendor can build workable
systems (engines, freight cars, and tracks). All new engines must support all
five different wheel widths. It is left up to industry to worry about how to
make the complete system work.
Detailed comments on draft-ietf-pem-mime-07.txt are provided below.
Paul A. Lambert
Motorola, Inc.
M/S AZ49-R1209 Internet: Paul_Lambert(_at_)email(_dot_)mot(_dot_)com
8220 E. Roosevelt Rd. Phone: +1-602-441-3646
Scottsdale, Az. Fax: +1-602-441-8864
85257 USA
=== Detailed Comments on draft-ietf-pem-mime-07.txt - January 22, 1995 ===
The following are specific comments and recommended changes to draft-ietf-pem-
mime-07.txt
Number: 1
Type: Major Editorial
Location: Page 2, end of paragraph 1 in section 1.
Comment: The specification claims that only mechanisms are changed when
in fact the trust models and naming conventions of PEM have
been modified.
Change: Replace last two sentences (Page 2, end of paragraph 1) with:
"These changes represent a departure in mechanism, trust model,
and naming conventions. These changes are detailed in
Section 8.
Number: 2
Type: Major Technical
Location: Page 3, paragraph 3
Comment: It is claimed that a key pair is uniquely identified by a name
form and key selector combination. This is not true. Nothing
prevents a name form and key selector from being used by more
than one issuing system (user or third party).
Change: Provide mechanisms and recommendations for name form and key
selector usage to prevent multiple name form/key selector pairs.
Provide a mechanism and/or recommendations to uniquely associate
a specific certification chain with a PEM-MIME signature.
Change text (page 3) to reflect limitations of key pair binding.
Number: 3
Type: Major Technical
Location: Page 3
Comment: The PEM-MIME specification bases security primarily on
public/private key pairs. This is a problem when the identity of
an entity depends not only on the key pair, but also the
context of the key certification (whether old PEM
model or newer PGP like models).
Change: Provide text giving recommendations for use of new name forms.
Provide a mechanism to uniquely associate a specific
certification chain with a PEM-MIME signature applied to data.
Number: 4
Type: Major Editorial
Location: Throughout
Comment: The PEM-MIME (version 7) specification documents five ways to
identify public keys (E-mail Addresses, Arbitrary Strings,
Distinguished Name, raw Public Key and Issuer Distinguished
Names). The description of these mechanisms focus on the means
to retrieve a public keys. Digital signatures provide a senders
identifty based on the public/private key pair and the context in
which the keys might be certified. The specification does not
indicate when and how a "identifier" can be unabibuosly mapped to
a single certification chain. The specification needs to
describe when this lack of mapping is a feature and when it is a
flaw.
Change: Add text to describe the usage and limitations of the five
identifiers. Provide recomendations for the usage of each name
form (e.g. when is a PK prefered to a EN).
Number: 5
Type:
Location: Page 17
Comment: The text below is far to fuzzy about the new PEM-MIME
certificate formats:
NOTE: Insofar as a certificate represents a mechanism by which a
third party vouches for the binding between a name and a public
key, the signing of an application/pemkey-data body part is a
similar mechanism.
Change: Include specific recomendations for the use of signed
application/pemkey-data body parts.
Provide examples of signed application/pemkey-data body parts.
Number: 6
Type: Major Editorial
Location: Throughout
Comment: The RFC1422 hierarchies are still supported in the specification,
but no guidelines are provided for resolving what happens when
the "top down" 1422 hierarchy meets the "roll your own" PEM-MIME
certificate-like structures. No guidelines are provided for the
interworking of the various name forms.
Change: Provide recommendations for interworking of 1422 certificates
with the new name forms and raw public key approaches.
Number: 7
Type: Major Editorial
Location: Page 32
Comment: The references a specification that it claims to replace
(RFC1421).
Change: Text from RFC1421 should be borrowed and placed in the PEM-MIME
document. The grammar should be placed in section 9.
Number: 8
Type: Minor Editorial
Location: Section 9 and Page 32 (Appendix: Imported Grammar)
Comment: Separating the imported grammar from the collected grammar makes
the specification more difficult to read.
Change: Move the text in Section 14 to Section 9.
Number: 9
Type: Minor Editorial
Location: Section 3.1
Comment: The specification does not address the issues of "white space"
and digital signatures.
Change: Add text that describes white space issues in a digitally signed
Suggestion - include an example describing the scanning of signed
documents that have trailing white space.