<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Thanks.  I sent over the latest code that I was testing on
      yesterday.</p>
    <p>I changed our code to use null instead of
      <a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.4.1#">"http://uri.etsi.org/01903/v1.4.1#"</a> -- 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.<br>
    </p>
    <p>XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR Failed
      core validation; SignatureValue validated: true<br>
       -> Reference[0] before validate(): r.getId():
      Payload_Reference_ID; r.getURI(): <br>
       -> Reference[0] validated: true<br>
       -> Reference[1] before validate(): r.getId(): null;
      r.getURI(): #KeyInfo_ID<br>
       -> Reference[1] validated: true<br>
      <b> -> Reference[2] before validate(): r.getId(): null;
        r.getURI(): #QualifyingProperties_ID</b><b><br>
      </b><b> -> Reference[2] validated: false</b><b><br>
      </b> -> Reference[3] before validate(): r.getId(): null;
      r.getURI(): #OpenESignForms_Seal_ID<br>
       -> Reference[3] validated: true<br>
    </p>
    <p>It's not clear why that section can generate the signature fine,
      but can't validate it.</p>
    <p>Before removing the namespace spec on that element, it appeared
      fine in the signed XML, but fails verification:</p>
    <p>    <ds:Object><br>
              <xades:QualifyingProperties
      xmlns:xades=<a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.4.1#">"http://uri.etsi.org/01903/v1.4.1#"</a>
      xades:Id="QualifyingProperties_ID"><br>
                  <xades:SignedProperties><br>
                      <xades:SignedSignatureProperties><br>
                         
