Russ:
Boy, this discussion that you started has taken many tangents.
Yes, I must admit that I am a little dumbfounded by some of the recent
exchanges (Many of which are clearly founded on ignorance of the
technical bases we have). In my view:
(1) X.500 naming and X.509 give an excellent base for public-key
infrastructures of any type. One point to note is that an X.509
certificate does no more than bind a public key to a name for an
*entity* that holds the corresponding private key. When used for
digital signature purposes, the X.509 certificate conveys very little
*attribute* information; this is why we use attribute certificates in
X9.30-3. The attribute certificate approach may prove to be all that
is needed, but maybe extensions to the X.509 certificate format will
also be needed at some stage.
(2) The existing PEM conventions, and their use of X.509, are very
sound. There is one problem, regarding the naming convention for CAs,
arising as a side-effect of the name subordination rules. My original
proposal here was simply an attempt to correct this (comparatively
small) problem. If that problem is corrected, I think we can achieve a
situation which allows the PEM CA infrastructure to interoperate with
any other X.509-based infrastructure, e.g., digital signatures for
electronic commerce.
My understanding is that it is realtively easy to add attributes to
directories
UNLESS the new attribute will be used in naming. Steve Kent and John
Lowry
have each made recent postings discussing this topic so I will not
repeat the
arguments.
I am not aware of a particular problem in adding naming attributes,
except when a new attribute-syntax is required. In the case of the
CA-name attribute, an existing syntax (caseIgnoreStringSyntax) was
suggested.
Your suggestion includes a new attribute that is used in as part of
the
Distinguished Name for every CA. This looks easy to specify, but hard
to
deploy. Am I still missing something?
The main goal of my preceding exposition was to explain the impact of
deploying the change. Only a very limited set of systems is affected.
I know some DSA systems can be easily reconfigured for new attributes,
but it would seem other DSA implementations have problems.
I disagree. When DSAs use strong authentication, their certificates
would have
an issuer that is a CA. Of course, the CA's Distinguished Name would
include
the new attribute.
OK. *IF* you have an installed base of strongly-authenticating DSAs and
if you want to use the same CA for PEM and for DSA-authentication, you
would need to upgrade the schemas in those DSAs too.
Again, every DUA that uses strong authentication will encounter the
new
attribute. If we are successful in deploying certificate-based key
management
for PEM, then the Directory will very likely use the same technology
for
authentication. I hope that the successful use of certificates in PEM
will
lead to the use of certificates in other authentication applications.
After
all, this is the reason why PEM adopted the X.509 certifcate
format....
We are now mixing up two different issues. What I was originally
addressing was the impact on EXISTING systems of introducing a new
CA-naming scheme. Of course, if we do introduce such a system, and if
it becomes widely accepted, then the systems that use it will clearly
have to understand it.
I still think that the pain will be global rather than localized.
You may be right, but let us weed out the misinformation before making
a final assessment.
Should we decide that the pain must be endoured to achieve our desired
result,
then we should do it immediately while there are relatively few DSAs
and DUAs
deployed.
I completely agree. However, note that I am not wedded to adding new
distinguished attributes if there are real objections and if we can set
up a suitable CA-naming convention, using existing attributes. My goal
is to enable PEM CA names to fit properly into the typical X.500
organizational name tree (which I believe will help get PEM into the
typical organization).
Warwick