XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8, 9 and 10
Open eSignForms
yozons at gmail.com
Thu Feb 14 20:53:57 UTC 2019
Thanks. I sent over the latest code that I was testing on yesterday.
I changed our code to use null instead of
"http://uri.etsi.org/01903/v1.4.1#" -- as well as removed the "xades:"
prefixes (with or without prefixes never resolved anything for me,
though the prefix made the XML look better than all the generated
prefixes). It still signs fine, but the verify fails, and it only fails
in reference #3 which is the ETSI/XAdES element.
XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR Failed core
validation; SignatureValue validated: true
-> Reference[0] before validate(): r.getId(): Payload_Reference_ID;
r.getURI():
-> Reference[0] validated: true
-> Reference[1] before validate(): r.getId(): null; r.getURI():
#KeyInfo_ID
-> Reference[1] validated: true
* -> Reference[2] before validate(): r.getId(): null; r.getURI():
#QualifyingProperties_ID**
** -> Reference[2] validated: false**
* -> Reference[3] before validate(): r.getId(): null; r.getURI():
#OpenESignForms_Seal_ID
-> Reference[3] validated: true
It's not clear why that section can generate the signature fine, but
can't validate it.
Before removing the namespace spec on that element, it appeared fine in
the signed XML, but fails verification:
<ds:Object>
<xades:QualifyingProperties
xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"
xades:Id="QualifyingProperties_ID">
<xades:SignedProperties>
<xades:SignedSignatureProperties>
<xades:SigningTime>2019-02-14T10:46:44-08:00</xades:SigningTime>
</xades:SignedSignatureProperties>
<xades:SignedDataObjectProperties>
<xades:DataObjectFormat
xades:ObjectReference="#Payload_Reference_ID">
<xades:Description>description</xades:Description>
<xades:MimeType>text/html</xades:MimeType>
</xades:DataObjectFormat>
</xades:SignedDataObjectProperties>
</xades:SignedProperties>
<xades:UnsignedProperties/>
</xades:QualifyingProperties>
</ds:Object>
With the namespace removed, it also looks normal and fine to me, but
still fails verification:
<ds:Object>
<QualifyingProperties Id="QualifyingProperties_ID" xmlns="">
<SignedProperties>
<SignedSignatureProperties>
<SigningTime>2019-02-14T11:33:27-08:00</SigningTime>
</SignedSignatureProperties>
<SignedDataObjectProperties>
<DataObjectFormat
ObjectReference="#Payload_Reference_ID">
<Description>description</Description>
<MimeType>text/html</MimeType>
</DataObjectFormat>
</SignedDataObjectProperties>
</SignedProperties>
</QualifyingProperties>
</ds:Object>
On 2/14/19 11:29 AM, Sean Mullan wrote:
> I will need more time to look into this. In the meantime, another
> workaround is to just specify null as the namespace to the
> createElementNS and setAttributeNS methods. I tried this out on your
> example and it works fine on JDK 11. This should generate signatures
> just like you were creating before. They won't have the correct ETSI
> namespace and may instead inherit the XML Signature namespace, but if
> you haven't seen problems with that, then it might be ok. It's
> typically more of an issue if you are moving signed content from one
> document to another and an ancestor namespace can be inherited and
> break or invalidate the signature, although exclusive C14N is designed
> to protect against that.
>
>
> --Sean
>
> On 2/13/19 6:06 PM, Open eSignForms wrote:
>> Well, I have found that my verify routines are failing. I added the
>> following lines to the main() test method of your fixed code after
>> the signature is done to attempt to validate the generated signed XML:
>>
>> try {
>> System.err.println("Verifying signedXml...");
>> xmldsig.verify(signedXml, signatureKey);
>> System.err.println("Verified signedXml...");
>> } catch(Exception ve) {
>> System.err.println("XmlDigitalSignature.main() signature verification
>> exception: " + ve.getMessage());
>> }
>>
>> This basically submits the created 'signedXml' returned just above
>> with the same keys. I also had to update the method "verify(String
>> signedXml, SignatureKey signatureKey)" where it sets the ID attribute
>> to include the namespace added in the fixed code:
>>
>> qualifyingPropertiesElement.setIdAttribute*NS("http://uri.etsi.org/01903/v1.1.1#"*,"Id",
>> true); // mark our id as the "Id" attribute
>>
>> This then fails showing 2 out of 4 references validated, the others
>> failing:
>>
>> XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR Failed core
>> validation; SignatureValue validated: true
>> -> Reference[0] validated: true
>> -> Reference[1] validated: true
>> -> Reference[2] validated: false
>> -> Reference[3] validated: false
>> XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR exception:
>> Invalid signature. SignatureValue validated; XML data payload
>> validated; OpenESignForms Seal validated; Unexpected Reference[2]
>> INVALID; Unexpected Reference[3] INVALID
>>
>> In my test code I was able to show the references subscripts 0-3 being:
>>
>> -> Reference[0] before validate(): *r.getId():
>> Payload_Reference_ID*; r.getURI():
>> -> Reference[0] validated: true
>>
>> -> Reference[1] before validate(): r.getId(): null; *r.getURI():
>> #KeyInfo_ID*
>> -> Reference[1] validated: true
>>
>> -> Reference[2] before validate(): r.getId(): null; *r.getURI():
>> #QualifyingProperties_ID*
>> -> Reference[2] validated: false
>>
>> -> Reference[3] before validate(): r.getId(): null; *r.getURI():
>> #OpenESignForms_Seal_ID*
>> -> Reference[3] validated: false
>>
>> So, the namespace changes made allow the digital signature to be
>> applied, but now I'm stuck on how to verify these last two
>> references. It seems that references related to Payload_Reference_ID
>> and #KeyInfo_ID validate, but #QualifyingProperties_ID and
>> #OpenESignForms_Seal_ID are failing.
>>
>> I'm not sure how those references work with respect to the namespace
>> changes you suggested.
>>
>> In fact, the fixed code no longer validates the digital signature
>> under Java 8 once the namespaces were added. Any ideas?
>>
>> Thanks, David
>>
>>
>> On 2/13/19 1:23 PM, Open eSignForms wrote:
>>>
>>> I checked the ETSI XAdES spec
>>> (http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf) and it
>>> doesn't show any namespace on their entries for their
>>> QualifyingProperties element and all sub-elements under the ETSI
>>> example's element <ds:Object>.
>>>
>>> But, their specification does show element <QualifyingProperties>
>>> should be under the namespace "http://uri.etsi.org/01903/v1.1.1#" as
>>> you added in your fixed code.
>>>
>>> That is, when my snapshot element that's digitally signed using the
>>> below, it fails with the NAMESPACE_ERR exception:
>>>
>>> <snapshot *xmlns="http://open.esignforms.com/XMLSchema/2011"*
>>> timestamp="2019-02-13T11:02:30-08:00" type="document">
>>>
>>> But if my snapshot is set up with the ETSI namespace URI, it works:
>>>
>>> <snapshot *xmlns="**http://uri.etsi.org/01903/v1.1.1#**" *
>>> timestamp="2019-02-13T11:02:30-08:00" type="document">
>>>
>>> So, it seems that the XMLSignature is noting that the
>>> <QualifyingProperties> belongs to the default namespace in both
>>> cases, but of course expects that particular element to belong to
>>> the ETSI namespace, not ours.
>>>
>>> I presume that's correct behavior; I just didn't think that the
>>> XMLSignature.sign() knew about and was limited to that specific
>>> namespace.
>>>
>>> If you agree that this is the correct behavior, I think it's not
>>> really a bug in Java 11, though it fails backwards compatibility.
>>>
>>> The only oddity that remains is what I mentioned below with all the
>>> "
" characters in the digests/signatures that appear in Java
>>> 11. They sure look odd compared to simple line breaks that
>>> presumably were emitted before.
>>>
>>> David
>>>
>>>
>>>
>>> On 2/13/19 11:20 AM, Open eSignForms wrote:
>>>> Thanks, Sean. I was able to find the updated test case source code.
>>>>
>>>> A preliminary review seems to show worthwhile changes to our code.
>>>> That is, the namespaces and such seem to make sense as you have them.
>>>>
>>>> In particular, the use of:
>>>>
>>>> domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig");
>>>>
>>>> and adding this namespace to additional elements we added:
>>>>
>>>> String xmlns = "http://uri.etsi.org/01903/v1.1.1#";
>>>>
>>>> seem reasonable and an acceptable workaround for us. I'm not sure
>>>> if those were oversights from before, but likely were the result of
>>>> it being based on Oracle/Java example code from Java 6 days...
>>>>
>>>> We'll incorporate your namespace changes in our code and test, but
>>>> this seems like it will work as I was able to confirm that your
>>>> fixed version seems to run on Java 10 and Java 11.
>>>>
>>>> It is interesting that the fixed code, though, generates different
>>>> output on Java 10 and Java 11. I'm not positive, but it seems that
>>>> Java 11 adds '
' to the end of many lines that aren't present
>>>> in Java 10's output.
>>>>
>>>> Under Java 10, a test run products this result:
>>>>
>>>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011"
>>>> timestamp="2019-02-13T11:02:30-08:00"
>>>> type="document"><![CDATA[<html
>>>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy
>>>> HTML document</p></body></html>]]><dsig:Signature
>>>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
>>>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod
>>>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference
>>>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u
>>>>
>>>> xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference
>>>> URI="#KeyInfo_ID"><dsig:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc
>>>> 2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference
>>>> URI="#QualifyingProperties_ID"><dsig:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr
>>>> r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference
>>>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs
>>>> l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN
>>>>
>>>> hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K
>>>>
>>>> B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5
>>>>
>>>> vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o
>>>>
>>>> NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP
>>>>
>>>> RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG
>>>>
>>>> 7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b
>>>>
>>>> cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU
>>>>
>>>> kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=</dsig:SignatureValue><dsig:KeyInfo
>>>> Id="KeyInfo_ID"><dsig:KeyName>c42c747f-0f03-46a3-8ae8-81fc95464c8f</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9
>>>>
>>>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW
>>>>
>>>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU
>>>>
>>>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX
>>>>
>>>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ
>>>>
>>>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB
>>>>
>>>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z
>>>>
>>>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n
>>>>
>>>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu
>>>>
>>>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z
>>>>
>>>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2
>>>>
>>>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh
>>>>
>>>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz
>>>>
>>>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh
>>>>
>>>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw
>>>>
>>>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ
>>>>
>>>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi
>>>>
>>>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A
>>>>
>>>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6
>>>>
>>>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/
>>>>
>>>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn
>>>>
>>>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy
>>>>
>>>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW
>>>>
>>>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR
>>>>
>>>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz
>>>>
>>>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj
>>>>
>>>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC
>>>>
>>>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc
>>>>
>>>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI
>>>>
>>>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl
>>>>
>>>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o
>>>>
>>>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY
>>>>
>>>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N
>>>>
>>>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E
>>>>
>>>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg
>>>>
>>>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV
>>>>
>>>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC
>>>>
>>>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q
>>>>
>>>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX
>>>>
>>>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D
>>>>
>>>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+
>>>>
>>>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx
>>>>
>>>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P
>>>>
>>>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf
>>>>
>>>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z
>>>>
>>>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0
>>>>
>>>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN
>>>>
>>>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk
>>>>
>>>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw
>>>>
>>>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz
>>>>
>>>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO
>>>>
>>>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK
>>>>
>>>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u
>>>>
>>>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/
>>>>
>>>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX
>>>>
>>>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy
>>>>
>>>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties
>>>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#"
>>>> ns0:Id="QualifyingProperties_ID"
>>>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:02:30-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat
>>>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty
>>>> Id="OpenESignForms_Seal_ID"
>>>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal
>>>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011"
>>>> ns0:DeploymentHostAddress="192.1.1.1"
>>>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011"
>>>> ns1:DeploymentHostName="open.esignforms.com"
>>>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011"
>>>> ns2:DeploymentId="1.1.1.1"
>>>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011"
>>>> ns3:SignerAddress="192.1.1.1"
>>>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011"
>>>> ns4:SignerAgent="No-Browser-Test"
>>>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011"
>>>> ns5:Timestamp="2019-02-13T11:02:30-08:00"
>>>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011"
>>>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>>>>
>>>> while when run under Java 11 it shows what seems to be the same
>>>> (clearly, the digest/hashes aren't the same as the 'timestamp'
>>>> differs because they are actual times) except for lots of '
'
>>>> added to the digests and signatures:
>>>>
>>>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011"
>>>> timestamp="2019-02-13T11:01:22-08:00"
>>>> type="document"><![CDATA[<html
>>>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy
>>>> HTML document</p></body></html>]]><dsig:Signature
>>>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
>>>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod
>>>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference
>>>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr
>>>>
>>>> 7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference
>>>> URI="#KeyInfo_ID"><dsig:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB
>>>> LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference
>>>> URI="#QualifyingProperties_ID"><dsig:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX
>>>> x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference
>>>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM
>>>> oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI
>>>>
>>>> /N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e
>>>>
>>>> vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS
>>>>
>>>> J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8
>>>>
>>>> lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i
>>>>
>>>> qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN
>>>>
>>>> D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k
>>>>
>>>> jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI
>>>>
>>>> OlNbqOO7rjuxtb+gt1iO2dTHfQhG99BCBQhC7AEMp67fIlPjEOECXldDTpzPMZ1K6cPlk22rpvc=</dsig:SignatureValue><dsig:KeyInfo
>>>> Id="KeyInfo_ID"><dsig:KeyName>184a40b0-78b6-4070-a7d7-1497078a06e4</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9
>>>>
>>>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW
>>>>
>>>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU
>>>>
>>>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX
>>>>
>>>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ
>>>>
>>>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB
>>>>
>>>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z
>>>>
>>>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n
>>>>
>>>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu
>>>>
>>>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z
>>>>
>>>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2
>>>>
>>>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh
>>>>
>>>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz
>>>>
>>>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh
>>>>
>>>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw
>>>>
>>>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ
>>>>
>>>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi
>>>>
>>>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A
>>>>
>>>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6
>>>>
>>>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/
>>>>
>>>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn
>>>>
>>>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy
>>>>
>>>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW
>>>>
>>>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR
>>>>
>>>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz
>>>>
>>>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj
>>>>
>>>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC
>>>>
>>>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc
>>>>
>>>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI
>>>>
>>>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl
>>>>
>>>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o
>>>>
>>>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY
>>>>
>>>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N
>>>>
>>>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E
>>>>
>>>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg
>>>>
>>>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV
>>>>
>>>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC
>>>>
>>>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q
>>>>
>>>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX
>>>>
>>>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D
>>>>
>>>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+
>>>>
>>>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx
>>>>
>>>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P
>>>>
>>>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf
>>>>
>>>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z
>>>>
>>>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0
>>>>
>>>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN
>>>>
>>>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk
>>>>
>>>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw
>>>>
>>>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz
>>>>
>>>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO
>>>>
>>>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK
>>>>
>>>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u
>>>>
>>>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/
>>>>
>>>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX
>>>>
>>>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy
>>>>
>>>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties
>>>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#"
>>>> ns0:Id="QualifyingProperties_ID"
>>>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:01:22-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat
>>>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty
>>>> Id="OpenESignForms_Seal_ID"
>>>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal
>>>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011"
>>>> ns0:DeploymentHostAddress="192.1.1.1"
>>>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011"
>>>> ns1:DeploymentHostName="open.esignforms.com"
>>>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011"
>>>> ns2:DeploymentId="1.1.1.1"
>>>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011"
>>>> ns3:SignerAddress="192.1.1.1"
>>>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011"
>>>> ns4:SignerAgent="No-Browser-Test"
>>>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011"
>>>> ns5:Timestamp="2019-02-13T11:01:22-08:00"
>>>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011"
>>>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>>>>
>>>>
>>>> It's particularly odd because hex 13 isn't a typical character (^S).
>>>>
>>>> Any idea what that difference is about for the base64 digests and
>>>> signatures?
>>>>
>>>> David
>>>>
>>>>
>>>> On 2/13/19 6:03 AM, Sean Mullan wrote:
>>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190214/1e45ded8/attachment.htm>
More information about the security-dev
mailing list