So you have two machines, one (let's all it A) running 2.14.57 and one (let's call it B) running 2.16.0. Has 2.14.57 ever run on B, or 2.16.0 on A? I'm just wondering whether, on B, 2.14.57 created the certificates (and 2.16.0 just copied them) or whether 2.16.0 created the certificates from scratch.
Can we add a successful trial to the table above? Does a 2.14.57 DCP with a 2.14.57 KDM work?
I do the DKDM/machine testing just to confirm that I actually used the right certs and workflow. If DCP-o-matic player on that machine can play the DCP, KDM creator on the same machine is technically able to issue KDMs for it.
Was the conclusion on this that the problem was purely the certs having expiry dates too far into the future?
We had this same problem with a DCP at a festival this weekend on a Barco projector.
Barco ICMP-01
Software version 1.4.4.0.27499
The error was the same as reported here "Invalid CPL signature" and the DCP was encrypted.
But this was NOT a DCP made with DCP-o-matic. Cert subject identifier is mtifilm.com so I suspect the DCP was made with their Cortex software. I don't know much about this software, except have ran into a problem with a DCP made with it before and the post house in that case said "you won't have heard of it, it's extremely high end professional software". LOLs!
The DCP which wouldn't play this weekend has a leaf cert with expiry date September 2121 (i.e. 100 years from now).
So, 3 things:
1. It would be useful to know if the cert expiry date was the definite culprit for this issue, so I can report to the DCP maker.
2. Did you figure out what expiry date is the latest that's safe? Is problem a long expiry in relative terms (i.e. more than 10 years from today) or absolute (date is after X)? If so, I'd like to submit a patch to dcp_inspect to flag this issue.
3. Carl thought you'd be interested to know that other "high end professional" DCP-making software has the same problem and, unlike DCP-o-matic, they seem NOT to have fixed it.
Carsten might well remember things better than me, but:
1. I'd say we're 99% certain that the certificate expiry date caused the problem.
2. I'm not sure that we proved this conclusively, but AFAICR we have a hunch that the Barco limit is the 2038 "epochalypse" but that some Sony systems might have an earlier limit.
3. It always amuses me to hear stories like this, of course
This bug contains some fairly cryptic notes about our investigations at the time.
We are sure that we tracked a bug in Barco ICMPs that is triggered by signing cert validation extending beyond 2038. However, we don't know wether other issues could trigger the same error message on Barco ICMPs. 2121 clearly is calling for trouble.
Barco 1.4.4.0 is recent enough (1.4.4.3 is current) - that issue came up with Barco <1.4.3.7 and wasn't solved by any Barco software update so far.
DCI/SMPTE specs does not limit any cert validity formally, so I guess it's a bug at least in Barcos and Sonys, but one that can simply be avoided.
1. Do you have any guess of what might cause the problem with Sony projectors? If dates before 2038 can trigger the bug, I assume it can't be related to the epocalypse.
2. Does this problem only arise with encrypted DCPs? Or do you know of cases where unencrypted but signed DCPs also trigger the bug? You would expect it should, but maybe the projectors don't bother verifying the signature unless the DCP is encrypted.
We never had issues with DCPs - both encrypted and unencrypted DCPs with long signing cert validity ingested okay, never a complaint. Only the KDMs were rejected.
Carl made a special version for me to test different validity timeframe with SONY and Barco. I plead guilty for not diagnosing both servers to the end, so, Carl simply played safe with the general versions.
Strictly speaking, an encrypted DCP is not an archive format, but a distribution format. So, maybe one simply shouldn't use protection time frames so far into the future. Most gear these KDMs are targeted to will no longer exist in 10 years anyway.