OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x-comment message

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


Subject: Your issue DSSX-13: TransformedDocuments


Hi Juan Carlos,

happy new year!

As the holidays are over I'm about to solve all the remaining open
issues that stacked up in the DSS-X issue tracker. Here I found the item
DSSX-13 (https://issues.oasis-open.org/browse/DSSX-13) filed by you.
Here is subject:

    2. RequestTransformedDocument.

    DSS Core 1.0.
    This element does not seem to work in the case that the request
    contains more than one XML (XAdES) signatures. It only contains one
    attribute for identifying the number of a ds:Reference. And the text
    only speaks about "the" XML signature. If the text is changed to
    make it clear that the integer i value in the attribute corresponds
    to that ds:Reference that occupies the ith position once the request
    has been serialized, then this could work.

You pointed out a quite relevant topic! While considering the impact of
multi-signature input we stumbled about this topic, too. Here are my
concerns regarding (Return)TransformedDocument:

- The optional input 'ReturnTransformedDocument' refers to
transformations only, not to signatures. A SignaturePtr is missing here.

- The optional output 'TransformedDocument' refers to transformations
only, not to signatures. A SignaturePtr is missing here.

-The byte zone selection mechanism of PDF signatures can be considered
to be a transformation, too. So it should be represented by
TransformedDocument. The element 'WhichReference' of optional output
'TransformedDocument' is mandatory what's not matching the PDF case.

Solving these requirements adds additional complexity to the core. This
leads to the questions 'What does the user get in return'?
I'm not quite sure about the use case of the TransformedDocument
mechanism at all. Is it a debug feature to track down failed
validations? Wouldn't it also be useful to request partial
transformations? What client is able to interporet the different
transformation elements within a XMLDSig and take advantage of the
transformed documents _but_ cannot transform on its own? What about
confidentiality? A decryption transformation applied may reveal secret
information.

As you pointed out these shortcomings are in place since DSS 1.0 and no
one ever complained. So I would assume that this feature is of no/low
practical use!

My proposal is to drop the 'transformed' feature from the core as the
detail level of the output is a better match for the validation
protocol. What's your view?



Greetings,


Andreas

-- 
Andreas KÃhne phone: +49 177 293 24 97 mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas KÃhne

Company UK Company No: 5218868 Registered in England and Wales 




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