Russ:
My concerns is simply theone voice by Mike Roe, in practice the
intoduction of
new attribute types has been shown to be difficult. If you can show a
counter
example, then I might withdraw my objection. If we can show that the
new
attribute will not seriously break existing DSAs or DUAs, then I
really like
your suggestion.
Mike Roe's concerns seemed to be with X.400 '88 (which is nothing to do
with this debate) and with the claimed need to upgrade "all DSAs in
"the world" (which is definitely NOT the case). Let me try to spell
out the real impacts of adding a new X.500 attribute, looking first at
DSAs and then at DUAs.
DSAs: The DSAs that would need to be upgraded to have a CA attribute
added to their schema are (a) a DSA holding a CA entry and (b) DSAs
holding knowledge references to a CA name. In general, case (a) means
that when an organization operates a CA and wants an X.500 entry for
that CA, the DSA used (most likely a DSA belonging to the same
organization as the CA) must have the attribute type in its schema.
This is true when any attribute type is added, and many organizations
have requirements and plans to add their own private attribute types.
DSAs I know (including Quipu and commercial implementations) provide
for such schema additions in a straightforward way. Case (b) seems
like a non-issue in the CA-name case, as the only DSA needing a
knowledge reference to the CA entry is the DSA holding the superior
(e.g., O or OU) entry. This DSA will almost certainly belong to the
same organization as the DSA holding the CA entry; in fact, in the vast
majority of cases, I expect the CA entry and the superior entry would
both be held in the same DSA.
???????????????????????????????????????????????????????????
Apart from the above, there is no need for other DSAs to know of the
attribute. X.500 name resolution involves matching of prefixes which,
beyond the immediately superior node (e.g., O or OU), will not use the
CA-name attribute at all. Of course, if a DSA implementation had not
taken the possibility of unknown attribute types into account, it might
have trouble with such a DN (e.g., its parser might break if it tries
to fully parse the whole DN). Again, this is not a problem with DSAs I
know, including Quipu. If some DSA implementations have this problem,
I believe they should be fixed because if they do not run into trouble
with PEM CAs they will run into the same trouble with something else.
DUAs: With DUAs, those that need to manipulate the CA entry need to
have the attribute in their schema. Firstly, this will include (at
least some) DUAs in the organization that operates the CA, in order to
maintain the entry. Again this is no different to when an organization
adds its own private attribute types; DUAs should provide for such
schema additions in a straightforward way. Secondly, other DUAs
affected are those outside the organization that need to read from the
CA entry. This will include DUAs associated with PEM implementations
or other security applications. I expect this is a manageable
community of DUAs, given our current state of deployment of X.509-based
systems.
Apart from the above, there should be no impact on DUAs. If some other
DUA happens to pick up a CA entry (e.g., in a search op) then it will
not be able to present that attribute nicely in a user interface. To
me, this does not seem a significant problem.
I am not suggesting that addition of the CA-name attribute will be
totally painless, but it seems to me the pain will be mostly localized.
It is also pain that X.500 systems must learn to cope with at some
stage anyway.
...Warwick Ford
???????????????????????????????????????????????????
???????????????????????????????????????????????????????????????????????