Charlie,
Maybe you tuned in late, or more likely, the volume of messages has
been so great that you have skimmed some of them.
Let me say again that I am NOT trying to extend PEM to
handle EDI and other similarly structured applications where the
fined-grained access controls provided by yet-to-be-created-
and-standardized authority certificates are presumably the
most appropriate solutions. Those are laudable goals, perhaps,
but I would be content to merely handle routine business letters
for now.
Nor am I suggesting that PEM is "paralyzed." In fact I think it is
quite useful and usable as it stands, at least architecturally.
I haven't yet installed and operated any of the public-domain
or commercial quality PEM implementations that will hopefully
begin to flood the marketplace, so I can't really say whether
the implementations meet our operational needs or not.
In some cases, notably the issue of how certificate revocation
should be handled, I am addressing my belief that the
architectural mechanisms that have been defined to
date are not sufficient. But some of the forthcoming
implementations don't support CRLs at all (notably the
Apple OCE), so I think this is fair game.
With respect to the issue of what does or should constitute
an acceptable DN, I'd like to point out that the PEM RFCs
were recently revised to delete any discussion of minimally
required support for such attributes. I therefore assume that any
DN that is syntactically legal per X.509 should be admissable.
The RFC specifically does state that in the event of a DN
containing an attribute whose value or type is unknown to the
application, the application is to display the attribute as best it
can, if necessary as a hex or printable string. Until CCITT and/or
the NIST OIW people publish a stable list of attributes, the users
will probably have to make do with whatever tools are available.
In the absence of a workable scheme for solving some of these
real world problems, and without any agreement as to what attributes
are considered the core set, I have to object to your describing
what I have been saying as "kludging" the DN. It could equally well
be argued that using an X.500 construct in the absence of an X.500
directory was a pretty good-sized kludge to begin with, and that a
simple alphameric string containing the user's name, organization, and
address would have been sufficient for quite a long time.
As an systems architect of quite a few years experience, I am happy
to discuss these ideas with you in an architectural context, and I
am sure that we would both profit from the exchange of ideas.
But as a user or potential user, and more particularly as the more or
less self-appointed advocate, bigot, and annointed spear-catcher for
the rest of GTE in this area, I am assuming that most of the
architectural discussions should have been over long ago, that by
now the code is baking in the quality assurance oven, and that a
rash of beta versions should be showing up within a few months,
hopefully including those from organization like yours. I am therefore
trying to figure out how to go about making this system work, and
trying to anticipate the problems that the users are going to get into
and devise solutions ahead of time.
You are quite correct regarding the need for secure mechanisms for
key control, etc. But the examples I cited were not due to Trojan
Horses or security breaches, but rather due to sound business
policy reasons.
I WANT my secretary to be able to open and read my mail in my
absence, and to go to someone else on my staff if necessary to
decide how to respond to a question or request from one of my
customers, upper level management, etc. But I DON'T want her to be
able to sign my name to documents for which I alone am resp[onsible
according to company policy.
I don't like having to use a hack like roleName="Valid for encryption
only" -- I would prefer something that more easily machine processable,
But I don't know of any other way to indiciate that although this
certificate is valid for key exchange for encryption, it should not be
considered valid for ANY digital signature. If you can think of a way of
using one certificate and one private key for two different purposes
that are mutually exclusive, I'd like to hear it.
Likewise, the use of the roleName="For Management Confidential
correspondence and official signature use only" is intended to
dissuade a user from sending me mail which only I can read,
and not my secretary or staff.
Once again, if we had aX.500 directory, or if pigs could whistle,
we cold simply look up these kinds of things, and they wouldn't have
to clutter up the DN. But it really doesn't matter that much, I think.
Although a multivalued RDN is a little awkward to search for, you
probably won't know my exact organizational structure in any case.
So you will end up doing a BROWSE, rather than a READ, but you will
eventually find what you are looking for.
Of course we can always agree to disagree on these issues, in
which case I will go off and implement whatever solution fits
my user's needs best. But I would at least hope that I have adequately
explained my position, and that we don't disagree out of ignorance.
Bob