OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi Andreas,

You know that XML Signature Recommendation specifies the so-called Enveloped Signature Transform

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.

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:


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]