1、 Table of Contents Page Foreword 2 Intellectual Property . 2 Introduction. 2 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 Thumbpr
2、int (DnQualifier) 7 5.3.2 Root Name (OrganizationName) 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 Verificati
3、on (Informative) 11 Annex A CommonName Role Descriptions (Informative) . 12 Annex B Design Features and Validation Context Considerations (Informative) . 14 Annex C Example D-Certificate (Informative) . 16 Bibliography (Informative) . 21 Page 1 of 21 pages Annex D: Example D-Certificate (Informative
4、)P An example D-Cinema Certificate is illustrated below in the form of an ASN.1 syntax dump of DER encoding. The example contains two columns, separated by : (colon) characters. The first column presents an offset into the certificate proper (after the two byte DER preamble), followed by the data va
5、lue at that offset . The second column shows the ASN.1 syntax element discovered at that offset. Syntax element hierarchical nesting is indicated byenclosing and (curly braces). 0000 447: SEQUENCE 0004 32F: SEQUENCE 0008 3: 0 000A 1: INTEGER 2 : 000D 1: INTEGER 25 0010 D: SEQUENCE 0012 9: OBJECT IDE
6、NTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5) : (PKCS #1) 001D 0: NULL : 001F 77: SEQUENCE 0021 15: SET 0023 13: SEQUENCE 0025 3: OBJECT IDENTIFIER organizationName (2 5 4 10) : (X.520 id-at (2 5 4) 002A C: PrintableString DC.Company.Com : : 0038 18: SET 003A 16: SEQUENCE 003C 3: OBJECT IDENT
7、IFIER organizationalUnitName (2 5 4 11) : (X.520 id-at (2 5 4) 0041 F: PrintableString CA.DC.Company.Com : : 0052 1D: SET 0054 1B: SEQUENCE SMPTE ST 430-2:2017 Revision of SMPTE 430-2-2006 SMPTE STANDARD D-Cinema Operations Digital Certificate Copyright 2017 by THE SOCIETY OF MOTION PICTURE AND TELE
8、VISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved January 12, 2017 SMPTE ST 430-2:2017 Page 2 of 21 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally recognized standards developing organization. Headquartered and incor
9、porated 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 Committees is open to all with
10、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 its Standards Operations Manual. SMPTE ST 430-2 was prepared by Technology Committee 2
11、1DC. Intellectual Property SMPTE draws attention to the fact that it is claimed that compliance with this Standard may involve the use of one or more patents or other intellectual property rights (collectively, “IPR“). The Society takes no position concerning the evidence, validity, or scope of this
12、 IPR. Each holder of claimed IPR has assured the Society that it is willing to License all IPR it owns, and any third party IPR it has the right to sublicense, that is essential to the implementation of this Standard to those (Members and non-Members alike) desiring to implement this Standard under
13、reasonable terms and conditions, demonstrably free of discrimination. Each holder of claimed IPR has filed a statement to such effect with SMPTE. Information may be obtained from the Director, Standards certificate validity dates in 2050 or later shall be encoded as GeneralizedTime (four digit years
14、). (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 public key appears in multiple certi
15、ficates, 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
16、 the issuers certificate and the serial number assigned by the issuers issuer. KeyUsage Shall be present in all certificates, including root certificates. For certificate signing certificates, only the KeyCertSign flag shall be true. For leaf certificates either or both of the DigitalSignature and K
17、eyEncipherment flags shall be true. Other flags may be true. BasicConstraint This field shall be present in all certificates. When present, the CA attribute shall be true only for certificate signing certificates. Otherwise the CA attribute shall be false, and the PathLenConstraint shall be absent (
18、or zero). See example in Section 6.2.5. 5.3 Naming and Roles This section defines the semantics of the attributes that appear in the Issuer name field and the Subject name field of certificates. SMPTE ST 430-2:2017 Page 7 of 21 pages Each entity that is the subject or issuer of acertificate is unamb
19、iguously identified by a number of attributes. In order to enable the mapping of these attributes into the X.509 name structure, this specification overloads the semantics of the X.509 name attributes, as summarized in Table 3. Overloading was chosen rather than defining new attribute types in order
20、 to facilitate implementation with widely available services and toolkits. Table 3 Mapping of Identity Attributes to X.509 Name Attributes Identity Attribute X.509 Name Attribute Description Public Key Thumbprint dnQualifier Unique thumbprint of the public key of the entity issuing the certificate o
21、r being issued the certificate. n/a CountryName This X.509 name attribute shall not appear in certificates conforming to this specification. Root Name OrganizationName Name of the organization holding the root of the certificate chain. Organization Name OrganizationUnitName Name of the organization
22、to which the issuer or subject of the certificate belongs. This field does not identify the end owner or facility; rather it identifies the device maker. Entity Name CommonName Entity issuing the certificate or being issued the certificate. See Entity Name and Roles section. 5.3.1 Public Key Thumbpr
23、int (DnQualifier) Exactly one instance of the DnQualifier attribute shall be present in the Subject name and the Issuer name. It is a Base64 PrintableString encoding of a Public Key Thumbprint described in Section 5.4. When the DnQualifier appears in the Subject name field, it is the thumbprint of t
24、he subject public key that appears in this certificate. When the DnQualifier appears in the Issuer name field, it is the thumbprint of the public key that is used to verify the signature on this certificate (i.e., the thumbprint of the public key that appears in the issuers certificate). This field
25、is included to solve various security problems that can arise in an architecture that supports multiple root certificates. 5.3.2 Root Name (OrganizationName) The specification in this document implies that there will be multiple roots of trust for naming entities. The OrganizationName identifies the
26、 entity that is responsible for the root of trust for this certificate. Exactly one instance of the OrganizationName attribute is required in the Subject name and the Issuer name. It shall be a PrintableString. It should be a meaningful (to humans) name of the organization that is providing the root
27、 of trust for all certificates in this chain. There may be multiple roots of trust. The OrganizationName in the Issuer field shall match the OrganizationName in the Subject field. This means that the OrganizationName shall be the same in all certificates that chain back to the same root. The Organiz
28、ationName attribute shall be unique. Vendors can choose their own value for this field as long as it does not match that of another vendor. The values of this field should be chosen to be sufficiently distinct that a human would not confuse two similar names. This name actually identifies the root o
29、f trust for the system that issues certificates, so it is more specific than the name of the organization that owns the issuing system. For example, a name like “DC.CA.BigBlue.Com” would be a better name than “BigBlue.Com”. This SMPTE ST 430-2:2017 Page 8 of 21 pages name might exist for a very long
30、 time, so a company that might be purchased by another company may wish to choose a neutral name to which they have intellectual property rights. 5.3.3 Organization Name (OrganizationUnitName) There shall be one instance of the OrganizationUnitName attribute in the Subject name and the Issuer name f
31、ields. It shall be a PrintableString. Security devices do not perform any checks on this attribute, and OrganizationUnitName is ignored by the certificate validation and chaining rules. It is intended for the benefit of humans and may appear in log records. The OrganizationUnitName that appears in t
32、he Subject name field is the name of the organization to which the certificate has been issued and supplements the vendor information found in the CommonName attribute. The OrganizationUnitName that appears in the Issuer name field is name of the organization that issued the certificate. 5.3.4 Entit
33、y Name and Roles (CommonName) Exactly one instance of this attribute shall appear in the Subject name and the Issuer name fields. It shall be a PrintableString. It expresses the role(s) performed by the entity and expresses the physical identification of the entity (make, model, and serial number fo
34、r devices). The CommonName attribute is structured to express the authorized roles of the entity and a description of the entity (see Annex A). The value of this field has two parts separated by the leftmost period (“.”) character. The first part is a list of words (that only contain the 52 upper an
35、d lowercase letters) separated by single space characters. Each word indicates a role (see Annex A roles encoding table). The second part is a unique label for the entity. The Role shall be present in all leaf (end-entity i.e., exhibition security device) certificates. When the role is omitted, a pe
36、riod character shall be the first character of the CommonName. 5.4 Certificate and Public Key Thumbprint The Public Key Thumbprint is a statistically unique identifier of a public key, and thus also an identifier of the matching private key. A Public Key Thumbprint shall be the SHA-1 hash (see FIPS-
37、180-2) of the contents of the SubjectPublicKey BIT STRING in the SubjectPublicKeyInfo field (excluding the DER tag, length, and number of unused bits count in the DER header for the BIT STRING). For details on computing this value see RFC3280 Section 4.2.1.2 option 1. For using the DnQualifier attri
38、bute in certificate names, the Public Key Thumbprint may be Base64 encoded (see Base64) to create a printable representation. The Certificate Thumbprint is a computed value that is the SHA-1 hash of the To-Be-Signed portion of the certificate excluding the DER encoding tag and length. The Certificat
39、e Thumbprint may be Base64 encoded (see Base64) to create a printable representation. Informative Note: Certificate thumbprints are not subject to the SHA-1 collision risks that require SHA-256 in other Digital Certificate hash operations. 6 Certificate Processing Rules This section describes the ru
40、les for validating certificates and chains of certificates. Some security devices may choose to not perform chain validation in cases where the device does not have a list of trusted roots for the intended purpose. In these cases, the device may wish to remember the certificate thumbprint as a means
41、 of recognizing when it is speaking to the same entity. SMPTE ST 430-2:2017 Page 9 of 21 pages Some security devices may not have a clock, and may choose to skip the validity time check on the leaf certificate in the chain. 6.1 Validation Context Certificates are always validated in a context. The c
42、ontext consists of the following components, any of which may be empty except for the first, which shall be present: a) A chain containing the certificate being validated b) A minimum chain length (number of certificates) c) A desired role d) An effective time (i.e. time and date) e) A set of truste
43、d certificates f) A set of revoked certificate identifiers (issuerName-serialNumber pairs) g) A set of revoked public key values The context is used in the validation algorithm as specified in Section 6.2 below. This table summarizes the context-dependent algorithm steps: Context element Algorithm s
44、teps a) Cert chain 16,17,18,19 b) Chain length 16 c) Desired role 8 d) Effective time 9 e) Set of trusted root certs 19 f) Set of revoked certs 12 g) Set of revoked keys 12 Informative Note: The actual values of the context, and whether each particular context component is required, optional, or pro
45、hibited, are dependent on the specific application in which the certificate is being validated. Such application specifications are outside the scope of this document. Refer to informative Annex A regarding application considerations for validation context. 6.2 Validation Rules To validate a certifi
46、cate chain, the entity shall perform at least the following steps. These steps do not need to be performed in this order. Additional checks on the behavior of certificate issuing systems are not required for the entity (e.g., ensuring that the serial number is an unsigned integer value that is 64-bi
47、ts in length or less, or ensuring that the validity dates are properly encoded, or ensuring that the sequence numbers are unique). However, a certificate issuing system might not be trusted unless it performs these checks itself. 1. Parse the certificate with the ASN.1 DER decoding rules and reject
48、the certificate if there are syntax errors or it is not DER encoded. This avoids the need to re-code certificates that were received in BER format in order to verify the signature. 2. If the version field is not X.509v3, reject it. 3. If any unrecognized extensions in the certificate are marked Crit
49、ical, reject it. 4. If any required fields are missing, reject it. SMPTE ST 430-2:2017 Page 10 of 21 pages 5. If the CA attribute of the BasicConstraint field is True, check that the PathLenConstraint value is present and either zero or positive. This disallows certificate chains of unbounded length. If the CA attribute of the BasicConstraint field is False, check that th
