The issue of whose digital signature is to be _trusted_, and to what
extent, must be decided by the individual recipient. The de facto
assumption within the Privacy Enhanced Mail community is that the
entire certificate chain is displayed for the user's edification for
each message, and the user makes a decision as to the believability
of that message one at a time.
Actually, no, this is not correct; and this points to one of the
fundamental assumptions between PEM and PGP. One of the base
assumptions for PEM is that users are too stupid to figure out whether
or not a given certification chain is valid. They will see a bunch of
wierd X.400 series that will have little or no meaning to them, and they
will blindly hit the "OK" button. (Keep in mind, we're dealing with
Suits here. :-)
Hence, PEM's assumption, which is written into the RFC's is that user
will only be precented with the DN of the originator; and will get a
warning message if the PCA of the originator is different from the
"home" PCA of the recipient. (Because in that case, the policy of the
sender will be different from the policy that the recipient is generally
used, so the recipient should be warned.)
I overstated my case. I believe that you are correct about the RFC's
_assumption_ that only the DN is displayed, and not all of the details
about the certificate chain. Hence the requirement for name subordination,
which I believe is primarily for global name uniqueness, but which also spares
the user from having to look up the name of the CA in the user's certificate.
(It
also prevents the CA from impersonating anyone outside of the CA's own
organization, which is an even better reason.)
(BTW, I believe there is a potentially serious issue in this regard with respect
to "unaffiliated", i.e., residential users. It is my understanding that several
of the PCAs intend to issue certificates to unaffiliated users that will NOT
include the name of the CA in the user's DN. In all likelihood this is to avoid
the
potential implication of any liability. I'll grant that it would be a little
cumbersome,
but if the RFCs insist on name subordination, I think a DN such as
C=US,O=RSA,OU=Unaffiliated-User,S=MA,L=Acton,CN=R. Jueneman
should be required. I assume that a compliant PEM implementation would reject
or warn the user if the DN were simply C=US,S=MA, L=Acton, CN= R. Jueneman,
unless the town of Acton was actually the certificate issuer. If the potential
implication of liability is too much for a PCA to stomach, I think the
unaffiliated
users should be registered under a unique PCA, since PCA name subordiantion
is not required. In particular, I don't want to see the creation of CA policies
that are different from the PCA policy.)
However, I don't remember the bit about the warning if the PCA is other than
the "user's" PCA. Could you quote chapter and verse? I would tend to think that
this is an artifact of a particular implementation, and may not make a lot of
sense.
If I am merely verifying a signature, am I required to have a certificate of my
own? Why? And what if I have two certificates, issued by two different PCAs?
Which one is to be used?
I think the real issue may be a lack of generality in how the root keys are
handled, but I think that is an implementation detail. As Steve Kent and I
agreed
several months ago, it should be possible for a PEM-compliant implementation to
automatically accept, automatically reject, and/or display the details of the
certificate chain to the user under various circumstances. In particular,
I would like to see the ability to automatically warn on all "foreign"
PCAs, perhaps automatically rejecting certain PCAs or CAs, and optionally
accept certain CAs and/or users whether or not their certificate chain is
syntactically correct or not.
Presumably I as the user get to decide which PCA policies I like or will accept.
(I may accept the "guidance' of my employer, if I wish to continue to be
employed, of course). If I can choose my PCA, I should equally well be able to
choose which CAs I will accept, including my own CA. Finally, I should be able
to insert any individual's certificate that I wish, under my own authority.
Granted, if I force-add a CA or individual's certificate, I am responsible for
ensuring that that CA or individual is still a valid user, that whatever
affiliation
I was previously counting on still exists, and that the user or CA certificate
has
not be revoked, either voluntarily or involuntarily. But I have that
responsibility
in the case of the PCA and the IPRA in any case.
What I am suggesting is that there is nothing at all wrong with the direct trust
model, and that PEM-compliant implementations can and (IMHO) should support
such a model with a scheme as described above.
I don't believe the PGP folks are saying that they reject the notion of having
a hierarchical certificate structure in place, but they aren't necessarily
counting
on its existance. I belive that they are also saying that the syntactical
correctness of a certificate chain back to its root (which may be the receiving
user), is a necessary but not sufficient condition for TRUST in the eyes of
the recipient.
Considering the possibility that my computer has been infected with a virus,
I don't necessarily even trust my own digital signature completely, but I would
trust the signature and the contents of a document signed by myself,
one of my family members, or one of my close associates (using a certificate
received from them directly) far more than I would trust a document signed by
someone I don't know personally, even though that person's certificate chain
was correct.
I believe that the primary difference between the PEM and the PGP philosophies
is that the architects of PEM were concerned primarily with validating the
IDENTITY of the the originator, without concern for the degree of TRUST
(i.e., rights, privileges, and credibility) that should be associated that
individual.
Certainly there have been much discussion about the undesirability of
burdening the certificate, the DN, etc., with issues of liability,
authorization,
etc., for a general purpose mail program, and in the long run this may prove
to be the best approach (asuming we procede with the implementation
of authorization certificates.)
However, the PGP folks have been far more pragmatic and probably closer
to the true needs of the user community by allowing a more flexible TRUST
model to be described, though they tend to equate trust and identity a little
too much, I think.
I can conceive of how an identity-based mechanism can be scaled up to
millions of users, especially if I trust an association of CAs and users
operating
under the common ground-rules of a PCA's policy statement with respect to
the identification policy. I have a much tougher time trying to imagine how
to scale up a TRUST model to the same number of users without either personal
knowledge or a legally binding agreement.
I will pass on addressing issues of compatibility with various standards,
suitability for binary files, etc. PEM has done a lot of things right, but there
are also a whole lot of things that I think could have been done better.
Time (and usage) will tell. And formal standards, committee votes, etc., are
neither necessary nor sufficient to determine which products will survive in
the
marketplace.
Bob