If PEM is going to use DNs, then you have to play by X.500's rules.
In X.500, a DN refers to an entity in "the real world" with respect to
that entity's role in the real world. DNs do not refer to multiple
entities, but may refer to an entity which is a collection of other
entities.
What this means is that MTR might have one or more DNs: one for MTR
in a business role, another for MTR in a residential role, perhaps a
third DN for MTR as a student at a university, etc.
However, the DN assigned to MTR in any role, may not be assigned to any
other entity--NO EXCEPTIONS. This is why it is important to have a way
of ensuring the unique assignment of DNs, and why that way should be as
simple-to-use and error-free as possible.
The NADF's SD-5 document defines such an algorithm for c=US and c=CA.
The algorithm doesn't always produce short or pretty DNs, but it
leverages off the existing civil naming structure, with its myriad rules
of intellectual (naming) property rights, so that the hard registration
questions are answered before the DN is generated. With this paradigm,
the Directory is where things are listed, not registered.
How does this relate to PEM? The answer is that use of DNs by PEM must
not behave differently than the 2nd paragraph above ("In X.500, ...")
In addition, PEM shouldn't worry about how DNs get assigned, nor try to
associate any special semantics with an arbitrary DN--unless it has
special knowledge about that DN. To do so is to go looking for trouble.
/mtr