> I also think it's a mistake for XMLSig and similar specs to > require only one > or two algorithms be supported. It's a recipe for a big mess > later, seems to > me.
Interesting point. If one of the required algorithms is really broken, it may be difficult to reach consensus on what to use in its place. Implementation A may support algorithm 1 but not algorithm 2, while implementation B supports 2 but not 1, and the two no longer interoperate. Is this the sort of thing you're concerned about? If so, I'm not sure what can be done about it. The algorithms that are available to be included in specifications today may be cracked tomorrow. Maybe what's needed is a formal process for incorporating new required algorithms into the specifications that is less cumbersome than the normal specification process. (Of course, that process would have to be specified...) A thread on the W3C Dsig mailing list has begun to address the question of alternate algorithms (see http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2005JanMar/0030.htm l), but has not gotten very far (yet). Maybe you should chime in.
