<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> PROBLEM: <blockquote>Dogtag 10 is currently being designed with a new filesystem layout for PKI instances and is currently looking for a more accurate and descriptive terminology for its "[instance]" notation and its re-definition of the term "PKI Instance". (see <a class="moz-txt-link-freetext" href="http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#File_System_Directory_Layout_.28Proposed.29">http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#File_System_Directory_Layout_.28Proposed.29</a> and below for details)</blockquote> BACKGROUND: <blockquote>Prior to Dogtag 10, CA, KRA, OCSP, TKS (Tomcat5/Tomcat6), and RA, TPS (Apache 2.2) subsystems all consisted of an individual "named" instance of their web server. Each of these instances were often generically referred to as a "PKI instance". For example, a CA, KRA, TKS, and TPS might have something similar to the following layout: <ul> <li>/var/lib/pki-ca</li> <li>/var/lib/pki-kra</li> <li>/var/lib/pki-tks</li> <li>/var/lib/pki-tps</li> </ul> <blockquote>where each "PKI Instance" (named pki-ca, pki-kra, pki-tks, and pki-tps) is a separate process each containing their own collection of stand-alone NSS security databases. </blockquote> With the pending release of Dogtag 10, the notion of a single named "PKI Instance" has been introduced which no longer corresponds to a single PKI subsystem, but rather to the following definition: <ul> <li>consists of at least one of the following web server instances:</li> <ul> <li>one Tomcat 7 instance and/or</li> <li>one Apache 2.4 instance</li> </ul> <li>if a Tomcat 7 instance is being utilized, this process may contain the following PKI subsystem(s):</li> <ul> <li>one CA, and/or</li> <li>one KRA, and/or</li> <li>one OCSP, and/or</li> <li>one TKS</li> </ul> <li>similarly, if an Apache 2.4 instance is being utilized, this process may contain the following PKI subsystem(s):</li> <ul> <li>one RA, and/or</li> <li>one TPS </li> </ul> </ul> For example, a CA, KRA, TKS and TPS might have something similar to the following layout: <ul> <li>/var/lib/pki/[instance]/tomcat/ca</li> <li>/var/lib/pki/[instance]/tomcat/kra</li> <li>/var/lib/pki/[instance]/tomcat/tks</li> <li>/var/lib/pki/[instance]/apache/tps</li> </ul> <blockquote> where the [instance] notation is replaced by a named "PKI Instance" (e.g. - 'default'): </blockquote> <ul> <li>/var/lib/pki/default/tomcat/ca</li> <li>/var/lib/pki/default/tomcat/kra</li> <li>/var/lib/pki/default/tomcat/tks</li> <li>/var/lib/pki/default/apache/tps</li> </ul> </blockquote> <blockquote> Within this "PKI Instance" named 'default', the CA, KRA, and TKS constitute a single instance of Tomcat, TPS constitutes a single instance of Apache, and all four PKI subsystems share a single common collection of NSS security databases on a named "PKI Instance" basis. </blockquote> <blockquote>Note that this design allows future deployments to be similar to currently existing deployments, by merely creating more than one named "PKI Instance" on a single system, which in turn allows for the continued existence of multiple types of the same PKI subsystems on a single host (e. g. - two CAs and a KRA). </blockquote> REQUEST FOR SUGGESTIONS: <blockquote>As initially stated, we would like to replace the "[instance]" notation and "PKI instance" terminology currently used within Dogtag 10 with something that is more descriptive and more accurate. While several alternatives have already been suggested, none have gained wide-spread acceptance: <ul> <li>cluster (concerns about other non-PKI uses of this term) </li> <li>domain (potential confusion with the notion of PKI security domain) </li> <li>realm (potential conflict with the Tomcat concept) </li> <li>crypt (a "play" on words which humorously attempts to describe these PKI subsystems as a collection of cryptographic services) </li> <li>collection (concerns about other non-PKI uses of this term)</li> <li>group (potentially over-used term)</li> <li>bucket </li> <li>family </li> <li>pod</li> </ul> In any event, whatever this terminology turns out to be, a "PKI Instance" will still need to be implemented as a "named" entity (e. g. - 'default'). </blockquote> </body> </html>