Unless my user agent is running on an A1 trusted system that is NOT under my
control, how can you prevent me from refusing delivery? If you are sending me
my draft notice, or a subpoena, what is to prevent me from seeing the return
address and refusing to accept the message?
Bob, Valdis,
You are both asserting the same thing, I believe. And of course
it not practicable. The point is to get both parties to *willingly*
agree that delivery event X happened. This is a useful practical
property for commercial messaging.
Here are some definitions to help. The following text is quoted
from X.400 (88) and F.435. The Web/mime is providing a prefect
vehicle for realizing commerce-related services in the US
telecomms market. The evolving end-to-end Web commerce & payment
system is furthermore completely independent of the underlying
transport layer security or network-level directories. And so
it should be.
Dont get me wrong; I'm not advocating these protocols in the US.
These are definitions which do demonstrate, however, how X.400
security design evolved through experience of the vulnerabilities.
Hope they help.
Peter.
From X.402:
10.2.5.3 NonÑrepudiation of Delivery security service
This security service provides the originator of the message with
irrevocable proof that the message was delivered to its originally specified
recipient(s).
From F.435:
The security services as defined in Recommendation X.402 are:
- non-repudiation of origin;
- non-repudiation of submission ;
- non-repudiation of delivery.
These security services only cover some areas of transfer
between
EDIM responsibility domains, which may be of significance in an EDIMG
environment (as illustrated in Figure C.1/F.435). Areas which are not
covered by security services provided in 1988 for message handling include:
- between EDIMG user domains (i.e., end-to-end);
- between MTS management domains;
between an EDI message store and a recipient EDI-UA.
Therefore services and/or pervasive mechanisms defined in this
Recommendation cover the above deficiencies:
- non-repudiation/proof of transfer;
- non-repudiation/proof of retrieval;
- non-repudiation/proof of edi notification;
- non-repudiation/proof of content.
-Non-repudiation/proof of transfer+ counters the vulnerability of
repudiation of responsibility between MTA and/or management domains.
EDIMG environments may provide such a service using additional
pervasive mechanisms, such as security logs and archives within MTA and/or
MTS boundaries. Such pervasive mechanisms provide a -secure MT audit trail+
to record the message details and trace information.
-Non-repudiation/proof of retrieval+ counters the
vulnerability
of repudiation of responsibility of a message between a UA and an MS. EDIMG
environments may provide such a service using additional pervasive
mechanisms, such as security logs and archives within EDI-MSs. Such
pervasive mechanisms provide a -secure EDI-MS audit trail+ to record EDIMG
user actions in the EDI message store.
-Non-repudiation/proof of EDI notification+ counters the
vulnerability of repudiation of an EDI notification EDI-UA to EDIUA. This
service is specific to EDIMG and a complete solution is included in this
Recommendation. This vulnerability may be especially relevant in
the case of EDI forwarding, redirection,
etc, in addition to the scenario of delivery to an untrusted EDI message
store.
Two mechanisms have been defined for non-repudiation of EDI
notifications, the first uses the trusted EDI notification as
described above, the second using an external notary systems. Only the
trusted EDI notification was fully defined in this
Recommendation. External notary systems may be the subject of future
standardization.
-Non-repudiation/proof of content+ counters the vulnerability
of
manipulation of information by the EDIMG user after the message has been
received by the EDI-UA. Although such vulnerability is outside the MHS
environment, the MHS environment may provide assistance in terms of
trusted return of content and notarization services. There are several ways
this requirement may be supported, using the secure messaging environment
based on the security services provided in 1988.
Firstly non-repudiation of content by the originating EDI-UA
may be
provided by the existing -Non-repudiation of Origin+ Security service.
Secondly non-repudiation of content by the recipient EDI-UA
may be
provided by returning the subject content within the EDI notification and
submitting the EDI notification to the MTS using the -Non-repudiation of
Origin+ Security services.
Thirdly by notarization services, such services may be
achieved by
forwarding messages via a mutually trusted third-party notary (i.e., using
existing MHS security services).
All three approaches would thus require no modification to the secure
messaging environment based on the existing MHS Recommendations.
Note---Non-repudiation services (which may imply
the involvement
of a third party) are considered stronger than -proofof+ services.