Summary

Oracle JDK 7u is due to upgrade the Apache Santuario libraries to v2.1.4. Before that upgrade can be done, v2.1.1 and v2.1.3 must be integrated to the code base. As part of these upgrades, 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 7 Updates is proposed. This has already been implemented in JDK 8 Updates. When upgrading to JDK versions greater than 8, 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 7u Encoding output without ignoreLineBreaks property:

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

JDK7u Encoding output 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

In jdk7u, Base64 is not sufficiently capable for this task, nor does it reside in java.util. This upgrade will bring back existing java.util.Base64 functionality from 8u to a private package specific to this upgrade.

This fix will 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 JDK7 and JDK8 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.