View Issue Details

IDProjectCategoryView StatusLast Update
0001728DCP-o-matic[All Projects] Bugspublic2020-05-20 22:22
ReporterCarsten Assigned Tocarl  
PriorityimmediateSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformMacOSOS XOS Version10.12
Product Version2.16.0 
Target Version2.16.0Fixed in Version 
Summary0001728: DKDM creation is broken in 2.15.x
Description

DKDM creation traditionally uses a very long validity window for the DKDM and has no option for the user to set his own time frame.

In 2.15.x there is a new check against signing cert validity - the default time frame for DKDM creation (2012 through 2112) doesn't comply with that check (signing certs created by DCP-o-matic are always shorter - 40 years from now when created by 2.15.x, 10 years from now when created by earlier versions).

So, DKDM creation always fails with that check in 2.15.x

see https://dcpomatic.com/forum/viewtopic.php?p=6590#p6590

  • Carsten
TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredUndecided

Activities

Carsten

2020-03-10 12:56

manager   ~0003743

Last edited: 2020-03-10 13:03

View 4 revisions

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

carl

2020-03-10 15:56

administrator   ~0003744

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!

Carsten

2020-03-10 16:29

manager   ~0003745

Last edited: 2020-03-10 16:35

View 4 revisions

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

carl

2020-03-10 20:39

administrator   ~0003746

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?

Carsten

2020-03-10 21:41

manager   ~0003747

Last edited: 2020-03-10 21:51

View 2 revisions

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

carl

2020-03-10 22:34

administrator   ~0003748

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.

carl

2020-05-20 22:22

administrator   ~0003829

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

Issue History

Date Modified Username Field Change
2020-03-10 12:44 Carsten New Issue
2020-03-10 12:44 Carsten Status new => assigned
2020-03-10 12:44 Carsten Assigned To => carl
2020-03-10 12:56 Carsten Note Added: 0003743
2020-03-10 12:58 Carsten Note Edited: 0003743 View Revisions
2020-03-10 12:59 Carsten Description Updated View Revisions
2020-03-10 12:59 Carsten Estimated work required => Undecided
2020-03-10 13:00 Carsten Note Edited: 0003743 View Revisions
2020-03-10 13:03 Carsten Note Edited: 0003743 View Revisions
2020-03-10 15:56 carl Note Added: 0003744
2020-03-10 16:29 Carsten Note Added: 0003745
2020-03-10 16:34 Carsten Note Edited: 0003745 View Revisions
2020-03-10 16:35 Carsten Note Edited: 0003745 View Revisions
2020-03-10 16:35 Carsten Note Edited: 0003745 View Revisions
2020-03-10 20:39 carl Note Added: 0003746
2020-03-10 21:41 Carsten Note Added: 0003747
2020-03-10 21:51 Carsten Note Edited: 0003747 View Revisions
2020-03-10 22:34 carl Note Added: 0003748
2020-05-17 20:18 carl Priority normal => immediate
2020-05-20 22:22 carl Status assigned => resolved
2020-05-20 22:22 carl Resolution open => fixed
2020-05-20 22:22 carl Note Added: 0003829