21 Oct
2016
21 Oct
'16
5:10 p.m.
I ask for your experience on this. I never fully understood the signing thing.
Can I create a supplemental for a signed unencrypted DCP that I didn't create?
I always thought that it's not possible, as I don't have the adequate
certificates.
I heard that an unsigned Interop supplemental may work, even with
encrypted material on the new CPL.
A couple tests with DOM failed, but I'm not really sure if it was
something else.
Thanks!
Manuel AC
--
http://akadcp.com/
https://www.facebook.com/akadcp
21 Oct
21 Oct
11:17 p.m.
Hi Manuel,
As far as I know people are already doing this with DoM. The OV is signed
by somebody else's chain, the VF by yours; these signatures jus proves who
created the OV and VF and that they haven't been altered since creation.
How did your tests with DoM fail exactly?
Best,
Carl
On Fri, 21 Oct 2016, Manuel AC via DCPomatic wrote:
I ask for your experience on this. I never fully
understood the signing thing.
Can I create a supplemental for a signed unencrypted DCP that I didn't create?
I always thought that it's not possible, as I don't have the adequate
certificates.
I heard that an unsigned Interop supplemental may work, even with
encrypted material on the new CPL.
A couple tests with DOM failed, but I'm not really sure if it was
something else.
Thanks!
Manuel AC
--
http://akadcp.com/
https://www.facebook.com/akadcp
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
22 Oct
22 Oct
1:26 a.m.
Probably because my VF was unsigned?
Haven't made a proper test. Don't even remember if ti was SMPTE or
IOP, but the same standard for OV and VF, that's for sure.
I'm having some access to a few servers in the next weeks and I will
make some testing.
Good to know that it should work! I was convinced that the chains had
to match because a VF is in its own way a modification of the original
DCP.
For general information, this also applies for encrypted content? I
remember some discussion about this, something like that signature
matching was not yet enforced, but it will at some point because is
required by SMPTE.
Thanks!
Manuel AC
On Fri, Oct 21, 2016 at 7:17 PM, Carl Hetherington via DCPomatic
<dcpomatic(a)carlh.net> wrote:
Hi Manuel,
As far as I know people are already doing this with DoM. The OV is signed
by somebody else's chain, the VF by yours; these signatures jus proves who
created the OV and VF and that they haven't been altered since creation.
How did your tests with DoM fail exactly?
Best,
Carl
On Fri, 21 Oct 2016, Manuel AC via DCPomatic wrote:
> I ask for your experience on this. I never fully understood the signing thing.
>
> Can I create a supplemental for a signed unencrypted DCP that I didn't create?
> I always thought that it's not possible, as I don't have the adequate
> certificates.
> I heard that an unsigned Interop supplemental may work, even with
> encrypted material on the new CPL.
> A couple tests with DOM failed, but I'm not really sure if it was
> something else.
>
> Thanks!
> Manuel AC
9:03 a.m.
Am 22.10.2016 um 03:26 schrieb Manuel AC via DCPomatic:
For general information, this also applies for
encrypted content? I
remember some discussion about this, something like that signature
matching was not yet enforced, but it will at some point because is
required by SMPTE.
As far as I know, it is optional for IOP, but has to be there, even in the form of a
'NullSignature' for SMPTE. And it's mandatory for encrypted content.
To my knowledge, it is currently only actively being used by IMAX for 3D projection. You
can play any 2D content on a digital IMAX, but 3D DCPs have to be signed with an IMAX
keychain. So it can not only be used to verify content integrity, but also to limit
specific signatures/DCPs to specific equipment.
And, as Carl explains, it is not there to sign the media assets, but to sign/verify the
presentation/CPL. E.g. to make sure an age-rating is not manipulated by creating a new
CPL.
I remember there is an ISDCF document with some info on this.
- Carsten
24 Oct
24 Oct
4:06 p.m.
Hi, a couple of notes wrt signature below:
As far as I know, it is optional for IOP, but has to
be there, even in the form of a 'NullSignature' for SMPTE. And it's mandatory
for encrypted content.
XML Signature is optional in both Interop and SMPTE CPL/PKL.
XML Signature is optional for CPL with both encrypted and plaintext asset references.
In other words: encrypted playlist elements do not imply XML signature for the playlist
document.
There is one scenario, though, where a signature is inferred for CPL:
The rights owners decide to actually secure correct playback - of an unaltered CPL -
through the means of ContentAuthenticator. The ContentAuthenticator, as part of a KDM,
will contain the thumbprint of the CPL signer’s leaf certificate.
Playback systems are required to reject playback when the KDM’s element can’t be
matched with what the CPL contains: A valid signature with the correct leaf cert.
This workflow will yield KDMs of the DCI-Any or DCI-Specific formulation. And is,
ttbomk, not used anywhere yet. Of course everyone should but we don’t :)
See ISDCF’s “Guideline for SMPTE KDMs and Certificates Behaviour” for details. (1)
Note that in the Digital Cinema use case there is no such thing as a 'NullSignature’.
Wolfgang
(1) http://isdcf.com/papers/ISDCF-Doc5-Guideline-formulations-Interop-and-SMPTE…
8:07 p.m.
Am 24.10.2016 um 18:06 schrieb Wolfgang Woehl via DCPomatic:
Note that in the Digital Cinema use case there is no
such thing as a 'NullSignature’.
Hi Wolfgang,
I was probably referring from memory to the usage of 'zero' in this passage of
this document:
(1) http://isdcf.com/papers/ISDCF-Doc5-Guideline-formulations-Interop-and-SMPTE…
'Note: Role of Certificate that Signs the KDM: The KDM shall be signed using a leaf
certificate with a SubjectName having zero to many role(s) (See SMPTE ST 430-2 for more
information about certificate roles). DCI requires the use of CPL signature in those cases
where the CPL references encrypted track files (See DCI Specification v1.2, section 5.2.3
"Packaging Concepts"). The rationale for KDM interpretation presented above
explains why this is a desirable practice. It should be noted however that DCI does not
require that a player reject a CPL that is not signed, even in the case where the CPL
references encrypted track files - except in the special case where the
ContentAuthenticator element is present in the KDM.'
- Carsten
3108
days inactive
3111
days old
5 comments
4 participants
participants (4)
-
Carl Hetherington -
Carsten Kurz -
Manuel AC -
Wolfgang Woehl