Perhaps someone from VeriSign (Barry? Gary?) can comment on the viability of http://xmlsig.sourceforge.net/
Hans On Wed, Jun 10, 2009 at 11:54 PM, John Panzer<jpan...@acm.org> wrote: > My general impression is that something that requires two pieces of software > to agree on an exact, bit for bit infoset representation of an XML document > in order to get security to work is a poor idea. I have seen no wide > deployments/usage of DSig in Atom feeds -- despite it being part of the spec > -- and many complaints about how it's not possible to get it to work > reliably given the software stacks currently in use. The difficulties with > canonicalization-for-signing in OAuth implementations have also reinforced > my belief that it's much better to err on the side of the robust and simple. > > Signing a stream of uninterpreted bytes cuts out a whole slew of failure > modes, and the ones that remain are debuggable -- the bytes match or they > don't, and standard tools can tell you which. It means it's possible to > verify a signature with curl + a command line utility. These are all very > good things. > > (As a side note, it would also make the content type orthogonal to the > signature code -- this is a good thing.) > > So, +1 for the simplest form of signing that could possibly work. > > -John > > > Johannes Ernst wrote: > > I proposed something I called XML-RSig for similar reasons a few years ago: > http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html > > "RSig" for "Really simple Signature". > > The trouble for OpenID and XRD and so forth is that it is not our core > competency -- and shouldn't be -- to innovate around things that really > aren't our business. Signing XML documents isn't our business. > > On the other hand, the people whose business it should be somehow seem to be > asleep at the wheel, as the problems are well-known and somehow aren't being > addressed, and haven't for years. > > It seems to me that the best way out of this conundrum is: > 1. to foresee, architecturally, the use of several different ways of > constructing signatures, as the matter clearly isn't settled > 2. to make sure that high-end approaches (like XML-DSIG) work well, but > low-end approaches (like XML-RSIG) work just as well > 3. to maintain a best practices document that says "today, choice X is your > best bet, and we say that because based on our market research, X has the > highest market share in terms of implementors today." > > As we all know, any problem in computer science can be solved by adding a > level of indirection. This may well be one of those cases. > > > > > > Johannes Ernst > NetMesh Inc. > > > ________________________________ > > > > ________________________________ > > http://netmesh.info/jernst > > > > ________________________________ > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > > _______________________________________________ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
