Greg,
As noted in another message today, keep in mind that alias
entries do not contain certificates. I'm afraid this calls into
question much, but not all, of the analysis in your message.
There seems to continuing confusion about the rationale for
requiring CAs to certify only those entities with subordinate DNs.
While this is useful in ensuring unqueness of DNs in the absence of
ubiquitous X.500 directory service, it really has a much bigger
justification. As an analogy, my employer issues me an ID badge that
identifies me as the Stephen T. Kent who is an employee of the
Communications Division of Bolt Beranek and Newman Inc., in Cambridge
Massachusetts in the U.S. It would seem silly for IBM to issue me an
ID badge which identified me as that individual. The reason is that
one expects BBN to vouch for my identity as an employee of BBN, but
would not trust IBM to vouch for my identity as a BBN employee. The
DN subordination rule is a syntactic means of enforcing this natural
"who do you trust to vouch for a name" rule.
Note that if IBM hired me as a consultant, under contract from
BBN, it might be resaonable for IBM to issue me a badge (certificate)
identifying me as affiliated with IBM, in a consultant capacity
{perhaps c=US, O=IBM, OU=consultants, CN=Stephen T. Kent}. This badge
issuance model helps motivate the certification model in PEM.
Thus, in the earlier discussion, many folks are likely to have
a certificate as a residential person and as an organizational person.
While it is technically feasible for these two certificates to contain
the same key, but there are good reasons for the keys to be distinct,
as observed earlier. Depending on the organization's decisions, one
also might have use of a certificate representing an organizational
role which an employee is occupying, e.g., purchasing manager, which
would almost certainly contain a different key, which would be
retained after you moved on to occupy another role.
Steve