Lazy Cert Regeneration Design

James Bowes jbowes at redhat.com
Tue May 29 17:53:03 UTC 2012


On Sat, Jun 01, 2013 at 02:37:19PM -0300, Devan Goodwin wrote:
> On 05/25/2012 04:38 PM, Devan Goodwin wrote:
> >On Fri 25 May 2012 04:18:02 PM ADT, Devan Goodwin wrote:
> >>On 05/25/2012 04:02 PM, James Bowes wrote:
> >>>I mean the quantity in the entitlement decreases, rather than the
> >>>quantity in the pool.
> >>
> >>Ah yes, that might need more fleshing out, I think I missed that there
> >>is a path to regenerate, not just revoke in there. I will revisit that.
> >
> >Ok as per IRC discussion, if a cert needs to regen because it's quantity
> >changed (due to a decrease in the subscription), we will immediately
> >revoke and regen.
> >
> >>
> >>>
> >>>>Content set changes are indeed not detectable, but possibly being
> >>>>triggered by IT to mass regenerate via that product specific API
> >>>>call. We will not know why we're being triggered though so as it is
> >>>>today, we cannot decide if we're going to CRL now or later when we
> >>>>regenerate. However as per next point I am hoping we can keep it
> >>>>simple and have only two situations.
> >>>>
> >>>>For products being removed I will wager we still do not want to add
> >>>>to the CRL immediately, driver here was to not invalidate
> >>>>distributor certificates and my guess is we should not be doing that
> >>>>even if we're removing access to a particular repo from their
> >>>>subscription. Can we get clarification on this? (should we
> >>>>immediately invalidate certificates if a product is removed from a
> >>>>subscription)
> >>>>
> >>>
> >>>I'm pretty sure this is the exact situation where we do want to add to
> >>>the CRL. removing a product or a content set means you should no longer
> >>>have access to that content. If all a nefarious consumer has to do to
> >>>keep accessing content they're not rightly entitled to is to not ask for
> >>>a new cert, candlepin isn't doing its job.
> >>
> >>It's possible but I think we need to check, if I am reading the user
> >>story notes correctly, removal of content sets is listed explicitly as
> >>one of the scenarios where we want lazy revocation. i.e. we removed
> >>some content from your entitlement (in this case a provided product
> >>and it's content), but we do not want to immediately break all those
> >>downstream consumers.
> >>
> >>Candlepin could still be doing it's job if we reject immediately on
> >>loss of entitlement, but take a tolerant approach to rejecting
> >>certificates because we changed something on our end. Highly unlikely
> >>a nefarious consumer is going to anticipate a change to our product
> >>data, and shut off all consumer check-ins as far as I can forsee. It
> >>all depends on why this is being requested though.
> >>
> >
> >And for this we're going to assume content / product removal is still a
> >lazy operation by default, but both refresh pools for owner, and
> >regenerate all certs for a given product ID API calls will take an
> >option to force immediate certificate revocation. This is a safety net
> >in case something was granted that really should not have been.
> >
> >
> >I will write this all up on wiki and break down into tasks next week.
> >
> >Cheers,
> >
> >Devan
> >_______________________________________________
> >candlepin mailing list
> >candlepin at lists.fedorahosted.org
> >https://fedorahosted.org/mailman/listinfo/candlepin
> 
> Design is up at https://fedorahosted.org/candlepin/wiki/LazyCertRegen
> 
> Please have a look at let me know if anything needs to be clarified.
> 
> Thanks,

under task 2 you have "Be sure". Sentance fragment or way of life?
Maybe add a note that the regeneration that goes with an immediate CRL
can be either lazy or immediate, depending on which is cleaner in the
code.

-James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/candlepin/attachments/20120529/ad326947/attachment.sig>


More information about the candlepin mailing list