Steve,
You are right that the IPRA acts in a special role in the
certification system described in 1422. It provide more services than
you cited in your message (e.g., a global CRL database as well as name
a conflcit resolution database, a set of uniform rules that all PCAs
can be trusted to adhere too, etc.), but still it's role is a different
one than PCAs.
Goven the current lack of a functioning IPRA it is reasonable
to provide facilities in PEM implementations to directly insert
public] keys for PCAs. But this is different from PCA
cross-certification, the topic that started this discussion. Since
PCAs do not have names that are distinguished in any way, if one PCA
certifies another, the resulting certificate is syntactically
indistinguishable from one that would be issued by a PCA certifying a
CA. Yet another PCA certainly would not, in general, be expected to
implement the same policies, so the semantic implications of PCA
cross-certification would violate the model defined in 1422. The
result would leave users unable to determine the policy under which a
certificate was issued, and the name subordination checking rule would
have to be bypassed (or would often reject paths). So, PCA
cross-certification, is not permitted under 1422 for a variety of good
reasons.
You observe that there will be other hierarchies and they
should be accommodated by manual insertion of PCA certificates. There
are several problems with this approach. Other hierarchies need not
adhere to any of the certification rules imposed on PCAs and CAs by
the IPRA. This could leave users with no ability to determine
authentication trust semantices with certificates issued under those
hierarchies, unable to know when they are dealing with PCA-like
entities, CAs, etc. There would not necessary be any global means of
acquiring CRLs for these other certificates, no name subordination
rules (which would allow CAs in these other hierarchies to issue
certificates for users served by CAs under the Internet hierarchy),
... So, given this long, but only partial, list what could go wrong
with a model that adds certicicate issuers outside the defined system,
I can't be enthuiastic about the "feature" of the "reference"
implementation as other than a very short term hack.
As for the use of other than DNs in certificates, I'll refer
you the PEM WG meeting minutes and a paper to appear in INET 93 on
that topic.
Steve