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.
They weren't modified Paul, they were set aside as a separate and
independent topic. In other words, when you say PEM, you mean RFC 1421
and RFC 1422. When I say PEM, I don't mean RFC 1422 and neither does
any of the PEM/MIME specification, by explicit design.
Thus, I don't believe there is any change.
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.
It is true that a key pair is uniquely identified by a name form and a
key selector as long as both the name form and key selector are unique.
The next revision (in the works) of the document does specify the
required characteristics of a key selector. I will add some text
indicating that the name form must also be unique. (Although, I should
point out that for both distinguished name and email addresses the
necessary property is already present.)
I consider this a minor editorial change.
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.
I don't understand. A name form is used to associate a human consumable
label to a key. A user owning a key gets to choose this and assert it
to all those with whom the user communicates. The protocol doesn't care
what the value is. What kind of recommendations are you looking for?
As for the certification chain, the topic is explicitly excluded from
the scope of the document.
I don't know the type of this change since I don't understand it.
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).
Your comment is confusing name forms (there are 3) with identifiers
(there are 5). We explicitly do not provide guidance to a user as to
which name form or which identifier to use. The intent is that a user
may choose whichever form suits their fancy or is best suited to the
environment in which it will be used.
I'm not aware of any inherent limitations implicit in the use of any
particular name form or identifier. Some provide more information for
implementations and thus an implementation may be able to be more
helpful when they're present, but I wouldn't consider this a limitation.
I don't believe there is any change.
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.
The next version of the document has a specific recommendation about how
one might use application/pemkey-data. I don't remember offhand about
the examples but I'll look and make sure there is one.
I consider this a minor editorial change.
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.
This topic is explicitly excluded from the scope of the specification.
Thus, there is no change.
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.
We are, in fact, doing this now.
This is a major editorial change.
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.
The problem is we want to explicitly observe for the reader that the
correct grammar only exists in its original form, not in the borrowed
form in this document.
I'll see if there's a better way to organize it.
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.
This is handled by MIME. There is nothing for PEM todo.
Jim