Off-line Entitlement Management

[Jeroen van Meeuwen]

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.

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 ;-)

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

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?

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 ;-)

I would appreciate some feedback! ;-)

Take care,

[Bryan Kearney]

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