Warwick,
The thread that your proposal kicked off uncovered so many
other issues that I've have lost the original context
of you caName proposal.
Let me resummarize that context as follows.
PEM currently requires a certification authority (CA) DN to be the same
as the DN of a DIT node somewhere within the usual naming structure
(e.g., O, OU, or SP). The CA is then permitted to issue certificates
for subjects in the DIT subtree of that node. This has the following
problems:
(a) The CA must share a directory entry with the (e.g., O, OU, or SP)
node entry; this is a problem as the CA is generally a different
real-world entity hence needs different attribute values.
(b) There can be only one CA corresponding to any DIT (e.g., O, OU, or
SP) node. I previously noted some problems with this restriction.
There is also a requirement that it be easy to determine, in examining
a general certificate chain, if a certificate has been issued by a PCA,
a CA, or a user.
Could you look at my suggested revison to X.509 and
comment as to how your proposal would work under
such a scheme?
I think your proposal helps satisfy the latter requirement, as a
certificate for a particular DN/public-key could carry an attribute
indicating whether or not that public-key can be legitimately used for
signing another certificate as a CA, a PCA, or (by default) not at all.
It could also help with the first requirement, but only if you develop
a full attribute-based scheme that completely replaces name
subordination.
My own view is that your proposal has strong merits for consideration
in a future project to extend X.509 certificates (for use in X.500,
PEM, X9F1, and elsewhere).
However, I think we can get X.500 and PEM onto the same track very
quickly with less drastic measures. Let us first make some minor
adjustments in naming conventions, to allow PEM to mesh with the X.500
directories that organizations are starting to build up. We have a few
proposals on the table that achieve this, varying in such respects as
whether or not new X.500 naming atributes are added. Selecting the
right proposal of this type does not seem unduly difficult.
After we solve this, let us look at adding capabilities through the
attribute-certificate and/or extended-X.509 certificate approach.
There are clearly several issues to address, migration being a major
one.
Warwick