I am looking at possibilities of addressing the DN requirements of PEM.
Certain entities may be willing to have X.500 directory listings, but may not
have available canonical-schema X.500 (geographical/organizational)
registration authorities available to them.
"Users who are not registered in a directory should keep in mind likely
directory naming structure (schema) when selecting a distinguished name for
inclusion in a certificate." [1422 3.3.4]
We had previously always understood that there would be no attempt
made to actually store the DNS registered local and domain components
of Domain Names in the DIT.
This would then be attempt at (possibly) storing some of that information as a
means for naming otherwise un-X.500-named entities.
As DNS is currently in use providing names, an interim solution of using 1279
as a possible naming base for PEM users without X.500 DSAs looks plausible.
Is this now the proposition?
<mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>:
<10633(_dot_)745688441(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
We could just as easily define a new certificate structure using RFC 822
addresses (local(_at_)domain). ...
<D(_dot_)HadjSadok(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk>:
<9308190938(_dot_)AA27259(_at_)TIS(_dot_)COM>
I am in favour of such a certificate structure, then we won't have
to worry about how to map an address to a DN, where to get it from
what DN to use,...
<M(_dot_)Wahl(_at_)isode(_dot_)com>: <5737(_dot_)745759946(_at_)isode(_dot_)com>
I am not in favor of breaking support ... such that organizations which
would rather use registered DN in existing X.509 certificates than DNS names
with PEM may.
This (counter-)proposition is only applicable for those entities
which don't have an place in the tree underneath a country to go.
"...and if a user is already registered in an X.500 directory, his
distinguished name is defined via that registration." [1422 3.3.4]
In other cases, perhaps certain PCAs might become Directory service providers
in a limited sense - they assign names, but do not necessarily offer X.500
access to those named entries. If they wish to run DSAs, that's fine too.
For example "cs.ucl.ac.uk" is mapped onto "c=gb,o=UCL,ou=cs"
of which "ou=cs" is a CA. Other CAs may be added further down.
Where do we get to know about these CAs unless they map the
domain tree in the first place?
If there would be aliases going to outside o=Internet, as for instance those
to {ou=Computer Science,o=University College London,c=gb}, this scheme
wouldn't affect them. No problem putting this Distinguished Name in the
certificate. When an organization moves from the o=Internet tree to another
tree (say c=GB or c=US) certificates can be revoked/timed out and re-issued
with the new names. If there are DSAs, their old entries in the meantime
become aliases and the current certificates move to their new entries.
This is different to the current situation where a set of domainComponents
are stored within the existing internet naming architecture. The feasibility
using a DN/DM mapping depends on the congruence of the structures. This
approach
suits ad-hoc searches for DN->DM->DN pairings. These are useful for
building SMTP UAs in which the UI to the user relies upon recipient
identification expressed as a mailbox address, rather than the Name, as
with the various X.400 user agents. Though, it breaks down as soon as
the naming assumptions differ from the registered DNS domain-name.
If I follow what you're saying, I agree there would be problems in relying on
equivalence between DNS and X.500.
In the current scheme subordinate unregistered domains need
to be supplied by the user and possibly conveyed by the MTS
in order to identify such subordinate naming contexts.
That is, DNS domains are being invented for the purpose
of mapping names.
Here I'm also in agreement with you - by not replacing DNs in certificates
with mailboxes we don't have these problems with existing X.500-based CAs.
Instead of adding 'fake' DNS domains, portions of o=Internet could be delegated
out to organizations who've registered their domains and are using PEM. Under
there might be the possibility of subverting the implicit 1279 schema with
hybrids: {cn=John Smith,ou=Sales and Marketing,dc=foo,dc=com,o=Internet}.
I would be interested in hearing what suggestions you or others might have.
-------------------------------------
Mark Wahl; M(_dot_)Wahl(_at_)isode(_dot_)com; ISODE Consortium