Re: [widgets] Dig Sig Spec ready for pub
Editorial comments, section 9 #4 typo Optionaly, also formatting in section 9 item 3 number 7. You might want dates for the SIgnature 1.1 and Signature Properties References? Relying on XML Signature 1.1 for normative algorithm requirements is sensible in my personal opinion. regards, Frederick Frederick Hirsch Nokia On May 23, 2011, at 6:46 AM, ext Marcos Caceres wrote: Hi, I would like to republish the Widgets Dig Sig specification as LC (in preparation for moving it to PR): http://dev.w3.org/2006/waf/widgets-digsig/ I have also recreated the test suite to match the new specification: http://dev.w3.org/2006/waf/widgets-digsig/test-suite/ Kind regards, Marcos
Re: [widgets] Dig Sig spec
On Mon, May 2, 2011 at 5:25 PM, Marcos Caceres marcosscace...@gmail.com wrote: On Friday, April 29, 2011 at 8:19 PM, frederick.hir...@nokia.com wrote: Marcos I'd suggest you first send an email with the top 10 substantive changes to the list, e.g. which algorithms change from mandatory to optional or optional to mandatory etc, which processing rules you are relaxing, etc this would take less time for you and be much clearer to all. I could only come up with 5... as I previously mentioned, the spec just contained a ton of redundancies (4 pages worth), but the conformance requirements are all pretty much the same. The draft is up at: http://dev.w3.org/2006/waf/widgets-digsig/ As I previously stated, the purpose of this fix up was to make concessions for WAC 1.0 runtimes, which use the default canonicalization algorithm of XML Dig Sig 1.1. Additional changes are based on working with various vendors who implemented the WAC 1 or are working on the WAC 2 specs (including the implementation that was done at Opera). I've made C14N11 the recommended canonicalization method throughout. However, user agents are free to use whatever they want so long as it complies to XML Dig Sig 1.1. 1. Validator and signers are now true [XMLDSIG11] implementations. No exceptions. This means that the test suite can be greatly reduced because everything is palmed off to [XMLDSIG11]. There is now a clear separation between a signer and validator, meaning that the implementation product is no longer needed. 2. Validators and signers now rely on [Signature Properties] for generation and validation of signature properties (as it should have been from the start). This removes a bunch of redundant text in the spec. The validation process is now written as an algorithm, as is the signing process. It makes it easy now to generate or validate a signature by simply following the steps. In the old spec, one had to jump all over the spec to check all sorts of things (e..g, Common Constraints for Signature Generation and Validation and the Requirements on Widget Signatures, both which are now folded into the appropriate algorithms). The spec now also links to the right places in [XMLDSIG11] and [Signature Properties]. I've added the ability for user agents to optionally support all signature properties (i.e., a signer can include them, and a validator can validate them, if they want). 3. The specification now only RECOMMENDs algorithms, key lengths, and certificate formats. Validators are no longer forced fail on certain certificate formats or algorithm. The only exception is the minimum key lengths, which are still enforced during verification (impossible to test during signing, without verifying, so the requirement is kinda useless). 4. The specification strengthens the recommended key lengths to be a little bit stronger (buy a few more years). 5. The spec now only contains 3 conformance criteria. [ To digitally sign the contents of a widget package with an author signature, a signer MUST run the algorithm to generate a digital signature. To digitally sign the contents of a widget package with a distributor signature, a signer MUST run the algorithm to generate a digital signature. To validate the siganture files of a widget package, a validator MUST run the algorithm to validate digital signatures. ] I've condensed it down to just two conformance requirements by merging the two signing requirements into 1: To digitally sign the contents of a widget package with an author signature or with a distributor signature, a signer MUST run the algorithm to generate a digital signature. -- Marcos Caceres http://datadriven.com.au
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!
Re: [widgets] Dig Sig spec
On Friday, April 29, 2011 at 8:19 PM, frederick.hir...@nokia.com wrote: Marcos I'd suggest you first send an email with the top 10 substantive changes to the list, e.g. which algorithms change from mandatory to optional or optional to mandatory etc, which processing rules you are relaxing, etc this would take less time for you and be much clearer to all. I could only come up with 5... as I previously mentioned, the spec just contained a ton of redundancies (4 pages worth), but the conformance requirements are all pretty much the same. The draft is up at: http://dev.w3.org/2006/waf/widgets-digsig/ As I previously stated, the purpose of this fix up was to make concessions for WAC 1.0 runtimes, which use the default canonicalization algorithm of XML Dig Sig 1.1. Additional changes are based on working with various vendors who implemented the WAC 1 or are working on the WAC 2 specs (including the implementation that was done at Opera). 1. Validator and signers are now true [XMLDSIG11] implementations. No exceptions. This means that the test suite can be greatly reduced because everything is palmed off to [XMLDSIG11]. There is now a clear separation between a signer and validator, meaning that the implementation product is no longer needed. 2. Validators and signers now rely on [Signature Properties] for generation and validation of signature properties (as it should have been from the start). This removes a bunch of redundant text in the spec. The validation process is now written as an algorithm, as is the signing process. It makes it easy now to generate or validate a signature by simply following the steps. In the old spec, one had to jump all over the spec to check all sorts of things (e..g, Common Constraints for Signature Generation and Validation and the Requirements on Widget Signatures, both which are now folded into the appropriate algorithms). The spec now also links to the right places in [XMLDSIG11] and [Signature Properties]. 3. The specification now only RECOMMENDs algorithms, key lengths, and certificate formats. Validators are no longer forced fail on certain certificate formats or algorithm. The only exception is the minimum key lengths, which are still enforced during verification (impossible to test during signing, without verifying, so the requirement is kinda useless). 4. The specification strengthens the recommended key lengths to be a little bit stronger (buy a few more years). 5. The spec now only contains 3 conformance criteria. [ To digitally sign the contents of a widget package with an author signature, a signer MUST run the algorithm to generate a digital signature. To digitally sign the contents of a widget package with a distributor signature, a signer MUST run the algorithm to generate a digital signature. To validate the siganture files of a widget package, a validator MUST run the algorithm to validate digital signatures. ] I think everyone will now find this new specification much easier to read, implement, and conform to without having in real impact on existing implementations. Kind regards, Marcos
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
Re: [widgets] Dig Sig spec
Marcos I'd suggest you first send an email with the top 10 substantive changes to the list, e.g. which algorithms change from mandatory to optional or optional to mandatory etc, which processing rules you are relaxing, etc this would take less time for you and be much clearer to all. thanks regards, Frederick Frederick Hirsch Nokia On Apr 26, 2011, at 8:19 AM, ext Marcos Caceres wrote: On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote: Well, you started with a relatively ambiguous characterization of a need to eliminate redundancies and inconsistencies and now I see you think the spec as written has resulted in willful violations of the spec and of course those are quite different. Correct. But one really led to the other. The reality is that very few people who implemented the spec really read the spec in detail. Most people seemed to have been working from the examples. This is normal and to be expected. Cleaning it up a bit should make it easier to follow. Since this spec is in the Candidate state (and as such, perhaps already deployed), I think it would be helpful if you would please flesh out all the changes and bug(s) you propose must be fixed ^1. Then we should be able to have a more informed discussion re if it's OK to have a go at rewriting. I'm ok with that, but would prefer to do it like this: 1. make a mirror copy of the spec. 2. make all the edits I think need to be made. It's not many, as the spec is relatively small (~14 pages). 3. make a diff of the two documents to build the list of changes. 4. propose the complete list of changes to the group. 5. let the group decide which changes they accept or reject or need further discussion. If the new spec is take wholesale, then great. Otherwise, it's easy to backtrack on proposed changes. This is how I've done this kinds of changes in the past and it's always worked out ok.
Re: [widgets] Dig Sig spec
Hi Marcos, On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote: I've been reviewing and trying to implement the widgets dig sig spec and I'm finding that there is a lot of redundancies and inconsistencies with the way it is written. Although the conformance requirements are fairly clear, the main problem is that the spec is a bit confused when it comes to algorithms and processing. It also states things that really should just be deferred to XML Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with the goal of making it simpler to implement. Unless there are some relatively major bugs in the spec that are affecting interoperability, then I wouldn't recommend doing that. There are real costs for this proposal: for implementors and developers to review new WDs, external groups to consider (e.g. XML Security WG, WAC) as well as the WG's overhead of processing new publication requests. If folks have resources to spare on the Widgets specs, it seems like the higher priority would be to complete work already started. -Art Barstow
Re: [widgets] Dig Sig spec
On Tuesday, April 26, 2011 at 1:13 PM, Arthur Barstow wrote: Hi Marcos, On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote: I've been reviewing and trying to implement the widgets dig sig spec and I'm finding that there is a lot of redundancies and inconsistencies with the way it is written. Although the conformance requirements are fairly clear, the main problem is that the spec is a bit confused when it comes to algorithms and processing. It also states things that really should just be deferred to XML Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with the goal of making it simpler to implement. Unless there are some relatively major bugs in the spec that are affecting interoperability, then I wouldn't recommend doing that. There are real costs for this proposal: for implementors and developers to review new WDs, external groups to consider (e.g. XML Security WG, WAC) as well as the WG's overhead of processing new publication requests. I understand the costs to implementers, but I'm not proposing to radically change the conformance requirements of the specification (which will remain the same except were things are clearly broken). The major bugs in the spec are to do with the unnecessary restrictions that the spec imposes wrt canonicalization and other algorithms and signature formats. WAC already willfully violated the canonicalization requirement in WAC 1, which shows the spec is broken. I propose to fix this by increasing the reliance on XMLDigSig 1.1 for validation and generation and making the spec only recommend certain formats, algorithms, and key lengths. This will make the specification a proper profile of XML DigSig 1.1, which currently it is not. It will also allow WAC 1.0 runtimes to conform to the spec without impacting future WAC versions. If folks have resources to spare on the Widgets specs, it seems like the higher priority would be to complete work already started. My opinion is that this spec is too important to leave it in its current state.
Re: [widgets] Dig Sig spec
On Apr/26/2011 7:40 AM, ext Marcos Caceres wrote: On Tuesday, April 26, 2011 at 1:13 PM, Arthur Barstow wrote: Hi Marcos, On Apr/25/2011 11:53 AM, ext Marcos Caceres wrote: I've been reviewing and trying to implement the widgets dig sig spec and I'm finding that there is a lot of redundancies and inconsistencies with the way it is written. Although the conformance requirements are fairly clear, the main problem is that the spec is a bit confused when it comes to algorithms and processing. It also states things that really should just be deferred to XML Dig Sig 1.1. If it's ok with everyone, I want to have a go at rewriting it with the goal of making it simpler to implement. Unless there are some relatively major bugs in the spec that are affecting interoperability, then I wouldn't recommend doing that. There are real costs for this proposal: for implementors and developers to review new WDs, external groups to consider (e.g. XML Security WG, WAC) as well as the WG's overhead of processing new publication requests. I understand the costs to implementers, but I'm not proposing to radically change the conformance requirements of the specification (which will remain the same except were things are clearly broken). The major bugs in the spec are to do with the unnecessary restrictions that the spec imposes wrt canonicalization and other algorithms and signature formats. WAC already willfully violated the canonicalization requirement in WAC 1, which shows the spec is broken. I propose to fix this by increasing the reliance on XMLDigSig 1.1 for validation and generation and making the spec only recommend certain formats, algorithms, and key lengths. This will make the specification a proper profile of XML DigSig 1.1, which currently it is not. It will also allow WAC 1.0 runtimes to conform to the spec without impacting future WAC versions. If folks have resources to spare on the Widgets specs, it seems like the higher priority would be to complete work already started. My opinion is that this spec is too important to leave it in its current state. Well, you started with a relatively ambiguous characterization of a need to eliminate redundancies and inconsistencies and now I see you think the spec as written has resulted in willful violations of the spec and of course those are quite different. Since this spec is in the Candidate state (and as such, perhaps already deployed), I think it would be helpful if you would please flesh out all the changes and bug(s) you propose must be fixed ^1. Then we should be able to have a more informed discussion re if it's OK to have a go at rewriting. -AB ^1 presumably you should use Tracker since it is already being used for the widget specs
Re: [widgets] Dig Sig spec
On Tuesday, April 26, 2011 at 2:02 PM, Arthur Barstow wrote: Well, you started with a relatively ambiguous characterization of a need to eliminate redundancies and inconsistencies and now I see you think the spec as written has resulted in willful violations of the spec and of course those are quite different. Correct. But one really led to the other. The reality is that very few people who implemented the spec really read the spec in detail. Most people seemed to have been working from the examples. This is normal and to be expected. Cleaning it up a bit should make it easier to follow. Since this spec is in the Candidate state (and as such, perhaps already deployed), I think it would be helpful if you would please flesh out all the changes and bug(s) you propose must be fixed ^1. Then we should be able to have a more informed discussion re if it's OK to have a go at rewriting. I'm ok with that, but would prefer to do it like this: 1. make a mirror copy of the spec. 2. make all the edits I think need to be made. It's not many, as the spec is relatively small (~14 pages). 3. make a diff of the two documents to build the list of changes. 4. propose the complete list of changes to the group. 5. let the group decide which changes they accept or reject or need further discussion. If the new spec is take wholesale, then great. Otherwise, it's easy to backtrack on proposed changes. This is how I've done this kinds of changes in the past and it's always worked out ok.
