Subject: Re: [pkix] Appreciate your comments on a new version draft.Thks.

From: "Kravitz David-A00027" <[email-masked]>
Date: Thu, 22 Oct 2009 15:20:36 -0400

Dear Zhipeng and all,

Based on my read-through of the draft http://www.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-01.txt, although it indicates that the underlying DRM system can be OMA DRM v2.1, the proposed architecture would be significantly weaker than what is intended by OMA DRM v2.1 unless at least one of the following holds (where none of this appears to be addressed within the current IETF draft):

1.	There is an end-to-end security association (for integrity) between Request Device A and the Service Server/Service Provider; 
2.	The Authorization Response includes the Service Server’s signature for the purpose of the Request Device A’s verification of source and integrity of critical data; 
3.	The Proxy Device B has a certificate that explicitly identifies it as trusted with the Proxy role. 

With regard to option 3, OMA DRM v2.1 identifies (for the extKeyUsage extension) oma-kp-drmAgent key purpose and oma-kp-rightsIssuer key purpose object identifiers. Potentially, a Proxy Device could be provisioned with a certificate that includes the oma-kp-rightsIssuer key purpose. Although OMA Secure Content Exchange (SCE) defines key purposes that map to home gateway/home server roles, these are not part of the underlying OMA DRM v2.1 specifications.

Note that the use of a Connected Device as proxy for an Unconnected Device in OMA DRM v2.1 (section 18 of DRM v2.1) explicitly requires the Unconnected Device to register with the Rights Issuer (through the proxy) and join a Domain with the Rights Issuer (through the proxy) that corresponds to a Domain that the Connected Device also joins with the Rights Issuer, and is limited to Domain Rights Objects (i.e., excludes Device ROs).

If the sentence in section 7 of the draft that reads “The benefit is the User can just register the Device(the Home Server) to the Service Provider and apply for the services for all his personal devices as his desire very conveniently,” is interpreted as meaning that Request Devices need not complete OMA DRM v2.1 registration with the Service Server/Service Provider as Rights Issuer, then under the current OMA DRM v2.1 specifications the Service Provider/Rights Issuer cannot join the Request Device to its Domain(s) or generate Device Rights Objects for the direct use of the Request Device.  The Service Provider (as Rights Issuer) could complete these operations with the Proxy Device (as DRM Agent), and the Proxy Device (as Rights Issuer, if so certified) could join the Request Device to Domain(s) and could convert Rights Objects (generated by the Service Provider) that it has access to as a certified DRM Agent to Domain or Device Rights Objects for use by Reque
 st Devices. Under OMA DRM v2.1, a DRM Agent expects the signature over the <rights> element for a Domain RO to correspond to the Rights Issuer with which the DRM Agent joined the Domain.

The wording of the IETF draft, such as in the section 4 sentence “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,” is vague on what is intended.

Note also that if a Proxy Device is not securely differentiable (through its certificate) by the Service Server/Service Provider from an entity that is solely a DRM Agent, then there would need to be some other means to enforce the “Parent Mechanism” discussed in section 7 of the IETF draft, in order to prevent “children” from colluding to take on both the “parent” and “child” roles - Charging/billing aspects are not part of the DRM system, per se.

Thanks,
David Kravitz

Motorola Applied Research Center

[email-masked]

[pkix] Appreciate your comments on a new version draft.Thks.

________________________________

*	From: zhouzp <zhouzp at huawei.com <mailto:[email-masked]> > 
*	To: ietf-pkix at imc.org <mailto:[email-masked]>  
*	Date: Wed, 21 Oct 2009 11:54:40 +0800 
*	List-id: PKIX Working Group <pkix.ietf.org> 

________________________________

size=2 width="100%" align=center> 

Dear all,

I just summit a new version draft at the server. It is:http://www.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-01.txt <http://www.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-01.txt>  .

In this document, quite a few supplements and modifications have been done, exp. the section 6,7,8, to give a more complete solution on this topic.

Welcome your helpful comments, suggestions and ideas.

In the Hiroshima, also hope to get your kind opinions F2F.

Thanks.

Zhipeng

-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48，Ning Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail: zhouzp at huawei.com <mailto:zhouzp%20at%20huawei.com> 
Phone:(+86) 25-82276771
Fax:(+86) 25-82276760

Mobile:(+86) 13404162849

---

From: zhouzp <[email-masked]>
Date: Fri, 23 Oct 2009 16:29:28 +0800

