shibd unable to verify signature when metadata is cached

Bradley Beddoes bradleybeddoes at aaf.edu.au
Mon Mar 21 23:26:59 EDT 2016


Scott,
Thanks for the investigation here.

I've also been able to confirm the `
` characters are the difference
between our published document and that persisted by shibboleth SP. oXygen
did a much better job than what I had previously in highlighting this,
thanks for suggesting it.

I'll go back to our metadata code and filter the extraneous CR before
signing to address this issue.

cheers,
Bradley



On Tue, Mar 22, 2016 at 12:36 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Part of c14n is to normalize linefeeds (to LF), and other part is to
> expand
> > character references.
>
> That's actually in the base XML spec. It's XML 1.1, but that hasn't
> changed, see section 2.11 of [1].
>
> You'll note that single 0D characters have to be converted to 0A. That's
> what happens here, so 0D 0D 0A ends up as 0A 0A (I'm guessing).
>
> The original source document has entity references in it, so if there's a
> bug, it may be that Xerces isn't actually converting the 0D that's in the
> entity reference. It's not immediately clear to me if it should be or not,
> but whatever it does do is apparently "correct" and consistent with the
> Java parser.
>
> The round trip to the backup file loses the entity references and at that
> point the extra 0D characters are clearly linefeed separators and are being
> normalized out. So they clearly aren't being normalized out during the
> initial parse. I'm guessing the IdP and Java code create the backup file by
> copying the bytes directly but I don't know for sure.
>
> I think the basic answer here is that my SP may not allow certain things
> to be done, more or less as a consequence of the design of the backup
> creation. It may be that you could use CDATA here and get it to work, but
> it really depends on the DOM, and I'm not sure that I preserve CDATA nodes
> either.
>
> It's certainly a bad idea to try and slip in extra CRs whether it's a bug
> or not.
>
> -- Scott
>
> [1] https://www.w3.org/TR/2004/REC-xml11-20040204/#sec-white-space
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
*Bradley Beddoes* | Technical Lead - Innovation, Software Development and
Infrastructure
*Australian Access Federation Inc*
*Web: http://www.aaf.edu.au <http://www.aaf.edu.au/> | Support:*
http://support.aaf.edu.au <http://www.aaf.edu.au/>

PRIVILEGED – PRIVATE AND CONFIDENTIAL
This email and any files transmitted with it are intended solely for the
use of the addressee(s) and may contain information which is confidential
or privileged.  If you receive this email and you are not the addressee(s)
[or responsible for delivery of the email to the addressee(s)], please
disregard the contents of the email, delete the email and notify the author
immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160322/30d1c499/attachment-0001.html>


More information about the users mailing list