RE: Comments on Widgets 1.0 Security requirements

Hi Frederick,

Thanks for your comments. As someone who had a hand in some of the
requirements that you've commented on, please see some responses inline.

Regards,

Mark  

-----Original Message-----
From: public-webapps-request@w3.org
[mailto:public-webapps-request@w3.org] On Behalf Of Frederick Hirsch
Sent: 05 January 2009 22:22
To: public-webapps
Cc: Frederick Hirsch; Thomas Roessler
Subject: 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.

[MP] Re-reading the requirement I agree we could have been clearer in
what we were requiring, which is: 

1. It MUST be possible to extract a _copy_ of the digital signature
document(s) from the widget package.
2. It SHOULD (MUST?) be possible for the widget user agent to complete
the signature validation processing for a digital signature document
that is provided independently of a widget package (noting that the
signature is not validated until the reference validation processing has
also been successfully completed)

When we write the specification text to meet this requirement we will
need to ensure that the error cases are covered, e.g. when the
independently supplied and packaged digital signature do not match.

With these clarifications hopefully the requirement and rationale make
more sense? 


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

[MP] I support your suggested changes.

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

[MP] Well spotted, this is indeed an error - I support your suggested
changes

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

[MP] I support your suggested changes; more accurate and clearer

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

[MP] I don't object to this requirement but I would be interested in the
use case given that we have the author element?  

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

[MP] I agree with the intent of this requirement but think we need to be
clear what we want to specify. What we are really trying to say is that
the signature may be processed differently depending on the usage
associated to the signature. However, before we specify this text I
think we need some further discussion on what the usage properties
should be and how they should be specified. For example, is it expected
that for each usage property there will be a section in Widgets 1.0:
Digital Signatures that defines the processing for that usage property
on top of the core processing?  

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

[MP] Just so that I am clear, the requirement you are proposing here is
that the signature format must support the inclusion of signature
expiration data? This expiration data is associated to the signature and
not the end-entity certificate used to generate the signature? If this
is the proposal I am in full agreement. However, in this case I think
that we re-word the proposed text as it currently implies that we are
recommending the use of short lived signatures, which is really a
security policy decision for the signer.


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 Wednesday, 7 January 2009 16:04:09 UTC