Not sure if it is a single problem and not caused by something else, but it seems like the XAdESCC does not take into account the order of xades:Include elements within a xades:IndividualDataObjectsTimeStamp element.
The order is essential here, because it defines the order in which the ds:Reference elements are processed for message-imprint computation, in opposite to xades:AllDataObjectsTimeStamp, where references are taken in their order of appearance within a ds:SignedInfo element.
See 5.1.4.4.2 Include mechanism of ETSI EN 319 132-1:
Include elements shall explicitly reference data objects that contribute to the input of the electronic time-stamp's
message imprint computation, and consequently are time-stamped by the electronic time-stamp.
The order of appearance of the Include elements shall indicate the order in which the referenced data objects
contribute to the input of the electronic time-stamp's message imprint computation.
We have also discussed this moment within our email exchange and you agreed to clarify the message-imprint computation within the clause "5.2.8.2 The IndividualDataObjectsTimeStamp qualifying property".
I attach two files causing a validation error in Conformance Checker, one with the same signed references order as in ds:SignedInfo, and the second one with a changed order. Both of them fail currently, but I believe it can be caused by the issue #2 , which fix has not been included yet in production. But nevertheless, the CC computes the same message-imprint in both cases, when it is clearly must be different due to a different order of xades:Include elements.
Dear Juan Carlos,
Not sure if it is a single problem and not caused by something else, but it seems like the XAdESCC does not take into account the order of xades:Include elements within a xades:IndividualDataObjectsTimeStamp element.
The order is essential here, because it defines the order in which the ds:Reference elements are processed for message-imprint computation, in opposite to xades:AllDataObjectsTimeStamp, where references are taken in their order of appearance within a ds:SignedInfo element.
See 5.1.4.4.2 Include mechanism of ETSI EN 319 132-1:
We have also discussed this moment within our email exchange and you agreed to clarify the message-imprint computation within the clause "5.2.8.2 The IndividualDataObjectsTimeStamp qualifying property".
I attach two files causing a validation error in Conformance Checker, one with the same signed references order as in ds:SignedInfo, and the second one with a changed order. Both of them fail currently, but I believe it can be caused by the issue #2 , which fix has not been included yet in production. But nevertheless, the CC computes the same message-imprint in both cases, when it is clearly must be different due to a different order of xades:Include elements.
Best regards, Aleksandr.
IndividualDataObjectsTimeStamp.zip