7:02 p.m.
*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_Dir...
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'*).
8:38 p.m.
On 05/10/2012 08:02 PM, Matthew Harmsen wrote:
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:
Actually I think the term "instance" is descriptive and accurate, it
makes perfect sense to me in the context of how it's being used. Terms
like cluster, domain, realm, group, etc. have so many other connotations
I think it would be more confusing because it implies something it's not.
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
2:55 a.m.
On 05/11/2012 07:08 AM, John Dennis wrote:
--
/kashyap
On 05/10/2012 08:02 PM, Matthew Harmsen wrote:
> 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:
Actually I think the term "instance" is descriptive and accurate, it makes
perfect sense
to me in the context of how it's being used.
Agreed.
Terms like cluster, domain, realm, group,
etc. have so many other connotations I think it would be more
confusing because it implies
something it's not.
True, from a QE perspective, it's easier to refer it as pki(ca, etc,) instance while
communicating to debug an issue. Also, the terms you mentioned are really over used in
general, and in other projects. Not to mention, the word realm also being used in
kerberos, 'group' being a standard *nix term, domain(again, a very vague term).
10:02 a.m.
The term "instance" makes sense in this context when we are talking
specifically about either a single tomcat or a single apache instance,
even if that instance happens to correspond to multiple subsystems. And
this would make sense, because all of the subsystems within that
instance would be started/stopped by a single init script, and they will
share things like a password.conf file and a common nss database.
In the proposed layout though, we have the possibility of the "instance"
containing both an apache and a tomcat instance - and hence the casting
around for a new name.
Unless we plan on writing some hybrid init script, that allows us to
start/stop both apache and tomcat instances at the same time (which is
very unlikely in the near future - and probably a bad idea in any case),
maybe we should not allow the "instance" to contain both apache and
tomcat instances.
Instead I suggest the following :
/var/lib/pki/tomcat0 (for the ca, kra, ocsp, tks)
/var/lib/pki/apache0 (for the ra, tps)
I think I like tomcat0 and apache0 rather than "default" - it makes it
clearer that this is an instance name and also the type of instance.
Ade
On Fri, 2012-05-11 at 13:25 +0530, Kashyap Chamarthy wrote:
On 05/11/2012 07:08 AM, John Dennis wrote:
> On 05/10/2012 08:02 PM, Matthew Harmsen wrote:
>> 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:
>
> Actually I think the term "instance" is descriptive and accurate, it makes
perfect sense
> to me in the context of how it's being used.
Agreed.
Terms like cluster, domain, realm, group,
> etc. have so many other connotations I think it would be more confusing because it
implies
> something it's not.
True, from a QE perspective, it's easier to refer it as pki(ca, etc,) instance while
communicating to debug an issue. Also, the terms you mentioned are really over used in
general, and in other projects. Not to mention, the word realm also being used in
kerberos, 'group' being a standard *nix term, domain(again, a very vague term).
>
4374
days inactive
4374
days old
3 comments
4 participants
participants (4)
-
Ade Lee -
John Dennis -
Kashyap Chamarthy -
Matthew Harmsen