John,
I re-examined this and I agree that you are correct and that the
language in the updated draft is correct.
Interestingly, I now understand the reason that all new content infos
are required to NOT start with a CHOICE. Specifically the tag
representing the choice is not covered by the signature and thus is open
to changing under the PKCS#7 rules (but not under the updated CMS
rules).
I don't know that there are any advantages to removing the requirement
from the updated CMS draft, but it is certainly no longer needed as the
byte is now covered by the signature (and is one less odd ball statement
to have around).
jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Pawling,
John
Sent: Wednesday, September 19, 2001 1:44 PM
To: 'jimsch(_at_)exmsft(_dot_)com'; 'Housley, Russ'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
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
===========================================