- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Tue, 20 Jan 2009 11:23:46 -0500
- To: ext Marcos Caceres <marcosscaceres@gmail.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, public-webapps <public-webapps@w3.org>, Thomas Roessler <tlr@w3.org>
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.hirsch@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 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. > > This also sounds worth while. However, this again sounds like a > general > problem. I'm OK for Widgets Dig Sig to be the guinea pig of > solutions to > thwart such replay attacks, but would eventually like to see such > things > become part of XML Dig Sig 2.0. > > Kind regards, > Marcos > >
Received on Tuesday, 20 January 2009 16:24:33 UTC