SMPTE ST 430-2-2006 D-Cinema Operations Digital Certificate.pdf

《SMPTE ST 430-2-2006 D-Cinema Operations Digital Certificate.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 430-2-2006 D-Cinema Operations Digital Certificate.pdf（21页珍藏版）》请在麦多课文档分享上搜索。

1、 Table of Contents Page 1 Scope 3 2 Normative References 3 3 Glossary 3 4 Overview of Digital Certificates (Informative) 4 5 Certificate Fields . 5 5.1 Required Fields. 5 5.2 Field Constraints. 6 5.3 Naming and Roles 6 5.3.1 Public Key Thumbprint (DnQualifier) . 7 5.3.2 Root Name (OrganizationName)

2、. 7 5.3.3 Organization Name (OrganizationUnitName) 8 5.3.4 Entity Name and Roles (CommonName) 8 5.4 Certificate and Public Key Thumbprint . 8 6 Certificate Processing Rules. 8 6.1 Validation Context. 9 6.2 Validation Rules 9 6.3 Human Verification (Informative) 11 Annex A CommonName Role Description

3、s (Informative). 12 Annex B Design Features and Validation Context Considerations (Informative) . 14 Annex C Bibliography (Informative) 16 Annex D Example D-Certificate (Informative). 17 Page 1 of 21 pages SMPTE 430-2-2006 SMPTE STANDARD D-Cinema Operations Digital Certificate Copyright 2006 by THE

4、SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved October 3, 2006 SMPTE 430-2-2006 Page 2 of 21 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally recognized standards developing organiz

5、ation. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these C

6、ommittees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its Administrative Practices. SMPTE Standar

7、d 430-2 was prepared by Technology Committee DC28. Introduction This standard presents a specification for Digital Certificates used in a D-Cinema system. These certificates are used to help secure communications both within an exhibition facility and between business entities (Studios, Distributors

8、 and Exhibitors). This standard defines the Digital Certificate format and associated processing rules in sufficient detail to enable vendors to develop and rollout interoperable security solutions for D-Cinema. This Digital Certificate standard is based on a constrained form of the X.509v3 format a

9、nd processing rules. X.509v3 certificates have been widely used in other well-respected security standards such as SSL/TLS secure internet access, IPSec Virtual Private Networks and S/MIME secure email. The specific constraints on the X.509v3 format are chosen to reduce the amount of time and implem

10、entation effort required to achieve interoperability with high security and yet provide a robust flexible foundation that can support future enhancements. These certificates support a simple yet flexible trust model without having to introduce new business entities. Specifically, there is no need to

11、 create an industry wide certification lab, though one could be supported. These certificates are used in several D-Cinema standards. They are used to provide authenticity and integrity for Composition Play Lists CPL and Packing Lists PL. They provide authenticity, integrity and confidentiality in E

12、xtra-Theatre Messages ETM such as the Key Delivery Message KDM, and they are used with the TLS session security protocol to protect Intra-Theater Messages. NOTE The brackets convention “” as used herein denotes either a normative or informative reference. SMPTE 430-2-2006 Page 3 of 21 pages 1 Scope

13、This standard presents a specification for Digital Certificates for use in D-Cinema systems. The standard defines the Digital Certificate format and associated processing rules in sufficient detail to enable vendors to develop and implement interoperable security solutions. In the D-Cinema environme

14、nt, certificates have these primary applications: Establishing identity of security devices Supporting secure communications at the network layer (e.g. TLS) or application-messaging layer (e.g., Extra Theater Messages ETM) Authentication and integrity requirements for Composition Play Lists (CPL) an

15、d Packing Lists (PL) The Digital Certificate standard is based on a constrained form of the X.509v3 X.509 format and processing rules. Only the most widely supported features of X.509v3 are used in order to give vendors a large selection of X.509v3 development toolkits and certificate issuing produc

16、ts. The constraints also avoid the complexity and ambiguity that often occurs in systems that use X.509v3 certificates. 2 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of publication, the edi

17、tions indicated were valid. All standards are subject to revision, 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. ASN.1 ISO/IEC 8824-1:2002 (ITU-T X.680, Information Technology) - Ab

18、stract Syntax Notation One (ASN.1). See: http:/www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=35684 Base64 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. See: http:/www.ietf.org/rfc/rfc1521.txt F

