W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: Comments on Widgets 1.0 Security requirements

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Mon, 19 Jan 2009 13:02:58 +0000
To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, Frederick Hirsch <frederick.hirsch@nokia.com>
CC: public-webapps <public-webapps@w3.org>, Thomas Roessler <tlr@w3.org>
Message-ID: <C59A2A82.3D56%marcosscaceres@gmail.com>

On 1/12/09 2:03 PM, "Priestley, Mark, VF-Group"
<Mark.Priestley@vodafone.com> wrote:

> Hi Frederick, All,
> As promised on last week's call some further clarifications below on
> R44.
> Thanks,
> Mark
>>> (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?
>> Although one can extract a signature XML element from a widget
>> package, I'm not sure how meaningful that is if one cannot
>> subsequently locate the content that is signed - for example
>> if a ds:Reference refers to an item in the widget package, how
>> can an extracted signature be validated if that item is no
>> longer available?
>> Along similar lines, I might expect the URI for a resource to
>> be relative if the signature is always enveloped (the
>> signature is within the widget package containing the
>> signature and other items) but perhaps a full URL for
>> detached, when the signature is stored separately from the
>> signed items.
>> I do not think this requirement is met by the Widgets
>> Signature document as it states "The URI attribute must be a
>> relative path to the root of the widget."
>> how will this work with detached signatures where the widget
>> content is not in the same context as the signature?
> [MP] I think there is still some confusion over the use case we're
> trying to address. There is no desire to complete the validation of
> the signature document before the widget package has been downloaded
> and therefore no need to use anything other than relative paths in
> the reference elements. The main motivation for providing the
> signature document in advance of the widget package is to allow the
> widget user agent to check whether it has the necessary root certs
> installed to validate the signature's cert chain. If the widget agent
> can't do this it may choose not to download the widget package. In
> some cases there may be an advantage to validating the signature value
> of the signature document in advance of downloading the widget package,
> noting that the entire signature document will not be validated until
> the reference validation has also been successfully completed.
> However, as stated on the call, it is not the intention to specify this
> use of the signature document in Widgets 1.0. As such the only
> requirement
> on the specification is that it does not rule out this use case, e.g. by
> specifying that reference validation must always happen before
> validation 
> of the signature value. My understanding is that the current text is
> fine in 
> this regards.  

Agreed. The above, theoretically, can already happen. The requirement just
mandates that this will not change in the future.

Kind regards,
Received on Monday, 19 January 2009 20:50:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:23 UTC