SMPTE ST 430-7-2008 D-Cinema Security - Facility List Message.pdf

《SMPTE ST 430-7-2008 D-Cinema Security - Facility List Message.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 430-7-2008 D-Cinema Security - Facility List Message.pdf（23页珍藏版）》请在麦多课文档分享上搜索。

1、 Copyright 2008 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved October 28, 2008 Table of Contents Page Foreword . 2 Intellectual Property 2 1 Scope . 3 2 Conformance Notation . 3 3 Normative References . 3 4 Glossary . 4 5 Ov

2、erview of the FLM 5 5.1 Basic FLM Elements and D-Cinema Relationships (Informative). 5 5.2 XML File Structure . 7 5.3 XML Overview of the FLM (Informative) . 7 6 Authenticated and Unencrypted Information 9 6.1 MessageType. 9 6.2 RequiredExtensions. 9 6.2.1 FLMPartial (Optional) 9 6.2.2 FacilityInfo.

3、 9 6.2.3 SecurityDeviceList 12 6.3 NonCriticalExtensions 13 7 Authenticated and Private (Encrypted) Information .13 8 Signature Information. 13 9 XML Diagram Legend (Informative) 14 9.1 Element Symbols . 14 9.1.1 Examples 14 9.2 Model Symbols (“Compositors“) 15 9.3 Types . 15 9.4 Model Groups and Re

4、ferences 15 Annex A Design Features and Security Goals (Informative) . 17 Annex B Bibliography (Informative) 18 Annex C XML Schema for FLM (Normative) .19 Annex D XML Example FLM (Informative) 21 Page 1 of 23 pages SMPTE 430-7-2008SMPTE STANDARD D-Cinema Security Facility List Message SMPTE 430-7-20

5、08 Page 2 of 23 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineeri

6、ng Documents, including Standards, Recommended Practices and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, includi

7、ng ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its Administrative Practices. SMPTE Standard 430-7 was prepared by Technology Committee DC28. Intellectual Property At the time of publication no notice had been received by SMPTE claiming

8、 patent rights essential to the implementation of this Standard. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. SMPTE 430-7-2008 Page 3 o

9、f 23 pages 1 Scope This specification defines a “Facility List Message” (FLM) for use in Digital Cinema (D-Cinema) systems. The FLM has been designed to deliver digital certificate information between exhibition sites (facilities), KDM distributors, and/or content owners. The FLM carries three class

10、es of information: Identification and useful information pertaining to the exhibition complex (FacilityInfo), Optionally, descriptive information about the device (DeviceDescription) The digital cinema certificate(s) (KeyInfo) information of the device The FLM is based on the D-Cinema generic Extra-

11、Theater Message (ETM) format specified in SMPTE 430-3. It uses XML to represent the D-Cinema Digital Certificate information specified in SMPTE 430-2, and provides security using standardized XML encryption and signature primitives. The FLM message uses X.509 digital certificates, constrained for th

12、e digital cinema application in SMPTE 430-2, to provide authentication and trust. Note: The brackets convention “” as used herein denotes either a normative or informative reference. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable or contain

13、s the conformance language keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.

14、 All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be followed in order to conform to the document and

15、from which no deviation is permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the

16、 negative form) a certain possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, an

17、d may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one that includes all mandatory provisions (“shall“) and, if implemented, all recom

