Lazy Cert Regeneration Design

James Bowes jbowes at redhat.com
Fri May 25 19:02:40 UTC 2012


On Fri, May 25, 2012 at 03:43:00PM -0300, Devan Goodwin wrote:
> On 05/25/2012 02:50 PM, James Bowes wrote:
> >On Thu, May 24, 2012 at 04:30:32PM -0300, Devan Goodwin wrote:
> ><snip>
> >>jbowes has proposed possibly leveraging lazy regen for all consumers
> >>of all types for some cert v2 purposes. (might need more info from
> >>you on this jbowes) I think this just implies expanding the hooks
> >>for triggering regeneration to:
> >>
> >>GET /consumers/{uuid}
> >>GET /consumers/{uuid}/entitlements
> >>GET /consumers/{uuid}/certificates (both JSON and ZIP calls)
> >>GET /consumers/{uuid}/certificates/serials
> >>
> >>I don't think this is much more work, the method to scan for dirty
> >>entitlements and regenerate would be shared across all these API
> >>calls. The implementation is cleaner particularly in the locations
> >>where we decide to set dirty flag or not, if this is not specific to
> >>just one consumer type and path through the code.
> >>
> >>Thoughts?
> >>
> >
> >My thinking on making regens lazy for all consumer types:
> >  1. spread x509 related load out across time. systems check in every 4
> >     hours or whatever, not all at once.
> >  2. with multiple certificate formats, there's no need to know what
> >     version the consumer wants before they ask for it. we simply
> >     regenerate what they ask for (via api or looking at a header on the
> >     request or whatever).
> >  3. fewer special cases make for cleaner code
> >  4. if we want to be nice to distributors and let them use certs that
> >     aren't exactly current, shouldn't we extend the same courtesy to system
> >     consumers?
> >
> 
> +1 to all.
> 
> >Doing a lazy regen implies that the real work of deciding if a
> >certificate is still good is when we put that old certificate on the CRL
> >list. We'd only add a certificate to the CRL immediately if it has
> >recieved a detectable net loss in access to content, like:
> >- quantity of entitlement has decreased (not sure if this is a real
> >   thing or not)
> >- content set is removed from a product (not detectable?)
> >- content set url is changed on a product (not detectable?)
> >- product is removed from a subscription
> >
> >If we hit one of those cases on a refreshpools, we add the cert cerial
> >to the CRL, and mark it as dirty, letting the client trigger the regen
> >at some later point.
> 
> Quantity decreasing should probably do as it does now and go ahead
> and revoke, this isn't really a regeneration but an outright
> revocation, and probably is not important for the use case we're
> trying to solve. I vote we let this immediately go to CRL and revoke
> the cert as we do today. (it's probably a pretty rare situation
> anyhow)
> 

I mean the quantity in the entitlement decreases, rather than the
quantity in the pool.

> 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.

> Hopefully we can just stay with these two situations:
> 
> 1. we're either adding to CRL + revoking (overconsumption, normal
> unbind, no work required because this is how it is today)
> 
> 2. we're flagging entitlement dirty now, and adding to CRL +
> regenerating on next check-in or manifest generation
> 
> >
> >If we don't hit one of those cases, like if we've added a new product,
> >we simply mark the cert as dirty. That dirty cert is still valid until
> >the new  regen is done, but why not just keep it valid for as long as
> >the newly regenerated version? that is, can we reuse the cert serial on
> >the new cert, keeping the old version still valid, and reducing both the
> >clutter in our CRL and the rate at which we consume cert serials? I
> >think that would work.
> 
> Having multiple certificates out in the wild with different contents
> but the same serial, all still valid, seems strange and like a
> probable source of future confusion, and perhaps an issue for our
> database. Each unique cert seems like it should probably have it's
> own serial to me.

As far as the database goes, i think we'd be ok with just storing the
newest copy under that serial, I guess I'm ok with creating the new cert
with a new Id and revoking the old at the same time, but it would be
cool to cut down on additions to the CRL.

> 
> If CRL clutter is a current known problem then it's worth
> considering, but otherwise I'd propose we leave that for another day
> and solve it if the issue arises.
> 

It's not a problem, but it is a concern. Every item we add to that list
is more memory some hash table on the cdn takes up. I'd hate to see that
thing start swapping because the file we build it too large.

> Cheers,
> 
> Devan

-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/20120525/3d83f341/attachment.sig>


More information about the candlepin mailing list