1、 ATIS-08000015.v002 CERTIFICATE TRUST HIERARCHY INTEROPERABILITY SPECIFICATION ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than
2、 200 companies actively formulate standards in ATIS 17 Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks. In additi
3、on, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generation Partnersh
4、ip Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (ANSI). For more in
5、formation, please visit . Notice of Disclaimer manufacturer 1 opts to deploy two sub-CAs, while manufacturer 2 opts to issue device certificates directly from the Manufacturer DEV CA. For a DEV CA (or a Manufacturer DEV CA) run by a trusted organization that is not a device manufacturer (see part B
6、of Figure 3), the DEV CA (or a Manufacturer DEV CA) subject field shall be formatted as described in section 3.2. For a Manufacturer DEV CA run by a manufacturer (see part A of Figure 3), the Manufacturer DEV CA subject field shall be formatted as described in section 3.2. ATIS-0800015.v002 15 For a
7、 Manufacturer DEV sub-CA issued by the Manufacturer DEV CA, the subject field shall be formatted as described in section 3.2. In all cases, the can simply be the name of the CA vendor or another name. 3.2.5 Management CA A Management CA may be used by a trusted organization to issue Management Certi
8、ficates for management functions and extend the Certificate Trust Hierarchy. A Management CA shall not sign and issue certificates for any type other than management purposes. In other words, a Management CA shall not sign and issue certificates belonging to any branches other than the Management br
9、anch. When issued, a Management CA certificate shall be signed by a Root CA and the subject field shall be formatted as described in section 3.2. The can simply be the name of the CA vendor or another name. 3.2.6 Operator OAM CA An Operator OAM CA (s) issues OAM Certificates for operations, administ
10、ration, and maintenance functions. This includes server-side devices that provide functionality, compliant with ATIS specifications as well as servers and/or network elements required for support of operations that are not specified directly in ATIS specifications. An Operator OAM CA may be a CA tha
11、t is controlled and maintained by an operator (Service Provider SP or Network Provider NP), or its agents, to issue certificates for servers that are directly under control of the operator. An Operator OAM CA may issue OAM Certificates to server devices that already possess manufacturer-issued Devic
12、e Certificates. Examples of OAM Certificates are certificates issued to servers implementing Device Authentication Functions or time servers. An Operator OAM CA shall not sign and issue certificates for any type other than OAM purposes (its own branch). When an Operator OAM CA certificate is issued,
13、 it shall be signed by a Root CA and the subject field shall be formatted as described in section 3.2. The can simply be the name of the CA vendor or another name. 3.2.7 OCSP responder certificates OSCP responder certificates are issued by the CA that is delegating the revocation status checking to
14、an OCSP responder; refer to ATIS-0800023 5 for details. The OCSP responder certificate shall have the ISS/CA profile as specified in ATIS-0800016 6. 3.2.7.1 Root Level OCSP Responder When an OCSP responder certificate is issued by the Root CA (as shown in Figure 2), the OCSP responder certificate su
15、bject shall be formatted as described in section 3.2 More than one OCSP responder can be provisioned for both scalability and trust/ business reasons. For large networks, the operator should consider the deployment of OSCP responders at lower levels of the Trust Hierarchy. The can simply be the name
16、 of the CA vendor or another name. ATIS-0800015.v002 16 3.2.7.2 CA Level OCSP Responder The OCSP responders under the Root CA may be sufficient for certificate status checking of CVC, MVC, and Management branches. It is possible, however, to allow the CVC, MVC, and Management CAs to sign OCSP respon
17、der certificates and run OCSP responders independent of the root. This allows for a more flexible trust and business model for a variety of server-side architectures. Figure 1 shows all the normative placements of OCSP responder certificates in the certificate hierarchy as small green boxes. When OC
18、SP responder certificates are to be issued, the naming (subject field) for such certificates shall follow the conventions described for CA-level OCSP responders in section 3.2. The shall be selected from the following list: CVC CA: Code-Signing CA. MVC CA: Message-Signing CA. DEV CA: Device CA. Manu
19、facturer DEV CA: Device Manufacturer CA. Management CA: Management CA. Operator OAM CA: OAM CA. 3.2.8 Code Verification Certificate When issued, a CVC shall be signed by the issuing CVC CA holding a valid CVC CA certificate. The holder of the CVC (code signer) shall use the private key corresponding
20、 to the CVC to directly sign software code images. The CVC subject field shall be formatted as described in section 3.2. A CVC contains certificate extensions described in ATIS-0800016 6. 3.2.9 MVC (Message Verification Certificate) When issued, a MVC shall be signed by the issuing MVC CA holding a
21、valid MVC CA certificate. The holder of a MVC shall use the private key corresponding to the MVC to directly sign authenticated messages sent to IPTV Devices. The MVC subject field shall be formatted as described in section 3.2. A MVC contains certificate extensions described in ATIS-0800016 6. 3.2.
22、10 Device Certificate A Manufacturer DEV CA can issue a Device Certificate for any device type listed in Table 3. The Device Certificate is used by an IPTV Device to present verifiable credentials to any requesting entity. The combination of issuer and certificate serialNumber uniquely identifies th
23、e certificate under the entire domain of the ATIS IIF Trust Hierarchy. The combination of issuer and subject uniquely identifies the device under the entire domain of the ATIS IIF Trust Hierarchy. See ATIS-0800024, Security Robustness Rules Interoperability Specification 7, for robustness rules for
24、key protection in IPTV Devices. The Device Certificate subject field shall be formatted as described in section 3.2. As mentioned in section 3.2, is the device identifier defined in ATIS-0800037 11. The field currently can have different values depending on the type of device to which a certificate
25、is issued. This is described further in section 3.2.10.2. ATIS-0800015.v002 17 The field can have a different value depending on the security profile of the device, if any. This is defined further in section 3.2.10.1. 3.2.10.1 ISS Security Profile The is the expression of the ISS Security Profile fo
26、r the associated device as described in ATIS-0800014 3. The ISS Security Profile is a means to classify security characteristics of a specific implementation of an IPTV Device. The OU containing this variable shall only be used in Device Certificates; however, its use is optional. If the OU is inclu
27、ded to identify the ISS Security Profile, the value of shall be as described in Table 2. Table 2: ISS Security Profile Values ISS Profile Sub-profile Value for ISS Profile 0 0 ISS Profile 1 1 ISS Profile 2 2 ISS Profile 3 3 ISS Profile 4 4 ISS Profile 3-0 3.0 ISS Profile 3-1 3.1 ISS Profile 3-2 3.2
28、ISS Profile 3-3 3.3 ISS Profile 4-0 4.0 ISS Profile 4-1 4.1 ISS Profile 4-2 4.2 ISS Profile 4-3 4.3 The absence of the OU containing shall signify that no assumption may be made regarding the ISS Security Profile from that Device Certificate. The issuing Certificate Authority shall only place the OU
29、 containing in certificates for devices that have been administratively verified to conform to the stated profile per ATIS-0800024 7. NOTE The process for achieving ISS Security Profile certification is not part of this document. 3.2.10.2 Device Types A DEV CA branch can be used to issue certificate
30、s to a variety of device types. A number of different device types have been identified. In order to provide a flexible and extensible mechanism to add new device types in the future without requiring revisions to this specification, a numbering scheme is specified, where an integer number as indica
31、ted in the table below shall be used as a value for variable within the field of Device Certificate OU to indicate what the type of the device is. ATIS-0800015.v002 18 Table 3: Device Types Distinguished within Device Certificate Device type Integer Value for Reserved for future IIF use 0 ITF 1 DNG
32、2 Srvr 3 SSE 4 DSE 5 Reserved for future IIF use 6-255 3.2.11 Management Certificate When issued, a Management Certificate shall be signed by the issuing Management CA. A Management Certificate may be used for certificate revocation processing and to extend the Certificate Trust Hierarchy in the IPT
33、V Receiving Device as described in ATIS-0800023 5. The Management Certificate subject field shall be formatted as described in section 3.2. 3.2.12 OAM Certificate An OAM Certificate may be issued to any servers and/or network elements that are part of an operators network. Examples are device authen
34、tication servers within network provider or service provider networks. When issued, an OAM Certificate shall be signed by the issuing Operator OAM CA. The OAM Certificate subject field shall be formatted as described in section 3.2. The use of as part of certificate subject field shall be consistent
35、 with the requirements for profiles to be used with IKEv2, IPsec, and Internet Security Association Key Management Protocol (ISAKMP) 10. The variable allows the operator of an Operator OAM CA to provide a distinction between different OAM equipment within the OAM Certificate. values are defined in s
36、ection 3.2.12.1. The following example describes one case of mutual authentication between an OAM server and an ITF. The Authentication, Authorization, Audit/Accounting (AAA) server certificates used as part of mutual authentication with devices would use an OAM Certificate with an with proper assoc
37、iation to the operator. On the other hand, the device authenticating to the AAA server would use a Device Certificate issued under the DEV CA branch. 3.2.12.1 OAM Types An Operator OAM CA branch can be used to issue certificates to a variety of OAM equipment. A number of different OAM server types a
38、re identified where a declaration of is required in the OAM Certificate. In order to provide a flexible and extensible mechanism to add new OAM server types in the future without requiring revisions to this specification, a numbering scheme is specified, where an integer number as indicated in the t
39、able below shall be used as a value for ATIS-0800015.v002 19 variable within the subfield of the OAM Certificate OU to indicate what type of OAM server is referenced. Table 4: OAM Types Distinguished within OAM Certificate OAM server type Integer Value for Reserved for future IIF use 0 AAA 1 RCMS 2
40、Time Servers 3 Reserved for future IIF use 4-255 4 REQUIREMENTS TO SPECIFICATION MAPPING This specification addresses, in whole or in part, the following requirements of ATIS-0800001, IPTV DRM Interoperability Requirements 8. NOTE: The words “shall“, “should”, “conditional mandatory” and “may” shall
41、 be understood as described in 8. IIF.DRM.General.1000 - The IPTV Security Solution shall support a method to authenticate IPTV Receiving Devices. IIF.DRM.General.1400 - The IPTV Security Solution shall support rights management that is independent of specific content formats or standards. IIF.DRM.G
42、eneral.1400-0100 - The IPTV solution shall provide a mechanism for secure delivery of entitlements to the IPTV Receiving Devices. IIF.DRM.General.1500 - The IPTV Security Solution shall support non-repudiation of subscriber ordering transactions. IIF.DRM.General.2000 - The IPTV security solution sha
43、ll support a mechanism to allow an IPTV Receiving Device DRM Component to authenticate the DRM Servers. IIF.DRM.General.2100-0200 - The IPTV security solution shall support a mechanism to allow for the authenticity of signaling messages. IIF.DRM.General.2100-0300 - The IPTV security solution shall s
44、upport a mechanism to allow for the integrity of signaling messages. IIF.DRM.General.2200 - The IPTV security solution shall provide a secure execution environment in the IPTV Receiving Device by supporting secure boot-loading and secure installs and updates of middleware and applications for the IP
45、TV Receiving Device DRM Component. IIF.DRM.General.2300 - The IPTV Security Solution shall support secure download and install of the DRM operating code to IPTV Receiving Devices. IIF.DRM.General.2400 -The IPTV security solution shall provide mechanisms to support secure accurate time on the IPTV Re
46、ceiving Device (for example, via synchronization with authenticated NTP servers). This is because several processes such as time-based viewing controls, billing transactions, non-repudiation, QoS measurements, etc., rely on the time being accurate in the IPTV Receiving Device. ATIS-0800015.v002 20 I
47、IF.DRM.Operator.0500 - The IPTV security solution shall provide a mechanism to allow the IPTV operator to securely retrieve the parameters (e.g., configuration, status) of an IPTV Receiving Device DRM Component. IIF.DRM.Operator.0600 - The IPTV security solution shall provide a mechanism to allow IP
48、TV operator to securely update the parameters (e.g., configuration) of IPTV Receiving Device DRM Components. IIF.DRM.Operator.0700 - The IPTV security solution shall provide a mechanism to allow the IPTV operator to securely load the IPTV Receiving Device DRM Component to the IPTV Receiving Devices.
49、 5 REFERENCES 1 EB Docket 04-296, First Report and Order and Further Notice of Proposed Rulemaking, Review of the Emergency Alert System, FCC 05-191, November 10, 2005.12 ATIS-0800010, Emergency Alert Provisioning Specifications, April 2008.23 ATIS-0800014v.002, Secure Download and Messaging Interoperability Specification, September 2009.24 ATIS-0800009, Remote Management of Devices in the Consumer Domain for IPTV Services, March 2008.25 ATIS-0800023, Managing the Trust Hierarchy Interoperability Specification, January 201
