I generated a DCP yesterday and the resulting DKDM (for DOM) has the following start and end.
<ContentKeysNotValidBefore>2018-01-03T17:38:23+00:00</ContentKeysNotValidBefore>
<ContentKeysNotValidAfter>2027-12-28T17:38:23+00:00</ContentKeysNotValidAfter>
What does this depend on and how can I possibly increase the validity? As beyond this date I might not be able to issue KDMs if that is case so it would be important to somehow recreate the DKDM with extended validity.
Kindly guide.
DKDM - Validity Expiration Date
-
- Posts: 2954
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: DKDM - Validity Expiration Date
A DKDM is not something that is generated automatically in the process of generating a DCP. When you create a DKDM or KDM, the dialog offers you to set any desired time window - you just need to enter a different date based on the default values.
When you create or use a Self-DKDM for DCP-o-matic, time windows are not followed by DCP-o-matic as regular KDMs by cinema servers. Even if the default validity window runs out, you can still issue new KDMs. That's why there are no options to set a validity window for Self-DKDMs.
When I create a Self-DKDM in my installation, my validity window is:
<ContentKeysNotValidBefore>2022-10-20T10:47:46+00:00</ContentKeysNotValidBefore>
<ContentKeysNotValidAfter>2032-10-20T10:47:46+00:00</ContentKeysNotValidAfter>
Maybe this has to do with the installation age or initial creation of your prefs file. Carl may comment on this.
As I wrote, it's nothing to worry about, but maybe it would still be more useful to have that timeframe start on the current date - 1day or something like date.
When you create or use a Self-DKDM for DCP-o-matic, time windows are not followed by DCP-o-matic as regular KDMs by cinema servers. Even if the default validity window runs out, you can still issue new KDMs. That's why there are no options to set a validity window for Self-DKDMs.
When I create a Self-DKDM in my installation, my validity window is:
<ContentKeysNotValidBefore>2022-10-20T10:47:46+00:00</ContentKeysNotValidBefore>
<ContentKeysNotValidAfter>2032-10-20T10:47:46+00:00</ContentKeysNotValidAfter>
Maybe this has to do with the installation age or initial creation of your prefs file. Carl may comment on this.
As I wrote, it's nothing to worry about, but maybe it would still be more useful to have that timeframe start on the current date - 1day or something like date.
-
- Posts: 279
- Joined: Mon Nov 13, 2017 8:40 pm
Re: DKDM - Validity Expiration Date
This matter seems to me relevant to this one.
Probably has to do with the signing certificates created at that date (in this case, 2018).
To be honest, I couldn't get a clear idea of how does one circumvent the situation and what would be the effect of "Re-make certificates and key..." on "Signing DCPs and KDMs" nor the difference of the exact same button on the "Decrypting KDMs". The exchange derailed towards the way companies may keep a client hostage.
(I can get the notion, the difference between the signing certificates of DCPs and KDMs and the KDM certificates. But I still don't feel safe to press any such button.)
Probably has to do with the signing certificates created at that date (in this case, 2018).
To be honest, I couldn't get a clear idea of how does one circumvent the situation and what would be the effect of "Re-make certificates and key..." on "Signing DCPs and KDMs" nor the difference of the exact same button on the "Decrypting KDMs". The exchange derailed towards the way companies may keep a client hostage.
(I can get the notion, the difference between the signing certificates of DCPs and KDMs and the KDM certificates. But I still don't feel safe to press any such button.)