Hi Hans, this project offers a set of wrappers over xmlsec library used on many c++ envs. I used it a lot and their equivalent in Java for some years on critical production envs and they're very mature.
Dealing with xml data as opaque bits (a simplified xml version of CMS signature containers) instead of interpreting the infoset as proposed will be a much simpler approach because it eliminates the need of using c14n and transform algorithms (not mandatory but recommended on some scenarios). Maybe this simpler approach will fit for message exchange. Best regards Dave Garcia 2009/6/11 Hans Granqvist <[email protected]> > 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<[email protected]> 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 > > [email protected] > > http://openid.net/mailman/listinfo/specs > > > > > > _______________________________________________ > > specs mailing list > > [email protected] > > http://openid.net/mailman/listinfo/specs > > > > > _______________________________________________ > specs mailing list > [email protected] > http://openid.net/mailman/listinfo/specs > -- David Garcia CTO Tractis - Online contracts you can enforce http://www.tractis.com -- Tel: (34) 93 551 96 60 (ext. 260) Email: [email protected] Blog: http://blog.negonation.com Twitter: http://twitter.com/tractis
_______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
