Lazy Cert Regeneration Design

Devan Goodwin dgoodwin at redhat.com
Fri May 25 19:38:40 UTC 2012


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



More information about the candlepin mailing list