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
