Steve,
The OSI-DS working groups already specified an object identifier for domain
names and the corresponding "object class". The following is taken from
RFC-1274:
8.3.7. Domain
The Domain object class is used to define entries which represent DNS
or NRS domains. The domainComponent attribute should be used for
naming entries of this object class. The usage of this object class
is described in more detail in [3].
domain OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN {
domainComponent}
MAY CONTAIN {
associatedName,
organizationName,
organizationalAttributeSet}
::= {pilotObjectClass 13}
....
9.3.21. Domain Component
The Domain Component attribute type specifies a DNS/NRS domain. For
example, "uk" or "ac".
domainComponent ATTRIBUTE
WITH ATTRIBUTE-SYNTAX
caseIgnoreIA5StringSyntax
SINGLE VALUE
::= {pilotAttributeType 25}
The object identifiers are defined in the same RFC as:
7. Object Identifiers
Some additional object identifiers are defined for this schema.
These are also reproduced in Appendix C.
data OBJECT IDENTIFIER ::= {ccitt 9}
pss OBJECT IDENTIFIER ::= {data 2342}
ucl OBJECT IDENTIFIER ::= {pss 19200300}
pilot OBJECT IDENTIFIER ::= {ucl 100}
pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
The object identifier used for the "domainComponent" attribute would thus be:
domainComponent OBJECT IDENTIFIER ::= {0 9 19200300 100 1 25}
Using this definition, and using the abbreviation "D" for domain component,
email addresses like:
<Christian(_dot_)Huitema(_at_)sophia(_dot_)inria(_dot_)fr>
<crocker(_at_)tis(_dot_)com>
would be represented in X.500 syntax (using the UFN notation) as:
<CN=Christian.Huitema, D=sophia, D=inria, D=fr>
<CN=crocker, D=tis, D=com>
Indeed, we are merely using the X.500 syntax here - the chances to effectively
dploy an X.500 directory using these names is scarce. Also, the particular
choice of an OID embedding the X.25 network address of UCL is questionable.
But then, as you said, the problem is more about being practical than being
ugly.
On the practicality front, there are a couple of very strong requirements
derived from the X.500 experience + the need to keep the PEM "path
verification" available:
1) The translation must be completely systematic. No mapping tables,
no fancy algorithms. The solution here meets this criteria: the only
algorithm in use is based on the Domain Name syntax (separate it is
tokens) and on the Common Name syntax for the "left hand side". This
poses one small problem however as X.500 impose to only use "printable
strings" in the "Common Name" attribute. Some frequently used
characters like "_" are not in this set. The "encoding of special
chars" suggested by Rhys Weatherley has proven a major source of
troubles in X.400 gateways - maybe we need to use a new attribute
type here and allow an "IA5" syntax.
Declaring cleaner OIDs for the DomainName components and the left hand
side would be a shade less ugly.
2) The structure must exhibit a clear hierarchy, so that we can reuse
the PEM certificate verification rules. The proposed mapping does keep
this hierarchy. In true form, we should introduce in a revision of
1422 the notation of a "domain CA" similar to the "organizational CA".
So, I believe that nothing is really stopping us from experimenting with
domain name based certification...
Christian Huitema