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

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

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.....

Regards

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
> > 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dss-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dss-dev-help@lists.oasis-open.org