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

[Daniel Martín Lambea <dmlambea@tenerife.es>]

Dear Stefan,

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

The implementation I'm talking about is an internal project from the Spanish Public Administration.

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

This is exactly the point. I don't find any valid reason for the implementation to do so. Furthermore, it increases complexity around the signing process, since one has to keep a parser around every octet stream that is to be signed.

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

Well, actually I filed a bug report regarding this weird behavior, but implementors keep saying the standard enforces XML data to come within it's proper tag and therefore the usage of XML octet streams within Base64Data is prohibited. I think that ANY octet stream should be signed without further considerations as long as it comes within <Base64Data>. My bug report is being rejected due to their interpretation of the standards.

> Coming back to the implementation "quest": Maybe this is a mix-in from 
> some local policy the implementation has to enforce?

I don't think it's the case, but rather an interpretation of the DSS-core document.
 
> 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 ;-)

There is a chance for the software to be licensed under a OSS licence, but I don't know if this will finally come true or not. I hope so! Anyway, in case the software became publicly available, I'd drop you a note. :-)

Kind regards,
Daniel M. Lambea