[Pulp-list] Candlepin and Certificate Revocation

[Jason L Connor]

Disclaimer: I haven't done any work with Candlepin integration or even
our certificate based authorization. So this email is going to be a
bunch of "thinking out loud", if you will.

It looks like the functionality is boiling down to batch vs single
certificate revocation.

In either case I prefer standards compliance over non-, so I don't like
the custom option.

I guess it's a trade off of how fine-grained, time-wise, we want
certificate revocation to be vs. how much do we want to talk over the
network.

I like the batch operation (CRL) as it doesn't need to check the status
of a certificate with candlepin at the same time as fielding a request
from a client. However, depending on how often the revocation list is
generated, the information pulp has at any given time for a certificate
may be out of date.

If we can keep the time granularity on certificate revocation
sufficiently coarse or we're willing to live with sufficiently short
periods of time in which we have dated certificate information, I think
this solution is the best.

If we cannot, we should move to OCSP.


On Wed, 2011-07-20 at 12:30 -0400, 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
> 
> 
> 
> 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
> 
> 
> 
> 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?
> 
> -- bk
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list

-- 
Jason L Connor
linear on freenode #pulp
http://pulpproject.org/
RHCE: 805010912355231
GPG Fingerprint: 2048R/CC4ED7C1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20110721/ecf325e8/attachment.sig>