In working through some of the implementation issues for signed receipts I
ended up with two questions:
1. We say what to do if you need to encrypt a signed receipt, however we
don't provide any guidance on when a signed receipt should be encrypted.
While this can be said to be a user agent policy decision, I would like to
make sure that is the correct answer. I can see alot of arguments for
attempting to encrypted the returned receipt if the message came in
encrypted. There is information which is shown in the receipt which was not
in the orginal encrypted message and is therefore a source of data leak.
How significant this data is in the real world is a different question.
To start the discussion: Recommend that Section 2.4 item 11 be modified by
appending the following sentences. "Signed receipts SHOULD be encrypted if
possible if the receipt request was also encrypted. The receipt SHOULD be
sent without encryption if no key can be found for receipt receipients."
2. Do we think that the standard additional S/MIME signature attributes
should be added to signed receipts? My initial response to this is to say
yes. It provides an interesting way to collect certificates and S/MIME
capibilities however. Send a receipt request to lots of people and you may
get back lots of certificates to be automatically updated in your address
book. The main reason for saying no is size of the receipt -- there is no
need to include your encrypt certificates, S/MIME capabilities and any other
interesting information not immeadiately relevent to the signature on the
receipt.
jim