Jeroen:
Thanks for stopping bye. Comments in line.
On 07/14/2010 11:38 AM, Jeroen van Meeuwen (Kolab Systems) wrote:
Hello there,
We (Kolab Systems AG) are very much interested in using Candlepin for entitlement management. In the capacity of one of their sysadmins, I'm exploring implementation feasibility and such and so forth.
Now, I'm not all too familiar with Candlepin, so please bear with me while I attempt to both give a correct representation of Candlepin semantics and my idea for off-line entitlement management.
High level summary:
Owners have pools which correspond to a quantity of a product with an effective date. Owners have consumers which will want to make use of the product. The entitlement is the act of a consumer "taking" one from the pool. Rules govern how and if that is possible.
Let me first state that Kolab System on it's own was looking to include the entitlement metadata in x509 extensions, and it seems to me so does Candlepin. Restricted access to updates for the work using SSL server/client certificates included, I think the similarities between the two sets of functional requirements are worth exploring ;-)
The hope is that we have put together the model so that the the candlepin engine proper has not idea of the content of the certificates ,it is just a blob. But.. if you look at the default implementations, we are also interested in X.509. So, worth exploring :)
Either way, this topic is about how entitlements are verified; We've had a short discussion on IRC on the subject, and given that conversation and the docs on fh.o/candlepin it seems to me, that the entitlement verification is based on some sort of -what one could arguably call- a phone-home mechanism (with or without a satellite candlepin system in between provider and customer).
If you are using a technology such as x.509 for the certificate, it should be possible to provide that certificate with enough data to know if it was valid. The only case, as with all certs, is if the CA has revoked it.
Now, let's suppose a customer simply refuses to implement any kind of phone- home mechanism, and wants their systems completely offline -which to me sounds like a very reasonable requirement.
The functionality that I proposed for consideration in a short IRC chat is based on this -existing- requirement;
What if we figure out a way to encrypt a license file somehow, that the application on the customer side can only decrypt to verify its entitlements, and the provider can create using information not available to the customer?
I missed the IRC chat, so I am a bit behind. let me give a couple of names here:
Provider: The Company which provides the products. Customer: The Company which purchases the products from the provider Hosts: Machines which the Customer Owns, which consume the products.
Are you looking for a way for the Provider to give data to the Customer who is running a candlepin server in an offline fashion? Or are you looking for way for the Hosts to be 100% offline?
The culprit basically is, that if it can be taken off-line, it might also be forged. However, since we're in the realm of Free Software (capital F), we're not worried about this. We're worried about not being able to meet the customer implementation requirements ;-)
Understood... lets dig into this a bit more...
-- bk