<br>Hi Hans,<br><br>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.<br><br>
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).<br>
<br>Maybe this simpler approach will fit for message exchange.<br><br>Best regards <br><br>Dave Garcia <br><br><br><div class="gmail_quote">2009/6/11 Hans Granqvist <span dir="ltr"><<a href="mailto:hans@granqvist.com">hans@granqvist.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Perhaps someone from VeriSign (Barry? Gary?) can comment on the viability of<br>
<a href="http://xmlsig.sourceforge.net/" target="_blank">http://xmlsig.sourceforge.net/</a><br>
<font color="#888888"><br>
Hans<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Wed, Jun 10, 2009 at 11:54 PM, John Panzer<<a href="mailto:jpanzer@acm.org">jpanzer@acm.org</a>> wrote:<br>
> My general impression is that something that requires two pieces of software<br>
> to agree on an exact, bit for bit infoset representation of an XML document<br>
> in order to get security to work is a poor idea. I have seen no wide<br>
> deployments/usage of DSig in Atom feeds -- despite it being part of the spec<br>
> -- and many complaints about how it's not possible to get it to work<br>
> reliably given the software stacks currently in use. The difficulties with<br>
> canonicalization-for-signing in OAuth implementations have also reinforced<br>
> my belief that it's much better to err on the side of the robust and simple.<br>
><br>
> Signing a stream of uninterpreted bytes cuts out a whole slew of failure<br>
> modes, and the ones that remain are debuggable -- the bytes match or they<br>
> don't, and standard tools can tell you which. It means it's possible to<br>
> verify a signature with curl + a command line utility. These are all very<br>
> good things.<br>
><br>
> (As a side note, it would also make the content type orthogonal to the<br>
> signature code -- this is a good thing.)<br>
><br>
> So, +1 for the simplest form of signing that could possibly work.<br>
><br>
> -John<br>
><br>
><br>
> Johannes Ernst wrote:<br>
><br>
> I proposed something I called XML-RSig for similar reasons a few years ago:<br>
> <a href="http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html" target="_blank">http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html</a><br>
><br>
> "RSig" for "Really simple Signature".<br>
><br>
> The trouble for OpenID and XRD and so forth is that it is not our core<br>
> competency -- and shouldn't be -- to innovate around things that really<br>
> aren't our business. Signing XML documents isn't our business.<br>
><br>
> On the other hand, the people whose business it should be somehow seem to be<br>
> asleep at the wheel, as the problems are well-known and somehow aren't being<br>
> addressed, and haven't for years.<br>
><br>
> It seems to me that the best way out of this conundrum is:<br>
> 1. to foresee, architecturally, the use of several different ways of<br>
> constructing signatures, as the matter clearly isn't settled<br>
> 2. to make sure that high-end approaches (like XML-DSIG) work well, but<br>
> low-end approaches (like XML-RSIG) work just as well<br>
> 3. to maintain a best practices document that says "today, choice X is your<br>
> best bet, and we say that because based on our market research, X has the<br>
> highest market share in terms of implementors today."<br>
><br>
> As we all know, any problem in computer science can be solved by adding a<br>
> level of indirection. This may well be one of those cases.<br>
><br>
><br>
><br>
><br>
><br>
> Johannes Ernst<br>
> NetMesh Inc.<br>
><br>
><br>
> ________________________________<br>
><br>
><br>
><br>
> ________________________________<br>
><br>
> <a href="http://netmesh.info/jernst" target="_blank">http://netmesh.info/jernst</a><br>
><br>
><br>
><br>
> ________________________________<br>
> _______________________________________________<br>
> specs mailing list<br>
> <a href="mailto:specs@openid.net">specs@openid.net</a><br>
> <a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
><br>
><br>
> _______________________________________________<br>
> specs mailing list<br>
> <a href="mailto:specs@openid.net">specs@openid.net</a><br>
> <a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
><br>
><br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@openid.net">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>David Garcia<br>CTO<br><br>Tractis - Online contracts you can enforce<br><a href="http://www.tractis.com">http://www.tractis.com</a><br>--<br>Tel: (34) 93 551 96 60 (ext. 260) <br>
<br>Email: <a href="mailto:david.garcia@tractis.com">david.garcia@tractis.com</a><br>Blog: <a href="http://blog.negonation.com">http://blog.negonation.com</a><br>Twitter: <a href="http://twitter.com/tractis">http://twitter.com/tractis</a><br>