You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #498, we added newline normalization before signature validation in validateSignatureForCert. The suggestion for this fix came from #431 (comment); however, I don't believe this fix goes deep enough into newline normalization.
While this fix normalizes newlines right before the signature validation, it doesn't normalize newlines in the XML payload that is passed to sig.loadSignature. As a result, the sig.getCanonSignedInfoXml that is part of sig.checkSignature encodes carriage returns into 
, and the signature computed from that canonicalized SignedInfo XML is incorrect.
** Spec-driven development **
This is related to the XML spec for newlines mentioned here: #431 (comment)
** Community development model **
PR to come
To Reproduce
Add a newline to response.root-signed.assertion-signed.xml inside the Signature block.
Re-run test-signatures.js and see that R1A - both signed => valid fails, as expected, since the signature should be different now that the XML is different.
Compute the correct digests and signatures for this modified file and update them in DigestValue and SignatureValue
Re-run test-signatures.js and see that all tests pass except for CRLF line endings and CR line endings.
Expected behavior
XML payloads with non-LF line endings should have the same digest and signature values as the same XML payload with LF line endings, and it is up to the XML processor to normalize line endings to ensure that (#431 (comment))
Environment
Node.js version: 14.15.1
passport-saml version: 2.0.2
The text was updated successfully, but these errors were encountered:
In #498, we added newline normalization before signature validation in
validateSignatureForCert
. The suggestion for this fix came from #431 (comment); however, I don't believe this fix goes deep enough into newline normalization.While this fix normalizes newlines right before the signature validation, it doesn't normalize newlines in the XML payload that is passed to
sig.loadSignature
. As a result, thesig.getCanonSignedInfoXml
that is part ofsig.checkSignature
encodes carriage returns into
, and the signature computed from that canonicalized SignedInfo XML is incorrect.** Spec-driven development **
This is related to the XML spec for newlines mentioned here: #431 (comment)
** Community development model **
PR to come
To Reproduce
response.root-signed.assertion-signed.xml
inside theSignature
block.test-signatures.js
and see thatR1A - both signed => valid
fails, as expected, since the signature should be different now that the XML is different.DigestValue
andSignatureValue
test-signatures.js
and see that all tests pass except forCRLF line endings
andCR line endings
.Expected behavior
XML payloads with non-LF line endings should have the same digest and signature values as the same XML payload with LF line endings, and it is up to the XML processor to normalize line endings to ensure that (#431 (comment))
Environment
The text was updated successfully, but these errors were encountered: