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
>
>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.
>

In principle good, in practice the value is questionable. Means testing
effort. DSA deployment seems to be quite limited. 
There does not seem to be such information about weaknesses of RSA as
there is for e.g. SHA-1.
And if there would be in the future, e.g. related to basics of RSA, the
same weaknesses could apply for DSA as well (both relying on same
mathematics).

I think that the required algorithm set should be a minimal set
supporting interoperability. 

>
>
>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).
>

Makes sense.

>
>
>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.
>

Using id-kp-codeSigning makes sense. Defining a new OID probably does
not.

>
>RXX. Inclusion of Revocation Information

I have concerns regarding deployment of this idea.

Strictly from format point of view, XML signature
http://www.w3.org/TR/xmldsig-core/ supports adding a CRL but does not
seem to support adding an OCSP response. 


>
>
>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
>


Olli Immonen
Nokia Research Center
Helsinki, Finland
olli.immonen@nokia.com

Received on Friday, 8 August 2008 11:47:27 UTC