You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered: