Bob:
Based on a suggestion by Steve Kent, I had been planning
to use something like
C=US, O=GTE Laboratories Incorporated, OU=Employee
as the name for the CA, but this was more for convenience
in designating the status of the user. Extensions
could then include OU=Resident Visitor, OU=Contractor,
OU=Dependent, etc.
Granting that "unnaturalness" is in the eye of the beholder,
as has certainly be demonstrated recently, would such a
usage strike you as unnatural? Moreover, whould you
feel the need to create aliases for every name?
Perhaps I am wrong, but this looks to me a lot like a complete level
being added to the name tree purely for the purpose of satisfying CA
name subordination requirements. The typical directory administrator
(for whom PEM and CAs are an insignificant issue) may well consider
this unnatural. Directory administrators like to build their name
trees on corporate structures (for administration delegation and access
control reasons), and also have to take into account DSA distribution
requirements (for performance reasons). If at all possible, we should
avoid adding another constraint (the CA name warp) on the larger X.500
naming picture. Of course, aliases can always provide an (albeit
unwieldy) way around the problem.
Your OU=Employee approach will work fine (provided you can live with
the constraint of only one CA at the OU=Employee level), and may be
perfectly acceptable to everyone at GTE as "the" corporate name
structure. (If so, you do not need the aliases.) However, I cannot see
it being forced on all organizations - especially organizations that
have already established directory structures without being aware of
the PEM CA problem.
I have not been able to think all through the implications
of your Authorized Subtree suggestions, or Francisco Jordan's
rather similar proposals yet, but on the surface they seem to
merit.
I am somewhat afraid, however, that these additional issues
may be enough to sink the boat, given the apparent willingness
of some to give up nonrepudiation, DNs, etc. and just embrace
RIPEM or PGP.
The biggest issue seems to be that of "bottom-up" and "hierarchical"
(or X.500) philosphosies. I think the only sensible approach is to
progress both philosphosies together. There is clearly a need for
flexibility in certificate chain processing, which accommodates
different chain start-points and different trust models. It seems
necessary, in particular, to allow for different
starting-points-of-trust, e.g., the IPRA, other TLCAs, and self-signed
oxymorons or other cached trusted keys. However, in all cases it seems
worthwhile keeping the chain-processing rules (name subordination) as
well. Splitting the whole activity in two would be counterproductive.
The issue I am addressing in this thread is orthogonal to the
"bottom-up" trust issue and the EN-in-DN issue. There are several
issues on the table, and they need to be identified, prioritized, and
worked on.
As an admittedly temporizing suggestions, I would suggest
either using something like OU=Employee, or otherwise
and second best, O=BNR, CN=Certification Authority #1,
with the understanding that the name subordination rules
would not apply to CNs (or perhaps to any attributes other
country, organization and organizationalUnit?).
The latter-type approach constitutes a very simple modification to the
current rule and solves some significant real-world problems. It
eliminates two problems apparent in the former approach: (1) CA-names
warping otherwise-convenient directory trees, and (2) preclusion of
multiple CAs for a subtree.
Warwick Ford
?????????????????????????????????????????????