Bob,
We seem to have a major disconnect here. Cross-certification
refers to one CA issuing a certificate for another CA, and vice versa.
In the model defined in RFC 1422, there is no need for cross
certification between PCAs because the IPRA, acting as the root,
provides certification paths that lead to ALL PCAs, CAs, etc.
The existance of a certification path is INDEPENDENT of a
user's confidence in the trustworthiness of the identification
provided by a certificate validated through the path. You seem to be
saying that if a certification path exists to a PCA, CA, or user then
I am somehow bound to trust the certified entity. This is simply not
the case for PEM; making this inferrence would be a misinterpretation
of the certification semantics of PEM.
What you seem to want is access control, whereas what PEM
provides is authentication. If there is any access control provided
in a PEM environemnt, it is enforced by a user who examines the PCA
under which a certificate is issued and the name of the certificate
subject, and uses these two pieces of information to make a value
judgement. PEM does not attempt to embody an access control mechanism
in message and cerfificate processing, and this is clearly stated in
1421 (under what security services PEM does and does not provide).
In a sense, our model for PEM is like the secure telephone
model. The phone on my desk allows me establish a secure connection
to any other secure phone user. It identifies the users to one
another (as vouched for and relative to the name of a local
department, agency, or organization) and it provides clearance info
(vouched by the local authority, but constrained by the root of the
system to be withion the range allowed for by department, agency, or
organization). [Note the parallels to the name subordination rules in
PEM.] However, the secure phone deos not constraint who I talk to.
It provides me the authentication info and allows me, as the user, to
evaluate the identification info and make an access control decision.
That is what PEM does as well.
Mail-enabled applications, where human users are not directly
involved, might want to invoke an access control mechanism based on
the identificatyion provided by PEM certificates. One can imagine
creating access control lists for such applications in which each
entry consists of a PCA name and a user name (including star naming
conventions to avoid the need to enumerate individual users when
name-based groups would suffice) plus authorization attributes. This
would be a useful adjunct to PEM, but it is an addition required for
applications, not for inter-personal email.
So, I think that a major part of the concern you raise about
PEM certification seems to be based on a different model of what PEM
does. Your model seems to want certificate validation to succeed ONLY
if the entity being authenticated meets some access control model.
Yes, one could construct a certificate validation model that would
operate that way, but PEM did not do this and the decision is an
intentional one. I think most email users want to be able to send and
receive mail on a largely unconstrained basis. Personally, I may want
to make value judgements about the sender of mail based on
(authenticated) identification info, but I don't want to try to
program that value judgement, a priori, into my email system, and
certainly not at the basic authentication level. I am willing to
receive PEM messages from people certificated under various PCAs, even
PERSONA PCAs. I don't want to a priori exlcude users under any PCA,
nor do I want to have to explicitly make provisions to include users
under each PCA, since that precludes my receiving PEM email from them
until I add their PCA to my list.
Steve