[Pki-devel] The Why's of PKI
Adam Young
ayoung at redhat.com
Wed Sep 14 20:01:33 UTC 2011
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
> <mailto: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
> <mailto:Pki-devel at redhat.com>
> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> <mailto:Pki-devel at redhat.com>
> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> <mailto:Pki-devel at redhat.com>
> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com <mailto:Pki-devel at redhat.com>
> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com <mailto:Pki-devel at redhat.com>
> https://www.redhat.com/mailman/listinfo/pki-devel
>
>
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20110914/7b524d3f/attachment.htm>
More information about the Pki-devel
mailing list