OpenSAML java withcomments canonicalization

[Bob Jacoby]

Scott,

Thanks for you reply. I don't think I fully understand it so sorry if
you've already answered this question and I just don't realize it...

Based on https://issues.shibboleth.net/jira/projects/OSJ/issues/OSJ-230 I
understand that I can't specify the transform c14n algorithm, and that c14n
w/o comments is always used when signing in openSAML. I'm trying to
understand the reverse. Suppose I try to use openSAML to validate a
signature (e.g. generated by some other library that does allow c14n w/
comments as the transform) that produced the following:

<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/
2001/10/xml-exc-c14n#WithComments"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#73651ce4-0ee9-4452-b063-c70657fb99dc">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-
signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments
"><ec:InclusiveNamespaces PrefixList="xsd" xmlns:ec="http://www.w3.org/
2001/10/xml-exc-c14n#"/></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>MVm6t//vsyxMT7jt1KJl6Ef1G6Ie+f5ewTi54CHV4D8=</ds:
DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
EvT1KHe0o2h1pqtgQ7QsjTBJfoopDPgTgR7s1IY7asCxzYWdr95re290xwTPibMsxids36VYYcb1
S5UoXhUY2OCF4KXrWmyY2OVvDbGtKwW1QDTmzx1jaZCuOj+RPdtQaJVWg6YSwQFA7KlkyGtRvASb
nBmh2OkszTHGhB9dkPE=
</ds:SignatureValue>
</ds:Signature>

When the digest of ref #73651ce4-0ee9-4452-b063-c70657fb99dc is
recalculated for validation purposes within openSAML, will the c14n w/
comments algorithm specified in the transform be used or will c14n w/o
comments be used?

Best,
Bob


On Thu, Mar 1, 2018 at 8:25 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Is this as expected?
>
> No, I don't really believe that's possible. It might be in a case where
> the final transform in the chain produced a node set, but with a second
> transform doing c14n, it should be an octet stream and that shouldn't
> undergo any further c14n.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20180301/c11b19ca/attachment.html>