Hi Nat,<br><br>yes you're right most of those impls are wrappers over aleksey's xmlsec library. <br>Using wrappers requires systems running those services to have xmlsec lib installed. <br>
<br>Most unix like distros are shipped with this xmlsec and if not it could be downloaded from the aleksey site (<a href="http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.9.tar.gz">http://www.aleksey.com/xmlsec/download/xmlsec1-1.2.9.tar.gz</a>).<br>
<br>Processing on xmlsignature is not very complex, but transforms like c14n are.<br><br>So most complex processes are to perform those transformation processes that are complicated to implement and very aggressive on computation requirements.<br>
<br>As I said yesterday this morning I made a comparative of some available options and what I've liked most is <a href="http://xmlsig.sourceforge.net/">http://xmlsig.sourceforge.net/</a> <br><br>This lib provides a set of wrappers over xmlsec made available using swig. Those bindings that are suposed to work in php, python and ruby. I tested the ruby version.<br>
<br>Installation requires libxml, libsxlt, swig and libxmlsec including their -dev packages. I have to fix some include paths on building because make didn't find header files from those libs.<br> <br>I started the process from the scratch and took me less than 1 hour to have ruby code performing enveloped/enveloping signature creation and validation (only crypto validation no certificate validation process is included).<br>
<br>I submit the code I created to have a message signer/validator. The examples available on the test directory from the lib are awesome to know how to perform signing and verification primitives calls.<br><br>So my point of view about using pure dynamic libs or libs creating a bridge over C libs is depend. Pure dynamic libs are easier to deploy but in some cases like openssl, xml processing or in this case xml signature (core tasks) bridging could be a good alternative.<br>
<br>I post here my sample code on ruby. I got it working on Ubuntu running on amd64 and debian running on power g4 but the doc claims the lib working on most UNIX like systems including MacOSX and Windows.<br><br>Hope this helps :)<br>
<br>Best regards<br><br>Dave <br><br>require 'xmlsig'<br>class MessageSigner<br><br>def self.sign_message(message , xpath = nil)<br> x = Xmlsig::XmlDoc.new<br> x.loadFromString(message)<br><br> private_key = Xmlsig::Key.new<br>
private_key.loadFromFile('rsakey.pem','pem','')<br><br> signing_certificate = Xmlsig::Signer.new(x,private_key)<br> signing_certificate.addCertFromFile('rsacert.pem', 'pem')<br>
<br> if (xpath.nil?)<br> signed_signature = signing_certificate.sign<br> return signed_signature.toString<br> else<br> xp = Xmlsig::XPath.new<br> xp.setXPath(xpath)<br> signing_certificate.signInPlace(xp)<br>
return x.toString <br> end <br>end<br><br>def self.verify_message(signed_message)<br> to_be_verified = Xmlsig::XmlDoc.new<br> to_be_verified.loadFromString(signed_message)<br> <br> #Assuming a single signature per message <br>
xp = Xmlsig::XPath.new()<br> xp.addNamespace('ds', '<a href="http://www.w3.org/2000/09/xmldsig#">http://www.w3.org/2000/09/xmldsig#</a>')<br> xp.setXPath('/descendant::ds:Signature[position()=1]')<br>
v = Xmlsig::Verifier.new(to_be_verified,xp)<br> valid = v.verify<br><br> return valid == 1<br>end<br><br>message = "<Message>message content </Message>"<br><br><br>#Second param is xpath. <br>
#If not provided signature will be enveloping, this is signed message will be embeded inside ds:Object node<br>#Providing Xpath will result in the signature being embeded inside the message to be signed, that is an enveloped signature<br>
signed_message = sign_message(message, "/Message")<br><br><br>valid = verify_message(signed_message)<br><br>puts "Signature #{valid ? "is" : "isn't"} valid!"<br><br>#Trying to cheat the signature validator<br>
signed_message = signed_message.gsub(/content/, "other content")<br>valid = verify_message(signed_message)<br><br>puts "Signature #{valid ? "is" : "isn't"} valid!"<br><br>end<br>
<br><div class="gmail_quote">2009/6/13 Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.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;">
Thanks David, <div><br></div><div>One of the issue that has been raised was that much of those scripting languages implementation actually calls C++ library to do the task. This makes it difficult to deploy it in some hosting and PaaS environment, so libs written in that scripting language is sought. </div>
<div><br></div><div>If it is not there, then we need to evaluate how easy is it to do that, and perhaps create a project to make them. </div><div><br></div><div>Cheers, </div><div><br></div><div><font color="#888888">=nat</font><div>
<div></div><div class="h5"><br><br><div class="gmail_quote">
On Sat, Jun 13, 2009 at 3:01 AM, David Garcia <span dir="ltr"><<a href="mailto:davebcn@gmail.com" target="_blank">davebcn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
Sure I'll do it, but let me make an in-depth analisis of alternatives before pointing to a concrete implementation.<br>
<br>
I'll rebrowse sources to make those checks this weekend.<br>
<br>
Best regards<br>
<br>
David Garcia<br>
<br>
El 12/06/2009, a las 19:19, Tatsuki Sakushima <<a href="mailto:tatsuki@nri.com" target="_blank">tatsuki@nri.com</a>> escribió:<div><div></div><div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi David,<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I completely agree with you, a single technology for those closely related protocols would be better than forking. The main advantage using XMLdSIG is that there are a huge amount of services currently working with this technology. As far as I know there are mature libs for C, C++, Java, .net, python, ruby, php .<br>
</blockquote>
<br>
Can you navigate us to some libraries you have seen especially for those scripting languages, python, ruby, and php? So some of us including me can test them and see how they works. Some forks expertizing XML says XML DSig with exclusive c14n is "easy enough", but many of us haven't seen the real example in scripting languages. And if it is easy or not is somewhat subjective. I think showing examples will facilitate this discussion.<br>
<br>
Best,<br>
Tatsuki<br>
<br>
Tatsuki Sakushima<br>
NRI Pacific - Nomura Research Institute America, Inc.<br>
<br>
(6/12/09 1:48 AM), David Garcia wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Nat,<br>
I completely agree with you, a single technology for those closely related protocols would be better than forking. The main advantage using XMLdSIG is that there are a huge amount of services currently working with this technology. As far as I know there are mature libs for C, C++, Java, .net, python, ruby, php .<br>
Those libs are compliant with xmldsig interopt tests so this give us warranties about their intertoperability. Message sign and verify primitives are very simple from the point of view of the developer and the only problem arises when trying to verify the signer certificate (path building, validation, status validation vs CRL and OCSP...) but several "tricks" could be made here to keep the process simple.<br>
I'll feel very comfortable about using XMLdSIG because from the point of view of the increase of complexity it won't be as easy as raw data processing, but it won't be very painful if we use those sets of libs.<br>
If you want maybe we can create a little project for a proof of concept and make an interop between 2 different technologies signing and verifying messages. If so please let me know :).<br>
Best regards<br>
Dave<br>
2009/6/12 =nat <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a> <mailto:<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>><br>
Hi.<br>
Thanks for your great feedback.<br>
It is kind of interesting that OpenID side wants the simplest form while<br>
in the OAuth list, XML DSig is liked better somehow.<br>
>From the spec point of view, it is better to not to fork as much as<br>
possible,<br>
so if we can stick to XML DSig, that's great.<br>
Now, here is another question then.<br>
If libraries with decent API becomes available to each language,<br>
written in that language, and is tested for compatibility to each other,<br>
would you be amiable to this constrained form of XML DSig?<br>
=nat<br>
On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia<br>
<<a href="mailto:david.garcia@tractis.com" target="_blank">david.garcia@tractis.com</a> <mailto:<a href="mailto:david.garcia@tractis.com" target="_blank">david.garcia@tractis.com</a>>><br>
wrote:<br>
> Hi Hans,<br>
><br>
> this project offers a set of wrappers over xmlsec library used on<br>
many<br>
c++<br>
> envs. I used it a lot and their equivalent in Java for some years on<br>
> critical production envs and they're very mature.<br>
><br>
> Dealing with xml data as opaque bits (a simplified xml version of CMS<br>
> signature containers) instead of interpreting the infoset as proposed<br>
will<br>
> be a much simpler approach because it eliminates the need of<br>
using c14n<br>
> and<br>
> transform algorithms (not mandatory but recommended on some<br>
scenarios).<br>
><br>
> Maybe this simpler approach will fit for message exchange.<br>
><br>
> Best regards<br>
><br>
> Dave Garcia<br>
><br>
><br>
> 2009/6/11 Hans Granqvist <<a href="mailto:hans@granqvist.com" target="_blank">hans@granqvist.com</a><br>
<mailto:<a href="mailto:hans@granqvist.com" target="_blank">hans@granqvist.com</a>>><br>
><br>
>> Perhaps someone from VeriSign (Barry? Gary?) can comment on the<br>
> viability<br>
>> of<br>
>> <a href="http://xmlsig.sourceforge.net/" target="_blank">http://xmlsig.sourceforge.net/</a><br>
>><br>
>> Hans<br>
>><br>
>><br>
>><br>
>> On Wed, Jun 10, 2009 at 11:54 PM, John Panzer<<a href="mailto:jpanzer@acm.org" target="_blank">jpanzer@acm.org</a><br>
<mailto:<a href="mailto:jpanzer@acm.org" target="_blank">jpanzer@acm.org</a>>> wrote:<br>
>> > My general impression is that something that requires two<br>
pieces of<br>
>> software<br>
>> > to agree on an exact, bit for bit infoset representation of an XML<br>
>> document<br>
>> > in order to get security to work is a poor idea. I have seen<br>
no wide<br>
>> > deployments/usage of DSig in Atom feeds -- despite it being<br>
part of<br>
> the<br>
>> spec<br>
>> > -- and many complaints about how it's not possible to get it<br>
to work<br>
>> > reliably given the software stacks currently in use. The<br>
difficulties<br>
>> with<br>
>> > canonicalization-for-signing in OAuth implementations have also<br>
>> reinforced<br>
>> > my belief that it's much better to err on the side of the<br>
robust and<br>
>> simple.<br>
>> ><br>
>> > Signing a stream of uninterpreted bytes cuts out a whole slew of<br>
> failure<br>
>> > modes, and the ones that remain are debuggable -- the bytes<br>
match or<br>
> they<br>
>> > don't, and standard tools can tell you which. It means it's<br>
possible<br>
> to<br>
>> > verify a signature with curl + a command line utility. These<br>
are all<br>
>> very<br>
>> > good things.<br>
>> ><br>
>> > (As a side note, it would also make the content type<br>
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<br>
few years<br>
>> ago:<br>
>> ><br>
>><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<br>
our core<br>
>> > competency -- and shouldn't be -- to innovate around things that<br>
> 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<br>
somehow seem<br>
> to<br>
>> be<br>
>> > asleep at the wheel, as the problems are well-known and<br>
somehow aren't<br>
>> 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<br>
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<br>
well,<br>
> but<br>
>> > low-end approaches (like XML-RSIG) work just as well<br>
>> > 3. to maintain a best practices document that says "today,<br>
choice X is<br>
>> your<br>
>> > best bet, and we say that because based on our market<br>
research, X has<br>
> 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<br>
> 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" target="_blank">specs@openid.net</a> <mailto:<a href="mailto:specs@openid.net" target="_blank">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" target="_blank">specs@openid.net</a> <mailto:<a href="mailto:specs@openid.net" target="_blank">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" target="_blank">specs@openid.net</a> <mailto:<a href="mailto:specs@openid.net" target="_blank">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>
><br>
> --<br>
> David Garcia<br>
> CTO<br>
><br>
> Tractis - Online contracts you can enforce<br>
> <a href="http://www.tractis.com" target="_blank">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" target="_blank">david.garcia@tractis.com</a> <mailto:<a href="mailto:david.garcia@tractis.com" target="_blank">david.garcia@tractis.com</a>><br>
> Blog: <a href="http://blog.negonation.com" target="_blank">http://blog.negonation.com</a><br>
> Twitter: <a href="http://twitter.com/tractis" target="_blank">http://twitter.com/tractis</a><br>
-- <br>
David Garcia<br>
CTO<br>
Tractis - Online contracts you can enforce<br>
<a href="http://www.tractis.com" target="_blank">http://www.tractis.com</a><br>
--<br>
Tel: (34) 93 551 96 60 (ext. 260)<br>
Email: <a href="mailto:david.garcia@tractis.com" target="_blank">david.garcia@tractis.com</a> <mailto:<a href="mailto:david.garcia@tractis.com" target="_blank">david.garcia@tractis.com</a>><br>
Blog: <a href="http://blog.negonation.com" target="_blank">http://blog.negonation.com</a><br>
Twitter: <a href="http://twitter.com/tractis" target="_blank">http://twitter.com/tractis</a><br>
------------------------------------------------------------------------<br>
_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
</blockquote></blockquote>
</div></div></blockquote></div><br><br clear="all"><br></div></div><div class="im">-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</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>