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 > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-list -- Jason L Connor linear on freenode #pulp http://pulpproject.org/ RHCE: 805010912355231 GPG Fingerprint: 2048R/CC4ED7C1
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
