Domain Component Naming in Institutional End Entity Certificates
Editor: James Jokl
Date: March 14, 2001
Comments to: firstname.lastname@example.org
A Public Key cryptography Infrastructure (PKI) based on X.509 certificates provides excellent mechanisms for user authentication and digital signatures but, in general, does not convey significant authorization information. The PKI identifies the user but does not generally define what the user should be permitted to do. Standard X.509 certificates also lack a simple and commonly implemented mechanism for locating sources of information about the certificate and other user authorization data. One-way to facilitate locating these additional sources of information (e.g. LDAP directories, etc) is to encode an institutionís Domain Name System (DNS) name into the certificate. Once the DNS name is available, the institutionís DNS servers can be queried for SRV records to locate many different sources of information. This scheme provides a clear and extensible mechanism that enables new sources of data to be added without the need to re-issue user certificates.
RFC-2247 defines a way to map DNS names into Distinguished Names (DN) and can be used to encode an institutionís domain name into the DNs used in a certificateís Issuer and Subject fields.
The primary issues that HEPKI-TAG discussed in addressing this question involved determining if better solutions exist and working to see if the use of domain component names is likely to cause problems with existing applications.
Summary: adding domain component names to the Subject and Issuer fields of the certificate may help facilitate the location of authorization information. Furthermore, the addition of the domain components does not appear to cause problems for any known applications.
Much work is still underway in the general areas of naming and how to locate authorization information given a name. HEPKI-TAG will review this recommendation as appropriate in the future.