Lazy Cert Regeneration Design

Devan Goodwin dgoodwin at redhat.com
Tue May 29 18:16:01 UTC 2012


On 05/29/2012 02:53 PM, James Bowes wrote:
> 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

Thanks, added.

Sorry about the previous future email as well all, date testing cert 
expiration again. :)

Devan



More information about the candlepin mailing list