18、mended provisions (“should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows. Normative pr

19、ose shall be the authoritative definition. Tables shall be next, followed by formal languages, then figures, and then any other language forms. 3 Normative References The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time

20、 of publication, the editions indicated were valid. All standards are subject to revision, SMPTE 430-7-2008 Page 4 of 23 pages and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. CountryC

21、ode ISO 3166, Codes for the Representation of Names of Countries, 1993. See: http:/www.iso.org/iso/en/prods-services/iso3166ma/index.html CountryDialingCode ITU-T, List of ITU-T Recommendation E.164 assigned country codes, October 2006. See http:/www.itu.int/pub/T-SP-E.164D-2006/en Data Types SMPTE

22、433-2008, D-Cinema XML Data Types DateTime IETF RFC 3339, Date and Time on the Internet: Timestamps. G. Klyne and C. Newman. July 2002. See: http:/www.ietf.org/rfc/rfc3339.txt Email IETF RFC 822, Standard for the Format of ARPA Internet Messages, D.H. Crocker, August 1982. See http:/www.ietf.org/rfc

23、/rfc0822.txt ETM SMPTE 430-3-2006, D-Cinema Operations Generic Extra Theater Message Format URI IETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, and L. Masinter. August 1998. See http:/www.ietf.org/rfc/rfc2396.txt UUID “A Universally Unique Identifier (

24、UUID) URN Namespace” July 2005. See: http:/www.ietf.org/rfc/rfc4122.txt KeyInfo “The KeyInfo Element.” See http:/www.w3.org/TR/xmldsig-core/#sec-KeyInfo XML World Wide Web Consortium (W3C) (2004, February 4). Extensible Markup Language (XML) 1.0 (Third Edition) XML Schema World Wide Web Consortium (

25、W3C) (2004, October 28). XML Schema Part 1: Structures (Second Edition) XML Schema World Wide Web Consortium (W3C) (2004, October 28). XML Schema Part 2: Datatypes (Second Edition) 4 Glossary The following paragraphs define the acronyms used in this document: Base64: A printable encoding of binary d

26、ata. See Base64. ETM: Extra Theater Message See SMPTE 430-3 FLM: Facility List Message IETF: Internet Engineering Task Force standards group. IP: Internet Protocol. An IETF standard. ISO: International Standards Organization KDM: Key Delivery Message (See SMPTE 430-1 SM: Security Manager TMS: Theate

27、r Management System X.50: A widely used and supported digital certificate standard. XML: Extensible Markup Language SMPTE 430-7-2008 Page 5 of 23 pages 5 Overview of the FLM 5.1 Basic FLM Elements and D-Cinema Relationships (Informative) This standard presents a specification for the Facility List M

28、essage (FLM) for use in a Digital Cinema (D-Cinema) system. The D-Cinema Facility List Message is normally sent: 1. Between a theater facility and a KDM distributor, or 2. Between a KDM distributor and a content owner, or 3. Between a KDM distributor or a content owner, and a certificate authenticat

29、ion entity. D-Cinema systems require that content keys and “trusted equipment” information (Trusted Device List or TDL) be created for use in exhibition facilities. The vehicle for communicating this information to the facility is the Key Delivery Message (KDM), specified in SMPTE 430-1. The FLM sup

30、plies the essential information required to create the KDMs for an exhibition facility. The message contains the D-Cinema Digital Certificate information, specified in SMPTE 430-2, of each security-related device in the facility. The general flow of information leading to the creation of KDMs is ill

31、ustrated in Figure 1. Note that the element should contain the full certificate chain for ease of processing. SecureProcessingBlock #1DC-CertSecureProcessingBlock #2DC-CertFacility ListMessageDC-CertDC-CertCertificateInformationCertificateInformationKDM DistributorExhibition FacilityKDMsContent Key(

32、s)Figure 1 FLM Information Flow The FLM message is a particular instance of the generic XML security wrapper defined by the D-Cinema Generic Extra Theater Message Format specified in SMPTE 430-3, and uses digital certificates defined by the D-Cinema Digital Certificate specified in SMPTE 430-2. This

33、 document defines the characteristics that are SMPTE 430-7-2008 Page 6 of 23 pages specific to the FLM, and should be followed in combination with SMPTE 430-3, which in turn references the digital certificate specification. The FLM uses XML to communicate the digital certificate data and provides se

34、curity using the XML Encryption and Signature primitives. As there may be a need to authenticate each device certificate contained by the recipient of the FLM, the complete device certificate is carried. The device certificates contain only Public Key information and not Private Keys, so there is no

35、 risk of exposing secrets. The FLM does not utilize encryption to secure its payload, and so does not employ the Authenticated Private element of the ETM. However, the FLM employs the digital signature of the ETM to allow downstream entities to authenticate its payload and origin. The essential payl

