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 and Stefan,

Sorry for jumping in the thread....

Maybe the reason for this behaviour could be found in clause 2.4.2, where these two elements are specified. I copy their specifications below:

" <Base64XML> [Optional] [Default]
This contains a base64 string obtained after base64 encoding of a XML data. The server MUST decode it to obtain the XML data."

"<Base64Data> [Optional]
This contains a base64 encoding of data that are not XML. The type of data is specified by its MimeType attribute, that may be required when using DSS with other signature types."

The first sentence specifying the contents of <Base64Data> seems to me the reason for this behaviour: as the standard seems to mandate NOT XML here, I would say that the application is checking that this requirement is actually satisfied, which I personally feel it is reasonable.....I am aware that my understanding is not built on any "MUST" or "MUST NOT", in which case it would be unarguable...

As for 3.3.4, I only say text that requires base-64 decoding and the requirement not to do any change to the octet string before hashing it....one could argue that somehow there could be a mismatch between this process and a strict reading of the <Base64Data> specification, sd the intermediate step of checkin ghat the result is not XML, is not present.....


Juan Carlos.

El 23/04/2013 12:11, Stefan Drees escribió:
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
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

To unsubscribe, e-mail: dss-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dss-dev-help@lists.oasis-open.org

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