Comments on Widgets 1.0 Security requirements

I have some comments on requirements section 4.6, Security and DIgital  
Signatures, editors draft [1], and some concrete suggestions for  
changes:

(1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44.-

This requirement is unclear. Is the intent to say that a signature  
associated with a widget package might be extracted and served to a  
client independently of the package, allowing the package to be  
delivered without the signature inside of it?

Or is it saying that the certificate chain and/or revocation  
information should be able to be accessed independently of the package?

In general it might not make sense to validate a signature without  
access the widget content, since that is not meaningful unless it is  
possible to validate the content hashes used to generate and validate  
the signature.

(2) R45 http://dev.w3.org/2006/waf/widgets-reqs/#r45.-

It would be useful to add a sentence as to why SHA-1 is still  
required, e.g. "Continued SHA-1 support is recommended to enable  
backward compatibility and interoperability".

On the other hand if the widget specification has not yet been  
adopted, is there a reason not to require SHA-256 (and make SHA-1  
optional), given the known potential weaknesses with SHA-1?

Suggestion:  replace "MUST strongly recommend the use of SHA-256" to  
"MUST recommend SHA-256  for new signature generation and must  
recommend SHA-1 and SHA-256 for signature verification" (or explicitly  
note that SHA-1 is optional)

"strongly recommend" is not a normative phrase according to RFC 2119.

(3) R46 http://dev.w3.org/2006/waf/widgets-reqs/#r46.-

Change "and" to "or" in the first sentence and "or" to "and" in the  
second to obtain the intended meaning.

(4) R49 http://dev.w3.org/2006/waf/widgets-reqs/#r49.-

The phrase "To provide up-to-date" is misleading, since cached  
information may be less up to date than the result of an online query,  
especially with OCSP.

Suggest changing  rationale paragraph to

"To enable a widget to obtain revocation information without having to  
query an online CRL or OSCP server from each device. This is a lot  
more efficient and eases the load on CRL or OCSP servers.  Note,  
however, that the revocation information may not be as up to date as  
an online query. However, if this information is updated at the server  
in a timely manner before widget installations, then an online query  
would not be necessary at the client."

(5) Missing requirement: "A signature should indicate the role of the  
signer."

Suggested text "A signature may be signed by a widget author as well  
as a widget distributor. The role of the signer should be indicated to  
enable the verifier to understand the role of the signer and  
associated implications."

(6) Missing requirement: "A signature should indicate a policy  
associated with it, independent of information associated with key or  
certificate information"

For example, a signature should have a usage (or policy) property  
indicating that it is associated with the W3C Widget Signature  
specification and processing rules. The use of a URL is recommended to  
allow different policies and to enable updated versions.

(7) Missing  requirement: "Widget packages only require signature  
validation and certificate and revocation verification upon first  
installation on a device"

Proposed text:
"A widget package signature is validated and associated certificates  
and revocation information verified, only when the widget is first  
installed on the device. Signatures and certificate and revocation  
information may be updated over time at the server for subsequent  
installation on other devices, effectively creating a new widget  
package."

(8) Missing requirement - "Widget signatures must include counter- 
measures against use of out of date widget packages"

Since a signature is validated upon widget installation, and this  
signature (and associated certificate and revocation information) can  
be updated before subsequent widget installations, it is important  
that an old signature cannot be re-used (replayed), since that would  
cause updated certificate and revocation information to be ignored.

Thus a signature should have material to avoid later inappropriate  
reuse - such as a short-lived expiration of the signature.

Note that a nonce and timestamp, as used for replay attack mitigation,  
may not be suitable since the client may never have installed the  
widget previously and not have access to earlier nonce information.

That is all for now, though I may have missed something.

regards, Frederick

Frederick Hirsch
Nokia


[1] http://dev.w3.org/2006/waf/widgets-reqs/

Received on Monday, 5 January 2009 22:22:56 UTC