[Pki-devel] Request for better Dogtag 10 terminology . . .

[Matthew Harmsen]

*PROBLEM:
*

    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
    http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#File_System_Directory_Layout_.28Proposed.29
    and below for details)

*BACKGROUND:*

    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:

      * /var/lib/pki-ca
      * /var/lib/pki-kra
      * /var/lib/pki-tks
      * /var/lib/pki-tps

        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.

    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:

      * consists of at least one of the following web server instances:
          o one Tomcat 7 instance and/or
          o one Apache 2.4 instance
      * if a Tomcat 7 instance is being utilized, this process may
        contain the following PKI subsystem(s):
          o one CA, and/or
          o one KRA, and/or
          o one OCSP, and/or
          o one TKS
      * similarly, if an Apache 2.4 instance is being utilized, this
        process may contain the following PKI subsystem(s):
          o one RA, and/or
          o one TPS

    For example, a CA, KRA, TKS and TPS might have something similar to
    the following layout:

      * /var/lib/pki/[instance]/tomcat/ca
      * /var/lib/pki/[instance]/tomcat/kra
      * /var/lib/pki/[instance]/tomcat/tks
      * /var/lib/pki/[instance]/apache/tps

        where the *[instance]* notation is replaced by a *named "PKI
        Instance"* (e.g. - *'default'*):

      * /var/lib/pki/default/tomcat/ca
      * /var/lib/pki/default/tomcat/kra
      * /var/lib/pki/default/tomcat/tks
      * /var/lib/pki/default/apache/tps

    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.

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

*REQUEST FOR SUGGESTIONS:*

    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:

      * cluster (concerns about other non-PKI uses of this term)
      * domain (potential confusion with the notion of PKI security domain)
      * realm (potential conflict with the Tomcat concept)
      * crypt (a "play" on words which humorously attempts to describe
        these PKI subsystems as a collection of cryptographic services)
      * collection (concerns about other non-PKI uses of this term)
      * group (potentially over-used term)
      * bucket
      * family
      * pod

    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'*).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20120510/50ba1240/attachment.htm>