<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 2022-03-24, at 01:59, Jason Pyeron <<a href="mailto:jpyeron@pdinc.us" class="">jpyeron@pdinc.us</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(31, 73, 125); color: rgb(31, 73, 125); font-family: Calibri, sans-serif; font-size: 14.666666984558105px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;" class="">RFC 7468 allows for whitespace, 
 is ASCII 13, a white space char. Why not here? The RFC says, in General Considerations:</span></div></blockquote></div><div class=""><br class=""></div>Things are probably a bit more complicated than they appear. When we see an encoded CR character like this, either as 
 or as it's usually because something in the chain got deeply confused about how the end of a line should be represented.<div class=""><br class=""></div><div class="">On Windows, as you're probably aware, text file lines are CR (12) followed by LF (10). On most other systems these days, it's just LF. If something gets moved from one kind of system to another, the CR can end up isolated from the logical end of line and treated as independent white space.</div><div class=""><br class=""></div><div class="">This sounds harmless (it's just white space, in some sense) but in fact can cause issues with things like signatures (on one system, there's just a line terminator, on another it's white space then a line terminator).</div><div class=""><br class=""></div><div class="">For example, see <a href="https://shibboleth.atlassian.net/browse/SSPCPP-684" class="">https://shibboleth.atlassian.net/browse/SSPCPP-684</a></div><div class=""><br class=""></div><div class="">I didn't think the IdP was similarly impacted but I guess I'm not astonished. As a result of the problems with the SP, several federations now look for this and exclude entity-encoded CR characters to avoid issues for their members, so we don't see this in the wild any more.</div><div class=""><br class=""></div><div class="">As to this:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">"Since we include the "
" characters to show a break in the metadata information, we will not be able to remove these characters from the XML file"</blockquote><div class=""><br class=""></div>Your supplier is just obviously confused, sorry. The "
" does nothing of the kind. A line break does, and this may once have been part of a line break, but it isn't any more.<br class=""><div class=""><br class=""></div><div class="">As you say this just appears in the certificate data, I'd have to say my suspicion is that they got bitten by one of the changes that was made to Base64 handling in Java a while back, in which things like certificate and signature data ends up internally with CR LF sequences inside the Java strings; when written out on a non-Windows system, the CRs end up encoded. In my opinion, this is nonsensical and a result of an over-reading of the Base64 specification but obviously others disagree.</div><div class=""><br class=""></div><div class="">If your supplier thinks this is somehow mandated by the XML standard "to show a break in the metadata information", I wonder why they didn't notice that the rest of the XML wasn't done the same way.</div><div class=""><br class=""></div><div class="">Having said which, if that's their response I doubt that you'll be able to have a real conversation about this. You're probably going to have to remove the entities by hand.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">The IdP fails to parse this. Is this actually valid SAML for the metadata?</blockquote><br class=""></div><div class="">It's complicated. It might be worth putting in a Jira case for this, but if you do we'd need a lot more detail: ideally the whole of the metadata file and more detail about how "fails to parse" manifests. There are multiple layers of interpretation being performed so the issue (if any) could be in a number of different places.</div><div class=""><br class=""></div><div class=""><span style="font-size: 12px; orphans: 2; widows: 2; -webkit-text-decorations-in-effect: none;" class=""> -- Ian</span></div><div class=""><span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; font-weight: normal; line-height: normal; border-spacing: 0px; -webkit-text-decorations-in-effect: none;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div class=""><span class="Apple-style-span" style="font-size: medium;"><br class=""></span></div></span></div></span><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>