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

["Pim van der Eijk" <lists@sonnenglanz.net>]

Would a DSS server canonicalize the XML prior to signing it?
(Sorry I've not worked on DSS for quite some time so I don't
remember how this was done).

Then not allowing XML in Base64Binary may be a way to warn
users that no such canonicalization is applied and/or to
prevent different results depending on how the XML to be
signed was passed in.

Pim

-----Original Message-----
From: Stefan Drees [mailto:stefan@drees.name] 
Sent: 23 April 2013 16:18
To: dss-dev@lists.oasis-open.org
Subject: Re: [dss-dev] Data format guessing of data within
Base64Data tag

On 23.04.13 14:33, Daniel Martín Lambea wrote in response to
Juan Carlos Cruellas mail:
> ...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...
>
> Then the ambiguity lies in 2.4.2. For what I understand,
the <Base64Data> tag is defined for everything that is not
_necessarily_ XML.
> <Base64XML> seems specially designed for XML while
<Base64Data> is just for plain data. I don't see the rule
that enforces mutual exclusion between both tags.
>
> IMHO, if there is not "MUST NOT" in the definition and
also there is no checking step defined in the processing,
the simplest thing is not to parse the octet stream.
> ...

first of all it should be clear, that no direct violation of
conformance is notable.

But, the reason for inventing Base64Data was not, to
certify, that the content is no XML. The motivation was: How
can we tunnel/embed something not being XML inside an xml
container for signing purposes?
Just imagine an intermediate version of an xml document
neither wel-formed not valid. How would you sign this as
"your version of thursday, say 1300 CEST :-?

As a server "programmer" I am still curious what might
motivate a service to parse something, the spec sees only as
data ... ?

All the best,
Stefan.


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