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/
