Hi Rainer, On Thu, Mar 26, 2009 at 1:57 PM, Hillebrand, Rainer <[email protected]> wrote: > Dear Marcos, > > I have some proposals for editorial changes. > > 1. Section 1.2: change "which MAY logically contains" to "which MAY logically > contain"
fixed. > 2. Section 1.2: "An unsigned widget package is a widget package that does not > contain any signature files. It is left to the user agent's security policy > how to deal with unsigned widget packages." Doesn't the same apply to signed > widget packages, too? There is no W3C right now that specifies how a user > agent shall deal with signed widget packages. I suggest to delete the > sentence "It is left to the user agent's security policy how to deal with > unsigned widget packages." > Deleted. > 3. Section 1.2: "Rules are concatenated by being written next to each other > and a rule prep ended by * means zero or more." I would suggest to split this > sentence into two: "Rules are concatenated by being written next to each > other. A rule prep ended by * means zero or more." What is a "rule prep"? > Ok, split. Dunno what a prep is, so I removed it. > 4. Section 2: change "this specification supports SHA-256 the reference > element and ds:SignedInfo element" to "this specification supports SHA-256, > the reference element and ds:SignedInfo element" > fixed. > 5. Section 3: "Implementers are encouraged to provide mechanisms to enable > end-users to install additional root certificates. Trust in a root > certificate is established through a security critical mechanism implemented > by the user agent that is out of scope for this specification." A root > certificate could be used for TLS as well but we mean certificates for widget > package signature verification. "additional" could imply that a user agent is > always provided with at least one certificate which does not need to be the > case. Therefore, I would like to propose to change this part to "Implementers > are encouraged to provide mechanisms to enable end-users to install > certificates for widget package digital signature verification. Trust in a > certificate is established through a security critical mechanism implemented > by the user agent that is out of scope for this specification." > Ok, I included your text, but modified it slightly: "Implementers are encouraged to provide mechanisms to enable end-users to install certificates for enabling verification of digital signatures within the widget package. Trust in a certificate is established through a security critical mechanism implemented by the user agent, which is out of scope for this specification." > 6. Section 4: "Process the signature files in the signatures list in > descending order, with distributor signatures first (if any)." The processing > is not defined before and it is unclear whether there is a difference between > processing and signature validation. Suggestion: "Validate the signature > files in the signatures list in descending order, with distributor signatures > first (if any)." > Fixed. > 7. Section 5.1: change "in [XML-Schema-Datatypes])within" to "in > [XML-Schema-Datatypes]) within" Fixed. > 8. Section 5.2: change header "Author Signatures" to "Author Signature" > because we have zero or one author signature. > True. fixed. > 9. Section 5.2: "and whether two widgets came from the same author": Two > signed widgets that were signed with the same certificate only indicate that > these both widgets were signed with the same certificate. The signatures do > not enable any confidence in the relationship between a widget author and a > widget signer. There are no means that hinder me as an attacker to strip off > all widget's signatures, sign it with my own certificate with which I signed > another but rogue widget from somebody else. Therefore, I would recommend to > delete this bullet point. > Agreed. Can we say "were signed with the same certificate" instead? > 10. Section 5.2: change "A widget package MAY contain zero or one author > signatures." to "A widget package MAY contain zero or one author signature." > fixed. > More change proposals may come tomorrow (if identified tomorrow). Thanks for taking the time to do the review!!! Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
