XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8, 9 and 10

[Sean Mullan]

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