DC Auth Blog
Jul 3 2013 A Father’s Letter
Here’s a neat little trick how to generate a diff from stereoscopic material with FFmpeg. These diffs are one way to visualize convergence plane and disparity. It’s really simple: Take left and right eye and blend in subtraction mode. This will reduce structure where there is little to no disparity and emphasize structure vice versa. The result allows you to peek inside the bag of tricks used in contemporary stereoscopic filmmaking.
There’s a nice shot in The Hobbit – An unexpected Journey where they combined a focus rack and a convergence sweep (both from back to foreground). The shot starts out focusing on Bilbo in the background and ends up on Gollum’s ring which rests on rock in the foreground. With a stereo diff you can actually see the convergence zone — a dark band without structure — sweep towards you.
FFmpeg’s filtergraph mechanism is very versatile and allows to generate a stereo diff in one go:
ffmpeg -i jp2k_hobbit_trlf1_s_3d_rev_3D_24fps_4b81acb4-088b-4893-a577-7a6c5ee702a7_video.mxf \
-filter_complex "split [a] [b]; [a] select=not(mod(n\,2)) [left]; [b] select=mod(n\,2) [right]; [left][right] blend=all_mode=subtract" \
-crf 18 diff.mkvAll elements of the filtergraph described in -filter_complex have in- and output(s), using explicitly named labels (I’m omitting implicit labels like in for the 1st-in-graph input and out at the end). E.g. split is a filter which clones 1 input to x outputs, using 2 named a and b here. The trick is to take a stereoscopic container with alternating left/right sequence and pick each eye based on frame number (n).
This simple example should wet your appetite enough to invest a day or two in reading about and experimenting with FFmpeg filtergraphs. And when you’re done don’t forget to donate to the FFmpeg project :)
Wouldn’t it be nice if dcp_inspect told you more about a composition’s audio properties? RMS peaks, level peaks, silence in channels etc. — all these can be useful to confirm or detect what is really going on soundwise. Couple that with a bunch of useful hints (e.g. nag about Left/Right-only audio or levels being too high) and it just might help out in authoring where lots of people are struggling to do the right thing.
Of course, once we peek inside a container’s content to examine its core properties we need a mechanism to not only do it for plaintext essence but for encrypted essence as well. So there’s going to be a --dkdms option. Should be quite useful for festivals, too. Working the kinks out here. Upstream coming up.
Many moons ago I was heavy into audio tracker abuse and MIDI monstrosities. Apparently I needed to express something — not that I’m sure what it was, mind you. Now that I’m old I can look back fondly and set some of them free: Being Tina. Expect cheesy midi and camp-o-tastic melodrama!
Installing any of the tools mentioned below (dcp_inspect, cinemaslides etc.) has been painful, to say the least: A bleeding-edge XML parser is required, some non-trivial-to-build libraries one has never heard of before.
Well, fear no more, help is on the way: See Digital Cinema Tools Distribution for an easy-to-use setup script to install everything required in one step. Tested on a bunch of standard Linux distributions. You’ll be ready to go within 10 minutes. Enjoy and let me know how it works for you.
Here’s a short update about some Digital Cinema related open source tools:
First of all: If you haven’t already head on over to dcinemaforum.com. It’s a good entry-level resource for anything related to Digital Cinema. Run by Terrence Meiczinger, author of OpenDCP.
dcp_inspect (GPLv3) will inspect DCPs and check consistency and completeness. Basically it simulates ingest and validation, the process any cinema server must perform to make sure it has a valid package to play. One of dcp_inspect’s benchmark targets was Mike Radford’s awesome Fox Subtitle Test (aka Killer Reel) which consists of 3 packages actually. Mike’s distribution isn’t supposed to stress-test ingest but rather SMPTE subtitle implementations of various media blocks and servers. But its somewhat out-of-the-ordinary package structure and cross-references made it an interesting target for ingest consistency checks. So there. dcp_inspect can be quite chatty, see its report about the Killer Reel for an example.
The proof-of-concept code for building encrypted packages and KDMs with cinemaslides (GPLv3) is well-tested and stable. If you check it out please consider contributing test reports to Testing encrypted DCPs and KDMs, a server matrix which lists feedback on ingest and playback of encrypted (and signed) packages and KDMs made with open source tools.
kdm-decrypt.rb will decrypt Interop (should you ever run into one) and SMPTE KDMs if you have access to the targeted private key. Useful for testing round-trip.
xsd-check.rb will, via Libxml and Nokogiri and in conjunction with DC related schema files schema check Assetmaps, PKLs, CPLs and KDMs.
Point dc_crypto_context.rb at a directory holding X.509 certificates and it will tell you whether the certificates found in there are SMPTE/DCI compliant, chain-complete and verifyable, thus usable for signing packages. Create a proof-of-concept chain of compliant certificates with make-dc-certificate-chain.rb. You will want to tweak the code if you intend to use these in production, of course.
So all of the above are building blocks for more. Get in touch if you have questions or need a custom solution.
Couple of years ago we had a guest who is a giant in his field. An eloquent, sensitive and tender giant. Throughout his career he had created moving images that became iconic in many cases, always strong, never so-so. Even his bread-and-butter shots reach beyond. He had worked next to other giants for decades and the audience he addressed was awestruck. Asked for the secret to his success he said
I was always prepared.
Of course he went on to explain and illustrate what might have appeared mundane to some. Mentioned how part of any solid preparation was to think about alternatives, to learn and know about the relevant gear and then some, to fully appreciate the coming-up tasks, to sometimes move off the beaten (and working) path. But the essence of his advice was really just that: Be. Prepared.
His name: Michael Ballhaus.
While for most of us true greatness may lie beyond our reach we can always at least strive for excellence. In anything we do. Ballhaus’ motto is one of the simple recipes required for our daily dish of excellence.
What’s this got to do with anything?, you may ask. Well, I’m thinking the Prep Principle is in effect everywhere. Imagine your standard user forum board. Enter newbie user Boom, saying
Gee, this doesn’t work at all. It needs to work tomorrow. Someone help me.
Boom might be having a lucky day and indeed get helped out. More likely he just should have been prepared, would then have asked a better question and might have gotten piled with useful advice, invitations to weddings and birthday parties and serious challenges to run for president. And wouldn’t that be a Good Thing :?
If you have a minute take a look at your browser’s certificate manager (Chrome’s chrome://settings/certificates, Firefox’s Preferences → Advanced → Encryption → View Certificates → Authorities). Scroll down to find COMODO CA Limited. There you’ll find a bunch of self-signed authority certificates. Your browser uses these certificates to authenticate websites.
If your bank wants to provide secure web access to your account they go to Certficate Authorities like Verisign or Comodo, ask them to sign their certificate and thus establish a trusted certificate chain. Browsers trust companies like Verisign or Comodo to have a number of procedures in place to make sure the requester is actually your bank instead of a rogue imposter — The rogue imposter would trick you into using his fake bank site which would be authenticated by his fraudulently obtained certificate, enabling him to skim your login credentials.
With that in mind read Comodo’s statement, more details from Comodo, Mozilla’s statement and the whole story from a skilled user’s perspective.
PS: It is perfectly legitimate to tag the story as The Comodo Incident — rather than the Comodo Trusted Partner in Southern Europe Incident (where the actual breach occurred). A reliable CA needs to make sure that it can trust its Trusted Partners. While making sure is entirely not trivial it is fundamental.
I’m writing a little tool that will ease the pain with handling Digital Cinema/SMPTE compliant X.509 certificates. Right now the somewhat odd combination of Cinemaslides and the proof-of-concept script make-dc-certificate-chain.rb is the only open-source implementation of Digital Cinema related certificate/private key usage (for signature and encryption) and KDM generation I’m aware of. And while it works nicely it still locks us into a rather constrained space: Current Cinemaslides (v0.2010.12.23) will expect certain filenames and exactly 3 related certificates and make-dc-certificate-chain.rb will generate exactly these 3, nothing more, nothing less.
We can of course tweak make-dc-certificate-chain.rb, mainly to put our own namespace in there, and for one-shot projects this may work just fine.
But the minute we want to use these features in real-world production we need more flexibility. For example we would want to be able to bring in an existing, 3rd party certificate chain, use chains with sizes other than 3, check and verify chains etc.
While working on a tool to do the latter I was again thinking about an infrastructural requirement for content distribution and KDM authoring which regularly pops up in conversations and which is sometimes met with some doubt. Yet it is a crucial requirement for secure handling of valuable essence:
If we distribute content keys to anyone (via KDM) we need to absolutely make sure that the certificate we’re targeting our KDM at is part of a certified cinema server’s certificate chain.
Why? Remember how public-key-cryptography works: The parties involved have key pairs of which one sibling can be made public and the other sibling will be kept private. Although there is a strong mathematical binding between the public and private keys we cannot easily recreate a private key from its related public key only — The 1-way function used to create the public key constitutes the main elegance of public-key-cryptography. Senders use the public key to encrypt a message and only the related private key of the key pair will decrypt that message correctly.
Neat. Here’s the caveat, though: How do we make sure we’re using the right public key? Anyone can generate a key pair, publish its public key and declare This is Bob Boogleheimer’s public key. If you want to send Bob a secure message use this one. Anyone who can make us use their fake-Bob public key will be able to decrypt our message intended for Bob.
In the real people world that’s when grandma Betty Boogleheimer steps up to set things straight. She will say this:
About Bob I don’t know. All grown up now, he never shows up anymore. But you go ask my son Benny, a good kid. Look for the tiny fellow with the spots under his chin, that’s my Benny.
So she certifies her son Benny Boogleheimer who in turn would vouch for his son Bob Boogleheimer. It is this chain of vouchers that allows Bob to assert I’m a Boogleheimer, ask grandma Betty. Come to think of her, I should visit more often …
A chain of certificates offers pretty much that, supported by math. It allows to verify ancestry. Back to our problem of making sure we’re using the intended public key:
Given a target certificate we have to verify its ancestry to make sure that it is indeed the intended cinema server we’re delivering our content keys to.
At one point in time, no matter how our certificate store is organized, we have to verify that the related certificate chains lead back to a vendor-controlled root certificate (Grandma Betty, if you will). Only if that verification succeeds can we be sure to hit the bullseye with our KDM. So we need a tool for not only checking and verifying content provider certificates but device certificates and their certificate chains as well. Subtle differences there.
Apologies for being lengthy. The Gradual Construction of Thoughts while Speaking is the name of the process.
In digital cinema content keys are 16 bytes long (For details on trackfile and cryptographic infrastructure see SMPTE 429-6-2006). We use one content key per MXF container. Whoever gets hold of the key and its related, encrypted MXF can immediately decrypt that portion of essence, obviously. Whoever gets us to send her the encrypted key (via KDM) targeting a self-made certificate (that does not belong to a known cinema server) can immediately decrypt that portion of essence. If, for some reason, all we have is encrypted essence and the related content keys, we want to make sure these keys never get replaced by fake ones or else we won’t be able to extract plaintext essence anymore.
How to handle those 16 crucial bytes best? I think there is a number of valid ways and one that makes the most sense.
-
Plaintext content keys. Like a file called
f1e404b2-d229-4860-aa74-1445d9e6a806(key UUID) which contains23d1be6dba632e34a1d20983446c07bd(16 bytes content key). Or a simple key-value store. It’s important to keep the key UUID around, otherwise we wouldn’t be able to retrieve the right key (which is referenced by CPLs through its UUID).
The main advantage here is we’re ready to go and use the key for a KDM, independent of all else. This method might be perfectly fine for some scenarios where the value of the essence has a very small financial component and where we can, with some confidence, assume noone will be twiddling with our computer.
- Encrypted content keys. Could be the above plaintext format with a lock, either at the front door or specific to each content key.
Main advantage is the increased level of protection, obviously. Also the protection mechanisms and levels can be custom-tailored for specific constraints.
The main disadvantage, like with many custom or proprietary solutions, is the required maintenance of the format in the future. Will we be able to understand our custom protection mechanisms 10 years from now?
- Self-targeted KDM. This one makes the most sense to me. Instead of targeting a KDM at a distribution target (a digital cinema server) we deliver the content keys to our own front door. We, as gatekeepers of the targeted private key component, are the only ones able to decrypt that KDM. Also we keep the content keys somewhat in context. Which is good for toolchains and maintenance.
Keeping content keys in self-targeted KDMs involves a strong binding to the issuing facility — us in this case. A transfer of the caretaking would happen, again, via KDMs targeted at the other party’s certificate.
Duh! moment upon realizing that content keys can be kept safely in a self-targeted KDM as well.
Finally succeeded in playing an encrypted DCP on our XDC with a KDM out of cinemaslides. Turns out the XDC’s errors were subsequent errors, originating in a namespace prefix definition issue. Staring at XDC’s error codes
0x9000054D : invalid/malformed EncryptionMethod
0x9000043D : missing X509IssuerNameand the cinemaslides KDM’s valid, non-malformed
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">and the non-missing
<ds:X509IssuerSerial>
<ds:X509IssuerName>dnQualifier=3ObtIhFENkqUAjlDlEKzpTnkB5s=,CN=.dcstore.INTERMEDIATE,OU=csc.example.org,O=example.org</ds:X509IssuerName>
<ds:X509SerialNumber>7</ds:X509SerialNumber>
</ds:X509IssuerSerial>it became apparent that I was looking at the wrong spot. Or rather the server’s XML parser could not see the scoped nodes. The non-working KDM had these namespace prefix definitions (note
ds and dsig):<DCinemaSecurityMessage
xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns="http://www.smpte-ra.org/schemas/430-3/2006/ETM">to accomodate for what I took as reference prefix usage (CineCert’s KDM Generator for DCI Test Content v1.3 outputs XML using both
ds and dsig). Having identical values for different prefixes assigned in an XML document’s root node is not valid (according to Namespaces in XML). Removing one of them and adjusting prefix usage makes all the difference — at least on our XDC Solo G3 (5.5.3.88 SP2). I wonder why enc fails, though.
I’m seeing a whole slew of XML related errors on the XDC Solo G3 now, depending on some tentative changes to the KDM code. Same class of errors, which is good. Cryptic errors nonetheless. Lesson learned: A successful ingest means pretty much nothing. At least our XDC Solo G3 runs the real content and key checks only upon select for playback. Pants-down-open-source in progress …
… at XDC the showstopper, mentioned below, quite likely is gone. KDM ingest tests tomorrow. Not that there might be no other issues anymore. But this one XDC is explicit about. It concerns a KDM’s MessageType tag which the original SMPTE standard (430-1-2006) specifies as having a value of http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type. In 2009 SMPTE released an amendment to that standard (430-1-Am1-2009) which notifies users of a potential change of that value, should there be an official revision of 430-1-2006. The note says
The MessageType value “http://www.smpte-ra.org/430-1/2006/KDM#kdm-key-type” is legal and correct, but, in the event a future revision of the KDM specification requires a revision to the MessageType value, the MessageType value should follow the pattern http://www.smpte-ra.org/430-1/2006/KDM and match the target namespace of the schema.
Note the change concerning #kdm-key-type. In the cinemaslides proof-of-concept code I had indeed used the amended value for MessageType.
My assumption that the work of vendors aiming at full SMPTE compliance would include this amendment was, well, just that: an assumption. And a wrong one at that. Fact is the amendment 430-1-Am1-2009 is only up for approval, thus it needn’t necessarily work in servers right now.
Big thanks go out to XDC’s R&D for revealing what the related error codes were pointing at. This one was not on my list of things to check and test at all and I probably would have tried a million things before realizing its potential.
It’s tiny details like this kind of support that confirm the general impression of a vendor: Quick, up to their game, helpful. It’s a good thing when vendors understand that opening up a little will generate business in the long run. Good for the platform.
See cinemaslides’ proof-of-concept code (classes DCTools, KDM_SMPTE_430_1_2006 and DCSignatureKDM). Right now it is tightly coupled to make-dc-certificate-chain.rb’s output. It expects 3 related certificates with specific names in a specific location pointed at with an environment variable called CINEMACERTSTORE. It also expects a specific keyfile format and keyfile names — Created when you run cinemaslides --encrypt ... to build encrypted DCPs:
<Key UUID>:<Key type>:<Key data>with the filename set to the key’s ID. This is somewhat prototype legacy. Will probably change to key data only.
Here’s a recipe for trying it out:
$ mkdir certstore
$ cd certstore
# generate 3 related certificates in certstore:
$ make-dc-certificate-chain.rb
# add the following with an absolute path to .bashrc/.tcshrc to have it set permanently (pwd used here for convenience):
$ export CINEMACERTSTORE=`pwd` # note the backticks
$ cd ../
# cinemaslides uses a work directory to store assets, DCPs (unless you use -o) and content keys:
$ mkdir cinemaslidesworkdir
$ cd cinemaslidesworkdir
# again add the following with an absolute path to .bashrc/.tcshrc (pwd used here for convenience):
$ export CINEMASLIDESDIR=`pwd` # note the backticks
$ cinemaslides -t dcp --encrypt --title "Encryption Test" -o ENCRYPTION-TEST -x cut,1 <imagefile> <audiofile>
# "mis-use" your own leaf certificate as a "device target". this allows for later decryption of the KDM's payload:
$ cinemaslides --kdm --cpl ENCRYPTION-TEST/cpl_<uuid>_.xml --target $CINEMACERTSTORE/leaf.signed.pem -v debug
# KDM file will be called differently:
$ kdm-decrypt k_ENCRYPTION-TEST_dcstore.LEAF_20101129_20101227_WOL_OV_4c645d45.xml $CINEMACERTSTORE/leaf.key
# cross-check kdm-decrypt's output with the CPL's KeyId's and the related keydata (stored in $CINEMASLIDESDIR/keys) ...Some progress with cinemaslides’ KDM mode — transitioning from prototype code to a more general handling rather painful, though. That’s why the code is not pushed upstream yet. Will come up in the next days.
The current status of KDM mode I’d describe as blissfully showstopped. It works up to the point of successful KDM ingest on a cinema server which will then display the correct time window next to the targeted CPL plus a nifty unlocked icon. Playback select of that CPL does not work, though, and triggers error messages centering around
-- The KDM for clip (file: E:/CineStore/content/cpl/536517df-99fb-4795-bc77-3bfbc6ffeeb5/a32ffb5a-acb2-4c80-85de-3842423b6005.xml) load failed: SM error [90000131] LIBITM_ERR_KDM_SMPTE_430_1, with xml error [90000527] 2415920423
-- KDM XML error: 0x80060227Well,
$ xmlsec1 verify --pubkey-cert-pem leaf.signed.pem --trusted-pem intermediate.signed.pem --trusted-pem ca.self-signed.pem --id-attr:Id http://www.smpte-ra.org/schemas/430-3/2006/ETM:AuthenticatedPublic --id-attr:Id http://www.smpte-ra.org/schemas/430-3/2006/ETM:AuthenticatedPrivate k_CRYPT_TST_SOLOG3-MVC200.V5.000487.00000369_20101126_20101206_WOE_OV.xml
OK
SignedInfo References (ok/all): 2/2
$ schema-check k_CRYPT_TST_SOLOG3-MVC200.V5.000487.00000369_20101126_20101206_WOE_OV.xml SMPTE-430-3-2008-ETM.xsd SMPTE-430-1-2006-Amd-1-2009-KDM.xsd
[no errors]There might still be some canonicalization issues lurking. Also I’m seeing an awful lot of (Note the namespace prefix definitions for dsig and enc and note the absence of a definition for ds)
<DCinemaSecurityMessage xmlns="http://www.smpte-ra.org/schemas/430-3/2006/ETM" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#">
<!-- omitted nodes -->
<ds:DigestMethod xmlns:ds="http://www.w3.org/2000/09/xmldsig#" ...>in the wild without a
ds definition in any of DigestMethod ‘s parent nodes. Nokogiri, for example, will not build an XML node with an undefined namespace prefix. From what I understand I’d say Nokogiri is doing the right thing here and I’m a bit flabbergasted. What am I missing?
Nov 25 2010 KDM, signing AuthenticatedPublic and AuthenticatedPrivate elements
xmlsec1 --sign --id-attr:Id http://www.smpte-ra.org/schemas/430-3/2006/ETM:AuthenticatedPublic --id-attr:Id http://www.smpte-ra.org/schemas/430-3/2006/ETM:AuthenticatedPrivate --privkey-pem #{ signer_key_file } --trusted-pem #{ ca_cert_file } --trusted-pem #{ intermediate_cert_file } #{ tmp.path }
xmlsec1 --sign --id-attr:Id http://www.smpte-ra.org/schemas/430-3/2006/ETM:AuthenticatedPublic --id-attr:Id http://www.smpte-ra.org/schemas/430-3/2006/ETM:AuthenticatedPrivate --privkey-pem #{ signer_key_file } --trusted-pem #{ ca_cert_file } --trusted-pem #{ intermediate_cert_file } #{ tmp.path }Got a prototype working. It produces valid XML and kdm-decrypt succesfully decrypts the payload. No server tests, yet. Code needs to get dressed, too. Issue remaining wrt Id annotation of ID_AuthenticatedPublic and ID_AuthenticatedPrivate. Still, a joyous day.
Something interesting came up with another test DCP (Encrypted essence. CPL and PKL carrying certificates made with make-dc-certificate-chain.rb v0.2010.11.16 — these had validity periods of 365 days each): Upon select for playback — which, expectedly, fails because the CPL has no valid KDM associated — our XDC logs
Certificate chain verification should fail: issuer-subject validities do not fit
Examination of the certificates revealed that the leaf certificate’s validity period2 exceeded the validity period of its issuer, the intermediate certificate — by 1 minute. Obviously a minute had flipped during script execution. According to SMPTE 430-2-2006 section 6.2 Validation rules this would lead to verification failure:
Reject the certificate if the validity dates of the child certificate are not contained within the validity dates of the parent certificate. Specifically, the start date of the child certificate shall be identical to or later than the start date of the parent certificate, and the end date of the child certificate shall be identical to or earlier than the end date of the parent certificate. Validation rule 18
Interestingly enough the XDC Solo G3 (5.5.3.88) explicitly logs ... verification should fail instead of the expected ... verification failed. XDC? Update: I’m thinking the box would indeed fail in the presence of a KDM containing the described above type of out-of-bounds certificate chain. It indicates the potential problem. Will test once the last bug is shaken off the KDM tree.
It’s useful to ponder the concept of validity periods and their constraints on certificate chains: If an issuing certificate authority is asked to vouch (by signing) for a certificate the above restriction allows to technically verify the issued certificate at any given time during its validity period. Had the issuer certificate’s validity expired there would be no technical way to verify, its life-span having run out.
I’m thinking: If an issuer’s authority was incontestable vouching for a certificate whose validity period exceeded the authority’s would be conceivable just as well. Though there would be no technical verification path the general assumption could be
If, at any point in time, the certificate authority was ready to vouch (by signing) for this certificate its intentions could well include vouching for a period of time exceeding its own life-span. Like a father or a mother pass their names on to their children, well aware of the fact that their life-span will end before their children’s.
But then again, of course, the whole point of a technical certification is a technical verification path. Well, just pondering.
Realised I had a wrong Algorithm specification in <SignatureMethod>, probably from staring too long at Interop cpl’s, where 2000/09/xmldsig#rsa-sha1 seems to be valid (Keep in mind that xmlsec will act accordingly when calculating <SignatureValue>). Targeting SMPTE packages here, of course, so this got changed to the required 2001/04/xmldsig#rsa-sha256.
Figured I would have to change the CN RDN of the signing certificate as well: It had a non-compliant <roles> <entity label> sequence in there, like CS dcstore.leaf instead of the compliant CS.dcstore.leaf (Note the leftmost .). With more than 1 role this would have to be something like RO CS.dcstore.leaf. Standards and CTP are explicit on this topic, so servers’ verification should fail when this is wrong.
Funny thing is:
I have 1 package with <SignatureMethod> declared as 2000/09/xmldsig#rsa-sha1 and a signer cert’s CN with RO SM CS.dcstore.leaf
and another one with <SignatureMethod> declared as 2000/09/xmldsig#rsa-sha1 and a signer cert’s CN with CS.dcstore.leaf
The first verifies without errors, the second fails. In my opinion both should fail. This on an XDC Solo G3 (5.5.3.88)
Update: See entry above (Nov 19) for the real reason of verification failure.
Verify signed XML (signed with leaf.key. leaf.signed.pem would be the corresponding certificate, signed by intermediate.key. The certificate intermediate.signed.pem is signed by ca.key. These keys and certificates were created with make-dc-certificate-chain.rb).
$ xmlsec1 --verify --trusted-pem ca.self-signed.pem --trusted-pem intermediate.signed.pem cpl.xml
OK
SignedInfo References (ok/all): 1/1
$ openssl verify -CAfile ca.self-signed.pem -untrusted intermediate.signed.pem leaf.signed.pem
leaf.signed.pem: OKThings seem to be fine here. CPLs signed with leaf.key and the corresponding certificate chain ingest in Fraunhofer’s
easyDCP Player without messages. Ingest on an XDC Solo G3, too, but with the error message
XML certificate chain is invalid. Signature verification is skipped
Trying to hunt this down right now.