Re: [widgets] Dig Sig spec

On Tuesday, May 3, 2011 at 12:00 AM, timeless wrote: 
> It's pretty much impossible for me to figure out which things are new
> or which i've missed in previous rounds. (It's also possible that I
> didn't review this spec, in which case, I'm sorry.) I don't believe
> these comments significantly affect the document, i.e. they're mostly
> editorial, although some are technically errors which should
> definitely be fixed.
> 
> http://dev.w3.org/2006/waf/widgets-digsig/
> 
> > A widget package can be digitally signed by an author to produce a signature file
> > that cryptographically includes all of the files of a widget package that are not
> 
> i don't think "includes" is right, perhaps "covers" or "attests".
> 
Covers it is. 


> > A user agent or other entity can use author signature to determine:
> 
> use _an_ author

fixed. 
> 
> > As the following terms are used throughout this specification, they are gathered here for the readers convenience.
> 
> reader's

fixed 
> 
> > A file name is the name of a file contained in a widget package (excludes path information), as defined in the [Widgets Packaging] specification.
> 
> probably s/excludes/excluding/
fixed 
> 
> > Set the a URI attribute for each ds:Reference to be the zip relative path that identifies a file inside the widget package.
> 
> drop "a"
I changed it "the fie"... just saying "file" 
> >  Generate a identifier property in the manner specified in [Signature Properties].
> 
> an
fixed 
> 
> >  Serialized the signature as a [UTF-8] encoded [XML] document using the appropriate naming convention depending on its role:
> 
> Serialize ? (present tense, action/command v. past tense)
> 
Fixed. 
> > To validate the siganture files of a widget package, a validator MUST run the algorithm to validate digital signatures.
> 
> signature is misspelled
fixed 
> 
> > terminate this algorithm and treat as an unsigned widget package:
> 
> treat _it_ as...

fixed 
> 
> >  Check that signature has a ds:Reference for every file that is not a signature file. If every non-signature file is not included, then signature is in error.
> 
> s/every/any/
> s/not included/not listed/
fixed and fixed 
> 
> >  If the role property is missing or or invalid, then signature is in error.
> 
> s/or or/or/
fixed 
> 
> >  If all signatures validated successfully, treat this as a signed widget package.
> 
> s/validated/validate/

fixed 
> 
> >  Search the root of the widget package for any file name that case-sesitively
> 
> sensitively is misspelled
> 

Fixed. 
> > This implies that, in order to verify a signature file, a user agent need
> 
> needs
> 

fixed 
> > A signature .. does not limit .. decompression and unpacking code used during signature extraction and verification.
> 
> This doesn't seem to be a complete thought.

Agreed. This is redundant anyway so I killed it. I just said in the first paragraph: "the security considerations of [Widget Packaging] also apply to this specification." 
> 
> > A signature file can also be renamed, which can affect the order in which distributor signatures are processed.
> 
> This could have been addressed by embedding the signature file name
> into the file, oh well :)
True... oh well. Something for v2, I guess. 
> 
> > Mechanisms to install new root certificates in a user agent need to be subject to security critical mechanisms.
> 
> 'security critical mechanisms' doesn't sound right
Agreed. Removed that sentence. Changed the paragraph to: 

 If the user agent supports installing a new root certificate, an end-user should be made aware of what they are doing, and why. 

Thanks for the review, Josh!

Received on Wednesday, 4 May 2011 15:11:04 UTC