Matthew,
There are several motivations for making PCA DNs be OUs with
an explicit indication of the function. A major motivation here
arises because each of these organizations will probably be a CA in
its own right, irresepctive of its role as a PCA. In its capacity as
a CA, it will issue certificates for individuals affiliated with the
organization and maybe for subordinate organizations within the
parent. In its role as a PCA, it wants to differentiate certificates
issued to organizations that are NOT affiliated with it, except
through the PCA role. Thus, for example, it seems natural for TIS to
have a CA certificate that says: C=US, S=MD, O= Trusted Information
Systems. Under this certificate it can issues user certificates and
certificates to subordinate organizations, e.g., its offices in CA,
MN, and the UK. So you might see C=US, S=MD, O= Trusted Information
Systems, S=CA as another CA certificate, signed by the TIS CA. TIS
also wants to have a separate certificate for its PCA role, and that
certificate should be descriptive (a major rationale for using DNs!)
in its name for the PCA as an OU related to TIS. Thus C=US, S=MD, O=
Trusted Information Systems, OU= Residential PCA is a reasonable DN
for this part of TIS operating not as a CA for TIS affiliates, but as
a PCA for other organizations.
In this light, I don't see the use of OU as a hack, but as a
natural means of distinguishing a part of the organization that is
offeering the PCA service, separate from the CA parts) of TIS. There
is no requirement in 1422 that such an OU have a name that includes
the term "PCA" in it. I think people have merely tried to construct
descriptive DNs that refelct the fact that being a PCA is but a part
of their bsuiness.
Of course, X.500 does not embody the concept of PCAs, so they
talk onoy in terms of CAs, but PCAs are just CAs with very explicit
semantics and a specific location in the Internet certification
hierarchy. They (and the IPRA) represent the "breaks" with the X.500
DIT, to allow for the explicit introduction of policies into
certification, while preserving DN subordination at lower tiers in the
system. I don't think there really is a need to introduce a new
attribute into a CA object class, but maybe I missed the thurst of
your argument of why it might be needed.
Steve