draft-internet2-HEPKI-TAG-DC

HEPKI-TAG Recommendation
Domain Component Naming in Institutional End Entity Certificates

Document: draft-internet2-HEPKI-TAG-DC_Naming-3.html
Editor: James Jokl
Date: March 14, 2001
Comments to: hepki-tag@internet2.edu

Abstract
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.

Issues
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.

No Better Solutions
The certificate format documented in RFC-2459 provides standardized mechanisms for encoding the location of some services into the IssuerAlternativeName and SubjectAlternativeName fields. However, these fields are not widely used or implemented at the present time.

No Known Problems
No one has been able to document a situation where the addition of the domain components to the certificate has caused problems. All appears to be well as long as the domain component names are used with valid distinguished names. RFC-2459 specifically states that complaint implementations must be able to handle domain component naming.

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.

Recommendation

HEPKI-TAG recommends that institutions use Domain Component names as defined in RFC-2247 in the Issuer and Subject field distinguished names in the End Entity certificates they issue to users. For example, the Issuer field for Georgetown University might contain: o=Georgetown University, c=US, dc=georgetown, dc=edu.
HEPKI-TAG further suggests that the Domain Components be grouped together in the most significant portion of the name. This follows the implementation practice of OpenLDAP and Microsoft.
HEPKI-TAG also recommends that domain component names be used in addition to any attributes encoded directly into the certificate for the purpose of looking up particular types of information. When searching for additional information about the Subject or Issuer, applications should always prefer a direct reference to the information over using the more generalized approach of Domain Component names and DNS SRV records to locate the information.

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.