ietf-smime
[Top] [All Lists]

RE: ESS : Secure Receipt encoding within EncapsulatedContentInfo

2000-03-27 20:06:49
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

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