Re: Comments on Widgets 1.0 Security requirements

Hi Frederick, 
I've updated the requirements document wrt the suggestions you have made.
However, I have not yet included the new requirements as I need to consider
them a bit more before I do so. Naturally, if we find that things like
expiration and policy association are applicable beyond widgets, I'm
wondering if they should become requirements for XML Dig Sig 2.0?

Inline comments below...

On 1/5/09 10:21 PM, "Frederick Hirsch" <frederick.hirsch@nokia.com> wrote:

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

Simplified the requirement (see my response to Art).
 
> (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".

I've added the text above to the rationale.

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

I reworded the requirement using your recommended text.

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

Fixed.

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

Agreed. 

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

New rationale seems good. Added your text, but with some minor editorial
changes. 

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

We have been bouncing the idea around of having an "author.sig" resource
inside the package to overcome this issue. However, this is a more elegant
solution. Again, would this be something useful for XML Dig Sig 2.0?
 
> (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.

I support this requirement. Can you give me an (XML) example of what this
might look like? 
 
> (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."

This seems reasonable, tough a little like an implementation detail.
However, I'm happy to include this requirement.
 
> (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.

This also sounds worth while. However, this again sounds like a general
problem. I'm OK for Widgets Dig Sig to be the guinea pig of solutions to
thwart such replay attacks, but would eventually like to see such things
become part of XML Dig Sig 2.0.

Kind regards,
Marcos

Received on Monday, 19 January 2009 20:50:31 UTC