<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>That seems to work, though I used this code instead:</p>
    <p>           
qualifyingPropertiesElement.setAttributeNS(<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/xmlns/">"http://www.w3.org/2000/xmlns/"</a>,"xmlns:xades", 
      <a class="moz-txt-link-rfc2396E"
        href="http://uri.etsi.org/01903/v1.1.1#">"http://uri.etsi.org/01903/v1.4.1#"</a>);</p>
    <p>That's because my xades elements all carry that prefix.  It does
      seem to work.  It's a bit odd to have to code it since the signed
      XML generates it in the expected way, as does the signature
      validation code.  In the end, as long as it works, I'm happy
      again!   <br>
    </p>
    <p>Thanks for all your help.  After I try to push this back into our
      actual code, I'll report back since I need to make sure that this
      works not only on newly signed data using Java 11, but also
      continues to work on previously signed content.  I think it will
      from prior testing.</p>
    <p>Thanks, <br>
      David<br>
    </p>
    <div class="moz-cite-prefix">On 2/15/19 1:21 PM, Sean Mullan wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:c92d46fc-a60f-a0b2-e670-e4fb78efe332@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class="moz-cite-prefix">I know what the problem is.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">You also need to add the actual
        namespace attribute to your element, for example:</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">   
        qualifyingPropertiesElement.setAttributeNS(<br>
                <a class="moz-txt-link-rfc2396E"
          href="http://www.w3.org/2000/xmlns/" moz-do-not-send="true">"http://www.w3.org/2000/xmlns/"</a>,
        "xmlns", <a class="moz-txt-link-rfc2396E"
          href="http://uri.etsi.org/01903/v1.1.1#"
          moz-do-not-send="true">"http://uri.etsi.org/01903/v1.1.1#"</a>);</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">You only need to do that on the
        top-most parent element in that namespace.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">When I made that change to your code,
        everything generated and verified for me correctly (on JDK 10
        anyway, JDK 11 may still have some issues).</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">--Sean<br>
      </div>
      <div class="moz-cite-prefix"> <br>
      </div>
      <div class="moz-cite-prefix">On 2/15/19 3:11 PM, Open eSignForms
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:8a01a47e-0984-b732-7cac-ec76e35b11ab@gmail.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        <p>XML namespaces are pretty confusing.  From what little I
          gather, unprefixed attributes don't belong to any namespace,
          not even the default one.</p>
        <p>I think I can see the bug in the debugging output.<br>
        </p>
        <p>On Java 8 and 10 and 11, I'd guess that the
          marshaling/canonicalization has issues when combining
          differently namespaced objects.<br>
        </p>
        <p>In my working code (also works on Java 11), when my
          ETSI/XADES QualifyingProperties element is created specifying
          my namespace (the default namespace for the XML document that
          I'm signing), it works fine.  If I change my document's
          default namespace to be the XADES one, it also works.  But I
          cannot make them work when both are in use.  The reason seems
          to be as follows.</p>
        <p>1) The signedXML generated looks great and sensible, with the
          xades namespace as expected.<br>
        </p>
        <p>    <ds:Object><br>
                  <xades:QualifyingProperties
          Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal" <b>xmlns:xades=<a
              class="moz-txt-link-rfc2396E"
              href="http://uri.etsi.org/01903/v1.4.1#"
              moz-do-not-send="true">"http://uri.etsi.org/01903/v1.4.1#"</a></b>><br>
                      <xades:SignedProperties><br>
                          <xades:SignedSignatureProperties><br>
                             
<xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime><br>
                          </xades:SignedSignatureProperties><br>
                          <xades:SignedDataObjectProperties><br>
                              <xades:DataObjectFormat
          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:QualifyingProperties><br>
              </ds:Object><br>
          <br>
        </p>
        <p>2) But using the debugging options, it shows this element
          during SIGNING (presuming canonicalization) that makes <i><b>no
              sense</b></i>.  It's added both the default namespace, the
          'dsig' namespace, but doesn't include the xades namespace. 
          Wwhat does the 'xades' prefix even refer to in this XML for
          the signing digest?<br>
        </p>
        <p>    <xades:QualifyingProperties <b>xmlns=<a
              class="moz-txt-link-rfc2396E"
              href="http://open.esignforms.com/XMLSchema/2011"
              moz-do-not-send="true">"http://open.esignforms.com/XMLSchema/2011"</a>
            xmlns:ds=<a class="moz-txt-link-rfc2396E"
              href="http://www.w3.org/2000/09/xmldsig#"
              moz-do-not-send="true">"http://www.w3.org/2000/09/xmldsig#"</a></b>
          Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal"><br>
                  <xades:SignedProperties><br>
                      <xades:SignedSignatureProperties><br>
                         
<xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime><br>
                      </xades:SignedSignatureProperties><br>
                      <xades:SignedDataObjectProperties><br>
                          <xades:DataObjectFormat
          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:QualifyingProperties><br>
        </p>
        <p>3) And again, the debugger shows this element during
          VERIFICATION (presuming canonicalization) that is excessive,
          but at least makes some sense (though there are no default
          elements nor 'dsig' elements).  It's added all three
          namespaces: our default namespace, the 'dsig' namespace AND
          the 'xades' namespace.  <br>
        </p>
        <p>   <xades:QualifyingProperties <b>xmlns=<a
              class="moz-txt-link-rfc2396E"
              href="http://open.esignforms.com/XMLSchema/2011"
              moz-do-not-send="true">"http://open.esignforms.com/XMLSchema/2011"</a>
            xmlns:ds=<a class="moz-txt-link-rfc2396E"
              href="http://www.w3.org/2000/09/xmldsig#"
              moz-do-not-send="true">"http://www.w3.org/2000/09/xmldsig#"</a>
            <font color="#cc0000">xmlns:xades=<a
                class="moz-txt-link-rfc2396E"
                href="http://uri.etsi.org/01903/v1.4.1#"
                moz-do-not-send="true">"http://uri.etsi.org/01903/v1.4.1#"</a></font></b>
          Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal"><br>
                  <xades:SignedProperties><br>
                      <xades:SignedSignatureProperties><br>
                         
<xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime><br>
                      </xades:SignedSignatureProperties><br>
                      <xades:SignedDataObjectProperties><br>
                          <xades:DataObjectFormat
          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:QualifyingProperties<br>
        </p>
        <p>So the libraries are oddly creating two distinct
          canonicalized XML for digesting, with the signing phase
          seeming to miss the important 'xades' namespace declaration
          entirely.  This is no doubt why this is the only Reference
          that fails verification as the two.  I'm guessing that the
          verification digest is correct when using multiple namespaced
          objects/references, but the signing digest is not since it
          doesn't include the 'xades' namespace declaration.</p>
        <p>This seems to hold true for Java 8, 10 and 11.  That is, by
          specifying null namespaces on atrributes, the code fails the
          same under under Java 11, and the debugging output shows the
          same odd namespaces above.  If I use a single namespace, then
          it signs fine under Java 8, 10 and 11.<br>
        </p>
        <p>David</p>
        <p><br>
        </p>
        <div class="moz-cite-prefix">On 2/15/19 11:12 AM, Sean Mullan
          wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:ea7a7809-665d-c8aa-9ebf-f2a54abbaf92@oracle.com">
          <meta http-equiv="Content-Type" content="text/html;
            charset=UTF-8">
          <div class="moz-cite-prefix">On 2/14/19 9:32 PM, Open
            eSignForms wrote:<br>
          </div>
          <blockquote type="cite"
            cite="mid:166893ef-5c96-ba36-3a94-114dd2caeccf@gmail.com">
            <meta http-equiv="Content-Type" content="text/html;
              charset=UTF-8">
            <p>Yes, indeed that's the issue.  But I don't know why/how
              all those xmlns attributes are added, since I don't
              directly add them.</p>
            <p>I found the only way I can make it work under Java 8, 10
              and 11 is to use my common namespace (XML_NAMESPACE_2011 =
              <a class="moz-txt-link-rfc2396E"
                href="http://open.esignforms.com/XMLSchema/2011"
                moz-do-not-send="true">"http://open.esignforms.com/XMLSchema/2011"</a>)
              for all the XADES elements with the null namespace on all
              their attributes.  Even if I put that same namespace on
              the attributes, it then fails.</p>
            <p>When I do that, the signed XML generates clean looking
              XML like this:</p>
            <p>    <ds:Object><br>
                      <QualifyingProperties
              Id="QualifyingProperties_ID"
              Target="#OpenESignForms_Seal"><br>
                         
              <SignedProperties><SignedSignatureProperties><br>
                             
              <SigningTime>2019-02-14T17:37:39-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>
                  <ds:Object><br>
                      <ds:SignatureProperties><br>
                          <ds:SignatureProperty<b>
                Id="OpenESignForms_Seal_ID"
                Target="#OpenESignForms_Seal"</b>><br>
                              <OpenESignForms_XmlDigitalSignatureSeal
              DeploymentHostAddress="192.1.1.1"
              DeploymentHostName="open.esignforms.com"
              DeploymentId="1.1.1.1" SignerAddress="192.1.1.1"
              SignerAgent="No-Browser-Test"
              Timestamp="2019-02-14T17:37:39-08:00"
              Version="19.1.19"/><br>
                          </ds:SignatureProperty><br>
                      </ds:SignatureProperties><br>
                  </ds:Object><br>
              <br>
            </p>
            <p>But even above, as you can see, the second ds:Object
              shows ds:SignatureProperty, yet the Id and Target
              attributes do not include a 'ds:' prefix, which it's my
              understanding to mean that they default to our XML
              payload's default namespace.  </p>
          </blockquote>
          <p>I don't think that's correct, I think attributes w/o a
            prefix by default belong to the namespace of the element in
            which they are defined, which in this case is
            SignatureProperties and the dsig namespace.</p>
          <p>Regarding below, I would forget about JDK 11 for the time
            being and focus on generating a signature with proper XMLNS
            definitions on JDK 10. If you have any problems verifying
            with that on JDK 10 or prior, let me know. The reason is
            that we will likely be restoring JDK 11 (and later) to the
            same state it was in for JDK 10. There were some changes to
            the marshalling code in JDK 11 which is causing these and
            other problems which will likely be backed out. <br>
          </p>
          <p>--Sean</p>
        </blockquote>
      </blockquote>
    </blockquote>
  </body>
</html>