RE: Comments on Widgets 1.0 Security requirements

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.  
   









>-----Original Message-----
>From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com] 
>Sent: 07 January 2009 18:36
>To: Priestley, Mark, VF-Group
>Cc: Frederick Hirsch; public-webapps; Thomas Roessler
>Subject: Re: Comments on Widgets 1.0 Security requirements
>
>Mark
>
>Some more discussion inline, thanks for taking the time to review.
>
>Do you mind updating the draft with the items we agree?
>
>regards, Frederick
>
>Frederick Hirsch
>Nokia
>
>
>
>On Jan 7, 2009, at 11:03 AM, ext Priestley, Mark, VF-Group wrote:
>
>> 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?
>>
>
>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?
>
>
>>
>> (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.
>>
>
>I strongly suggest we require XML Signature 1.1 which should 
>include new algorithms and address some practices around their use.
>
>
>> (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?
>
>where is 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?
>>
>
>I meant something different than what you read, so we may need 
>to be clearer.
>
>I suggest we have a URI that indicates signature conformance 
>to the Widgets 1.0 Digital Signature specification.
>
>I believe you are suggesting additional policy that can vary? If so   
>that is a different requirement.
>
>
>
>> (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.
>>
>>
>
>I was trying to capture the use case and associated 
>requirements - that signatures are only verified upon widget 
>installation and can be short lived (changed between 
>installations). This is different than long term signatures 
>used for legal purposes and more a code signing application.
>
>Yes, I believe an Expires property could satisfy the 
>requirement but the requirement is about verification upon 
>install and not allowing inappropriate reuse of widget packages.
>
>> 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 Monday, 12 January 2009 14:05:34 UTC