ietf-smime
[Top] [All Lists]

RE: Questions on Signed Receipts

1998-05-19 14:58:47
Larry (and friends),

Recommend that the following text be added to Section 2.4, item 11: "The ESS
signed receipt includes the message digest value calculated for the original
signedData object that requested the signed receipt.  If the original
signedData object was sent encrypted within an envelopedData object and the
ESS signed receipt is sent unencrypted, then the message digest value
calculated for the original encrypted signedData object is sent unencrypted.
The responder should consider this when deciding whether or not to encrypt
the ESS signed receipt."

I don't believe that any stronger wording is justified.  I disagree that ESS
should mandate that a signed receipt MUST always be encrypted when
responding to a encrypted signedData object.  I believe that this should be
an optional feature.  Organizations would not need to develop tailored
applications.  The COTS S/MIME v3 products should provide this as an
optional feature that is activated by a value in a configuration file.  If
this strategy were followed, then no custom SW development would be required.

- John Pawling 


At 08:35 AM 5/19/98 -0500, Larry Layten wrote:
John,

I disagree with you. Since what this standard is trying to do
is to allow implementers to utilize any UA to achieve basically
the same functionality -- not to make an organization develop
tailored applications to meet their needs (even the paranoid
ones). 

I also believe that there are occasions and applications where
in fact there would be too much information to assure a secure
environment without encrypting the signed return receipt, 
especially since the hash of the original message is contained
in it.

Larry

-----Original Message-----
From:  John Pawling [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent:  Tuesday, May 19, 1998 7:13 AM
To:    Jim Schaad (Exchange); Ietf-Smime (E-mail)
Subject:       RE: Questions on Signed Receipts

Jim,

I believe that it is an extremely low probability that an attacker could
gain any information of value from analyzing an unencrypted signed receipt.
Therefore, I don't believe that ESS should encourage the encryption of
signed receipts.  However, I don't believe that ESS should prohibit the
encryption of signed receipts either.  IMHO, it should be a matter of local
policy.  If an organization is paranoid enough to require that signed
receipts must be encrypted, then they can pay the performance cost of
encrypting the signed receipts.  I do not believe that encrypting signed
receipts should be the deafult mode documented in ESS.  In summary, I
believe that ESS should remain unchanged regarding this topic.

- John Pawling


At 04:33 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
John,

If you are suggesting that this is a matter of local policy, it is my belief
that most clients will never encrypt a secure receipt back.  I am not sure
that this is better than over encrypting.  Would adding a statement that it
should be done unless local policy says otherwise be ok?

On point 2 I was really asking about expectation rather than about what is
permitted/prohibitted.  I agree that the current state of non-prohibition
should remain, I was just asking if people thought that SMimeCapabilities is
expected in a signed receipt message.

jim


-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
Sent: Monday, May 18, 1998 2:41 PM
To: Ietf-Smime (E-mail)
Subject: Re: Questions on Signed Receipts


Jim,

1. I respectfully disagree with your proposed text for Section 2.4, item 11.
I believe that the decision to encrypt a signed receipt should be a matter
of local policy.  The "SHOULD" requirement in your recommended text would
cause local organizations and implementors to decide to encrypt signed
receipts more often than not.  IMHO, it is wasteful to encrypt signed
receipts.

2. I believe that any of the S/MIME attributes could be included in a signed
receipt (except for receiptRequest).  This is what ESS currently states.
For many of the attribute types (such as ESSSecurityLabel), it doesn't make
sense to include them in a signed receipt, but I don't see any reason why
ESS should specifcally prohibit their inclusion.

================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 12:59 PM 5/18/98 -0700, Jim Schaad (Exchange) wrote:
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





<Prev in Thread] Current Thread [Next in Thread>