Re: [dss-x] Raw chat trace of meeting #186 on 2017-SEP-18

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Hi Andreas,

You know that XML Signature Recommendation specifies the so-called 
Enveloped Signature Transform
https://www.w3.org/TR/xmldsig-core1/#sec-EnvelopedSignature

This transform is defined for allowing the non-disruptive extraction of 
an enveloped signature from a XML document. So far I have not heard of 
anyone that has reported a failure in the validation of a signature by a 
missbehaviour of that transform.

And this implies not only to signatures that sign whole or part of the 
enveloping document, but also to signatures that at the same time sign 
parts of the enveloping document and documents enveloped by the 
signature (like for instance could do an enveloped XAdES signature - in 
its most adopted version, it signs the xades:SignedProperties, which is 
enveloped by the ds:Signature root element).

My point is the following one: if this transforms works for signatures 
that are at the same time sign the whole or part of the document where 
they are enveloped , and sign another document that they envelop, it 
must work for signatures that are enveloped but just sign a document 
that they envelop.

I certainly would be surprised that in the case that you mention with 
JAXB  that tools based on JAXB would not be able to correctly process 
the extraction and validaton of the signature regardless where you put 
the xmlns namespace. Maybe you could make a try?. Certainly within 
XMLBeans, which is the "competitor" of JAXB, this extraction works 
pretty well, as it is able to successfully validate any kind of XML 
Signature....as far as I am aware...

My proposal in consequence is to keep the ds:Signature and require as 
first step the application of the Signature enveloped Transform as if it 
was the first transform appearing in the first ds:Reference child of the 
ds:Signature.

Regards
Juan Carlos

El 19/9/17 a las 20:19, Andreas Kuehne escribió:
> Hi Juan Carlos,
>
> before you invest time in a way to isolate a subtree out of a document
> using DOM please take into account that there are other ways of XML
> processing, like SAX or some type of language binding (e.g. JAXB in the
> Java space). We have to offer a well defined process that's easy to
> implement and language / framework independent. The flexibility of XML
> namespace declarations makes it very tricky to come up with a simple
> solution: A namespace declared on the root level is as valid as a
> declaration within the same element or within any element in between.
> And the namespace can be redeclared. That may happen before we reach the
> subtree we like to extract. Some of these inherited namespaces are
> required for the subtree,  the other MUST be dropped.I would guess we
> quickly end up in re-defining the namespace-related part of exclusive
> canonicalization! Maybe the complexity of this is topic is the reason
> why there isn't a simple method defined in the DOM specification.
>
> As I mentioned JAXB above: This is the XML of the 'plain vanilla' JAXB
> serialization of a DSS verification request:
>
>      <SOAP-ENV:Body>
>          <ns2:VerifyRequest
> xmlns:ns2="urn:oasis:names:tc:dss:1.0:core:schema"
>              xmlns:ns3="http://www.w3.org/2000/09/xmldsig#";
> xmlns:ns4="http://uri.etsi.org/019512/v1.0#";
>             
> xmlns:ns5="urn:oasis:names:tc:dss:1.0:profiles:asynchronousprocessing:1.0"
>              RequestID="TestIdSign--5492689337464250234">
>              <ns2:SignatureObject>
>                  <ns3:Signature>
>                     
> <ns3:SignatureValue>H3eXrKtSF/MPJnNMzWF1rgpLBla+ei687C+Btq3q0gIOuTZZcxJf+MPY3lucP2cnNiWTk+eLWLhp
> [...]
>
> As you can see there is the need to respect _some_ of namespace
> declarations given _outside_ of the relevant Signature object. So I
> would like to vote for a drop of this last resort of 'inlined XML'
> instead of taking the burden to define an extraction scheme.
>
> Greetings,
>
> Andreas