Hi Steve,
... I think it is quite clear from the unfortunate problem we
currently have with the Apple AOCE software that hard coding the root key,
ANY root key, into the software would be a mistake. (To the best of my
knowledge the IPRA is not yet operational, so the public key for the
IPRA is not yet available even if someone wanted to hard code it.)
Forgive my ignorance, what problem is it that you are referring to ?
Because the current AOCE release imbeds the public key of the RSA
Commercial Hierarchy as its (only) root, it almost by definition makes
the Commercial Hierarchy a de facto standard for business uses. Anyone
contemplating using digital signatures for such purposes would either be
pretty brave or pretty foolish to ignore that potential market.
Unfortunately, to the best of my understanding we still do not have a
concensus as to what the policy statement for that PCA is, should be, or
will be. The fact that both residential users and corporate CAs will be included
in the same PCA makes drafting of an appropriate policy much more difficult,
IMHO, because of the different needs and potential liability concerns of the
different players.
In effect, the deal with Apple created an 800 pound gorilla -- a "severe
opportunity," and I don't think that we in the community have quite come to
grips with this yet. This is why I have suggested the creation of some sort
of a user's group of both corporate and residential users or potential users
of the RSA-CH, so that we can mutually work through these issues and come
up with a PCA policy that will satisfy the greatest majority of the users. This
in
turn might create a certain momentum to help persuade reluctant or nervous
corporations to go ahead and sign up as CAs.
I think what you are indicating is that the message and cryptographic
constructs of PEM may have value outside of the strict interpretation
of the certification hierarchy defined by RFC1422. I too believe this
to be the case.
I have implicitly been rying to address the needs of a wider community
than "just" the PEM simple e-mail paradigm and trying to consider an overall
public key infrastructure that will eventually become global in scope, and
not limited to the Internet community.
However, as a practical matter I am beginning to see a tremendous number
of policy and legal issues that will have to be overcome within most
corporations
before they can feel comfortable with the widespread use of any system that
implements any form of digital signatures at all. As one corporate lawyer
expressed it, "Even if we were succcessful in pursuing a case (either as
plaintiff or defendant) all the way to the Supreme Court and thereby established
a binding precedent, we would have lost, becasue it is our job to keep our
clients out of the court. For that reason, we are very conservative as to what
we would recommend in the way of new technology, and especially in areas
where there is no case law, no enabling legislation, and no judicial precedent."
For that reason, if we are to make use of digital signatures at all, it may
become
necessary to start small, with non-connected islands of CA domains, where the
public key of that CA is deliberately withheld from people outside of the
limited circle of the trial, in order to limit the potential exposure or
liability.
If the existance of a PCA becomes a practical necessity from the standpoint of
existing PEM implementations simply not working without one, then it may
be necessary for corporations to set up their own internal PCA, and not
broadcast the existance of that PCA or its public key to the rest of the world,
and certainly not to the IPRA. If and when companies become willing to take the
first cautious steps towards a more liberal use of digital signatures, it may
have to be in the context of a bilateral trading partner agreement.
I sincerely hope that I am being unduly pessimistic. This certainly wasn't what
I had in mind when I first started working on these issues -- I had expected
that
individual users, including corporations, would be able to exchange digitally
signed messages, even for middling sized purchase orders, without having to
set up all of the bilateral arrangements that have been necessary in the past.
Now, however, I am afraid that it may be necessary to create some form of
MasterCard or other type of 3rd-party middle man or clearing house to facilitate
those transactions. Too bad -- I hope I'm wrong.
..I would suggest that although
there are many valid reasons why we imposed the name subordination
requirements for PEM, there may be certain instances where it may not be
achievable or even desirable...
...Exceptions may therefore have to be made, and if we have to
make them at all it might be nice to have a general-purpose mechanism.
Allow me to force the issue... Should the name subordination
requirement in RFC1422 become a policy issue to be determined by each
PCA ?
I was suggesting that individual users may have to make the decision as to
whether or not to enforce name subordination, based on their individual
circumstances and their correspondents. Should it be a policy option at the
PCA level? I don't know.
The reasons for name subordination are pretty good -- particularly if you
assume
that users may be mislead by a long chain of certifications. In the case of a
rogue CA that tries to mislead people, name subordination also limits the
damage to the user's under that CA. Assuming that in most cases the CA will
be the employer of most of the users, that seems appropriate.
But now lets think about a CA that has a looser relationship with the users.
For example, what if a company such as Apple or GTE Mobilcom or the Michelin
tire company wants to certify its dealers, so that they can exchange purchase
orders, etc. It certainly would be awkward to have one organization under
another one, e.g.,
C=US, O=Apple, S=MA, L=Boston, O=ComputerLand
Clearly Apple does not want to have any deep pockets responsibility for
anything that ComputerLand might sign.
Likewise, what if Bank of America wants to issue certificates to its
customers? In fact, what if ANY private or public organization CA other than
a civil government issues a certificate to a residential or business customer
without either a contract or a subsidiary relationship -- what is implied by
name subordination?
Do you have other examples of where name subordination is not desirable,
or at least should not be mandated? (It should perhaps be observed that
only PEM has the requirement for a PCA and an attendent policy at all.)
What happens if an organization creates a certificate hierarchy that looks like
a PEM hierarchy, but doesn't enforce the name subordination policy?
Bob