[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
Am 23.04.13 16:58, schrieb Pim van der Eijk:
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).
in the core w.r.t processing suggestions and childelement <Base64XML> we specified in 3.3.1 step 1.b: " The data is processed and transforms applied by the server to produce a canonicalized octet string as required in [XMLDSIG] section 4.3.3.2. " and as we also accept <EscapedXML> and <InlineXML> we have more or less canonicalization in each case plus/minus same document references ... .
So, right, if <Base64Data> carries xml document content Aand another sign request content A inside <Base64XML> or one of its sisters <EscapedXML> and <InlineXML> the signatures might be different.
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
I also see this as a possible policy added on top. But as the original poster Daniel was not aware of any documentation for that implementation pointing this out, we tried to understand it in isolation.
So I agree with Pim's hint and see use cases that profit from it, but would OTOH as a user expect to have such behaviors actively documented that such a message is really perceived as a hint by the client "being warned" and not as an irritation.
All the best, Stefan.
-----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 inclause2.4.2,where these two elements are specified. I copy theirspecifications below:" <Base64XML> [Optional] [Default] This contains a base64 string obtained after base64encoding of a XMLdata. 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 ofdata is specified by its MimeType attribute, that may berequiredwhen using DSS with other signature types." The first sentence specifying the contents of<Base64Data> seems tome the reason for this behaviour: as the standard seemsto mandateNOT XML here, I would say that the application ischecking that thisrequirement is actually satisfied, which I personallyfeel it isreasonable.....I am aware that my understanding is notbuilt on any"MUST" or "MUST NOT", in which case it would beunarguable...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 andalso 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 --------------------------------------------------------------------- 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]