Bob,
Not only do we have different models of what is useful from a
secure mail system, but we also have different understanding of how to
make use of the proposed structure to achieve various goals.
For example, in your environment you would like a user to be
able to understand the "trustworthiness" of a message originator
without looking at a lot of info. Well, that can be accomplished
using the infrastrcuture defined today. Users may tag all the PCAs
that they (or their company) trust with the same or a similar local
alias ("GOOD GUYS R US"). Then, a compliant PEM system would display
exactly two pieces of info for the user wrt any incvoming message: the
PCA name (which would be "GOOD GUYS R US" for all the PCAs that are
"trusted") and the DN of the originator. That's a pretty small amount
of data to ask a user to examine. It permit the user to receive mail
from other originators who are certified by PCAs that are no so
trusted, and they could all be (locally) labelled ("UNTRUSTED
SOURCE"). This is a means of using the existing system to achieve
what I think you might achieve by other means.
Contrary to the concerns that your expressed, there is no
requirement in PEM for a user to read every line of a certification
path. Moreover, in general I expect a user will interect with
individuals who are covered by PCAs with which the user is already
familier, so reading the PCA policy statement wil also be unnecessary,
on a steady state basis. However, the system defined in 1422 allows a
user to add to his list of GOOD GUYS easily, at his discretion, with
information and an infrastructure that is electronically accessible.
Your description of having to examine all the DNs in a certification
path is precisely what might happen if there are CAs that are NOT
covered by the IPRA common policy, are not constrained to certify name
subordinated users, don't publish policy statements, etc.
Admittedly, the approach I suggested above permits
PEM-protected communication with those "other folks," but I am hard
pressed to believe that that is a bad feature for the vast majority of
users. Admittedly, you could design an alternative, closed system in
which the public key for each PCA or CA of interest is directly
entered into each user's local cache. However, that is clearly not a
scalable system and it is contrary to the general thurst of Internet
technology. (For example, most of the Internet has left the HOSTS.TXT
world behind and uses the DNS, indicative of the sort of dynamically
extendable system we are trying to create with the 1422 certification
scheme.)
As for "content free" certification, methinks you protest too
much. The question answered in 1422 is not WHAT an entity is
certified to DO, but WHO the entity is certified to be. This is a
fundamental distinction between inputs to rule-based and
identity-based access control systems. The infrastructure is design
to supprort applications that might make use of the former, not the
latter, type of access control
What I have heard you ask for in many instances is
certification that an individual is authorized to engage in some
financial interchange. That is a rule-based authorization. I suggest
you look at what the ANSI X9F1 committee is doing. They make use of
X.509 certificates for authentication and other certificates for
fiduciary authorization purposes. That is a reasonable use of
complementary certificate-based systems. But it is not reasonable to
try to put all that info into one certification system, unless you
want to create a custom system for EACH user community, since each
community will have different ideas about what trust semantics should
be associated with certified entities. That is not the sort of
(community-specific) standard the Internet community tends to produce.
The infrastructre defined in 1422 is general enough to
accommodate a wide range of PCA policies, without unduly constraining
the policy space as a whole. To that extent, you are right in
characterizing the IPRA common policy as the LCD for all PCAs. I
maintain this is a feature, not a flaw. The IPRA has an ability and a
responsibiluty to decertify a PCA who fails to abide by the common
policy. That is another reason to have an IPRA, in addition to the
usual desire to avoid order n**2 bilateral agreements between PCAs, ...
Could the Mafia run a PCA? Yes, they could. They run large
banks in various parts of the world (maybe in the U.S.?), so I doubt
that our requirements for being a PCA would be hard for them to
satisfy. A Mafia-run PCA could either abide by its PCA statement, or
it could fail to comply. If it abides by its published policy, it is
a legitimate PCA. if it fails to abide, it could be decertified
(though the ISOC might want to check on life and property insurance
policies before adding that PCA to the CRL). A natural side effect of
adopting a system that admits a very broad range of policies is the
need to accommodate some policies that are not acceptable to some set
of subscribers. However, so long as the subscribers can be advised of
the policies, this seems to be an equitable approach. We live with
this situation all the time as consumers, but with less "truth in
advertising" in the titles of variuous vendors.
I cannot answer the first question you posed, because it is
simply orthogonal to the certification system defined in 1422. PCAs
don't certify other PCAs under this system. As I noted in my message
to Steve Crocker, having users add another PCA key to their list is a
fine interim capability in the absence of the IPRA, but the term
"cross certification" is an inappropriate way to characterize that
action. If you want to develop another certification system in which
real PCA cross-certification is feasible, I suggest you write a
document comparable in scope to 1422 and submit it as an Internet
draft.
My response to your second question is yes. The current
system, because its goal is to provide a large scale, fully
interoperable certification system to the Internet, must provide a
basis for any user to acquire the CRLs need to validate the
certification path for any other user in the system. We have chosen
the PCAs a access points for this capability, although that could be
changed over time if commonly available directory systems (X.500 or an
extended DNS) hold the requisite info. Note that we have defined (RFC
1424) a mail-based access mechanism, since some Internet users would
not have other than email access to such databases. A smaller, closed
system could do less, but the creation of standards for closed,
limited scale systems is not the primary goal of the Internet
standards process.
Steve