Candlepin and Certificate Revocation
Bryan Kearney
bkearney at redhat.com
Wed Jul 20 17:03:59 UTC 2011
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
More information about the candlepin
mailing list