XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8, 9 and 10
Sean Mullan
sean.mullan at oracle.com
Wed Feb 13 14:03:33 UTC 2019
On 2/12/19 6:28 PM, Open eSignForms wrote:
> Thanks for the update, Sean. I'm a bit perplexed because I found the
> original code works under Java 9 and Java 10, so it seems like the
> change occurred in Java 11.
Sorry, that was a typo, I meant to say JDK 11.
> I don't see the modified version of the test case. If you attached it,
> it somehow didn't make it through to me.
>
> If it's just a matter of making the code more correct, we'd love to make
> the changes. My concern, of course, is that we've already done millions
> of XML digital signatures, so we need that to continue to verify
> correctly (and even under Java 11, it seems that the verify code works
> against previously digitally signed content) even if we now start
> digitally signing using more update-to-date code.
The verification of pre-existing signatures should continue to work
regardless of how this bug is addressed.
> Please send over the modified test case and I'll take a look.
It is attached to the bug report in the Attachments section:
https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you download
the one I added yesterday).
--Sean
>
> Thanks!
> David
>
> On 2/12/19 2:14 PM, Sean Mullan wrote:
>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>
>> I have started looking at this issue and have some progress I can report.
>>
>> In JDK 9, we updated the version of the Apache XML Signature
>> implementation in the JDK. Some of the marshalling code was rewritten
>> such that it will throw Exceptions if legacy DOM level 1 methods were
>> used to create XML content which is then passed into XMLObject and
>> similar XMLSignature types that take DOMStructure objects. This is
>> because the DOM level 1 methods do not support namespaces.
>>
>> I am still evaluating what the best fix is. However, you can
>> workaround the issue by always using DOM level 3 methods which are
>> namespace aware. For example, use Document.createElementNS instead of
>> Document.createElement and Element.createAttributeNS instead of
>> Element.createAttribute.
>>
>> Using legacy or non-namespace aware XML parsers or implementations is
>> not recommended and the XML Signature Best Practices document gives
>> some rationale:
>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces
>>
>> That said, this is a regression in behavior so it would be best if we
>> could restore the previous behavior.
>>
>> I have attached a modified version of the test case to the bug report
>> which no longer throws an Exception. Let me know if this is an
>> acceptable workaround. Double-check the namespaces that I used to make
>> sure they are correct.
>>
>> --Sean
>>
>>
>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>
>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>> I have a test version of the code that can run standalone and shows
>>>>> the bug. I'm not sure how best to transfer this information to the
>>>>> forum for those to play with, but it is included below.
>>>>
>>>> Thanks, I can reproduce the issue now. I will need to debug further
>>>> to see what might be causing this.
>>>>
>>>> --Sean
More information about the security-dev
mailing list