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