36、oad of the FLM is illustrated in Figure 2 below. Facility ListAuthenticated Public InformationSecurityDevicey Subject X509 Certificatey Intermediate X509 Certificatesy ForensicMarkIdy DeviceDescription (Optional)SecurityDevicey Subject X509 Certificatey Intermediate X509 Certificatesy DeviceDescript

37、ion (Optional)SecurityDevicey Subject X509 Certificatey Intermediate X509 Certificatesy ForensicMarkIdy DeviceDescription (Optional).IssueDateFacilityInfoSecurityDeviceListFigure 2 FLM Payload SecurityDevice elements contain both descriptive and security-related information, and are listed in no par

38、ticular order or organization. Subject X509 certificates and intermediate X509 certificates refer to elements of the certificate chain. The leaf certificate contained in each SecurityDevice element corresponds to either a KDM recipient or an entry in the DeviceList of the KDM. Note that the example

39、in Figure 2 is only illustrative of how the FLM is constructed. SMPTE 430-7-2008 Page 7 of 23 pages 5.2 XML File Structure The structures defined in this document are represented using the Extensible Markup Language (XML) XML 1.0, and specified using XML Schema XML Schema Part 1: Structures and XML

40、Schema Part 2: Datatypes. This specification shall be associated with a unique XML namespace name Namespaces in XML. The namespace name shall be the string value “http:/www.smpte-ra.org/schemas/430-7/2008/FLM”. This namespace name conveys both structural and semantic version information, but does no

41、t serve the purpose of a traditional version number field. Table 1 lists the XML namespace names used in this specification. Namespace names are represented as Uniform Resource Identifier (URI) values RFC 2396.1Table 1 XML Namespaces Qualifier URI dcml http:/www.smpte-ra.org/schemas/433/2008/dcmlTyp

42、es ds http:/www.w3.org/2000/09/xmldsig# etm http:/www.smpte-ra.org/schemas/430-3/2006/ETM flm http:/www.smpte-ra.org/schemas/430-7/2008/FLM xenc http:/www.w3.org/2001/04/xmlenc# xs http:/www.w3.org/2001/XMLSchema xsi http:/www.w3.org/2001/XMLSchema-instance The URIs found in Table 1 are normative. T

43、he namespace qualifier values (also called namespace prefixes in XML jargon) used in Table 1 and elsewhere in this document, namely “dcml”, “ds,” etm,” “flm,“ “xenc,” and “xsi“, are not normative. Specifically, they may be replaced in instance documents by any XML compliant namespace prefix. In othe

44、r words, implementations shall expect any arbitrary XML compliant namespace prefix value that is associated with a URI from Table 1. 5.3 XML Overview of the FLM (Informative) Note: See Appendix C for the normative XML schema that defines the FLM. The XML diagrams in this document conform to the lege

45、nd given in Section 9. An FLM is an ETM instance which has in the RequiredExtensions element a child element named FLMRequiredExtensions. The FLMRequiredExtensions element contains Digital Cinema Certificate information of secure devices within an exhibition facility complex, but does not carry or o

46、therwise expose secret private key information. Optionally, the element may also contain Forensic Mark information, and information about the device itself. 1Readers unfamiliar with URI values as XML namespace names should be aware that although a URI value begins with a “method” element (“http” in

47、this case), the value is designed primarily to be a unique string and does not necessarily correspond to an actual on-line resource. Applications implementing this standard should not attempt to resolve URI values on-line. SMPTE 430-7-2008 Page 8 of 23 pages Figure 3 D-Cinema Security Message The FL

48、M does not utilize the AuthenticatedPrivate portion of the ETM. However, the AuthenticatedPrivate ID attribute must be included. The Signature element defined in SMPTE 430-3 (ETM) carries the signers certificate chain and protects the integrity and authenticity of the AuthenticatedPublic portion. No

49、te: The Signature section ensures the authenticity of the message to the extent that the recipient has prior knowledge of the certificate of the sender. SMPTE 430-7-2008 Page 9 of 23 pages 6 Authenticated and Unencrypted Information The FLM extends the ETM by including the FLMRequiredExtensionType (see Figure 4 below) in its RequiredExtensions element. Figure 4 FLM Required Extensions Type The normative schema is defined in Annex C. The in