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 <david.rogers@omtp.org> 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: public-webapps-request@w3.org
> [mailto:public-webapps-request@w3.org] On Behalf Of Marcos Caceres
> Sent: 05 September 2008 14:30
> To: David Rogers; Nick Allott; Priestley, Mark, VF-Group; Paddy Byers
> Cc: public-webapps-request@w3.org; art.barstow@nokia.com
> 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 <david.rogers@omtp.org>
> 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
> > provide a means of non-repudiation for users." to "To provide a means
> to
> > verify the authenticity, check the data integrity and provide
> persistent
> > proof of origin of the widget resource."
> >
> > "a digital signature" to "are digitally signed"
> >
> > And the following addition:
> >
> >
> >
> > "The ability to provide certificate chains with signatures is vital,
> > particularly in the mobile world, to allow end entity certificates to
> be
> > chained to a locally installed root.
> >
> >
> >
> > The ability to include multiple signatures can help address the issue
> that
> > target devices may have different root certificates installed. Equally
> there
> > SHOULD be defined behaviour for what happens when a required root
> isn't
> > available. Treating this case as an error case (and therefore not
> allowing
> > the installation of the widget) has been seen to encourage developers
> not to
> > get the applications signed whereas allowing this case but treating
> widgets
> > as unsigned doesn't provide the same disincentive."
> >
> >
> >
> >
> >
> > R21. Security Declarations
> >
> > We suggest the addition of the following text to the existing
> requirement:
> >
> >
> >
> > "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."
> >
> >
> >
> > The reason for this suggested addition is to make it explicit that it
> must
> > be possible to include required APIs in the security declarations. In
> > addition, we suggest that the security declarations should be treated
> as a
> > protected resource as the authenticity and integrity of this
> information is
> > essential if it is to be used when making security decisions.
> >
> >
> >
> > These proposed modifications are based on the assumption that security
> > declarations are included in the configuration document, which can be
> used
> > independently of the widget resource, as stated in R.23. If this is
> not the
> > case then an additional requirement is needed to ensure that the
> security
> > declarations can be used independently of the widget resource.
> >
> >
> >
> >
> >
> > 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."
> >
> > The reason for this proposal is that the existing requirement seems to
> > suggest that the user should always be able to install additional root
> > certificates on their device whereas in our opinion this capability
> should
> > be controlled by the security policy of the device. In addition, we
> have
> > removed the reference to standard root certificates as this implies a
> set of
> > root certificates that are common across all devices.
> >
> > In addition, we suggest that following text is added to the rationale
> "using
> > self-signed or test certificates, and install these test certificates
> on a
> > device in order to test their widget on a real device." as this links
> more
> > closely to the requirement.
> >
> >
> >
> >
> >
> > R43. Default Security Policy
> >
> > While we agree that it is a requirement to be able to specify a
> default
> > security policy, and that this should err on the side of caution, we
> would
> > like to seek clarification of this requirement?
> >
> >
> >
> > For example, is the intention to mandate static declarations of
> requested
> > permissions or are programmatic requests also to be allowed?
> >
> >
> >
> > We would also like to indicate that BONDI are currently working on a
> policy
> > framework and the definition of default or recommended policies and
> policy
> > configurations and would like to co-ordinate this work with W3C.
> >
> >
> >
> >
> >
> > R44. Runtime Security Exceptions
> >
> > In the sentence "A conforming specification MUST specify runtime
> exceptions
> > for when the API attempts to perform an action it is not authorized to
> > perform." suggest that "API" is changed to "widget" as this seems to
> fit in
> > better with the rationale?
> >
> > Normative references
> >
> > 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
> >
> > Part II - New Requirements Proposed By BONDI
> >
> >
> >
> > The following text proposes new requirements, related specifically to
> > security mechanisms that have been derived from ongoing work within
> BONDI.
> >
> >
> >
> >
> >
> > 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).
> >
> > Motivation:
> >
> > Web and offline distribution, device independence current development
> > practice or industry best-practices
> >
> >
> >
> > Rationale:
> >
> > To allow the signature information to be extracted and used by other
> > applications (either on the server or on the client side) for
> different
> > purposes. For example, a server may automatically extract the
> signature
> > information from a widget resource and serve it upon request. The
> > independent signature information may then be used, for instance, to
> provide
> > the user with information about the source (signing entity) and
> associated
> > trust level of the widget without needing to download the complete
> widget
> > resource. Additionally, if combined with security declaration
> information,
> > the signature information may allow a security decision to be made
> about
> > whether or not the widget will run properly, enabling a further
> decision to
> > be made as to whether to continue to download and install the widget.
> This
> > may be particularly useful for users of widgets on mobile devices,
> where the
> > cost of downloading data can sometimes be expensive.
> >
> >
> >
> > Comment:
> >
> > This is common practice in the mobile world with Java applications.
> The
> > purpose of pre-verifying elements of the signature and certificate
> chain is
> > to address the case in which a widget provided by a non-malicious
> developer
> > fails to install because for example, the certificate is out of date
> or no
> > revocation information is available. It also allows parallel OCSP
> round
> > trips while downloading widget resource (as is done for Java apps in
> the
> > mobile world)
> >
> >
> >
> >
> >
> > 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).
> >
> >
> >
> > Motivation:
> >
> > current development practice or industry best-practices
> >
> > Rationale:
> >
> >
> >
> > Some information associated to the widget resource might need to be
> changed
> > during ingestion (e.g. version, provider, name etc.). This is common
> when a
> > single developer provides the same content to a number of re-sellers.
> It may
> > be that the same information needs to be provided with the
> configuration
> > document.
> >
> >
> >
> >
> >
> > RXX. Signing Procedure Agnostic
> >
> > A conforming specification SHALL specify a mechanism for signing a
> widget
> > resource that does not explicitly or implicitly impose any
> restrictions on
> > the procedure for generating the signature. More specifically, a
> conforming
> > specification SHALL allow the use of end entity keys stored in a
> secure
> > module in a hosted environment. A conforming specification SHALL
> specify
> > that implementations SHOULD be able to use end entity keys via a
> PKCS#11
> > interface.
> >
> >
> >
> > In addition, the mechanism SHALL make it feasible for end entity keys
> to be
> > used once and then securely deleted.
> >
> >
> >
> > Motivation:
> >
> > Security, current development practice or industry best-practices
> >
> > Rationale:
> >
> > To enable signing schemes to provide assurances that a high level of
> > end-to-end security has been maintained around the signing process, in
> > particular assurance that the signing key has not been compromised.
> PKCS#11
> > is the most widely supported standard interface for hardware security
> > modules.
> >
> >
> >
> >
> >
> > 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.
> >
> >
> >
> > Motivation:
> >
> > Security
> >
> > Rationale:
> >
> > Due to known weaknesses in the SHA-1 algorithm and the expected
> lifetime of
> > implementations it is prudent to strongly recommend support for
> SHA-256 to
> > ensure that the overall security of the solution is maintained.
> >
> >
> >
> >
> >
> > RXX. Support for Multiple Signature Algorithms
> >
> > A conforming specification SHALL specify that where digital signatures
> are
> > used it SHALL be possible to use the DSA signature algorithm and SHALL
> be
> > possible to use the RSA signature algorithm.
> >
> >
> >
> > Motivation:
> >
> > Security
> >
> > Rationale:
> >
> > Security best practice: to support two algorithms to mitigate against
> the
> > risk that weaknesses are found with a selected algorithm.
> >
> >
> >
> >
> >
> > RXX. Key Lengths
> >
> > A conforming spec SHALL specify that widget processing environments
> SHALL
> > support RSA with key lengths up to at least 2048 bits and SHALL
> support DSA
> > with key lengths up to at least 2048 bits (see NIST Recommendation). A
> > conforming spec SHALL recommend that widget signing tools SHALL
> support and
> > use RSA with key lengths of at least 2048 bits and DSA with key
> lengths of
> > at least 2048 bits (see NIST Recommendation).
> >
> >
> >
> > Motivation:
> >
> > Security
> >
> > Rationale:
> >
> > To be in-line with current security recommendations and provide
> longevity of
> > the system security. In some use cases it may be desirable to use key
> > lengths of less than 2048 bits, e.g. where the impact on performance
> > outweighs the additional security afforded.
> >
> >
> >
> >
> >
> > RXX. Key Usage Extension
> >
> > A conforming specification MUST specify the expected use of valid key
> usage
> > extensions and when present (in end entity certs) MUST specify that
> > implementations verify that the extension has the digitalSignature bit
> set.
> >
> >
> >
> > A conforming specification MUST specify that implementations recognize
> the
> > extended key usage extension and when present (in end entity certs)
> verify
> > that the extension contains the id-kp-codeSigning object identifier. A
> > conforming specification MAY also define a new OID specifically for
> widget
> > signing, and specify that implementations verify that the extended key
> usage
> > extension in the end entity cert contains this new OID.
> >
> >
> >
> > Rationale:
> >
> > To maintain compliance to RFC 3280 (experience suggests that if this
> is not
> > explicitly required then the RFC 3280 is not followed when it comes to
> key
> > extension usage).
> >
> >
> >
> > Compliance ensures that only certificates intended to be used (issued
> for)
> > code signing can be used to sign widget resources.
> >
> >
> >
> > Comments:
> >
> > Using the extended key usage extension "id-kp-codeSigning" would in
> theory
> > allow the same end entity certificate to be used to sign any
> executables
> > including widgets, Java applets and native executables. However, it
> should
> > be possible to restrict the use of a particular end entity certificate
> so
> > that it can only be used to sign certain a certain type (or types) of
> > executables by associating a usage restriction with the root
> certificate to
> > which the end entity certificate is chained.
> >
> >
> >
> >
> >
> > RXX. Inclusion of Revocation Information
> >
> > A conforming specification SHOULD specify a means of packaging
> up-to-date
> > revocation information with digital signature and associated
> certificate
> > chain (e.g. a CRL or OCSP response stating that certificate has not
> been
> > revoked). In addition, a conforming specification SHOULD specify the
> > behaviour in the case that the revocation information is not included
> or not
> > complete. A conforming specification SHOULD specify that if the
> revocation
> > information is present the widget processing environment MUST attempt
> to
> > verify the revocation information. A conforming specification SHOULD
> specify
> > the behaviour if revocation information is out of date or otherwise
> invalid.
> >
> >
> >
> > In addition, the mechanism specified SHALL not require the widget
> resource
> > to be re-signed to include new revocation information.
> >
> >
> >
> > Rationale:
> >
> > To provide up-to-date revocation information, when it is needed by the
> > widget engine, without requiring a query to an online CRL or OSCP
> server
> > from each device. This is a lot more efficient and eases the load on
> CRL or
> > OSCP servers.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --------  END OF DOCUMENT  --------
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Many thanks,
> >
> >
> >
> >
> >
> > David.
> >
> >
> >
> > David Rogers
> > OMTP Director of External Relations
> > m: +44 (0) 7771 838197  david.rogers@omtp.org
> > skype: dg.rogers
> >
> > linkedIn: http://www.linkedin.com/in/davidrogersuk
> >
> > OMTP Ltd.
> > Marble Arch Tower
> > 55 Bryanston Street
> > London
> > W1H 7AJ
> >
> > www.omtp.org
> >
> > P Please consider the environment - don't print this mail unless you
> really
> > need to...
> >
> >
>
>
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.169 / Virus Database: 270.6.15/1648 - Release Date:
> 04/09/2008 18:54
>



-- 
Marcos Caceres
http://datadriven.com.au