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


Help: OASIS Mailing Lists Help | MarkMail Help

dss-dev message

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

Subject: Re: [dss-dev] Data format guessing of data within Base64Data tag

Dear Daniel,

On 23.04.13 11:14, Daniel Martín Lambea wrote:
... I have found an implementation of the DSS standard that refuses to sign
an octet stream provided as base 64 string within a
<dss:Base64Data>...</dss:Base64Data> tag, as long as the octet stream
can be interpreted as XML. In other words, if one tries to provide a
base64 encoding of the following sample string '<sample>Hello,
world!</sample>' into the <dss:Base64Data> tag, the implementation
denies the signing operation with an error saying that "The data is XML
and therefore must be provided within <Base64XML> tag".

AFAIK, the standard
paragraph 3.3.4, "Process variant for <Base64Data>" says that the octed
stream must not be processed. The ambiguity here is in the parsing that
the implementation is doing for the provided base64 data. "Parsing" is
not "processing", as far as no modification is being performed over the
data. But since the implementation is trying to guess the format of the
data, no signing operation can be done over an arbitrary octet stream,
whenever the octet stream has XML look & feel.

Is that implementation correct? I mean, is the implementation
responsible of parsing the octet stream within Base64Data to ensure it
MUST NOT be XML data?

The spec says the server SHOULD perform the steps described in 3.3.1. So it is more or less common sense that rules conformance here.

To summarize my understanding of the implementations behavior (alwas curious which implementation we are toalking about ...?) is:

Given e.g.

the server implementation decodes the data to:
octet-string-of('<sample>Hello, world!</sample>')
which is compliant with 3.3.4 step 1.a: "The server base64-decodes the data contained within <Document> into an octet string."

then parses it as xml?
Here 3.3.4 step 1.b states "No transforms or other changes are made to the octet string before hashing."
Yes. Parsing is compliant, as it operates on a copy (conceptually).

But back to common sense: Why does it do so?

Without any further context I find it rather strange, that the processor parses a document as xml, which is submitted as data in a "language (dss)" that offers three alternative containers for XML content: If the client had requested the parsing, it might have used EscapedXML, InlineXML or Base64XML instead in the first place.

Coming back to the implementation "quest": Maybe this is a mix-in from some local policy the implementation has to enforce?

Please share any details with the list or me about the implementation if further help is needed. I enjoy reading the source of core implementations ;-)

All the best,
Stefan Drees

Kind regards,
Daniel M. Lambea

Unidad Orgánica de Desarrollo
Instituto Insular de Informática y Comunicaciones
Excmo. Cabildo Insular de Tenerife
C/ Clavel, Nº2, 38003 Santa Cruz de Tenerife
Tfno. 922239362

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