25 Jan
2016
25 Jan
'16
10:46 p.m.
Still trying to get a grip on our Barco certificate issue.
What I don't understand is - there seem to be certificate/pem files with one, or
multiple certificate blocks in them (multiple '-----BEGIN CERTIFICATE-----'
'-----END CERTIFICATE-----' blocks).
Sometimes when I request a certificate, I get a single .pem file, sometimes I get multiple
files. I understand there are separate certificates for J2K and MPEG-2, and also
certificates that include the root chain or not.
E.g. when I download my ICMP certificate from the ICMP itself, I get an 8KB
BARCO-ICMP-9730000916.pem.
When I request it from Barco, I get a ZIP file with two files:
Barco-ICMP.9730000916_cert.pem 4kB
Barco-ICMP.9730000916_chain.pem 8kB
Which of the two are actually needed for KDM creation? DOM seems to accept both - but when
I create encrypted DCPs, neither works.
The two 8kB files are bit-identical.
I received a Doremi certificate file that I used sucessfully with DOM to create and play
an encrypted DCP - but that file only contained a single certificate block. How can it be
those certificate files are so different?
For this Doremi server, the Doremi FTP site delivers a ZIP with SIX certificate files:
dcp2000-254124.cert.mpeg.pem - 4kB
dcp2000-254124.cert.sha256.pem - 4kB
dcp2000-254124.cert.sms.pem - 4kB
dcp2000-254124.chain.mpeg.pem - 12kB
dcp2000-254124.chain.sha256.pem - 12kB
dcp2000-254124.chain.sms.pem - 12kB
I would think that the mpeg.pem is for MPEG2-Interop KDMs, sha256.pem is for
J2C-SMPTE-KDMs, and that sms.pem is for verifying signed log files from the server?
I understand that chains will not only contain the device certificate itself, but also
it's parent-certificate, in the case of the Barco ICMP e.g. leading the device
cetificate back to Barco. As such, I would assume that for KDM creation, a software would
be able to work with both types of files? How will a software know which is which, when
the number of certificate blocks differ between devices?
- Carsten
26 Jan
26 Jan
3:33 p.m.
Hi Carsten,
On Mon, 25 Jan 2016, Carsten Kurz via DCPomatic wrote:
Still trying to get a grip on our Barco certificate
issue.
What I don't understand is - there seem to be certificate/pem files with
one, or multiple certificate blocks in them (multiple '-----BEGIN
CERTIFICATE-----' '-----END CERTIFICATE-----' blocks).
Sometimes when I request a certificate, I get a single .pem file,
sometimes I get multiple files. I understand there are separate
certificates for J2K and MPEG-2, and also certificates that include the
root chain or not.
That's it, as I understand it. Sometimes you get just the leaf
certificate (which contains a public key used to encrypt KDMs) and
sometimes you also get the rest of the chain so you can see the trust.
E.g. when I download my ICMP certificate from the ICMP
itself, I get an 8KB BARCO-ICMP-9730000916.pem.
When I request it from Barco, I get a ZIP file with two files:
Barco-ICMP.9730000916_cert.pem 4kB
Barco-ICMP.9730000916_chain.pem 8kB
Which of the two are actually needed for KDM creation? DOM seems to accept both - but
when I create encrypted DCPs, neither works.
The single certificate should be enough.
The two 8kB files are bit-identical.
I received a Doremi certificate file that I used sucessfully with DOM to
create and play an encrypted DCP - but that file only contained a single
certificate block. How can it be those certificate files are so
different?
Which files are you talking about being "different" here?
I understand that chains will not only contain the
device certificate
itself, but also it's parent-certificate, in the case of the Barco ICMP
e.g. leading the device cetificate back to Barco. As such, I would
assume that for KDM creation, a software would be able to work with both
types of files? How will a software know which is which, when the number
of certificate blocks differ between devices?
The software must use the leaf certificate to create the KDM. I would
guess that the easiest way to handle chains would be to use the leaf
certificate (which the software can find).
Regards,
Carl
27 Jan
27 Jan
12:47 a.m.
Am 26.01.2016 um 16:33 schrieb Carl Hetherington via DCPomatic:
That's it, as I understand it. Sometimes you get
just the leaf
certificate (which contains a public key used to encrypt KDMs) and
sometimes you also get the rest of the chain so you can see the trust.
And I guess, if the software creating the KDMs is set to follow the certificate chain up,
it could also verify wether the device or company would be DCI compliant, and if there is
no chain leading to such result, it could refuse to create KDMs for specific content (like
main-stream features).
I heard that Cine Cert software does that, effectively preventing the creation of KDMs for
non-DCI approved equipment with that software.
- Carsten
10:15 a.m.
2016-01-27 1:47 GMT+01:00 Carsten Kurz via DCPomatic <dcpomatic(a)carlh.net>et>:
Am 26.01.2016 um 16:33 schrieb Carl Hetherington via DCPomatic:
If you're talking about Waima, as far as I know, you need both chain and
leaf. When you register a certificate, it uses the chain for verification,
then only the leaf for KDM creation.
Wolfgang's cinemaslide can use chain of leaf to do that.
Carsten, are your Interop and SMPTE packages signed? Signed CPL+KDM is
mandatory for SMPTE encrypted packages.
Can you send me the certificate for your server? I'll send you two other
SMPTE / Interop samples made with other tools.
Best,
Lilian
That's it, as I understand it. Sometimes you
get just the leaf
certificate (which contains a public key used to encrypt KDMs) and
sometimes you also get the rest of the chain so you can see the trust.
And I guess, if the software creating the KDMs is set to follow the
certificate chain up, it could also verify wether the device or company
would be DCI compliant, and if there is no chain leading to such result, it
could refuse to create KDMs for specific content (like main-stream
features).
I heard that Cine Cert software does that, effectively preventing the
creation of KDMs for non-DCI approved equipment with that software.
- Carsten
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
1:15 p.m.
Am 27.01.2016 um 11:15 schrieb lilian:
Carsten, are your Interop and SMPTE packages signed?
Signed CPL+KDM is mandatory for SMPTE encrypted packages.
Can you send me the certificate for your server? I'll send you two other SMPTE /
Interop samples made with other tools.
That would be great. Yes, I always create signed packages.
When browsing the playout logs, I now see there are some audio errors as well. For these
tests, I created only 2ch-audio DCPs. Maybe the Barco ICMP doesn't like that. It looks
as if ingest and formal verification of DCP and KDM work, but it then gives up only on
decoding the actual encrypted content at playout time.
Now that I know the leaf certificate worked that I sent to this professional mastering
studio, I will do some more testing. Before, I wasn't even sure I had the proper
certificate.
I'll send the same certificate to you.
Thanks - Carsten
1:17 p.m.
Le 27/01/2016 14:15, Carsten Kurz a écrit :
Am 27.01.2016 um 11:15 schrieb lilian:
SMPTE should handle 6 channels. Not sure that
it is mandatory.
Carsten, are your Interop and SMPTE packages
signed? Signed CPL+KDM is mandatory for SMPTE encrypted packages.
Can you send me the certificate for your server? I'll send you two other SMPTE /
Interop samples made with other tools.
That would be great. Yes, I always create
signed packages.
When browsing the playout logs, I now see there are some audio errors as well. For these
tests, I created only 2ch-audio DCPs. Maybe the Barco ICMP doesn't like that. It looks
as if ingest and formal verification of DCP and KDM work, but it then gives up only on
decoding the actual encrypted content at playout time.
Now that I know the leaf certificate worked that I sent to this professional mastering
studio, I will do some more testing. Before, I wasn't even sure I had the proper
certificate.
I'll send the same certificate to you.
Thanks - Carsten
28 Feb
28 Feb
12:04 p.m.
On Wed, 27 Jan 2016, Carsten Kurz via DCPomatic wrote:
Am 26.01.2016 um 16:33 schrieb Carl Hetherington via DCPomatic:
Indeed, software could refuse to operate if it didn't like the look of a
particular certificate chain.
Best,
Carl
That's it, as I understand it. Sometimes you
get just the leaf
certificate (which contains a public key used to encrypt KDMs) and
sometimes you also get the rest of the chain so you can see the trust.
And I guess, if the software creating the KDMs is set to follow the
certificate chain up, it could also verify wether the device or company
would be DCI compliant, and if there is no chain leading to such result,
it could refuse to create KDMs for specific content (like main-stream
features). I heard that Cine Cert software does that, effectively
preventing the creation of KDMs for non-DCI approved equipment with that
software.
3347
days inactive
3381
days old
6 comments
4 participants
participants (4)
-
Carl Hetherington -
Carsten Kurz -
lilian -
lilian lefranc