ietf-smime
[Top] [All Lists]

Re: Receipts

1997-11-11 06:20:39
Rich,

The security services provided by the PKCS #9 countersignature attribute and
CMS/ESS signed receipt are very different.   The purpose of the CMS/ESS
signed receipt is to prove to the originator that the recipient was able to
verify the signature of the original message.  In order to verify the
signature of the original message, the recipient must actually receive the
content of the original message.  To form the signed receipt signature, the
recipient must first hash the original content and Receipt content.  When
the originator verifies the signature of the signed receipt, that proves to
the originator that the recipient actually received the content of the
original message because that is the only way that the recipient could have
successfully generated the signed receipt signature.

A PKCS #9 countersignature is calculated solely on the hash of the signature
value of the original message.  The countersignature can be calculated by an
entity that never receives the content of the original message.  That is the
important difference between the security services provided by the PKCS #9
countersignature and CMS/ESS signed receipt.

In summary, I believe that we should not change the signed receipt syntaxes
and text included in ESS (other than adding clarifying text regarding
multiple receiptRequests included in a signedData object as discussed in
previous messages on the list). 

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




At 08:33 PM 11/10/97 -0500, Rich Ankney wrote:
The receipt mechanism in ESS appears to be based on the MSP receipt.  There
are several draft standards in ANSI X9 and ASTM E31.20 (medical
informatics) that represent a receipt as a countersignature on the
originator's signature.  In PKCS #7 and PKCS #9 terms, a countersignature
is just a SignerInfo which signs the encryptedDigest field in another
SignerInfo.  It is carried as an unauthenticated attribute in this
enclosing SignerInfo.  While I'm not proposing adding this to ESS, I was
wondering if anyone sees any problems with this approach.

Regards,
Rich



<Prev in Thread] Current Thread [Next in Thread>
  • Receipts, Rich Ankney
    • Re: Receipts, John Pawling <=