pkix Zhou, Ed. Internet-Draft Huawei Technologies, Inc. Intended status: Standards Track Chen Expires: August 30, 2010 China Telecom Feb 26, 2010 PKI Proxy Architecture draft-zhipeng-pkix-drm-proxy-architecture-02 Abstract This document specifies a method and its architecture for proxy application based on the PKI environment with X.509 certificate [X.509]. As a typical application, this method can be used on DRM service regardless the specific DRM standard which is implemented on the interface between the Client Device and Service Server. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Zhou & Chen Expires August 30, 2010 [Page 1] Internet-Draft PKI Proxy Architecture Feb 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture for Proxy Service . . . . . . . . . . . . . . . . 4 4. Trust Architecture for Proxy service . . . . . . . . . . . . . 5 5. Format of Authorization Document . . . . . . . . . . . . . . . 7 5.1. Authorization Document based on OMA DRM2.1 . . . . . . . . 7 6. Initiation and Update of Authorization . . . . . . . . . . . . 10 7. Application Example . . . . . . . . . . . . . . . . . . . . . 13 8. Extended Architecture . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 12. Normative References . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Zhou & Chen Expires August 30, 2010 [Page 2] Internet-Draft PKI Proxy Architecture Feb 2010 1. Introduction In the PKI applications, there exist many requirements on establishing and verifying the trust relationship among multiple entities. For example, in the proxy services there exist the requirement for maintaining the trust relationship among the server, the client and the proxy entity. This kind of trust chain exists in many industries, for example in bank services there exists the broker as the proxy of the client for the bank services. As a typical PKI application, the DRM(Digital Rights Management) service currently has been well developed on the service protocol, so in this document, the full solution of proxy trust relationship on the DRM service based on the OMA DRM2.1 is taken as an instance for the implementation of the Trust Architecture for proxy Service. This document has specified a method and its architecture to fulfill that a device can apply for the DRM service or content on behalf of another device. Below list two typical situations when an application MAY use this proxy method : - In home network, the home server or home gateway can manage the home devices and subscribe services for these home devices and only the home server or home gateway has the right to subscribe services. Thus, the home devices can only access service under the permission of the home server or home gateway. - In business environment, the device with higher grade can control the access rights of the devices with lower grade. So the lower grade device can only access some special services or some secret content through a server when it holds the authorization of a device with higher grade. To verify the service subscription or service acquisition, the Service Provider (Service Server) SHOULD verify the trusted relationship between the request device and the proxy device. Based on PKI technology, it is available to conduct such verification to support such proxy service under the PKI environment with X.509 certification. Generally, in order to set up the trusted relationship with proxy device, the request device SHALL create an authorization document with its digital signature to authorize the proxy device of proxy responsibilities. The authorization document SHALL contain the detail service information that the proxy device can subscribe for the request device. After receiving the authorization document, the Zhou & Chen Expires August 30, 2010 [Page 3] Internet-Draft PKI Proxy Architecture Feb 2010 proxy device can follow the authorization to take the service operation for the request device. Meanwhile the authorization between the request device and the proxy device SHALL be delivered to the Service Server. Thus the Service Server will only send or issue the service response which is compliant to the authorization to the proxy device. Finally, the service response will be transferred to the request device by the proxy device. Under this proxy method and architecture, the proxy device on one hand can manage the service subscription of the request device, and on the other hand can take on most communication tasks with the Service Server to reduce the burden of request device. As for the DRM implementation, two issues SHOULD depend on the specific application: The first issue is "types of DRM service". This document does not define the types of DRM service while section 5.1 gives the definition of Authorization Document based on the services defined in OMA DRM specification [OMA DRM2.1 TS] such as "RO Acquisition" and "Join Domain" are referred as an example. The second issue is "message of DRM service". This document will not define the message of DRM service either. It can depend on the DRM specification. The method defined in this document can be used for any DRM devices if they support PKI and X.509 certificate. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Architecture for Proxy Service The general service architecture for the proxy application is listed as Figure 1: +----------+ Request +----------+ Proxy Request +----------+ | Request | -----------> | Proxy | ---------------->| Service | | Device A |<----------- | Device B |<---------------- | Server | +----------+ Response +----------+ Proxy Response +----------+ Figure 1. Architecture for Proxy Service Zhou & Chen Expires August 30, 2010 [Page 4] Internet-Draft PKI Proxy Architecture Feb 2010 On the request flow, the Request Device A creates the " Request" and sends it to the Proxy Device B. After verifying over the request successfully, the Proxy Device B creates and sends the "Proxy Request" to Service Server to apply for service for the Request Device A. The "Proxy Request" can contain the whole "Request" as an element or contain relative elements picked up from the "Request". Similarly, on the response flow, the Service Server sends the "Proxy Response" upon the "Proxy Request" to the Proxy Device B. Then the Proxy Device B creates the "Response" on the basis of the "Proxy Response" and sends the "Response" to the Request Device A. In general third party proxy services, such kind of interactive flow is rather usual. While for secure application such as DRM application, the key issue is to build up and to effectively deliver the trust mechanism since the Service Server SHOULD control the risk from all the devices that could access the service or content. The solution defined in this document to deliver the trust mechanism is that the Request Device A sets up trusted authorization with the Proxy Device B and authorizes the Proxy Device B with the proxy rights to take service operations with the Service Server for the Request Device A. After the Proxy Device B completes the service session with the Service Server, it will send the response that corresponds to the trusted authorization back to the Request Device A. The mechanism to set up trusted relationship is fully elaborated in the following section 4. The message formats of "Request" and "Response" in the Figure 1 depends on the specific applications. As for the DRM application, the "Request" and "Response" will be the "DRM Request" and "DRM Response". Similarly, the "Proxy Request" and "Proxy Response" will be the "Proxy DRM Request" and "Proxy DRM Response". See the following Figure 2. +----------+ DRM Request +----------+ Proxy DRM Request +----------+ | Request | -----------> | Proxy | ------------------>| Service | | Device A |<----------- | Device B |<------------------ | Server | +----------+ DRM Response +----------+ Proxy DRM Response +----------+ Figure 2. Architecture for Proxy DRM Service 4. Trust Architecture for Proxy service In bi-entity architecture, based on PKI environment, the trust verification is conducted via verifying the Certificate Chain of each other between the two entities of the service. So, to fulfill the trust verification among the three entities within the proxy service, a method is given that the Request Device creates an authorization to Zhou & Chen Expires August 30, 2010 [Page 5] Internet-Draft PKI Proxy Architecture Feb 2010 enumerate what right the Proxy Device can hold to subscribe the service for the Request Device A. The Trust Architecture is shown as Figure 3: Certificate A Certificate A + Certificate B + + +----------+ Authorization +----------+ Authorization +----------+ | Request | ------------->| Proxy | -----------------> | Service | | Device A |<------------- | Device B |<----------------- | Server | +----------+ Response +----------+ Proxy Response +----------+ Figure 3. Trust Architecture for proxy Service The Authorization can be contained in a document. The Authorization Document is sent to Proxy Device B as well as the Certificate Chain of Request Device A. The Proxy Device B verifies the secure status of Request Device A by checking certificate revocation list (CRL) [RFC5280] for the Certificate A. If successfully, then verifies the Authorization Document using the public Key of Request Device A that is enclosed in the Certificate A, including verifying the signature and the proxy rights enclosed in the Authorization Document. If all the verifications are correct, the Proxy Device B parses each element in the Authorization document to be aware of the proxy rights that are authorized by the Request Device A and confirms that the trusted relationship has been set up successfully. In the proxy service, the Authorization Document as well as the certificates of both Request Device A and Proxy Device B SHALL also be delivered to Service Server. Upon receiving the two Certificates and the Authorization Document, Service Server SHALL verify the secure statuses of both Request Device A and Proxy Device B by checking CRL for their certificates. If both devices are in secure status, then verifies the Authorization Document using the public Key of Request Device A that is enclosed in the Certificate A. Once the verification of the Authorization Document is successful, the Service Server will catch the rights that are authorized to Proxy Device B by Request Device A via parsing the elements in the Authorization document. For example in DRM service, if the Authorization Document only contains the rights of 2-pass RO Acquisition, the Proxy Device can subscribe the ROs for the Request Device via the 2-pass RO Acquisition protocol defined in OMA DRM2.1 and can not subscribe for the Request Device for joining a Domain. After all the operations above have been finished, the trusted relationship has been set up successfully for the proxy service. Thus, the Proxy Device B can only execute the proxy service operation under the authorization by the Request Device A. At the same time the Service Server will only issue the permitted service to the Request Zhou & Chen Expires August 30, 2010 [Page 6] Internet-Draft PKI Proxy Architecture Feb 2010 Device A via the Proxy Device B according to the Proxy Request (For service flow, please refer to section 3). 5. Format of Authorization Document The Authorization Document is composed of: -- name of Request Device -- CertId of Request Device -- name of Proxy Device -- CertId of Proxy Device -- authorized service rights -- extensions -- signature algorithm -- signature The signature is computed across hash of the Authorization Document except the signature itself. As for the "authorized service rights", it MUST depend on the real application, for example the DRM service SHOULD be based on a specific DRM specification. As following, this document gives the definition of proxy rights based on [OMA DRM2.1 TS] for the OMA DRM service that can be referenced by other kind of services. 5.1. Authorization Document based on OMA DRM2.1 This sub-section provides a structure of Authorization Document. In this instance, the service types or service authorization are based on the OMA DRM2.1 specification (For details, please refer to [OMA DRM2.1 TS] ). Defined in the specification of OMA DRM2.1, the service operations include "2-pass RO Acquisition","4-pass Confirmed RO Acquisition", "1-pass RO Acquisition","3-pass Confirmed RO Acquisition","2-pass Join Domain", "2-pass Leave Domain", "2-pass Metering Report" and "2-pass RO Upload". The data structure for the Authorization Document is described as follows: AuthorizationDocument() { DeviceId() // The id of Request Device A CertId() // The key information of certificate A DeviceId() // The id of Proxy Device B CertId() // The key information of certificate B AuthorizedRights() //proxy rights authorized to Proxy Device B ExpireDate() //The deadline of validity, UTC time Zhou & Chen Expires August 30, 2010 [Page 7] Internet-Draft PKI Proxy Architecture Feb 2010 SerialNumber 32 uimsbf SignatureAlgorithm() //Refer to X.509 Signature() } DeviceId() { Hash() } CertId() { hashAlgorithmId 8 uimsbf //AlgorithmIdentifier issuerNameHash() //Hash of Issuer's name issuerKeyHash() //Hash of Issuer's public key serialNumber 32 uimsbf //CertificateSerialNumber } The "hashAlgorithmId" is used to indicate the hash Algorithm. Following is the definitions of "hashAlgorithmId" in this document. +----------------------------------------+ | hash Algorithm | value | +---------------------+------------------+ | SHA-1 | 0 | +---------------------+------------------+ | rfu | 1~255 | +---------------------+------------------+ issuerNameHash(){ Hash() } issuerKeyHash(){ Hash() } Hash(){ // Hash Value, the Hash algorithm refers to [SHA-1] OctetString8() } AuthorizedRights(){ // The following service rights in proxy service are defined: // 0 2-pass RO Acquisition // 1 4-pass Confirmed RO Acquisition // 2 1-pass RO Acquisition // 3 3-pass Confirmed RO Acquisition // 4 2-pass Join Domain // 5 2-pass Leave Domain // 6 2-pass Metering Report Zhou & Chen Expires August 30, 2010 [Page 8] Internet-Draft PKI Proxy Architecture Feb 2010 // 7 2-pass RO Upload //at most contain eight kinds of authorized right as listed above for( i = 0; i < RightsNub; i++ ){ ProxyRightsId 8 uimsbf } for( i = 0; i < RightsNub; i++ ){ SuspendedRightsId 8 uimsbf } for( i = 0; i < AuthorizationDocumentNub; i++ ){ //Serial Number of the Authorization Document to be suspended SuspendedAuthorizationNumber 32 uimsbf } } ExpireDate(){ // Deadline of Validity OctetString8() } Signature(){ // Signature Value OctetString8() } OctetString8(){ length 8 uimsbf for( i = 0; i < length; i++ ){ octet 8 uimsbf } } The fields are defined as follows: .length - Length of the octet string .octet - A byte The Authorization Document contains the essential information for other entities to verify the authorization of the Request Device to the Proxy Device. Following is the detailed description: DeviceId: In OMA DRM 2.1, is defined as the hash of the Device's public key info. Here that definition is followed and the hash algorithm is SHA-1 that is set as default hash algorithm in OMA DRM 2.1. CertId: The essential information of the device's Public Key Zhou & Chen Expires August 30, 2010 [Page 9] Internet-Draft PKI Proxy Architecture Feb 2010 Certificate, including hashAlgorithmId, issuerNameHash, issuerKeyHash, and serialNumber. AuthorizedRights: It contains three parts: ProxyRightsId, SuspendedRightsId and SuspendedAuthorizationNumber. The ProxyRightsId indicates the right that the Request Device has authorized to the Proxy Device to subscribe a specific service. This document supports the services defined in OMA DRM2.1, including 2-pass RO Acquisition, 4-pass Confirmed RO Acquisition, 1-pass RO Acquisition, 3-pass Confirmed RO Acquisition, 2-pass Join Domain, 2-pass Leave Domain, 2-pass Metering Report and 2-pass RO Upload. To support suspending a proxy right, the SuspendedRightsId is used to indicate which right is suspended (refer to the section of "Update of Authorization").The SuspendedAuthorizationNumber indicates the suspended Authorization Document by its serial number. ExpireDate: For security concern, the Authorization Document contains an "ExpireDate" element. Once that date exceeds the ExpireDate, the authorization turns invalid immediately. SerialNumber: the serial number of the Authorization Document. The Request Device SHALL assign each Authorization Document a unique serial number. Signature and SignatureAlgorithm: The Authorization Document contains the digital signature over the other part of the Authorization Document except the Signature itself under the request Device's private device key. The SignatureAlgorithm indicates the Algorithm for creating the digital signature. 6. Initiation and Update of Authorization The procedure of initiating or updating the Authorization can be an independent service flow. The Request Device will get a response for its request of Authorization Initiation or Authorization Update. Once the authorization is expired, the trusted relationship between the Request Device and the Proxy Device will not exist any more. The Request Device needs to initiate a new Authorization. And during the valid duration, the authorization can also be updated. For example, the Request Device wants to authorize the Proxy Device some more rights, it can either suspend the original Authorization Document and then create a new Authorization Document or just create another Authorization Document containing the additional authorized rights. Hence the Proxy Device can conduct all the proxy rights up to date. If the Request Device wishes to suspend the whole or part of the Zhou & Chen Expires August 30, 2010 [Page 10] Internet-Draft PKI Proxy Architecture Feb 2010 existing authorization, it can create an Authorization Document to the Proxy Device to indicate which Authorization Document or which proxy right SHOULD be suspended on the base that the Proxy Device is fully trusted by the Request Device. If to guarantee a higher security, the Request Device can take a measure to inform the Service Server that the trusted relationship to the Proxy Device or some a proxy right is suspended. On the other side, in the real application, the Proxy Device can also suspend part or whole of the trusted relationship. Thus the Proxy Device will not apply for the suspended service for the Request Device any more. The procedure of Authorization Initiation & Update is shown in Figure 4 below. Zhou & Chen Expires August 30, 2010 [Page 11] Internet-Draft PKI Proxy Architecture Feb 2010 Authorization Proxy Authorization +----------+ Request +----------+ Request +---------+ | Request | ------------->| Proxy | ------------------->| Service | | Device A |<------------- | Device B |<------------------- | Server | +----------+ Authorization +----------+ Proxy Authorization +---------+ Response Response Figure 4. Procedure of Authorization Initiation & Update The message formats are defined as follow: AuthorizationRequest() { AuthorizationDocument(); Certificate A; } AuthorizationResponse() { Status; } ProxyAuthorizationRequest() { AuthorizationDocument(); Certificate A; Certificate B; } ProxyAuthorizationResponse() { Status; } The possible status value of AuthorizationResponse and ProxyAuthorizationResponse are defined as below: +---------------------------------------------+ | status | value | +--------------------------+------------------+ | SUCCESS | 0 | +--------------------------+------------------+ | Certificate A invalid | 1 | +--------------------------+------------------+ | Certificate B invalid | 2 | +--------------------------+------------------+ | Certificate A&B invalid | 3 | +--------------------------+------------------+ | Authorization invalid | 4 | +--------------------------+------------------+ | rfu | 5~255 | +--------------------------+------------------+ In the Authorization Request, the certificate of Request Device Zhou & Chen Expires August 30, 2010 [Page 12] Internet-Draft PKI Proxy Architecture Feb 2010 A(certificate A) and the Authorization Document are contained. If the certificate A and Authorization Document are verified successfully by the Proxy Device B, and the Proxy Device B has accepted the Authorization request, then the Proxy Device B will send the Proxy Authorization Request to the Service Server, else return the Authorization Response with the status value indicating the failure reason. The Proxy Authorization Request contains the certificates of both Request Device A and Proxy Device B(certificate A and certificate B) and the Authorization Document. If the information in the Proxy Authorization Request is verified successfully and Service Server has accepted the Proxy Authorization Request, the Proxy Authorization Response will contain the status value of 'SUCCESS', else contain the status value according to the failure reason. Once the Proxy Device B receives the Proxy Authorization Response with the status value of 'SUCCESS', it will return the Request Device A the Authorization Response with the status value of 'SUCCESS', else if the failure reason in the Proxy Authorization Response is only on the side of Proxy Device B(such as the 'Certificate B invalid'), it will correct the errors and send the Proxy Authorization Request again to the Service Server, else will return the Request Device A the Authorization Response with the status value of the failure reason. 7. Application Example Take the home application as an example, the Home Gateway( or the Home Server) acts as the Proxy Device. The benefit is the User can just register one Device(the Home Server) to the Service Provider and apply for the services for all his personal devices as his desire very conveniently. The procedure is very simple that the User operates a device to create and send an Authorization Document to the Home Server. Then he can use that device to apply for service via the Home Server's proxy at once after the Home Serve accepts the authorization. On this architecture the service charging will also be very convenient to the service since the charge can be bounded on the Home Server only. On this architecture, another advantage is that the Home Server can actually control the other devices for applying the service. Somehow this architecture acts similarly as the "Parent Mechanism" to constrain the children's content applications via controlling the devices of the children since the Home Server can judge and refuse the service applications of the Request Device, or refuse the "Authorized Rights" from the Request Device. Zhou & Chen Expires August 30, 2010 [Page 13] Internet-Draft PKI Proxy Architecture Feb 2010 On some cases, the Request Device SHOULD ask the Home Server to suspend some service applications. For instance, the Request Device will be given to the User's friend, then the Proxy relationship can be suspended once the Request Device sends the Authorization Document containing the suspending rights. 8. Extended Architecture In the section 3, one Proxy Device is deployed in the Proxy Architecture. In fact, by the proxy mechanism defined above, a Multiple-Proxy Architecture can be implemented. It is shown in Figure 5 below: Proxy Proxy +--------+ Request +---------+ Request-1 +---------+ Request-n +-------+ |Request | ------->|Proxy | .........>|Proxy |---------->|Service| |Device A|<------- |Device-1 |<..........|Device-n |<----------|Server | +--------+ +---------+ Proxy +---------+ Proxy +-------+ Response Response-1 Response-n Figure 5. Architecture Multiple-Proxy Service In the Multiple-Proxy Architecture, if the Proxy Device can not apply for service to the Service Server directly either, it can forward the Request to the next Proxy Device. On the return way, the Response will be delivered back one by one to the Request Device. The Trust Architecture for Multiple-Proxy Service is shown in Figure 6 below. Certificate-A Certificate-A + Certificate-1 + + +---------+ Authorization +---------+ Authorization +---------+ |Request | -------------->|Proxy | ...................>|Proxy | |Device A |<-------------- |Device-1 |<....................|Device-n | +---------+ Response +---------+ Proxy +---------+ Response-1 | | | | | | Certificate-A | | + ...... | | + Certificate-n | | +-------+ + Authorization | | |Service|--------------------------+ | |Server |----------------------------+ +-------+ Proxy Response-n Figure 6. Trust Architecture for Multiple-Proxy Service Zhou & Chen Expires August 30, 2010 [Page 14] Internet-Draft PKI Proxy Architecture Feb 2010 In the Trust Architecture for the Multiple-Proxy Service, the certificates and authorization SHOULD be relayed until to the Service Server. If in one step, the verification of certificates and Authorization is not successful, the trusted relationship chain between the Request Device and the Service Server can not be built up. Hence the proxy service will not be available for the Request Device. As for the DRM application, the "Response" will be the "DRM Response" as depicted in following Figure 7. Certificate-A Certificate-A + Certificate-1 + + +---------+ Authorization +---------+ Authorization +---------+ |Request | -------------->|Proxy | ...................>|Proxy | |Device A |<-------------- |Device-1 |<....................|Device-n | +---------+ DRM Response +---------+ Proxy +---------+ DRM Response-1 | | | | | | Certificate-A | | + ...... | | + Certificate-n | | +-------+ + Authorization | | |Service|--------------------------+ | |Server |----------------------------+ +-------+ Proxy DRM Response-n Figure 7. Trust Architecture for Multiple-Proxy DRM Service 9. Security Considerations To guarantee the Authorization Document is valid in limited period, it SHALL contain the expiration date which SHALL be earlier than the expiration date ("notAfter" element defined in X.509) of the certificates of both Request Device and Proxy Device. During the valid period, the Authorization Document does not need to be delivered in every service operation if the target entity (the Proxy Device or Service Server) has already held it. If during the valid period, either the Request Device or the Proxy Device has updated its certificate, this Authorization Document will expire automatically. It means either the Proxy Device or the Service Server will reject the Request or Proxy Request if the Authorization Document can not be verified successfully. Therefore the Request Device needs to create a new one if it like to continue the proxy service. Zhou & Chen Expires August 30, 2010 [Page 15] Internet-Draft PKI Proxy Architecture Feb 2010 In the Trust Architecture, all the involved entities including the Request Device, the Proxy Device and the Service Server MUST be secure device and server meanwhile should correctly execute the service protocols. With regard to the DRM devices(including the requesting device and proxy device) in DRM applications, they SHALL obey the DRM specification strictly and SHALL own the security capability requested for DRM device in the DRM specification. Therefore all the related security measures defined in DRM specification SHALL be completely implemented in these Devices. The Proxy Device MAY need to register with Service Device and only the registered Proxy Device can conduct the Proxy Service. But the Proxy Device will be able to take proxy service for any Request Device although it SHOULD send the certificate of the Request Device to the Service Server to ensure that the Service Server can verify the Request Device's security status. With regard to the Service Server in DRM applications, it SHALL obey the DRM specification too. For instance, it acts as the RI (Rights Issuer) that is defined in OMA DRM2.1 [OMA DRM2.1 TS] . 10. IANA Considerations This document requires no actions from IANA. 11. Acknowledgements Many thanks to all the members of Huawei DRM project team. Countless discussions and ceaseless effort have surely helped us transcend each tough process one after another. Great and Cheer! Also many thanks to all the people I know in the DRM-related Chinese and international standard organizations. Interesting debates and discussions help me much and will remain in my mind forever. Wish all of us big success in the future. When revising this draft, I have got much kind comments and guidance. Big thanks in heart. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Zhou & Chen Expires August 30, 2010 [Page 16] Internet-Draft PKI Proxy Architecture Feb 2010 [X.509] "ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks". [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [OMA DRM2.1 TS] OMA-TS-DRM_DRM-V2_1-20081106-A, "DRM Specification". [SHA-1] National Institute of Standards and Technology (NIST), "FIPS 180-2: Secure Hash Standard", August 2002. Authors' Addresses Zhipeng Zhou (editor) Huawei Technologies, Inc. Floor 2, Building A, NO.48, Ning Nan AV., Nanjing, Jiangsu Province 210001 P.R.China Phone: +86-25-82276771 Email: zhouzp@huawei.com Ge Chen China Telecom 109 West Zhongshan Ave, Tianhe District Guangzhou, Guangdong Province 510630 P.R.China Phone: +86-20-38639766 Email: cheng@gsta.com Zhou & Chen Expires August 30, 2010 [Page 17]