RE: Comments on draft-ietf-smime-rfc2630bis-03
"Pawling, John" <John.Pawling@GetronicsGov.com> Wed, 19 September 2001 21:18 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11229 for <smime-archive@odin.ietf.org>; Wed, 19 Sep 2001 17:18:41 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id f8JKhqj10065 for ietf-smime-bks; Wed, 19 Sep 2001 13:43:52 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8JKhpD10061 for <ietf-smime@imc.org>; Wed, 19 Sep 2001 13:43:51 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052Y4BL>; Wed, 19 Sep 2001 16:43:58 -0400
Message-ID: <0B95FB5619B3D411817E006008A59259B51BC2@wfhqex06.gfgsi.com>
From: "Pawling, John" <John.Pawling@GetronicsGov.com>
To: "'jimsch@exmsft.com'" <jimsch@exmsft.com>, "'Housley, Russ'" <rhousley@rsasecurity.com>
Cc: ietf-smime@imc.org
Subject: RE: Comments on draft-ietf-smime-rfc2630bis-03
Date: Wed, 19 Sep 2001 16:43:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
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.Pawling@GetronicsGov.com Getronics Government Solutions, LLC ===========================================
- Comments on draft-ietf-smime-rfc2630bis-03 Jim Schaad
- Re: Comments on draft-ietf-smime-rfc2630bis-03 Housley, Russ
- RE: Comments on draft-ietf-smime-rfc2630bis-03 Jim Schaad
- RE: Comments on draft-ietf-smime-rfc2630bis-03 Pawling, John
- RE: Comments on draft-ietf-smime-rfc2630bis-03 Jim Schaad