D.2  Non-repudiation of receipt (FCO_NRR)

Non-repudiation of receipt defines requirements to provide evidence to other users/subjects that the information was received by the recipient. The recipient cannot successfully deny having received the information because evidence of receipt (e.g. digital signature) provides evidence of the binding between the recipient attributes and the information. The originator or a third party can verify the evidence of receipt. This evidence should not be forgeable.

User notes

It should be noted that the provision of evidence that the information was received does not necessarily imply that the information was read or comprehended, but only delivered

If the information or the associated attributes are altered in any way, validation of the evidence of receipt with respect to the original information might fail. Therefore a PP/ST author should consider including integrity requirements such as FDP_UIT.1 Data exchange integrity in the PP/ST.

In non-repudiation, there are several different roles involved, each of which could be combined in one or more subjects. The first role is a subject that requests evidence of receipt (only in FCO_NRR.1 Selective proof of receipt ). The second role is the recipient and/or other subjects to which the evidence is provided, (e.g. a notary). The third role is a subject that requests verification of the evidence of receipt, for example, an originator or a third party such as an arbiter.

The PP/ST author must specify the conditions that must be met to be able to verify the validity of the evidence. An example of a condition which could be specified is where the verification of evidence must occur within 24 hours. These conditions, therefore, allow the tailoring of the non-repudiation to legal requirements, such as being able to provide evidence for several years.

In most cases, the identity of the recipient will be the identity of the user who received the transmission. In some instances, the PP/ST author does not want the user identity to be exported. In that case, the PP/ST author must consider whether it is appropriate to include this class, or whether the identity of the transport service provider or the identity of the host should be used.

In addition to (or instead of) the user identity, a PP/ST author might be more concerned about the time the information was received. For example, when an offer expires at a certain date, orders must be received before a certain date in order to be considered. In such instances, these requirements can be customised to provide a timestamp indication (time of receipt).