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.

Received on Tuesday, 26 April 2011 11:40:53 UTC