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

[Stefan Drees <stefan@drees.name>]

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
> (http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.pdf)
> 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:

A)
Given e.g.
<Base64Data>PHNhbXBsZT5IZWxsbywgd29ybGQhPC9zYW1wbGU+</Base64Data>

B)
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."

C)
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