Steve,
I think you are right. We do have a fundamental disagreement here.
I have not kept up on all of the ins and outs of PEM as it has progressed
to the point of becoming a draft standard, and I certainly accept what you
say is the intent of the current PEM RFCs, as you speak "ex cathedra."
I also have the greatest personal respect for what you have been able to
accomplish in this area over the last several years -- it is monumental.
However, I am trying to focus on the potential business uses of PEM
and the allied technology that X.500 and X.509 brings to the table,
and providing advice to our users as to how to make all of this work.
In this context, I am not particularly interested in securely
communicating with someone whom I don't know, nor in receiving
authenticated communications from someone whom I may not be
able to trust. I am not prohibiting such communications -- they can
send them to me in the clear, or using MIC-CLEAR, or by using a
certificate chain which I don't choose to validate, and I can still
read them, but I won't accord them much credibility or weight
other than that which derives from the content of the message itself.
In particular, I do NOT want to have to read every line of the entire
certification chain, followed by a detailed examination of the digitally
signed Policy statement of the PCA, before I decide whether or not
a message is valid. Instead, I want my UA to automatically and on a
routine basis confirm that a message has been received from someone
who has agreed to the same type of authentication policy that
I have agreed to. If a message is received from outside of that circle
of trust, i.e., from outside of my PCA's certification domain, and
maybe even if it is from outside of my CA's domain, then I would like
to be alerted to that fact. Then, and only then, would I take the
time to go through all of the various verification steps, and then
only if I had some particular reason to want to clearly establish
the authenticity of the message. For routine e-mail I wouldn't
bother.
[Maybe that is at the heart of our disagreement. I view electronic
mail as including business communications of all types. I am
afraid that much of the PEM community views mail as being
primarily for social, technical, and academic correspondence,
with little or no busiess content. This results in different value
judgments being applied.]
What you seem to be proposing is content-free authentication, and
that just baffles me.
To my way of thinking, the word "certified" has to be immediately
followed by the question, "To do what?" The answer ought to be,
"To conform to an agreed upon Policy, for the mutual benefit of
all those who choose to agree with the same Policy." But if the
Policy is essentially vacuous, then the certification is almost
meaningless.
Unless I have missed an important point, it seems to me that the IPRA
is certifying PCAs that meet the absolute lowest common denominator
of trust, i.e., that the Distinguished Names of their various users are
unique, and that they have publioshed a Policy statement. I suppose
that having the IPRA certifiy that an organization is in fact a PCA is
worth something -- I can at least go read that PCA's policy and
see whether I like it.
But without any kind of a due diligence type of effort on the part of the
IPRA, how do I know that a given PCA isn't a front for the Mafia, the
KGB, or some nut who thinks he's the tooth fairy?
Moral suasion is one possible solution, of course, but I suspect that
the Internet's Society's lawyers would feel very uncomfortable with
the notion of the IPRA disavowing a PCA unless there was a strong
contractual basis for doing so. And for an international organization
that has to deal with the varying laws of different countries, that
is probably impossible.
I'm not saying that the current PEM IPRA structure is wrong, simply
irrelevant to most if not all of our business needs. And since the
RFCs are still just draft Internet standards, maybe we should think
a little harder about the problem, and perhaps modify them while
there is still time.
As a potential customer, I agree with the approach taken by Steve
Crocker and most other implementations I am aware of. The user
and/or the system administrator will be given the ability to specify
what root keys he wishes to use for certain purposes, and the
warning flags that may be issued or not issued if a certificate
chain is validated against that root key.
At present, my perception is that certification by the IPRA adds so
little additional trust in and of itself that it isn't worth the additional
certificate processing time. I therefore wouldn't put the IPRA's
key in my list of root keys, and would flag for exception processing
any messages or documents authenticated through a chain that
is rooted in an otherwise unknown PCA.
Can we now go back to the two basic questions?
1. Supposing that a PCA wishes to certify another PCA as
complying with its policies (e.g., if the U.S. government
adopts a policy for a subset of its users that is
harmonized with the RSA Commercial Hierarchy, but
for political reasons wants to maintain its own PCA),
how can either or both of the PCAs certify the other?
(I should make it clear that the cross-certification does
not have to be bi-directional, and often won't be.)
Maybe we should simply suggest that the users add that
second PCA to their list of root keys.
2. Are we convinced that burdening all the PCAs with
providing access to all of the CRLs from all PCAs
and all of the CAs throughout the world is worth
the cost?