Hmm, interesting... I jumped between 2.15.47 and 2.10.5 to compare their behaviour - and was able to create a DKDM successfully with 2.15.47 after 2.10.5 dumped my prefs and these were recreated when starting 2.15.47 again (incl. the recreation of signing cert).

I now have a signing cert validity of 2020 through 2060, but the DKDM was created in 2.15.47 with a validity time frame of
<ContentKeysNotValidBefore>2020-04-10T12:25:12+01:00</ContentKeysNotValidBefore>
<ContentKeysNotValidAfter>2030-02-06T12:25:12+01:00</ContentKeysNotValidAfter>

That is from April 2020? That would mean, this DKDM becomes only valid in the future? As far as I know, some KDM mastering solutions will adhere to validity time frames in DKDMs?

Before with my existing prefs, and using 2.15.47, it was

<ContentKeysNotValidBefore>2012-01-01T01:00:00+00:00</ContentKeysNotValidBefore>
<ContentKeysNotValidAfter>2112-01-01T01:00:00+00:00</ContentKeysNotValidAfter>

What brings DCP-o-matic 2.15.47 to use a different DKDM validity window if prefs/certs change?

Wouldn't it be the best if we either allow the DKDM time frame to be set by the user (as with KDMs), and still check against signing cert validity? Or, at least create the DKDM validity window always within the current signing cert validity?

Why does 2.15 seem to create different DKDM validity windows when I come from 2.10.5 prefs? Is that due to the forced signing cert recreation in newer versions?

• Carsten

For some strange reason it was setting DKDM validity periods to 2 hours less than the validity period of the KDM decryption certificate. That doesn't seem to make much sense. I've changed it to use 2 minutes less than the signer cert validity. I guess we could add a UI to allow the user to specify the time period. It feels like it might give a false sense of security, though. Once somebody has a DKDM the cat is out of the bag and the validity period is kind of meaningless, AFAICS!

but - that is April 10th 2020, right?

<ContentKeysNotValidBefore>2020-04-10T12:25:12+01:00</ContentKeysNotValidBefore>

Why did DCP-o-matic 2.15.47 do that for a DKDM?

It's true that being able to set a DKDM validity window might give a false sense of security. But, whoever uses DKDMs SHOULD be able to understand these aspects, otherwise, he shouldn't ;-)

But I understand that some systems in fact do obey DKDM validity windows, and, from a right holders perspective, if he chooses encryption, why shouldn't he not be able to control the time window in which KDMs can be issued? So, having that option DOES make some sense. I think I remember that some german DCP release in repertoire at some point could not have new KDMs issued because the DKDM issued towards the german service company had expired.

But -clearly - we are talking about DCP-o-matic's built-in DKDM creation function here, which only target's one's OWN installation/config. DKDMs for other systems would need to be issued through the regular KDM creation process, which does offer explicit time window setting. So, being able to set a validity window towards yourself may indeed be a bit overcautious...

One possible issue could be that people might think that the DKDM time window will need to be set accordingly with the later KDMs being issued. Then people may issue their own DKDMs too short - but, again, that should not be a problem as long as DCP-o-matic is used for KDM creation from that DKDM - as it ignores the DKDM time window anyway.

Whatever. Yes, I guess it is best to always keep the DKDM within the signers certificate validity period. To get rid of possible timezone and clock drift issues - wouldn't it be useful to keep it within the signers certificate validity window +/- one day?

• Carsten

Sorry, a thinko. I meant 2 months less than the validity period, so DKDM validity starting one month after the cert validity, which I think is what you are seeing...?

With respect to the validity I'm just thinking that any distribution company could take the time-limited DKDM and make another un-time-limited one, should they choose; they don't need to be running "dodgy" software (that ignores validity periods) to have that capability.

You could use +/- one day but then you're more likely to hit the problem of a new installation being used to make a DKDM which then has a validity period starting before its signer; that's why I picked 1 minute. I can't imagine there should be many clock drift / timezone problems if the certificate is being read at the same time and on the same machine as the DKDM?

Alright... Hmm, I would hesitate to create a DKDM with a time window that starts in the future, but...it is only the future for max 2 months from cert creation ;-) plus, it really doesn't matter much, as that DKDM is only to be used by your own DCP-o-matic, which doesn't care for that aspect.
Still, two months seems overly/unnecessarily 'long' for me.

So, the fix for 2.15.48 is to look at the signing cert validity and create the DKDM based on that?

I am not into the signing/cert business enough to know wether such future validity windows would be recognized by some server KDM/signature checks. Once an actual KDM is created using such a 'futuristic' DKDM, both the time window of the original DKDM, as well as that of the signer certificate will be stripped off, yes?

• Carsten

What I've done so far is to make the DKDM window start 1 minute after the signing cert window starts and finish 1 minute before the signing cert window ends. Can you see any problems with that?

And yes, you're right, you can make an actual KDM using whatever validity period (and signed by whatever certs) you like. So long as you can get the "actual" keys out of the DKDM, that's all you really need. And that just needs the right private key to decrypt the payload.

I believe this should be OK in 2.15.76; let me know if not!