Subject: RE: ESS : Secure Receipt encoding within EncapsulatedContentInfo

From: Pawling, John <[email-masked]>
Date: Thu, 16 Mar 2000 13:41:23 -0500

Cameron,
 
The signedData encapContentInfo eContent field is defined as an OCTET STRING
in RFC 2630 (CMS).   If the eContent field is present, then the OCTET STRING
tag and length octets must be present in the encoding of the signedData.
RFC 2630 Section 2 states: "As a general design philosophy, each content
type permits single pass processing using indefinite-length Basic Encoding
Rules (BER) encoding." and "Signed attributes and authenticated attributes
are the only CMS data types that require DER encoding."  Therefore, the
signedData content type (including the encapContentInfo eContent OCTET
STRING tag and length octets) does not need to be DER-encoded.  
 
As you correctly point out, RFC 2634 (ESS) requires that the Receipt content
type must be DER-encoded within the signedData encapContentInfo eContent
OCTET STRING.

============================================ 
John Pawling, Director - Systems Engineering 
J.G. Van Dyke & Associates, Inc; 
a Wang Government Services Company 
[email-masked] <mailto:[email-masked]>  
============================================ 

-----Original Message-----
From: Cameron Stillion [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Thursday, March 09, 2000 9:15 PM
To: [email-masked]' <mailto:[email-masked]'> 
Cc: [email-masked]'; Bryan Staats
Subject: ESS : Secure Receipt encoding within EncapsulatedContentInfo

... and now for something completely different:
 
According to the ESS RFC on page 16, step 9:
 
9.  The ASN.1 DER encoded Receipt content MUST be directly encoded within
the signedData encapContentInfo eContent OCTET STRING defined in [CMS].
 
Should eContent be a DER-encoding of the receipt?
    or
Should eContent be a DER-encoding of an OCTET STRING containing the
DER-encoding of the receipt?
 
The word "directly" seems to indicate that the former is the correct one.
Just tell me I'm not crazy.
 
Cameron Stillion

---

From: Pawling, John <[email-masked]>
Date: Mon, 27 Mar 2000 22:08:34 -0500

Jim,

I agree with all of your statements except for bullet #3.  You stated that
the OCTET wrapping can be omitted if an ESS receipt content-type is
encapsulated within a PKCS#7 signedData.  This would cause severe
interoperability problems with an RFC 2630/RFC 2634 (a.k.a. CMS/ESS)
implementation such as the S/MIME Freeware Library.    

RFC 2630 (CMS) defines EncapsulatedContentInfo as follows:
 EncapsulatedContentInfo ::= SEQUENCE {
      eContentType ContentType,
      eContent [0] EXPLICIT OCTET STRING OPTIONAL }

If the eContent field is present, then the OCTET STRING tag and length
octets must be present in the encoding of the signedData.
 
RFC 2634 (ESS), Section 2.4, bullet 9 states: "The ASN.1 DER encoded
Receipt content MUST be directly encoded within the signedData
encapContentInfo eContent OCTET STRING defined in [CMS]."

Notice the text "defined in [CMS]".  A valid encoding of an ESS signed
receipt MUST contain the signedData encapContentInfo eContent OCTET STRING
tag and length octets.  If the eContent OCTET STRING tag and length octets
are omitted (as you suggest in your message), then a CMS/ESS implementation
cannot decode the message.

There is no text in ESS that addresses the inclusion of a receipt content in
a PKCS #7 signedData.  If there was such text, it would need to state that
the ASN.1 DER encoded Receipt content MUST be directly encoded within an
OCTET STRING within the PKCS #7 signedData contentInfo content
defined in PKCS #7.  This is the only way (without changing the CMS
encapContentInfo eContent syntax) that signed receipt interoperability can
be achieved between CMS/ESS and PKCS #7/ESS implementations.  

If you believe that there will be PKCS #7/ESS implementations that are
sending signed receipts, then the aforementioned text needs to be included
in RFC 2634.

Thank you for your feedback,
-John Pawling