pkix Zhou, Ed. Internet-Draft Huawei Technologies, Inc. Intended status: Standards Track Chen Expires: October 7, 2010 China Telecom April 5, 2010 PKI Proxy Architecture draft-zhipeng-pkix-drm-proxy-architecture-03 Abstract This document specifies a method and its architecture for proxy application based on the PKI environment with X.509 certificate [X.509]. This kind of proxy service is applicable in the occasions that a proxy entity is authorized by the client to implement the tasks with the service provider. 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. An DRM instance of the PKI proxy service is given in the appendix of this document and is fully addressed to support the proxy architecture defined in this document. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 7, 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 (http://trustee.ietf.org/license-info) in effect on the date of Zhou & Chen Expires October 7, 2010 [Page 1] Internet-Draft PKI Proxy Architecture April 2010 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 Simplified 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 . . . . . . . . . . . . . . . 6 6. Initiation and Update of Authorization . . . . . . . . . . . . 8 7. Application Example . . . . . . . . . . . . . . . . . . . . . 11 8. Extended Architecture . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 12. Normative References . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Proxy DRM Service . . . . . . . . . . . . . . . . . . 14 A.1. Architecture for Proxy DRM Service . . . . . . . . . . . . 15 A.2. Authorization Document based on OMA DRM2.1 TS . . . . . . 15 A.3. Trust Architecture for Multiple-Proxy DRM Service . . . . 17 A.4. Security on Proxy DRM Service . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Zhou & Chen Expires October 7, 2010 [Page 2] Internet-Draft PKI Proxy Architecture April 2010 1. Introduction In the PKI applications, there exist many requirements on establishing and verifying the trust relationships 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. An example is the proxy service from bank (e.g. e-bank platform) can delegate the clients to pay electricity fees from the client's account automatically every month if the client has authorized the bank to do this service. Below list two typical situations when an application MAY use this proxy method for service or content access : - 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. 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. In the proxy service, 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 proxy device can follow the authorization to take the service Zhou & Chen Expires October 7, 2010 [Page 3] Internet-Draft PKI Proxy Architecture April 2010 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. 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 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, 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 Zhou & Chen Expires October 7, 2010 [Page 4] Internet-Draft PKI Proxy Architecture April 2010 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. 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 enumerate what right the Proxy Device can hold to subscribe the service for the Request Device A. The Trust Architecture is shown as Figure 2: Certificate A Certificate A + Certificate B + + +----------+ Authorization +----------+ Authorization +----------+ | Request | ------------->| Proxy | -----------------> | Service | | Device A |<------------- | Device B |<----------------- | Server | +----------+ Response +----------+ Proxy Response +----------+ Figure 2. 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 Zhou & Chen Expires October 7, 2010 [Page 5] Internet-Draft PKI Proxy Architecture April 2010 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. 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 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(AD) 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 By owning the Authorization Document, the proxy entity can be trusted by others that it has already held the authorization by the client for the assigned services depicted in the "authorized service rights" element while the "authorized service rights" MUST depend on the real application. The binary structure of Authorization Document is defined as follow: 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 SerialNumber 32 uimsbf SignatureAlgorithm() //Refer to X.509 Signature() } Zhou & Chen Expires October 7, 2010 [Page 6] Internet-Draft PKI Proxy Architecture April 2010 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 service rights in proxy service are defined in the implementation. // Given each service right will be assigned an Id value. 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 Zhou & Chen Expires October 7, 2010 [Page 7] Internet-Draft PKI Proxy Architecture April 2010 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 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: For verifying whether the AD is true or not, 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. For details of each element of the Authorization Document, it can be referred by the DRM instance in the appendix. 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 Zhou & Chen Expires October 7, 2010 [Page 8] Internet-Draft PKI Proxy Architecture April 2010 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 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 3 below. Zhou & Chen Expires October 7, 2010 [Page 9] Internet-Draft PKI Proxy Architecture April 2010 Authorization Proxy Authorization +----------+ Request +----------+ Request +---------+ | Request | ------------->| Proxy | ------------------->| Service | | Device A |<------------- | Device B |<------------------- | Server | +----------+ Authorization +----------+ Proxy Authorization +---------+ Response Response Figure 3. 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 October 7, 2010 [Page 10] Internet-Draft PKI Proxy Architecture April 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 October 7, 2010 [Page 11] Internet-Draft PKI Proxy Architecture April 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 as shown in Figure 4 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 4. 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 5 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 Zhou & Chen Expires October 7, 2010 [Page 12] Internet-Draft PKI Proxy Architecture April 2010 Figure 5. Trust Architecture for Multiple-Proxy Service 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. 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. 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. 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 Zhou & Chen Expires October 7, 2010 [Page 13] Internet-Draft PKI Proxy Architecture April 2010 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. [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. Appendix A. Proxy DRM Service As a typical PKI application, the DRM(Digital Rights Management) service currently has been well developed on the service protocol, so in this appendix, 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. As following, this appendix gives the definition of proxy rights based on [OMA DRM2.1 TS] for the OMA DRM service that can be referenced by other kinds of services. 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. Zhou & Chen Expires October 7, 2010 [Page 14] Internet-Draft PKI Proxy Architecture April 2010 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. A.1. Architecture for Proxy DRM Service The figure 1 in this document has given the general "Architecture for Proxy Service". 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 as the following Figure 6. +----------+ DRM Request +----------+ Proxy DRM Request +----------+ | Request | -----------> | Proxy | ------------------>| Service | | Device A |<----------- | Device B |<------------------ | Server | +----------+ DRM Response +----------+ Proxy DRM Response +----------+ Figure 6. Architecture for Proxy DRM Service The message format of the "DRM Request" and "DRM Response" are defined in DRM specifications. This appendix just take the OMA DRM2.1 TS as the basement to give a full description on the Proxy DRM Service. A.2. Authorization Document based on OMA DRM2.1 TS This sub-section provides a instance of Authorization Document for DRM service. 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". For example, 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. The fields in Authorization Document for DRM service can be defined as following: DeviceId: In OMA DRM 2.1, is defined as the hash of the Zhou & Chen Expires October 7, 2010 [Page 15] Internet-Draft PKI Proxy Architecture April 2010 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 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. For details, see as following: AuthorizedRights(){ // The following service rights in proxy service are defined // with the assigned Id respectively: // 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 // 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 } Zhou & Chen Expires October 7, 2010 [Page 16] Internet-Draft PKI Proxy Architecture April 2010 } A.3. Trust Architecture for Multiple-Proxy DRM Service In the DRM application, one device can assign another device for the DRM service. Theoretically, the proxy relationship can be relayed for multiple times. Based on the "Trust Architecture for Multiple- Proxy Service", the DRM application can be depicted as the following figure 7 while the "Response" will be the "DRM Response" . 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 A.4. Security on Proxy DRM Service In DRM service, except the general secure requirement, the DRM entities SHALL also comply for the secure measures defined in DRM specification or DRM applications. 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. Zhou & Chen Expires October 7, 2010 [Page 17] Internet-Draft PKI Proxy Architecture April 2010 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] . 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 October 7, 2010 [Page 18]