Warwick,
I must note that although I liked the proposed means of
allowing the CA DN to be different from the organization, that your
primary rationale for doing so it not correct. 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.
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. 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).
Also, since DN subordination does not apply to PCAs, I don't
see that the rationale you provided for a PCA attribute applies here.
Your examples related to residential users don't seem to be consistent
with RCC 1422. Perahps I missed a detail of your suggestion there.
Steve