Hi David, 
Thanks for your careful review and detailed feedback,esp. on the part of the
pki certificates.
I think I need a little more time reviewing these issues . 
While for the service model, I like to invite as many people as possible to
see whether it is capable.
Then review wether there are some implementation topics or gaps on the
existing DRM specs.
If exist, maybe just via implementation solution or via an extension to
existing DRM spec, the complete solution for the market will be available.
In my next version, your kind comments will make sense. And welcome more :)
Thanks.
Zhipeng

  _____  

From: Kravitz David-A00027 [mailto:[email-masked]] 
Sent: Friday, October 23, 2009 3:21 AM
To: [email-masked]; zhouzp
Subject: Re: [pkix] Appreciate your comments on a new version draft.Thks.

Dear Zhipeng and all,

Based on my read-through of the draft
http://www.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-01.txt,
although it indicates that the underlying DRM system can be OMA DRM v2.1,
the proposed architecture would be significantly weaker than what is
intended by OMA DRM v2.1 unless at least one of the following holds (where
none of this appears to be addressed within the current IETF draft):

1.	There is an end-to-end security association (for integrity) between
Request Device A and the Service Server/Service Provider; 

2.	The Authorization Response includes the Service Server’s signature
for the purpose of the Request Device A’s verification of source and
integrity of critical data; 

3.	The Proxy Device B has a certificate that explicitly identifies it
as trusted with the Proxy role. 

With regard to option 3, OMA DRM v2.1 identifies (for the extKeyUsage
extension) oma-kp-drmAgent key purpose and oma-kp-rightsIssuer key purpose
object identifiers. Potentially, a Proxy Device could be provisioned with a
certificate that includes the oma-kp-rightsIssuer key purpose. Although OMA
Secure Content Exchange (SCE) defines key purposes that map to home
gateway/home server roles, these are not part of the underlying OMA DRM v2.1
specifications.

Note that the use of a Connected Device as proxy for an Unconnected Device
in OMA DRM v2.1 (section 18 of DRM v2.1) explicitly requires the Unconnected
Device to register with the Rights Issuer (through the proxy) and join a
Domain with the Rights Issuer (through the proxy) that corresponds to a
Domain that the Connected Device also joins with the Rights Issuer, and is
limited to Domain Rights Objects (i.e., excludes Device ROs).

If the sentence in section 7 of the draft that reads “The benefit is the
User can just register the Device(the Home Server) to the Service Provider
and apply for the services for all his personal devices as his desire very
conveniently,” is interpreted as meaning that Request Devices need not
complete OMA DRM v2.1 registration with the Service Server/Service Provider
as Rights Issuer, then under the current OMA DRM v2.1 specifications the
Service Provider/Rights Issuer cannot join the Request Device to its
Domain(s) or generate Device Rights Objects for the direct use of the
Request Device.  The Service Provider (as Rights Issuer) could complete
these operations with the Proxy Device (as DRM Agent), and the Proxy Device
(as Rights Issuer, if so certified) could join the Request Device to
Domain(s) and could convert Rights Objects (generated by the Service
Provider) that it has access to as a certified DRM Agent to Domain or Device
Rights Objects for use by Request Devices. Under OMA DRM v2.1, a DRM Agent
expects the signature over the <rights> element for a Domain RO to
correspond to the Rights Issuer with which the DRM Agent joined the Domain.

The wording of the IETF draft, such as in the section 4 sentence “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,” is vague on what is intended.

Note also that if a Proxy Device is not securely differentiable (through its
certificate) by the Service Server/Service Provider from an entity that is
solely a DRM Agent, then there would need to be some other means to enforce
the “Parent Mechanism” discussed in section 7 of the IETF draft, in order
to prevent “children” from colluding to take on both the “parent” and
“child” roles – Charging/billing aspects are not part of the DRM system,
per se.

Thanks,
David Kravitz

 

  _____  

  _____  

Dear all,

I just summit a new version draft at the server. It is:
<http://www.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-01.txt>
http://www.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-01.txt .

In this document, quite a few supplements and modifications have been done,
exp. the section 6,7,8, to give a more complete solution on this topic.

Thanks.

Zhipeng

Floor 2, Building A, NO.48，Ning Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail:  <mailto:zhouzp%20at%20huawei.com> zhouzp at huawei.com
Phone:(+86) 25-82276771
Fax:(+86) 25-82276760

Mobile:(+86) 13404162849