My 2 cents: XML was designed as an information protocol, not a wire protocol, with multiple ways of representing the same canonical information. Why would you ever not canonicalize the data: are you sure the pipe between sender and receiver never have midpoints where, say, line breaks and carriage returns change?
The XML sig spec + libraries have had hundreds of man-year in the design and implementation and for example Java 6 has an XML signature library built in http://java.sun.com/developer/technicalArticles/xml/dig_signature_api/ BTW, xml namespaces carry information and should not be rewritten: http://www.w3.org/TR/xml-c14n#NoNSPrefixRewriting Hans On Wed, Jun 10, 2009 at 6:05 AM, Zhihong<[email protected]> wrote: > > We had some terrible experiences with XMLDSig a few years ago so we > switched to SimpleSign. The problem is with namespace prefixes. The > signature includes the prefixes and the prefixes can be changed. Say > you sign the SAML assertion with a prefix called "saml". Later the > assertion is put into a SAMLResponse which defines the same namespace > as "sa". When the whole thing is used in some other context (BEA Web > Services), the namespaces are optimized so "saml" is changed into "sa" > defined in outer layer and it messed up the signature. Back then, > there is a new c14n proposal to sign with full namespaces, not sure if > it went anywhere. > > Then we ran into a similar issue with SimpleSign. Firefox normalizes > line-break characters and I had to ask for a spec change to sign the > XML, instead of the Base64. > > The SimpleSign works for our use case (SAML Simple SSO profile) > because the XML is a Base64 BLOB already. For SXRD, XMLDSig seems to > be a better solution if you can rein in on the complexities of the > spec so you don't have to rely on the huge library like Apache XMLSec. > > Zhihong > > On Jun 10, 2:43 am, Nat Sakimura <[email protected]> wrote: >> Hi all: >> >> At XRI TC of OASIS Open, we are talking about the signing method for XRD. >> The current trend in the TC is that to use a constrained form of XML DSig, >> which is found in the SAML Core spec. We are almost deciding on it, >> but I would like to hear from the community that if it would be OK. >> >> The reason I ask this was that when we started to discuss the >> signing method for XRD back in November last year, we were >> hearing from the community that XML DSig is too complex and >> hard to use by some developers. That's why we came up with >> "Simple Sign" which basically signes the blob without any >> cannonicalization. >> >> e.g., >> >> <SXRD sig="signature" >> sigalg="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; certuri="pem file >> location" data="BASE64 of the payload" /> >> >> Where: >> >> - XRD/@data : Base64 encoded XRD to be signed. >> - XRD/@sig : Signature taken over the original data (before Base64 >> encoding). >> - XRD/@certuri: (Optional) Certificate location.Either XRD/@certuri or >> XRD/@certs MUST be present. >> - XRD/@certs : (Optional) The content of [email protected] both >> XRD/@certuri and XRD/@certs are present, XRD/@certs takes precidence. >> - XRD/@sigalg : (Optional) Signature Algorithm. Defaults to rsa-sha1. >> >> When we started writing spec on such thing, we found that we are re-writing >> a lot of things that are already in XML DSig. >> As the result, XML DSig with new canonicalization method=no-canonicalization >> was discussed and in the end, >> it seems the discussion precipitated to "After all, constrained XML DSig >> would be good enough." >> Theoretically, it looks good. >> >> The remaining question is then the reality check, such as: >> >> - Is it widely implementable, in each scripting language and hosting >> environment including Google AppEngine, Force.com, etc.? >> - Would the community feel that this is simple enough? >> >> I would appreciate your insight/opinion/input into this matter. >> >> Best, >> >> -- >> Nat Sakimura (=nat)http://www.sakimura.org/en/ > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
