<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <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/">"http://www.w3.org/2000/xmlns/"</a>, "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>);</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>
  </body>
</html>