On 1/12/09 2:03 PM, "Priestley, Mark, VF-Group"
<mark.priest...@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,
Marcos
