Warwick,
I would like to think that the issue of naming and CA naming was
orthogonal to the issue of top-down vs. bottom-up trust, but
I am afraid that the two issues have becme inextricably linked
in people's minds.
Many people on this list, and perhaps especially those who
champion the use of e-mail names rather than civil DNs, would
take the position that although they are using their employer's
workstation, communications links, desks, and time at work,
nonetheless their e-mail does not reflect their employers position,
but is only their own private thoughts -- even on a matter that they
are working on professionally.
They view their e-mail address as a simple routing convention,
and would argue that they could as well receive mail at home, or
via CompuServe or America OnLine. As anyone who has ever been
involved in a fraud or sexual harrassment case involving e-mail
can tell you, the privacy implications and other issues that revolve
around these positions become quite complex.
My view would be more along the following lines. You work for
BNR, I work for GTE Labs, Steve Kent works for BBN, and Steve
Crocker has a position of some authority within TIS. All of us have
a certain amount of influence within our own company (some more,
some less, perhaps), and we have some influence on technical matters
within the technical community.
Like it or not, when any of us say anything in public at all, including
public e-mail such as this list, what we say colors, and is colored by,
the reputation of our respective companies. No, I don't go and ask
my Director before I say something, much less get a vote by
the Executive Committee of the Board of Diorectors. So perhaps
what we say isn't "official" in that sense. But we would have to be
pretty naive not to realize that we have an obligation to be prudent
in what we say, and not promise something we can't deliver, malign
or defame an individual or company, etc.
To my mind, then, whether I am identified as Jueneman(_at_)GTE(_dot_)COM
or C=US, O=GTE Laboratories Incorporated, CN=Robert Jueneman
makes very little difference in my responsibility. I know that in
either case, identity implies attribution, and that to a certain arguable
extent, my employer has a piece of that identity and attribution.
What is important, and I think the primary reason for name subordination,
is to ensure that "Certificates R Us" doesn't issue a certificate that
says C=CA, O=Bell Northern Research, CN=Robert Jueneman.
I am not affiliated with BNR in any way, and such an implied
affiliation could harm me, or harm BNR, or both.
So _some_ form of name subordination is an absolute requirement,
and I am sure that we agree on that. The use of a DN rather
than an e-mail name permits a much more precise identification
of affiliation. In my case, technically I do _not_ work for GTE,
but rather for GTE Laboratories Incorporated, a wholly owned
subsidiary.
(Dr. Redmond, the President of GTE Labs, might be upset if I said
something that relected poorly on the Labs, but I assure you that Chuck
Lee, the Chairman and CEO of GTE Corporation, would be a lot
_more_ upset if he felt that I were speaking for all of GTE, as I
am sure that he feels that is his job, not mine.)
For that reason, I do not favor the use of CA names that correspond to
domain names in the e-mail address space, as some have suggested.
The reasons is that the domain names have much more to do with
addressing and networking issues than they do with corporate structure
and authority, and are therefore not as appropriate for this use.
But enough philosophy. Let's talk nuts and bolts.
I'm not developing a PEM implementation, so I'm willing to discuss
even sweeping changes if necessary to advance the overall
cause. On the other hand, it took us far too long to come to a
reasonable concensus on the existing RFCs, with the result that
people like Apple had to cut loose and go their own way with
PKCS becasue they had a product to ship and PEM wasn't ready.
I am therefore reluctant to change the standard once again in any
significant way without a very good reason.
It seems to me that slightly modifying the existing name subordination
rule to specify that only Country, Organization, and the series, if any,
of Organization Unit names have to match the name of the subject
woiuld achieve 90+% of your (and my) goals, with a minimal if any hit
on PEM implementations and no discernible impact on X.500 either,
and might be the best compromise.
The certification authority could then be named as a commonName
under the O and OU nodes, without creating artificial entries or
unnecessary additional nodes in the naming tree. (Once I found out
that many X.500 implementations keep all but the lowest link in the
tree in memory, for the sake of efficiency, I became much more
interested in having fairly flat names spaces!)
Better yet, as you have proposed before, we should create a new
attribute, caName, with the same syntax as commonName but a
unique OID to better separate the functions and eliminate confusion
with an employee named "High Assurance CA" Otherwise, one
employee could appear to be a CA and sign a certificate
for another employee, and thereby forge his name without him knowing
about it. This is another case of a rogue CA. for that reason, after thinking
about it some more, I _don't_ like the use of CN=Certificates R Us
as a CA name.
As you point out, this would permit us to have several CAs within one
organization, e.g., caName=GTE Labs EDI CA, caName=GTE Labs e-mail CA,
caname=Low Assurance/Test/Anonymous CA. I hope that it won't come
to the point where individual CAs have to have policies like the PCAs,
but this would allow that. It would also allow the different CAs to be
certified under different PCAs, without having to use the ugly "try the
various public keys until you find one that works" approach that
we use now.
I don't want to ignore or overlook any good ideas, however, and a more
general certification naming structure may be called for. So I urge
you and Francisco Jordan to think carefully whether this kind of
a pragmatic, get-the-job-done type of solution will really solve
the problem. But if you do agree, then perhaps a quick Internet Draft
(before Monday!) would be in order to put a firm proposal on the table.
Bob