Steve:
You stated that "A
major concern with current PEM naming rules is that one cannot have
multiple CAs (at least not CAs with different key pairs) at the same
point of the naming tree." This is not true.
From the PEM viewpoint you are right, but this does not help me. My
perspective is that of someone designing X.509-compatible
CA-infrastructures for large corporations, and, as a secondary goal, I
would like to see the same certificates usable with PEM. As things
stand, I am finding great difficulty in building structures with
certificates which conform to the PEM rules.
We already allow for this in the case where the multiple CAs
represent different PCA policies and we do not preclude it otherwise.
It has a slight performance penalty due to the potential ambiguity
associated with selecting the "right" CA, but this could be readily
addressed with the IssuerUID field in the 93 X.509 spec, or via
heuristic means that have been described previously.
My multiple-CA requirement arises in the non-PEM sphere, so the
multiple-PCA angle does not help.
The issue underlying here is the use of the same DN (as certificate
issuer) applying to different real-world entities. Maybe this is not a
problem (e.g., use IssuerUID as you suggest) until we want to use a
real X.500 directory to support our structure then, of course, things
start falling down.
I think the
better argument is that your proposal for a CA attribute would allow
more flexibility in naming a CA, compared to the current scheme, while
retaining a modified DN subordination rule.
Also, I don't think some of the examples you cited, for why
poly-instantiation of keys is not always feasible, are especially
strong arguyments. For example, BBN has developed mechanisms that
allow secure poly-instantiation using smart-card equivalent devices.
Nonetheless, I agree with your overall notion that it would be good to
have other means of dealing with the potential problem other than
requiring polyinstantiation (although the extent to which this will be
a real problem is as yet unknown).
I suggest we agree to disagree on this one. (While some of us may be
building products to deal with private key transport, some of us think
that one of the beauties of the PK digital-signature world is that we
can avoid the need to deal with such things.)
Also, since DN subordination does not apply to PCAs, I don't
see that the rationale you provided for a PCA attribute applies here.
Correct, I have no real requirement here. I only extended the proposal
to PCAs because it seemed a useful follow-on if we accepted the CA-name
attribute.
Your examples related to residential users don't seem to be consistent
with RCC 1422. Perahps I missed a detail of your suggestion there.
No, we are just hitting again the issue of using the same DN for
different real-world entities. I have requirements that the CA-world
and the X.500-world be aligned - I would really like to see PEM also
align.
...Warwick Ford