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.
My 2cents worth:
The X.500 naming schema is important. PEM was not developed, nor were
X.509 certificates and the PEM naming rules developed in a vacuum.
The suggested DIT was considered and, I would argue, adopted as
specified. PEM restricts itself to attributes which are part of
object classes which are specified in X.520 and suggests a naming
schema compliant with the suggested DIT precisely so that it can
take advantage of the Directory.
The Directory supports expansion by allowing attributes to be
specified and referenced by object identifier. These attributes
DO NOT automatically become elements of the DIT.
As a practical matter, it is not trivial to change a DIT in any
DSA implementation I have seen. Typically it requires that
a new DSA be built and the information from the old database
be copied. (Try changing the size of your Unix root partition
and you will see what I mean).
Consequently I conclude that PEM can define attributes to support
whatever functionality it requires, but cannot realistically expect
these attributes to be adopted as distinguished naming components.
John Lowry