[Pki-devel] The Why's of PKI

Michael Brown mrb137 at gmail.com
Wed Sep 14 20:27:59 UTC 2011 

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 at 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 at 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 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
>>>>
>>>
>>> _______________________________________________
>>> 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 listPki-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-devel
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20110914/a0ad08a8/attachment.htm>

More information about the Pki-devel mailing list