Lazy Cert Regeneration Design

Devan Goodwin dgoodwin at redhat.com
Tue May 29 17:46:45 UTC 2012


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,



More information about the candlepin mailing list