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 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. Fwiw, I would not like to go down this path. This would add a lot of complexity. I would like to see how we go with 1.0 and standardize these more advanced features if they are really needed in 2.0 or beyond. >> (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. > Again, fwiw, this all sounds good to me.
