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

[Andreas Kuehne <kuehne@trustable.de>]

Hi Juan Carlos,

> 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.
>
as far as I understand this transformation it drops an embedded
signature to enable the reference evaluation of the enveloping document.
So it does exactly the opposite, it drops a subtree instead of
extracting the subtree. So no effects of inherited namespaces. 
See the samples given in
https://stackoverflow.com/questions/24961073/is-that-what-exactly-does-the-enveloped-signature-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).
In the advanced XMLDSig (e.g. XAdES) case there are several references
in use. E.g. one for the enveloping document (using the transformation
mentioned above) and one or more references pointing to stuff inside the
ds:Object, e.g. the SignedProperties.
>
> 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.
>
The 'enveloped-signature' transformation is used in a reference to the
surrounding document, not for the elements inside the ds:Object.

> 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...
I don't gave the snippet of the JAXB output to suggest that there is
something wrong but as an example of possible valid ways of namespace
definitions. It's a valid way to define the namespaces but shows that a
simple cut-out of a subtree won't do the job! That#s why the exclusive
conicalization defines such a complex procedure of namespace handling.
>
> 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.
I don't consider it a good approach to drop the signature from
dss:SignatureObject!

Should we try to meet on a web conference? My favorite day is Wednesday ...

Greetings,

Andreas
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales