RE: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
Hi Marcos, On behalf of OMTP, I'd like to thank you for your hard work integrating the OMTP input to the requirements spec. We're happy with the changes in [1]. Thanks, David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcos Caceres Sent: 05 September 2008 14:30 To: David Rogers; Nick Allott; Priestley, Mark, VF-Group; Paddy Byers Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2) Hi All, I've now integrated the OMTP requirements into the Req spec. OMTP crew, I'm made lots of edits (and dropped some of your requirements with Mark's permission) so please check to see that your intent is still conveyed (and that I haven't introduced any new typos, etc.). Apologies to those who are still waiting for me to respond to your comments, I'm going as fast as I can and will do my best to address everyone's comments within the next week. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/ On Fri, Aug 1, 2008 at 12:30 PM, David Rogers [EMAIL PROTECTED] wrote: Dear Art, Marcos and all, Please find attached the OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call. I've extracted the text of the input below. Please note this is the first of two sets of input. This first input contains comments to existing requirements and proposals for new requirements. The second document contains more general comments, applicable to the Widget Requirements and also the Packaging and Configuration work. Introduction OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain. It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices. OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C. Devices supporting some of the features of BONDI will become available in 2009. This document forms the input from BONDI relating to the security aspects of the W3C Widgets: 1.0 Requirements found at http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/. The document is divided into two parts; the first part details proposed changes to existing W3C requirements, the second part proposes new requirements that for inclusion. Part I - Changes to Existing Requirements Proposed By BONDI R11. Digital Signature We suggest the following re-wording of the existing requirement so that it reads: A conforming specification MUST specify a means to verify the authenticity and integrity of all resources in a widget resource, with the exception of any resources explicitly excluded by the specification. A conforming specification MUST provide this capability by specifying a processing model for generating and verifying a digital signature associated to a widget resource. The digital signature scheme MUST be compatible with existing Public Key Infrastructures (PKI), particularly X.509 digital certificates. In addition, the recommended digital signature format SHALL support the ability to include a certificate chain with a digital signature to enable the receiving device to build a certificate chain from the end entity certificate used to generate the signature to a locally stored root certificate. In addition, the recommended digital signature format SHOULD support the ability for a widget resource to be signed using multiple end entity keys (i.e. it SHOULD be possible to include multiple signatures and associated certificate chains). The proposed changes attempt to tighten and clarify the use of digital signatures and certificate chains. In addition we suggest that the following text should be added to the existing requirement: A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. A conforming specification SHALL specify that if none of the signatures and certificate chains can be verified, e.g. because of missing root certificates or where any certificates in the chain have expired or are not yet valid, then the widget resource SHALL be treated as unsigned. A conforming specification SHALL specify that the widget environment SHALL not install or load a widget resource when it can determine that any certificate in the chain has been revoked
Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
Great! Thank you David, and thanks to OMTP members for this important contribution. I personally look forward to our continued collaboration to take the Widget specs to REC :) Kind regards, Marcos On Wed, Sep 10, 2008 at 7:08 PM, David Rogers [EMAIL PROTECTED] wrote: Hi Marcos, On behalf of OMTP, I'd like to thank you for your hard work integrating the OMTP input to the requirements spec. We're happy with the changes in [1]. Thanks, David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcos Caceres Sent: 05 September 2008 14:30 To: David Rogers; Nick Allott; Priestley, Mark, VF-Group; Paddy Byers Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2) Hi All, I've now integrated the OMTP requirements into the Req spec. OMTP crew, I'm made lots of edits (and dropped some of your requirements with Mark's permission) so please check to see that your intent is still conveyed (and that I haven't introduced any new typos, etc.). Apologies to those who are still waiting for me to respond to your comments, I'm going as fast as I can and will do my best to address everyone's comments within the next week. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/ On Fri, Aug 1, 2008 at 12:30 PM, David Rogers [EMAIL PROTECTED] wrote: Dear Art, Marcos and all, Please find attached the OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call. I've extracted the text of the input below. Please note this is the first of two sets of input. This first input contains comments to existing requirements and proposals for new requirements. The second document contains more general comments, applicable to the Widget Requirements and also the Packaging and Configuration work. Introduction OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain. It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices. OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C. Devices supporting some of the features of BONDI will become available in 2009. This document forms the input from BONDI relating to the security aspects of the W3C Widgets: 1.0 Requirements found at http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/. The document is divided into two parts; the first part details proposed changes to existing W3C requirements, the second part proposes new requirements that for inclusion. Part I - Changes to Existing Requirements Proposed By BONDI R11. Digital Signature We suggest the following re-wording of the existing requirement so that it reads: A conforming specification MUST specify a means to verify the authenticity and integrity of all resources in a widget resource, with the exception of any resources explicitly excluded by the specification. A conforming specification MUST provide this capability by specifying a processing model for generating and verifying a digital signature associated to a widget resource. The digital signature scheme MUST be compatible with existing Public Key Infrastructures (PKI), particularly X.509 digital certificates. In addition, the recommended digital signature format SHALL support the ability to include a certificate chain with a digital signature to enable the receiving device to build a certificate chain from the end entity certificate used to generate the signature to a locally stored root certificate. In addition, the recommended digital signature format SHOULD support the ability for a widget resource to be signed using multiple end entity keys (i.e. it SHOULD be possible to include multiple signatures and associated certificate chains). The proposed changes attempt to tighten and clarify the use of digital signatures and certificate chains. In addition we suggest that the following text should be added to the existing requirement: A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. A conforming specification SHALL specify that if none of the signatures
Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
Hi All, I've now integrated the OMTP requirements into the Req spec. OMTP crew, I'm made lots of edits (and dropped some of your requirements with Mark's permission) so please check to see that your intent is still conveyed (and that I haven't introduced any new typos, etc.). Apologies to those who are still waiting for me to respond to your comments, I'm going as fast as I can and will do my best to address everyone's comments within the next week. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/ On Fri, Aug 1, 2008 at 12:30 PM, David Rogers [EMAIL PROTECTED] wrote: Dear Art, Marcos and all, Please find attached the OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call. I've extracted the text of the input below. Please note this is the first of two sets of input. This first input contains comments to existing requirements and proposals for new requirements. The second document contains more general comments, applicable to the Widget Requirements and also the Packaging and Configuration work. Introduction OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain. It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices. OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C. Devices supporting some of the features of BONDI will become available in 2009. This document forms the input from BONDI relating to the security aspects of the W3C Widgets: 1.0 Requirements found at http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/. The document is divided into two parts; the first part details proposed changes to existing W3C requirements, the second part proposes new requirements that for inclusion. Part I - Changes to Existing Requirements Proposed By BONDI R11. Digital Signature We suggest the following re-wording of the existing requirement so that it reads: A conforming specification MUST specify a means to verify the authenticity and integrity of all resources in a widget resource, with the exception of any resources explicitly excluded by the specification. A conforming specification MUST provide this capability by specifying a processing model for generating and verifying a digital signature associated to a widget resource. The digital signature scheme MUST be compatible with existing Public Key Infrastructures (PKI), particularly X.509 digital certificates. In addition, the recommended digital signature format SHALL support the ability to include a certificate chain with a digital signature to enable the receiving device to build a certificate chain from the end entity certificate used to generate the signature to a locally stored root certificate. In addition, the recommended digital signature format SHOULD support the ability for a widget resource to be signed using multiple end entity keys (i.e. it SHOULD be possible to include multiple signatures and associated certificate chains). The proposed changes attempt to tighten and clarify the use of digital signatures and certificate chains. In addition we suggest that the following text should be added to the existing requirement: A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. A conforming specification SHALL specify that if none of the signatures and certificate chains can be verified, e.g. because of missing root certificates or where any certificates in the chain have expired or are not yet valid, then the widget resource SHALL be treated as unsigned. A conforming specification SHALL specify that the widget environment SHALL not install or load a widget resource when it can determine that any certificate in the chain has been revoked. This addition is to ensure that there is a consistent behaviour when verifying signatures and certificate chains, especially in error cases in which the verification fails because of missing certificates and in which one of the certificates has been revoked. We use the term load to cover the case in which a widget is not subject to an installation event. In addition, we suggest the following changes to the Rationale: To provide a means to verify authenticity, check data integrity, and
RE: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
Hello all, See below some comments to the OMTP input regarding widget signing. I hope it is useful. Regards /Olli A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. The ability to sign by multiple entity keys was part of the original input paper regarding widget signing format. I understand it was removed later by the wg presumably because of lack of a compelling use case or anticipated practice. So, OMTP now considers there is a use case. Background is that this is supported in MIDP2. It would be interesting to know if signing by multiple entity keys has really been deployed so it would be worth the effort to support in the web widget scenarios. This SHALL include a means of declaring the APIs that a widget expects to access. A conforming specification SHALL provide a means to verify the authenticity and integrity of security declarations included in the widget resource. I think having a declaration of critical APIs that the widget will access is a good requirement. Now there is allow plugins, allow files, allow network in the access element. But it should be possible to declare all APIs in some way. Of course this is tricky if the APIs are not specified. Perhaps some means for organizations and vendors to allocate access flags for their APIs. R38. Additional Digital Certificates We suggest that the requirement is re-worded along the following lines A conforming specification SHOULD define mechanisms to enable end-users to install additional root certificates, provided this is compatible with the security policy of the widget processing environment. This makes sense for the overall picture. I just that a widget signing spec should not deal too much with handling root certificates since this is a general PKI issue. We suggest that the reference for X.509 is updated as follows: X.509 RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, R. Housley. IETF, April 2002. Available at: http://www.ietf.org/rfc/rfc3280.txt Makes sense. RFC3820 (or its successor RFC5280) is a practical, internet and interoperability oriented profile of X.509 whereas X.509 alone is a generic format specification. RXX. Signature Document Independence A conforming specification MUST specify the digital signature format in such a way that the signature value(s) and associated certificate chain(s) can be used independently of the widget resource that is covered by the digital signature. A conforming specification SHOULD provide guidelines for how the signature(s) and certificate chain(s) can be used separately from a widget resource. A conforming specification SHOULD specify a means to provide the independent signature document in conjunction with the independent configuration document (see R23). This independent use of signature and declarations would be similar as there is in MIDP: first get the the declarations and signature and only if everything goes well get the whole package. I have assumed it would be simpler for deployment just to deliver a single package. Note however that independent signature is in principle possible even with the existing widget signature format spec: first deliver the configuration document and the signature files (extract them from the zip); then deliver the entire zip. RXX. Independence of Non-Security Critical Information from Digital Signature A conforming specification SHOULD make it possible to change non-security critical information associated to the widget resource without having to re-sign the widget resource. The non-security critical information may or may not be included in the widget package. A conforming specification SHALL specify which information can be considered non-security critical. A conforming specification SHOULD specify a means to provide this non-security critical information in conjunction with the independent configuration document (see R23). The original widget signing input paper had the feature of possible partial signing, i.e. leaving some non-critical information unsigned. Of course then partial signing semantics would need to be clearly stated. Combining signed and unsigned information always has its risks. Of course it is also possible to have the additional information outside the widget, e.g. as part of the download web page. RXX. Support for Multiple Message Digest Algorithms A conforming specification SHALL specify that where the integrity of data is protected using a message digest, it SHALL be possible to use the SHA-1 message digest algorithm and SHALL be possible to use the SHA-256 message digest algorithm. This is good, even if SHA-1 weaknesses would be of academic nature. It would mean that widget user agent implementations would need to support both algorithms (even if everybody would just use SHA-1 :-) RXX. Support for Multiple Signature Algorithms
