On 07/20/2011 12:45 PM, jesus m. rodriguez wrote:
On 07/20/2011 12:30 PM, Bryan Kearney wrote:
> Cross posting to pulp and candlepin lists. I apologize in advance.
>
> I am looking at how candlepin needs to communicate certificate
> revocation. The two main consumers I know of for this data are pulp (as
> part of katello) and thumbslug. In both cases, pulp and thumbslug are
> emitting a CDN interface and need to verify if a certificate presented
> to them are accurate.
>
> There are three main options that I have seen. Basic pros and cons
> below. I am looking for feedback from both camps as which they would
> prefer. I would like to agree on one model to limit testing issues.
>
>
> Certificate Revocation Lists (CRL)
> ==================================
> Candlepin generates CRLs which are read by Pulp/Thumbslug. Files are
> regenerated every X hours and need to be refreshed.
>
> Pros:
> (1) Candlepin does this already!
> (2) Standards compliant
>
> Cons:
> (1)As the tools are horzontally scaled, we need to design out how
> (1.1) Handle candlepin is on many machines
> (1.2) Handle when pulp/thumbslug is on different machines from candlepin
so the problem here is the replication of the crls? as well as
the delay in their generation?
I dont think they delay is an issue, just need to account for it. It is
more of replicating them across machines.
> Online Certificate Status Protocol (OCSP)
> =========================================
> An OCSP responder exists which can return a yes/no for certificates.
>
> Pros:
> (1) Standards Compliant
> (2) Should solve the cross machine issues
>
> Cons:
> (1) More work for Candlepin
> (2) May need to implementing a "mirror list" type solution for finding
> candlepin
Why would we need a mirror list? Is the idea here that each Candlepin
would be an OCSP responder, hence needing a mirror list? or is there
something else?
to avoid a single point of failure. If the responder is on 2 machines,
then pulp/thubslug would need to look at both.
> Custom Wire Protocol
> ====================
> Same model as OCSP, but custom protocol.
>
> Pros:
> (1) Should be easier to implement than OCSP
> (2) Should resolve the cross machine issues
>
> Cons:
> (1) Same as OCSP
>
>
> Comments from folks?
What is this 'custom wire protocol' or is it truly custom in
the sense that we can make it up? :D
Yeah.. quick/dirty/custom
-- bk