RE: Comments on Widgets 1.0 Security requirements

Sorry for the (very) delayed response:

Art wrote:

>Based on the following "clarifications" and Mark's reply above:
>
>[[
><http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/
>0036.html>
>
>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) ]]
>
>It seems like #1 is a no-brainer in that every file in the 
>package must be extractable and if that requirement needs to 
>be explicit, it doesn't need to be stated as such in the 
>context of "Signature Document Independence".
>
>I view #2 as an implementation optimization that should be 
>out-of- band for the spec. I can't imagine we would write a 
>spec that would preclude a UA from doing what it is described above.
>
>Given all of this, I'm not convinced this requirement is needed.

This is fine for me. As Art suggests, as we're aware of the issue we
should be capable of specifying something that doesn't block the
behaviour described in 2. 

Thanks,

Mark 


>-----Original Message-----
>From: Arthur Barstow [mailto:art.barstow@nokia.com] 
>Sent: 13 January 2009 19:46
>To: Priestley, Mark, VF-Group; Frederick Hirsch; 
>public-webapps; Thomas Roessler
>Subject: Re: Comments on Widgets 1.0 Security requirements
>
>
>On Jan 12, 2009, at 9:03 AM, ext Priestley, Mark, VF-Group wrote:
>
>>>> (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.
>
>I agree with Frederick that R44 as codified in the most recent 
>ED (11 Dec 2008) isn't clear,  particularly trying to foresee 
>what exactly would be specified in the Widgets DigSig spec and 
>assuring we don't prescribe deployments:
>
>[[
>R44. Signature Document Independence
><http://dev.w3.org/2006/waf/widgets-reqs/#r44.->
>
>A conforming specification MUST recommend a digital signature 
>format that allows for the signature value(s) and associated 
>certificate
>chain(s) (if any) associated to the widget resource to be used 
>independently of the widget resource. A conforming 
>specification SHOULD provide guidelines for how any digital 
>signature can be used separately from a widget resource.
>]]
>
>Based on the following "clarifications" and Mark's reply above:
>
>[[
><http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/
>0036.html>
>
>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) ]]
>
>It seems like #1 is a no-brainer in that every file in the 
>package must be extractable and if that requirement needs to 
>be explicit, it doesn't need to be stated as such in the 
>context of "Signature Document Independence".
>
>I view #2 as an implementation optimization that should be 
>out-of- band for the spec. I can't imagine we would write a 
>spec that would preclude a UA from doing what it is described above.
>
>Given all of this, I'm not convinced this requirement is needed.
>
>-Regards, Art Barstow
>
>
>

Received on Thursday, 12 February 2009 12:33:59 UTC