Re: Comments on Widgets 1.0 Security requirements
Requirements related to widgets should be clearly stated, even if mechanisms can be used beyond widgets. Thus if widgets need expiration then we should be able to articulate both the use case and the requirement. Thanks for updating the requirements document for the other items. regards, Frederick Frederick Hirsch Nokia On Jan 19, 2009, at 7:48 AM, ext Marcos Caceres wrote: 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.hir...@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
Re: Comments on Widgets 1.0 Security requirements
Hi Frederick, On Tue, Jan 20, 2009 at 4:23 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: Requirements related to widgets should be clearly stated, even if mechanisms can be used beyond widgets. Thus if widgets need expiration then we should be able to articulate both the use case and the requirement. Agreed. We should probably discuss these requirements in this weeks teleconf and decide on which ones we are going to formally specify as part of Widgets 1.0 and which can be deferred to XML Dig Sig. Thanks for updating the requirements document for the other items. No problem. Thank you for providing the feedback and helping clarify the requirements! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0 Security requirements
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
Re: Comments on Widgets 1.0 Security requirements
Hi Frederick, Mark, On 1/7/09 6:36 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: 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-requ...@w3.org [mailto:public-webapps-requ...@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. I support this move. (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
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.hir...@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
Re: Comments on Widgets 1.0 Security requirements
Hi Artb, On 1/13/09 7:46 PM, Arthur Barstow art.bars...@nokia.com wrote: 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. I agree with Art, this requirement is a no brainer. Nevertheless, I'm as it does not real harm, I'm inclined to leave it the document. I've renamed it and rewritten it as: [R44. Signature Document Format A conforming specification MUST recommend a digital signature format that can be extracted and 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.] Kind regards, Marcos
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.hir...@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-requ...@w3.org [mailto:public-webapps-requ...@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
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-requ...@w3.org [mailto:public-webapps-requ...@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
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. (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. (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. (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. (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. (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. (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. 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/
