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 -~----------~----~----~----~------~----~------~--~---
