Jim,
However, if an
RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData
type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the
SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET
STRING). Therefore, the message digest is computed using only the
value octets of the Receipt SEQUENCE encoding.
[Jim wrote: I have a minor issue with the last sentence. The digest must
include
the type and length bytes of the SEQUENCE and I don't believe that this
is correctly stated in the text. Suggest: "Therefore, the message
digest is computed using the entirety of the Receipt SEQUENCE encoding."]
I agree that when an RFC 2634 [ESS] signed receipt is encapsulated in the
CMS signedData type, then the message digest is computed using the entire
Receipt SEQUENCE encoding (as specified in RFC 2634 and RFC 2630). However,
when a signed receipt is encapsulated in the PKCS #7 signedData type, then
RFC 2315 (PKCS #7), Section 9.3 (see below) specifies that the message
digest is computed using only the value octets (not the identifier octets or
the length octets) of the "content being signed" (i.e. Receipt SEQUENCE
encoding).
When we performed signed receipt interoperability testing between the S/MIME
Freeware Library (SFL) and Microsoft, the Microsoft implementation was
initially encapsulating the signed receipt in a PKCS #7 signedData type.
When creating a PKCS #7 signed receipt, the Microsoft implementation encoded
the Receipt SEQUENCE in the SignedData contentInfo content ANY field (a
SEQUENCE, not an OCTET STRING) and calculated the message digest using only
the value octets of the Receipt SEQUENCE encoding. Once we modified the SFL
to accept this format, then we were able to decode and verify the Microsoft
PKCS #7 signed receipt. Please note that Microsoft later generated a
CMS<< signed receipt that we were able to decode and verify using the SFL
without any special modifications.
RFC 2315 (PKCS #7), Section 9.3:
"9.3 Message-digesting process
The message-digesting process computes a message digest on either the
content being signed or the content together with the signer's
authenticated attributes. In either case, the initial input to the
message-digesting process is the "value" of the content being signed.
Specifically, the initial input is the contents octets of the DER
encoding of the content field of the ContentInfo value to which the
signing process is applied. Only the contents octets of the DER
encoding of that field are digested, not the identifier octets or the
length octets."
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================