I begin to see the problem here.
What you are saying, I think, is that PEM should impose the "syntax"
rules (caseIgnore, etc) suggested for attributes listed in X.520 when
deciding whether two DNs are in fact the same.
How can it not impose the "syntax"? If it doesn't, then two strings
which represent the same value will be treated as distinct.
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?
I understand that equivalence classes of names are necessary for
directory searches and even reads. But are we certain that we need to
have such a construct for DNs in a certificate?
Total confusion here on my part. If Syntax rules don't apply to DNs,
are we free (obliged?) to treat all values as distinct if they don't
match exactly? Is a CA, for example, allowed to issue one certificate
to Sally a. Smith and another to Sally A. Smith, with the
understanding that these are *different* people?
I agree that we ought to require a certain amount of canonicalization
of the DN before we consider it acceptable for PEM purposes, and a PEM
CA could enforce those rules. But other than removing multiple
consecutive blanks, what else would we propose?
The issue that triggered this thread is undocumented OIDs. What
answer would you prefer, and once you decide, how does it affect
undocumented OIDs?
In particular, as part of the "CA Guidelines for Name Registration"
document that I am trying to put together for the ABA, I am suggesting
that organization names in particular be the precise legal name by
which an organization is known. Since that name is derived from either
a national registration authority (ANSI), or by virtue of being
incorporated or otherwise registered by the Secretary of State of a
state or province, or by being listed on a business license within a
state and locality, it would appear to me that there is one and only
one name that is allowable.
At the level of this discussion, "precise legal name" probably isn't
sufficient. I suspect there's nothing written down that says
INTERNATIONAL BUSINESS MACHINES
and
International Business Machines
are legally the same, but I doubt anyone would get far claiming otherwise.
If someone registers "IBM", meaning International Business Machines
Corp., and someone else is allowed by the Secretary of State of the
Federated Iislands of Micronesia to register as "ibm" meaning Itty
Bitty Movers, who are we to say that those names "ought" to be the
same?
Yes, if "ibm" (all lower case) and "IBM" (all upper case) are intended
to mean different entities, this is indeed an example of the issue.
I think that I'm suggesting that the issue of variant DNs within a
certificate is a red herring. Even if you don't know the syntax
associated with an OID that you have never seen before, we can tell
whether or not there is an exact match FOR PURPOSES OF COMPARISON
BETWEEN CERTIFICATES.
Not quite. I think you've just declared that a CA may use only one
form of a value when it issues a certificate. Unfortunately, that
also opens the door for issuing certificates for Sally A. Smith and
Sally a. Smith and meaning that they're separate people.
Suppose you're attempting to look up the certificate for the Sally
Smith you know. You look in some local store, and up pops a
certificate for Sally a. Smith. Is it the one you want? How would
you know whether there's another? (Well, I suppose some of this would
exist even if the CA had issued only one certificate, but it wasn't to
the person you hoped it was for.)
Trying to do more would simply come to grief with aliases in any case,
or so it would seem to me.
I've probably oversimplified this. It seems too easy??
So what's the specific proposal? Ignore all syntax? Fine with me!
But I think that's different from what's expected.
Steve