Thanks guys for great feedback!
Now I am feeling better in sticking with XML DSig.
In the previous spec, we used XML DSig and turned out that
most people did not implement/use it. If the community feels
better about XML DSig now than several years ago,
that is very reassuring.
Thanks!
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
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
We pointed out the w3c recommendation referred here to the vendor.
Their explanation is different and I tend to agree. The recommendation
is for c14n. The prefix was changed in the process of embedding a
document into another one, that's rewriting, not c14n.
This prefix rewriting happens in
SimpleSign had the same key rotation issue. Their solution is to add
another Based-64 encoded KeyInfo. That's problematic for us because
KeyInfo is part of XMLDSig and it's not trivial to process without a
library. So we implemented it without KeyInfo. To get around the key
rotation issue, we
