Expose signing parameter to control ContentReference c14n algorithm
Description
Environment
Activity
Brent PutmanSeptember 12, 2018 at 1:39 AM
Added in a2921ae5a69931afc98d5713f91894b3c0c958f2.
Brent PutmanSeptember 6, 2018 at 3:34 AM
I have this mostly implemented. Only thing pending is adding support to the SignatureSigningConfiguration and -Resolver impls to support the new parameter.
It's a little weird and different than the reference digest one, since the C14N is just one of many possible list of transforms. So have to traverse that list looking for an existing C14N and then replace or add as appropriate. Seems to work.
Scott CantorMarch 1, 2018 at 5:05 PM
I don't exactly understand your question, but please take it to the dev list rather than JIRA.
Unidentified Legacy AccountMarch 1, 2018 at 5:03 PMEdited
Thanks, Scott. Does this impact validation of signatures that include a different algorithm as well? If a provided signed assertion specified c14n w/ comments as the transform, it would be ignored such that recomputing the digest would use c14n w/o comments? If so would this improvement address both sides - signing and validating?
Scott CantorMarch 1, 2018 at 2:19 PM
That's what I'm referring to. Shibboleth doesn't manually create content references, and the algorithms to use are computed out of a very complex merging process that allows for appropriate policy control and need to be fed into the layer that actually creates the content reference.There isn't a way to pass that in right now.
Some recent discoveries have demonstrated that there may be value in being able to selectively change the c14n algorithm used inside the Transforms chain of a SAML signature, which right now is hardwired to exclusive w/o comments by virtue of the ContentReference building logic.
We expose the top level c14n algorithm for SignedInfo, but not the embedded one.