-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,06
MIC-Info: RSA-MD5,RSA,fhkxQhgNCVMLn1qLjSQaBiQlffACYGqnK6yqdLET4cA
h1zHS6uvdNs1QznGxEFtjoOmeDSi4oIWX9U7TWoWLR6ety+lQaBrmkmKn6HuwOA1
1wyHaGsAMAvEP7r31uaI2
...
As it turns out, I lobbied for an almost
identical scheme inside our group several months ago and couldn't get
anyone else to sign up for it; the strong preference was for unparsed
email names, e.g. EN = crocker(_at_)tis(_dot_)com(_dot_)
Isn't "crocker(_at_)tis(_dot_)com" easier to remember and put on a business card
than "C=US, O=Internet, OU=com, OU=tis, CN=crocker"? Since the former
is required for the email exchange, isn't the latter redunant?
Given that Rhys' method provides both forward and reverse mappings,
providing the same information either way, why bother with the
translation?
If you want to support distinguished name (DN) subordination that
follows the domain name system (DNS), that can be coded without
requiring changes to anything seen by the user, includiung the
distinguished name. If the policy states that you may only use an EN
in a DN if you own the matching DNS name, there is no uniquenes
problem.
For subordination, parse the EN domain and do DNS subordination. Yes,
subordination within a single AVA:
EN=crocker(_at_)tis(_dot_)com
is subordinate to
EN=tis.com
is subordinate to
EN=com
is subordinate to
EN=.
It may not be palatable to the X.500 community, but who are we trying
to please?
The biggest complaint I've heard from users about distinguished names
is that they're unwieldy and not the Internet/TCP/IP Way(tm).
crocker(_at_)tis(_dot_)com looks right. C=US, O=Internet, OU=com, OU=tis,
CN=crocker, while perhaps more palatable to some than C=US, O=Trusted
Information Systems, OU=Glenwood, CN=Stephen D. Crocker, is still not
the Internet way.
Your hack for handling the top level is interesting. Subject to
coordination with the pwoers that be in teh DNS community to make sure
we understand where DNS names are headed, your scheme looks
reasonable.
The only suggestion I'd make is to make sure there's a way to
correctly reconstruct names with "%" or any other e-mail address
oddities. We might need to use additional OIDs as stand-ins for "%"
or something. Maybe everything to the left of the "@" can be left
unparsed. (Is it guaranteed there's always exaqctly one "@"? I have
the impression that mail addresses can somet8imes have two "@".)
First, if you don't parse the EN, there's no need to worry about the
syntax. Second, and maybe more important, do we really want to make
an effort to support funky addressing? With current mailers and DNS
support, there's really no need for funky addresses with %'s, source
routing, and the like. Do we want to help propagate them?
user(_at_)domain is really all that's needed. My email address is
feldman(_at_)tis(_dot_)com, regardless of what host I actually use to read and
send mail and what routes it must take on the TIS internal network.
Isn't just having crocker(_at_)tis(_dot_)com so much simpler than
crocker%happy(_at_)tis(_dot_)com, crocker(_at_)happy(_dot_)tis(_dot_)com,
@tis.com:crocker(_at_)happy(_dot_)tis(_dot_)com and all of the other
combinations and
permutations that exist with all of the other hosts here?
Since Bob Juneman's address comes up in many examples, let me address
his address. The fact that we ever see a % in his mail is, in my
opinion, laziness on his sysadmin's part. There's really no reason it
couldn't always come from juneman(_at_)gte(_dot_)com or some such.
...
P.S. One enormous value of your proposal is that it does indeed fit
into the usual rules of name subordination and hierarchical
certification. This is a big win.
It's a win for the X.500 folks, but not the average Internet user.
Much more market share can be gained by pleasing the average Internet
user. user(_at_)domain is within the grasp of the average Internet user.
All of the talk about DN reform was the result of fear and dislike of
unwieldy, bureaucratic DNs by the average Internet user. Why take the
nice EN and make it look like the feared and disliked X.500 DN?
Mark
-----END PRIVACY-ENHANCED MESSAGE-----