8:41 a.m.
The Layout of the PKI project is very unusual for a Java Server
application. I'm trying to understand the rationale for some of the
things that were done.
Why do we create a separate server instance for each subsystem? Is a
reason to continue doing so?
Is using different ports for CA and DRM (an so forth) merely an
artifact of using multiple servers, or is there an additional reason to
do so?
Do we expect the same user to have and user different certificates for
different servers, such that the certificate then becomes a union of
authentication and authorization?
Is there a reason to separate the CA and DRM Directory servers? Is it
a "best practice" to do so? What would be the implications of using a
single instance for both?
Is there any reason why the CA uses an LDAP server instead of a
Relational Database? Do we expect people to make queries dircetyl
against the CA DirSrv, or is the Database best hidden from public view?
Why do we split the build process up into multiple Source RPMS? Is
there a reason to maintain this split?
Are there design documents or discussions for these decisions?
5:06 p.m.
These are all very excellent design/architectural level questions.
We may need to dig through the old archives and figure this out if need be..
On 09/13/2011 06:41 AM, Adam Young wrote:
The Layout of the PKI project is very unusual for a Java Server
application. I'm trying to understand the rationale for some of the
things that were done.
looks like your discussion is centering mostly around the Java side
atleast for now. We should ask the same questions for the non Java side
I would think as well like TPS and RA which are currently apps on top of
Apache/mod_nss and are using different instances and ports etc..
Why do we create a separate server instance for each subsystem?
You see it as a "separate instance" only if you
deploy it on the same machine which is almost always not how a customer
would do. If you are deploying it on a customer site, you would almost
always
deploy CA,DRM etc on separate physical hosts mainly due to performance and
scalability and security considerations.
So even if we need to consolidate these instances onto the same "tomcat
instance",
or the same apache instance, we would still have the use cases where
this application
would need to behave as a CA or a DRM individually on different hosts.
Guess that
could still be achieved by tweaking configuration.
Is a reason to continue doing so?
Nothing comes to mind at
this time. At a future major release
of the project/product, these things would be good candidates to
consider revamping.
Is using different ports for CA and DRM (an so forth) merely an
artifact of using multiple servers, or is there an additional reason
to do so?
Same things as cited above for instances. Different ports is mainly an
artifact due to creating separate instances.
Do we expect the same user to have and user different certificates for
different servers, such that the certificate then becomes a union of
authentication and authorization?
no
Is there a reason to separate the CA and DRM Directory servers? Is
it a "best practice" to do so? What would be the implications of
using a single instance for both?
I don't think so. Infact we have long been critiqued that we have been
mis-using LDAP this way and the way we use VLV/indexes. We had in our
blue sky ideas page to convert this and use a relational db like mysql
but the usual suspects come into play - time/resources.
Is there any reason why the CA uses an LDAP server instead of a
Relational Database? Do we expect people to make queries dircetyl
against the CA DirSrv, or is the Database best hidden from public view?
These databases are to be restricted from public access. There's a
reason why it is called "Internal Database".
Why do we split the build process up into multiple Source RPMS? Is
there a reason to maintain this split?
Not that I can see.
Are there design documents or discussions for these decisions?
I have been pouring over these archives. Didn't find any that
specifically answers these questions.
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
7:48 p.m.
On 09/13/2011 06:41 AM, Adam Young wrote:
The Layout of the PKI project is very unusual for a Java Server
application.
I'm trying to understand the rationale for some of the things
that
were done.
Why do we create a separate server instance for each subsystem?
Because each subsystem is a standalone server.
Is a reason to continue doing so?
It provides great flexibility in deploying Certificate Server
Is using different ports for CA and DRM (an so forth) merely an
artifact of using multiple servers, or is there an additional reason
to do so?
Pkicreate tool allows selecting any ports. Pkicreate also suggests
ports for out of the box ease of use.
Do we expect the same user to have and user different certificates for
different servers,
This is a matter of deployment strategy.
such that the certificate then becomes a union of authentication and
authorization?
Certificates are the source of identity. Authorization is a separate
process based on verified identity.
Is there a reason to separate the CA and DRM Directory servers?
Protection of archived keys.
Is it a "best practice" to do so? What would be the
implications of
using a single instance for both?
Is there any reason why the CA uses an LDAP server instead of a
Relational Database?
X509 certificates are using the same distinguished names as LDAP.
Many identity products are based on directories.
Provides very secure access options.
Provides robust replication over secure channel.
Do we expect people to make queries dircetyl against the CA
DirSrv,
No
or is the Database best hidden from public view?
Why do we split the build process up into multiple Source RPMS?
Is there a reason to maintain this split?
Are there design documents or discussions for these decisions?
Yes, please look for "Legacy Certificate Management System Website" on
the internal CS wiki.
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
7:08 a.m.
On 09/13/2011 08:48 PM, Andrew Wnuk wrote:
On 09/13/2011 06:41 AM, Adam Young wrote:
> The Layout of the PKI project is very unusual for a Java Server
> application.
> I'm trying to understand the rationale for some of the things that
> were done.
>
> Why do we create a separate server instance for each subsystem?
Because each subsystem is a standalone server.
> Is a reason to continue doing so?
It provides great flexibility in deploying Certificate Server
>
> Is using different ports for CA and DRM (an so forth) merely an
> artifact of using multiple servers, or is there an additional reason
> to do so?
Pkicreate tool allows selecting any ports. Pkicreate also suggests
ports for out of the box ease of use.
>
> Do we expect the same user to have and user different certificates
> for different servers,
This is a matter of deployment strategy.
> such that the certificate then becomes a union of authentication and
> authorization?
Certificates are the source of identity. Authorization is a separate
process based on verified identity.
>
> Is there a reason to separate the CA and DRM Directory servers?
Protection of archived keys.
> Is it a "best practice" to do so? What would be the implications
> of using a single instance for both?
>
> Is there any reason why the CA uses an LDAP server instead of a
> Relational Database?
X509 certificates are using the same distinguished names as LDAP.
Many identity products are based on directories.
Provides very secure access options.
Provides robust replication over secure channel.
> Do we expect people to make queries dircetyl against the CA DirSrv,
No
These discussion points are ones I often have with customers I support,
so I echo Chandra that it's refreshing to see. In regards to whether we
expect people to make queries I think Andrew is correct, but a large US
Government customer regularly queries the CA internal slapd servers that
they manage and operate. The reasons for this have to do with legacy
publishing issues that Red Hat has worked hard to resolve in the current
rev of the product. In earlier revs of the product the customer found
that they could not rely upon the publishing functionality to reliably
publish both the large number of certificates they issued and the large
size CRLs they generated for use by the user base, so they developed an
out of band methodology to pull certificates and CRLs from the CA
internal slapd servers using the servlets built into the product, and
populate another set of Directory Servers with the certs and CRLs. This
methodology had worked well for them for several years and helped to a
large extent to resolve the distribution of the very large CRLs. Not to
say there aren't remaining challenges, but it's to the point that they
aren't complaining as loudly as previous.
> or is the Database best hidden from public view?
>
> Why do we split the build process up into multiple Source RPMS?
> Is there a reason to maintain this split?
>
> Are there design documents or discussions for these decisions?
Yes, please look for "Legacy Certificate Management System Website" on
the internal CS wiki.
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
7:31 a.m.
On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
On 09/13/2011 06:41 AM, Adam Young wrote:
> The Layout of the PKI project is very unusual for a Java Server
> application.
> I'm trying to understand the rationale for some of the things that
> were done.
>
> Why do we create a separate server instance for each subsystem?
Because each subsystem is a standalone server.
I'm not sure if it needs to be a stand alone server. It was designed and
implemented as such
starting 10 years ago. It might be very well be a separated name space
uri inside the same tomcat instance.
> Is a reason to continue doing so?
It provides great flexibility in deploying Certificate Server
The same level of flexibility can be achieved even with a single tomcat
instance provided that instance configuration at install time takes care
of tweaking stuff.
>
> Is using different ports for CA and DRM (an so forth) merely an
> artifact of using multiple servers, or is there an additional reason
> to do so?
Pkicreate tool allows selecting any ports. Pkicreate also suggests
ports for out of the box ease of use.
>
> Do we expect the same user to have and user different certificates
> for different servers,
This is a matter of deployment strategy.
> such that the certificate then becomes a union of authentication and
> authorization?
Certificates are the source of identity. Authorization is a separate
process based on verified identity.
>
> Is there a reason to separate the CA and DRM Directory servers?
Protection of archived keys.
They could even stay protected - if there's a plan to consolidate.
In my mind Separation != protection.
> Is it a "best practice" to do so? What would be the implications
> of using a single instance for both?
>
> Is there any reason why the CA uses an LDAP server instead of a
> Relational Database?
X509 certificates are using the same distinguished names as LDAP.
Many identity products are based on directories.
Provides very secure access options.
Provides robust replication over secure channel.
> Do we expect people to make queries dircetyl against the CA DirSrv,
No
> or is the Database best hidden from public view?
>
> Why do we split the build process up into multiple Source RPMS?
> Is there a reason to maintain this split?
>
> Are there design documents or discussions for these decisions?
Yes, please look for "Legacy Certificate Management System Website" on
the internal CS wiki.
Sorry I dug through that pile. None answered the first question still so
far for me. Why are these separate instances to begin with ?.
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
10:42 a.m.
On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
> On 09/13/2011 06:41 AM, Adam Young wrote:
>> The Layout of the PKI project is very unusual for a Java Server
>> application.
>
>> I'm trying to understand the rationale for some of the things that
>> were done.
>>
>> Why do we create a separate server instance for each subsystem?
>
> Because each subsystem is a standalone server.
I'm not sure if it needs to be a stand alone server. It was designed
and implemented as such
starting 10 years ago. It might be very well be a separated name space
uri inside the same tomcat instance.
They are standalone servers for reliability and availability reasons, so
single tomcat failure is not going to knock down all your servers at the
same time.
>
>> Is a reason to continue doing so?
>
> It provides great flexibility in deploying Certificate Server
The same level of flexibility can be achieved even with a single
tomcat instance provided that instance configuration at install time
takes care of tweaking stuff.
>
>>
>> Is using different ports for CA and DRM (an so forth) merely an
>> artifact of using multiple servers, or is there an additional
>> reason to do so?
>
> Pkicreate tool allows selecting any ports. Pkicreate also suggests
> ports for out of the box ease of use.
>
>>
>> Do we expect the same user to have and user different certificates
>> for different servers,
>
> This is a matter of deployment strategy.
>
>> such that the certificate then becomes a union of authentication and
>> authorization?
>
> Certificates are the source of identity. Authorization is a separate
> process based on verified identity.
>
>>
>> Is there a reason to separate the CA and DRM Directory servers?
>
> Protection of archived keys.
They could even stay protected - if there's a plan to consolidate.
In my mind Separation != protection.
Separation is not equal protection, but it allows to apply appropriate
protection standards to specific data.
>
>> Is it a "best practice" to do so? What would be the implications
>> of using a single instance for both?
>>
>> Is there any reason why the CA uses an LDAP server instead of a
>> Relational Database?
>
> X509 certificates are using the same distinguished names as LDAP.
> Many identity products are based on directories.
> Provides very secure access options.
> Provides robust replication over secure channel.
>
>> Do we expect people to make queries dircetyl against the CA DirSrv,
>
> No
>
>> or is the Database best hidden from public view?
>>
>> Why do we split the build process up into multiple Source RPMS?
>
>> Is there a reason to maintain this split?
>>
>> Are there design documents or discussions for these decisions?
>
> Yes, please look for "Legacy Certificate Management System Website"
> on the internal CS wiki.
Sorry I dug through that pile. None answered the first question still
so far for me. Why are these separate instances to begin with ?.
>
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
11:10 a.m.
On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>> The Layout of the PKI project is very unusual for a Java Server
>>> application.
>>
>>> I'm trying to understand the rationale for some of the things that
>>> were done.
>>>
>>> Why do we create a separate server instance for each subsystem?
>>
>> Because each subsystem is a standalone server.
>
> I'm not sure if it needs to be a stand alone server. It was designed
> and implemented as such
> starting 10 years ago. It might be very well be a separated name
> space uri inside the same tomcat instance.
They are standalone servers for reliability and availability reasons,
so single tomcat failure is not going to knock down all your servers
at the same time.
That is easily avoided by cloning...
>
>
>>
>>> Is a reason to continue doing so?
>>
>> It provides great flexibility in deploying Certificate Server
>
> The same level of flexibility can be achieved even with a single
> tomcat instance provided that instance configuration at install time
> takes care of tweaking stuff.
>
>>
>>>
>>> Is using different ports for CA and DRM (an so forth) merely an
>>> artifact of using multiple servers, or is there an additional
>>> reason to do so?
>>
>> Pkicreate tool allows selecting any ports. Pkicreate also suggests
>> ports for out of the box ease of use.
>>
>>>
>>> Do we expect the same user to have and user different certificates
>>> for different servers,
>>
>> This is a matter of deployment strategy.
>>
>>> such that the certificate then becomes a union of authentication
>>> and authorization?
>>
>> Certificates are the source of identity. Authorization is a
>> separate process based on verified identity.
>>
>>>
>>> Is there a reason to separate the CA and DRM Directory servers?
>>
>> Protection of archived keys.
>
> They could even stay protected - if there's a plan to consolidate.
> In my mind Separation != protection.
Separation is not equal protection, but it allows to apply appropriate
protection standards to specific data.
I'm yet to hear how it cannot be achieved otherwise when consolidated..
>
>>
>>> Is it a "best practice" to do so? What would be the implications
>>> of using a single instance for both?
>>>
>>> Is there any reason why the CA uses an LDAP server instead of a
>>> Relational Database?
>>
>> X509 certificates are using the same distinguished names as LDAP.
>> Many identity products are based on directories.
>> Provides very secure access options.
>> Provides robust replication over secure channel.
>>
>>> Do we expect people to make queries dircetyl against the CA
>>> DirSrv,
>>
>> No
>>
>>> or is the Database best hidden from public view?
>>>
>>> Why do we split the build process up into multiple Source RPMS?
>>
>>> Is there a reason to maintain this split?
>>>
>>> Are there design documents or discussions for these decisions?
>>
>> Yes, please look for "Legacy Certificate Management System Website"
>> on the internal CS wiki.
>
> Sorry I dug through that pile. None answered the first question still
> so far for me. Why are these separate instances to begin with ?.
>
>
>>
>>>
>>> _______________________________________________
>>> Pki-devel mailing list
>>> Pki-devel(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
11:30 a.m.
On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
> On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
>> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>>> The Layout of the PKI project is very unusual for a Java Server
>>>> application.
>>>
>>>> I'm trying to understand the rationale for some of the things that
>>>> were done.
>>>>
>>>> Why do we create a separate server instance for each subsystem?
>>>
>>> Because each subsystem is a standalone server.
>>
>> I'm not sure if it needs to be a stand alone server. It was designed
>> and implemented as such
>> starting 10 years ago. It might be very well be a separated name
>> space uri inside the same tomcat instance.
>
> They are standalone servers for reliability and availability reasons,
> so single tomcat failure is not going to knock down all your servers
> at the same time.
That is easily avoided by cloning...
Standalone servers are even more reliable with cloning. They are more
modular and provide bigger flexibility in designing deployments. For
example, ratio 1:1 between CAs and DRMs is necessarily the best as we
learned from big deployments.
>
>>
>>
>>>
>>>> Is a reason to continue doing so?
>>>
>>> It provides great flexibility in deploying Certificate Server
>>
>> The same level of flexibility can be achieved even with a single
>> tomcat instance provided that instance configuration at install time
>> takes care of tweaking stuff.
>>
>>>
>>>>
>>>> Is using different ports for CA and DRM (an so forth) merely an
>>>> artifact of using multiple servers, or is there an additional
>>>> reason to do so?
>>>
>>> Pkicreate tool allows selecting any ports. Pkicreate also suggests
>>> ports for out of the box ease of use.
>>>
>>>>
>>>> Do we expect the same user to have and user different certificates
>>>> for different servers,
>>>
>>> This is a matter of deployment strategy.
>>>
>>>> such that the certificate then becomes a union of authentication
>>>> and authorization?
>>>
>>> Certificates are the source of identity. Authorization is a
>>> separate process based on verified identity.
>>>
>>>>
>>>> Is there a reason to separate the CA and DRM Directory servers?
>>>
>>> Protection of archived keys.
>>
>> They could even stay protected - if there's a plan to consolidate.
>> In my mind Separation != protection.
>
> Separation is not equal protection, but it allows to apply
> appropriate protection standards to specific data.
I'm yet to hear how it cannot be achieved otherwise when consolidated..
>
>>
>>>
>>>> Is it a "best practice" to do so? What would be the
>>>> implications of using a single instance for both?
>>>>
>>>> Is there any reason why the CA uses an LDAP server instead of a
>>>> Relational Database?
>>>
>>> X509 certificates are using the same distinguished names as LDAP.
>>> Many identity products are based on directories.
>>> Provides very secure access options.
>>> Provides robust replication over secure channel.
>>>
>>>> Do we expect people to make queries dircetyl against the CA
>>>> DirSrv,
>>>
>>> No
>>>
>>>> or is the Database best hidden from public view?
>>>>
>>>> Why do we split the build process up into multiple Source RPMS?
>>>
>>>> Is there a reason to maintain this split?
>>>>
>>>> Are there design documents or discussions for these decisions?
>>>
>>> Yes, please look for "Legacy Certificate Management System Website"
>>> on the internal CS wiki.
>>
>> Sorry I dug through that pile. None answered the first question
>> still so far for me. Why are these separate instances to begin with ?.
>>
>>
>>>
>>>>
>>>> _______________________________________________
>>>> Pki-devel mailing list
>>>> Pki-devel(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>
>>> _______________________________________________
>>> Pki-devel mailing list
>>> Pki-devel(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
noon
On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
> On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
>> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>>> The Layout of the PKI project is very unusual for a Java Server
>>>> application.
>>>
>>>> I'm trying to understand the rationale for some of the things that
>>>> were done.
>>>>
>>>> Why do we create a separate server instance for each subsystem?
>>>
>>> Because each subsystem is a standalone server.
>>
>> I'm not sure if it needs to be a stand alone server. It was designed
>> and implemented as such
>> starting 10 years ago. It might be very well be a separated name
>> space uri inside the same tomcat instance.
>
> They are standalone servers for reliability and availability reasons,
> so single tomcat failure is not going to knock down all your servers
> at the same time.
That is easily avoided by cloning...
Standalone servers are even more reliable with cloning. They are more
modular and provide bigger flexibility in designing deployments. For
example, ratio 1:1 between CAs and DRMs is not necessarily the best as
we learned from big deployments.
(sorry, I missed "not" in the original answer)
>
>>
>>
>>>
>>>> Is a reason to continue doing so?
>>>
>>> It provides great flexibility in deploying Certificate Server
>>
>> The same level of flexibility can be achieved even with a single
>> tomcat instance provided that instance configuration at install time
>> takes care of tweaking stuff.
>>
>>>
>>>>
>>>> Is using different ports for CA and DRM (an so forth) merely an
>>>> artifact of using multiple servers, or is there an additional
>>>> reason to do so?
>>>
>>> Pkicreate tool allows selecting any ports. Pkicreate also suggests
>>> ports for out of the box ease of use.
>>>
>>>>
>>>> Do we expect the same user to have and user different certificates
>>>> for different servers,
>>>
>>> This is a matter of deployment strategy.
>>>
>>>> such that the certificate then becomes a union of authentication
>>>> and authorization?
>>>
>>> Certificates are the source of identity. Authorization is a
>>> separate process based on verified identity.
>>>
>>>>
>>>> Is there a reason to separate the CA and DRM Directory servers?
>>>
>>> Protection of archived keys.
>>
>> They could even stay protected - if there's a plan to consolidate.
>> In my mind Separation != protection.
>
> Separation is not equal protection, but it allows to apply
> appropriate protection standards to specific data.
I'm yet to hear how it cannot be achieved otherwise when consolidated..
>
>>
>>>
>>>> Is it a "best practice" to do so? What would be the
>>>> implications of using a single instance for both?
>>>>
>>>> Is there any reason why the CA uses an LDAP server instead of a
>>>> Relational Database?
>>>
>>> X509 certificates are using the same distinguished names as LDAP.
>>> Many identity products are based on directories.
>>> Provides very secure access options.
>>> Provides robust replication over secure channel.
>>>
>>>> Do we expect people to make queries dircetyl against the CA
>>>> DirSrv,
>>>
>>> No
>>>
>>>> or is the Database best hidden from public view?
>>>>
>>>> Why do we split the build process up into multiple Source RPMS?
>>>
>>>> Is there a reason to maintain this split?
>>>>
>>>> Are there design documents or discussions for these decisions?
>>>
>>> Yes, please look for "Legacy Certificate Management System Website"
>>> on the internal CS wiki.
>>
>> Sorry I dug through that pile. None answered the first question
>> still so far for me. Why are these separate instances to begin with ?.
>>
>>
>>>
>>>>
>>>> _______________________________________________
>>>> Pki-devel mailing list
>>>> Pki-devel(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>
>>> _______________________________________________
>>> Pki-devel mailing list
>>> Pki-devel(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
12:18 p.m.
On 09/14/2011 10:00 AM, Andrew Wnuk wrote:
On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
> On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
>> On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
>>> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>>>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>>>> The Layout of the PKI project is very unusual for a Java Server
>>>>> application.
>>>>
>>>>> I'm trying to understand the rationale for some of the things
>>>>> that were done.
>>>>>
>>>>> Why do we create a separate server instance for each subsystem?
>>>>
>>>> Because each subsystem is a standalone server.
>>>
>>> I'm not sure if it needs to be a stand alone server. It was
>>> designed and implemented as such
>>> starting 10 years ago. It might be very well be a separated name
>>> space uri inside the same tomcat instance.
>>
>> They are standalone servers for reliability and availability
>> reasons, so single tomcat failure is not going to knock down all
>> your servers at the same time.
>
> That is easily avoided by cloning...
Standalone servers are even more reliable with cloning. They are more
modular and provide bigger flexibility in designing deployments. For
example, ratio 1:1 between CAs and DRMs is not necessarily the best as
we learned from big deployments.
(sorry, I missed "not" in the original answer)
As we know being modular provides flexibility _only at a cost_. The cost
of deploying more and more instances is high and having to maintain them
as well.
Rather consolidating these "services" into one server seems like a good
approach to me. When we start talking about 1:1, I start thinking along
these lines..
- What good can a DRM do when its associated CA is offline anyways -
it cant archive. So there goes 50% of its functionality..
- What good can a TPS do when its 1:1 associated services like tks,drm
are offline. Might as well be a single server.
- What good can a OCSP be when its associated CA is offline. Serve
OCSP requests based on stale data?.
IMHO this modular design has brought in unnecessary complexity to a PKI
topology which could be simplified by consolidating these services
together in a single container.
>>
>>>
>>>
>>>>
>>>>> Is a reason to continue doing so?
>>>>
>>>> It provides great flexibility in deploying Certificate Server
>>>
>>> The same level of flexibility can be achieved even with a single
>>> tomcat instance provided that instance configuration at install
>>> time takes care of tweaking stuff.
>>>
>>>>
>>>>>
>>>>> Is using different ports for CA and DRM (an so forth) merely an
>>>>> artifact of using multiple servers, or is there an additional
>>>>> reason to do so?
>>>>
>>>> Pkicreate tool allows selecting any ports. Pkicreate also
>>>> suggests ports for out of the box ease of use.
>>>>
>>>>>
>>>>> Do we expect the same user to have and user different
>>>>> certificates for different servers,
>>>>
>>>> This is a matter of deployment strategy.
>>>>
>>>>> such that the certificate then becomes a union of authentication
>>>>> and authorization?
>>>>
>>>> Certificates are the source of identity. Authorization is a
>>>> separate process based on verified identity.
>>>>
>>>>>
>>>>> Is there a reason to separate the CA and DRM Directory servers?
>>>>
>>>> Protection of archived keys.
>>>
>>> They could even stay protected - if there's a plan to consolidate.
>>> In my mind Separation != protection.
>>
>> Separation is not equal protection, but it allows to apply
>> appropriate protection standards to specific data.
>
> I'm yet to hear how it cannot be achieved otherwise when consolidated..
>
>>
>>>
>>>>
>>>>> Is it a "best practice" to do so? What would be the
>>>>> implications of using a single instance for both?
>>>>>
>>>>> Is there any reason why the CA uses an LDAP server instead of a
>>>>> Relational Database?
>>>>
>>>> X509 certificates are using the same distinguished names as LDAP.
>>>> Many identity products are based on directories.
>>>> Provides very secure access options.
>>>> Provides robust replication over secure channel.
>>>>
>>>>> Do we expect people to make queries dircetyl against the CA
>>>>> DirSrv,
>>>>
>>>> No
>>>>
>>>>> or is the Database best hidden from public view?
>>>>>
>>>>> Why do we split the build process up into multiple Source RPMS?
>>>>
>>>>> Is there a reason to maintain this split?
>>>>>
>>>>> Are there design documents or discussions for these decisions?
>>>>
>>>> Yes, please look for "Legacy Certificate Management System
>>>> Website" on the internal CS wiki.
>>>
>>> Sorry I dug through that pile. None answered the first question
>>> still so far for me. Why are these separate instances to begin with ?.
>>>
>>>
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pki-devel mailing list
>>>>> Pki-devel(a)redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>
>>>> _______________________________________________
>>>> Pki-devel mailing list
>>>> Pki-devel(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
12:37 p.m.
On 09/14/2011 10:18 AM, Chandrasekar Kannan wrote:
On 09/14/2011 10:00 AM, Andrew Wnuk wrote:
> On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
>> On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
>>> On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
>>>> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>>>>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>>>>> The Layout of the PKI project is very unusual for a Java Server
>>>>>> application.
>>>>>
>>>>>> I'm trying to understand the rationale for some of the things
>>>>>> that were done.
>>>>>>
>>>>>> Why do we create a separate server instance for each subsystem?
>>>>>
>>>>> Because each subsystem is a standalone server.
>>>>
>>>> I'm not sure if it needs to be a stand alone server. It was
>>>> designed and implemented as such
>>>> starting 10 years ago. It might be very well be a separated name
>>>> space uri inside the same tomcat instance.
>>>
>>> They are standalone servers for reliability and availability
>>> reasons, so single tomcat failure is not going to knock down all
>>> your servers at the same time.
>>
>> That is easily avoided by cloning...
>
> Standalone servers are even more reliable with cloning. They are more
> modular and provide bigger flexibility in designing deployments. For
> example, ratio 1:1 between CAs and DRMs is not necessarily the best
> as we learned from big deployments.
>
> (sorry, I missed "not" in the original answer)
As we know being modular provides flexibility _only at a cost_. The
cost of deploying more and more instances is high and having to
maintain them as well.
Rather consolidating these "services" into one server seems like a
good approach to me. When we start talking about 1:1, I start thinking
along these lines..
- What good can a DRM do when its associated CA is offline anyways -
it cant archive. So there goes 50% of its functionality..
- What good can a TPS do when its 1:1 associated services like
tks,drm are offline. Might as well be a single server.
- What good can a OCSP be when its associated CA is offline. Serve
OCSP requests based on stale data?.
Redundancy is the only thing that can help If some subsystems are
permanently offline.
Deployments should be able to recover from situations where subsystems
are temporarily offline.
Please open bugs if there are any issues in the recovery process.
IMHO this modular design has brought in unnecessary complexity to a
PKI topology which could be simplified by consolidating these services
together in a single container.
>>>
>>>>
>>>>
>>>>>
>>>>>> Is a reason to continue doing so?
>>>>>
>>>>> It provides great flexibility in deploying Certificate Server
>>>>
>>>> The same level of flexibility can be achieved even with a single
>>>> tomcat instance provided that instance configuration at install
>>>> time takes care of tweaking stuff.
>>>>
>>>>>
>>>>>>
>>>>>> Is using different ports for CA and DRM (an so forth) merely an
>>>>>> artifact of using multiple servers, or is there an additional
>>>>>> reason to do so?
>>>>>
>>>>> Pkicreate tool allows selecting any ports. Pkicreate also
>>>>> suggests ports for out of the box ease of use.
>>>>>
>>>>>>
>>>>>> Do we expect the same user to have and user different
>>>>>> certificates for different servers,
>>>>>
>>>>> This is a matter of deployment strategy.
>>>>>
>>>>>> such that the certificate then becomes a union of authentication
>>>>>> and authorization?
>>>>>
>>>>> Certificates are the source of identity. Authorization is a
>>>>> separate process based on verified identity.
>>>>>
>>>>>>
>>>>>> Is there a reason to separate the CA and DRM Directory servers?
>>>>>
>>>>> Protection of archived keys.
>>>>
>>>> They could even stay protected - if there's a plan to consolidate.
>>>> In my mind Separation != protection.
>>>
>>> Separation is not equal protection, but it allows to apply
>>> appropriate protection standards to specific data.
>>
>> I'm yet to hear how it cannot be achieved otherwise when consolidated..
>>
>>>
>>>>
>>>>>
>>>>>> Is it a "best practice" to do so? What would be the
>>>>>> implications of using a single instance for both?
>>>>>>
>>>>>> Is there any reason why the CA uses an LDAP server instead of a
>>>>>> Relational Database?
>>>>>
>>>>> X509 certificates are using the same distinguished names as LDAP.
>>>>> Many identity products are based on directories.
>>>>> Provides very secure access options.
>>>>> Provides robust replication over secure channel.
>>>>>
>>>>>> Do we expect people to make queries dircetyl against the CA
>>>>>> DirSrv,
>>>>>
>>>>> No
>>>>>
>>>>>> or is the Database best hidden from public view?
>>>>>>
>>>>>> Why do we split the build process up into multiple Source RPMS?
>>>>>
>>>>>> Is there a reason to maintain this split?
>>>>>>
>>>>>> Are there design documents or discussions for these decisions?
>>>>>
>>>>> Yes, please look for "Legacy Certificate Management System
>>>>> Website" on the internal CS wiki.
>>>>
>>>> Sorry I dug through that pile. None answered the first question
>>>> still so far for me. Why are these separate instances to begin
>>>> with ?.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pki-devel mailing list
>>>>>> Pki-devel(a)redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>
>>>>> _______________________________________________
>>>>> Pki-devel mailing list
>>>>> Pki-devel(a)redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>
>>>
>>> _______________________________________________
>>> Pki-devel mailing list
>>> Pki-devel(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>
>
12:41 p.m.
On 09/14/2011 01:37 PM, Andrew Wnuk wrote:
On 09/14/2011 10:18 AM, Chandrasekar Kannan wrote:
> On 09/14/2011 10:00 AM, Andrew Wnuk wrote:
>> On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
>>> On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
>>>> On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
>>>>> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>>>>>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>>>>>> The Layout of the PKI project is very unusual for a Java
Server
>>>>>>> application.
>>>>>>
>>>>>>> I'm trying to understand the rationale for some of the
things
>>>>>>> that were done.
>>>>>>>
>>>>>>> Why do we create a separate server instance for each
subsystem?
>>>>>>
>>>>>> Because each subsystem is a standalone server.
>>>>>
>>>>> I'm not sure if it needs to be a stand alone server. It was
>>>>> designed and implemented as such
>>>>> starting 10 years ago. It might be very well be a separated name
>>>>> space uri inside the same tomcat instance.
>>>>
>>>> They are standalone servers for reliability and availability
>>>> reasons, so single tomcat failure is not going to knock down all
>>>> your servers at the same time.
>>>
>>> That is easily avoided by cloning...
>>
>> Standalone servers are even more reliable with cloning. They are
>> more modular and provide bigger flexibility in designing
>> deployments. For example, ratio 1:1 between CAs and DRMs is not
>> necessarily the best as we learned from big deployments.
>>
>> (sorry, I missed "not" in the original answer)
>
> As we know being modular provides flexibility _only at a cost_. The
> cost of deploying more and more instances is high and having to
> maintain them as well.
> Rather consolidating these "services" into one server seems like a
> good approach to me. When we start talking about 1:1, I start
> thinking along these lines..
>
> - What good can a DRM do when its associated CA is offline anyways -
> it cant archive. So there goes 50% of its functionality..
> - What good can a TPS do when its 1:1 associated services like
> tks,drm are offline. Might as well be a single server.
> - What good can a OCSP be when its associated CA is offline. Serve
> OCSP requests based on stale data?.
Redundancy is the only thing that can help If some subsystems are
permanently offline.
Deployments should be able to recover from situations where subsystems
are temporarily offline.
Please open bugs if there are any issues in the recovery process.
When you say "For example, ratio 1:1 between CAs and DRMs is not
necessarily the best as we learned" what is the general approach that
we have found works? More DRMS? More CAs?
>
> IMHO this modular design has brought in unnecessary complexity to a
> PKI topology which could be simplified by consolidating these
> services together in a single container.
>
>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> Is a reason to continue doing so?
>>>>>>
>>>>>> It provides great flexibility in deploying Certificate Server
>>>>>
>>>>> The same level of flexibility can be achieved even with a single
>>>>> tomcat instance provided that instance configuration at install
>>>>> time takes care of tweaking stuff.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Is using different ports for CA and DRM (an so forth) merely
>>>>>>> an artifact of using multiple servers, or is there an
>>>>>>> additional reason to do so?
>>>>>>
>>>>>> Pkicreate tool allows selecting any ports. Pkicreate also
>>>>>> suggests ports for out of the box ease of use.
>>>>>>
>>>>>>>
>>>>>>> Do we expect the same user to have and user different
>>>>>>> certificates for different servers,
>>>>>>
>>>>>> This is a matter of deployment strategy.
>>>>>>
>>>>>>> such that the certificate then becomes a union of
>>>>>>> authentication and authorization?
>>>>>>
>>>>>> Certificates are the source of identity. Authorization is a
>>>>>> separate process based on verified identity.
>>>>>>
>>>>>>>
>>>>>>> Is there a reason to separate the CA and DRM Directory
servers?
>>>>>>
>>>>>> Protection of archived keys.
>>>>>
>>>>> They could even stay protected - if there's a plan to
consolidate.
>>>>> In my mind Separation != protection.
>>>>
>>>> Separation is not equal protection, but it allows to apply
>>>> appropriate protection standards to specific data.
>>>
>>> I'm yet to hear how it cannot be achieved otherwise when
>>> consolidated..
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> Is it a "best practice" to do so? What would be
the
>>>>>>> implications of using a single instance for both?
>>>>>>>
>>>>>>> Is there any reason why the CA uses an LDAP server instead of
a
>>>>>>> Relational Database?
>>>>>>
>>>>>> X509 certificates are using the same distinguished names as
LDAP.
>>>>>> Many identity products are based on directories.
>>>>>> Provides very secure access options.
>>>>>> Provides robust replication over secure channel.
>>>>>>
>>>>>>> Do we expect people to make queries dircetyl against the
CA
>>>>>>> DirSrv,
>>>>>>
>>>>>> No
>>>>>>
>>>>>>> or is the Database best hidden from public view?
>>>>>>>
>>>>>>> Why do we split the build process up into multiple Source
RPMS?
>>>>>>
>>>>>>> Is there a reason to maintain this split?
>>>>>>>
>>>>>>> Are there design documents or discussions for these
decisions?
>>>>>>
>>>>>> Yes, please look for "Legacy Certificate Management System
>>>>>> Website" on the internal CS wiki.
>>>>>
>>>>> Sorry I dug through that pile. None answered the first question
>>>>> still so far for me. Why are these separate instances to begin
>>>>> with ?.
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pki-devel mailing list
>>>>>>> Pki-devel(a)redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pki-devel mailing list
>>>>>> Pki-devel(a)redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pki-devel mailing list
>>>> Pki-devel(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>
>>
>
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
1:53 p.m.
On 09/14/2011 10:41 AM, Adam Young wrote:
On 09/14/2011 01:37 PM, Andrew Wnuk wrote:
> On 09/14/2011 10:18 AM, Chandrasekar Kannan wrote:
>> On 09/14/2011 10:00 AM, Andrew Wnuk wrote:
>>> On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
>>>> On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
>>>>> On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
>>>>>> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>>>>>>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>>>>>>> The Layout of the PKI project is very unusual for a Java
>>>>>>>> Server application.
>>>>>>>
>>>>>>>> I'm trying to understand the rationale for some of
the things
>>>>>>>> that were done.
>>>>>>>>
>>>>>>>> Why do we create a separate server instance for each
subsystem?
>>>>>>>
>>>>>>> Because each subsystem is a standalone server.
>>>>>>
>>>>>> I'm not sure if it needs to be a stand alone server. It was
>>>>>> designed and implemented as such
>>>>>> starting 10 years ago. It might be very well be a separated name
>>>>>> space uri inside the same tomcat instance.
>>>>>
>>>>> They are standalone servers for reliability and availability
>>>>> reasons, so single tomcat failure is not going to knock down all
>>>>> your servers at the same time.
>>>>
>>>> That is easily avoided by cloning...
>>>
>>> Standalone servers are even more reliable with cloning. They are
>>> more modular and provide bigger flexibility in designing
>>> deployments. For example, ratio 1:1 between CAs and DRMs is not
>>> necessarily the best as we learned from big deployments.
>>>
>>> (sorry, I missed "not" in the original answer)
>>
>> As we know being modular provides flexibility _only at a cost_. The
>> cost of deploying more and more instances is high and having to
>> maintain them as well.
>> Rather consolidating these "services" into one server seems like a
>> good approach to me. When we start talking about 1:1, I start
>> thinking along these lines..
>>
>> - What good can a DRM do when its associated CA is offline anyways
>> - it cant archive. So there goes 50% of its functionality..
>> - What good can a TPS do when its 1:1 associated services like
>> tks,drm are offline. Might as well be a single server.
>> - What good can a OCSP be when its associated CA is offline. Serve
>> OCSP requests based on stale data?.
>
> Redundancy is the only thing that can help If some subsystems are
> permanently offline.
> Deployments should be able to recover from situations where
> subsystems are temporarily offline.
> Please open bugs if there are any issues in the recovery process.
When you say "For example, ratio 1:1 between CAs and DRMs is not
necessarily the best as we learned" what is the general approach that
we have found works?
It might be hard to define single general approach. Deployment life is
complex combination of many factors starting from initial architecture,
its evolution, real life requirements, support, environmental
limitations, longevity of the deployment, and budgetary limitations.
More DRMS? More CAs?
Please ask Michael Brown for more details.
>
>>
>> IMHO this modular design has brought in unnecessary complexity to a
>> PKI topology which could be simplified by consolidating these
>> services together in a single container.
>>
>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> Is a reason to continue doing so?
>>>>>>>
>>>>>>> It provides great flexibility in deploying Certificate
Server
>>>>>>
>>>>>> The same level of flexibility can be achieved even with a
>>>>>> single tomcat instance provided that instance configuration at
>>>>>> install time takes care of tweaking stuff.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Is using different ports for CA and DRM (an so forth)
merely
>>>>>>>> an artifact of using multiple servers, or is there an
>>>>>>>> additional reason to do so?
>>>>>>>
>>>>>>> Pkicreate tool allows selecting any ports. Pkicreate also
>>>>>>> suggests ports for out of the box ease of use.
>>>>>>>
>>>>>>>>
>>>>>>>> Do we expect the same user to have and user different
>>>>>>>> certificates for different servers,
>>>>>>>
>>>>>>> This is a matter of deployment strategy.
>>>>>>>
>>>>>>>> such that the certificate then becomes a union of
>>>>>>>> authentication and authorization?
>>>>>>>
>>>>>>> Certificates are the source of identity. Authorization is a
>>>>>>> separate process based on verified identity.
>>>>>>>
>>>>>>>>
>>>>>>>> Is there a reason to separate the CA and DRM Directory
servers?
>>>>>>>
>>>>>>> Protection of archived keys.
>>>>>>
>>>>>> They could even stay protected - if there's a plan to
consolidate.
>>>>>> In my mind Separation != protection.
>>>>>
>>>>> Separation is not equal protection, but it allows to apply
>>>>> appropriate protection standards to specific data.
>>>>
>>>> I'm yet to hear how it cannot be achieved otherwise when
>>>> consolidated..
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> Is it a "best practice" to do so? What would
be the
>>>>>>>> implications of using a single instance for both?
>>>>>>>>
>>>>>>>> Is there any reason why the CA uses an LDAP server
instead of
>>>>>>>> a Relational Database?
>>>>>>>
>>>>>>> X509 certificates are using the same distinguished names as
LDAP.
>>>>>>> Many identity products are based on directories.
>>>>>>> Provides very secure access options.
>>>>>>> Provides robust replication over secure channel.
>>>>>>>
>>>>>>>> Do we expect people to make queries dircetyl against
the
>>>>>>>> CA DirSrv,
>>>>>>>
>>>>>>> No
>>>>>>>
>>>>>>>> or is the Database best hidden from public view?
>>>>>>>>
>>>>>>>> Why do we split the build process up into multiple Source
RPMS?
>>>>>>>
>>>>>>>> Is there a reason to maintain this split?
>>>>>>>>
>>>>>>>> Are there design documents or discussions for these
decisions?
>>>>>>>
>>>>>>> Yes, please look for "Legacy Certificate Management
System
>>>>>>> Website" on the internal CS wiki.
>>>>>>
>>>>>> Sorry I dug through that pile. None answered the first question
>>>>>> still so far for me. Why are these separate instances to begin
>>>>>> with ?.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pki-devel mailing list
>>>>>>>> Pki-devel(a)redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pki-devel mailing list
>>>>>>> Pki-devel(a)redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pki-devel mailing list
>>>>> Pki-devel(a)redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>
>>>
>>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
2:33 p.m.
On Wed, Sep 14, 2011 at 2:53 PM, Andrew Wnuk <awnuk(a)redhat.com> wrote:
On 09/14/2011 10:41 AM, Adam Young wrote:
> On 09/14/2011 01:37 PM, Andrew Wnuk wrote:
>
>> On 09/14/2011 10:18 AM, Chandrasekar Kannan wrote:
>>
>>> On 09/14/2011 10:00 AM, Andrew Wnuk wrote:
>>>
>>>> On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
>>>>
>>>>> On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
>>>>>
>>>>>> On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
>>>>>>
>>>>>>> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>>>>>>>
>>>>>>>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>>>>>>>
>>>>>>>>> The Layout of the PKI project is very unusual for a
Java Server
>>>>>>>>> application.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm trying to understand the rationale for some of
the things that
>>>>>>>>> were done.
>>>>>>>>>
>>>>>>>>> Why do we create a separate server instance for each
subsystem?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Because each subsystem is a standalone server.
>>>>>>>>
>>>>>>>
>>>>>>> I'm not sure if it needs to be a stand alone server. It
was designed
>>>>>>> and implemented as such
>>>>>>> starting 10 years ago. It might be very well be a separated
name
>>>>>>> space uri inside the same tomcat instance.
>>>>>>>
>>>>>>
>>>>>> They are standalone servers for reliability and availability
reasons,
>>>>>> so single tomcat failure is not going to knock down all your
servers at the
>>>>>> same time.
>>>>>>
>>>>>
>>>>> That is easily avoided by cloning...
>>>>>
>>>>
>>>> Standalone servers are even more reliable with cloning. They are more
>>>> modular and provide bigger flexibility in designing deployments. For
>>>> example, ratio 1:1 between CAs and DRMs is not necessarily the best as
we
>>>> learned from big deployments.
>>>>
>>>> (sorry, I missed "not" in the original answer)
>>>>
>>>
>>> As we know being modular provides flexibility _only at a cost_. The cost
>>> of deploying more and more instances is high and having to maintain them as
>>> well.
>>> Rather consolidating these "services" into one server seems like a
good
>>> approach to me. When we start talking about 1:1, I start thinking along
>>> these lines..
>>>
>>> - What good can a DRM do when its associated CA is offline anyways - it
>>> cant archive. So there goes 50% of its functionality..
>>> - What good can a TPS do when its 1:1 associated services like tks,drm
>>> are offline. Might as well be a single server.
>>> - What good can a OCSP be when its associated CA is offline. Serve OCSP
>>> requests based on stale data?.
>>>
>>
>> Redundancy is the only thing that can help If some subsystems are
>> permanently offline.
>> Deployments should be able to recover from situations where subsystems
>> are temporarily offline.
>> Please open bugs if there are any issues in the recovery process.
>>
>
> When you say "For example, ratio 1:1 between CAs and DRMs is not
> necessarily the best as we learned" what is the general approach that we
> have found works?
>
It might be hard to define single general approach. Deployment life is
complex combination of many factors starting from initial architecture, its
evolution, real life requirements, support, environmental limitations,
longevity of the deployment, and budgetary limitations.
More DRMS? More CAs?
>
Please ask Michael Brown for more details.
The largest Red Hat PKI customer has found that multiple CAs per DRM has
worked for them. Not every CA archives keys to a DRM in the customer
deployment, and those that do archive (several per production site)
typically archive to single DRM or small set of DRMs; smaller than the set
of CAs. This is contrary to how Red Hat has typically documented a
deployment in the Admin Guide, etc., which is one RA to one CA to one DRM.
Also one TPS to one TKS to one CA to one DRM in a Token deployment,
particularly as related to TPS. The customer has commented on several
occasions, sometimes loudly, that this one-to-one-to-one doesn't reflect the
reality of an enterprise deployment that requires redundancy and
availability, and in which certificate requests are load balanced across a
set of multi-site CAs. I think that's what Andrew has been getting at
above. Maintaining the ability to separate out the instances will remain
important for Red Hat's largest PKI customer going forward. At the same
time, not every customer deployment will have the same stringent reliability
and availability requirements as the largest customer.
What I don't see discussed much, either above or in the docs, is the
important role multi-mastered internal slapd servers can potentially play in
providing improved reliability and availability. These are the main data
repositories, and having these multi-mastered across multiple hosts with
failover is the being seen as the target architecture of choice for the
largest customer going forward (I'm working on this). Having multiple CA
tomcat instances on a single host, or having multiple DRM tomcat instances
on a single host (separate from the CA hosts) is not seen as a major issue.
The important thing is to be able to re-connect tomcat instances with the
data in a failure. Cloning will also hopefully be introduced in the next
deployment (I'm working on this), and it will obviously also be a
requirement to have these clones as separate instances, and probably on
separate hosts, to prevent the issue Andrew mentioned above; the failure of
a single tomcat instance taking out multiple instances of CA, DRM, etc.
Hope this helps.
>
>
>>
>>> IMHO this modular design has brought in unnecessary complexity to a PKI
>>> topology which could be simplified by consolidating these services together
>>> in a single container.
>>>
>>
Do you have a suggested topology that will be simpler and also meet the
requirements of Red Hat's largest customer?
>>>
>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Is a reason to continue doing so?
>>>>>>>>>
>>>>>>>>
>>>>>>>> It provides great flexibility in deploying Certificate
Server
>>>>>>>>
>>>>>>>
>>>>>>> The same level of flexibility can be achieved even with a
single
>>>>>>> tomcat instance provided that instance configuration at
install time takes
>>>>>>> care of tweaking stuff.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> Is using different ports for CA and DRM (an so forth)
merely an
>>>>>>>>> artifact of using multiple servers, or is there an
additional reason to do
>>>>>>>>> so?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Pkicreate tool allows selecting any ports. Pkicreate
also suggests
>>>>>>>> ports for out of the box ease of use.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Do we expect the same user to have and user different
certificates
>>>>>>>>> for different servers,
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is a matter of deployment strategy.
>>>>>>>>
>>>>>>>> such that the certificate then becomes a union of
authentication
>>>>>>>>> and authorization?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Certificates are the source of identity. Authorization
is a
>>>>>>>> separate process based on verified identity.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Is there a reason to separate the CA and DRM
Directory servers?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Protection of archived keys.
>>>>>>>>
>>>>>>>
>>>>>>> They could even stay protected - if there's a plan to
consolidate.
>>>>>>> In my mind Separation != protection.
>>>>>>>
>>>>>>
>>>>>> Separation is not equal protection, but it allows to apply
>>>>>> appropriate protection standards to specific data.
>>>>>>
>>>>>
>>>>> I'm yet to hear how it cannot be achieved otherwise when
>>>>> consolidated..
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> Is it a "best practice" to do so? What would
be the implications
>>>>>>>>> of using a single instance for both?
>>>>>>>>>
>>>>>>>>> Is there any reason why the CA uses an LDAP server
instead of a
>>>>>>>>> Relational Database?
>>>>>>>>>
>>>>>>>>
>>>>>>>> X509 certificates are using the same distinguished names
as LDAP.
>>>>>>>> Many identity products are based on directories.
>>>>>>>> Provides very secure access options.
>>>>>>>> Provides robust replication over secure channel.
>>>>>>>>
>>>>>>>> Do we expect people to make queries dircetyl against
the CA
>>>>>>>>> DirSrv,
>>>>>>>>>
>>>>>>>>
>>>>>>>> No
>>>>>>>>
>>>>>>>> or is the Database best hidden from public view?
>>>>>>>>>
>>>>>>>>> Why do we split the build process up into multiple
Source RPMS?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Is there a reason to maintain this split?
>>>>>>>>>
>>>>>>>>> Are there design documents or discussions for these
decisions?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, please look for "Legacy Certificate Management
System Website"
>>>>>>>> on the internal CS wiki.
>>>>>>>>
>>>>>>>
>>>>>>> Sorry I dug through that pile. None answered the first
question
>>>>>>> still so far for me. Why are these separate instances to
begin with ?.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> ______________________________**_________________
>>>>>>>>> Pki-devel mailing list
>>>>>>>>> Pki-devel(a)redhat.com
>>>>>>>>>
https://www.redhat.com/**mailman/listinfo/pki-devel<https://www.redhat...
>>>>>>>>>
>>>>>>>>
>>>>>>>> ______________________________**_________________
>>>>>>>> Pki-devel mailing list
>>>>>>>> Pki-devel(a)redhat.com
>>>>>>>>
https://www.redhat.com/**mailman/listinfo/pki-devel<https://www.redhat...
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ______________________________**_________________
>>>>>> Pki-devel mailing list
>>>>>> Pki-devel(a)redhat.com
>>>>>>
https://www.redhat.com/**mailman/listinfo/pki-devel<https://www.redhat...
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>> ______________________________**_________________
>> Pki-devel mailing list
>> Pki-devel(a)redhat.com
>>
https://www.redhat.com/**mailman/listinfo/pki-devel<https://www.redhat...
>>
>
> ______________________________**_________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
>
https://www.redhat.com/**mailman/listinfo/pki-devel<https://www.redhat...
>
______________________________**_________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/**mailman/listinfo/pki-devel<https://www.redhat...
3:01 p.m.
When we say "one CA" or Multiple "DRM" are we talkin servers? With
Directory Server Replication, I would assume that A CA could talk to any
DRM instance of a replicated group of Directory Servers? Is this not
the case?
On 09/14/2011 03:33 PM, Michael Brown wrote:
On Wed, Sep 14, 2011 at 2:53 PM, Andrew Wnuk <awnuk(a)redhat.com
<mailto:awnuk@redhat.com>> wrote:
On 09/14/2011 10:41 AM, Adam Young wrote:
On 09/14/2011 01:37 PM, Andrew Wnuk wrote:
On 09/14/2011 10:18 AM, Chandrasekar Kannan wrote:
On 09/14/2011 10:00 AM, Andrew Wnuk wrote:
On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
On 09/14/2011 05:31 AM, Chandrasekar
Kannan wrote:
On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
On 09/13/2011 06:41 AM, Adam Young
wrote:
The Layout of the PKI project
is very unusual for a Java
Server application.
I'm trying to understand the
rationale for some of the
things that were done.
Why do we create a separate
server instance for each
subsystem?
Because each subsystem is a
standalone server.
I'm not sure if it needs to be a stand
alone server. It was designed and
implemented as such
starting 10 years ago. It might be
very well be a separated name space
uri inside the same tomcat instance.
They are standalone servers for
reliability and availability reasons, so
single tomcat failure is not going to
knock down all your servers at the same time.
That is easily avoided by cloning...
Standalone servers are even more reliable with
cloning. They are more modular and provide bigger
flexibility in designing deployments. For example,
ratio 1:1 between CAs and DRMs is not necessarily
the best as we learned from big deployments.
(sorry, I missed "not" in the original answer)
As we know being modular provides flexibility _only at
a cost_. The cost of deploying more and more instances
is high and having to maintain them as well.
Rather consolidating these "services" into one server
seems like a good approach to me. When we start
talking about 1:1, I start thinking along these lines..
- What good can a DRM do when its associated CA is
offline anyways - it cant archive. So there goes 50%
of its functionality..
- What good can a TPS do when its 1:1 associated
services like tks,drm are offline. Might as well be a
single server.
- What good can a OCSP be when its associated CA is
offline. Serve OCSP requests based on stale data?.
Redundancy is the only thing that can help If some
subsystems are permanently offline.
Deployments should be able to recover from situations
where subsystems are temporarily offline.
Please open bugs if there are any issues in the recovery
process.
When you say "For example, ratio 1:1 between CAs and DRMs is
not necessarily the best as we learned" what is the general
approach that we have found works?
It might be hard to define single general approach. Deployment
life is complex combination of many factors starting from initial
architecture, its evolution, real life requirements, support,
environmental limitations, longevity of the deployment, and
budgetary limitations.
More DRMS? More CAs?
Please ask Michael Brown for more details.
The largest Red Hat PKI customer has found that multiple CAs per DRM
has worked for them. Not every CA archives keys to a DRM in the
customer deployment, and those that do archive (several per production
site) typically archive to single DRM or small set of DRMs; smaller
than the set of CAs. This is contrary to how Red Hat has typically
documented a deployment in the Admin Guide, etc., which is one RA to
one CA to one DRM. Also one TPS to one TKS to one CA to one DRM in a
Token deployment, particularly as related to TPS. The customer has
commented on several occasions, sometimes loudly, that this
one-to-one-to-one doesn't reflect the reality of an enterprise
deployment that requires redundancy and availability, and in which
certificate requests are load balanced across a set of multi-site
CAs. I think that's what Andrew has been getting at above.
Maintaining the ability to separate out the instances will remain
important for Red Hat's largest PKI customer going forward. At the
same time, not every customer deployment will have the same stringent
reliability and availability requirements as the largest customer.
What I don't see discussed much, either above or in the docs, is the
important role multi-mastered internal slapd servers can potentially
play in providing improved reliability and availability. These are
the main data repositories, and having these multi-mastered across
multiple hosts with failover is the being seen as the target
architecture of choice for the largest customer going forward (I'm
working on this). Having multiple CA tomcat instances on a single
host, or having multiple DRM tomcat instances on a single host
(separate from the CA hosts) is not seen as a major issue. The
important thing is to be able to re-connect tomcat instances with the
data in a failure. Cloning will also hopefully be introduced in the
next deployment (I'm working on this), and it will obviously also be a
requirement to have these clones as separate instances, and probably
on separate hosts, to prevent the issue Andrew mentioned above; the
failure of a single tomcat instance taking out multiple instances of
CA, DRM, etc.
Hope this helps.
IMHO this modular design has brought in unnecessary
complexity to a PKI topology which could be simplified
by consolidating these services together in a single
container.
Do you have a suggested topology that will be simpler and also meet
the requirements of Red Hat's largest customer?
Is a reason to continue doing so?
It provides great flexibility in
deploying Certificate Server
The same level of flexibility can be
achieved even with a single tomcat
instance provided that instance
configuration at install time takes
care of tweaking stuff.
Is using different ports for
CA and DRM (an so forth)
merely an artifact of using
multiple servers, or is there
an additional reason to do so?
Pkicreate tool allows selecting
any ports. Pkicreate also
suggests ports for out of the box
ease of use.
Do we expect the same user to
have and user different
certificates for different
servers,
This is a matter of deployment
strategy.
such that the certificate then
becomes a union of
authentication and authorization?
Certificates are the source of
identity. Authorization is a
separate process based on verified
identity.
Is there a reason to separate
the CA and DRM Directory servers?
Protection of archived keys.
They could even stay protected - if
there's a plan to consolidate.
In my mind Separation != protection.
Separation is not equal protection, but it
allows to apply appropriate protection
standards to specific data.
I'm yet to hear how it cannot be achieved
otherwise when consolidated..
Is it a "best practice" to do
so? What would be the
implications of using a single
instance for both?
Is there any reason why the CA
uses an LDAP server instead of
a Relational Database?
X509 certificates are using the
same distinguished names as LDAP.
Many identity products are based
on directories.
Provides very secure access options.
Provides robust replication over
secure channel.
Do we expect people to make
queries dircetyl against the
CA DirSrv,
No
or is the Database best hidden
from public view?
Why do we split the build
process up into multiple
Source RPMS?
Is there a reason to maintain
this split?
Are there design documents or
discussions for these decisions?
Yes, please look for "Legacy
Certificate Management System
Website" on the internal CS wiki.
Sorry I dug through that pile. None
answered the first question still so
far for me. Why are these separate
instances to begin with ?.
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
<mailto:Pki-devel@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
<mailto:Pki-devel@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
<mailto:Pki-devel@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com <mailto:Pki-devel@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com <mailto:Pki-devel@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com <mailto:Pki-devel@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
3:27 p.m.
If you are referring to my input, I mean instances.
I'm having difficulty following your question about CA-DRM communication,
though. Typically, the enrollment pages of a CA are configured with a
transport cert known to the DRM to enable the archival. Multiple DRMs can
be configured with the same transport cert, if that is what you are getting
at.
mrb
On Wed, Sep 14, 2011 at 4:01 PM, Adam Young <ayoung(a)redhat.com> wrote:
When we say "one CA" or Multiple "DRM" are we
talkin servers? With
Directory Server Replication, I would assume that A CA could talk to any DRM
instance of a replicated group of Directory Servers? Is this not the case?
On 09/14/2011 03:33 PM, Michael Brown wrote:
On Wed, Sep 14, 2011 at 2:53 PM, Andrew Wnuk <awnuk(a)redhat.com> wrote:
> On 09/14/2011 10:41 AM, Adam Young wrote:
>
>> On 09/14/2011 01:37 PM, Andrew Wnuk wrote:
>>
>>> On 09/14/2011 10:18 AM, Chandrasekar Kannan wrote:
>>>
>>>> On 09/14/2011 10:00 AM, Andrew Wnuk wrote:
>>>>
>>>>> On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:
>>>>>
>>>>>> On 09/14/2011 08:42 AM, Andrew Wnuk wrote:
>>>>>>
>>>>>>> On 09/14/2011 05:31 AM, Chandrasekar Kannan wrote:
>>>>>>>
>>>>>>>> On 09/13/2011 05:48 PM, Andrew Wnuk wrote:
>>>>>>>>
>>>>>>>>> On 09/13/2011 06:41 AM, Adam Young wrote:
>>>>>>>>>
>>>>>>>>>> The Layout of the PKI project is very unusual for
a Java Server
>>>>>>>>>> application.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm trying to understand the rationale for some
of the things
>>>>>>>>>> that were done.
>>>>>>>>>>
>>>>>>>>>> Why do we create a separate server instance for
each subsystem?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because each subsystem is a standalone server.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not sure if it needs to be a stand alone server.
It was
>>>>>>>> designed and implemented as such
>>>>>>>> starting 10 years ago. It might be very well be a
separated name
>>>>>>>> space uri inside the same tomcat instance.
>>>>>>>>
>>>>>>>
>>>>>>> They are standalone servers for reliability and availability
>>>>>>> reasons, so single tomcat failure is not going to knock down
all your
>>>>>>> servers at the same time.
>>>>>>>
>>>>>>
>>>>>> That is easily avoided by cloning...
>>>>>>
>>>>>
>>>>> Standalone servers are even more reliable with cloning. They are
more
>>>>> modular and provide bigger flexibility in designing deployments. For
>>>>> example, ratio 1:1 between CAs and DRMs is not necessarily the best
as we
>>>>> learned from big deployments.
>>>>>
>>>>> (sorry, I missed "not" in the original answer)
>>>>>
>>>>
>>>> As we know being modular provides flexibility _only at a cost_. The
>>>> cost of deploying more and more instances is high and having to maintain
>>>> them as well.
>>>> Rather consolidating these "services" into one server seems
like a good
>>>> approach to me. When we start talking about 1:1, I start thinking along
>>>> these lines..
>>>>
>>>> - What good can a DRM do when its associated CA is offline anyways -
>>>> it cant archive. So there goes 50% of its functionality..
>>>> - What good can a TPS do when its 1:1 associated services like tks,drm
>>>> are offline. Might as well be a single server.
>>>> - What good can a OCSP be when its associated CA is offline. Serve
>>>> OCSP requests based on stale data?.
>>>>
>>>
>>> Redundancy is the only thing that can help If some subsystems are
>>> permanently offline.
>>> Deployments should be able to recover from situations where subsystems
>>> are temporarily offline.
>>> Please open bugs if there are any issues in the recovery process.
>>>
>>
>> When you say "For example, ratio 1:1 between CAs and DRMs is not
>> necessarily the best as we learned" what is the general approach that we
>> have found works?
>>
>
> It might be hard to define single general approach. Deployment life is
> complex combination of many factors starting from initial architecture, its
> evolution, real life requirements, support, environmental limitations,
> longevity of the deployment, and budgetary limitations.
>
> More DRMS? More CAs?
>>
>
> Please ask Michael Brown for more details.
The largest Red Hat PKI customer has found that multiple CAs per DRM has
worked for them. Not every CA archives keys to a DRM in the customer
deployment, and those that do archive (several per production site)
typically archive to single DRM or small set of DRMs; smaller than the set
of CAs. This is contrary to how Red Hat has typically documented a
deployment in the Admin Guide, etc., which is one RA to one CA to one DRM.
Also one TPS to one TKS to one CA to one DRM in a Token deployment,
particularly as related to TPS. The customer has commented on several
occasions, sometimes loudly, that this one-to-one-to-one doesn't reflect the
reality of an enterprise deployment that requires redundancy and
availability, and in which certificate requests are load balanced across a
set of multi-site CAs. I think that's what Andrew has been getting at
above. Maintaining the ability to separate out the instances will remain
important for Red Hat's largest PKI customer going forward. At the same
time, not every customer deployment will have the same stringent reliability
and availability requirements as the largest customer.
What I don't see discussed much, either above or in the docs, is the
important role multi-mastered internal slapd servers can potentially play in
providing improved reliability and availability. These are the main data
repositories, and having these multi-mastered across multiple hosts with
failover is the being seen as the target architecture of choice for the
largest customer going forward (I'm working on this). Having multiple CA
tomcat instances on a single host, or having multiple DRM tomcat instances
on a single host (separate from the CA hosts) is not seen as a major issue.
The important thing is to be able to re-connect tomcat instances with the
data in a failure. Cloning will also hopefully be introduced in the next
deployment (I'm working on this), and it will obviously also be a
requirement to have these clones as separate instances, and probably on
separate hosts, to prevent the issue Andrew mentioned above; the failure of
a single tomcat instance taking out multiple instances of CA, DRM, etc.
Hope this helps.
>
>
>
>>
>>
>>>
>>>> IMHO this modular design has brought in unnecessary complexity to a PKI
>>>> topology which could be simplified by consolidating these services
together
>>>> in a single container.
>>>>
>>>
Do you have a suggested topology that will be simpler and also meet the
requirements of Red Hat's largest customer?
>
>>>>
>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Is a reason to continue doing so?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It provides great flexibility in deploying
Certificate Server
>>>>>>>>>
>>>>>>>>
>>>>>>>> The same level of flexibility can be achieved even with
a single
>>>>>>>> tomcat instance provided that instance configuration at
install time takes
>>>>>>>> care of tweaking stuff.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Is using different ports for CA and DRM (an so
forth) merely an
>>>>>>>>>> artifact of using multiple servers, or is there
an additional reason to do
>>>>>>>>>> so?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Pkicreate tool allows selecting any ports. Pkicreate
also
>>>>>>>>> suggests ports for out of the box ease of use.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Do we expect the same user to have and user
different
>>>>>>>>>> certificates for different servers,
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is a matter of deployment strategy.
>>>>>>>>>
>>>>>>>>> such that the certificate then becomes a union of
authentication
>>>>>>>>>> and authorization?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Certificates are the source of identity.
Authorization is a
>>>>>>>>> separate process based on verified identity.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Is there a reason to separate the CA and DRM
Directory servers?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Protection of archived keys.
>>>>>>>>>
>>>>>>>>
>>>>>>>> They could even stay protected - if there's a plan to
consolidate.
>>>>>>>> In my mind Separation != protection.
>>>>>>>>
>>>>>>>
>>>>>>> Separation is not equal protection, but it allows to apply
>>>>>>> appropriate protection standards to specific data.
>>>>>>>
>>>>>>
>>>>>> I'm yet to hear how it cannot be achieved otherwise when
>>>>>> consolidated..
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> Is it a "best practice" to do so? What
would be the
>>>>>>>>>> implications of using a single instance for
both?
>>>>>>>>>>
>>>>>>>>>> Is there any reason why the CA uses an LDAP
server instead of a
>>>>>>>>>> Relational Database?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> X509 certificates are using the same distinguished
names as LDAP.
>>>>>>>>> Many identity products are based on directories.
>>>>>>>>> Provides very secure access options.
>>>>>>>>> Provides robust replication over secure channel.
>>>>>>>>>
>>>>>>>>> Do we expect people to make queries dircetyl
against the CA
>>>>>>>>>> DirSrv,
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No
>>>>>>>>>
>>>>>>>>> or is the Database best hidden from public view?
>>>>>>>>>>
>>>>>>>>>> Why do we split the build process up into
multiple Source RPMS?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is there a reason to maintain this split?
>>>>>>>>>>
>>>>>>>>>> Are there design documents or discussions for
these decisions?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, please look for "Legacy Certificate
Management System
>>>>>>>>> Website" on the internal CS wiki.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry I dug through that pile. None answered the first
question
>>>>>>>> still so far for me. Why are these separate instances to
begin with ?.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Pki-devel mailing list
>>>>>>>>>> Pki-devel(a)redhat.com
>>>>>>>>>>
https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Pki-devel mailing list
>>>>>>>>> Pki-devel(a)redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pki-devel mailing list
>>>>>>> Pki-devel(a)redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Pki-devel mailing list
>>> Pki-devel(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
>
_______________________________________________
Pki-devel mailing
listPki-devel@redhat.comhttps://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
3:44 p.m.
>
> Is using different ports for CA and DRM (an so forth) merely an
> artifact of using multiple servers, or is there an additional reason
> to do so?
Pkicreate tool allows selecting any ports. Pkicreate also suggests
ports for out of the box ease of use.
There must be more to the story than this. I tried running pkicreate
with two of the subsystems using the same port
-agent_secure_port=8443 -ee_secure_port=8443
And when it runs I get the error
[error] Invalid port numbers submitted!
Is there some reason that these cannot be the same port, or is it just
convention. Does the agent use some protocol other than HTTP? I get
this error is I try to use the same port for any two *_secure_port values.
3:52 p.m.
On 09/14/2011 01:44 PM, Adam Young wrote:
>>
>> Is using different ports for CA and DRM (an so forth) merely an
>> artifact of using multiple servers, or is there an additional
>> reason to do so?
>
> Pkicreate tool allows selecting any ports. Pkicreate also suggests
> ports for out of the box ease of use.
There must be more to the story than this. I tried running pkicreate
with two of the subsystems using the same port
-agent_secure_port=8443 -ee_secure_port=8443
And when it runs I get the error
[error] Invalid port numbers submitted!
Is there some reason that these cannot be the same port, or is it just
convention. Does the agent use some protocol other than HTTP? I get
this error is I try to use the same port for any two *_secure_port
values.
one is for regular ssl. other is for ssl with "client auth".
- Chandra
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
3:55 p.m.
On 09/14/2011 01:52 PM, Chandrasekar Kannan wrote:
On 09/14/2011 01:44 PM, Adam Young wrote:
>
>>>
>>> Is using different ports for CA and DRM (an so forth) merely an
>>> artifact of using multiple servers, or is there an additional
>>> reason to do so?
>>
>> Pkicreate tool allows selecting any ports. Pkicreate also suggests
>> ports for out of the box ease of use.
>
> There must be more to the story than this. I tried running pkicreate
> with two of the subsystems using the same port
>
>
> -agent_secure_port=8443 -ee_secure_port=8443
>
> And when it runs I get the error
>
> [error] Invalid port numbers submitted!
>
>
> Is there some reason that these cannot be the same port, or is it
> just convention. Does the agent use some protocol other than HTTP?
> I get this error is I try to use the same port for any two
> *_secure_port values.
one is for regular ssl. other is for ssl with "client auth".
- Chandra
Adam can also check docs for more details:
http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.1/html/Com...
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
4:16 p.m.
On 09/14/2011 04:55 PM, Andrew Wnuk wrote:
On 09/14/2011 01:52 PM, Chandrasekar Kannan wrote:
> On 09/14/2011 01:44 PM, Adam Young wrote:
>>
>>>>
>>>> Is using different ports for CA and DRM (an so forth) merely an
>>>> artifact of using multiple servers, or is there an additional
>>>> reason to do so?
>>>
>>> Pkicreate tool allows selecting any ports. Pkicreate also suggests
>>> ports for out of the box ease of use.
>>
>> There must be more to the story than this. I tried running
>> pkicreate with two of the subsystems using the same port
>>
>>
>> -agent_secure_port=8443 -ee_secure_port=8443
>>
>> And when it runs I get the error
>>
>> [error] Invalid port numbers submitted!
>>
>>
>> Is there some reason that these cannot be the same port, or is it
>> just convention. Does the agent use some protocol other than HTTP?
>> I get this error is I try to use the same port for any two
>> *_secure_port values.
>
> one is for regular ssl. other is for ssl with "client auth".
>
> - Chandra
>
Adam can also check docs for more details:
http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.1/html/Com...
And there I see that specifying the separate ports is an option, but
that the first line of the script is for it all to use 3 ports:
Unsecure, SSL, startup/shutdown. So multiple ports is not required.
>
>>
>>
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
4856
days inactive
4857
days old
19 comments
4 participants
participants (4)
-
Adam Young -
Andrew Wnuk -
Chandrasekar Kannan -
Michael Brown