When we first started discussing the topic, we started off with something quite similar (in fact a little more simpler) than RSig. <div><br></div><div>The flow of our discussion over the last 6 months were like this: </div>
<div><br></div><div>The trait was like this.<br><br>1. XRDS has been using SAML constrained version
of XML DSig, but nobody<br>implemented it.<br> There has to be something
wrong in specifying this signature method.<br> (Also, we know that SAML XML
DSig created a lot of compatibility issues<br>in the field. )<br>2. We have
studied the current XML DSig implementations for script<br>languages, and<br>
found that in most case, we have to link the C libraries. This is no go<br>for
many hosting<br> environment, so we decided to make a simple alternative
"Simple Sign".<br>3. We came up with Simple Canonicalization + X.509(RSA-SHA)
Signature<br>method,<br> which can be implemented widely in many scripting
languages.<br>4. Even this Simple Canonicalization raised an issue of
comaptibility, so<br>decided to do<br> no Canonicalization at all.<br>5. This
seemed to require a detached signature, but it would not be able to<br>deal
with<br> sequence of XRDs. (Detached Sig)<br>6. Thus, we created SignedXRD
(SXRD) method so that it can be inline, which<br>is currently in<br> <a href="http://wiki.oasis-open.org/xri/XrdOne/SimpleSign">http://wiki.oasis-open.org/xri/XrdOne/SimpleSign</a><br><br>
<XRD sig="signature" sigalg="<a href="http://www.w3.org/2000/09/xmldsig#rsa-sha1">http://www.w3.org/2000/09/xmldsig#rsa-sha1</a>"<br>certuri="pem
file location" data="BASE64 of the payload" /><br><br>7. When writing a spec
for Detached Sig, it has been found that we are<br> rewriting a lot of what
has been in XML Dsig. Thus, XML Dsig with no<br>canonicalization was
explored.<br>8. Then, it was argued that SAML core ch.5 version of XML DSig is
simple<br>enough and there are scripting language implementations as
well, though they need<br>the C Libraries to be linked.<br>9. We are back
to the square ONE. (<= We are here.)</div><div><br></div><div>My main concern about XML DSig are as follows: </div><div><br></div><div>1. Perception: </div><div> If developers think it is too much, it is not going to be deployed. </div>
<div>2. Performance: </div><div> In Java 6, it is not an issue, but in the past, it seems it has been. </div><div>3. Support: </div><div> There are linkable C libraries for script languages, but are they deployed or </div>
<div> deployable? For example, I do not think that can be deployed on Google </div><div> AppEngine Python. (Or is it? Please let me know!)</div><div>4. If support is not there, is it easy to write your own? </div><div>
5. What about the performance then? </div><div><br></div><div>etc. </div><div><br></div><div>My Concern about Simple Sign only is </div><div><br></div><div>1. It is new: do people implement it? <br></div><div><br></div><div>
My Concern about supporting both are: </div><div><br></div><div>1. Is it going to be too much to ask library writers to support both XML Dsig and Simple Sign? <br></div><div><br></div><div>As a "ever indecisive" person, I tend to opt for "Both" option, but what do you guys think of it? </div>
<div><br></div><div>=nat<br><div><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 2:01 PM, Johannes Ernst <span dir="ltr"><jernst+<a href="http://openid.net">openid.net</a>@<a href="http://netmesh.us">netmesh.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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 competency -- and shouldn't be -- to innovate around things that really 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 asleep at the wheel, as the problems are well-known and somehow aren't being 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 constructing signatures, as the matter clearly isn't settled<br>
2. to make sure that high-end approaches (like XML-DSIG) work well, but 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 best bet, and we say that because based on our market research, X has the 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 level of indirection. This may well be one of those cases.<br><font color="#888888">
<br>
<br>
<br>
<br>
<br>
Johannes Ernst<br>
NetMesh Inc.<br>
<br>
</font><br> <br> <a href="http://netmesh.info/jernst" target="_blank">http://netmesh.info/jernst</a><br>
<br>
<br>
<br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>
</div></div>