Re: [widgets] Dig Sig spec

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".

> signature files (e.g., HTML files, CSS files, and JavaScript files).


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

use _an_ author

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

reader's

> 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/

> 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"
>    Generate a identifier property in the manner specified in [Signature Properties].

an

>    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)

> To validate the siganture files of a widget package, a validator MUST run the algorithm to validate digital signatures.

signature is misspelled

> terminate this algorithm and treat as an unsigned widget package:

treat _it_ as...

>        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/

>            If the role property is missing or or invalid, then signature is in error.

s/or or/or/

>    If all signatures validated successfully, treat this as a signed widget package.

s/validated/validate/

>    Search the root of the widget package for any file name that case-sesitively

sensitively is misspelled

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

needs

> A signature .. does not limit .. decompression and unpacking code used during signature extraction and verification.

This doesn't seem to be a complete thought.

> 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 :)

> 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

Received on Monday, 2 May 2011 22:01:26 UTC