RE: Comments on draft-ietf-smime-rfc2630bis-03

["Jim Schaad" <[e-mail]>]

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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Pawling, John
> Sent: Wednesday, September 19, 2001 1:44 PM
> To: '[e-mail]'; 'Housley, Russ'
> Cc: [e-mail]
> 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, [e-mail]
> Getronics Government Solutions, LLC
> ===========================================
>