I was surprised by the comment:
This has nothing to do with PCA cross-certification (which is
prohibited)...
I expect cross-certification to be relatively frequent.
Steve [Crocker]
I would expect that cross-certification might be relatively frequent,
but not transitive.
That is, I would expect RSA's Persona PCA to accept certificates
signed by TIS's medium security PCA (whatever the name will be?),
but not vice versa. Likewise, I would expect that TIS might certify
RSA's Commercial Hierarchy, but not vice versa.
However, this assumes that the only difference between these
various policies will be in the area of the stringency of
identification of the user, so that (perhaps) a strictly ordered
relationship can be created.
Unfortunately, I suspect that life will seldom be so simple.
Instead, there are likely to be varying degrees of policy
differences having to do with what the intended USE of the
digital signatures is, and trying to control the risks that may be
associated with them. This will have the effect of making the
various policies noncomparable, and incapable of being
hierarchically ordered -- Oranges vs.Apples vs. IBMs, as it were.
I believe that the availability of various PCA policies will be
driven by market forces, including services offered by the
PCA and the terms and conditions of the policy.
However, based on discussions with RSA on the policy
for their Commercial Hierarchy, I think it will be very difficult
to establish these policies in a vacuum, or one-on-one with
a particular organization. Few companies will be willing to
sign up for a particular policy until they can be sure that a
useful number of other users will also sign up, so that they
can reach critical mass. This tends to lead to a chicken-
nd-egg situtation, unless one particularly dominent user can
call the tune and establish a defacto standard. However,
it is difficult to think of a single organization (other than
the US Government, and maybe not even
them) that would have that much clout.
Instead, I think it will be necessary to form various user
groups or consortia of common interests to hammer out
a consensus as to what a mutually beneficial policy
should be in a more or less open forum,and then (assuming
the PCA is willing to agree) have everyone sign up.
With all due respect, I believe that it must be the members
of that user group, not the PCA by itself, and certainly not
the PSRG or the IAB or the Internet Society that must
decide whether or not to allow cross-certification between
PCAs, and if so on what terms.
If the PCA users group that I choose to belong to decides
as a matter of policy to certify (cross-certify tends to imply
transitivity) another PCA, then the PCA that is certifying
the other PCA should make arrangements to provide
access to that PCA's CRLs.
But there does not seem to be any point at all in providing
access to CRLs from a PCA that your PCA is not willing to
certify, for that whole PCA is CRLed (to coin a verb) by
default. CRL's for lower-level CAs and users are therefore
completely irrelevant.
Likewise, I don't see any point in having the IPCA
actually publish certificates for the various PCAs, since
the IPRA is not in a position to enforce ANY particular
policy. This would avoid an additional level of certificate
checking which would be pointless in any case. Or does
the Internet Society intend to establish binding contracts
with all the various PCAs, including sovereign governments?
Interesting concept! To paraphrase Hitler's comment about
the Pope, how many divisions does the Internet have
[to compel performance]?
Instead, I would suggest that the IPRA merely serve as a
clearing house for the various PCAs and their policies,
and let the user's groups decide which flag to salute.
It should also be noted that one policy may apply to
certification for the purposes of identification for
encrypted communication, and another for purposes
of accepting a digital signature. My company might not
allow encrypted communication with a competitor or any
other company for reasons of trade secret protection, but
it might accept a signed purchase order or a product
announcement or price list from that organization.
(That's why it's a shame that we didn't separate the
algorithms and the keys used for encryption from those
used for signing.)
Finally, regardless of the various hierarchies and policies
that may be established, it will be the users themseleves
that will decide whether or not to trust or confide in a
particular user. Business and/or personal alliances or
"enemies" may come and go, and policies may change.
Prudent implementors will therefore allow their users to
manipulate the choice of the root key to be used for
validating certificates, perhaps allowing multiple root
keys. In particular, I would like to allow my PCA, my CA,
and myself to certify any particular user and/or other CA,
in INCREASING order of assurance. This also speeds up
the certificate validation process.
All of this aside, if PCAs were to be allowed to certify other
PCAs, what mechanisms could be used? Could they just
issue a certificate for that PCA as though they were
another CA? Is the requirement to limit certifications to
two levels deep just a convenience, or is it a firm
requirement of the RFCs?
"The sound you are hearing is the sound of the
rubber meeting the road."