4 ms·

> 'what if you wanted to only sign part of a document' and 'what if, after signing, the document was processed by something that reordered the attributes' Thos

> 'what if you wanted to only sign part of a document' and 'what if, after signing, the document was processed by something that reordered the attributes' Those use cases are valid. The second one is actually the reason why JSON can't be used for a similarly usage (there is not canonization standard, and reading then writing a file could reorder the elements order).

tptacek 5y ago
The problem isn't that there's no valid use case for it; it's that there's no use case for it in SAML, just as there's no valid SAML use case for XML comments (which also broke SAML). You can defend DSIG in a lot of different ways. I'll disagree with all of them and feel like I could probably win the argument; DSIG is a cursed standard. But that's not the bar you have to clear in this discussion; here you have to establish that DSIG is good for SAML. It clearly isn't.
- stouset 5y ago
  I might be wrong but I vaguely remember that something like “all” of the popular open source SAML libraries in the wild were vulnerable due to DSIG mishandling circa 2012. They’d blindly accept any document as valid as long as there was a signature in place that signed some element, but didn’t bother to check that that element was the set of assertions actually being used.
  - rb12345 5y ago
    There were similar issues more recently (2018/19) with custom XML entities or comments. The XML signature was unaffected, but if code used the equivalent of element.children[0] to get the contents, it was possible for attackers to truncate the attribute values seen by the service provider library.
  - tptacek 5y ago
    Yep. You still find variants of that today.
formerly_proven 5y ago
The latter is not a valid use case for anything using signatures, because it² is virtually impossible to implement correctly. The former might be important for something? But generally also very nearly impossible to do correctly. When that is the case, one should contemplate whether the actual business requirements can be fulfilled another way, instead of making things broken by design. ² "canonicalize-encode-sign" as opposed to the correct way of "sign blob, parse blob".

tptacek 5y ago

The problem isn't that there's no valid use case for it; it's that there's no use case for it in SAML, just as there's no valid SAML use case for XML comments (which also broke SAML). You can defend DSIG in a lot of different ways. I'll disagree with all of them and feel like I could probably win the argument; DSIG is a cursed standard. But that's not the bar you have to clear in this discussion; here you have to establish that DSIG is good for SAML. It clearly isn't.

stouset 5y ago
I might be wrong but I vaguely remember that something like “all” of the popular open source SAML libraries in the wild were vulnerable due to DSIG mishandling circa 2012. They’d blindly accept any document as valid as long as there was a signature in place that signed some element, but didn’t bother to check that that element was the set of assertions actually being used.
- rb12345 5y ago
  There were similar issues more recently (2018/19) with custom XML entities or comments. The XML signature was unaffected, but if code used the equivalent of element.children[0] to get the contents, it was possible for attackers to truncate the attribute values seen by the service provider library.
- tptacek 5y ago
  Yep. You still find variants of that today.

formerly_proven 5y ago

The latter is not a valid use case for anything using signatures, because it² is virtually impossible to implement correctly. The former might be important for something? But generally also very nearly impossible to do correctly. When that is the case, one should contemplate whether the actual business requirements can be fulfilled another way, instead of making things broken by design. ² "canonicalize-encode-sign" as opposed to the correct way of "sign blob, parse blob".