Holding back the progression of this specification is the only way to
ensure that changes are made to fix this document.
Perhaps; on the other hand, this message is an anomaly in containing
actual suggestions on how to fix it.
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.
I would prefer "expansion of" instead of "departure in," since one can
operate a MIME/PEM implementation in a way that fully conforms to the trust
model and naming conventions of RFC 1422. However, I would still rather
see policy treated in a separate document.
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).
True. I do not immediately see how this affects security, since in such
a case they key is being used outside of a certification schema, and
therefore must be validated through some out of band means. Given a
validated public key and associated name form and key selector, the
recipient has sufficient information to validate or invalidate the signature
or encryption. The name form / key selector pair is not a certification
path.
Provide a mechanism and/or recommendations to uniquely associate
a specific certification chain with a PEM-MIME signature.
Is this not already served by using certificates?
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).
Can you elaborate?
The specification does not
indicate when and how a "identifier" can be unabibuosly mapped to
a single certification chain.
Perhaps I am reading into it more than is actually there, but this seems
fairly simple to me. There are two cases:
(1) There is a certification chain, in which case certificates provide the
mapping. Such certificates may be included in the message, retrieved
from a directory, or any of the other methods currently in use.
(2) There is no certification chain, in which case the identifier and key
must ipso facto be validated via some other means. Such means are
outside the scope of PEM-MIME.
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.
To my understanding, there is no "interworking" possible, although an
implementation may operate in both modes independently. Either a signature
has a certificate chain, in which case it can use X.509 (even if it is not
rooted at the IPRA or some other public PCA), or it does not. What kind
of "interworking" could there possibly be?
As I have said before, it is of no great concern to me whether the
non-certificate based modes are called PEM or not, since I see (and
will thus relfect in any software I write) a clear difference between
certified and uncertified modes of operation. I also think, with Ned,
that uncertified operation will only serve to demonstrate the utility
of certificates (something that is by no means understood in the
user community at large) except for special purposes.
Amanda Walker
InterCon Systems Corporation