19、IPS-180-2 “Secure Hash Standard” Version 2. August 1, 2002. FIPS-180-2. http:/csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf PKCS1 “PKCS #1: RSA Encryption Version 2.1” By B. Kaliski. February 2003. IETF RFC 3447 See: http:/www.ietf.org/rfc/rfc3447.txt RFC4055 “Additional Algorithms and Ide

20、ntifiers for RSA Cryptography for Use in the Internet X.509 Public Key Infrastructure” by J. Schaad, B. Kaliski, R. Housley, June 2005. See: http:/www.ietf.org/rfc/rfc4055.txt RFC3280 “Internet X.509 Public Key Infrastructure Certificate and CRL Profile” by R. Housley, W. Ford, W. Polk, D. Solo, Apr

21、il 2002. See: http:/www.ietf.org/rfc/rfc3280.txt Time UTC, RFC 3339: Date and Time on the Internet: Timestamps. G. Klyne and C. Newman. Informational, July 2002. See: http:/ietf.org/rfc/rfc3339.txt X.509 ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection The D

22、irectory: Authentication Framework, June 1997. See: http:/www.itu.int/ITU-T/asn1/database/itu-t/x/x509/1997/ 3 Glossary The following paragraphs define the acronyms used in this standard. SMPTE 430-2-2006 Page 4 of 21 pages ASN.1: Abstract Syntax Notation 1. BER: Basic Encoding Rules for ASN.1 struc

23、tures. There are multiple BER encodings for a given value. Base64: A printable encoding of binary data. Defined in Base64. CA: Certificate (issuing) Authority DC: Digital Cinema. DER: Distinguished Encoding Rules for ASN.1 structures. These rules create a canonical representation. ETM: Extra Theatre

24、 Message. FIPS: Federal Information Processing Standards of NIST. IETF: Internet Engineering Task Force standards group. IP: Internet Protocol. An IETF standard. ISO: International Standards Organization. LE: Link Encryptor. LD: Link Decryptor. MD: Media Decryptor. NIST: National Institute of Standa

25、rds and Technologies. RO: Rights Owner. RSA: Rivest Shamir Adleman public key algorithm. SE: Security Entity. Any Digital Cinema entity that performs cryptography. SHA-1: Secure Hash Algorithm revision 1. See FIPS-180-2. SHA-256: Secure Hash Algorithm. See FIPS-180-2. SM: Security Manager. S/MIME: S

26、ecure Multipurpose Internet Mail Extensions. SPB: Secure Processing Block. SSL: Secure Socket Layer protocol. See TLS. TCP: Transmission Control Protocol. IETF standard for reliable bi-directional streams. TLS: Transport Layer Security protocol. See Rescorla. TMS: Theatre Management System. X.509: A

27、 widely used and supported digital certificate standard. XML: Extensible Mark-up Language. 4 Overview of Digital Certificates (Informative) Digital certificates provide a way for a D-Cinema device to start with a small amount of trustworthy information and use that to verify the trustworthiness of a

28、dditional information. Certificates also support the privacy, integrity and authenticity of communications. The certificate for a security device is a statement signed by the vendor of the device saying “If you speak to an entity that can prove that it has current access to the private key that matc

29、hes the public key in this certificate, then I, the vendor of the device, state that the entity has the following attributes.” The body of the certificate lists attributes such as the make, model and serial number of the device, and the D-Cinema roles supported by the device. For reasons of scaling

30、and security, equipment vendors need not directly sign the certificates of devices. Instead there may be one or more intermediate certificates in a chain. The vendors primary certificate is the “root” of this chain (called the root certificate), and the devices certificate is the “leaf-end” of the c

31、hain. The SMPTE 430-2-2006 Page 5 of 21 pages public key in the vendors root certificate (which is self-signed) may be used to verify the attributes in an intermediate certificate. Those attributes include the public key of the intermediate Certificate issuing Authority (CA), which is then used to v

32、erify the next certificate in the chain, and so forth. Eventually, the public key from the last CA certificate in the chain is used to verify the devices certificate, and thus establish the trustworthiness of the attributes in the certificate (including the devices public key). Devices that perform

33、certificate chain validation assume that the vendor has established good policies and procedures for securely operating the CAs in the chain, which should make it unlikely that an attacker will be able to create fraudulent certificates. The name of the organization that owns the root certificate app

