[Pki-devel] The Why's of PKI

[Andrew Wnuk]

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 at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>>
>>>> _______________________________________________
>>>> Pki-devel mailing list
>>>> Pki-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pki-devel
>>>
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>