But where should we stop? Should we reject a DN for inclusion in a
certificate if it doesn't meet our understanding of what a
"reasonable" directory schema should be, even though Subschema
Administrative Authorities and/or Autonymous Administrative
Authorities can define their own unique schemas?
I can't parse the above paragraph because it speaks in terms of
directories, schemas, etc. From a PEM perspective, such things don't
exist. Is there a way to say the same thing in terms of lists of sets
of AVAs?
That was sort of my point. At present, I could presumably construct a
certificate that strung together legitimate X.520 attributes in a way that
made little if any sense from a syntactic perspective, UNLESS we
decide to impose all of the object class rules as well as the attribute syntax
rules.
Example:
C=US, OU=Wireless and Secure Systems Laboratory, givenName=Yair.
From the standpoint of being a valid distinguished name, this is perfectly
OK. (I am assuming that there is no other organization called the Wireless
and Secure Systems Laboratory except for the one I am in within GTE
Laboratories. And I know for a fact that there is no one within WSSL with
the given name of Yair except for Dr. Yair Frankel).
But from the point of view of a directory schema, this would certaily be poor
form, if not forbidden, because OUs are supposed to have a superior node
of Organization, and because (I am assuming without checking) givenName
should be subordinated to surname.
However, such a listing might be acceptable as an alias. The real question is
whether we should allow it as a DN within a certificate, and if not, what rules
do we use to exclude it?
With regard to your Sally a. Smith example, consider another member of my
group, Leonard D'Alotto. I don't know, but I can imagine that familial
variations
along the lines of d'Alotto and Dalotto may exist somewhere, yet should be
considered different people. If Sally's middle name were D'Alotto and another
Sally had the middle name of d'Alotto, they might well be two different people.
Are we then going to try to write an all-encompassing description of how to
form a "proper" common name, considering all of the cultural differences?
So what's the specific proposal? Ignore all syntax? Fine with me!
But I think that's different from what's expected.
I certainly don't have a specific proposal at this time, although the
"ignore all syntax and directory schema rules" sounds pretty good to me at
present.
The alternative would appear to be to insist that PEM implement ALL of the
X.500 attribute syntax, object class, and schema rules, even though the schemas
haven't been nailed down and may differ across directory service providers.
This would seem to be an extremely slippery slope that would almost guarantee
that we would never have a compliant PEM within the next decade, IMHO.
I suppose an alternate rule would be to say that PEM UAs shouldn't care, and
that "ignore all syntax and directory schema" is the rule, but that CAs should
apply human judgment to the creation of names that might be misleading?
At least this would solve the problem of what to do with an unknown OID -
look for an exact match, and otherwise conclude that they are different
entities.
BTW, as I understand it, doing a directory read that only gives you one result
is
probably dangerous. You should do a directory search, so that you would be
more likely to find similar names. But does this mean that we should be using
the Surname, givenName, initials approach? How about Soundex equivalents?
Right now, I think that all we can reasonably conclude is that two names are
either EXACTLY the same, or that they are different. I really believe that
trying to define equivalence classes for DNs in PEM certificates will lead
us down a black hole.
PEM ought not to depend on X.500. If it can be compatible, great. CAs
with X.500 directory support can probably do a better job of creating "good"
names. But we shouldn't burden PEM developers with the entire X.500
infrastructure requirements, I feel.
Bob