metadata x509 certificate lines terminated with 
 ?

[Ian Young]

> On 2022-03-24, at 01:59, Jason Pyeron <jpyeron at pdinc.us> wrote:
> 
> RFC 7468 allows for whitespace, &#xd; is ASCII 13, a white space char. Why not here? The RFC says, in General Considerations:


Things are probably a bit more complicated than they appear. When we see an encoded CR character like this, either as &#xd; or as 
 it's usually because something in the chain got deeply confused about how the end of a line should be represented.

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.

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).

For example, see https://shibboleth.atlassian.net/browse/SSPCPP-684 <https://shibboleth.atlassian.net/browse/SSPCPP-684>

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.

As to this:

> "Since we include the "&#xd" characters to show a break in the metadata information, we will not be able to remove these characters from the XML file"

Your supplier is just obviously confused, sorry. The "&#xd;" 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.

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.

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.

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.

> The IdP fails to parse this. Is this actually valid SAML for the metadata?

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.

    -- Ian




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220324/5616a8f5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3883 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20220324/5616a8f5/attachment.p7s>