34、ears in all the certificates in the chain and this serves as an indication of the quality of the policies and procedures. 5 Certificate Fields D-Cinema certificates shall use the standard X.509 (version 3) (see X.509) format in constrained ways defined in this standard in order to reduce the complex

35、ity and ambiguity that often occurs in systems that used X.509 certificates. This section defines those constraints. 5.1 Required Fields This section specifies the required fields in D-Cinema certificates. The following table summarizes the required fields. Table 1 describes the detailed constraints

36、 for each field. The certificate shall be encoded (converted to bytes) using the ASN.1 DER rules (see ASN.1, Kaliski), which produce a unique representation for the certificate. Table 1 Required X.509v3 fields for Digital Cinema Certificates Field Description The first two fields shall appear outsid

37、e of the signed portion of the certificate. SignatureAlgorithm Identifier of the algorithm used to sign this certificate. Must be same as signature field inside the certificate. SignatureValue Value of the signature for the certificate. The following fields are inside the signed portion of the certi

38、ficate. The fields after the SubjectPublicKeyInfo field shall appear in the “extensions” part of the signed portion. Version Indicates X.509 Version 3 format certificates. SerialNumber Serial number of certificate that is uniquely chosen by the Issuer. Signature Identifier of the signature algorithm

39、. It appears inside the signed portion of the certificate and must match the algorithm identified on the outside in the SignatureAlgorithm field. Issuer Name of entity that issued and signed this certificate. Subject Name of the entity that is the subject of this certificate and thus controls access

40、 to the private key that corresponds to the public key that appears in this certificate. Validity Date/Time range when the certificate is valid. SubjectPublicKeyInfo Information about the subjects public key including the algorithm type, any algorithm parameters and the set of values that makes up t

41、he public key, such as modulus and public exponent for RSA. AuthorityKeyIdentifier This field identifies the issuers certificate. KeyUsage Collection of flag bits that identify all the operations that are authorized to be performed with the public key in this certificate, and thus imply what can be

42、done with the corresponding private key. BasicConstraint This field indicates whether certificate signing is allowed and specifies the maximum number of certificate signing certificates that can appear in the chain below this one. SMPTE 430-2-2006 Page 6 of 21 pages D-Cinema certificates may contain

43、 other extension fields that are meaningful to equipment from specific vendors. All implementations shall ignore extensions (i.e. fields other than the above specified required fields) that they do not understand. 5.2 Field Constraints Table 2 describes the constraints on the required fields. Table

44、2 Field Constraints for Digital Cinema Certificates X.509 Field Description SignatureAlgorithm Shall be sha256WithRSAEncryption, which is the algorithm identifier for encrypting a SHA-256 (see FIPS-180-2) digest of the certificate body with RSA using PKCS #1 v1.5 signature padding (see PKCS1). Signa

45、tureValue This field is an ASN.1 Bit String that contains a PKCS #1 signature block. It shall contain a SHA-256WithRSA signature (see RFC4055). Version Shall indicate X.509 Version 3 format certificates. SerialNumber Unique number assigned by Issuer. Shall be an unsigned integer value that is 64-bit

46、s in length or less. Signature Shall be sha-256WithRSAEncryption algorithm identifier. Issuer Globally unique name of entity that issued and signed this certificate. See section on Naming and Roles, for further constraints. Subject Globally unique name of the entity that controls access to the priva

47、te key that corresponds to the public key of this certificate. See section on Naming and Roles, for further constraints. Validity The issuer shall always encode certificate validity dates through the year 2049 as UTCTime (two digit years); certificate validity dates in 2050 or later shall be encoded

48、 as GeneralizedTime (four digit years). (Time) SubjectPublicKeyInfo This shall describe an RSA public key. The RSA public modulus shall be 2048-bits long. The public exponent shall be 65537. The same public key may appear in multiple certificates. Certificate issuers should try to ensure that when a

49、 public key appears in multiple certificates, those certificates correspond to the same entity or device. AuthorityKeyIdentifier AuthorityCertIssuer AuthorityCertSerialNumber Shall be present in all certificates, including root certificates. These attributes are the unique identifier for the issuers certificate. They name the issuer of the issuers certificate and the serial number assigned by the issuers issuer. KeyUsage Shall be present in all certificates, including root cert