Summary
-------

Oracle JDK 8u231 upgraded the Apache Santuario libraries to v2.1.3. As part of that upgrade, the Santuario stack has become more strict on how it encodes data and is now using the JDK encoder rather than its own legacy encoder. This change introduced an issue where XML signature using the Base64 encoding resulted in appending `&#xd` or `&#13` to the encoded output. This issue is seen in the Apache Santuario code base and not a JDK issue. The Santuario team has adopted a position of keeping their libraries compliant with the RFC 2045 - 

> https://issues.apache.org/jira/browse/SANTUARIO-494

> https://issues.apache.org/jira/browse/SANTUARIO-482

and recommended using `com.sun.org.apache.xml.internal.security.ignoreLineBreaks` System property to workaround the issue. But this property usage results in a long encoded output. A few Oracle JDK customers use client software to verify the format returned by the encoder. The software expects the data obtained to match legacy Base64 encoding result. Customers expect JDK Updates to work seamlessly in their enterprise, a need for fixing the issue specific to Oracle JDK 8 Updates is proposed. When upgrading to later JDK versions, it is the Customer's responsibility to upgrade their client's software as well.


Problem
-------

With the upgraded Apache Santuario libraries, nearly all encoding requests are now managed by the JDK java.util.Base64 implementation, which is more compliant with the RFC standards as opposed to the legacy encoder that ships with the Santuario libraries. 

As per the RFC complaint Encoder specification adopted by Apache Santuario:

> The encoded output must be represented in lines of no more than 76
> characters each and uses a carriage return {@code '\r'} followed
> immediately by a linefeed {@code '\n'} as the line separator.

`&#xd` or `&#13` are the ASCII values of `'\r'` who somehow escape encoding and appends to the encoded output.

Following examples can be used for better understanding: 

JDK 8u231 Encoding output :

    Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1t
    appOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvX
    sf4F9Q==

JDK 8u231 with ignoreLineBreaks property:

    Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1tappOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvXsf4F9Q==

Expected output (Legacy Encoding output):

    Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1t
    appOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvX
    sf4F9Q==



Solution
--------

Introduce a new system property `com.sun.org.apache.xml.internal.security.lineFeedOnly` which when set uses the API `getMimeEncoder(int linelength, byte[] lineSeparator)` with linelength as 76 and lineSeparator as '\n'. This way no carriage return is passed to Encoding logic.

With the new property the expected result is obtained:

Result before setting System property:

    Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1t
    appOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvX
    sf4F9Q==

Result after setting System property:

    Ccpdzsqrjo/QxOvlEyRyM1n8/Dszfxik1LurcFcM8tTuyKT9aQ2EnV/id8mKx01ldzFAPkWQWU1t
    appOfZ/2bHOM8gdmiyHpKCrkkvVR+YJc0x3FuzjuqJP8CkC/WdTJr3YcuLQ6K9QhPO8KIVDs3BvX
    sf4F9Q==


This new `com.sun.org.apache.xml.internal.security.lineFeedOnly` System Property will be available only in Oracle JDK 8 Updates. Later JDK versions will still need to use System Property `com.sun.org.apache.xml.internal.security.ignoreLineBreaks` and client software's should be updated to work with the logic.


Specification
-------------

No specification change, only behavioral change with the new property is observed. This new property has no effect on default behavior nor when `com.sun.org.apache.xml.internal.security.ignoreLineBreaks` property is set.