<xades:SigningTime>2019-02-14T10:46:44-08:00</xades:SigningTime><br>
                      </xades:SignedSignatureProperties><br>
                      <xades:SignedDataObjectProperties><br>
                          <xades:DataObjectFormat
      xades:ObjectReference="#Payload_Reference_ID"><br>
                             
      <xades:Description>description</xades:Description><br>
                             
      <xades:MimeType>text/html</xades:MimeType><br>
                          </xades:DataObjectFormat><br>
                      </xades:SignedDataObjectProperties><br>
                  </xades:SignedProperties><br>
                  <xades:UnsignedProperties/><br>
              </xades:QualifyingProperties><br>
          </ds:Object><br>
    </p>
    <p>With the namespace removed, it also looks normal and fine to me,
      but still fails verification:</p>
    <p>    <ds:Object><br>
              <QualifyingProperties Id="QualifyingProperties_ID"
      xmlns=""><br>
                  <SignedProperties><br>
                      <SignedSignatureProperties><br>
                         
      <SigningTime>2019-02-14T11:33:27-08:00</SigningTime><br>
                      </SignedSignatureProperties><br>
                      <SignedDataObjectProperties><br>
                          <DataObjectFormat
      ObjectReference="#Payload_Reference_ID"><br>
                             
      <Description>description</Description><br>
                              <MimeType>text/html</MimeType><br>
                          </DataObjectFormat><br>
                      </SignedDataObjectProperties><br>
                  </SignedProperties><br>
              </QualifyingProperties><br>
          </ds:Object><br>
    </p>
    <br>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2/14/19 11:29 AM, Sean Mullan wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:ba795b7d-6100-208e-e463-1c3894612245@oracle.com">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.
      <br>
      <br>
      <br>
      --Sean
      <br>
      <br>
      On 2/13/19 6:06 PM, Open eSignForms wrote:
      <br>
      <blockquote type="cite">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:
        <br>
        <br>
                     try {
        <br>
                         System.err.println("Verifying signedXml...");
        <br>
                         xmldsig.verify(signedXml, signatureKey);
        <br>
                         System.err.println("Verified signedXml...");
        <br>
                     } catch(Exception ve) {
        <br>
        System.err.println("XmlDigitalSignature.main() signature
        verification exception: " + ve.getMessage());
        <br>
                     }
        <br>
        <br>
        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:
        <br>
        <br>
                    
qualifyingPropertiesElement.setIdAttribute*NS(<a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.1.1#">"http://uri.etsi.org/01903/v1.1.1#"</a>*,"Id",
        true); // mark our id as the "Id" attribute
        <br>
        <br>
        This then fails showing 2 out of 4 references validated, the
        others failing:
        <br>
        <br>
        XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR Failed
        core validation; SignatureValue validated: true
        <br>
          -> Reference[0] validated: true
        <br>
          -> Reference[1] validated: true
        <br>
          -> Reference[2] validated: false
        <br>
          -> Reference[3] validated: false
        <br>
        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
        <br>
        <br>
        In my test code I was able to show the references subscripts 0-3
        being:
        <br>
        <br>
          -> Reference[0] before validate(): *r.getId():
        Payload_Reference_ID*; r.getURI():
        <br>
          -> Reference[0] validated: true
        <br>
        <br>
          -> Reference[1] before validate(): r.getId(): null;
        *r.getURI(): #KeyInfo_ID*
        <br>
          -> Reference[1] validated: true
        <br>
        <br>
          -> Reference[2] before validate(): r.getId(): null;
        *r.getURI(): #QualifyingProperties_ID*
        <br>
          -> Reference[2] validated: false
        <br>
        <br>
          -> Reference[3] before validate(): r.getId(): null;
        *r.getURI(): #OpenESignForms_Seal_ID*
        <br>
          -> Reference[3] validated: false
        <br>
        <br>
        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.
        <br>
        <br>
        I'm not sure how those references work with respect to the
        namespace changes you suggested.
        <br>
        <br>
        In fact, the fixed code no longer validates the digital
        signature under Java 8 once the namespaces were added.  Any
        ideas?
        <br>
        <br>
        Thanks, David
        <br>
        <br>
        <br>
        On 2/13/19 1:23 PM, Open eSignForms wrote:
        <br>
        <blockquote type="cite">
          <br>
          I checked the ETSI XAdES spec
          (<a class="moz-txt-link-freetext" href="http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf">http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf</a>) 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>.
          <br>
          <br>
          But, their specification does show element
          <QualifyingProperties> should be under the namespace
          <a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.1.1#">"http://uri.etsi.org/01903/v1.1.1#"</a> as you added in your fixed
          code.
          <br>
          <br>
          That is, when my snapshot element that's digitally signed
          using the below, it fails with the NAMESPACE_ERR exception:
          <br>
          <br>
          <snapshot
          *xmlns=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>*
          timestamp="2019-02-13T11:02:30-08:00" type="document">
          <br>
          <br>
          But if my snapshot is set up with the ETSI namespace URI, it
          works:
          <br>
          <br>
          <snapshot *xmlns="**<a class="moz-txt-link-freetext" href="http://uri.etsi.org/01903/v1.1.1#**">http://uri.etsi.org/01903/v1.1.1#**</a>" *
          timestamp="2019-02-13T11:02:30-08:00" type="document">
          <br>
          <br>
          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.
          <br>
          <br>
          I presume that's correct behavior; I just didn't think that
          the XMLSignature.sign() knew about and was limited to that
          specific namespace.
          <br>
          <br>
          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.
          <br>
          <br>
          The only oddity that remains is what I mentioned below with
          all the "&#13;" characters in the digests/signatures that
          appear in Java 11.  They sure look odd compared to simple line
          breaks that presumably were emitted before.
          <br>
          <br>
          David
          <br>
          <br>
          <br>
          <br>
          On 2/13/19 11:20 AM, Open eSignForms wrote:
          <br>
          <blockquote type="cite">Thanks, Sean.  I was able to find the
            updated test case source code.
            <br>
            <br>
            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.
            <br>
            <br>
            In particular, the use of:
            <br>
            <br>
            domSignContext.putNamespacePrefix(XMLSignature.XMLNS,
            "dsig");
            <br>
            <br>
            and adding this namespace to additional elements we added:
            <br>
            <br>
                        String xmlns =
            <a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.1.1#">"http://uri.etsi.org/01903/v1.1.1#"</a>;
            <br>
            <br>
            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...
            <br>
            <br>
            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.
            <br>
            <br>
            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 '&#13;' to the end of
            many lines that aren't present in Java 10's output.
            <br>
            <br>
            Under Java 10, a test run products this result:
            <br>
            <br>
            <snapshot
            xmlns=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            timestamp="2019-02-13T11:02:30-08:00"
            type="document"><![CDATA[<html
xmlns=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/1999/xhtml">"http://www.w3.org/1999/xhtml"</a>><head></head><body><p>Dummy
            HTML
            document</p></body></html>]]><dsig:Signature
            xmlns:dsig=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/09/xmldsig#">"http://www.w3.org/2000/09/xmldsig#"</a>
Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2006/12/xml-c14n11#WithComments">"http://www.w3.org/2006/12/xml-c14n11#WithComments"</a>/><dsig:SignatureMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512">"http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"</a>/><dsig:Reference
            Id="Payload_Reference_ID"
            URI=""><dsig:Transforms><dsig:Transform
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/09/xmldsig#enveloped-signature">"http://www.w3.org/2000/09/xmldsig#enveloped-signature"</a>/></dsig:Transforms><dsig:DigestMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha512">"http://www.w3.org/2001/04/xmlenc#sha512"</a>/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u
            <br>
xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference
            URI="#KeyInfo_ID"><dsig:DigestMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha512">"http://www.w3.org/2001/04/xmlenc#sha512"</a>/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc<br>
2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference
            URI="#QualifyingProperties_ID"><dsig:DigestMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha512">"http://www.w3.org/2001/04/xmlenc#sha512"</a>/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr<br>
r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference
            URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha512">"http://www.w3.org/2001/04/xmlenc#sha512"</a>/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs<br>
l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN
            <br>
hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K
            <br>
B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5
            <br>
vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o
            <br>
NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP
            <br>
RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG
            <br>
7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b
            <br>
cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU
            <br>
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
            <br>
Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW
            <br>
I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU
            <br>
MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX
            <br>
oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ
            <br>
Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB
            <br>
snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z
            <br>
Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n
            <br>
C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu
            <br>
X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z
            <br>
VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2
            <br>
NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh
            <br>
YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz
            <br>
Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh
            <br>
bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw
            <br>
ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ
            <br>
RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi
            <br>
MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A
            <br>
5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6
            <br>
drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/
            <br>
pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn
            <br>
bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy
            <br>
JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW
            <br>
Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR
            <br>
onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz
            <br>
GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj
            <br>
K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC
            <br>
JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc
            <br>
2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI
            <br>
8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl
            <br>
kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o
            <br>
97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY
            <br>
LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N
            <br>
SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E
            <br>
aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg
            <br>
Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV
            <br>
Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC
            <br>
AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q
            <br>
3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX
            <br>
SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D
            <br>
pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+
            <br>
aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx
            <br>
GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P
            <br>
TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf
            <br>
hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z
            <br>
IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0
            <br>
FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN
            <br>
BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk
            <br>
zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw
            <br>
LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz
            <br>
syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO
            <br>
KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK
            <br>
GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u
            <br>
FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/
            <br>
aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX
            <br>
3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy
            <br>
VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties
            xmlns:ns0=<a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.1.1#">"http://uri.etsi.org/01903/v1.1.1#"</a>
            ns0:Id="QualifyingProperties_ID"
xmlns=<a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.1.1#">"http://uri.etsi.org/01903/v1.1.1#"</a>><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=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns0:DeploymentHostAddress="192.1.1.1"
            xmlns:ns1=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns1:DeploymentHostName="open.esignforms.com"
            xmlns:ns2=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns2:DeploymentId="1.1.1.1"
            xmlns:ns3=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns3:SignerAddress="192.1.1.1"
            xmlns:ns4=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns4:SignerAgent="No-Browser-Test"
            xmlns:ns5=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns5:Timestamp="2019-02-13T11:02:30-08:00"
            xmlns:ns6=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot><br>
            <br>
            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 '&#13;' added to the digests and signatures:
            <br>
            <br>
            <snapshot
            xmlns=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            timestamp="2019-02-13T11:01:22-08:00"
            type="document"><![CDATA[<html
xmlns=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/1999/xhtml">"http://www.w3.org/1999/xhtml"</a>><head></head><body><p>Dummy
            HTML
            document</p></body></html>]]><dsig:Signature
            xmlns:dsig=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/09/xmldsig#">"http://www.w3.org/2000/09/xmldsig#"</a>
Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2006/12/xml-c14n11#WithComments">"http://www.w3.org/2006/12/xml-c14n11#WithComments"</a>/><dsig:SignatureMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512">"http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"</a>/><dsig:Reference
            Id="Payload_Reference_ID"
            URI=""><dsig:Transforms><dsig:Transform
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/09/xmldsig#enveloped-signature">"http://www.w3.org/2000/09/xmldsig#enveloped-signature"</a>/></dsig:Transforms><dsig:DigestMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha512">"http://www.w3.org/2001/04/xmlenc#sha512"</a>/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr&#13;
            <br>
7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference
            URI="#KeyInfo_ID"><dsig:DigestMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha512">"http://www.w3.org/2001/04/xmlenc#sha512"</a>/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB&#13;<br>
LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference
            URI="#QualifyingProperties_ID"><dsig:DigestMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha512">"http://www.w3.org/2001/04/xmlenc#sha512"</a>/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX&#13;<br>
x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference
            URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod
Algorithm=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/04/xmlenc#sha512">"http://www.w3.org/2001/04/xmlenc#sha512"</a>/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM&#13;<br>
oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI&#13;
            <br>
/N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e&#13;
            <br>
vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS&#13;
            <br>
J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8&#13;
            <br>
lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i&#13;
            <br>
qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN&#13;
            <br>
D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k&#13;
            <br>
jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI&#13;
            <br>
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&#13;
            <br>
Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW&#13;
            <br>
I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU&#13;
            <br>
MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX&#13;
            <br>
oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ&#13;
            <br>
Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB&#13;
            <br>
snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z&#13;
            <br>
Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n&#13;
            <br>
C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu&#13;
            <br>
X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z&#13;
            <br>
VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2&#13;
            <br>
NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh&#13;
            <br>
YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz&#13;
            <br>
Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh&#13;
            <br>
bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw&#13;
            <br>
ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ&#13;
            <br>
RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi&#13;
            <br>
MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A&#13;
            <br>
5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6&#13;
            <br>
drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/&#13;
            <br>
pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn&#13;
            <br>
bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy&#13;
            <br>
JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW&#13;
            <br>
Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR&#13;
            <br>
onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz&#13;
            <br>
GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj&#13;
            <br>
K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC&#13;
            <br>
JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc&#13;
            <br>
2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI&#13;
            <br>
8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl&#13;
            <br>
kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o&#13;
            <br>
97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY&#13;
            <br>
LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N&#13;
            <br>
SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E&#13;
            <br>
aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg&#13;
            <br>
Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV&#13;
            <br>
Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC&#13;
            <br>
AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q&#13;
            <br>
3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX&#13;
            <br>
SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D&#13;
            <br>
pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+&#13;
            <br>
aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx&#13;
            <br>
GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P&#13;
            <br>
TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf&#13;
            <br>
hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z&#13;
            <br>
IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0&#13;
            <br>
FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN&#13;
            <br>
BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk&#13;
            <br>
zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw&#13;
            <br>
LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz&#13;
            <br>
syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO&#13;
            <br>
KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK&#13;
            <br>
GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u&#13;
            <br>
FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/&#13;
            <br>
aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX&#13;
            <br>
3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy&#13;
            <br>
VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties
            xmlns:ns0=<a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.1.1#">"http://uri.etsi.org/01903/v1.1.1#"</a>
            ns0:Id="QualifyingProperties_ID"
xmlns=<a class="moz-txt-link-rfc2396E" href="http://uri.etsi.org/01903/v1.1.1#">"http://uri.etsi.org/01903/v1.1.1#"</a>><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=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns0:DeploymentHostAddress="192.1.1.1"
            xmlns:ns1=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns1:DeploymentHostName="open.esignforms.com"
            xmlns:ns2=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns2:DeploymentId="1.1.1.1"
            xmlns:ns3=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns3:SignerAddress="192.1.1.1"
            xmlns:ns4=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns4:SignerAgent="No-Browser-Test"
            xmlns:ns5=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
            ns5:Timestamp="2019-02-13T11:01:22-08:00"
            xmlns:ns6=<a class="moz-txt-link-rfc2396E" href="http://open.esignforms.com/XMLSchema/2011">"http://open.esignforms.com/XMLSchema/2011"</a>
ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot><br>
            <br>
            <br>
            It's particularly odd because hex 13 isn't a typical
            character (^S).
            <br>
            <br>
            Any idea what that difference is about for the base64
            digests and signatures?
            <br>
            <br>
            David
            <br>
            <br>
            <br>
            On 2/13/19 6:03 AM, Sean Mullan wrote:
            <br>
            <blockquote type="cite">On 2/12/19 6:28 PM, Open eSignForms
              wrote:
              <br>
              <blockquote type="cite">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.
                <br>
              </blockquote>
              <br>
              Sorry, that was a typo, I meant to say JDK 11.
              <br>
              <br>
              <blockquote type="cite">I don't see the modified version
                of the test case.  If you attached it, it somehow didn't
                make it through to me.
                <br>
                <br>
                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.
                <br>
              </blockquote>
              <br>
              The verification of pre-existing signatures should
              continue to work regardless of how this bug is addressed.
              <br>
              <br>
              <blockquote type="cite">Please send over the modified test
                case and I'll take a look.
                <br>
              </blockquote>
              <br>
              It is attached to the bug report in the Attachments
              section: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8218629">https://bugs.openjdk.java.net/browse/JDK-8218629</a>
              (make sure you download the one I added yesterday).
              <br>
              <br>
              --Sean
              <br>
              <br>
              <blockquote type="cite">
                <br>
                Thanks!
                <br>
                David
                <br>
                <br>
                On 2/12/19 2:14 PM, Sean Mullan wrote:
                <br>
                <blockquote type="cite">The bug is now at
                  <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8218629">https://bugs.openjdk.java.net/browse/JDK-8218629</a>
                  <br>
                  <br>
                  I have started looking at this issue and have some
                  progress I can report.
                  <br>
                  <br>
                  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.
                  <br>
                  <br>
                  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.
                  <br>
                  <br>
                  Using legacy or non-namespace aware XML parsers or
                  implementations is not recommended and the XML
                  Signature Best Practices document gives some
                  rationale:
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces">https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces</a>
                  <br>
                  That said, this is a regression in behavior so it
                  would be best if we could restore the previous
                  behavior.
                  <br>
                  <br>
                  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.
                  <br>
                  <br>
                  --Sean
                  <br>
                  <br>
                  <br>
                  On 2/7/19 11:23 AM, Open eSignForms wrote:
                  <br>
                  <br>
                  <blockquote type="cite">On 2/7/19 7:49 AM, Sean Mullan
                    wrote:
                    <br>
                    <blockquote type="cite">On 2/6/19 4:51 PM, Open
                      eSignForms wrote:
                      <br>
                      <blockquote type="cite">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.
                        <br>
                      </blockquote>
                      <br>
                      Thanks, I can reproduce the issue now. I will need
                      to debug further to see what might be causing
                      this.
                      <br>
                      <br>
                      --Sean
                      <br>
                    </blockquote>
                  </blockquote>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
  </body>
</html>