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
john(_dot_)pawling(_at_)wang(_dot_)com
<mailto:john(_dot_)pawling(_at_)wang(_dot_)com>
============================================
-----Original Message-----
From: Cameron Stillion [ mailto:camerost(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com
<mailto:camerost(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com> ]
Sent: Thursday, March 09, 2000 9:15 PM
To: 'ietf-smime(_at_)imc(_dot_)org' <mailto:'ietf-smime(_at_)imc(_dot_)org'>
Cc: 'phoffman(_at_)imc(_dot_)org'; 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