Posted: 2012-03-18, 18:47 UTC
My proposal with certificates includes no standard server, nor anything in TC for communicating with one. There is nothing that someone could make public.
Currently (correct me if I'm wrong) you have licence keys with unique numbers and everyone who buys the licence gets the same type key, no matter if it's single or multi user licence. And the problem here is the multi user one, where the customer needs to have the same licence file on all his computers. And the more computers and more people using them, the bigger change that someone takes it home, then shares it with friends and later it's available to everyone. And you have no other chance than blocking the whole licence.
With certificates you would have the main one and use it to sign licences (certificates) given to customers. It's public part would be hardcoded in TC for verification purposes. Customer then could use the file directly (single licences and tiny companies where everyone can be trusted) or use it to sign sub-licences (bigger companies). There can be even multiple levels, e.g. customer key would be used to sign certificate for individual company branches and each branch could then issue certificates for its users. The licence file for end user could be simple PEM file containing the whole certificate chain (except the first one hardcoded in TC).
It does add some management effort compared to current keys (copy it once and don't ever touch it again), so the licence server seems like logical solution to make it easy again. But I think it's not the best idea. First because of theoretical possibility of public ones. And second, it's another non-standard thing to have in network. If you have network with hundered or more computers, you already have some means for central management. Rather than having each individual TC connnecting to central server, it's easier to use existing infrastructure to update the licences on end user's workstations (either file or registry value, exactly as it's now, except the format/content would be different). For admin it means writing just few scripts to manage the whole thing. Or something can be offered pre-made for standard environments.
It solves just one problem - allows each customer to define how much they want to protect their key from leaking (and later being blocked by you). Nothing more, nothing less. It does not try to implement any kind of global real-time licence enforcement controlled by you as author. Only problems I see are non-technical ones (although I might have missed some, it's not impossible ;). E.g. to clearly define that you tolerate leaked end user keys with expiration of X days and less and won't block the main customer's key in that case.
--
EDIT: Ooops, there is one major technical flaw. Anyone could simply remove the last certificate and it would work just fine. But it could be solved by requiring the last certicate to have CA attribute set to false.
Currently (correct me if I'm wrong) you have licence keys with unique numbers and everyone who buys the licence gets the same type key, no matter if it's single or multi user licence. And the problem here is the multi user one, where the customer needs to have the same licence file on all his computers. And the more computers and more people using them, the bigger change that someone takes it home, then shares it with friends and later it's available to everyone. And you have no other chance than blocking the whole licence.
With certificates you would have the main one and use it to sign licences (certificates) given to customers. It's public part would be hardcoded in TC for verification purposes. Customer then could use the file directly (single licences and tiny companies where everyone can be trusted) or use it to sign sub-licences (bigger companies). There can be even multiple levels, e.g. customer key would be used to sign certificate for individual company branches and each branch could then issue certificates for its users. The licence file for end user could be simple PEM file containing the whole certificate chain (except the first one hardcoded in TC).
It does add some management effort compared to current keys (copy it once and don't ever touch it again), so the licence server seems like logical solution to make it easy again. But I think it's not the best idea. First because of theoretical possibility of public ones. And second, it's another non-standard thing to have in network. If you have network with hundered or more computers, you already have some means for central management. Rather than having each individual TC connnecting to central server, it's easier to use existing infrastructure to update the licences on end user's workstations (either file or registry value, exactly as it's now, except the format/content would be different). For admin it means writing just few scripts to manage the whole thing. Or something can be offered pre-made for standard environments.
It solves just one problem - allows each customer to define how much they want to protect their key from leaking (and later being blocked by you). Nothing more, nothing less. It does not try to implement any kind of global real-time licence enforcement controlled by you as author. Only problems I see are non-technical ones (although I might have missed some, it's not impossible ;). E.g. to clearly define that you tolerate leaked end user keys with expiration of X days and less and won't block the main customer's key in that case.
--
EDIT: Ooops, there is one major technical flaw. Anyone could simply remove the last certificate and it would work just fine. But it could be solved by requiring the last certicate to have CA attribute set to false.
