Ken
I believe you to be confusing the argument with OSI Directory theory,
without benefit. Tom should just learn to really read ASN.1.
The central point of NADF existence is/was surely to assert that, based
on n years of working with std name forms (which generically allow
many things), certain schematic practices (well described by said group)
would allow a given community to actually interoperate now --- without
prejudicing the future, or, current effectiveness in the security area.
OSI was based on the notion that profiles would make reality possible. Surely
Tom's reading of pure CCITT standards is that of a newcomer --- one
who has to learn that, yes, its subsequent provider agreements
which really matter, within the common framework stated by X.???
On the substantive issue, I would consider TIS to have been over strict
in requiring even international certification of identities to require naming
based on US (NADF) rules. That naming be schematised over and above the
suggestions of X.5xx, is now obvious; that PCA/adminstrative security policies
should actually impose restrictions as the embodiment of naming and
certification authorities, is not.
Perhaps the underlying problem of PEM deployment is precisely the fact
that it, verily, assumes too much of OSI. Deploy CAs on any old basis,
with any old std-naming, with little or no assurance, is surely the way
to go. As communities begin to care --- after reflection about assurance ---
then they will auto-impose beneficial authority rules.
>From: Ken Rossen <kenr(_at_)com(_dot_)shl>
>Subject: Re: DN's formation
>Date: Wed, 21 Jul 93 16:06:39 EDT
>According to [9594-2 | X.501], leaving off the last RDN
>("last," that is, using the notation employed in this
>discussion so far) must also yield the name of an object.
>
>So while Tom's examples below may refer to technically
>valid Distinguished Names, from a Directory point of
>view they imply the existence of (referring to the second
>example) some object class named by an OrganizationName
>and a CommonName together, and which can have as a
>subordinate some other object class named by the pair
>Locality and CommonName.
>
>Offhand I'd say that none of the object classes laid out in
>[9594-7 | X.521] would work in quite this way, but the
>Directory certainly doesn't prevent you from making
>such classes up.
>
>Now I hasten to add that I realize we are *not*, in fact,
>talking about the Directory, but rather about PEM, which
>although it employs the DN concept from the Directory
>standard, does not necessarily deal with Directory
>objects.
>However, if it is still envisioned that PEM will someday
>use an X.500-based Directory as a certificate and CRL
>respository (for example), then keeping these
>additional restrictions in mind may be important.
>
>
>
>> >From a strict application of X.501 I can see that, but what about
>>
>> { (c=US); (st=California); (o=DBC); (l=Mountain View);
>> (l=Santa Clara)}
>>
>> >From my reading of the X.500's this must be legal.
>>
>
>> This is legal because within each RDN the attributes are
>> distinct. The localilty attribute is allowed to appear
>> in more than one RDN. [...]
>>
>
>> And so should
>>
>> { (c=US); (st=Confusion); (o=DBC, cn=MTRose); (l=Santa Clara,
>> cn=Marshall)}
>>
>
>> This is also legal, for the same reason
>>
>
>
>--
>KENR(_at_)SHL(_dot_)COM
>Systemhouse