[Pki-devel] The Why's of PKI

Wed Sep 14 17:41:07 UTC 2011

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