You might want to take a look at the following drafts:
An Extensible Message Format for Message Disposition Notifications
draft-ietf-receipt-mdn-05.txt
and
MIME-based Secure EDI
draft-ietf-ediint-as1-04.txt
The MDN draft decribes the specifics for request of and syntax for
repudiatable receipts. Request is at the RFC822 level of the
originating document, receipt is in multipart/report format, and
includes the original-message-id of the originating document.
The MIME-based Secure EDI draft adds non-repudiation to the MDN (it is
unfortunate that this was buried in the EDIINT draft, rather than
standing as a draft on its own merit), adding a hash of the original
message data within the multipart/report, and encasing the MDN in a
multipart/signed construct, signable using either S/MIME or PGP.
Regards,
Karen
Ian Brown wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Something which has been mentioned over the last few days, which I
also
think would be enormously useful, is the possibility to do secure
message receipts. When an OpenPGP client succesfully decrypts a
message
which has a flag set requesting a message receipt, it could mail back
a
secure receipt packet which would look something like the following
(this is just a very first draft, based on the current Signature
packet):
Header: We would need to choose a new packet ID number
Version number = 4
Length of following material included in MD calculation
|Signature classification
|Timestamp
|Some identification of the message receipt is for (e.g.
<1897(_dot_)877010412(_at_)cs(_dot_)ucl(_dot_)ac(_dot_)uk> as given in the
Message-ID: field of a
message). This could be flexible to allow for receipts for data
transferred using other protocols.
|Message digest algorithm
|Digest of message receipt is for
Key ID for key used for signing
Public-key cryptosystem type
Message digest algorithm
First two bytes of MD output as checksum
Signed digest of fields above marked with |
Does this sound feasible/desirable? If so, maybe this could go in the
second draft? I know we want to get the standard out ASAP, but this is
quite a simple and isolated proposal which shouldn't be too difficult
to
add in...
Ian.
-----BEGIN PGP SIGNATURE-----
Version: Cryptix 2.2.2
iQCVAgUBNEY5jJpi0bQULdFRAQEuJAQAnylXfYZ/FZosCvd0yCwtBoGC31WmBMLW
Pyff3tsOAqpuFxgMAtahnykEXOSs9AJJJOo7ER5AFUawja2/RVEbn7m3XELdTWZa
5QlenZ8Ac4U5OTpdLQvavsWClzAppD7WwaOj4+9aMau6QUMR6W0w7ZFYAr1OOzEr
e1oz3CtQ+L8=
=nVqZ
-----END PGP SIGNATURE-----
--
Karen Rosenthal Email: karenr(_at_)premenos(_dot_)com
Premenos Tel#: 1-510-688-2928
1000 Burnett Ave Fax#: 1-510-602-2133
Concord, CA 94520 Visit: http://www.premenos.com