[Pki-devel] The Why's of PKI

Chandrasekar Kannan ckannan at redhat.com
Wed Sep 14 17:18:34 UTC 2011


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 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
>>
>




More information about the Pki-devel mailing list