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(a)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