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