Re: [Pki-devel] The Why's of PKI

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 >