Access to license or policy metadata

[Wouter de Vries]

We are looking into an air-gapped solution for licenses that are bound to specific version ranges of a product. The "Choosing a Licensing Model" guide has a solution for individual features that works in the air-gapped case, but I don't quite understand.

The preferred way would be to add metadata fields to a license, minversion and maxversion. Unfortunately it seems the license metadata is not included in the key and thus cannot be read in the software. How can be link licenses to specific version ranges? In addition we also want to be able to extend the version range of air-gapped licenses over time. Is that possible or would they then require a new license?

Another oddity in the dashboard is that RSA_2048_PKCS1_PSS_SIGN requires you to manually specify the key. Why can it not be automatically generated?

[Zeke Gabrielse]

You can embed that data within a signed key, e.g. using the RSA_2048_PKCS1_PSS_SIGN scheme. That way, when the customer inputs the license key, you can read the embedded data within the key and cryptographically verify its signature to ensure it has not been altered.

And just to clarify the flow for generating and verifying signed license keys:

1. You input "seed data" for the license key (this can be anything, but this is usually where you would add embedded data within the key, such as version numbers, feature set, etc).
2. We sign the provided data using your account's private key (which we keep securely stored and never share), and append the signature onto the end, separated by a . delimiter.
3. You deliver the entire "key" to your customer, which includes the original seed data base64 encoded, and the signature we generated also base64 encoded, separated by a . delimiter.
4. You prompt your customer to input the entire key into your software.
5. You split the inputted key by the . value (the delimiter), which will give you the original seed data, and the signature, respectively. I.e. BASE64_SEED_DATA.BASE64_SIGNATURE.
6. You pass the data and signature to RSA to cryptographically verify it using the configured algorithm, e.g. PKCS1 PSS, using your account's public key.
7. You handle the cryptographic signature verification result (e.g. invalid or valid signature).

The reason you must specify a key attribute when using a signed scheme, e.g. RSA_2048_PKCS1_PSS_SIGN, is that our systems need some type of seed data to cryptographically sign. Our system does not auto-generate keys for licenses that utilize a cryptographic scheme.

You will need to create a new license key if the embedded data needs to change, e.g. when the min/max versions change. Let me know if you have any questions.