From owner-ietf-smime@mail.imc.org Mon Mar 1 00:27:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05692 for ; Mon, 1 Mar 2004 00:27:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i214jngA086558; Sun, 29 Feb 2004 20:45:50 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i214jnX0086556; Sun, 29 Feb 2004 20:45:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i214jmhp086550 for ; Sun, 29 Feb 2004 20:45:48 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 18396 invoked by uid 0); 1 Mar 2004 04:42:34 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 1 Mar 2004 04:42:34 -0000 Message-Id: <5.2.0.9.2.20040229232208.03e787f0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 29 Feb 2004 23:45:49 -0500 To: "Blake Ramsdell" , From: Russ Housley Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have six comments. None of them are show stoppers. 1. Section 1,1, 1st sentence: s/draft/document/ 2. Should Section 1,2 reference RFC 3369? 3. Section 1.4: s/MD2 use for certificate signatures discouraged/The use of the MD5 message digest for certificate signatures is discouraged/ 4. Delete Section 1.5 before submitting the document to the IESG. 5. Section 4.4.2 include the following paragraph: If the key usage extension is not specified, receiving clients MUST presume that the digitalSignature and nonRepudiation bits are set. Should there be an 'only' in this sentence? 6. Section 4.4.4, 2nd paragraph, last sentence. Add a period. Russ From owner-ietf-smime@mail.imc.org Mon Mar 1 00:48:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06991 for ; Mon, 1 Mar 2004 00:48:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i215GQlL087936; Sun, 29 Feb 2004 21:16:26 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i215GP8N087935; Sun, 29 Feb 2004 21:16:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i215GOL7087929 for ; Sun, 29 Feb 2004 21:16:25 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 24615 invoked by uid 0); 1 Mar 2004 05:13:11 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 1 Mar 2004 05:13:11 -0000 Message-Id: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 01 Mar 2004 00:16:27 -0500 To: "Blake Ramsdell" , From: Russ Housley Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hare are seven comments. I think number 6 is the most significant one, but none of them are show stoppers. 1. Should Section 1.4 reference RFC 3369? 2. Delete section 1.6 before the document is sent to the IESG. 3. Section 2.4 probably should point out that ContentInfo is needed to encapsulate each of the protection content types. 4. What compression algorithm MUST be implemented if CompressedData is supported? 5. Section 2.5.2: s/SMIMECapabilities attribute should/SMIMECapabilities attribute SHOULD/ 6. Section 2.6: the first two paragraphs are not clear. S/MIME v3.1 MUST support both issuerAndSerialNumber and subjectKeyIdentifier for sending and receiving. 7. Section 3.4.3.2: s/not currently supported in S/MIME/not currently recommended in S/MIME/ Russ From owner-ietf-smime@mail.imc.org Mon Mar 1 03:19:25 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00945 for ; Mon, 1 Mar 2004 03:19:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i217ejGM032071; Sun, 29 Feb 2004 23:40:46 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i217ejpn032068; Sun, 29 Feb 2004 23:40:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i217eiXY032045 for ; Sun, 29 Feb 2004 23:40:44 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 22075 invoked by uid 0); 1 Mar 2004 07:37:21 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 1 Mar 2004 07:37:21 -0000 Message-Id: <5.2.0.9.2.20040301023919.03e628a8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 01 Mar 2004 02:40:38 -0500 To: blake@brutesquadlabs.com, ietf-smime@imc.org From: Russ Housley Subject: Fwd: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ooops. Please excuse the typo in #3. It should read: 3. Section 1.4: s/MD2 use for certificate signatures discouraged/The use of the MD2 message digest for certificate signatures is discouraged/ Russ >Date: Sun, 29 Feb 2004 23:45:49 -0500 >To: "Blake Ramsdell" , >From: Russ Housley >Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt > >I have six comments. None of them are show stoppers. > >1. Section 1,1, 1st sentence: s/draft/document/ > >2. Should Section 1,2 reference RFC 3369? > >3. Section 1.4: s/MD2 use for certificate signatures discouraged/The use >of the MD5 message digest for certificate signatures is discouraged/ > >4. Delete Section 1.5 before submitting the document to the IESG. > >5. Section 4.4.2 include the following paragraph: > > If the key usage extension is not specified, receiving clients MUST > presume that the digitalSignature and nonRepudiation bits are set. > >Should there be an 'only' in this sentence? > >6. Section 4.4.4, 2nd paragraph, last sentence. Add a period. > >Russ From owner-ietf-smime@mail.imc.org Mon Mar 1 19:57:52 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17336 for ; Mon, 1 Mar 2004 19:57:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220XYAc060155; Mon, 1 Mar 2004 16:33:34 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i220XYVO060154; Mon, 1 Mar 2004 16:33:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.11/8.12.8) with SMTP id i220XV8j060145 for ; Mon, 1 Mar 2004 16:33:33 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@218.37.226.73 with plain) by smtp003.bizmail.yahoo.com with SMTP; 2 Mar 2004 00:33:36 -0000 Message-ID: <40449AEB.8060109@ieca.com> Date: Tue, 02 Mar 2004 09:32:11 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Housley CC: Blake Ramsdell , ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt References: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> In-Reply-To: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, For #4 ZLIB compression algorithm from RFC1950/1951 is a MUST in the RFC3274 do we need to say it again here? spt Russ Housley wrote: > > Hare are seven comments. I think number 6 is the most significant > one, but none of them are show stoppers. > > 1. Should Section 1.4 reference RFC 3369? > > 2. Delete section 1.6 before the document is sent to the IESG. > > 3. Section 2.4 probably should point out that ContentInfo is needed > to encapsulate each of the protection content types. > > 4. What compression algorithm MUST be implemented if CompressedData > is supported? > > 5. Section 2.5.2: s/SMIMECapabilities attribute > should/SMIMECapabilities attribute SHOULD/ > > 6. Section 2.6: the first two paragraphs are not clear. S/MIME v3.1 > MUST support both issuerAndSerialNumber and subjectKeyIdentifier for > sending and receiving. > > 7. Section 3.4.3.2: s/not currently supported in S/MIME/not currently > recommended in S/MIME/ > > Russ > From owner-ietf-smime@mail.imc.org Mon Mar 1 20:14:14 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18436 for ; Mon, 1 Mar 2004 20:14:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220u62J061928; Mon, 1 Mar 2004 16:56:06 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i220u6te061927; Mon, 1 Mar 2004 16:56:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i220u5ts061921 for ; Mon, 1 Mar 2004 16:56:05 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 23464 invoked by uid 0); 2 Mar 2004 00:52:38 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 2 Mar 2004 00:52:38 -0000 Message-Id: <5.2.0.9.2.20040301194955.02017f78@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 01 Mar 2004 19:56:05 -0500 To: "Sean P. Turner" From: Russ Housley Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Cc: Blake Ramsdell , ietf-smime@imc.org In-Reply-To: <40449AEB.8060109@ieca.com> References: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean: >For #4 ZLIB compression algorithm from RFC1950/1951 is a MUST in the >RFC3274 do we need to say it again here? Yes. The decision of the S/MIME WG more than a year ago was to put all of the mandatory to implement algorithms in this document. In this case, we need to say: If an implementation chooses to support compression, then the implementation MUST support the ZLIB compression algorithm. Russ From owner-ietf-smime@mail.imc.org Mon Mar 1 21:23:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23559 for ; Mon, 1 Mar 2004 21:23:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2220Zvb066590; Mon, 1 Mar 2004 18:00:35 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2220ZTe066586; Mon, 1 Mar 2004 18:00:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from falcon.verisign.com (falcon.verisign.com [216.168.239.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2220Xnk066578 for ; Mon, 1 Mar 2004 18:00:34 -0800 (PST) (envelope-from shollenbeck@verisign.com) Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id i2221uop002377; Mon, 1 Mar 2004 21:01:56 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 21:00:36 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02BF9A93@vsvapostal8.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "'Russ Housley'" , "'Sean P. Turner'" Cc: "'Blake Ramsdell'" , "'ietf-smime@imc.org'" Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Date: Mon, 1 Mar 2004 21:05:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If an implementation chooses to support compression, then > the implementation MUST support the ZLIB compression > algorithm. > > Russ Something to consider: ZLIB (RFC 1950) and DEFLATE (RFC 1951) are NOT the same thing. I ran into a small bit of specification confusion (thankfully caught by Ned Freed) when my TLS compression draft went through IESG review. It might be worth noting Ned's comments so that rfc2633bis specifies the algorithm you intend: "First of all, it is important to realize that RFC 1950 and RFC 1951 specify two things: (1) A compression scheme and corresponding format called DEFLATE (1951) and (2) A general wrapper format for compressed data called ZLIB (1950). I believe most compression applications simply use the DEFLATE format and don't bother with the extra wrapper and most of our specifications that do this refer to deflate and RFC 1951 rather than zlib and RFC 1950. This document doesn't follow this approach. Rather, it repeatedly calls the compression scheme ZLIB and refers to both of the RFCs. Does this mean this specification actually uses the zlib wrapper? I suspect the answer is no, and if that's indeed the case, the document needs to be clarified in this regard. I suggest referring to the scheme as DEFLATE and removing the reference to RFC 1950 entirely. If, on the other hand, the intent really is to use the zlib wrapper, then the specification is incomplete in that ZLIB allows for multiple compression algorithms, checksumming, and so forth. These various settings would need to be specified in order to have interoperable ZLIB implementations." -Scott- From owner-ietf-smime@mail.imc.org Mon Mar 1 21:53:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25282 for ; Mon, 1 Mar 2004 21:53:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i222ZbZ8069072; Mon, 1 Mar 2004 18:35:37 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i222Zb0Y069070; Mon, 1 Mar 2004 18:35:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i222ZaKx069063 for ; Mon, 1 Mar 2004 18:35:36 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 12435 invoked by uid 0); 2 Mar 2004 02:32:09 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 2 Mar 2004 02:32:09 -0000 Message-Id: <5.2.0.9.2.20040301212939.04509890@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 01 Mar 2004 21:35:37 -0500 To: shollenbeck@verisign.com, turners@ieca.com From: Russ Housley Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Cc: blake@brutesquadlabs.com, ietf-smime@imc.org In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02BF9A93@vsvapostal8.vcorp .ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My understanding of the MIME registration is that ZLIB is really used. Russ At 09:05 PM 3/1/2004 -0500, Hollenbeck, Scott wrote: > > If an implementation chooses to support compression, then > > the implementation MUST support the ZLIB compression > > algorithm. > > > > Russ > >Something to consider: ZLIB (RFC 1950) and DEFLATE (RFC 1951) are NOT the >same thing. I ran into a small bit of specification confusion (thankfully >caught by Ned Freed) when my TLS compression draft went through IESG review. >It might be worth noting Ned's comments so that rfc2633bis specifies the >algorithm you intend: > >"First of all, it is important to realize that RFC 1950 and RFC 1951 specify >two things: (1) A compression scheme and corresponding format called DEFLATE >(1951) and (2) A general wrapper format for compressed data called ZLIB >(1950). >I believe most compression applications simply use the DEFLATE format and >don't >bother with the extra wrapper and most of our specifications that do this >refer to deflate and RFC 1951 rather than zlib and RFC 1950. > >This document doesn't follow this approach. Rather, it repeatedly calls >the compression scheme ZLIB and refers to both of the RFCs. Does this mean >this specification actually uses the zlib wrapper? I suspect the answer >is no, and if that's indeed the case, the document needs to be clarified >in this regard. I suggest referring to the scheme as DEFLATE and removing >the reference to RFC 1950 entirely. > >If, on the other hand, the intent really is to use the zlib wrapper, then >the specification is incomplete in that ZLIB allows for multiple compression >algorithms, checksumming, and so forth. These various settings would need to >be specified in order to have interoperable ZLIB implementations." > >-Scott- From owner-ietf-smime@mail.imc.org Mon Mar 1 22:02:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25627 for ; Mon, 1 Mar 2004 22:02:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i222jqlQ069667; Mon, 1 Mar 2004 18:45:52 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i222jpUw069666; Mon, 1 Mar 2004 18:45:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.11/8.12.8) with SMTP id i222jo3u069660 for ; Mon, 1 Mar 2004 18:45:51 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@218.37.226.73 with plain) by smtp001.bizmail.yahoo.com with SMTP; 2 Mar 2004 02:45:56 -0000 Message-ID: <4044B9EF.5090401@ieca.com> Date: Tue, 02 Mar 2004 11:44:31 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Blake Ramsdell CC: ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Comments:
  1. Para 1, 2nd sentence: Replace "MUST certify that the public" with "MUST verify that the public".
  2. Para 1.1, ASN.1 references- Why do these point to X.680-680 while the 2633bis ASN.1 references point to X.208-209. Shouldn't they point to the same thing?
  3. Para 1.1, Certificate definition: Replace "binds an entity's distinguished name" with "binds an entity's name".
  4. Para 2.3, 5th para,  Can add a pointer to the path building ID/RFC from PKIX?
  5. Para 2.3, 5th para 2nd sentence, Replace "Other methods of building certificate chains may be supported" with "Other methods of building certificate chains MAY be supported"
  6. Para 5: I'd like to add a security consideration about why it might not be good to send CRLs: "CRLs sent with the message impose concern when the signer's certificate is revoked, but the signer purposely includes a valid CRL but not the most recent CRL without the signer's serialNumber thereby providing a false verification". (or something like that)
  7. Para 5: The last 4 reasons for a signature and certificate checking to fail are may not be true if the sig/cert is checked at some future date after an initial check. Should we add a note to indicate that if the signature or certificate is verified at some later date they should be considered "valid" even though one of the four things occurred?
Cheers,

spt
From owner-ietf-smime@mail.imc.org Mon Mar 1 22:02:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25664 for ; Mon, 1 Mar 2004 22:02:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i222k8YN069681; Mon, 1 Mar 2004 18:46:08 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i222k8vZ069680; Mon, 1 Mar 2004 18:46:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.11/8.12.8) with SMTP id i222k788069674 for ; Mon, 1 Mar 2004 18:46:07 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@218.37.226.73 with plain) by smtp001.bizmail.yahoo.com with SMTP; 2 Mar 2004 02:46:13 -0000 Message-ID: <4044BA02.3070207@ieca.com> Date: Tue, 02 Mar 2004 11:44:50 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Blake Ramsdell CC: ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Only minor editorial comments (read NO show stoppers):
  1. Para 1.3, Certificate definition: Replace "distinguished name" with "name" the names are not always "distinguished."
  2. Para 1.3, Receiving agent, Sending agent, and S/MIME agent definitions: Capitalize 1st word "software" and "user."
  3. Para 2.2, Last paragraph last sentence: replace "and may not implement id-dsa-with-sha1 at all" with "and may not implement id-dsa-with-sha1 or id-sha at all."
  4. Para 2.4.2, SignedData Content Type: Can we add a sentence that says "Applying a signature to message provides authentication, message integrity, and non-repudiation of origin."  The other content types indicate what "services" they support or don't support.
  5. Para 2.4.4, 2nd sentence: Replace "This content type does not provide authentication or privacy" with "This content type does not provide authentication, message integrity, non-repudiation, or data confidentiality".  Just making it match the "services" listed in the introduction.
  6. Para 3.1, Steps 1-4: Add periods to end of sentences.
  7. Para 3.1.3, 3rd Para 2nd sentence: Replace "8-bit clear" with "8-bit clean" to match terminology in 3.1.2 2nd paragraph 4 sentence.
  8. Para 3.3, Step 2, last sentence: Replace "(see CMS Section 6)" with (see [CMS] Section 6).
  9. Para 3.4.2, Steps 1&2: Add periods to end of sentences.
  10. Compressed data text in 3.5 points to 3.1 but there's no mention in 3.1 of compression.  You should either add a sentence to say that in 3.1 enveloped = compression in this section or make the following changes (or others to clarify that you also mean to refer to compression data):
    1. Para 3.1, Title: Replace "Signing or Enveloping" with "Signing, Enveloping, or Compressing" because para 3.5 says perform message as in 3.1 but there's not mention of compressing in 3.1.
    2. Para 3.1, 1st para 1st sentence: Replace "S/MIME is used to secure MIME entities" with "S/MIME is used to secure and optionally compress MIME entities."
    3. Para 3.1, 2nd para 1st sentence: Replace "The MIME entity that is secured and ..." with "The MIME entity that is secured or compressed and ..."
    4. Para 3.1, 4th para 1st sentence: Replace "A single procedure is used for creating MIME entities that are to be signed, enveloped, or both signed and enveloped" with "A single procedure is used for creating MIME entities that are to be signed, enveloped, compressed and both signed and enveloped, signed and compressed, compressed and enveloped, and compressed, signed, and enveloped, etc." (or whatever # of combinations you feel like listing)
    5. Para 3.1, 4th para 3rd sentence: Replace "It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages" with "It is recommended that these additional steps be performed on enveloped and compressed messages, or signed and enveloped messages or compressed, signed and enveloped messages."
    6. Para 3.1, 1st para after Step 3: Replace "the security services on the message are processed" with "the security services or compression on the message are processed"
    7. Para 3.5, Step 1: Replace "to be enveloped" with "to be compressed".
  11. Para 3.7, Step 3: Add period to end of sentence.
  12. Annex F, Remove prior to submission to IESG (?)
From owner-ietf-smime@mail.imc.org Wed Mar 3 02:01:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08497 for ; Wed, 3 Mar 2004 02:01:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i236YxkK069660; Tue, 2 Mar 2004 22:34:59 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i236YxMV069657; Tue, 2 Mar 2004 22:34:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i236YvT1069634 for ; Tue, 2 Mar 2004 22:34:58 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (unknown [218.37.225.152]) by smtp3.pacifier.net (Postfix) with ESMTP id A3D8B6D99C; Tue, 2 Mar 2004 22:35:02 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Jongwook Park'" Cc: "Ietf-Smime" Subject: Comments on draft-park-seed-00.txt Date: Wed, 3 Mar 2004 15:39:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQA6lNET45oev4STXqKWvT2F3nmww== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040303063502.A3D8B6D99C@smtp3.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Issues: 1. The text and references to RFC 2119 can be removed as there are no protocol statements in this document. 2. Section 2, para last: L0, L1, R0, R1, Ki0, Ki1 are not used in the preceeding psudeo-code. Wordsmithing suggestions: These are optional, they just correspond to what I think might be better grammer. 1. Abstract s/adopted to most/adopted by most/ 2. Section 2, p1: s/64-bit subkeys Ki generated/64-bit subkey Ki generated/ Jim From owner-ietf-smime@mail.imc.org Wed Mar 3 13:23:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15997 for ; Wed, 3 Mar 2004 13:23:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23Hh201080080; Wed, 3 Mar 2004 09:43:02 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23Hh2sX080078; Wed, 3 Mar 2004 09:43:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23Hh10J080071 for ; Wed, 3 Mar 2004 09:43:01 -0800 (PST) (envelope-from capel@comgate.com) Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id i23Hh21C006025; Wed, 3 Mar 2004 12:43:02 -0500 Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id i23HgxvK019312; Wed, 3 Mar 2004 12:43:02 -0500 From: "Tony Capel" To: "'Sean P. Turner'" , "'Blake Ramsdell'" Cc: Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt Date: Wed, 3 Mar 2004 12:42:58 -0500 Message-ID: <002601c40146$f803e5c0$01b5a8c0@tony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4044B9EF.5090401@ieca.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Minor additional comment (not a show stopper) related to Sean's number 6 comment: | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Sean P. Turner | Sent: March 2, 2004 11:45 AM | To: Blake Ramsdell | Cc: ietf-smime@imc.org | Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt | | <> | | 6. Para 5: I'd like to add a security consideration about why it | might not be good to send CRLs: "CRLs sent with the message | impose concern when the signer's certificate is revoked, but | the signer purposely includes a valid CRL but not the most | recent CRL without the signer's serialNumber thereby | providing a false verification". (or something like that) | .... IF this is added, it may also make sense to emphasize that the transmission of root certificates may also be a problem (Para 2.3 paragraph 4 uses "SHOULD NOT" in the context of accepting root certificates - this may not raise the issue strongly enough). A caution in the Security section something like: "The ability of a receiver to adopt a self-signed certificate received within a messages should be strongly controlled to prevent the inadvertent adoption of root certificates. The ability of a sender to transmit self-signed certificates should be controlled to ensure that they cannot unexpectedly send root certificates which may potentially alter the trust settings of receiving entities. Some implementers may choose to permit the disabling of the ability to send and process-upon-receipt self-signed certificates." Some enterprise environments may want to disable the ability of their desktops to accept or send root certificates in messages. Tony From owner-ietf-smime@mail.imc.org Wed Mar 3 17:25:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00500 for ; Wed, 3 Mar 2004 17:25:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23LuZEr099528; Wed, 3 Mar 2004 13:56:35 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23LuYH2099527; Wed, 3 Mar 2004 13:56:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.11/8.12.8) with SMTP id i23LuXRj099505 for ; Wed, 3 Mar 2004 13:56:34 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@210.93.162.110 with plain) by smtp003.bizmail.yahoo.com with SMTP; 3 Mar 2004 21:56:38 -0000 Message-ID: <4047191E.3050701@ieca.com> Date: Thu, 04 Mar 2004 06:55:10 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org CC: Tony Capel , "'Blake Ramsdell'" Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt References: <002601c40146$f803e5c0$01b5a8c0@tony> In-Reply-To: <002601c40146$f803e5c0$01b5a8c0@tony> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with Tony's comment. It is in the same vein and should be added. spt Tony Capel wrote: >Minor additional comment (not a show stopper) related to Sean's number 6 >comment: > >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Sean P. Turner >| Sent: March 2, 2004 11:45 AM >| To: Blake Ramsdell >| Cc: ietf-smime@imc.org >| Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt >| >| <> >| >| 6. Para 5: I'd like to add a security consideration about why it >| might not be good to send CRLs: "CRLs sent with the message >| impose concern when the signer's certificate is revoked, but >| the signer purposely includes a valid CRL but not the most >| recent CRL without the signer's serialNumber thereby >| providing a false verification". (or something like that) >| .... > >IF this is added, it may also make sense to emphasize that the transmission of >root certificates may also be a problem (Para 2.3 paragraph 4 uses "SHOULD NOT" >in the context of accepting root certificates - this may not raise the issue >strongly enough). A caution in the Security section something like: > >"The ability of a receiver to adopt a self-signed certificate received within a >messages should be >strongly controlled to prevent the inadvertent adoption of root certificates. >The ability of a sender >to transmit self-signed certificates should be controlled to ensure that they >cannot >unexpectedly send root certificates which may potentially alter the trust >settings of receiving entities. Some implementers may choose to permit the >disabling of the ability to send and process-upon-receipt self-signed >certificates." > >Some enterprise environments may want to disable the ability of their desktops >to accept or send root certificates in messages. > >Tony > > > > > From owner-ietf-smime@mail.imc.org Wed Mar 3 17:25:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00518 for ; Wed, 3 Mar 2004 17:25:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23M1UOe099786; Wed, 3 Mar 2004 14:01:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23M1UD4099785; Wed, 3 Mar 2004 14:01:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.11/8.12.8) with SMTP id i23M1TC2099775 for ; Wed, 3 Mar 2004 14:01:29 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@210.93.162.110 with plain) by smtp004.bizmail.sc5.yahoo.com with SMTP; 3 Mar 2004 22:01:33 -0000 Message-ID: <40471A45.1090800@ieca.com> Date: Thu, 04 Mar 2004 07:00:05 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David P. Kemp" , ietf-smime@imc.org CC: "Ramsdell, Blake" Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt References: <200402242159.i1OLxotW027670@stingray.missi.ncsc.mil> In-Reply-To: <200402242159.i1OLxotW027670@stingray.missi.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David P. Kemp wrote: > > Blake, > > Thanks for clarifying the requirement to support certificates > without email addresses. > > Comments: > > 1. Section 2.3 para 4: "Agents MAY send CA certificates, that is, > certificates that are self-signed and can be considered the "root" > of other chains." This incorrectly implies that the only kind > of CA cert is the self-signed kind. Suggest "Agents MAY send > CA certificates that are self-signed and ..." > > 2. Section 4.4 paragraph 2: Why must sending and receiving > agents correctly handle the listed extensions only when they > appear in end-entity certificates? Suggest that sending and > receiving agents MUST correctly (i.e. in accordance with RFC 3280) > handle the basic constraints, key usage, AKI, SKI, and SAN extensions > in end-entity *and CA* certificates. > > 3. Section 4.4.1 paragraph 3: "Certificates SHOULD contain a > basicConstraints extension in CA certificates and SHOULD NOT contain > that extension in end entity certificates." In order to avoid > inconsistency with PKIX, change to "Certificates MUST contain a > basicConstraints extension in CA certificates and SHOULD NOT contain > that extension in end entity certificates." In other words, a > sending and receiving agent is non-compliant if it accepts > a v3 certificate without the basicConstraints extension as a CA > certificate. > > Dave Dave, I think the 1st and 3rd comments are editorial, but the 2nd corrects something that was wrong. I hope that implementors didn't just handle the extensions in EE certs but instead did the right thing and handled the extensions in CA certs as per 3280. spt From owner-ietf-smime@mail.imc.org Wed Mar 3 19:12:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08844 for ; Wed, 3 Mar 2004 19:12:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23NiFYl007024; Wed, 3 Mar 2004 15:44:15 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23NiFxI007022; Wed, 3 Mar 2004 15:44:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23NiEVR007016 for ; Wed, 3 Mar 2004 15:44:14 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (unknown [218.37.225.152]) by smtp4.pacifier.net (Postfix) with ESMTP id 80EBB6A47E; Wed, 3 Mar 2004 15:44:09 -0800 (PST) Reply-To: From: "Jim Schaad" To: "Ietf-Smime" Cc: "'Jongwook Park'" Subject: Comments on draft-park-cms-seed-00.txt Date: Thu, 4 Mar 2004 08:48:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQA6kc3r8a9yw4xTVqJOO9pKgly8AAj8NBw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040303234409.80EBB6A47E@smtp4.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1. In section 4, the OID presented and encoded in this section is incorrect. The OID that is encoded here needs to be id-seedCBC not id-npki-app-cmsSeed-wrap. Jim From owner-ietf-smime@mail.imc.org Thu Mar 4 02:03:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11726 for ; Thu, 4 Mar 2004 02:03:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i246YZbC047186; Wed, 3 Mar 2004 22:34:35 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i246YZjZ047182; Wed, 3 Mar 2004 22:34:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.11/8.12.8) with SMTP id i246YYM3047164 for ; Wed, 3 Mar 2004 22:34:34 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@218.37.231.20 with plain) by smtp004.bizmail.sc5.yahoo.com with SMTP; 4 Mar 2004 06:34:36 -0000 Message-ID: <40479284.8080205@ieca.com> Date: Thu, 04 Mar 2004 15:33:08 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SMIME , "Housley, Russ" Subject: IETF 59 S/MIME WG Summary and Upcomming Events Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit At the 59th IETF S/MIME WG Meeting:
  • MSGbis and CERTbis stauts was presented - both are in WG last call
  • GOST update was provided
  • SEED was adopted by working group
In the next month:
  • MSGbis and CERTbis will be updated with comments and reissued
  • MSGbis and CERTbis will be forwarded to IESG for IETF Wide last call
  • Compressed will be obsoleted and reissued
  • Examples draft will be submitted to ID-editor
  • Examples draft will reenter WG last call
  • SEED will be resubmitted to the ID-editor
  • SEED will enter WG last call
In the coming months:
  • ESSbis will be produced
  • Interop for MSGbis and CERTbis will be produced
From owner-ietf-smime@mail.imc.org Thu Mar 4 05:15:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05775 for ; Thu, 4 Mar 2004 05:15:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i249cYrh014821; Thu, 4 Mar 2004 01:38:34 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i249cYWS014819; Thu, 4 Mar 2004 01:38:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i249cWss014735 for ; Thu, 4 Mar 2004 01:38:33 -0800 (PST) (envelope-from aalberti@axway.com) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i249cQ5B026613 for ; Thu, 4 Mar 2004 10:38:27 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C401CC.71B3CC02" Subject: SubjectAltName & email address X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 4 Mar 2004 10:38:26 +0100 Message-ID: Thread-Topic: SubjectAltName & email address Thread-Index: AcQBzHA4XvI+/RtwTXiPUoUxPXUm2A== From: "Alberti Antoine" To: X-OriginalArrivalTime: 04 Mar 2004 09:38:46.0312 (UTC) FILETIME=[7D76F280:01C401CC] X-Scanned-By: MIMEDefang 2.38 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C401CC.71B3CC02 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I still have a theorical problem about the email address in the = certificate: S/MIME is not reserved to email messages. In particular, it = is already used in AS.2 (HTTP) from ediint working group. And as an = extension, it may be used in anything based on MIME. It seems that the = current version of the "S/MIME Version 3.1 Certificate Handling" draft = allows the use of S/MIME without email addresses. But is it really so = extreme to use S/MIME in other MIME based protocols than SMTP and POP3 = that it deserves no comment at all (the question is open, it is not = ironic at all) ? By the way, has anyone been in contact with the ediint working group = when they created their AS.2 and AS.3 (FTP) drafts? Regards. > = =20 > Antoine Alberti Axway. a Sopra Group company=09 > Tel : +33 (0)1 47 17 24 37 XFB R&D > Fax : +33 (0)1 47 17 24 25 26 Rue des Pavillons > email: aalberti@axway.com 92807 Puteaux Cedex - France >=20 >=20 >=20 ------_=_NextPart_001_01C401CC.71B3CC02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SubjectAltName & email address

I still have a theorical problem about = the email address in the certificate: S/MIME is not reserved to email = messages. In particular, it is already used in AS.2 (HTTP) from ediint = working group. And as an extension, it may be used in anything based on = MIME. It seems that the current version of the "S/MIME Version 3.1 Certificate = Handling" draft allows the use = of S/MIME without email addresses. But is it really so extreme to use = S/MIME in other MIME based protocols than SMTP and POP3 that it deserves = no comment at all (the question is open, it is not ironic at all) = ?

By the way, has anyone been in contact = with the ediint working group when they created their AS.2 and AS.3 = (FTP) drafts?

Regards.

            =          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        

            = Antoine Alberti =         =         Axway.  a Sopra Group company  
            = Tel  : +33 (0)1 47 17 24 = 37     =         XFB = R&D
            = Fax : +33 (0)1 47 17 24 = 25      =         26 Rue des = Pavillons
            = email: = aalberti@axway.com       =         = 92807 Puteaux Cedex - = France



------_=_NextPart_001_01C401CC.71B3CC02-- From lrosas_ui@ispe.ro Thu Mar 4 13:07:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04870 for ; Thu, 4 Mar 2004 13:07:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxG3-000164-00 for smime-archive@ietf.org; Thu, 04 Mar 2004 13:07:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxF4-0000pJ-00 for smime-archive@ietf.org; Thu, 04 Mar 2004 13:06:43 -0500 Received: from [61.249.8.242] (helo=thenetwork.de) by ietf-mx with smtp (Exim 4.12) id 1AyxE0-0000RX-00 for smime-archive@ietf.org; Thu, 04 Mar 2004 13:05:36 -0500 Message-ID: From: "Leland Rosas" To: smime-archive@ietf.org Subject: More efficient than via-gra Date: Thu, 04 Mar 2004 19:03:07 +0100 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_30_40,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 8bit

Generic cialis (Regalis), at cheap prices.
Most places charge $20, we charge $5. Quite a difference.

Cialis is known as a Super-Víagra or Weekend-Víagra because its effects start sooner and last much longer.

Shipped worldwide.

Your easy-to-use solution is here: http://www.mega-health.net/cia/?oxygen

-----
The link below is for those who hate spam...
http://www.mega-health.net/off.html
-==-

From owner-ietf-smime@mail.imc.org Mon Mar 8 05:55:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24340 for ; Mon, 8 Mar 2004 05:55:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28ATIg7059426; Mon, 8 Mar 2004 02:29:18 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28ATIgs059425; Mon, 8 Mar 2004 02:29:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28ATIXW059418 for ; Mon, 8 Mar 2004 02:29:18 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 989E58ABD7; Mon, 8 Mar 2004 02:29:17 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: "Ietf-Smime" Subject: Comments draft-ietf-smime-rfc2633bis-07.txt Date: Mon, 8 Mar 2004 02:34:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQE+N9NYXOKa0Y7Qg+c04MKBYHNlg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040308102917.989E58ABD7@smtp2.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Blake, 1. I just realized there is no abstract for this document. Is one required? 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/ 3. Section 1.1, p 4: Should there be a dependency/reference to CMSALG here as well? 4. Section 2.5.2, p1: Need to add text for Compression Algorithms. 5. Section 2.5.2: The following statement is no longer true (please delete): Note that all OIDs associated with the MUST and SHOULD implement algorithms are included in section A of this document. 6. section 3, p 1: s/[ESS] document provides examples/[ESS] document provides descriptions/ s/ESS provides an example of/ESS provides a description of/ 7. Section 3.1, p 5, s/implementor/implementer/ Section 3.6, p 3: ditto Section 4.1, p 2: ditto - I don't know if that is really an incorrect spelling, but MS Word does not know it. 8. Section 3.2.1, s/Application/pkcs7-signature/Application/pkcs7-signature (SignedData)/ 9. Section 3.2.2, p last: Suggest adding the text: "An smime-type parameters is not intended to give indications of security layers applied in the event of multiple levels of wrapping." 10. Section 3.4: In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both. --- what is the MUST handle? Otherwise there is no interop. 11: Section 3.4.3.2: The text "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not currently supported in S/MIME, and are included here for completeness." Is only partially correct. They are supported, just not required by this document. I would like to clean this up by saying this in a tighter fashion. 12. Section 4, p 1: s/certification/certificate/ 13. Section A: s/prefered/preferred/ 14. References: CMSAES = RFC 3565 15. Section 1.1, p 4: s/the Cryptographic Message Syntax/the Cryptographic Message Syntax document/ 16. Is a specification MUST/SHOULD (section 1.1, p4) or the document (section 1.1, p3) (The same word is used, but in completely different meanings. Would not be a problem but for the MUST in p4 potentially wanting to force meaning into p3). 17. Section 2.2, p 3: s/the algorithms/the hash algorithms/ 18. Section 2.4.1, p1: s/signedData/SignedData/ - also envelopedData vs EnvelopedData and compressedData vs CompressedData. signedData does not actually exist in the CMS documents. The type is SignedData or the concept is signed data. I think we need to clean this up. Russ: Please note there is one section in CMS that needs to be cleaned up in the same way. 19. Section 2.4.1, p1: s/encryptedContentInfo ContentType/encryptedContentInfo contentType/ 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/ 21. Section 2.4.2, p1: Should add "This content type does not provide privacy." 22. Section 2.5 title, s/Attribute/Attributes and the/ 23. Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/ 24. I heard this comment at the last IETF meeting from somebody. As I have had the same problem in a number of cases (esp with doing interop matrixes) I am throwing it out for your consideration: The use of the words must, should and may in lower case causes some confusion dealing with the question of - did the author just forget to uppercase this or is it really not a protocol statement. SHOULD examine all instances of these words to see if a different word works just as well. Jim From owner-ietf-smime@mail.imc.org Mon Mar 8 13:04:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17299 for ; Mon, 8 Mar 2004 13:04:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28Heb4Q084750; Mon, 8 Mar 2004 09:40:37 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28Hebr7084749; Mon, 8 Mar 2004 09:40:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28HeaIX084742 for ; Mon, 8 Mar 2004 09:40:36 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman Message-Id: Date: Mon, 8 Mar 2004 09:40:37 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Draft minutes from the Seoul meeting Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. Here are my version of the minutes from last weeks meeting. Please let me know this week if you have any changes. --Paul Hoffman S/MIME Minutes March 2, 2004 Seoul, Korea The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in from Seattle via Jabber and iChat. The short agenda was agreed to. Sean updated the status since the last IETF meeting. New RFC (3657, Camellia) Three drafts that are with the RFC editor (symkeydist, x400wrap, and x400transport) Two drafts in WG last call (rfc2632bis and rfc2633bis) The draft that will go into WG last call when its editor finally finishes it (examples). Three drafts are currently active in the WG: cms-rsa-kem gost park-cms-seed Sean talked about the milestones and how well we are doing on them. We have a few short-term milestones and a much longer list of long-term ones. Sean gave Blake's presentation on MSGbis and CERTbis status Give the list of changes from last versions Received a bunch of editorial comments for both documents Russ said that other groups are using these docs, so please take a careful look at them. Sean gave a presentation on GOST status Added a new draft with the algorithms needed for implementing GOST Move the default parameters to different doc Added message examples Seeking more input, particularly from implementers Jongwook Park gave SEED updates Two drafts are already out there The algorithm is mandatory in Korea for government devices Approved by ISO/IEC JTC1/SC27 Looking for comments and implementations We finished in about 17 minutes. From owner-ietf-smime@mail.imc.org Mon Mar 8 15:45:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28912 for ; Mon, 8 Mar 2004 15:45:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28KNXsn097465; Mon, 8 Mar 2004 12:23:33 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28KNXGM097464; Mon, 8 Mar 2004 12:23:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28KNXPF097458 for ; Mon, 8 Mar 2004 12:23:33 -0800 (PST) (envelope-from capel@comgate.com) Received: from mail4.magma.ca (mail4.magma.ca [206.191.0.222]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id i28KNaXe007182; Mon, 8 Mar 2004 15:23:36 -0500 Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail4.magma.ca (8.12.10/8.12.9) with ESMTP id i28KNQ7N024711; Mon, 8 Mar 2004 15:23:36 -0500 From: "Tony Capel" To: Cc: "'Sean P. Turner'" Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt Date: Mon, 8 Mar 2004 15:23:23 -0500 Message-ID: <001401c4054b$38075ff0$01b5a8c0@tony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4044B9EF.5090401@ieca.com> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This may be falling into the crack between S/MIME and PKIX. I do not think this needs a change in any of the documents, although something in the security section MIGHT be appropriate (as below). I have seen it proposed that the signing time be used when validating signatures, and at least one S/MIME implementation may do this. I THINK this violates the intent of CERT section 4.1 and rfc3280 (KEYM) sections 3.3 and 6.3.3. That is, "current time" in these rfc's should not be interpreted to be equivalent to the "signing time" from the message. Sean Turner's recent comment #6, 2 March 2004 on CERT is also relevant. This was discussed back in 1998 and I think responsibility allocated to KEYM (PKIX). The unique S/MIME WG issue is the improper (IMHO) use of the signing time in the message to judge certificate expiry or CRL validity (of course KEYM does not mention signing time). Denis Pinkas wrote (28 Sept 1998, in part): "...The signingTime attribute only reflects the time the signer wanted to be included. The signer may well pre-date that value, ... but more important, if the key of the signer is compromised then an attacker may also pre-date that value. In such a situation it cannot be made a difference between a past "honest" signature from the right signer and a pre-dated "fake" signature from an attacker...." Alternatively stated: An attack is for a forger to set their local clock back to a time prior to the revocation, forge the message and enclose a then-current (old) CRL in the message. If the signing time is used to select the CRL the forger could succeed (the forger might mount a DOS attack to prevent the receiver getting a more recent CRL). Alternatively, the forger waits for certificate expiry and then compromises the key, back-dates their forged signature - and again the attack is successful even if the rightful owner knows about it (since revocation support is not guaranteed past expiry). I think the following are correct: 1. The certificate is checked for expiry, and if unexpired, the current and not "too old" CRL is used (or OCSP server, etc. accessed). Specifically the check for expiry AND "too old" must be based on the receiver's sense of time, NOT the signing time. (Ideally it would be based on a trusted time source but this is normally not available, so this should not be mandatory. If there is a trusted time stamp other options are available). 2. If the certificate is expired, no CRL (or OCSP) check is done since the CA does not guarantee revocation processing. CRL checking should not be done even if a cached "old" CRL is available (e.g. as provided within the message). This has consequences when attempting to (re-)verify old messages stored in inBoxes for example. They may verify when received, but fail when re-verified later. This is bad for users, and implementers may be tempted to provide a "better" solution by using the signing time (bad). If a signature on an incoming message is important, users must consider using (prior to cert expiry) a trusted time stamp server or trusted archive so a "trusted time" can be added. Enterprise users might consider automating this; e.g. ensuring that old e-mails (and CRLs!!) are archived in a trusted and timely manner. Should a sentence be added cautioning users against using the untrusted signing time from the message for certificate expiry and CRL validity checking? For example something like: "The signing time in the message cannot be trusted if the signing key has been compromised. Thus the signing time should not be used as the "current time" when performing certificate expiry or revocation checking as per KEYM." Tony PS: A quote from Peter Sylvester (30 July 2003) in the PKIX WG discussion: "Isn't creating a digital signature which is not almost immediately presented to some relying or attesting party a profound misunderstanding of cryptographic techniques? " Unfortunately we must live with e-mail application reality! PPS: There is a long discussion, (starting in about 30 July 2003) in the PKIX WG on related issues including potential archiving of CRL's. I think for current purposes we just need to emphasize that "signing time" is untrusted and must not be used for expiry or CRL validity testing. Going beyond that might get too complicated and best left with PKIX. From owner-ietf-smime@mail.imc.org Mon Mar 8 16:45:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04632 for ; Mon, 8 Mar 2004 16:45:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28LP2ME002416; Mon, 8 Mar 2004 13:25:02 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28LP2ma002415; Mon, 8 Mar 2004 13:25:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28LP1Ud002409 for ; Mon, 8 Mar 2004 13:25:01 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 4B5666F7CF; Mon, 8 Mar 2004 13:24:51 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: "Ietf-Smime" Subject: Comments on draft-ietf-smime-rfc2632bis-05.txt Date: Mon, 8 Mar 2004 13:28:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQFVE4/B8TaScgQTEO/S9PyZbCNpw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040308212451.4B5666F7CF@smtp1.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Blake, 1. Section 2.2.1: In the following text, I have a problem with "PKIX" as oppose to X.509 Identity Certificates, esp as PKIX now has a definition for ACs. The CMS message format supports a choice of certificate formats for public key content types: PKIX, PKCS #6 Extended Certificates and X.509 Attribute Certificates. 2. Section 2.2.1, p 3: s/suerceded/superseded/ --- I didn't believe it but I looked it up. 3. Section 2.3: The following statements don't agree: Receiving agents MUST be able to handle an arbitrary number of certificates of arbitrary relationship to the message sender and to each other in arbitrary order. A receiving agent SHOULD be able to handle an arbitrarily large number of certificates and chains. 4. Section 2.3: Let's get a better term for this that "CA certificates" Agents MAY send CA certificates, that is, certificates that are self- signed and can be considered the "root" of other chains. 5. Section 3: Please define the type of field for pkcs-9-at-emailAddress. (I think it's IA5 string but can't swear to it off the top of my head.) 6. Section 5: s/noticable/noticeable/ 7. Section 5: s/message,if/message, if/ From owner-ietf-smime@mail.imc.org Mon Mar 8 17:53:18 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08408 for ; Mon, 8 Mar 2004 17:53:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28MXcY5007258; Mon, 8 Mar 2004 14:33:38 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28MXciI007257; Mon, 8 Mar 2004 14:33:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.11/8.12.8) with SMTP id i28MXbnb007247 for ; Mon, 8 Mar 2004 14:33:37 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@210.93.162.119 with plain) by smtp001.bizmail.yahoo.com with SMTP; 8 Mar 2004 22:33:42 -0000 Message-ID: <404DB93C.2040700@ieca.com> Date: Tue, 09 Mar 2004 07:31:56 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-smime@imc.org Subject: Re: Draft minutes from the Seoul meeting References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please have all comments in by next Monday. I want to get the presentations and minutes to the proceeding folks as soon as possible. spt Paul Hoffman / IMC wrote: > > Greetings again. Here are my version of the minutes from last weeks > meeting. Please let me know this week if you have any changes. > > --Paul Hoffman > > > S/MIME Minutes > March 2, 2004 > Seoul, Korea > > The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in > from Seattle via Jabber and iChat. > > The short agenda was agreed to. > > Sean updated the status since the last IETF meeting. > > New RFC (3657, Camellia) > Three drafts that are with the RFC editor > (symkeydist, x400wrap, and x400transport) > Two drafts in WG last call (rfc2632bis and rfc2633bis) > The draft that will go into WG last call when its editor > finally finishes it (examples). > Three drafts are currently active in the WG: > cms-rsa-kem > gost > park-cms-seed > > Sean talked about the milestones and how well we are doing on them. > We have a few short-term milestones and a much longer list of > long-term ones. > > Sean gave Blake's presentation on MSGbis and CERTbis status > Give the list of changes from last versions > Received a bunch of editorial comments for both documents > Russ said that other groups are using these docs, so please take > a careful look at them. > > Sean gave a presentation on GOST status > Added a new draft with the algorithms needed for implementing GOST > Move the default parameters to different doc > Added message examples > Seeking more input, particularly from implementers > > Jongwook Park gave SEED updates > Two drafts are already out there > The algorithm is mandatory in Korea for government devices > Approved by ISO/IEC JTC1/SC27 > Looking for comments and implementations > > We finished in about 17 minutes. > From owner-ietf-smime@mail.imc.org Wed Mar 10 01:08:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21188 for ; Wed, 10 Mar 2004 01:08:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A5isd7097588; Tue, 9 Mar 2004 21:44:54 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A5irs6097587; Tue, 9 Mar 2004 21:44:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A5irtM097581 for ; Tue, 9 Mar 2004 21:44:53 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 5C6D16F4EE; Tue, 9 Mar 2004 21:45:00 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt Date: Tue, 9 Mar 2004 21:49:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcP5sqq1SUllhFz9SXCFRjorZD2AbQBUkjUg Message-Id: <20040310054500.5C6D16F4EE@smtp1.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Blake, A couple of small issues: 1. Do we need to review the RSA key sizes on certificate verification, 4096 is soon to be a common key size I think and should be supported. I don't know that 512 should not be dropped from MUST to SHOULD. 2. I just noticed that 4.4.2.1 does not have a corresponding section for RSA. In point of fact this may now be in CMSALG and therefore not needed. (i.e. remove 4.4.2.1) jim From achigh@yemenmail.com Wed Mar 10 02:29:04 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20595 for ; Wed, 10 Mar 2004 02:29:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0y9G-0004gY-00 for smime-archive@ietf.org; Wed, 10 Mar 2004 02:29:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0y7r-0004OU-00 for smime-archive@ietf.org; Wed, 10 Mar 2004 02:27:36 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0y77-0004AD-00 for smime-archive@ietf.org; Wed, 10 Mar 2004 02:26:50 -0500 Received: from dsl-200-78-45-88.prod-infinitum.com.mx ([200.78.45.88]) by mx2.foretec.com with smtp (Exim 4.24) id 1B0y79-00047J-Ii for smime-archive@ietf.org; Wed, 10 Mar 2004 02:26:52 -0500 Received: from 9rsdt.3ajvdsj.net ([16.29.29.148]) by dsl-200-78-45-88.prod-infinitum.com.mx; Wed, 10 Mar 2004 10:18:46 +0300 Message-ID: <7--a60s9-y-u49@pl9e3tn.fb> From: "Make money at home with eBay!" Reply-To: "Make money at home with eBay!" To: smime-archive@ietf.org Subject: Guaranteed to profit with ebay dubhegosling Date: Wed, 10 Mar 04 10:18:46 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_2FF..DE29_5_76.A6DA._B" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=20.8 required=5.0 tests=CLICK_BELOW, DATE_SPAMWARE_Y2K,FORGED_MUA_OIMO,FORGED_OUTLOOK_TAGS,HTML_50_60, HTML_FONTCOLOR_RED,HTML_FONT_INVISIBLE,HTML_IMAGE_ONLY_04, HTML_MESSAGE,HTML_TITLE_EMPTY,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,OBFUSCATING_COMMENT, SUBJ_GUARANTEED autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 2.4 SUBJ_GUARANTEED Subject GUARANTEED * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.5 HTML_TITLE_EMPTY BODY: HTML title contains no text * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 1.5 HTML_IMAGE_ONLY_04 BODY: HTML: images with 200-400 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text * 2.7 FORGED_MUA_OIMO Forged mail pretending to be from MS Outlook IMO --_2FF..DE29_5_76.A6DA._B Content-Type: text/html; Content-Transfer-Encoding: quoted-printable order confirmation. your order should be s= hipped by January, via fedex. your federal express tracking number is hebe.
thank you for registering. your userid is: orthonormal

Learn to Make A Fortune With Ebay!
Complete Turnkey System
Software - Videos - Turo= rials
Click Here For Information




click here if you would not like t= o receive future mailings.

--_2FF..DE29_5_76.A6DA._B-- From owner-ietf-smime@mail.imc.org Wed Mar 10 04:38:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28963 for ; Wed, 10 Mar 2004 04:38:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9ADg3068263; Wed, 10 Mar 2004 01:10:13 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A9ADZA068262; Wed, 10 Mar 2004 01:10:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from postman-pat.actimage.fr (postman-pat.actimage.net [80.87.224.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9ACsf068219 for ; Wed, 10 Mar 2004 01:10:12 -0800 (PST) (envelope-from muriel@actimage.net) Received: from leila (inet-gate3 [80.87.224.93]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i2A93mC15554 for ; Wed, 10 Mar 2004 10:03:48 +0100 (CET) Message-ID: <03aa01c4067f$c53b0810$4406a8c0@leila> From: "Muriel Souville" To: Subject: Launch of the Security Plugtests Registration Date: Wed, 10 Mar 2004 10:12:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_039A_01C40688.253A6780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_039A_01C40688.253A6780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, The ETSI Plugtests(tm) Service is pleased to announce the opening of the Security Plugtests registration. The event will take place from 24 till 28 May at the ETSI premises, in Sophia Antipolis (France). Deadline to register is 5th May. All details about the event are to be found at http://www.etsi.org/plugtests/security.htm Feel free to forward this email to as many people as you want in order to have a really interesting test opportunity this week. For any enquiry you may have, please write to plugtests@etsi.org. Thanks for your attention. We look forward to welcoming you at our Headquarters in May. Best regards Muriel SOUVILLE ETSI Consultant Tel: +33 (0) 3 90 23 63 63 ------=_NextPart_000_039A_01C40688.253A6780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,

The ETSI Plugtests(tm) Service is pleased to announce the=20 opening
of the Security Plugtests registration.
The event will = take place=20 from 24 till 28 May at the ETSI premises,
in Sophia Antipolis=20 (France).
Deadline to register is 5th May.

 All details = about the=20 event are to be found at
http://www.etsi.org/plugtests/security.htm

Feel free to forward this email to as = many people=20 as you want in order
to have a really interesting test opportunity = this=20 week.

For any enquiry you may have, please write to plugtests@etsi.org.

Thanks for your attention.
We look forward to = welcoming you=20 at our Headquarters in May.

Best regards

Muriel = SOUVILLE
ETSI=20 Consultant
Tel: +33 (0) 3 90 23 63=20 63
------=_NextPart_000_039A_01C40688.253A6780-- From smileyjg@uk.mahjong.dk Thu Mar 11 11:01:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08417 for ; Thu, 11 Mar 2004 11:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Sd8-0005LJ-00 for smime-archive@ietf.org; Thu, 11 Mar 2004 11:01:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Sbc-0004tX-00 for smime-archive@ietf.org; Thu, 11 Mar 2004 11:00:20 -0500 Received: from [211.109.50.168] (helo=vrflow.oulu.fi) by ietf-mx with smtp (Exim 4.12) id 1B1Sa6-0004an-00 for smime-archive@ietf.org; Thu, 11 Mar 2004 10:58:47 -0500 Message-ID: From: "Shelia Smiley" To: smime-archive@ietf.org Subject: 6-Home Loans as low as 2.9% Date: Thu, 11 Mar 2004 19:47:01 +0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/html Content-Transfer-Encoding: 8bit X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.7 required=5.0 tests=DATE_IN_FUTURE_03_06, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_30_40,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY autolearn=no version=2.60 X-Spam-Report: * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 2.8 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format Content-Transfer-Encoding: 8bit G'day

Would you re-finance if you knew you'd SAVE TH0USANDS?

We'll get you rates as low as 2.9%.

Don't believe me? Fill out our small online form and we'll show you how.

Get the house and/or car you always wanted, it only takes 2 minutes of your time:
http://xdtyiuiipthub.giwurks.info






No thanks From owner-ietf-smime@mail.imc.org Tue Mar 16 16:31:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26531 for ; Tue, 16 Mar 2004 16:31:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GL0X3H062305; Tue, 16 Mar 2004 13:00:33 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2GL0XOK062304; Tue, 16 Mar 2004 13:00:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GL0WjZ062297 for ; Tue, 16 Mar 2004 13:00:33 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24382; Tue, 16 Mar 2004 16:00:34 -0500 (EST) Message-Id: <200403162100.QAA24382@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt Date: Tue, 16 Mar 2004 16:00:34 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Cryptographic Message Syntax (CMS) Author(s) : R. Housley Filename : draft-ietf-smime-rfc3369bis-00.txt Pages : 53 Date : 2004-3-16 This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc3369bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc3369bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-16162515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc3369bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc3369bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-16162515.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Tue Mar 16 17:24:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00023 for ; Tue, 16 Mar 2004 17:24:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLx4Zw065298; Tue, 16 Mar 2004 13:59:04 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2GLx49J065297; Tue, 16 Mar 2004 13:59:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2GLx4s7065290 for ; Tue, 16 Mar 2004 13:59:04 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 26172 invoked by uid 0); 16 Mar 2004 21:52:02 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.156) by woodstock.binhost.com with SMTP; 16 Mar 2004 21:52:02 -0000 Message-Id: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 16 Mar 2004 16:58:49 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt In-Reply-To: <200403162100.QAA24382@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear S/MIME WG: Yes, we are making another round of updates to CMS. I expect them to be very minor. The changes are described in Section 1.2, which says: This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC 3369 introduced an extension mechanism to support new key management schemes without further changes to the CMS. This document introduces a similar extension mechanism to support additional certificate formats for the verification of digital signatures without further changes to the CMS. Backward compatibility with both RFC 2630 and RFC 3369 is preserved. I expect to fold in all of the changes needed to correct the errata posted on the RFC Editor's web site in the next version. Also, Peter Gutmann has asked for some clarification of countersignature. Finally, Jim Schaad has suggested that support for "other format" revocation status information is appropriate since "other format" certificates are being supported. I do not expect these changes to take long. I will post -01 before the end of the week. Russ >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the S/MIME Mail Security Working Group of the >IETF. > > Title : Cryptographic Message Syntax (CMS) > Author(s) : R. Housley > Filename : draft-ietf-smime-rfc3369bis-00.txt > Pages : 53 > Date : 2004-3-16 > >This document describes the Cryptographic Message Syntax (CMS). This > syntax is used to digitally sign, digest, authenticate, or encrypt > arbitrary message content. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-00.txt From owner-ietf-smime@mail.imc.org Tue Mar 16 20:24:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10332 for ; Tue, 16 Mar 2004 20:24:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H0x7HQ075451; Tue, 16 Mar 2004 16:59:07 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2H0x7aC075450; Tue, 16 Mar 2004 16:59:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H0x5fV075439; Tue, 16 Mar 2004 16:59:06 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> Date: Tue, 16 Mar 2004 16:59:09 -0800 To: Russ Housley , ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:58 PM -0500 3/16/04, Russ Housley wrote: >Dear S/MIME WG: > >Yes, we are making another round of updates to CMS. I expect them >to be very minor. The changes are described in Section 1.2, which >says: > > This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC > 3369 introduced an extension mechanism to support new key management > schemes without further changes to the CMS. This document introduces > a similar extension mechanism to support additional certificate > formats for the verification of digital signatures without further > changes to the CMS. Backward compatibility with both RFC 2630 and > RFC 3369 is preserved. Maybe I'm being blind, but *where* is that extension mechanism introduced in the new document? Listing it explicitly in this introductory material would help the reader (or at least me...). --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@mail.imc.org Tue Mar 16 20:35:55 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11429 for ; Tue, 16 Mar 2004 20:35:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1J5Ks076412; Tue, 16 Mar 2004 17:19:05 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2H1J5ZL076411; Tue, 16 Mar 2004 17:19:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1J3Jj076402; Tue, 16 Mar 2004 17:19:04 -0800 (PST) (envelope-from shenson@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 1B3Pi7-0007oS-0V; Wed, 17 Mar 2004 01:19:07 +0000 Message-ID: <4057A78D.9030204@drh-consultancy.demon.co.uk> Date: Wed, 17 Mar 2004 01:19:09 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> In-Reply-To: X-Enigmail-Version: 0.83.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > At 4:58 PM -0500 3/16/04, Russ Housley wrote: > >> Dear S/MIME WG: >> >> Yes, we are making another round of updates to CMS. I expect them to >> be very minor. The changes are described in Section 1.2, which says: >> >> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC >> 3369 introduced an extension mechanism to support new key management >> schemes without further changes to the CMS. This document introduces >> a similar extension mechanism to support additional certificate >> formats for the verification of digital signatures without further >> changes to the CMS. Backward compatibility with both RFC 2630 and >> RFC 3369 is preserved. > > > Maybe I'm being blind, but *where* is that extension mechanism > introduced in the new document? Listing it explicitly in this > introductory material would help the reader (or at least me...). > Presumably the CertificateChoices type mentioned in 10.2.2 and its use in CertificateSet. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From owner-ietf-smime@mail.imc.org Tue Mar 16 21:07:51 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12990 for ; Tue, 16 Mar 2004 21:07:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1nwA2078047; Tue, 16 Mar 2004 17:49:58 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2H1nwZr078046; Tue, 16 Mar 2004 17:49:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1nv9Y078038; Tue, 16 Mar 2004 17:49:57 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 8BC7E6ABA3; Tue, 16 Mar 2004 17:50:02 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Dr Stephen Henson'" , "'Paul Hoffman / IMC'" Cc: Subject: RE: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt Date: Tue, 16 Mar 2004 17:54:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4057A78D.9030204@drh-consultancy.demon.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQLwLmtnAH/WQtDRLmZ44pQHVnX2wAAfelg Message-Id: <20040317015002.8BC7E6ABA3@smtp2.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve is correct. The change was made by adding the OtherCertFormat data type to section 10.2.2. However I think that it is easier for people to find if the section number is included in the changes section. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Dr Stephen Henson Sent: Tuesday, March 16, 2004 5:19 PM To: Paul Hoffman / IMC Cc: ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt Paul Hoffman / IMC wrote: > > At 4:58 PM -0500 3/16/04, Russ Housley wrote: > >> Dear S/MIME WG: >> >> Yes, we are making another round of updates to CMS. I expect them to >> be very minor. The changes are described in Section 1.2, which says: >> >> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC >> 3369 introduced an extension mechanism to support new key management >> schemes without further changes to the CMS. This document introduces >> a similar extension mechanism to support additional certificate >> formats for the verification of digital signatures without further >> changes to the CMS. Backward compatibility with both RFC 2630 and >> RFC 3369 is preserved. > > > Maybe I'm being blind, but *where* is that extension mechanism > introduced in the new document? Listing it explicitly in this > introductory material would help the reader (or at least me...). > Presumably the CertificateChoices type mentioned in 10.2.2 and its use in CertificateSet. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From owner-ietf-smime@mail.imc.org Wed Mar 17 11:24:46 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16942 for ; Wed, 17 Mar 2004 11:24:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HG2K1a013948; Wed, 17 Mar 2004 08:02:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2HG2Kuv013947; Wed, 17 Mar 2004 08:02:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2HG2J0M013924 for ; Wed, 17 Mar 2004 08:02:19 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 26849 invoked by uid 0); 17 Mar 2004 15:55:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.132.209) by woodstock.binhost.com with SMTP; 17 Mar 2004 15:55:05 -0000 Message-Id: <5.2.0.9.2.20040317105944.01f7d848@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 17 Mar 2004 11:01:36 -0500 To: Paul Hoffman / IMC , ietf-smime@imc.org From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt In-Reply-To: References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: Se section 10.2.2. Russ At 04:59 PM 3/16/2004 -0800, Paul Hoffman / IMC wrote: >At 4:58 PM -0500 3/16/04, Russ Housley wrote: >>Dear S/MIME WG: >> >>Yes, we are making another round of updates to CMS. I expect them to be >>very minor. The changes are described in Section 1.2, which says: >> >> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC >> 3369 introduced an extension mechanism to support new key management >> schemes without further changes to the CMS. This document introduces >> a similar extension mechanism to support additional certificate >> formats for the verification of digital signatures without further >> changes to the CMS. Backward compatibility with both RFC 2630 and >> RFC 3369 is preserved. > >Maybe I'm being blind, but *where* is that extension mechanism introduced >in the new document? Listing it explicitly in this introductory material >would help the reader (or at least me...). > >--Paul Hoffman, Director >--Internet Mail Consortium > From skdiocesz@crosslink.net Thu Mar 18 04:22:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28956 for ; Thu, 18 Mar 2004 04:22:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3tjH-0004eF-00 for smime-archive@ietf.org; Thu, 18 Mar 2004 04:22:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3tiS-0004WD-00 for smime-archive@ietf.org; Thu, 18 Mar 2004 04:21:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3thh-0004Ng-00 for smime-archive@ietf.org; Thu, 18 Mar 2004 04:20:41 -0500 Received: from [211.236.186.177] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1B3thi-0005dD-4Z for smime-archive@ietf.org; Thu, 18 Mar 2004 04:20:42 -0500 Received: from 207.20.120.7 by 211.236.186.177; Thu, 18 Mar 2004 14:17:10 +0500 Message-ID: From: "Teddy Madrid" Reply-To: "Teddy Madrid" To: smime-archive@ietf.org Subject: Free Prescriptions Date: Thu, 18 Mar 2004 04:17:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8395449138024609103" X-IP: 218.8.108.141 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=9.9 required=5.0 tests=BIZ_TLD,CLICK_BELOW, FORGED_RCVD_NET_HELO,HTML_30_40,HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, ONLINE_PHARMACY,RCVD_NUMERIC_HELO,SUB_FREE_OFFER autolearn=no version=2.60 X-Spam-Report: * 0.5 SUB_FREE_OFFER Subject starts with "Free" * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.8 HTML_30_40 BODY: Message is 30% to 40% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 0.0 CLICK_BELOW Asks you to click below * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----8395449138024609103 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

SuperMeds Online Pharmacy
Prescriptions You Need At Prices You Deserve!

View our expanded product line and new low prices today!

Click Here To Start Saving

Sleep Aides
Ambien, Sonata

Muscle Relaxers
Soma, Flexeril, Skelaxin

Pain Relief
Fioricet, Vioxx

Chanoverian berkeley clara opponent hormone assert bookshelves compensatory anatomic canoga panda eisner typhus keno robot asexual tofu dizzy credulous handmaiden . Mcommissary delft referred tofu conferrable cried chloride buzzsaw sans arabic creedal k's imitable billings huntington schubert sludge wiggle ignorant illuminate boris presentational parch transliterate persist ! Ndispel hampshire calcareous newton tremulous escort eutectic ssw row daytona ceramium vice justinian ashland integrity lucerne caputo harem carlin chorus afflict guess ukraine .Utn boolean multiplicative amputate assonant onto arlen chinch cady paddle dogging geometrician abrasion defunct dionysian carven diffuse ellipsoidal contribution prefect coronado fishpond ! Jdietetic am horton closet blackbird athlete sanitarium workforce potlatch snowshoe cal woody axiomatic spike chamber inarticulate gary rome beauteous halloween declamatory smack waltham ! Zearsplitting stomp josef quadrennial atrium romp dalhousie bold inapplicable bulrush poland no boson eleventh inaccurate obfuscatory irreproducible sidesaddle median retrograde lineage chaperon circumvention look affectation centrifugal cargoes casket insubordinate lost benzene sergei polecat help mateo suey airpark creaky cordon .Zdank redemptive teaspoon nose alcoholic cerulean demagnify freest accuse sweaty warmish magpie connubial degumming pliers ; Acavern informant doormen died caret sanctify dinghy taxied schiller churchill castanet qualitative shaw curry carte buttermilk sofia caress tall ? Qsake spaulding pubescent tragedy talus dulcet mizar delphi beacon falter commiserate mchugh attic barge devotee amherst gigavolt cell crawlspace coop firewall oxcart eightieth block edelweiss franciscan vernacular tribulate dextrous cheesecake debacle eeoc oklahoma edwardine logan pinafore alarm baronial amply barbudo turnover blurb Fburgeon accent bernardino cigar apostrophe repudiate rent penurious angie blurry ptarmigan rachmaninoff sewage c oequal anarch !! Limmerse mediterranean probate trinidad myoglobin goody drape adele corrosion successive ramp prosaic archetypical alcohol brae cheerlead josephine declassify particle !! Hcomply alyssum euclidean they'll athlete terpsichorean jangle nicholas breccia ductile buried swenson ditty crucify bereave scarsdale heterocyclic butyrate bogy elope flintlock gyrfalcon highhanded flop lummox hole bangle atheist anglicanism Uinsufficient alterman economic slap midband ; Nsiliceous buggy detract ; Zabsentee nightcap pamphlet brokerage whup hologram handline chapman nowadays decrement scrupulosity probate cinnamon cornmeal crappie combination yugoslavia lateran reason ankle vaudeville chance gunmen febrile discrepant guesswork coronary muscular conferrable anderson mckenna introject bon pump instinctual achilles latvia obscure centrist burette sedulous difficult covert exuberant west bellicose bungle Ycrucifix awhile gentility devolve script hatteras decease modus accessible alsop collimate ltd circus amber coleus . Hparkinson refusal allegra burtt meadowsweet monroe slob insubordinate polka vessel culprit eugenic ! Bfelonious vary fate shoulder euler nathan imperil culvert navigate stayed breadboard workforce supple conrail damage teller consignee poodle vegetarian health typesetting rangoon judicial

If this notice has reached you in error, please notify us by clicking here ----8395449138024609103-- From owner-ietf-smime@mail.imc.org Thu Mar 18 21:54:44 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24430 for ; Thu, 18 Mar 2004 21:54:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2WHkG010713; Thu, 18 Mar 2004 18:32:17 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J2WH5Q010712; Thu, 18 Mar 2004 18:32:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp005.bizmail.sc5.yahoo.com (smtp005.bizmail.sc5.yahoo.com [66.163.175.82]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2J2WC6l010697 for ; Thu, 18 Mar 2004 18:32:16 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@138.88.0.49 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 19 Mar 2004 02:32:18 -0000 Message-ID: <405A5C15.7070001@ieca.com> Date: Fri, 19 Mar 2004 11:33:57 +0900 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: Draft minutes from the Seoul meeting References: <404DB93C.2040700@ieca.com> In-Reply-To: <404DB93C.2040700@ieca.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hearing no objections I send the minutes in ot the proceedings people.

spt

Sean P. Turner wrote:


Please have all comments in by next Monday.  I want to get the presentations and minutes to the proceeding folks as soon as possible.

spt

Paul Hoffman / IMC wrote:


Greetings again. Here are my version of the minutes from last weeks meeting. Please let me know this week if you have any changes.

--Paul Hoffman


S/MIME Minutes
March 2, 2004
Seoul, Korea

The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in
from Seattle via Jabber and iChat.

The short agenda was agreed to.

Sean updated the status since the last IETF meeting.

    New RFC (3657, Camellia)
    Three drafts that are with the RFC editor
        (symkeydist, x400wrap, and x400transport)
    Two drafts in WG last call (rfc2632bis and rfc2633bis)
    The draft that will go into WG last call when its editor
        finally finishes it (examples).
    Three drafts are currently active in the WG:
        cms-rsa-kem
        gost
        park-cms-seed

Sean talked about the milestones and how well we are doing on them.
We have a few short-term milestones and a much longer list of
long-term ones.

Sean gave Blake's presentation on MSGbis and CERTbis status
    Give the list of changes from last versions
    Received a bunch of editorial comments for both documents
    Russ said that other groups are using these docs, so please take
        a careful look at them.

Sean gave a presentation on GOST status
    Added a new draft with the algorithms needed for implementing GOST
    Move the default parameters to different doc
    Added message examples
    Seeking more input, particularly from implementers

Jongwook Park gave SEED updates
    Two drafts are already out there
    The algorithm is mandatory in Korea for government devices
    Approved by ISO/IEC JTC1/SC27
    Looking for comments and implementations

We finished in about 17 minutes.



From kqibafdzmwmk@168.com Thu Mar 18 22:03:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24730 for ; Thu, 18 Mar 2004 22:03:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4AIS-0005Ho-00 for smime-archive@ietf.org; Thu, 18 Mar 2004 22:03:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4AHY-0005Fx-00 for smime-archive@ietf.org; Thu, 18 Mar 2004 22:02:49 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4AHK-0005Dq-00 for smime-archive@ietf.org; Thu, 18 Mar 2004 22:02:34 -0500 Received: from pcp01851640pcs.audubn01.nj.comcast.net ([68.46.159.147]) by mx2.foretec.com with smtp (Exim 4.24) id 1B4AHM-0003n2-1b for smime-archive@ietf.org; Thu, 18 Mar 2004 22:02:36 -0500 Received: from 118.138.100.2 by 68.46.159.147; Fri, 19 Mar 2004 07:06:15 +0400 Message-ID: From: "Leopoldo Hawkins" Reply-To: "Leopoldo Hawkins" To: smime-archive@ietf.org Subject: Re: XSBARXL, now interested most Date: Fri, 19 Mar 2004 04:00:15 +0100 X-Mailer: AOL 1.0 for Windows US sub 629 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--922279006018578904" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 80.22.224.81 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.5 required=5.0 tests=FORGED_AOL_HTML, FORGED_MUA_AOL_FROM,HTML_20_30,HTML_IMAGE_ONLY_06,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 X-Spam-Report: * 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't ----922279006018578904 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Free Cable%RND_SYB TV

vague el everhart burglary clergyman metallic constituent arteriosclerosis academic carryover deflate charlotte conspire sonoma banter bow dramaturgy sedentary incandescent choosy minor descartes oust libation orthodoxy typhoid diathesis kuwait adler
wi atypic bishop bloodshot avocet ideolect blackout argive hardware horsewomen sunfish duct compatible astrophysical cyprus terror lipstick brinkmanship legitimacy syntheses larson oboist arcsin
----922279006018578904-- From owner-ietf-smime@mail.imc.org Thu Mar 18 22:42:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24431 for ; Thu, 18 Mar 2004 21:54:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2WM2p010731; Thu, 18 Mar 2004 18:32:22 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J2WM0Y010730; Thu, 18 Mar 2004 18:32:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp005.bizmail.sc5.yahoo.com (smtp005.bizmail.sc5.yahoo.com [66.163.175.82]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2J2WLCn010724 for ; Thu, 18 Mar 2004 18:32:21 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@138.88.0.49 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 19 Mar 2004 02:32:28 -0000 Message-ID: <405A5C1E.4080109@ieca.com> Date: Fri, 19 Mar 2004 11:34:06 +0900 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: Draft minutes from the Seoul meeting References: <404DB93C.2040700@ieca.com> In-Reply-To: <404DB93C.2040700@ieca.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hearing no objections I send the minutes in ot the proceedings people.

spt

Sean P. Turner wrote:

Please have all comments in by next Monday.  I want to get the presentations and minutes to the proceeding folks as soon as possible.

spt

Paul Hoffman / IMC wrote:


Greetings again. Here are my version of the minutes from last weeks meeting. Please let me know this week if you have any changes.

--Paul Hoffman


S/MIME Minutes
March 2, 2004
Seoul, Korea

The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in
from Seattle via Jabber and iChat.

The short agenda was agreed to.

Sean updated the status since the last IETF meeting.

    New RFC (3657, Camellia)
    Three drafts that are with the RFC editor
        (symkeydist, x400wrap, and x400transport)
    Two drafts in WG last call (rfc2632bis and rfc2633bis)
    The draft that will go into WG last call when its editor
        finally finishes it (examples).
    Three drafts are currently active in the WG:
        cms-rsa-kem
        gost
        park-cms-seed

Sean talked about the milestones and how well we are doing on them.
We have a few short-term milestones and a much longer list of
long-term ones.

Sean gave Blake's presentation on MSGbis and CERTbis status
    Give the list of changes from last versions
    Received a bunch of editorial comments for both documents
    Russ said that other groups are using these docs, so please take
        a careful look at them.

Sean gave a presentation on GOST status
    Added a new draft with the algorithms needed for implementing GOST
    Move the default parameters to different doc
    Added message examples
    Seeking more input, particularly from implementers

Jongwook Park gave SEED updates
    Two drafts are already out there
    The algorithm is mandatory in Korea for government devices
    Approved by ISO/IEC JTC1/SC27
    Looking for comments and implementations

We finished in about 17 minutes.



From alfred.lowepe@tvatungor.se Sat Mar 20 15:35:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24000 for ; Sat, 20 Mar 2004 15:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4nBS-0005IY-00 for smime-archive@ietf.org; Sat, 20 Mar 2004 15:35:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4nAT-0005DM-00 for smime-archive@ietf.org; Sat, 20 Mar 2004 15:34:06 -0500 Received: from d198-53-140-187.abhsia.telus.net ([198.53.140.187] helo=mojo.co.uk) by ietf-mx with smtp (Exim 4.12) id 1B4n9x-00058L-00 for smime-archive@ietf.org; Sat, 20 Mar 2004 15:33:33 -0500 Message-ID: From: "Alfred Lowe" To: smime-archive@ietf.org Subject: (538)Scientificaly proven to work(436) Date: Sat, 20 Mar 2004 22:23:42 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=CLICK_BELOW,FREE_TRIAL, HTML_70_80,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNKNOWN, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_FONT_INVISIBLE,HTML_MESSAGE, HTML_TAG_BALANCE_BODY,MIME_HTML_ONLY,PENIS_ENLARGE2 autolearn=no version=2.60 Content-Transfer-Encoding: 8bit
hgtmkbdvzvpc kkhlwmcsjuhf vbuidtcdadjsh qvwqgobwjcurab oomxqqczhfgrkb pyqdzicjuru
The only solution to Penis Enlargement
cfyutqbrfwlr sbewijbsmap
LIMITED OFFER: Add at least 3 INCHES or get your money back!
iolshejwncmlgi daxasddyiskof
We are so sure our product works we are willing to prove it by offering a free trial bottle + a 100% cash back guarantee upon purchase if you are not satisfied with the results.

---> Click Here To Learn More <---

Also check out our *brand new* product: Penis Enlargement Patches
Comes with the 100% cash back warranty as well!
vtxzvnzsuxv hptiirmyqp

dgdndecwkbnqz gwkhmqcrup


ldwagbrzuxz lmgdkobikgfaxc
No more offers From bgalindo_oz@swh-t.lv Mon Mar 22 06:45:22 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17621 for ; Mon, 22 Mar 2004 06:45:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Nru-0003mu-00 for smime-archive@ietf.org; Mon, 22 Mar 2004 06:45:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Nr3-0003iY-00 for smime-archive@ietf.org; Mon, 22 Mar 2004 06:44:29 -0500 Received: from ool-44c030e8.dyn.optonline.net ([68.192.48.232] helo=wwi.dk) by ietf-mx with smtp (Exim 4.12) id 1B5NqO-0003dx-00 for smime-archive@ietf.org; Mon, 22 Mar 2004 06:43:48 -0500 Message-ID: <0f2f01c41003$8fdf5204$ac22038c@wwi.dk> From: "Brittney Galindo" To: smime-archive@ietf.org Subject: Get cheap v i a g r a Date: Mon, 22 Mar 2004 18:46:06 +0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.7 required=5.0 tests=BIZ_TLD,GAPPY_SUBJECT, HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 8bit

Generic viagra, at cheap prices.
Most places charge $20, we charge $3. Quite a difference, right?

An amazing erection EVERY TIME is guaranteed to you!
Go into sexual overdrive today... vroooom!

Shipped to the whole world.

Your solution is here: http://www.wowrx.biz/via/?oxygen

-----
The link below is for people who hate spam.....
http://www.wowrx.biz/off.html

From owner-ietf-smime@mail.imc.org Mon Mar 22 16:09:34 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22368 for ; Mon, 22 Mar 2004 16:09:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MKjCI0028068; Mon, 22 Mar 2004 12:45:12 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MKjCET028067; Mon, 22 Mar 2004 12:45:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MKjAwG028061 for ; Mon, 22 Mar 2004 12:45:11 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19688; Mon, 22 Mar 2004 15:44:17 -0500 (EST) Message-Id: <200403222044.PAA19688@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-01.txt Date: Mon, 22 Mar 2004 15:44:17 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Cryptographic Message Syntax (CMS) Author(s) : R. Housley Filename : draft-ietf-smime-rfc3369bis-01.txt Pages : 55 Date : 2004-3-22 This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc3369bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-22151357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc3369bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-22151357.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Mon Mar 22 17:12:41 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28225 for ; Mon, 22 Mar 2004 17:12:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MLnD19033602; Mon, 22 Mar 2004 13:49:13 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MLnDuJ033601; Mon, 22 Mar 2004 13:49:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mlnya401er.ml.com (mlnya401er.ml.com [199.43.38.99]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MLnDIa033595 for ; Mon, 22 Mar 2004 13:49:13 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from mlnya303bh.amrs.win.ml.com (unknown [146.125.109.101]) by mlnya401er.ml.com (Postfix) with ESMTP id 0A5611B55 for ; Mon, 22 Mar 2004 16:49:13 -0500 (EST) thread-index: AcQQV4EpSL1P/RuMSKCW7HAPVoQNng== Received: from mail pickup service by mlnya303bh.amrs.win.ml.com with Microsoft SMTPSVC; Mon, 22 Mar 2004 16:49:08 -0500 Received: from MLTKA302BH.aja.win.ml.com ([170.242.208.96]) by mlnya301bh.amrs.win.ml.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Mar 2004 16:22:17 -0500 Received: from tkpsexh12.exchange.japan.ml.com ([170.242.29.194]) by MLTKA302BH.aja.win.ml.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Mar 2004 06:22:14 +0900 Received: by tkpsexh12.exchange.japan.ml.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Mar 2004 06:22:18 +0900 Received: from ewstwt04.exchange.ml.com ([146.125.249.154]) by tkpsexh8.exchange.japan.ml.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HNMYD656; Tue, 23 Mar 2004 06:22:15 +0900 Received: from 146.125.185.11 by ewstwt04.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Mon, 22 Mar 2004 16:22:11 -0500 Received: from wstutil12a.ml.com (wstutil12a-v [209.65.19.67]) by wstutil13a.ml.com (8.12.10/8.12.5/wstutil13a-1.1) with ESMTP id i2MLME1u027023 for ; Mon, 22 Mar 2004 16:22:14 -0500 (EST) Received: from psmtp.com (exprod6mx67.postini.com [12.158.36.51]) by wstutil12a.ml.com (8.12.10/8.12.5/wstutil12a-1.2) with SMTP id i2MLM9Ng004309 for ; Mon, 22 Mar 2004 16:22:09 -0500 (EST) Received: from source ([132.151.6.40]) by exprod6mx67.postini.com ( [12.158.35.251]) with SMTP; Mon, 22 Mar 2004 13:22:08 PST Content-Transfer-Encoding: 7bit Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1B5WSV-0001RA-At for ietf-announce-list@asgard.ietf.org; Mon, 22 Mar 2004 15:55:43 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp ( Exim 4.14) id 1B5WIP-000107-Ow for all-ietf@asgard.ietf.org; Mon, 22 Mar 2004 15:45:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org ( 8.9.1a/8.9.1a) with ESMTP id PAA19688; Mon, 22 Mar 2004 15:44:17 -0500 (EST) X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Message-ID: <200403222044.PAA19688@ietf.org> MIME-Version: 1.0 To: <"IETF-Announce:"@mlnya401er.ml.com> Cc: Content-Class: urn:content-classes:message Importance: normal From: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Reply-To: Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-01.txt Date: Mon, 22 Mar 2004 15:44:17 -0500 X-pstn-levels: (S:34.91659/99.43921 P:95.9108 ) X-pstn-settings: 1 (0.1500:0.1500) p X-pstn-addresses: from [db-null] X-WSS-ID: 6C418689835493-01-01 Content-Type: multipart/mixed; boundary="NextPart" X-OriginalArrivalTime: 22 Mar 2004 21:22:14.0705 (UTC) FILETIME=[BF101A10:01C41053] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --NextPart Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the S/MIME Mail Security Working Group of = the IETF. Title : Cryptographic Message Syntax (CMS) Author(s) : R. Housley Filename : draft-ietf-smime-rfc3369bis-01.txt Pages : 55 Date : 2004-3-22 =09 This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-01.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc3369bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.=20 -------------------------------------------------------- =20 If you are not an intended recipient of this e-mail, please notify the = sender, delete it and do not read, act upon, print, disclose, copy, = retain or redistribute it. Click here for important additional terms = relating to this e-mail. http://www.ml.com/email_terms/=20 -------------------------------------------------------- =20 --NextPart Content-Type: multipart/alternative; boundary="OtherAccess" --OtherAccess Content-Type: message/external-body; access-type=mail-server; server=mailserv@ietf.org Content-Transfer-Encoding: 7bit Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-22151357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt --OtherAccess Content-Type: message/external-body; access-type=anon-ftp; site=ftp.ietf.org; directory=internet-drafts; name="draft-ietf-smime-rfc3369bis-01.txt" Content-Transfer-Encoding: 7bit --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Mon Mar 22 20:50:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09696 for ; Mon, 22 Mar 2004 20:50:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N1RmP3045911; Mon, 22 Mar 2004 17:27:48 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2N1RmHU045910; Mon, 22 Mar 2004 17:27:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N1RlFw045904 for ; Mon, 22 Mar 2004 17:27:47 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id D555A6A97B; Mon, 22 Mar 2004 17:27:52 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Russ Housley'" Cc: Subject: Comments on draft-ietf-smime-rfc3369bis-01.txt Date: Mon, 22 Mar 2004 17:32:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQQV4EpSL1P/RuMSKCW7HAPVoQNngAG/soA In-Reply-To: <200403222044.PAA19688@ietf.org> Message-Id: <20040323012752.D555A6A97B@smtp4.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1. Section 5.1, para version: Grammer issue s/certificates is present/certificates are present/ 2. Section 5.1, para version: Correct to the beginning of the if clauses should be IF (any certificates with a type of other are present) OR (any crls with a type of other are present) THEN version MUST be 5. The other two clauses add nothing to the text. 3. Section 5.3: Consider the following text. When generating a SignerIdentifier, implementations MAY support one of the forms (either issuerAndSerialNumber or subjectKeyIdentifier) and always use it, or implementations MAY arbitrarily mix the two forms. I think that it might need to be updated for dealing with OTHER, but I don't know what to really say about that. 4. Section 6.2.1, para 'rid': s/signer's/recipient's/ 5. Section 6.2.2, para 'originator': s/thereby the sender's public key, a/thereby the sender's public key, by a/ Jim From owner-ietf-smime@mail.imc.org Wed Mar 24 18:03:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27487 for ; Wed, 24 Mar 2004 18:03:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OMZ0Jj096462; Wed, 24 Mar 2004 14:35:00 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2OMZ0xO096461; Wed, 24 Mar 2004 14:35:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2OMYxuE096452 for ; Wed, 24 Mar 2004 14:34:59 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 11611 invoked by uid 0); 24 Mar 2004 22:26:02 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.242.191) by woodstock.binhost.com with SMTP; 24 Mar 2004 22:26:02 -0000 Message-Id: <5.2.0.9.2.20040324172111.03aa6a20@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 17:35:02 -0500 To: From: Russ Housley Subject: Re: Comments on draft-ietf-smime-rfc3369bis-01.txt Cc: In-Reply-To: <20040323012752.D555A6A97B@smtp4.pacifier.net> References: <200403222044.PAA19688@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim: Thanks for the continuing quality review. >1. Section 5.1, para version: Grammer issue s/certificates is >present/certificates are present/ I consider this to be short for: if the certificates field is present, then ... Since the name of the field is plural, it does lead to an awkward read, but I think it is okay. >2. Section 5.1, para version: Correct to the beginning of the if clauses >should be > IF (any certificates with a type of other are present) OR > (any crls with a type of other are present) > THEN version MUST be 5. > > The other two clauses add nothing to the text. This is the way we did it in the past: IF (certificates is present) AND (any version 2 attribute certificates are present) THEN version MUST be 4 We say: if the field is present and that field contains the new thing, then .... >3. Section 5.3: Consider the following text. > > When generating a SignerIdentifier, > implementations MAY support one of the forms (either > issuerAndSerialNumber or subjectKeyIdentifier) and always use it, > or implementations MAY arbitrarily mix the two forms. > > I think that it might need to be updated for dealing with OTHER, but >I don't know what to really say about that. I added: "However, subjectKeyIdentifier MUST be used to refer to a public key contained in a non-X.509 certificate." Does that address your concern? >4. Section 6.2.1, para 'rid': s/signer's/recipient's/ Good catch. It will be fixed in version -02. >5. Section 6.2.2, para 'originator': s/thereby the sender's public key, >a/thereby the sender's public key, by a/ Good catch. It will be fixed in version -02. Russ From owner-ietf-smime@mail.imc.org Wed Mar 24 20:59:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06735 for ; Wed, 24 Mar 2004 20:59:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P1aeI3010524; Wed, 24 Mar 2004 17:36:40 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2P1ae1S010523; Wed, 24 Mar 2004 17:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-148.dsl.snfc21.pacbell.net [63.202.92.148]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P1adgA010515 for ; Wed, 24 Mar 2004 17:36:40 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Wed, 24 Mar 2004 17:36:42 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: A good article on S/MIME implementation problems Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. I wouldn't normally send "here's another S/MIME article" messages to the list, but this author has done an excellent job of both finding the problem and proposing solutions. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@mail.imc.org Thu Mar 25 08:07:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18944 for ; Thu, 25 Mar 2004 08:07:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PCkCpP025431; Thu, 25 Mar 2004 04:46:12 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PCkCdF025430; Thu, 25 Mar 2004 04:46:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2PCkA0a025414 for ; Thu, 25 Mar 2004 04:46:11 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 23783 invoked by uid 0); 25 Mar 2004 12:37:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.183.67) by woodstock.binhost.com with SMTP; 25 Mar 2004 12:37:01 -0000 Message-Id: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 25 Mar 2004 07:45:44 -0500 To: Paul Hoffman / IMC From: Russ Housley Subject: Re: A good article on S/MIME implementation problems Cc: ietf-smime@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: I do not completely agree with your assessment. I had a short email exchange with Jon Udell, and I made the following points. 1. The article gives the impression is that S/MIME is broken, and this is not the case. I would have been much happier with a title that conveyed problems with certificate issuing services and the ramifications of poor identity proofing. S/MIME is not the only security protocol that will suffer if the identity in a certificate is bogus. 2. As far as S/MIME is concerned, the email address is the identity. X.500 Distinguished Names are not helpful to the S/MIME application, as there are not any protocol fields that make use of this form of identity. 3. The fact that Outlook hides the only form of identity that is validated is the biggest problem. Now that a script has been posted, maybe we should put some stronger language in MSGbis about the user interface. Russ At 05:36 PM 3/24/2004 -0800, Paul Hoffman / IMC wrote: >Greetings again. I wouldn't normally send "here's another S/MIME article" >messages to the list, but this author has done an excellent job of both >finding the problem and proposing solutions. > > > >--Paul Hoffman, Director >--Internet Mail Consortium > From owner-ietf-smime@mail.imc.org Thu Mar 25 11:54:27 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06520 for ; Thu, 25 Mar 2004 11:54:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PGSJqx047060; Thu, 25 Mar 2004 08:28:19 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PGSJNI047059; Thu, 25 Mar 2004 08:28:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PGSGp3047050; Thu, 25 Mar 2004 08:28:17 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> Date: Thu, 25 Mar 2004 08:17:44 -0800 To: Russ Housley From: Paul Hoffman / IMC Subject: Re: A good article on S/MIME implementation problems Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 7:45 AM -0500 3/25/04, Russ Housley wrote: >1. The article gives the impression is that S/MIME is broken, and >this is not the case. I would have been much happier with a title >that conveyed problems with certificate issuing services and the >ramifications of poor identity proofing. S/MIME is not the only >security protocol that will suffer if the identity in a certificate >is bogus. We disagree that the article gives the impression that S/MIME is broken. Reading it, I came away with the impression that some S/MIME implementations are broken. Maybe I've been working with this too long and I know that S/MIME isn't broken. >2. As far as S/MIME is concerned, the email address is the >identity. X.500 Distinguished Names are not helpful to the S/MIME >application, as there are not any protocol fields that make use of >this form of identity. Exactly right. The fact that Thawte asks for, and some S/MIME applications use, it shows a disregard for the standard. They are blatantly ignoring the SHOULD NOT. >3. The fact that Outlook hides the only form of identity that is >validated is the biggest problem. Absolutely true, and pretty clear from the article. >Now that a script has been posted, maybe we should put some stronger >language in MSGbis about the user interface. That would be nice. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@mail.imc.org Thu Mar 25 13:59:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13809 for ; Thu, 25 Mar 2004 13:59:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PIbW3I058423; Thu, 25 Mar 2004 10:37:32 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PIbWIq058422; Thu, 25 Mar 2004 10:37:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PIbV31058410 for ; Thu, 25 Mar 2004 10:37:32 -0800 (PST) (envelope-from dpkemp@missi.ncsc.mil) Message-ID: <200403251808.i2PI8GRK022057@stingray.missi.ncsc.mil> Date: Thu, 25 Mar 2004 13:37:29 -0500 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: A good article on S/MIME implementation problems References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Not exactly right. There is a difference between an RFC822 address as a user identity and an RFC822 address as routing information to enable message delivery. If I have a certificate identifying me as dpkemp@missi.ncsc.mil, then S/MIME user agents should display my identity without rejecting, or even whining, if I send a signed message from my hotmail account. And S/MIME user agents should allow me to encrypt a message to Paul using his imc.org certificate, but address it to Paul's hotmail account, without rejection or whining. Using a different syntax for subject names and email addresses makes this distinction obvious and would force user agents to operate correctly. Using the same RFC822 syntax for both subject names and email addresses leads to confusion between a user's single identity and that user's multiple mailboxes. Mismatch between an identity in a certificate and an unauthenticated address in a message header is NOT a security vulnerability. Displaying an unauthenticated message header as if it were an authenticated identity IS a vulnerability. Blurring this distinction by saying "the email address is the identity" is wrong, even if it is written down in black and white in the RFCs. Dave Paul Hoffman / IMC wrote: >> 2. As far as S/MIME is concerned, the email address is the identity. >> X.500 Distinguished Names are not helpful to the S/MIME application, >> as there are not any protocol fields that make use of this form of >> identity. > > Exactly right. The fact that Thawte asks for, and some S/MIME > applications use, it shows a disregard for the standard. They are > blatantly ignoring the SHOULD NOT. From owner-ietf-smime@mail.imc.org Thu Mar 25 14:44:31 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15740 for ; Thu, 25 Mar 2004 14:44:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PJOA39062491; Thu, 25 Mar 2004 11:24:10 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PJOAFE062490; Thu, 25 Mar 2004 11:24:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2PJO9J2062480 for ; Thu, 25 Mar 2004 11:24:09 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 1452 invoked by uid 0); 25 Mar 2004 19:14:58 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.77) by woodstock.binhost.com with SMTP; 25 Mar 2004 19:14:58 -0000 Message-Id: <5.2.0.9.2.20040325122850.03bd87c8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 25 Mar 2004 12:45:19 -0500 To: Paul Hoffman / IMC From: Russ Housley Subject: Re: A good article on S/MIME implementation problems Cc: ietf-smime@imc.org In-Reply-To: References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: >>1. The article gives the impression is that S/MIME is broken, and this >>is not the case. I would have been much happier with a title that >>conveyed problems with certificate issuing services and the ramifications >>of poor identity proofing. S/MIME is not the only security protocol that >>will suffer if the identity in a certificate is bogus. > >We disagree that the article gives the impression that S/MIME is broken. >Reading it, I came away with the impression that some S/MIME >implementations are broken. Maybe I've been working with this too long and >I know that S/MIME isn't broken. The title implies that S/MIME is broken. >>2. As far as S/MIME is concerned, the email address is the >>identity. X.500 Distinguished Names are not helpful to the S/MIME >>application, as there are not any protocol fields that make use of this >>form of identity. > >Exactly right. The fact that Thawte asks for, and some S/MIME applications >use, it shows a disregard for the standard. They are blatantly ignoring >the SHOULD NOT. Agree. >>3. The fact that Outlook hides the only form of identity that is >>validated is the biggest problem. > >Absolutely true, and pretty clear from the article. Yes. So, the title of the article could have been more descriptive of the real issue. >>Now that a script has been posted, maybe we should put some stronger >>language in MSGbis about the user interface. > >That would be nice. Maybe the editor can generate some proposed text. Russ From owner-ietf-smime@mail.imc.org Fri Mar 26 00:06:23 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15707 for ; Fri, 26 Mar 2004 00:06:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4iU9R003396; Thu, 25 Mar 2004 20:44:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4iUAA003395; Thu, 25 Mar 2004 20:44:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0ru003338 for ; Thu, 25 Mar 2004 20:44:30 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Thu, 25 Mar 2004 20:44:37 -0800 From: "Blake Ramsdell" To: "'Sean P. Turner'" Cc: Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Date: Thu, 25 Mar 2004 20:44:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4044BA02.3070207@ieca.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Comments inline. Good luck finding them. -----Original Message----- From: Sean P. Turner [mailto:turners@ieca.com] Sent: Tuesday, March 02, 2004 8:45 AM To: Blake Ramsdell Cc: ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Para 1.3, Certificate definition: Replace "distinguished name" with "name" the names are not always "distinguished." [bcr] Neat. That's not even correct either. It binds a bunch of arbitrary things (including a picture of your cat) to a public key. Switched to "name". Para 1.3, Receiving agent, Sending agent, and S/MIME agent definitions: Capitalize 1st word "software" and "user." [bcr] Done. Para 2.2, Last paragraph last sentence: replace "and may not implement id-dsa-with-sha1 at all" with "and may not implement id-dsa-with-sha1 or id-sha at all." [bcr] I presume you meant "id-dsa" not "id-sha" here. Done. Para 2.4.2, SignedData Content Type: Can we add a sentence that says "Applying a signature to message provides authentication, message integrity, and non-repudiation of origin." The other content types indicate what "services" they support or don't support. [bcr] Done. Para 2.4.4, 2nd sentence: Replace "This content type does not provide authentication or privacy" with "This content type does not provide authentication, message integrity, non-repudiation, or data confidentiality". Just making it match the "services" listed in the introduction. [bcr] Done. Para 3.1, Steps 1-4: Add periods to end of sentences. [bcr] Done. Para 3.1.3, 3rd Para 2nd sentence: Replace "8-bit clear" with "8-bit clean" to match terminology in 3.1.2 2nd paragraph 4 sentence. [bcr] Done. Para 3.3, Step 2, last sentence: Replace "(see CMS Section 6)" with (see [CMS] Section 6). [bcr] Done. Para 3.4.2, Steps 1&2: Add periods to end of sentences. [bcr] Done. Compressed data text in 3.5 points to 3.1 but there's no mention in 3.1 of compression. You should either add a sentence to say that in 3.1 enveloped = compression in this section or make the following changes (or others to clarify that you also mean to refer to compression data): Para 3.1, Title: Replace "Signing or Enveloping" with "Signing, Enveloping, or Compressing" because para 3.5 says perform message as in 3.1 but there's not mention of compressing in 3.1. [bcr] Done. Para 3.1, 1st para 1st sentence: Replace "S/MIME is used to secure MIME entities" with "S/MIME is used to secure and optionally compress MIME entities." [bcr] Done. Para 3.1, 2nd para 1st sentence: Replace "The MIME entity that is secured and ..." with "The MIME entity that is secured or compressed and ..." [bcr] Nope. We're going with "secured" here until someone comes up with a concise word that means "signed or encrypted or compressed". Para 3.1, 4th para 1st sentence: Replace "A single procedure is used for creating MIME entities that are to be signed, enveloped, or both signed and enveloped" with "A single procedure is used for creating MIME entities that are to be signed, enveloped, compressed and both signed and enveloped, signed and compressed, compressed and enveloped, and compressed, signed, and enveloped, etc." (or whatever # of combinations you feel like listing) [bcr] A single procedure is used for creating MIME entities that are to have any combination of signing, enveloping and compressing applied. Para 3.1, 4th para 3rd sentence: Replace "It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages" with "It is recommended that these additional steps be performed on enveloped and compressed messages, or signed and enveloped messages or compressed, signed and enveloped messages." [bcr] I'm not even sure what the spirit of this guidance is. No change -- either suggest less awkward language or help me figure out what the spirit of this is. Para 3.1, 1st para after Step 3: Replace "the security services on the message are processed" with "the security services or compression on the message are processed" [bcr] See previous discussion about "secured" Para 3.5, Step 1: Replace "to be enveloped" with "to be compressed". [bcr] Done. Para 3.7, Step 3: Add period to end of sentence. [bcr] Done. Annex F, Remove prior to submission to IESG (?) [bcr] No more changes from last draft. From owner-ietf-smime@mail.imc.org Fri Mar 26 00:06:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15721 for ; Fri, 26 Mar 2004 00:06:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i1ob003350; Thu, 25 Mar 2004 20:44:01 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4i1XI003349; Thu, 25 Mar 2004 20:44:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0rs003338 for ; Thu, 25 Mar 2004 20:44:00 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Thu, 25 Mar 2004 20:44:00 -0800 From: "Blake Ramsdell" To: "'Russ Housley'" , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Date: Thu, 25 Mar 2004 20:44:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Sunday, February 29, 2004 9:16 PM > To: Blake Ramsdell; ietf-smime@imc.org > Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt > > 1. Should Section 1.4 reference RFC 3369? This section just describes where "prior practice of S/MIME" is located. I think that RFC 3369 is "current practice of S/MIME". > 2. Delete section 1.6 before the document is sent to the IESG. Deleted. > 3. Section 2.4 probably should point out that ContentInfo is > needed to > encapsulate each of the protection content types. Hmm. I don't agree. This is meant to describe the subset of types that are supported by S/MIME, independent of their encoding. > 4. What compression algorithm MUST be implemented if > CompressedData is > supported? Has this train finished wrecking or is it still in progress? > 5. Section 2.5.2: s/SMIMECapabilities attribute > should/SMIMECapabilities > attribute SHOULD/ Fixed. > 6. Section 2.6: the first two paragraphs are not clear. > S/MIME v3.1 MUST > support both issuerAndSerialNumber and subjectKeyIdentifier > for sending and > receiving. S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as well as subjectKeyIdentifier. Messages that use the subjectKeyIdentifier choice cannot be read by S/MIME v2 clients. > 7. Section 3.4.3.2: s/not currently supported in S/MIME/not > currently > recommended in S/MIME/ Fixed. Blake From owner-ietf-smime@mail.imc.org Fri Mar 26 00:06:28 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15744 for ; Fri, 26 Mar 2004 00:06:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4iHdK003366; Thu, 25 Mar 2004 20:44:17 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4iHmx003365; Thu, 25 Mar 2004 20:44:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0rt003338 for ; Thu, 25 Mar 2004 20:44:16 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Thu, 25 Mar 2004 20:44:23 -0800 From: "Blake Ramsdell" To: Cc: "'Ietf-Smime'" Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Date: Thu, 25 Mar 2004 20:44:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040308102917.989E58ABD7@smtp2.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Monday, March 08, 2004 2:34 AM > To: 'Blake Ramsdell' > Cc: Ietf-Smime > Subject: Comments draft-ietf-smime-rfc2633bis-07.txt > > 1. I just realized there is no abstract for this document. Is one > required? Don't know -- someone comment. > 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/ Done. > 3. Section 1.1, p 4: Should there be a dependency/reference > to CMSALG here > as well? Dunno. "No" for now. > 4. Section 2.5.2, p1: Need to add text for Compression Algorithms. Suggest language. > 5. Section 2.5.2: The following statement is no longer true (please > delete): > Note that all OIDs associated with the MUST and SHOULD > implement algorithms > are included in section A of this document. Entire paragraph removed. > 6. section 3, p 1: s/[ESS] document provides examples/[ESS] document > provides descriptions/ > s/ESS provides an example of/ESS provides a > description of/ Done. > 7. Section 3.1, p 5, s/implementor/implementer/ > Section 3.6, p 3: ditto > Section 4.1, p 2: ditto > - I don't know if that is really an incorrect spelling, > but MS Word > does not know it. This is like "advisor" vs. "adviser" I think. In any case, can't have Word upset, so modified. > 8. Section 3.2.1, > s/Application/pkcs7-signature/Application/pkcs7-signature > (SignedData)/ Done. > 9. Section 3.2.2, p last: Suggest adding the text: "An smime-type > parameters is not intended to give indications of security > layers applied in > the event of multiple levels of wrapping." What do you see as the confusion here? Not done. > 10. Section 3.4: In general, the multipart/signed form is > preferred for > sending, and > receiving agents SHOULD be able to handle both. --- what is > the MUST handle? > Otherwise there is no interop. Don't know -- bees nest. Start a discussion... If you say MUST send SignedData, I imagine that's going to be an issue. Maybe MUST multipart/signed? > 11: Section 3.4.3.2: The text > "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not > currently supported in S/MIME, and are included here for > completeness." > Is only partially correct. They are supported, just not > required by this > document. I would like to clean this up by saying this in a tighter > fashion. Could use some language, but this may have been handled when I fixed it for someone else. > 12. Section 4, p 1: s/certification/certificate/ Done. > 13. Section A: s/prefered/preferred/ Done. > 14. References: CMSAES = RFC 3565 Done. > 15. Section 1.1, p 4: s/the Cryptographic Message Syntax/the > Cryptographic > Message Syntax document/ Done. > 16. Is a specification MUST/SHOULD (section 1.1, p4) or the document > (section 1.1, p3) (The same word is used, but in completely different > meanings. Would not be a problem but for the MUST in p4 > potentially wanting > to force meaning into p3). No idea -- reword and I'll try and parse it again. > 17. Section 2.2, p 3: s/the algorithms/the hash algorithms/ Done. "the digest algorithms" I believe is more correct. > 18. Section 2.4.1, p1: s/signedData/SignedData/ > - also envelopedData vs EnvelopedData and compressedData vs > CompressedData. > signedData does not actually exist in the CMS > documents. The type > is SignedData or the concept is signed data. I think we need > to clean this > up. > Russ: Please note there is one section in CMS that needs to be > cleaned up in the same way. Done. > 19. Section 2.4.1, p1: s/encryptedContentInfo > ContentType/encryptedContentInfo contentType/ Done. > 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/ 18. > 21. Section 2.4.2, p1: Should add "This content type does not provide > privacy." And also add "and does not provide compression"? Should we just remove "does not provide authentication" from the EnvelopedData section? Not changed. > 22. Section 2.5 title, s/Attribute/Attributes and the/ Done. > 23. Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/ Done. > > 24. I heard this comment at the last IETF meeting from > somebody. As I have > had the same problem in a number of cases (esp with doing > interop matrixes) > I am throwing it out for your consideration: > > The use of the words must, should and may in lower case causes some > confusion dealing with the question of - did the author just forget to > uppercase this or is it really not a protocol statement. > SHOULD examine all > instances of these words to see if a different word works > just as well. Ugh. MAY. Blake From owner-ietf-smime@mail.imc.org Fri Mar 26 00:42:54 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17356 for ; Fri, 26 Mar 2004 00:42:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q5PhnY005428; Thu, 25 Mar 2004 21:25:43 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q5Phbu005427; Thu, 25 Mar 2004 21:25:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q5PeDH005419; Thu, 25 Mar 2004 21:25:41 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 25 Mar 2004 21:25:46 -0800 To: "Blake Ramsdell" , From: Paul Hoffman / IMC Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Cc: "'Ietf-Smime'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:44 PM -0800 3/25/04, Blake Ramsdell wrote: > > 1. I just realized there is no abstract for this document. Is one >> required? > >Don't know -- someone comment. Yes, an abstract is required. The wimpy way out is to move the first paragraph of the Intro into the Abstract. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@mail.imc.org Fri Mar 26 02:31:53 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04495 for ; Fri, 26 Mar 2004 02:31:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7AiBC031465; Thu, 25 Mar 2004 23:10:44 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q7AiDK031464; Thu, 25 Mar 2004 23:10:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7AiR1031455 for ; Thu, 25 Mar 2004 23:10:44 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 166306AACC for ; Thu, 25 Mar 2004 23:10:52 -0800 (PST) Reply-To: From: "Jim Schaad" To: Subject: Interop Requirement for Signed Data formats Date: Thu, 25 Mar 2004 23:15:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQTAh9qhsbAimd1RLqKFQS7JKZZxg== Message-Id: <20040326071052.166306AACC@smtp4.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In my last review of the document I found the following text in section 3.4 There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both. The problem here is that there is no interop in the signed message format as specified by the above statement. I.E. Person one could implement application/pkcs7-mime only and person two could implemement multipart/signed only -- no interop. The best change for interop purposes is to change the SHOULD to a MUST. Comments? Jim From owner-ietf-smime@mail.imc.org Fri Mar 26 02:38:43 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04824 for ; Fri, 26 Mar 2004 02:38:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7LK6j034973; Thu, 25 Mar 2004 23:21:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q7LKGr034972; Thu, 25 Mar 2004 23:21:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7LJYF034963 for ; Thu, 25 Mar 2004 23:21:19 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id A086A6DC85; Thu, 25 Mar 2004 23:21:18 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: "'Ietf-Smime'" Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Date: Thu, 25 Mar 2004 23:25:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQS7QVggYqlfjUySm+aWuy4Pbny5QAE+WNw In-Reply-To: Message-Id: <20040326072118.A086A6DC85@smtp3.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Blake, See in line comments. Jim -----Original Message----- From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] Sent: Thursday, March 25, 2004 8:44 PM To: jimsch@exmsft.com Cc: 'Ietf-Smime' Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Monday, March 08, 2004 2:34 AM > To: 'Blake Ramsdell' > Cc: Ietf-Smime > Subject: Comments draft-ietf-smime-rfc2633bis-07.txt > > 3. Section 1.1, p 4: Should there be a dependency/reference to CMSALG > here as well? Dunno. "No" for now. [JLS] - OK -- I think there needs to be an equivalent statement for [CMSALG] for algorithm parameter encoding. > 4. Section 2.5.2, p1: Need to add text for Compression Algorithms. Suggest language. [JLS] Never mind -- I missed it on the first read for some reason. > 9. Section 3.2.2, p last: Suggest adding the text: "An smime-type > parameters is not intended to give indications of security layers > applied in the event of multiple levels of wrapping." What do you see as the confusion here? Not done. [JLS] If you do a E(S(Receipt)) - The correct smime-type under the current rules is "enveloped-data" not "signed-receipt". I think this makes it more explicit what is done for multiple layered messages. > 10. Section 3.4: In general, the multipart/signed form is preferred > for sending, and receiving agents SHOULD be able to handle both. --- > what is the MUST handle? > Otherwise there is no interop. Don't know -- bees nest. Start a discussion... If you say MUST send SignedData, I imagine that's going to be an issue. Maybe MUST multipart/signed? [JLS] Is now started. > 11: Section 3.4.3.2: The text > "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not > currently supported in S/MIME, and are included here for > completeness." > Is only partially correct. They are supported, just not required by > this document. I would like to clean this up by saying this in a > tighter fashion. Could use some language, but this may have been handled when I fixed it for someone else. [JLS] The SHA-256, SHA-384, and SHA-512 algorithms are defined in [FIBS180-2][PKIX-RSA-PKALGS]. Support is not currently required in S/MIME and the micalg values are included here for completeness. > 16. Is a specification MUST/SHOULD (section 1.1, p4) or the document > (section 1.1, p3) (The same word is used, but in completely different > meanings. Would not be a problem but for the MUST in p4 potentially > wanting to force meaning into p3). No idea -- reword and I'll try and parse it again. [JLS] Change specification to document in p3 and I'll be happy. 'This specification also discusses' 'MUST follow the specifications in this document' > 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/ 18. [JLS] - NAK > 21. Section 2.4.2, p1: Should add "This content type does not provide > privacy." And also add "and does not provide compression"? Should we just remove "does not provide authentication" from the EnvelopedData section? Not changed. [JLS] Works for me. > > 24. I heard this comment at the last IETF meeting from somebody. As > I have had the same problem in a number of cases (esp with doing > interop matrixes) I am throwing it out for your consideration: > > The use of the words must, should and may in lower case causes some > confusion dealing with the question of - did the author just forget to > uppercase this or is it really not a protocol statement. > SHOULD examine all > instances of these words to see if a different word works just as > well. Ugh. MAY. [JLS] - Yes Ugh - SHOULD. Blake From owner-ietf-smime@mail.imc.org Fri Mar 26 04:00:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08362 for ; Fri, 26 Mar 2004 04:00:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q8dkSA067355; Fri, 26 Mar 2004 00:39:46 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q8dk3v067354; Fri, 26 Mar 2004 00:39:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q8dj8w067322 for ; Fri, 26 Mar 2004 00:39:45 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Fri, 26 Mar 2004 00:39:40 -0800 From: "Blake Ramsdell" To: Cc: "'Ietf-Smime'" Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Date: Fri, 26 Mar 2004 00:39:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040326072118.A086A6DC85@smtp3.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Thursday, March 25, 2004 11:26 PM > To: 'Blake Ramsdell' > Cc: 'Ietf-Smime' > Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt > > -----Original Message----- > From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] > Sent: Thursday, March 25, 2004 8:44 PM > To: jimsch@exmsft.com > Cc: 'Ietf-Smime' > Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt > > > -----Original Message----- > > From: Jim Schaad [mailto:jimsch@nwlink.com] > > Sent: Monday, March 08, 2004 2:34 AM > > To: 'Blake Ramsdell' > > Cc: Ietf-Smime > > Subject: Comments draft-ietf-smime-rfc2633bis-07.txt > > > > > 3. Section 1.1, p 4: Should there be a > dependency/reference to CMSALG > > here as well? > > Dunno. "No" for now. > > [JLS] - OK -- I think there needs to be an equivalent > statement for [CMSALG] > for algorithm parameter encoding. I may not understand this. Are you saying that I need to recursively include all of the PKIX and CMS references? CMSALG is implicitly required by CMS in this case, I think. Maybe this paragraph just needs to go away, or I need to understand better why CMSALG (which is required by CMS) needs to be called out explicitly. > > 9. Section 3.2.2, p last: Suggest adding the text: "An > smime-type > > parameters is not intended to give indications of security layers > > applied in the event of multiple levels of wrapping." > > What do you see as the confusion here? Not done. > > [JLS] If you do a E(S(Receipt)) - The correct smime-type > under the current > rules is "enveloped-data" not "signed-receipt". I think this > makes it more > explicit what is done for multiple layered messages. There is existing guidance: It is explicitly intended that this field be a suitable hint for mail client applications to indicate whether a message is "signed" or "encrypted" without having to tunnel into the CMS payload. I think that this paragraph is sufficient as-is -- what would you modify? Should it be something like: It is explicitly intended that this field be a suitable hint for mail client applications to indicate the "essence" of the message without having to tunnel into the CMS payload. Or something like that? I need more help. > > 11: Section 3.4.3.2: The text > > "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not > > currently supported in S/MIME, and are included here for > > completeness." > > Is only partially correct. They are supported, just not > required by > > this document. I would like to clean this up by saying this in a > > tighter fashion. > > Could use some language, but this may have been handled when > I fixed it for > someone else. > > [JLS] The SHA-256, SHA-384, and SHA-512 algorithms are defined in > [FIBS180-2][PKIX-RSA-PKALGS]. Support is not currently > required in S/MIME > and the micalg values are included here for completeness. "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not currently recommended in S/MIME, and are included here for completeness." Is the language change I made for someone else. > > 16. Is a specification MUST/SHOULD (section 1.1, p4) or > the document > > (section 1.1, p3) (The same word is used, but in completely > different > > meanings. Would not be a problem but for the MUST in p4 > potentially > > wanting to force meaning into p3). > > No idea -- reword and I'll try and parse it again. > > [JLS] Change specification to document in p3 and I'll be happy. > > 'This specification also discusses' > 'MUST follow the specifications in this document' OK, next round. > > 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/ > > 18. > > [JLS] - NAK "Same as your #18 and fixed". > > 21. Section 2.4.2, p1: Should add "This content type does > not provide > > privacy." > > And also add "and does not provide compression"? Should we > just remove "does > not provide authentication" from the EnvelopedData section? > Not changed. > > [JLS] Works for me. Next round. > > 24. I heard this comment at the last IETF meeting from > somebody. As > > I have had the same problem in a number of cases (esp with doing > > interop matrixes) I am throwing it out for your consideration: > > > > The use of the words must, should and may in lower case causes some > > confusion dealing with the question of - did the author > just forget to > > uppercase this or is it really not a protocol statement. > > SHOULD examine all > > instances of these words to see if a different word works just as > > well. > > Ugh. MAY. > > [JLS] - Yes Ugh - SHOULD. MIGHT next round? Blake From lfahwwrtda@mail.com Fri Mar 26 04:54:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10072 for ; Fri, 26 Mar 2004 04:53:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6o2J-0004va-00 for smime-archive@ietf.org; Fri, 26 Mar 2004 04:53:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6o1T-0004qu-00 for smime-archive@ietf.org; Fri, 26 Mar 2004 04:53:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6o0y-0004lJ-00 for smime-archive@ietf.org; Fri, 26 Mar 2004 04:52:36 -0500 Received: from [218.235.97.8] (helo=ODS002) by mx2.foretec.com with smtp (Exim 4.24) id 1B6o0z-0006F1-4r for smime-archive@ietf.org; Fri, 26 Mar 2004 04:52:38 -0500 Received: from [218.235.97.8] by 111.212.70.120 with HTTP; Thu, 25 Mar 2004 16:54:37 -0500 From: "Maude Livingston" To: smime-archive@ietf.org Subject: glaswegian Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [111.212.70.120] Date: Thu, 25 Mar 2004 16:54:37 -0500 Reply-To: "Maude Livingston" Content-Type: multipart/alternative; boundary="36797503103940749" Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=BIZ_TLD,DATE_IN_PAST_06_12, HTML_MESSAGE autolearn=no version=2.60 --36797503103940749 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit heroin massage card concentric croupier eastbound pigtail massage twirly polaron aristotle hyaline barefaced connotative zag principal contractual florican volvo intricacy doom dyspeptic --36797503103940749 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit Dunbar%

Need onlineMd RX +

valiumXanax

SomaCialis

seenow!

http://www.salsa7535drugs.biz/B32/

__

deborah,over the platform.

--36797503103940749-- From owner-ietf-smime@mail.imc.org Fri Mar 26 09:54:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22585 for ; Fri, 26 Mar 2004 09:54:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEW0mx015896; Fri, 26 Mar 2004 06:32:00 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QEW0GO015895; Fri, 26 Mar 2004 06:32:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QEVxqT015888 for ; Fri, 26 Mar 2004 06:31:59 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 476 invoked by uid 0); 26 Mar 2004 14:22:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.147.58) by woodstock.binhost.com with SMTP; 26 Mar 2004 14:22:35 -0000 Message-Id: <5.2.0.9.2.20040326092932.01fc6420@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 26 Mar 2004 09:31:58 -0500 To: "Blake Ramsdell" From: Russ Housley Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Cc: ietf-smime@imc.org In-Reply-To: References: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake: > > 1. Should Section 1.4 reference RFC 3369? > >This section just describes where "prior practice of S/MIME" is located. >I think that RFC 3369 is "current practice of S/MIME". Okay. > > 2. Delete section 1.6 before the document is sent to the IESG. > >Deleted. Thanks. > > 3. Section 2.4 probably should point out that ContentInfo is > > needed to > > encapsulate each of the protection content types. > >Hmm. I don't agree. This is meant to describe the subset of types that >are supported by S/MIME, independent of their encoding. Okay. I accept that ContentInfo is not a content type. > > 4. What compression algorithm MUST be implemented if > > CompressedData is > > supported? > >Has this train finished wrecking or is it still in progress? I think we know where all the pieces landed. > > 5. Section 2.5.2: s/SMIMECapabilities attribute > > should/SMIMECapabilities > > attribute SHOULD/ > >Fixed. Thanks. > > 6. Section 2.6: the first two paragraphs are not clear. > > S/MIME v3.1 MUST > > support both issuerAndSerialNumber and subjectKeyIdentifier > > for sending and > > receiving. > >S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as >well as subjectKeyIdentifier. Messages that use the >subjectKeyIdentifier choice cannot be read by S/MIME v2 clients. Works for me. > > 7. Section 3.4.3.2: s/not currently supported in S/MIME/not > > currently > > recommended in S/MIME/ > >Fixed. Thanks. Russ From owner-ietf-smime@mail.imc.org Fri Mar 26 10:11:50 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24317 for ; Fri, 26 Mar 2004 10:11:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QElqr8016755; Fri, 26 Mar 2004 06:47:52 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QElqBi016754; Fri, 26 Mar 2004 06:47:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QElpCZ016748 for ; Fri, 26 Mar 2004 06:47:51 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 3339 invoked by uid 0); 26 Mar 2004 14:38:27 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.220.30) by woodstock.binhost.com with SMTP; 26 Mar 2004 14:38:27 -0000 Message-Id: <5.2.0.9.2.20040326093225.03adc888@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 26 Mar 2004 09:47:27 -0500 To: "Blake Ramsdell" From: Russ Housley Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Cc: ietf-smime@imc.org, jimsch@exmsft.com In-Reply-To: References: <20040308102917.989E58ABD7@smtp2.pacifier.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake: > > 1. I just realized there is no abstract for this document. Is one > > required? > >Don't know -- someone comment. There is supposed to be one. RFC 2633 got through without one. Today's IESG would not have let it happen. I suggest: This document defines S/MIME (Secure/Multipurpose Internet Mail Extensions) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity and non-repudiation with proof of origin. Encryption provides data confidentiality. > > 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/ > >Done. > > > 3. Section 1.1, p 4: Should there be a dependency/reference > > to CMSALG here > > as well? > >Dunno. "No" for now. I think it is a good idea to include the reference. >[snip] > > > 18. Section 2.4.1, p1: s/signedData/SignedData/ > > - also envelopedData vs EnvelopedData and compressedData vs > > CompressedData. > > signedData does not actually exist in the CMS > > documents. The type > > is SignedData or the concept is signed data. I think we need > > to clean this > > up. > > Russ: Please note there is one section in CMS that needs to be > > cleaned up in the same way. Thanks. It will be fixed in rfc3369bis-02. > > 21. Section 2.4.2, p1: Should add "This content type does not provide > > privacy." > >And also add "and does not provide compression"? Should we just remove >"does not provide authentication" from the EnvelopedData section? Not >changed. I think we should be talking about "confidentiality" not "privacy." See the definitions of these words in RFC 2828. >[snip] Russ From owner-ietf-smime@mail.imc.org Fri Mar 26 11:27:58 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29969 for ; Fri, 26 Mar 2004 11:27:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QFvpdI021171; Fri, 26 Mar 2004 07:57:51 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QFvp65021170; Fri, 26 Mar 2004 07:57:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QFvplW021164 for ; Fri, 26 Mar 2004 07:57:51 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@67.153.90.34 with plain) by smtp004.bizmail.sc5.yahoo.com with SMTP; 26 Mar 2004 15:57:54 -0000 Message-ID: <40645347.9010501@ieca.com> Date: Fri, 26 Mar 2004 10:59:03 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Blake Ramsdell CC: ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Comments inline ...snip >Para 3.1, 2nd para 1st sentence: Replace "The MIME entity that is >secured and ..." with "The MIME entity that is secured or compressed and >..." > >[bcr] Nope. We're going with "secured" here until someone comes up with >a concise word that means "signed or encrypted or compressed". > > [spt] How about having "signed or encrypted or compressed (s/e/c)" in the 1st instance and then repeating "s/e/c" after that? >Para 3.1, 4th para 1st sentence: Replace "A single procedure is used for >creating MIME entities that are to be signed, enveloped, or both signed >and enveloped" with "A single procedure is used for creating MIME >entities that are to be signed, enveloped, compressed and both signed >and enveloped, signed and compressed, compressed and enveloped, and >compressed, signed, and enveloped, etc." (or whatever # of combinations >you feel like listing) > >[bcr] A single procedure is used for creating MIME entities that are to >have any combination of signing, enveloping and compressing applied. > > [spt] Did you change it to say that? >Para 3.1, 4th para 3rd sentence: Replace "It is recommended that these >additional steps be performed on enveloped messages, or signed and >enveloped messages" with "It is recommended that these additional steps >be performed on enveloped and compressed messages, or signed and >enveloped messages or compressed, signed and enveloped messages." > >[bcr] I'm not even sure what the spirit of this guidance is. No change >-- either suggest less awkward language or help me figure out what the >spirit of this is. > > [spt] I was just trying to be complete and list all the times the steps should be taken. Comment was in line with the above three. >Para 3.1, 1st para after Step 3: Replace "the security services on the >message are processed" with "the security services or compression on the >message are processed" > >[bcr] See previous discussion about "secured" > > > [spt] As long as we do it the same way. Cheer - spt From owner-ietf-smime@mail.imc.org Fri Mar 26 12:46:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04102 for ; Fri, 26 Mar 2004 12:46:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHHJAk026543; Fri, 26 Mar 2004 09:17:19 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QHHJ5G026542; Fri, 26 Mar 2004 09:17:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp006.bizmail.sc5.yahoo.com (smtp006.bizmail.sc5.yahoo.com [66.163.175.83]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QHHJsU026536 for ; Fri, 26 Mar 2004 09:17:19 -0800 (PST) (envelope-from BonattiC@ieca.com) Received: from unknown (HELO Obsidian) (BonattiC@ieca.com@69.140.115.182 with login) by smtp006.bizmail.sc5.yahoo.com with SMTP; 26 Mar 2004 17:17:22 -0000 From: "Bonatti, Chris" To: Cc: Subject: RE: Interop Requirement for Signed Data formats Date: Fri, 26 Mar 2004 12:17:21 -0500 Organization: IECA, Inc. Message-ID: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20040326071052.166306AACC@smtp4.pacifier.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2QHHJsU026537 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Agree. It should read: There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. Sending agents MUST support the multipart/signed form, and SHOULD support the application/pkcs7-mime form. Receiving agents SHOULD be able to handle both. Chris -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad Sent: Friday, March 26, 2004 02:16 To: ietf-smime@imc.org Subject: Interop Requirement for Signed Data formats In my last review of the document I found the following text in section 3.4 There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both. The problem here is that there is no interop in the signed message format as specified by the above statement. I.E. Person one could implement application/pkcs7-mime only and person two could implemement multipart/signed only -- no interop. The best change for interop purposes is to change the SHOULD to a MUST. Comments? Jim From owner-ietf-smime@mail.imc.org Fri Mar 26 14:20:15 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09477 for ; Fri, 26 Mar 2004 14:20:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QIvbGw034673; Fri, 26 Mar 2004 10:57:37 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QIvb96034672; Fri, 26 Mar 2004 10:57:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QIvasv034645 for ; Fri, 26 Mar 2004 10:57:36 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 8DC9D6FE32; Fri, 26 Mar 2004 10:57:39 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Bonatti, Chris'" Cc: Subject: RE: Interop Requirement for Signed Data formats Date: Fri, 26 Mar 2004 11:02:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> thread-index: AcQTVjiLJ13q5kX2Qq6x0T7A6JZNIAADoVIg Message-Id: <20040326185739.8DC9D6FE32@smtp1.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris, That still does not give interop as a receiving agent may only handle application/pkcs7-mime. Making it MUST to receive both handles that problem. jim -----Original Message----- From: Bonatti, Chris [mailto:BonattiC@ieca.com] Sent: Friday, March 26, 2004 9:17 AM To: jimsch@exmsft.com Cc: ietf-smime@imc.org Subject: RE: Interop Requirement for Signed Data formats Agree. It should read: There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. Sending agents MUST support the multipart/signed form, and SHOULD support the application/pkcs7-mime form. Receiving agents SHOULD be able to handle both. Chris -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad Sent: Friday, March 26, 2004 02:16 To: ietf-smime@imc.org Subject: Interop Requirement for Signed Data formats In my last review of the document I found the following text in section 3.4 There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both. The problem here is that there is no interop in the signed message format as specified by the above statement. I.E. Person one could implement application/pkcs7-mime only and person two could implemement multipart/signed only -- no interop. The best change for interop purposes is to change the SHOULD to a MUST. Comments? Jim From owner-ietf-smime@mail.imc.org Fri Mar 26 14:50:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10758 for ; Fri, 26 Mar 2004 14:50:21 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QJXuR8038946; Fri, 26 Mar 2004 11:33:56 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QJXuGU038944; Fri, 26 Mar 2004 11:33:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QJXtVv038935 for ; Fri, 26 Mar 2004 11:33:55 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 14007 invoked by uid 0); 26 Mar 2004 19:24:29 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.245.154) by woodstock.binhost.com with SMTP; 26 Mar 2004 19:24:29 -0000 Message-Id: <5.2.0.9.2.20040326143244.03696e00@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 26 Mar 2004 14:33:54 -0500 To: , "'Bonatti, Chris'" From: Russ Housley Subject: RE: Interop Requirement for Signed Data formats Cc: In-Reply-To: <20040326185739.8DC9D6FE32@smtp1.pacifier.net> References: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think that we have plenty of implementations that already handle both. Please correct me if this is not the case. If my assertion holds, then MUST for both formats seems like the best way forward. Russ At 11:02 AM 3/26/2004 -0800, Jim Schaad wrote: >Chris, > >That still does not give interop as a receiving agent may only handle >application/pkcs7-mime. > >Making it MUST to receive both handles that problem. > >jim > >-----Original Message----- >From: Bonatti, Chris [mailto:BonattiC@ieca.com] >Sent: Friday, March 26, 2004 9:17 AM >To: jimsch@exmsft.com >Cc: ietf-smime@imc.org >Subject: RE: Interop Requirement for Signed Data formats > >Agree. It should read: > >There are two formats for signed messages defined for S/MIME: >application/pkcs7-mime with SignedData, and multipart/signed. >Sending agents MUST support the multipart/signed form, and SHOULD support >the application/pkcs7-mime form. Receiving agents SHOULD be able to handle >both. > >Chris > > >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad >Sent: Friday, March 26, 2004 02:16 >To: ietf-smime@imc.org >Subject: Interop Requirement for Signed Data formats > > > >In my last review of the document I found the following text in section 3.4 > >There are two formats for signed messages defined for S/MIME: >application/pkcs7-mime with SignedData, and multipart/signed. In general, >the multipart/signed form is preferred for sending, and receiving agents >SHOULD be able to handle both. > >The problem here is that there is no interop in the signed message format as >specified by the above statement. I.E. Person one could implement >application/pkcs7-mime only and person two could implemement >multipart/signed only -- no interop. > >The best change for interop purposes is to change the SHOULD to a MUST. > > >Comments? > >Jim From f_cherrydo@0700webhilfe.de Sat Mar 27 07:40:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10445 for ; Sat, 27 Mar 2004 07:40:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7D6u-0003AD-00 for smime-archive@ietf.org; Sat, 27 Mar 2004 07:40:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7D4y-0002m8-00 for smime-archive@ietf.org; Sat, 27 Mar 2004 07:38:25 -0500 Received: from [61.172.18.177] (helo=stanley1948.freeserve.co.uk) by ietf-mx with smtp (Exim 4.12) id 1B7D3u-0002XI-00 for smime-archive@ietf.org; Sat, 27 Mar 2004 07:37:20 -0500 Message-ID: From: "Felix Cherry" To: smime-archive@ietf.org Subject: (3)It works or you don't pay(63) Date: Sat, 27 Mar 2004 13:11:37 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=CLICK_BELOW,FREE_TRIAL, HTML_70_80,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNKNOWN, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_FONT_INVISIBLE,HTML_MESSAGE, HTML_TAG_BALANCE_BODY,MIME_HTML_ONLY,PENIS_ENLARGE2 autolearn=no version=2.60 Content-Transfer-Encoding: 8bit

xeaoklbscz smcldwvwaaj kkfurcdesdgac zvzgmgcoudo tgubvabqyfjo wrxfaphezqmjz
The only solution to Penis Enlargement
mqarypcihctt envqfbbofsnu
LIMITED OFFER: Add at least 3 INCHES or get your money back!
axkkbddrmrkb ivzodbdsxc
We are so sure our product works we are willing to prove it by offering a free trial bottle + a 100% cash back guarantee upon purchase if you are not satisfied with the results.

---> Click Here To Learn More <---

Also check out our *brand new* product: Penis Enlargement Patches
Comes with the 100% cash back warranty as well!
yjwcagbjyfsv nrowacdfplyy

rhescbbdtynha svbusudgvwtpxx


hrthltdjiomjn ldvncbbmwaqlx
No more offers From l_plummer_tt@gks.de Sat Mar 27 11:18:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18920 for ; Sat, 27 Mar 2004 11:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7GWG-0001uz-00 for smime-archive@ietf.org; Sat, 27 Mar 2004 11:18:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7GVJ-0001n6-00 for smime-archive@ietf.org; Sat, 27 Mar 2004 11:17:49 -0500 Received: from pa-westmifflin1a-319.pit.adelphia.net ([24.48.239.63] helo=global-logistic.at) by ietf-mx with smtp (Exim 4.12) id 1B7GUL-0001Y0-00 for smime-archive@ietf.org; Sat, 27 Mar 2004 11:16:50 -0500 Message-ID: From: "Ladonna I. Plummer" To: smime-archive@ietf.org Subject: Internet Pharmacy - Cheap Prices Date: Sat, 27 Mar 2004 11:16:31 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=BIZ_TLD,HTML_70_80, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Onlìne Pharmacy - No doctor visit needed.
I don't like emails. From owner-ietf-smime@mail.imc.org Sat Mar 27 19:25:16 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08499 for ; Sat, 27 Mar 2004 19:25:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2RNxEEG022626; Sat, 27 Mar 2004 15:59:14 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2RNxEE0022625; Sat, 27 Mar 2004 15:59:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (user-38lc0eq.dialup.mindspring.com [209.86.1.218]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2RNx9bM022616; Sat, 27 Mar 2004 15:59:11 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> References: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> Date: Sat, 27 Mar 2004 09:43:41 -0800 To: "Bonatti, Chris" , From: Paul Hoffman / IMC Subject: RE: Interop Requirement for Signed Data formats Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:17 PM -0500 3/26/04, Bonatti, Chris wrote: >Agree. It should read: > >There are two formats for signed messages defined for S/MIME: >application/pkcs7-mime with SignedData, and multipart/signed. >Sending agents MUST support the multipart/signed form, and SHOULD >support the application/pkcs7-mime form. Receiving agents SHOULD >be able to handle both. Disagree with Chris, agree with Jim. The paragraph in the current document should read: There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents MUST be able to handle both. We have been over this a million times, and it is clear we can't come to agreement. It's history vs. correct interaction with the rest of email, and both have strong arguments in their favor. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@mail.imc.org Sat Mar 27 20:08:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10052 for ; Sat, 27 Mar 2004 20:08:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2S0nUXH025257; Sat, 27 Mar 2004 16:49:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2S0nUT0025256; Sat, 27 Mar 2004 16:49:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2S0nTFi025250 for ; Sat, 27 Mar 2004 16:49:30 -0800 (PST) (envelope-from ejnorman@doit.wisc.edu) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 37492500 for ietf-smime@imc.org; Sat, 27 Mar 2004 18:44:28 -0600 Date: Sat, 27 Mar 2004 18:49:35 -0600 (CST) From: Eric Norman To: SMIME list Subject: RE: Interop Requirement for Signed Data formats In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 27 Mar 2004, Paul Hoffman / IMC wrote: > At 12:17 PM -0500 3/26/04, Bonatti, Chris wrote: > >Agree. It should read: > > > >There are two formats for signed messages defined for S/MIME: > >application/pkcs7-mime with SignedData, and multipart/signed. > >Sending agents MUST support the multipart/signed form, and SHOULD > >support the application/pkcs7-mime form. Receiving agents SHOULD > >be able to handle both. > > Disagree with Chris, agree with Jim. The paragraph in the current > document should read: > > There are two formats for signed messages defined for S/MIME: > application/pkcs7-mime with SignedData, and multipart/signed. In > general, the multipart/signed form is preferred for sending, and > receiving agents MUST be able to handle both. Minor nit: multipart/signed also contains a PKCS7 SignedData object. > We have been over this a million times, and it is clear we can't come > to agreement. It's history vs. correct interaction with the rest of > email, and both have strong arguments in their favor. I also agree. Nevertheless, it might be worth a stronger warning that multipart/signed has a greater risk of being mangled by non-compliant mail handling software. Many examples of this have been discovered in mailing list software. At least one I know of mangles the message so badly that the plaintext is rendered unreadable by common agents. Eric Norman "Congress shall make no law restricting the size of integers that may be multiplied together, or the number of times that an integer may be multiplied by itself, or the modulus by which an integer may be reduced". From a.mcLeanwr@emb-safrica.intl.tn Mon Mar 29 21:27:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10080 for ; Mon, 29 Mar 2004 21:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B88yo-0004S3-00 for smime-archive@ietf.org; Mon, 29 Mar 2004 21:27:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B88xt-0004L1-00 for smime-archive@ietf.org; Mon, 29 Mar 2004 21:26:58 -0500 Received: from [210.124.196.244] (helo=modeemi.cs.tut.fi) by ietf-mx with smtp (Exim 4.12) id 1B88xd-0004DX-00 for smime-archive@ietf.org; Mon, 29 Mar 2004 21:26:42 -0500 Message-ID: <528c01c41603$60e4e83c$1740f2a7@modeemi.cs.tut.fi> From: "Alberto McLean" To: smime-archive@ietf.org Subject: (9)It works or you don't pay(21) Date: Tue, 30 Mar 2004 03:03:19 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=CLICK_BELOW,FREE_TRIAL, HTML_70_80,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNKNOWN, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_FONT_INVISIBLE,HTML_MESSAGE, HTML_TAG_BALANCE_BODY,MIME_HTML_ONLY,PENIS_ENLARGE2 autolearn=no version=2.60 Content-Transfer-Encoding: 8bit

nuioaydajmwk djyxvdcrqci zulhfcbgsockho nqjxqadudonsf pnardkdbxsvy rllmqhcccjocm
The only solution to Penis Enlargement
uqhoyocvtgdmoq ukhxdkdbpqfd
LIMITED OFFER: Add at least 3 INCHES or get your money back!
xmgelbdofmhxmc cpueberncfcwb
We are so sure our product works we are willing to prove it by offering a free trial bottle + a 100% cash back guarantee upon purchase if you are not satisfied with the results.

---> Click Here To Learn More <---

Also check out our *brand new* product: Penis Enlargement Patches
Comes with the 100% cash back warranty as well!
lbhkohbpvyki agnxzxdmppdn

smxddhderkzz gesqoydoraei


nvzflfdxsj xiqdaidiaemdf
No more offers From anynnktcreotik@168.com Tue Mar 30 06:37:07 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13843 for ; Tue, 30 Mar 2004 06:37:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8HYK-0006Lq-00 for smime-archive@ietf.org; Tue, 30 Mar 2004 06:37:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8HXQ-0006E9-00 for smime-archive@ietf.org; Tue, 30 Mar 2004 06:36:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8HWb-00066e-00 for smime-archive@ietf.org; Tue, 30 Mar 2004 06:35:21 -0500 Received: from [68.186.193.23] (helo=rajesh.cpe.dectr.al.charter.com) by mx2.foretec.com with smtp (Exim 4.24) id 1B8HWb-0004EY-GD for smime-archive@ietf.org; Tue, 30 Mar 2004 06:35:23 -0500 Received: from [68.186.193.23] by 255.170.198.32 with HTTP; Tue, 30 Mar 2004 06:39:35 -0500 From: "Mcnamara" To: smime-archive@ietf.org Subject: incommensurable Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [255.170.198.32] Date: Tue, 30 Mar 2004 06:39:35 -0500 Reply-To: "Mcnamara" Content-Type: multipart/alternative; boundary="652374351893688978" Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --652374351893688978 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit character montenegrin define bedim hereby fallacy pour elastomer bribe kingston parrot congressional dorothea straighten cologne mccall drudge authoritarian cruickshank dazzle dis obsolete waterhouse stateroom --652374351893688978 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit Giles Govenment don't want me to sell

Bannedcd

Check Your spouse and staff

http://www.8004hosting.com/cd/

tollgate,staggering and looking. --652374351893688978-- From itbrzzguy@victorycapital.net Wed Mar 31 19:21:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22209 for ; Wed, 31 Mar 2004 19:21:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8pxh-0004r8-00 for smime-archive@ietf.org; Wed, 31 Mar 2004 19:21:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8pwi-0004oW-00 for smime-archive@ietf.org; Wed, 31 Mar 2004 19:20:37 -0500 Received: from 209-102-132-89.dialup.gulftelephone.net ([209.102.132.89]) by ietf-mx with smtp (Exim 4.12) id 1B8pvh-0004lL-00 for smime-archive@ietf.org; Wed, 31 Mar 2004 19:19:36 -0500 Received: from 191.13.44.28 by 209.102.132.89; Wed, 31 Mar 2004 18:22:04 -0600 Message-ID: From: "Reuben Hubbard" Reply-To: "Reuben Hubbard" To: smime-archive@ietf.org Subject: Get All Meds. Any Meds You Want Prescriptions Written and Filled Online. Date: Thu, 01 Apr 2004 03:15:04 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--94987364368383603167" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----94987364368383603167 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Hello,

we make it easier and faster than ever to get the medications you need!

Cialis, Phentermine, Viagra, Soma, Ambien, Levitra, Floricet, Imitrex, Paxil, Prozac, Zoloft, and many many more prescription drugs!

Order by 2 pm EST and you get your meds tomorrow.

Start Ordering your Medications Here

Bdiversion citroen rotenone slog progress wharves island ccny chlordane dreyfuss ; Qderbyshire hollowware alexander leaflet inflationary cool carmichael hank tanaka carney beck coccidiosis assignation florin !!! Dbelgrade inheritance bandwagon bestubble chattanooga counterargument auschwitz logarithmic sheik cookbook avocation ms swivel colloq pont cleanup assuage decompile amatory ann boca collage mac anus chronic anorthosite agrimony diorite catbird edelweiss omniscient spilt entranceway shaft Matlantes assailant eggshell ambiguity bolshevism !!! Oglaucous chi hettie southernmost squid countrymen jacobite expedite loge assuage counterargument positron kerchief cavalier architectonic dried andrew . Ceffluvia hyades piecewise regulate unesco meier sinister general commotion bullish rackety mack octagonal calcify cuddle anaerobic lateral foss abundant handyman binge sentential imperturbable cold decompress anyhow gather desolater beatrice sleigh stairway tuesday valkyrie restroom arequipa botulism antic yuh hyperboloidal spouse annoyance notify pectoral idiot merchant pretense stopband zap

If this notice has reached you in error, please notify us by clicking here ----94987364368383603167-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2S0nUXH025257; Sat, 27 Mar 2004 16:49:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2S0nUT0025256; Sat, 27 Mar 2004 16:49:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2S0nTFi025250 for ; Sat, 27 Mar 2004 16:49:30 -0800 (PST) (envelope-from ejnorman@doit.wisc.edu) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 37492500 for ietf-smime@imc.org; Sat, 27 Mar 2004 18:44:28 -0600 Date: Sat, 27 Mar 2004 18:49:35 -0600 (CST) From: Eric Norman To: SMIME list Subject: RE: Interop Requirement for Signed Data formats In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Sat, 27 Mar 2004, Paul Hoffman / IMC wrote: > At 12:17 PM -0500 3/26/04, Bonatti, Chris wrote: > >Agree. It should read: > > > >There are two formats for signed messages defined for S/MIME: > >application/pkcs7-mime with SignedData, and multipart/signed. > >Sending agents MUST support the multipart/signed form, and SHOULD > >support the application/pkcs7-mime form. Receiving agents SHOULD > >be able to handle both. > > Disagree with Chris, agree with Jim. The paragraph in the current > document should read: > > There are two formats for signed messages defined for S/MIME: > application/pkcs7-mime with SignedData, and multipart/signed. In > general, the multipart/signed form is preferred for sending, and > receiving agents MUST be able to handle both. Minor nit: multipart/signed also contains a PKCS7 SignedData object. > We have been over this a million times, and it is clear we can't come > to agreement. It's history vs. correct interaction with the rest of > email, and both have strong arguments in their favor. I also agree. Nevertheless, it might be worth a stronger warning that multipart/signed has a greater risk of being mangled by non-compliant mail handling software. Many examples of this have been discovered in mailing list software. At least one I know of mangles the message so badly that the plaintext is rendered unreadable by common agents. Eric Norman "Congress shall make no law restricting the size of integers that may be multiplied together, or the number of times that an integer may be multiplied by itself, or the modulus by which an integer may be reduced". Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2RNxEEG022626; Sat, 27 Mar 2004 15:59:14 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2RNxEE0022625; Sat, 27 Mar 2004 15:59:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (user-38lc0eq.dialup.mindspring.com [209.86.1.218]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2RNx9bM022616; Sat, 27 Mar 2004 15:59:11 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> References: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> Date: Sat, 27 Mar 2004 09:43:41 -0800 To: "Bonatti, Chris" , From: Paul Hoffman / IMC Subject: RE: Interop Requirement for Signed Data formats Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:17 PM -0500 3/26/04, Bonatti, Chris wrote: >Agree. It should read: > >There are two formats for signed messages defined for S/MIME: >application/pkcs7-mime with SignedData, and multipart/signed. >Sending agents MUST support the multipart/signed form, and SHOULD >support the application/pkcs7-mime form. Receiving agents SHOULD >be able to handle both. Disagree with Chris, agree with Jim. The paragraph in the current document should read: There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents MUST be able to handle both. We have been over this a million times, and it is clear we can't come to agreement. It's history vs. correct interaction with the rest of email, and both have strong arguments in their favor. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QJXuR8038946; Fri, 26 Mar 2004 11:33:56 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QJXuGU038944; Fri, 26 Mar 2004 11:33:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QJXtVv038935 for ; Fri, 26 Mar 2004 11:33:55 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 14007 invoked by uid 0); 26 Mar 2004 19:24:29 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.245.154) by woodstock.binhost.com with SMTP; 26 Mar 2004 19:24:29 -0000 Message-Id: <5.2.0.9.2.20040326143244.03696e00@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 26 Mar 2004 14:33:54 -0500 To: , "'Bonatti, Chris'" From: Russ Housley Subject: RE: Interop Requirement for Signed Data formats Cc: In-Reply-To: <20040326185739.8DC9D6FE32@smtp1.pacifier.net> References: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I think that we have plenty of implementations that already handle both. Please correct me if this is not the case. If my assertion holds, then MUST for both formats seems like the best way forward. Russ At 11:02 AM 3/26/2004 -0800, Jim Schaad wrote: >Chris, > >That still does not give interop as a receiving agent may only handle >application/pkcs7-mime. > >Making it MUST to receive both handles that problem. > >jim > >-----Original Message----- >From: Bonatti, Chris [mailto:BonattiC@ieca.com] >Sent: Friday, March 26, 2004 9:17 AM >To: jimsch@exmsft.com >Cc: ietf-smime@imc.org >Subject: RE: Interop Requirement for Signed Data formats > >Agree. It should read: > >There are two formats for signed messages defined for S/MIME: >application/pkcs7-mime with SignedData, and multipart/signed. >Sending agents MUST support the multipart/signed form, and SHOULD support >the application/pkcs7-mime form. Receiving agents SHOULD be able to handle >both. > >Chris > > >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad >Sent: Friday, March 26, 2004 02:16 >To: ietf-smime@imc.org >Subject: Interop Requirement for Signed Data formats > > > >In my last review of the document I found the following text in section 3.4 > >There are two formats for signed messages defined for S/MIME: >application/pkcs7-mime with SignedData, and multipart/signed. In general, >the multipart/signed form is preferred for sending, and receiving agents >SHOULD be able to handle both. > >The problem here is that there is no interop in the signed message format as >specified by the above statement. I.E. Person one could implement >application/pkcs7-mime only and person two could implemement >multipart/signed only -- no interop. > >The best change for interop purposes is to change the SHOULD to a MUST. > > >Comments? > >Jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QIvbGw034673; Fri, 26 Mar 2004 10:57:37 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QIvb96034672; Fri, 26 Mar 2004 10:57:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QIvasv034645 for ; Fri, 26 Mar 2004 10:57:36 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 8DC9D6FE32; Fri, 26 Mar 2004 10:57:39 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Bonatti, Chris'" Cc: Subject: RE: Interop Requirement for Signed Data formats Date: Fri, 26 Mar 2004 11:02:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> thread-index: AcQTVjiLJ13q5kX2Qq6x0T7A6JZNIAADoVIg Message-Id: <20040326185739.8DC9D6FE32@smtp1.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, That still does not give interop as a receiving agent may only handle application/pkcs7-mime. Making it MUST to receive both handles that problem. jim -----Original Message----- From: Bonatti, Chris [mailto:BonattiC@ieca.com] Sent: Friday, March 26, 2004 9:17 AM To: jimsch@exmsft.com Cc: ietf-smime@imc.org Subject: RE: Interop Requirement for Signed Data formats Agree. It should read: There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. Sending agents MUST support the multipart/signed form, and SHOULD support the application/pkcs7-mime form. Receiving agents SHOULD be able to handle both. Chris -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad Sent: Friday, March 26, 2004 02:16 To: ietf-smime@imc.org Subject: Interop Requirement for Signed Data formats In my last review of the document I found the following text in section 3.4 There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both. The problem here is that there is no interop in the signed message format as specified by the above statement. I.E. Person one could implement application/pkcs7-mime only and person two could implemement multipart/signed only -- no interop. The best change for interop purposes is to change the SHOULD to a MUST. Comments? Jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QHHJAk026543; Fri, 26 Mar 2004 09:17:19 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QHHJ5G026542; Fri, 26 Mar 2004 09:17:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp006.bizmail.sc5.yahoo.com (smtp006.bizmail.sc5.yahoo.com [66.163.175.83]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QHHJsU026536 for ; Fri, 26 Mar 2004 09:17:19 -0800 (PST) (envelope-from BonattiC@ieca.com) Received: from unknown (HELO Obsidian) (BonattiC@ieca.com@69.140.115.182 with login) by smtp006.bizmail.sc5.yahoo.com with SMTP; 26 Mar 2004 17:17:22 -0000 From: "Bonatti, Chris" To: Cc: Subject: RE: Interop Requirement for Signed Data formats Date: Fri, 26 Mar 2004 12:17:21 -0500 Organization: IECA, Inc. Message-ID: <000b01c41356$33ae1b60$0300a8c0@darn.ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20040326071052.166306AACC@smtp4.pacifier.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2QHHJsU026537 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Agree. It should read: There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. Sending agents MUST support the multipart/signed form, and SHOULD support the application/pkcs7-mime form. Receiving agents SHOULD be able to handle both. Chris -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad Sent: Friday, March 26, 2004 02:16 To: ietf-smime@imc.org Subject: Interop Requirement for Signed Data formats In my last review of the document I found the following text in section 3.4 There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both. The problem here is that there is no interop in the signed message format as specified by the above statement. I.E. Person one could implement application/pkcs7-mime only and person two could implemement multipart/signed only -- no interop. The best change for interop purposes is to change the SHOULD to a MUST. Comments? Jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QFvpdI021171; Fri, 26 Mar 2004 07:57:51 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QFvp65021170; Fri, 26 Mar 2004 07:57:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QFvplW021164 for ; Fri, 26 Mar 2004 07:57:51 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@67.153.90.34 with plain) by smtp004.bizmail.sc5.yahoo.com with SMTP; 26 Mar 2004 15:57:54 -0000 Message-ID: <40645347.9010501@ieca.com> Date: Fri, 26 Mar 2004 10:59:03 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Blake Ramsdell CC: ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments inline ...snip >Para 3.1, 2nd para 1st sentence: Replace "The MIME entity that is >secured and ..." with "The MIME entity that is secured or compressed and >..." > >[bcr] Nope. We're going with "secured" here until someone comes up with >a concise word that means "signed or encrypted or compressed". > > [spt] How about having "signed or encrypted or compressed (s/e/c)" in the 1st instance and then repeating "s/e/c" after that? >Para 3.1, 4th para 1st sentence: Replace "A single procedure is used for >creating MIME entities that are to be signed, enveloped, or both signed >and enveloped" with "A single procedure is used for creating MIME >entities that are to be signed, enveloped, compressed and both signed >and enveloped, signed and compressed, compressed and enveloped, and >compressed, signed, and enveloped, etc." (or whatever # of combinations >you feel like listing) > >[bcr] A single procedure is used for creating MIME entities that are to >have any combination of signing, enveloping and compressing applied. > > [spt] Did you change it to say that? >Para 3.1, 4th para 3rd sentence: Replace "It is recommended that these >additional steps be performed on enveloped messages, or signed and >enveloped messages" with "It is recommended that these additional steps >be performed on enveloped and compressed messages, or signed and >enveloped messages or compressed, signed and enveloped messages." > >[bcr] I'm not even sure what the spirit of this guidance is. No change >-- either suggest less awkward language or help me figure out what the >spirit of this is. > > [spt] I was just trying to be complete and list all the times the steps should be taken. Comment was in line with the above three. >Para 3.1, 1st para after Step 3: Replace "the security services on the >message are processed" with "the security services or compression on the >message are processed" > >[bcr] See previous discussion about "secured" > > > [spt] As long as we do it the same way. Cheer - spt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QElqr8016755; Fri, 26 Mar 2004 06:47:52 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QElqBi016754; Fri, 26 Mar 2004 06:47:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QElpCZ016748 for ; Fri, 26 Mar 2004 06:47:51 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 3339 invoked by uid 0); 26 Mar 2004 14:38:27 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.220.30) by woodstock.binhost.com with SMTP; 26 Mar 2004 14:38:27 -0000 Message-Id: <5.2.0.9.2.20040326093225.03adc888@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 26 Mar 2004 09:47:27 -0500 To: "Blake Ramsdell" From: Russ Housley Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Cc: ietf-smime@imc.org, jimsch@exmsft.com In-Reply-To: References: <20040308102917.989E58ABD7@smtp2.pacifier.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake: > > 1. I just realized there is no abstract for this document. Is one > > required? > >Don't know -- someone comment. There is supposed to be one. RFC 2633 got through without one. Today's IESG would not have let it happen. I suggest: This document defines S/MIME (Secure/Multipurpose Internet Mail Extensions) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity and non-repudiation with proof of origin. Encryption provides data confidentiality. > > 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/ > >Done. > > > 3. Section 1.1, p 4: Should there be a dependency/reference > > to CMSALG here > > as well? > >Dunno. "No" for now. I think it is a good idea to include the reference. >[snip] > > > 18. Section 2.4.1, p1: s/signedData/SignedData/ > > - also envelopedData vs EnvelopedData and compressedData vs > > CompressedData. > > signedData does not actually exist in the CMS > > documents. The type > > is SignedData or the concept is signed data. I think we need > > to clean this > > up. > > Russ: Please note there is one section in CMS that needs to be > > cleaned up in the same way. Thanks. It will be fixed in rfc3369bis-02. > > 21. Section 2.4.2, p1: Should add "This content type does not provide > > privacy." > >And also add "and does not provide compression"? Should we just remove >"does not provide authentication" from the EnvelopedData section? Not >changed. I think we should be talking about "confidentiality" not "privacy." See the definitions of these words in RFC 2828. >[snip] Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEW0mx015896; Fri, 26 Mar 2004 06:32:00 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QEW0GO015895; Fri, 26 Mar 2004 06:32:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2QEVxqT015888 for ; Fri, 26 Mar 2004 06:31:59 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 476 invoked by uid 0); 26 Mar 2004 14:22:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.147.58) by woodstock.binhost.com with SMTP; 26 Mar 2004 14:22:35 -0000 Message-Id: <5.2.0.9.2.20040326092932.01fc6420@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 26 Mar 2004 09:31:58 -0500 To: "Blake Ramsdell" From: Russ Housley Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Cc: ietf-smime@imc.org In-Reply-To: References: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake: > > 1. Should Section 1.4 reference RFC 3369? > >This section just describes where "prior practice of S/MIME" is located. >I think that RFC 3369 is "current practice of S/MIME". Okay. > > 2. Delete section 1.6 before the document is sent to the IESG. > >Deleted. Thanks. > > 3. Section 2.4 probably should point out that ContentInfo is > > needed to > > encapsulate each of the protection content types. > >Hmm. I don't agree. This is meant to describe the subset of types that >are supported by S/MIME, independent of their encoding. Okay. I accept that ContentInfo is not a content type. > > 4. What compression algorithm MUST be implemented if > > CompressedData is > > supported? > >Has this train finished wrecking or is it still in progress? I think we know where all the pieces landed. > > 5. Section 2.5.2: s/SMIMECapabilities attribute > > should/SMIMECapabilities > > attribute SHOULD/ > >Fixed. Thanks. > > 6. Section 2.6: the first two paragraphs are not clear. > > S/MIME v3.1 MUST > > support both issuerAndSerialNumber and subjectKeyIdentifier > > for sending and > > receiving. > >S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as >well as subjectKeyIdentifier. Messages that use the >subjectKeyIdentifier choice cannot be read by S/MIME v2 clients. Works for me. > > 7. Section 3.4.3.2: s/not currently supported in S/MIME/not > > currently > > recommended in S/MIME/ > >Fixed. Thanks. Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q8dkSA067355; Fri, 26 Mar 2004 00:39:46 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q8dk3v067354; Fri, 26 Mar 2004 00:39:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q8dj8w067322 for ; Fri, 26 Mar 2004 00:39:45 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Fri, 26 Mar 2004 00:39:40 -0800 From: "Blake Ramsdell" To: Cc: "'Ietf-Smime'" Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Date: Fri, 26 Mar 2004 00:39:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040326072118.A086A6DC85@smtp3.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Thursday, March 25, 2004 11:26 PM > To: 'Blake Ramsdell' > Cc: 'Ietf-Smime' > Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt > > -----Original Message----- > From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] > Sent: Thursday, March 25, 2004 8:44 PM > To: jimsch@exmsft.com > Cc: 'Ietf-Smime' > Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt > > > -----Original Message----- > > From: Jim Schaad [mailto:jimsch@nwlink.com] > > Sent: Monday, March 08, 2004 2:34 AM > > To: 'Blake Ramsdell' > > Cc: Ietf-Smime > > Subject: Comments draft-ietf-smime-rfc2633bis-07.txt > > > > > 3. Section 1.1, p 4: Should there be a > dependency/reference to CMSALG > > here as well? > > Dunno. "No" for now. > > [JLS] - OK -- I think there needs to be an equivalent > statement for [CMSALG] > for algorithm parameter encoding. I may not understand this. Are you saying that I need to recursively include all of the PKIX and CMS references? CMSALG is implicitly required by CMS in this case, I think. Maybe this paragraph just needs to go away, or I need to understand better why CMSALG (which is required by CMS) needs to be called out explicitly. > > 9. Section 3.2.2, p last: Suggest adding the text: "An > smime-type > > parameters is not intended to give indications of security layers > > applied in the event of multiple levels of wrapping." > > What do you see as the confusion here? Not done. > > [JLS] If you do a E(S(Receipt)) - The correct smime-type > under the current > rules is "enveloped-data" not "signed-receipt". I think this > makes it more > explicit what is done for multiple layered messages. There is existing guidance: It is explicitly intended that this field be a suitable hint for mail client applications to indicate whether a message is "signed" or "encrypted" without having to tunnel into the CMS payload. I think that this paragraph is sufficient as-is -- what would you modify? Should it be something like: It is explicitly intended that this field be a suitable hint for mail client applications to indicate the "essence" of the message without having to tunnel into the CMS payload. Or something like that? I need more help. > > 11: Section 3.4.3.2: The text > > "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not > > currently supported in S/MIME, and are included here for > > completeness." > > Is only partially correct. They are supported, just not > required by > > this document. I would like to clean this up by saying this in a > > tighter fashion. > > Could use some language, but this may have been handled when > I fixed it for > someone else. > > [JLS] The SHA-256, SHA-384, and SHA-512 algorithms are defined in > [FIBS180-2][PKIX-RSA-PKALGS]. Support is not currently > required in S/MIME > and the micalg values are included here for completeness. "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not currently recommended in S/MIME, and are included here for completeness." Is the language change I made for someone else. > > 16. Is a specification MUST/SHOULD (section 1.1, p4) or > the document > > (section 1.1, p3) (The same word is used, but in completely > different > > meanings. Would not be a problem but for the MUST in p4 > potentially > > wanting to force meaning into p3). > > No idea -- reword and I'll try and parse it again. > > [JLS] Change specification to document in p3 and I'll be happy. > > 'This specification also discusses' > 'MUST follow the specifications in this document' OK, next round. > > 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/ > > 18. > > [JLS] - NAK "Same as your #18 and fixed". > > 21. Section 2.4.2, p1: Should add "This content type does > not provide > > privacy." > > And also add "and does not provide compression"? Should we > just remove "does > not provide authentication" from the EnvelopedData section? > Not changed. > > [JLS] Works for me. Next round. > > 24. I heard this comment at the last IETF meeting from > somebody. As > > I have had the same problem in a number of cases (esp with doing > > interop matrixes) I am throwing it out for your consideration: > > > > The use of the words must, should and may in lower case causes some > > confusion dealing with the question of - did the author > just forget to > > uppercase this or is it really not a protocol statement. > > SHOULD examine all > > instances of these words to see if a different word works just as > > well. > > Ugh. MAY. > > [JLS] - Yes Ugh - SHOULD. MIGHT next round? Blake Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7LK6j034973; Thu, 25 Mar 2004 23:21:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q7LKGr034972; Thu, 25 Mar 2004 23:21:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7LJYF034963 for ; Thu, 25 Mar 2004 23:21:19 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id A086A6DC85; Thu, 25 Mar 2004 23:21:18 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: "'Ietf-Smime'" Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Date: Thu, 25 Mar 2004 23:25:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQS7QVggYqlfjUySm+aWuy4Pbny5QAE+WNw In-Reply-To: Message-Id: <20040326072118.A086A6DC85@smtp3.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake, See in line comments. Jim -----Original Message----- From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] Sent: Thursday, March 25, 2004 8:44 PM To: jimsch@exmsft.com Cc: 'Ietf-Smime' Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Monday, March 08, 2004 2:34 AM > To: 'Blake Ramsdell' > Cc: Ietf-Smime > Subject: Comments draft-ietf-smime-rfc2633bis-07.txt > > 3. Section 1.1, p 4: Should there be a dependency/reference to CMSALG > here as well? Dunno. "No" for now. [JLS] - OK -- I think there needs to be an equivalent statement for [CMSALG] for algorithm parameter encoding. > 4. Section 2.5.2, p1: Need to add text for Compression Algorithms. Suggest language. [JLS] Never mind -- I missed it on the first read for some reason. > 9. Section 3.2.2, p last: Suggest adding the text: "An smime-type > parameters is not intended to give indications of security layers > applied in the event of multiple levels of wrapping." What do you see as the confusion here? Not done. [JLS] If you do a E(S(Receipt)) - The correct smime-type under the current rules is "enveloped-data" not "signed-receipt". I think this makes it more explicit what is done for multiple layered messages. > 10. Section 3.4: In general, the multipart/signed form is preferred > for sending, and receiving agents SHOULD be able to handle both. --- > what is the MUST handle? > Otherwise there is no interop. Don't know -- bees nest. Start a discussion... If you say MUST send SignedData, I imagine that's going to be an issue. Maybe MUST multipart/signed? [JLS] Is now started. > 11: Section 3.4.3.2: The text > "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not > currently supported in S/MIME, and are included here for > completeness." > Is only partially correct. They are supported, just not required by > this document. I would like to clean this up by saying this in a > tighter fashion. Could use some language, but this may have been handled when I fixed it for someone else. [JLS] The SHA-256, SHA-384, and SHA-512 algorithms are defined in [FIBS180-2][PKIX-RSA-PKALGS]. Support is not currently required in S/MIME and the micalg values are included here for completeness. > 16. Is a specification MUST/SHOULD (section 1.1, p4) or the document > (section 1.1, p3) (The same word is used, but in completely different > meanings. Would not be a problem but for the MUST in p4 potentially > wanting to force meaning into p3). No idea -- reword and I'll try and parse it again. [JLS] Change specification to document in p3 and I'll be happy. 'This specification also discusses' 'MUST follow the specifications in this document' > 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/ 18. [JLS] - NAK > 21. Section 2.4.2, p1: Should add "This content type does not provide > privacy." And also add "and does not provide compression"? Should we just remove "does not provide authentication" from the EnvelopedData section? Not changed. [JLS] Works for me. > > 24. I heard this comment at the last IETF meeting from somebody. As > I have had the same problem in a number of cases (esp with doing > interop matrixes) I am throwing it out for your consideration: > > The use of the words must, should and may in lower case causes some > confusion dealing with the question of - did the author just forget to > uppercase this or is it really not a protocol statement. > SHOULD examine all > instances of these words to see if a different word works just as > well. Ugh. MAY. [JLS] - Yes Ugh - SHOULD. Blake Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7AiBC031465; Thu, 25 Mar 2004 23:10:44 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q7AiDK031464; Thu, 25 Mar 2004 23:10:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q7AiR1031455 for ; Thu, 25 Mar 2004 23:10:44 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 166306AACC for ; Thu, 25 Mar 2004 23:10:52 -0800 (PST) Reply-To: From: "Jim Schaad" To: Subject: Interop Requirement for Signed Data formats Date: Thu, 25 Mar 2004 23:15:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQTAh9qhsbAimd1RLqKFQS7JKZZxg== Message-Id: <20040326071052.166306AACC@smtp4.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In my last review of the document I found the following text in section 3.4 There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both. The problem here is that there is no interop in the signed message format as specified by the above statement. I.E. Person one could implement application/pkcs7-mime only and person two could implemement multipart/signed only -- no interop. The best change for interop purposes is to change the SHOULD to a MUST. Comments? Jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q5PhnY005428; Thu, 25 Mar 2004 21:25:43 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q5Phbu005427; Thu, 25 Mar 2004 21:25:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q5PeDH005419; Thu, 25 Mar 2004 21:25:41 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Thu, 25 Mar 2004 21:25:46 -0800 To: "Blake Ramsdell" , From: Paul Hoffman / IMC Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Cc: "'Ietf-Smime'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:44 PM -0800 3/25/04, Blake Ramsdell wrote: > > 1. I just realized there is no abstract for this document. Is one >> required? > >Don't know -- someone comment. Yes, an abstract is required. The wimpy way out is to move the first paragraph of the Intro into the Abstract. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4iU9R003396; Thu, 25 Mar 2004 20:44:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4iUAA003395; Thu, 25 Mar 2004 20:44:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0ru003338 for ; Thu, 25 Mar 2004 20:44:30 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Thu, 25 Mar 2004 20:44:37 -0800 From: "Blake Ramsdell" To: "'Sean P. Turner'" Cc: Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Date: Thu, 25 Mar 2004 20:44:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4044BA02.3070207@ieca.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments inline. Good luck finding them. -----Original Message----- From: Sean P. Turner [mailto:turners@ieca.com] Sent: Tuesday, March 02, 2004 8:45 AM To: Blake Ramsdell Cc: ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Para 1.3, Certificate definition: Replace "distinguished name" with "name" the names are not always "distinguished." [bcr] Neat. That's not even correct either. It binds a bunch of arbitrary things (including a picture of your cat) to a public key. Switched to "name". Para 1.3, Receiving agent, Sending agent, and S/MIME agent definitions: Capitalize 1st word "software" and "user." [bcr] Done. Para 2.2, Last paragraph last sentence: replace "and may not implement id-dsa-with-sha1 at all" with "and may not implement id-dsa-with-sha1 or id-sha at all." [bcr] I presume you meant "id-dsa" not "id-sha" here. Done. Para 2.4.2, SignedData Content Type: Can we add a sentence that says "Applying a signature to message provides authentication, message integrity, and non-repudiation of origin." The other content types indicate what "services" they support or don't support. [bcr] Done. Para 2.4.4, 2nd sentence: Replace "This content type does not provide authentication or privacy" with "This content type does not provide authentication, message integrity, non-repudiation, or data confidentiality". Just making it match the "services" listed in the introduction. [bcr] Done. Para 3.1, Steps 1-4: Add periods to end of sentences. [bcr] Done. Para 3.1.3, 3rd Para 2nd sentence: Replace "8-bit clear" with "8-bit clean" to match terminology in 3.1.2 2nd paragraph 4 sentence. [bcr] Done. Para 3.3, Step 2, last sentence: Replace "(see CMS Section 6)" with (see [CMS] Section 6). [bcr] Done. Para 3.4.2, Steps 1&2: Add periods to end of sentences. [bcr] Done. Compressed data text in 3.5 points to 3.1 but there's no mention in 3.1 of compression. You should either add a sentence to say that in 3.1 enveloped = compression in this section or make the following changes (or others to clarify that you also mean to refer to compression data): Para 3.1, Title: Replace "Signing or Enveloping" with "Signing, Enveloping, or Compressing" because para 3.5 says perform message as in 3.1 but there's not mention of compressing in 3.1. [bcr] Done. Para 3.1, 1st para 1st sentence: Replace "S/MIME is used to secure MIME entities" with "S/MIME is used to secure and optionally compress MIME entities." [bcr] Done. Para 3.1, 2nd para 1st sentence: Replace "The MIME entity that is secured and ..." with "The MIME entity that is secured or compressed and ..." [bcr] Nope. We're going with "secured" here until someone comes up with a concise word that means "signed or encrypted or compressed". Para 3.1, 4th para 1st sentence: Replace "A single procedure is used for creating MIME entities that are to be signed, enveloped, or both signed and enveloped" with "A single procedure is used for creating MIME entities that are to be signed, enveloped, compressed and both signed and enveloped, signed and compressed, compressed and enveloped, and compressed, signed, and enveloped, etc." (or whatever # of combinations you feel like listing) [bcr] A single procedure is used for creating MIME entities that are to have any combination of signing, enveloping and compressing applied. Para 3.1, 4th para 3rd sentence: Replace "It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages" with "It is recommended that these additional steps be performed on enveloped and compressed messages, or signed and enveloped messages or compressed, signed and enveloped messages." [bcr] I'm not even sure what the spirit of this guidance is. No change -- either suggest less awkward language or help me figure out what the spirit of this is. Para 3.1, 1st para after Step 3: Replace "the security services on the message are processed" with "the security services or compression on the message are processed" [bcr] See previous discussion about "secured" Para 3.5, Step 1: Replace "to be enveloped" with "to be compressed". [bcr] Done. Para 3.7, Step 3: Add period to end of sentence. [bcr] Done. Annex F, Remove prior to submission to IESG (?) [bcr] No more changes from last draft. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4iHdK003366; Thu, 25 Mar 2004 20:44:17 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4iHmx003365; Thu, 25 Mar 2004 20:44:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0rt003338 for ; Thu, 25 Mar 2004 20:44:16 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Thu, 25 Mar 2004 20:44:23 -0800 From: "Blake Ramsdell" To: Cc: "'Ietf-Smime'" Subject: RE: Comments draft-ietf-smime-rfc2633bis-07.txt Date: Thu, 25 Mar 2004 20:44:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20040308102917.989E58ABD7@smtp2.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Monday, March 08, 2004 2:34 AM > To: 'Blake Ramsdell' > Cc: Ietf-Smime > Subject: Comments draft-ietf-smime-rfc2633bis-07.txt > > 1. I just realized there is no abstract for this document. Is one > required? Don't know -- someone comment. > 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/ Done. > 3. Section 1.1, p 4: Should there be a dependency/reference > to CMSALG here > as well? Dunno. "No" for now. > 4. Section 2.5.2, p1: Need to add text for Compression Algorithms. Suggest language. > 5. Section 2.5.2: The following statement is no longer true (please > delete): > Note that all OIDs associated with the MUST and SHOULD > implement algorithms > are included in section A of this document. Entire paragraph removed. > 6. section 3, p 1: s/[ESS] document provides examples/[ESS] document > provides descriptions/ > s/ESS provides an example of/ESS provides a > description of/ Done. > 7. Section 3.1, p 5, s/implementor/implementer/ > Section 3.6, p 3: ditto > Section 4.1, p 2: ditto > - I don't know if that is really an incorrect spelling, > but MS Word > does not know it. This is like "advisor" vs. "adviser" I think. In any case, can't have Word upset, so modified. > 8. Section 3.2.1, > s/Application/pkcs7-signature/Application/pkcs7-signature > (SignedData)/ Done. > 9. Section 3.2.2, p last: Suggest adding the text: "An smime-type > parameters is not intended to give indications of security > layers applied in > the event of multiple levels of wrapping." What do you see as the confusion here? Not done. > 10. Section 3.4: In general, the multipart/signed form is > preferred for > sending, and > receiving agents SHOULD be able to handle both. --- what is > the MUST handle? > Otherwise there is no interop. Don't know -- bees nest. Start a discussion... If you say MUST send SignedData, I imagine that's going to be an issue. Maybe MUST multipart/signed? > 11: Section 3.4.3.2: The text > "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not > currently supported in S/MIME, and are included here for > completeness." > Is only partially correct. They are supported, just not > required by this > document. I would like to clean this up by saying this in a tighter > fashion. Could use some language, but this may have been handled when I fixed it for someone else. > 12. Section 4, p 1: s/certification/certificate/ Done. > 13. Section A: s/prefered/preferred/ Done. > 14. References: CMSAES = RFC 3565 Done. > 15. Section 1.1, p 4: s/the Cryptographic Message Syntax/the > Cryptographic > Message Syntax document/ Done. > 16. Is a specification MUST/SHOULD (section 1.1, p4) or the document > (section 1.1, p3) (The same word is used, but in completely different > meanings. Would not be a problem but for the MUST in p4 > potentially wanting > to force meaning into p3). No idea -- reword and I'll try and parse it again. > 17. Section 2.2, p 3: s/the algorithms/the hash algorithms/ Done. "the digest algorithms" I believe is more correct. > 18. Section 2.4.1, p1: s/signedData/SignedData/ > - also envelopedData vs EnvelopedData and compressedData vs > CompressedData. > signedData does not actually exist in the CMS > documents. The type > is SignedData or the concept is signed data. I think we need > to clean this > up. > Russ: Please note there is one section in CMS that needs to be > cleaned up in the same way. Done. > 19. Section 2.4.1, p1: s/encryptedContentInfo > ContentType/encryptedContentInfo contentType/ Done. > 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/ 18. > 21. Section 2.4.2, p1: Should add "This content type does not provide > privacy." And also add "and does not provide compression"? Should we just remove "does not provide authentication" from the EnvelopedData section? Not changed. > 22. Section 2.5 title, s/Attribute/Attributes and the/ Done. > 23. Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/ Done. > > 24. I heard this comment at the last IETF meeting from > somebody. As I have > had the same problem in a number of cases (esp with doing > interop matrixes) > I am throwing it out for your consideration: > > The use of the words must, should and may in lower case causes some > confusion dealing with the question of - did the author just forget to > uppercase this or is it really not a protocol statement. > SHOULD examine all > instances of these words to see if a different word works > just as well. Ugh. MAY. Blake Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i1ob003350; Thu, 25 Mar 2004 20:44:01 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q4i1XI003349; Thu, 25 Mar 2004 20:44:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q4i0rs003338 for ; Thu, 25 Mar 2004 20:44:00 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with ESMTP ; Thu, 25 Mar 2004 20:44:00 -0800 From: "Blake Ramsdell" To: "'Russ Housley'" , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Date: Thu, 25 Mar 2004 20:44:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Sunday, February 29, 2004 9:16 PM > To: Blake Ramsdell; ietf-smime@imc.org > Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt > > 1. Should Section 1.4 reference RFC 3369? This section just describes where "prior practice of S/MIME" is located. I think that RFC 3369 is "current practice of S/MIME". > 2. Delete section 1.6 before the document is sent to the IESG. Deleted. > 3. Section 2.4 probably should point out that ContentInfo is > needed to > encapsulate each of the protection content types. Hmm. I don't agree. This is meant to describe the subset of types that are supported by S/MIME, independent of their encoding. > 4. What compression algorithm MUST be implemented if > CompressedData is > supported? Has this train finished wrecking or is it still in progress? > 5. Section 2.5.2: s/SMIMECapabilities attribute > should/SMIMECapabilities > attribute SHOULD/ Fixed. > 6. Section 2.6: the first two paragraphs are not clear. > S/MIME v3.1 MUST > support both issuerAndSerialNumber and subjectKeyIdentifier > for sending and > receiving. S/MIME v3.1 implementations MUST support both issuerAndSerialNumber as well as subjectKeyIdentifier. Messages that use the subjectKeyIdentifier choice cannot be read by S/MIME v2 clients. > 7. Section 3.4.3.2: s/not currently supported in S/MIME/not > currently > recommended in S/MIME/ Fixed. Blake Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PJOA39062491; Thu, 25 Mar 2004 11:24:10 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PJOAFE062490; Thu, 25 Mar 2004 11:24:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2PJO9J2062480 for ; Thu, 25 Mar 2004 11:24:09 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 1452 invoked by uid 0); 25 Mar 2004 19:14:58 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.77) by woodstock.binhost.com with SMTP; 25 Mar 2004 19:14:58 -0000 Message-Id: <5.2.0.9.2.20040325122850.03bd87c8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 25 Mar 2004 12:45:19 -0500 To: Paul Hoffman / IMC From: Russ Housley Subject: Re: A good article on S/MIME implementation problems Cc: ietf-smime@imc.org In-Reply-To: References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: >>1. The article gives the impression is that S/MIME is broken, and this >>is not the case. I would have been much happier with a title that >>conveyed problems with certificate issuing services and the ramifications >>of poor identity proofing. S/MIME is not the only security protocol that >>will suffer if the identity in a certificate is bogus. > >We disagree that the article gives the impression that S/MIME is broken. >Reading it, I came away with the impression that some S/MIME >implementations are broken. Maybe I've been working with this too long and >I know that S/MIME isn't broken. The title implies that S/MIME is broken. >>2. As far as S/MIME is concerned, the email address is the >>identity. X.500 Distinguished Names are not helpful to the S/MIME >>application, as there are not any protocol fields that make use of this >>form of identity. > >Exactly right. The fact that Thawte asks for, and some S/MIME applications >use, it shows a disregard for the standard. They are blatantly ignoring >the SHOULD NOT. Agree. >>3. The fact that Outlook hides the only form of identity that is >>validated is the biggest problem. > >Absolutely true, and pretty clear from the article. Yes. So, the title of the article could have been more descriptive of the real issue. >>Now that a script has been posted, maybe we should put some stronger >>language in MSGbis about the user interface. > >That would be nice. Maybe the editor can generate some proposed text. Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PIbW3I058423; Thu, 25 Mar 2004 10:37:32 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PIbWIq058422; Thu, 25 Mar 2004 10:37:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PIbV31058410 for ; Thu, 25 Mar 2004 10:37:32 -0800 (PST) (envelope-from dpkemp@missi.ncsc.mil) Message-ID: <200403251808.i2PI8GRK022057@stingray.missi.ncsc.mil> Date: Thu, 25 Mar 2004 13:37:29 -0500 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: A good article on S/MIME implementation problems References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Not exactly right. There is a difference between an RFC822 address as a user identity and an RFC822 address as routing information to enable message delivery. If I have a certificate identifying me as dpkemp@missi.ncsc.mil, then S/MIME user agents should display my identity without rejecting, or even whining, if I send a signed message from my hotmail account. And S/MIME user agents should allow me to encrypt a message to Paul using his imc.org certificate, but address it to Paul's hotmail account, without rejection or whining. Using a different syntax for subject names and email addresses makes this distinction obvious and would force user agents to operate correctly. Using the same RFC822 syntax for both subject names and email addresses leads to confusion between a user's single identity and that user's multiple mailboxes. Mismatch between an identity in a certificate and an unauthenticated address in a message header is NOT a security vulnerability. Displaying an unauthenticated message header as if it were an authenticated identity IS a vulnerability. Blurring this distinction by saying "the email address is the identity" is wrong, even if it is written down in black and white in the RFCs. Dave Paul Hoffman / IMC wrote: >> 2. As far as S/MIME is concerned, the email address is the identity. >> X.500 Distinguished Names are not helpful to the S/MIME application, >> as there are not any protocol fields that make use of this form of >> identity. > > Exactly right. The fact that Thawte asks for, and some S/MIME > applications use, it shows a disregard for the standard. They are > blatantly ignoring the SHOULD NOT. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PGSJqx047060; Thu, 25 Mar 2004 08:28:19 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PGSJNI047059; Thu, 25 Mar 2004 08:28:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PGSGp3047050; Thu, 25 Mar 2004 08:28:17 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> References: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> Date: Thu, 25 Mar 2004 08:17:44 -0800 To: Russ Housley From: Paul Hoffman / IMC Subject: Re: A good article on S/MIME implementation problems Cc: ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 7:45 AM -0500 3/25/04, Russ Housley wrote: >1. The article gives the impression is that S/MIME is broken, and >this is not the case. I would have been much happier with a title >that conveyed problems with certificate issuing services and the >ramifications of poor identity proofing. S/MIME is not the only >security protocol that will suffer if the identity in a certificate >is bogus. We disagree that the article gives the impression that S/MIME is broken. Reading it, I came away with the impression that some S/MIME implementations are broken. Maybe I've been working with this too long and I know that S/MIME isn't broken. >2. As far as S/MIME is concerned, the email address is the >identity. X.500 Distinguished Names are not helpful to the S/MIME >application, as there are not any protocol fields that make use of >this form of identity. Exactly right. The fact that Thawte asks for, and some S/MIME applications use, it shows a disregard for the standard. They are blatantly ignoring the SHOULD NOT. >3. The fact that Outlook hides the only form of identity that is >validated is the biggest problem. Absolutely true, and pretty clear from the article. >Now that a script has been posted, maybe we should put some stronger >language in MSGbis about the user interface. That would be nice. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PCkCpP025431; Thu, 25 Mar 2004 04:46:12 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PCkCdF025430; Thu, 25 Mar 2004 04:46:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2PCkA0a025414 for ; Thu, 25 Mar 2004 04:46:11 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 23783 invoked by uid 0); 25 Mar 2004 12:37:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.183.67) by woodstock.binhost.com with SMTP; 25 Mar 2004 12:37:01 -0000 Message-Id: <5.2.0.9.2.20040325073945.03be34b0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 25 Mar 2004 07:45:44 -0500 To: Paul Hoffman / IMC From: Russ Housley Subject: Re: A good article on S/MIME implementation problems Cc: ietf-smime@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: I do not completely agree with your assessment. I had a short email exchange with Jon Udell, and I made the following points. 1. The article gives the impression is that S/MIME is broken, and this is not the case. I would have been much happier with a title that conveyed problems with certificate issuing services and the ramifications of poor identity proofing. S/MIME is not the only security protocol that will suffer if the identity in a certificate is bogus. 2. As far as S/MIME is concerned, the email address is the identity. X.500 Distinguished Names are not helpful to the S/MIME application, as there are not any protocol fields that make use of this form of identity. 3. The fact that Outlook hides the only form of identity that is validated is the biggest problem. Now that a script has been posted, maybe we should put some stronger language in MSGbis about the user interface. Russ At 05:36 PM 3/24/2004 -0800, Paul Hoffman / IMC wrote: >Greetings again. I wouldn't normally send "here's another S/MIME article" >messages to the list, but this author has done an excellent job of both >finding the problem and proposing solutions. > > > >--Paul Hoffman, Director >--Internet Mail Consortium > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P1aeI3010524; Wed, 24 Mar 2004 17:36:40 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2P1ae1S010523; Wed, 24 Mar 2004 17:36:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-148.dsl.snfc21.pacbell.net [63.202.92.148]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2P1adgA010515 for ; Wed, 24 Mar 2004 17:36:40 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Wed, 24 Mar 2004 17:36:42 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: A good article on S/MIME implementation problems Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. I wouldn't normally send "here's another S/MIME article" messages to the list, but this author has done an excellent job of both finding the problem and proposing solutions. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OMZ0Jj096462; Wed, 24 Mar 2004 14:35:00 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2OMZ0xO096461; Wed, 24 Mar 2004 14:35:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2OMYxuE096452 for ; Wed, 24 Mar 2004 14:34:59 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 11611 invoked by uid 0); 24 Mar 2004 22:26:02 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.242.191) by woodstock.binhost.com with SMTP; 24 Mar 2004 22:26:02 -0000 Message-Id: <5.2.0.9.2.20040324172111.03aa6a20@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 17:35:02 -0500 To: From: Russ Housley Subject: Re: Comments on draft-ietf-smime-rfc3369bis-01.txt Cc: In-Reply-To: <20040323012752.D555A6A97B@smtp4.pacifier.net> References: <200403222044.PAA19688@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim: Thanks for the continuing quality review. >1. Section 5.1, para version: Grammer issue s/certificates is >present/certificates are present/ I consider this to be short for: if the certificates field is present, then ... Since the name of the field is plural, it does lead to an awkward read, but I think it is okay. >2. Section 5.1, para version: Correct to the beginning of the if clauses >should be > IF (any certificates with a type of other are present) OR > (any crls with a type of other are present) > THEN version MUST be 5. > > The other two clauses add nothing to the text. This is the way we did it in the past: IF (certificates is present) AND (any version 2 attribute certificates are present) THEN version MUST be 4 We say: if the field is present and that field contains the new thing, then .... >3. Section 5.3: Consider the following text. > > When generating a SignerIdentifier, > implementations MAY support one of the forms (either > issuerAndSerialNumber or subjectKeyIdentifier) and always use it, > or implementations MAY arbitrarily mix the two forms. > > I think that it might need to be updated for dealing with OTHER, but >I don't know what to really say about that. I added: "However, subjectKeyIdentifier MUST be used to refer to a public key contained in a non-X.509 certificate." Does that address your concern? >4. Section 6.2.1, para 'rid': s/signer's/recipient's/ Good catch. It will be fixed in version -02. >5. Section 6.2.2, para 'originator': s/thereby the sender's public key, >a/thereby the sender's public key, by a/ Good catch. It will be fixed in version -02. Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N1RmP3045911; Mon, 22 Mar 2004 17:27:48 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2N1RmHU045910; Mon, 22 Mar 2004 17:27:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2N1RlFw045904 for ; Mon, 22 Mar 2004 17:27:47 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id D555A6A97B; Mon, 22 Mar 2004 17:27:52 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Russ Housley'" Cc: Subject: Comments on draft-ietf-smime-rfc3369bis-01.txt Date: Mon, 22 Mar 2004 17:32:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQQV4EpSL1P/RuMSKCW7HAPVoQNngAG/soA In-Reply-To: <200403222044.PAA19688@ietf.org> Message-Id: <20040323012752.D555A6A97B@smtp4.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. Section 5.1, para version: Grammer issue s/certificates is present/certificates are present/ 2. Section 5.1, para version: Correct to the beginning of the if clauses should be IF (any certificates with a type of other are present) OR (any crls with a type of other are present) THEN version MUST be 5. The other two clauses add nothing to the text. 3. Section 5.3: Consider the following text. When generating a SignerIdentifier, implementations MAY support one of the forms (either issuerAndSerialNumber or subjectKeyIdentifier) and always use it, or implementations MAY arbitrarily mix the two forms. I think that it might need to be updated for dealing with OTHER, but I don't know what to really say about that. 4. Section 6.2.1, para 'rid': s/signer's/recipient's/ 5. Section 6.2.2, para 'originator': s/thereby the sender's public key, a/thereby the sender's public key, by a/ Jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MLnD19033602; Mon, 22 Mar 2004 13:49:13 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MLnDuJ033601; Mon, 22 Mar 2004 13:49:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mlnya401er.ml.com (mlnya401er.ml.com [199.43.38.99]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MLnDIa033595 for ; Mon, 22 Mar 2004 13:49:13 -0800 (PST) (envelope-from Internet-Drafts@ietf.org) Received: from mlnya303bh.amrs.win.ml.com (unknown [146.125.109.101]) by mlnya401er.ml.com (Postfix) with ESMTP id 0A5611B55 for ; Mon, 22 Mar 2004 16:49:13 -0500 (EST) thread-index: AcQQV4EpSL1P/RuMSKCW7HAPVoQNng== Received: from mail pickup service by mlnya303bh.amrs.win.ml.com with Microsoft SMTPSVC; Mon, 22 Mar 2004 16:49:08 -0500 Received: from MLTKA302BH.aja.win.ml.com ([170.242.208.96]) by mlnya301bh.amrs.win.ml.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Mar 2004 16:22:17 -0500 Received: from tkpsexh12.exchange.japan.ml.com ([170.242.29.194]) by MLTKA302BH.aja.win.ml.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 23 Mar 2004 06:22:14 +0900 Received: by tkpsexh12.exchange.japan.ml.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Mar 2004 06:22:18 +0900 Received: from ewstwt04.exchange.ml.com ([146.125.249.154]) by tkpsexh8.exchange.japan.ml.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id HNMYD656; Tue, 23 Mar 2004 06:22:15 +0900 Received: from 146.125.185.11 by ewstwt04.exchange.ml.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7);); Mon, 22 Mar 2004 16:22:11 -0500 Received: from wstutil12a.ml.com (wstutil12a-v [209.65.19.67]) by wstutil13a.ml.com (8.12.10/8.12.5/wstutil13a-1.1) with ESMTP id i2MLME1u027023 for ; Mon, 22 Mar 2004 16:22:14 -0500 (EST) Received: from psmtp.com (exprod6mx67.postini.com [12.158.36.51]) by wstutil12a.ml.com (8.12.10/8.12.5/wstutil12a-1.2) with SMTP id i2MLM9Ng004309 for ; Mon, 22 Mar 2004 16:22:09 -0500 (EST) Received: from source ([132.151.6.40]) by exprod6mx67.postini.com ( [12.158.35.251]) with SMTP; Mon, 22 Mar 2004 13:22:08 PST Content-Transfer-Encoding: 7bit Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1B5WSV-0001RA-At for ietf-announce-list@asgard.ietf.org; Mon, 22 Mar 2004 15:55:43 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp ( Exim 4.14) id 1B5WIP-000107-Ow for all-ietf@asgard.ietf.org; Mon, 22 Mar 2004 15:45:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org ( 8.9.1a/8.9.1a) with ESMTP id PAA19688; Mon, 22 Mar 2004 15:44:17 -0500 (EST) X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Message-ID: <200403222044.PAA19688@ietf.org> MIME-Version: 1.0 To: <"IETF-Announce:"@mlnya401er.ml.com> Cc: Content-Class: urn:content-classes:message Importance: normal From: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Reply-To: Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-01.txt Date: Mon, 22 Mar 2004 15:44:17 -0500 X-pstn-levels: (S:34.91659/99.43921 P:95.9108 ) X-pstn-settings: 1 (0.1500:0.1500) p X-pstn-addresses: from [db-null] X-WSS-ID: 6C418689835493-01-01 Content-Type: multipart/mixed; boundary="NextPart" X-OriginalArrivalTime: 22 Mar 2004 21:22:14.0705 (UTC) FILETIME=[BF101A10:01C41053] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --NextPart Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the S/MIME Mail Security Working Group of = the IETF. Title : Cryptographic Message Syntax (CMS) Author(s) : R. Housley Filename : draft-ietf-smime-rfc3369bis-01.txt Pages : 55 Date : 2004-3-22 =09 This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-01.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc3369bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.=20 -------------------------------------------------------- =20 If you are not an intended recipient of this e-mail, please notify the = sender, delete it and do not read, act upon, print, disclose, copy, = retain or redistribute it. Click here for important additional terms = relating to this e-mail. http://www.ml.com/email_terms/=20 -------------------------------------------------------- =20 --NextPart Content-Type: multipart/alternative; boundary="OtherAccess" Content-Transfer-Encoding: 7bit --OtherAccess Content-Type: message/external-body; access-type=mail-server; server=mailserv@ietf.org Content-Transfer-Encoding: 7bit Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-22151357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt --OtherAccess Content-Type: message/external-body; access-type=anon-ftp; site=ftp.ietf.org; directory=internet-drafts; name="draft-ietf-smime-rfc3369bis-01.txt" Content-Transfer-Encoding: 7bit --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MKjCI0028068; Mon, 22 Mar 2004 12:45:12 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2MKjCET028067; Mon, 22 Mar 2004 12:45:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2MKjAwG028061 for ; Mon, 22 Mar 2004 12:45:11 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19688; Mon, 22 Mar 2004 15:44:17 -0500 (EST) Message-Id: <200403222044.PAA19688@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-01.txt Date: Mon, 22 Mar 2004 15:44:17 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Cryptographic Message Syntax (CMS) Author(s) : R. Housley Filename : draft-ietf-smime-rfc3369bis-01.txt Pages : 55 Date : 2004-3-22 This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc3369bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-22151357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc3369bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc3369bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-22151357.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2WM2p010731; Thu, 18 Mar 2004 18:32:22 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J2WM0Y010730; Thu, 18 Mar 2004 18:32:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp005.bizmail.sc5.yahoo.com (smtp005.bizmail.sc5.yahoo.com [66.163.175.82]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2J2WLCn010724 for ; Thu, 18 Mar 2004 18:32:21 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@138.88.0.49 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 19 Mar 2004 02:32:28 -0000 Message-ID: <405A5C1E.4080109@ieca.com> Date: Fri, 19 Mar 2004 11:34:06 +0900 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: Draft minutes from the Seoul meeting References: <404DB93C.2040700@ieca.com> In-Reply-To: <404DB93C.2040700@ieca.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hearing no objections I send the minutes in ot the proceedings people.

spt

Sean P. Turner wrote:


Please have all comments in by next Monday.  I want to get the presentations and minutes to the proceeding folks as soon as possible.

spt

Paul Hoffman / IMC wrote:


Greetings again. Here are my version of the minutes from last weeks meeting. Please let me know this week if you have any changes.

--Paul Hoffman


S/MIME Minutes
March 2, 2004
Seoul, Korea

The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in
from Seattle via Jabber and iChat.

The short agenda was agreed to.

Sean updated the status since the last IETF meeting.

    New RFC (3657, Camellia)
    Three drafts that are with the RFC editor
        (symkeydist, x400wrap, and x400transport)
    Two drafts in WG last call (rfc2632bis and rfc2633bis)
    The draft that will go into WG last call when its editor
        finally finishes it (examples).
    Three drafts are currently active in the WG:
        cms-rsa-kem
        gost
        park-cms-seed

Sean talked about the milestones and how well we are doing on them.
We have a few short-term milestones and a much longer list of
long-term ones.

Sean gave Blake's presentation on MSGbis and CERTbis status
    Give the list of changes from last versions
    Received a bunch of editorial comments for both documents
    Russ said that other groups are using these docs, so please take
        a careful look at them.

Sean gave a presentation on GOST status
    Added a new draft with the algorithms needed for implementing GOST
    Move the default parameters to different doc
    Added message examples
    Seeking more input, particularly from implementers

Jongwook Park gave SEED updates
    Two drafts are already out there
    The algorithm is mandatory in Korea for government devices
    Approved by ISO/IEC JTC1/SC27
    Looking for comments and implementations

We finished in about 17 minutes.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2J2WHkG010713; Thu, 18 Mar 2004 18:32:17 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2J2WH5Q010712; Thu, 18 Mar 2004 18:32:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp005.bizmail.sc5.yahoo.com (smtp005.bizmail.sc5.yahoo.com [66.163.175.82]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2J2WC6l010697 for ; Thu, 18 Mar 2004 18:32:16 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@138.88.0.49 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 19 Mar 2004 02:32:18 -0000 Message-ID: <405A5C15.7070001@ieca.com> Date: Fri, 19 Mar 2004 11:33:57 +0900 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: Draft minutes from the Seoul meeting References: <404DB93C.2040700@ieca.com> In-Reply-To: <404DB93C.2040700@ieca.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hearing no objections I send the minutes in ot the proceedings people.

spt

Sean P. Turner wrote:

Please have all comments in by next Monday.  I want to get the presentations and minutes to the proceeding folks as soon as possible.

spt

Paul Hoffman / IMC wrote:


Greetings again. Here are my version of the minutes from last weeks meeting. Please let me know this week if you have any changes.

--Paul Hoffman


S/MIME Minutes
March 2, 2004
Seoul, Korea

The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in
from Seattle via Jabber and iChat.

The short agenda was agreed to.

Sean updated the status since the last IETF meeting.

    New RFC (3657, Camellia)
    Three drafts that are with the RFC editor
        (symkeydist, x400wrap, and x400transport)
    Two drafts in WG last call (rfc2632bis and rfc2633bis)
    The draft that will go into WG last call when its editor
        finally finishes it (examples).
    Three drafts are currently active in the WG:
        cms-rsa-kem
        gost
        park-cms-seed

Sean talked about the milestones and how well we are doing on them.
We have a few short-term milestones and a much longer list of
long-term ones.

Sean gave Blake's presentation on MSGbis and CERTbis status
    Give the list of changes from last versions
    Received a bunch of editorial comments for both documents
    Russ said that other groups are using these docs, so please take
        a careful look at them.

Sean gave a presentation on GOST status
    Added a new draft with the algorithms needed for implementing GOST
    Move the default parameters to different doc
    Added message examples
    Seeking more input, particularly from implementers

Jongwook Park gave SEED updates
    Two drafts are already out there
    The algorithm is mandatory in Korea for government devices
    Approved by ISO/IEC JTC1/SC27
    Looking for comments and implementations

We finished in about 17 minutes.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2HG2K1a013948; Wed, 17 Mar 2004 08:02:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2HG2Kuv013947; Wed, 17 Mar 2004 08:02:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2HG2J0M013924 for ; Wed, 17 Mar 2004 08:02:19 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 26849 invoked by uid 0); 17 Mar 2004 15:55:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.132.209) by woodstock.binhost.com with SMTP; 17 Mar 2004 15:55:05 -0000 Message-Id: <5.2.0.9.2.20040317105944.01f7d848@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 17 Mar 2004 11:01:36 -0500 To: Paul Hoffman / IMC , ietf-smime@imc.org From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt In-Reply-To: References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul: Se section 10.2.2. Russ At 04:59 PM 3/16/2004 -0800, Paul Hoffman / IMC wrote: >At 4:58 PM -0500 3/16/04, Russ Housley wrote: >>Dear S/MIME WG: >> >>Yes, we are making another round of updates to CMS. I expect them to be >>very minor. The changes are described in Section 1.2, which says: >> >> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC >> 3369 introduced an extension mechanism to support new key management >> schemes without further changes to the CMS. This document introduces >> a similar extension mechanism to support additional certificate >> formats for the verification of digital signatures without further >> changes to the CMS. Backward compatibility with both RFC 2630 and >> RFC 3369 is preserved. > >Maybe I'm being blind, but *where* is that extension mechanism introduced >in the new document? Listing it explicitly in this introductory material >would help the reader (or at least me...). > >--Paul Hoffman, Director >--Internet Mail Consortium > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1nwA2078047; Tue, 16 Mar 2004 17:49:58 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2H1nwZr078046; Tue, 16 Mar 2004 17:49:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1nv9Y078038; Tue, 16 Mar 2004 17:49:57 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 8BC7E6ABA3; Tue, 16 Mar 2004 17:50:02 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Dr Stephen Henson'" , "'Paul Hoffman / IMC'" Cc: Subject: RE: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt Date: Tue, 16 Mar 2004 17:54:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4057A78D.9030204@drh-consultancy.demon.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQLwLmtnAH/WQtDRLmZ44pQHVnX2wAAfelg Message-Id: <20040317015002.8BC7E6ABA3@smtp2.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve is correct. The change was made by adding the OtherCertFormat data type to section 10.2.2. However I think that it is easier for people to find if the section number is included in the changes section. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Dr Stephen Henson Sent: Tuesday, March 16, 2004 5:19 PM To: Paul Hoffman / IMC Cc: ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt Paul Hoffman / IMC wrote: > > At 4:58 PM -0500 3/16/04, Russ Housley wrote: > >> Dear S/MIME WG: >> >> Yes, we are making another round of updates to CMS. I expect them to >> be very minor. The changes are described in Section 1.2, which says: >> >> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC >> 3369 introduced an extension mechanism to support new key management >> schemes without further changes to the CMS. This document introduces >> a similar extension mechanism to support additional certificate >> formats for the verification of digital signatures without further >> changes to the CMS. Backward compatibility with both RFC 2630 and >> RFC 3369 is preserved. > > > Maybe I'm being blind, but *where* is that extension mechanism > introduced in the new document? Listing it explicitly in this > introductory material would help the reader (or at least me...). > Presumably the CertificateChoices type mentioned in 10.2.2 and its use in CertificateSet. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1J5Ks076412; Tue, 16 Mar 2004 17:19:05 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2H1J5ZL076411; Tue, 16 Mar 2004 17:19:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H1J3Jj076402; Tue, 16 Mar 2004 17:19:04 -0800 (PST) (envelope-from shenson@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]) by anchor-post-31.mail.demon.net with esmtp (Exim 3.35 #1) id 1B3Pi7-0007oS-0V; Wed, 17 Mar 2004 01:19:07 +0000 Message-ID: <4057A78D.9030204@drh-consultancy.demon.co.uk> Date: Wed, 17 Mar 2004 01:19:09 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> In-Reply-To: X-Enigmail-Version: 0.83.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman / IMC wrote: > > At 4:58 PM -0500 3/16/04, Russ Housley wrote: > >> Dear S/MIME WG: >> >> Yes, we are making another round of updates to CMS. I expect them to >> be very minor. The changes are described in Section 1.2, which says: >> >> This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC >> 3369 introduced an extension mechanism to support new key management >> schemes without further changes to the CMS. This document introduces >> a similar extension mechanism to support additional certificate >> formats for the verification of digital signatures without further >> changes to the CMS. Backward compatibility with both RFC 2630 and >> RFC 3369 is preserved. > > > Maybe I'm being blind, but *where* is that extension mechanism > introduced in the new document? Listing it explicitly in this > introductory material would help the reader (or at least me...). > Presumably the CertificateChoices type mentioned in 10.2.2 and its use in CertificateSet. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H0x7HQ075451; Tue, 16 Mar 2004 16:59:07 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2H0x7aC075450; Tue, 16 Mar 2004 16:59:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2H0x5fV075439; Tue, 16 Mar 2004 16:59:06 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> References: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> Date: Tue, 16 Mar 2004 16:59:09 -0800 To: Russ Housley , ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:58 PM -0500 3/16/04, Russ Housley wrote: >Dear S/MIME WG: > >Yes, we are making another round of updates to CMS. I expect them >to be very minor. The changes are described in Section 1.2, which >says: > > This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC > 3369 introduced an extension mechanism to support new key management > schemes without further changes to the CMS. This document introduces > a similar extension mechanism to support additional certificate > formats for the verification of digital signatures without further > changes to the CMS. Backward compatibility with both RFC 2630 and > RFC 3369 is preserved. Maybe I'm being blind, but *where* is that extension mechanism introduced in the new document? Listing it explicitly in this introductory material would help the reader (or at least me...). --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GLx4Zw065298; Tue, 16 Mar 2004 13:59:04 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2GLx49J065297; Tue, 16 Mar 2004 13:59:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2GLx4s7065290 for ; Tue, 16 Mar 2004 13:59:04 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 26172 invoked by uid 0); 16 Mar 2004 21:52:02 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.156) by woodstock.binhost.com with SMTP; 16 Mar 2004 21:52:02 -0000 Message-Id: <5.2.0.9.2.20040316165137.035d73d8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 16 Mar 2004 16:58:49 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt In-Reply-To: <200403162100.QAA24382@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear S/MIME WG: Yes, we are making another round of updates to CMS. I expect them to be very minor. The changes are described in Section 1.2, which says: This document obsoletes RFC 3369 [CMS2]. As discussed above, RFC 3369 introduced an extension mechanism to support new key management schemes without further changes to the CMS. This document introduces a similar extension mechanism to support additional certificate formats for the verification of digital signatures without further changes to the CMS. Backward compatibility with both RFC 2630 and RFC 3369 is preserved. I expect to fold in all of the changes needed to correct the errata posted on the RFC Editor's web site in the next version. Also, Peter Gutmann has asked for some clarification of countersignature. Finally, Jim Schaad has suggested that support for "other format" revocation status information is appropriate since "other format" certificates are being supported. I do not expect these changes to take long. I will post -01 before the end of the week. Russ >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the S/MIME Mail Security Working Group of the >IETF. > > Title : Cryptographic Message Syntax (CMS) > Author(s) : R. Housley > Filename : draft-ietf-smime-rfc3369bis-00.txt > Pages : 53 > Date : 2004-3-16 > >This document describes the Cryptographic Message Syntax (CMS). This > syntax is used to digitally sign, digest, authenticate, or encrypt > arbitrary message content. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-00.txt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GL0X3H062305; Tue, 16 Mar 2004 13:00:33 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2GL0XOK062304; Tue, 16 Mar 2004 13:00:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2GL0WjZ062297 for ; Tue, 16 Mar 2004 13:00:33 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24382; Tue, 16 Mar 2004 16:00:34 -0500 (EST) Message-Id: <200403162100.QAA24382@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rfc3369bis-00.txt Date: Tue, 16 Mar 2004 16:00:34 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Cryptographic Message Syntax (CMS) Author(s) : R. Housley Filename : draft-ietf-smime-rfc3369bis-00.txt Pages : 53 Date : 2004-3-16 This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc3369bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc3369bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-16162515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc3369bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc3369bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-16162515.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9ADg3068263; Wed, 10 Mar 2004 01:10:13 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A9ADZA068262; Wed, 10 Mar 2004 01:10:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from postman-pat.actimage.fr (postman-pat.actimage.net [80.87.224.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9ACsf068219 for ; Wed, 10 Mar 2004 01:10:12 -0800 (PST) (envelope-from muriel@actimage.net) Received: from leila (inet-gate3 [80.87.224.93]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i2A93mC15554 for ; Wed, 10 Mar 2004 10:03:48 +0100 (CET) Message-ID: <03aa01c4067f$c53b0810$4406a8c0@leila> From: "Muriel Souville" To: Subject: Launch of the Security Plugtests Registration Date: Wed, 10 Mar 2004 10:12:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_039A_01C40688.253A6780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_039A_01C40688.253A6780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, The ETSI Plugtests(tm) Service is pleased to announce the opening of the Security Plugtests registration. The event will take place from 24 till 28 May at the ETSI premises, in Sophia Antipolis (France). Deadline to register is 5th May. All details about the event are to be found at http://www.etsi.org/plugtests/security.htm Feel free to forward this email to as many people as you want in order to have a really interesting test opportunity this week. For any enquiry you may have, please write to plugtests@etsi.org. Thanks for your attention. We look forward to welcoming you at our Headquarters in May. Best regards Muriel SOUVILLE ETSI Consultant Tel: +33 (0) 3 90 23 63 63 ------=_NextPart_000_039A_01C40688.253A6780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,

The ETSI Plugtests(tm) Service is pleased to announce the=20 opening
of the Security Plugtests registration.
The event will = take place=20 from 24 till 28 May at the ETSI premises,
in Sophia Antipolis=20 (France).
Deadline to register is 5th May.

 All details = about the=20 event are to be found at
http://www.etsi.org/plugtests/security.htm

Feel free to forward this email to as = many people=20 as you want in order
to have a really interesting test opportunity = this=20 week.

For any enquiry you may have, please write to plugtests@etsi.org.

Thanks for your attention.
We look forward to = welcoming you=20 at our Headquarters in May.

Best regards

Muriel = SOUVILLE
ETSI=20 Consultant
Tel: +33 (0) 3 90 23 63=20 63
------=_NextPart_000_039A_01C40688.253A6780-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A5isd7097588; Tue, 9 Mar 2004 21:44:54 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A5irs6097587; Tue, 9 Mar 2004 21:44:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A5irtM097581 for ; Tue, 9 Mar 2004 21:44:53 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 5C6D16F4EE; Tue, 9 Mar 2004 21:45:00 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt Date: Tue, 9 Mar 2004 21:49:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcP5sqq1SUllhFz9SXCFRjorZD2AbQBUkjUg Message-Id: <20040310054500.5C6D16F4EE@smtp1.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake, A couple of small issues: 1. Do we need to review the RSA key sizes on certificate verification, 4096 is soon to be a common key size I think and should be supported. I don't know that 512 should not be dropped from MUST to SHOULD. 2. I just noticed that 4.4.2.1 does not have a corresponding section for RSA. In point of fact this may now be in CMSALG and therefore not needed. (i.e. remove 4.4.2.1) jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28MXcY5007258; Mon, 8 Mar 2004 14:33:38 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28MXciI007257; Mon, 8 Mar 2004 14:33:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.11/8.12.8) with SMTP id i28MXbnb007247 for ; Mon, 8 Mar 2004 14:33:37 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@210.93.162.119 with plain) by smtp001.bizmail.yahoo.com with SMTP; 8 Mar 2004 22:33:42 -0000 Message-ID: <404DB93C.2040700@ieca.com> Date: Tue, 09 Mar 2004 07:31:56 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-smime@imc.org Subject: Re: Draft minutes from the Seoul meeting References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please have all comments in by next Monday. I want to get the presentations and minutes to the proceeding folks as soon as possible. spt Paul Hoffman / IMC wrote: > > Greetings again. Here are my version of the minutes from last weeks > meeting. Please let me know this week if you have any changes. > > --Paul Hoffman > > > S/MIME Minutes > March 2, 2004 > Seoul, Korea > > The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in > from Seattle via Jabber and iChat. > > The short agenda was agreed to. > > Sean updated the status since the last IETF meeting. > > New RFC (3657, Camellia) > Three drafts that are with the RFC editor > (symkeydist, x400wrap, and x400transport) > Two drafts in WG last call (rfc2632bis and rfc2633bis) > The draft that will go into WG last call when its editor > finally finishes it (examples). > Three drafts are currently active in the WG: > cms-rsa-kem > gost > park-cms-seed > > Sean talked about the milestones and how well we are doing on them. > We have a few short-term milestones and a much longer list of > long-term ones. > > Sean gave Blake's presentation on MSGbis and CERTbis status > Give the list of changes from last versions > Received a bunch of editorial comments for both documents > Russ said that other groups are using these docs, so please take > a careful look at them. > > Sean gave a presentation on GOST status > Added a new draft with the algorithms needed for implementing GOST > Move the default parameters to different doc > Added message examples > Seeking more input, particularly from implementers > > Jongwook Park gave SEED updates > Two drafts are already out there > The algorithm is mandatory in Korea for government devices > Approved by ISO/IEC JTC1/SC27 > Looking for comments and implementations > > We finished in about 17 minutes. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28LP2ME002416; Mon, 8 Mar 2004 13:25:02 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28LP2ma002415; Mon, 8 Mar 2004 13:25:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28LP1Ud002409 for ; Mon, 8 Mar 2004 13:25:01 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 4B5666F7CF; Mon, 8 Mar 2004 13:24:51 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: "Ietf-Smime" Subject: Comments on draft-ietf-smime-rfc2632bis-05.txt Date: Mon, 8 Mar 2004 13:28:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQFVE4/B8TaScgQTEO/S9PyZbCNpw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040308212451.4B5666F7CF@smtp1.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Blake, 1. Section 2.2.1: In the following text, I have a problem with "PKIX" as oppose to X.509 Identity Certificates, esp as PKIX now has a definition for ACs. The CMS message format supports a choice of certificate formats for public key content types: PKIX, PKCS #6 Extended Certificates and X.509 Attribute Certificates. 2. Section 2.2.1, p 3: s/suerceded/superseded/ --- I didn't believe it but I looked it up. 3. Section 2.3: The following statements don't agree: Receiving agents MUST be able to handle an arbitrary number of certificates of arbitrary relationship to the message sender and to each other in arbitrary order. A receiving agent SHOULD be able to handle an arbitrarily large number of certificates and chains. 4. Section 2.3: Let's get a better term for this that "CA certificates" Agents MAY send CA certificates, that is, certificates that are self- signed and can be considered the "root" of other chains. 5. Section 3: Please define the type of field for pkcs-9-at-emailAddress. (I think it's IA5 string but can't swear to it off the top of my head.) 6. Section 5: s/noticable/noticeable/ 7. Section 5: s/message,if/message, if/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28KNXsn097465; Mon, 8 Mar 2004 12:23:33 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28KNXGM097464; Mon, 8 Mar 2004 12:23:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28KNXPF097458 for ; Mon, 8 Mar 2004 12:23:33 -0800 (PST) (envelope-from capel@comgate.com) Received: from mail4.magma.ca (mail4.magma.ca [206.191.0.222]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id i28KNaXe007182; Mon, 8 Mar 2004 15:23:36 -0500 Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail4.magma.ca (8.12.10/8.12.9) with ESMTP id i28KNQ7N024711; Mon, 8 Mar 2004 15:23:36 -0500 From: "Tony Capel" To: Cc: "'Sean P. Turner'" Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt Date: Mon, 8 Mar 2004 15:23:23 -0500 Message-ID: <001401c4054b$38075ff0$01b5a8c0@tony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4044B9EF.5090401@ieca.com> Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This may be falling into the crack between S/MIME and PKIX. I do not think this needs a change in any of the documents, although something in the security section MIGHT be appropriate (as below). I have seen it proposed that the signing time be used when validating signatures, and at least one S/MIME implementation may do this. I THINK this violates the intent of CERT section 4.1 and rfc3280 (KEYM) sections 3.3 and 6.3.3. That is, "current time" in these rfc's should not be interpreted to be equivalent to the "signing time" from the message. Sean Turner's recent comment #6, 2 March 2004 on CERT is also relevant. This was discussed back in 1998 and I think responsibility allocated to KEYM (PKIX). The unique S/MIME WG issue is the improper (IMHO) use of the signing time in the message to judge certificate expiry or CRL validity (of course KEYM does not mention signing time). Denis Pinkas wrote (28 Sept 1998, in part): "...The signingTime attribute only reflects the time the signer wanted to be included. The signer may well pre-date that value, ... but more important, if the key of the signer is compromised then an attacker may also pre-date that value. In such a situation it cannot be made a difference between a past "honest" signature from the right signer and a pre-dated "fake" signature from an attacker...." Alternatively stated: An attack is for a forger to set their local clock back to a time prior to the revocation, forge the message and enclose a then-current (old) CRL in the message. If the signing time is used to select the CRL the forger could succeed (the forger might mount a DOS attack to prevent the receiver getting a more recent CRL). Alternatively, the forger waits for certificate expiry and then compromises the key, back-dates their forged signature - and again the attack is successful even if the rightful owner knows about it (since revocation support is not guaranteed past expiry). I think the following are correct: 1. The certificate is checked for expiry, and if unexpired, the current and not "too old" CRL is used (or OCSP server, etc. accessed). Specifically the check for expiry AND "too old" must be based on the receiver's sense of time, NOT the signing time. (Ideally it would be based on a trusted time source but this is normally not available, so this should not be mandatory. If there is a trusted time stamp other options are available). 2. If the certificate is expired, no CRL (or OCSP) check is done since the CA does not guarantee revocation processing. CRL checking should not be done even if a cached "old" CRL is available (e.g. as provided within the message). This has consequences when attempting to (re-)verify old messages stored in inBoxes for example. They may verify when received, but fail when re-verified later. This is bad for users, and implementers may be tempted to provide a "better" solution by using the signing time (bad). If a signature on an incoming message is important, users must consider using (prior to cert expiry) a trusted time stamp server or trusted archive so a "trusted time" can be added. Enterprise users might consider automating this; e.g. ensuring that old e-mails (and CRLs!!) are archived in a trusted and timely manner. Should a sentence be added cautioning users against using the untrusted signing time from the message for certificate expiry and CRL validity checking? For example something like: "The signing time in the message cannot be trusted if the signing key has been compromised. Thus the signing time should not be used as the "current time" when performing certificate expiry or revocation checking as per KEYM." Tony PS: A quote from Peter Sylvester (30 July 2003) in the PKIX WG discussion: "Isn't creating a digital signature which is not almost immediately presented to some relying or attesting party a profound misunderstanding of cryptographic techniques? " Unfortunately we must live with e-mail application reality! PPS: There is a long discussion, (starting in about 30 July 2003) in the PKIX WG on related issues including potential archiving of CRL's. I think for current purposes we just need to emphasize that "signing time" is untrusted and must not be used for expiry or CRL validity testing. Going beyond that might get too complicated and best left with PKIX. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28Heb4Q084750; Mon, 8 Mar 2004 09:40:37 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28Hebr7084749; Mon, 8 Mar 2004 09:40:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28HeaIX084742 for ; Mon, 8 Mar 2004 09:40:36 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman Message-Id: Date: Mon, 8 Mar 2004 09:40:37 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Draft minutes from the Seoul meeting Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. Here are my version of the minutes from last weeks meeting. Please let me know this week if you have any changes. --Paul Hoffman S/MIME Minutes March 2, 2004 Seoul, Korea The meeting was chaired by Sean Turner; Blake Ramsdell was jacked in from Seattle via Jabber and iChat. The short agenda was agreed to. Sean updated the status since the last IETF meeting. New RFC (3657, Camellia) Three drafts that are with the RFC editor (symkeydist, x400wrap, and x400transport) Two drafts in WG last call (rfc2632bis and rfc2633bis) The draft that will go into WG last call when its editor finally finishes it (examples). Three drafts are currently active in the WG: cms-rsa-kem gost park-cms-seed Sean talked about the milestones and how well we are doing on them. We have a few short-term milestones and a much longer list of long-term ones. Sean gave Blake's presentation on MSGbis and CERTbis status Give the list of changes from last versions Received a bunch of editorial comments for both documents Russ said that other groups are using these docs, so please take a careful look at them. Sean gave a presentation on GOST status Added a new draft with the algorithms needed for implementing GOST Move the default parameters to different doc Added message examples Seeking more input, particularly from implementers Jongwook Park gave SEED updates Two drafts are already out there The algorithm is mandatory in Korea for government devices Approved by ISO/IEC JTC1/SC27 Looking for comments and implementations We finished in about 17 minutes. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28ATIg7059426; Mon, 8 Mar 2004 02:29:18 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28ATIgs059425; Mon, 8 Mar 2004 02:29:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28ATIXW059418 for ; Mon, 8 Mar 2004 02:29:18 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 989E58ABD7; Mon, 8 Mar 2004 02:29:17 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" Cc: "Ietf-Smime" Subject: Comments draft-ietf-smime-rfc2633bis-07.txt Date: Mon, 8 Mar 2004 02:34:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQE+N9NYXOKa0Y7Qg+c04MKBYHNlg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040308102917.989E58ABD7@smtp2.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Blake, 1. I just realized there is no abstract for this document. Is one required? 2. Section 2, p1: s/[CMS] provides/[CMSALG] provides/ 3. Section 1.1, p 4: Should there be a dependency/reference to CMSALG here as well? 4. Section 2.5.2, p1: Need to add text for Compression Algorithms. 5. Section 2.5.2: The following statement is no longer true (please delete): Note that all OIDs associated with the MUST and SHOULD implement algorithms are included in section A of this document. 6. section 3, p 1: s/[ESS] document provides examples/[ESS] document provides descriptions/ s/ESS provides an example of/ESS provides a description of/ 7. Section 3.1, p 5, s/implementor/implementer/ Section 3.6, p 3: ditto Section 4.1, p 2: ditto - I don't know if that is really an incorrect spelling, but MS Word does not know it. 8. Section 3.2.1, s/Application/pkcs7-signature/Application/pkcs7-signature (SignedData)/ 9. Section 3.2.2, p last: Suggest adding the text: "An smime-type parameters is not intended to give indications of security layers applied in the event of multiple levels of wrapping." 10. Section 3.4: In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both. --- what is the MUST handle? Otherwise there is no interop. 11: Section 3.4.3.2: The text "The SHA-256, SHA-384 and SHA-512 algorithms [FIPS180-2] are not currently supported in S/MIME, and are included here for completeness." Is only partially correct. They are supported, just not required by this document. I would like to clean this up by saying this in a tighter fashion. 12. Section 4, p 1: s/certification/certificate/ 13. Section A: s/prefered/preferred/ 14. References: CMSAES = RFC 3565 15. Section 1.1, p 4: s/the Cryptographic Message Syntax/the Cryptographic Message Syntax document/ 16. Is a specification MUST/SHOULD (section 1.1, p4) or the document (section 1.1, p3) (The same word is used, but in completely different meanings. Would not be a problem but for the MUST in p4 potentially wanting to force meaning into p3). 17. Section 2.2, p 3: s/the algorithms/the hash algorithms/ 18. Section 2.4.1, p1: s/signedData/SignedData/ - also envelopedData vs EnvelopedData and compressedData vs CompressedData. signedData does not actually exist in the CMS documents. The type is SignedData or the concept is signed data. I think we need to clean this up. Russ: Please note there is one section in CMS that needs to be cleaned up in the same way. 19. Section 2.4.1, p1: s/encryptedContentInfo ContentType/encryptedContentInfo contentType/ 20. Section 2.4.1, p1: s/in the envelopedData/in the EnvelopedData/ 21. Section 2.4.2, p1: Should add "This content type does not provide privacy." 22. Section 2.5 title, s/Attribute/Attributes and the/ 23. Section 2.5.2, p 3: s/SMIMECapabilites/SMIMECapabilities/ 24. I heard this comment at the last IETF meeting from somebody. As I have had the same problem in a number of cases (esp with doing interop matrixes) I am throwing it out for your consideration: The use of the words must, should and may in lower case causes some confusion dealing with the question of - did the author just forget to uppercase this or is it really not a protocol statement. SHOULD examine all instances of these words to see if a different word works just as well. Jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i249cYrh014821; Thu, 4 Mar 2004 01:38:34 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i249cYWS014819; Thu, 4 Mar 2004 01:38:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i249cWss014735 for ; Thu, 4 Mar 2004 01:38:33 -0800 (PST) (envelope-from aalberti@axway.com) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id i249cQ5B026613 for ; Thu, 4 Mar 2004 10:38:27 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C401CC.71B3CC02" Subject: SubjectAltName & email address X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 4 Mar 2004 10:38:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SubjectAltName & email address Thread-Index: AcQBzHA4XvI+/RtwTXiPUoUxPXUm2A== From: "Alberti Antoine" To: X-OriginalArrivalTime: 04 Mar 2004 09:38:46.0312 (UTC) FILETIME=[7D76F280:01C401CC] X-Scanned-By: MIMEDefang 2.38 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C401CC.71B3CC02 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I still have a theorical problem about the email address in the = certificate: S/MIME is not reserved to email messages. In particular, it = is already used in AS.2 (HTTP) from ediint working group. And as an = extension, it may be used in anything based on MIME. It seems that the = current version of the "S/MIME Version 3.1 Certificate Handling" draft = allows the use of S/MIME without email addresses. But is it really so = extreme to use S/MIME in other MIME based protocols than SMTP and POP3 = that it deserves no comment at all (the question is open, it is not = ironic at all) ? By the way, has anyone been in contact with the ediint working group = when they created their AS.2 and AS.3 (FTP) drafts? Regards. > = =20 > Antoine Alberti Axway. a Sopra Group company=09 > Tel : +33 (0)1 47 17 24 37 XFB R&D > Fax : +33 (0)1 47 17 24 25 26 Rue des Pavillons > email: aalberti@axway.com 92807 Puteaux Cedex - France >=20 >=20 >=20 ------_=_NextPart_001_01C401CC.71B3CC02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SubjectAltName & email address

I still have a theorical problem about = the email address in the certificate: S/MIME is not reserved to email = messages. In particular, it is already used in AS.2 (HTTP) from ediint = working group. And as an extension, it may be used in anything based on = MIME. It seems that the current version of the "S/MIME Version 3.1 Certificate = Handling" draft allows the use = of S/MIME without email addresses. But is it really so extreme to use = S/MIME in other MIME based protocols than SMTP and POP3 that it deserves = no comment at all (the question is open, it is not ironic at all) = ?

By the way, has anyone been in contact = with the ediint working group when they created their AS.2 and AS.3 = (FTP) drafts?

Regards.

            =          &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        

            = Antoine Alberti =         =         Axway.  a Sopra Group company  
            = Tel  : +33 (0)1 47 17 24 = 37     =         XFB = R&D
            = Fax : +33 (0)1 47 17 24 = 25      =         26 Rue des = Pavillons
            = email: = aalberti@axway.com       =         = 92807 Puteaux Cedex - = France



------_=_NextPart_001_01C401CC.71B3CC02-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i246YZbC047186; Wed, 3 Mar 2004 22:34:35 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i246YZjZ047182; Wed, 3 Mar 2004 22:34:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.11/8.12.8) with SMTP id i246YYM3047164 for ; Wed, 3 Mar 2004 22:34:34 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@218.37.231.20 with plain) by smtp004.bizmail.sc5.yahoo.com with SMTP; 4 Mar 2004 06:34:36 -0000 Message-ID: <40479284.8080205@ieca.com> Date: Thu, 04 Mar 2004 15:33:08 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: SMIME , "Housley, Russ" Subject: IETF 59 S/MIME WG Summary and Upcomming Events Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the 59th IETF S/MIME WG Meeting:
  • MSGbis and CERTbis stauts was presented - both are in WG last call
  • GOST update was provided
  • SEED was adopted by working group
In the next month:
  • MSGbis and CERTbis will be updated with comments and reissued
  • MSGbis and CERTbis will be forwarded to IESG for IETF Wide last call
  • Compressed will be obsoleted and reissued
  • Examples draft will be submitted to ID-editor
  • Examples draft will reenter WG last call
  • SEED will be resubmitted to the ID-editor
  • SEED will enter WG last call
In the coming months:
  • ESSbis will be produced
  • Interop for MSGbis and CERTbis will be produced
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23NiFYl007024; Wed, 3 Mar 2004 15:44:15 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23NiFxI007022; Wed, 3 Mar 2004 15:44:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23NiEVR007016 for ; Wed, 3 Mar 2004 15:44:14 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (unknown [218.37.225.152]) by smtp4.pacifier.net (Postfix) with ESMTP id 80EBB6A47E; Wed, 3 Mar 2004 15:44:09 -0800 (PST) Reply-To: From: "Jim Schaad" To: "Ietf-Smime" Cc: "'Jongwook Park'" Subject: Comments on draft-park-cms-seed-00.txt Date: Thu, 4 Mar 2004 08:48:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQA6kc3r8a9yw4xTVqJOO9pKgly8AAj8NBw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040303234409.80EBB6A47E@smtp4.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. In section 4, the OID presented and encoded in this section is incorrect. The OID that is encoded here needs to be id-seedCBC not id-npki-app-cmsSeed-wrap. Jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23M1UOe099786; Wed, 3 Mar 2004 14:01:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23M1UD4099785; Wed, 3 Mar 2004 14:01:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.11/8.12.8) with SMTP id i23M1TC2099775 for ; Wed, 3 Mar 2004 14:01:29 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@210.93.162.110 with plain) by smtp004.bizmail.sc5.yahoo.com with SMTP; 3 Mar 2004 22:01:33 -0000 Message-ID: <40471A45.1090800@ieca.com> Date: Thu, 04 Mar 2004 07:00:05 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David P. Kemp" , ietf-smime@imc.org CC: "Ramsdell, Blake" Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt References: <200402242159.i1OLxotW027670@stingray.missi.ncsc.mil> In-Reply-To: <200402242159.i1OLxotW027670@stingray.missi.ncsc.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David P. Kemp wrote: > > Blake, > > Thanks for clarifying the requirement to support certificates > without email addresses. > > Comments: > > 1. Section 2.3 para 4: "Agents MAY send CA certificates, that is, > certificates that are self-signed and can be considered the "root" > of other chains." This incorrectly implies that the only kind > of CA cert is the self-signed kind. Suggest "Agents MAY send > CA certificates that are self-signed and ..." > > 2. Section 4.4 paragraph 2: Why must sending and receiving > agents correctly handle the listed extensions only when they > appear in end-entity certificates? Suggest that sending and > receiving agents MUST correctly (i.e. in accordance with RFC 3280) > handle the basic constraints, key usage, AKI, SKI, and SAN extensions > in end-entity *and CA* certificates. > > 3. Section 4.4.1 paragraph 3: "Certificates SHOULD contain a > basicConstraints extension in CA certificates and SHOULD NOT contain > that extension in end entity certificates." In order to avoid > inconsistency with PKIX, change to "Certificates MUST contain a > basicConstraints extension in CA certificates and SHOULD NOT contain > that extension in end entity certificates." In other words, a > sending and receiving agent is non-compliant if it accepts > a v3 certificate without the basicConstraints extension as a CA > certificate. > > Dave Dave, I think the 1st and 3rd comments are editorial, but the 2nd corrects something that was wrong. I hope that implementors didn't just handle the extensions in EE certs but instead did the right thing and handled the extensions in CA certs as per 3280. spt Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23LuZEr099528; Wed, 3 Mar 2004 13:56:35 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23LuYH2099527; Wed, 3 Mar 2004 13:56:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.11/8.12.8) with SMTP id i23LuXRj099505 for ; Wed, 3 Mar 2004 13:56:34 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@210.93.162.110 with plain) by smtp003.bizmail.yahoo.com with SMTP; 3 Mar 2004 21:56:38 -0000 Message-ID: <4047191E.3050701@ieca.com> Date: Thu, 04 Mar 2004 06:55:10 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org CC: Tony Capel , "'Blake Ramsdell'" Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt References: <002601c40146$f803e5c0$01b5a8c0@tony> In-Reply-To: <002601c40146$f803e5c0$01b5a8c0@tony> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree with Tony's comment. It is in the same vein and should be added. spt Tony Capel wrote: >Minor additional comment (not a show stopper) related to Sean's number 6 >comment: > >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Sean P. Turner >| Sent: March 2, 2004 11:45 AM >| To: Blake Ramsdell >| Cc: ietf-smime@imc.org >| Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt >| >| <> >| >| 6. Para 5: I'd like to add a security consideration about why it >| might not be good to send CRLs: "CRLs sent with the message >| impose concern when the signer's certificate is revoked, but >| the signer purposely includes a valid CRL but not the most >| recent CRL without the signer's serialNumber thereby >| providing a false verification". (or something like that) >| .... > >IF this is added, it may also make sense to emphasize that the transmission of >root certificates may also be a problem (Para 2.3 paragraph 4 uses "SHOULD NOT" >in the context of accepting root certificates - this may not raise the issue >strongly enough). A caution in the Security section something like: > >"The ability of a receiver to adopt a self-signed certificate received within a >messages should be >strongly controlled to prevent the inadvertent adoption of root certificates. >The ability of a sender >to transmit self-signed certificates should be controlled to ensure that they >cannot >unexpectedly send root certificates which may potentially alter the trust >settings of receiving entities. Some implementers may choose to permit the >disabling of the ability to send and process-upon-receipt self-signed >certificates." > >Some enterprise environments may want to disable the ability of their desktops >to accept or send root certificates in messages. > >Tony > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23Hh201080080; Wed, 3 Mar 2004 09:43:02 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23Hh2sX080078; Wed, 3 Mar 2004 09:43:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23Hh10J080071 for ; Wed, 3 Mar 2004 09:43:01 -0800 (PST) (envelope-from capel@comgate.com) Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id i23Hh21C006025; Wed, 3 Mar 2004 12:43:02 -0500 Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id i23HgxvK019312; Wed, 3 Mar 2004 12:43:02 -0500 From: "Tony Capel" To: "'Sean P. Turner'" , "'Blake Ramsdell'" Cc: Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt Date: Wed, 3 Mar 2004 12:42:58 -0500 Message-ID: <002601c40146$f803e5c0$01b5a8c0@tony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4044B9EF.5090401@ieca.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Minor additional comment (not a show stopper) related to Sean's number 6 comment: | From: owner-ietf-smime@mail.imc.org | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Sean P. Turner | Sent: March 2, 2004 11:45 AM | To: Blake Ramsdell | Cc: ietf-smime@imc.org | Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt | | <> | | 6. Para 5: I'd like to add a security consideration about why it | might not be good to send CRLs: "CRLs sent with the message | impose concern when the signer's certificate is revoked, but | the signer purposely includes a valid CRL but not the most | recent CRL without the signer's serialNumber thereby | providing a false verification". (or something like that) | .... IF this is added, it may also make sense to emphasize that the transmission of root certificates may also be a problem (Para 2.3 paragraph 4 uses "SHOULD NOT" in the context of accepting root certificates - this may not raise the issue strongly enough). A caution in the Security section something like: "The ability of a receiver to adopt a self-signed certificate received within a messages should be strongly controlled to prevent the inadvertent adoption of root certificates. The ability of a sender to transmit self-signed certificates should be controlled to ensure that they cannot unexpectedly send root certificates which may potentially alter the trust settings of receiving entities. Some implementers may choose to permit the disabling of the ability to send and process-upon-receipt self-signed certificates." Some enterprise environments may want to disable the ability of their desktops to accept or send root certificates in messages. Tony Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i236YxkK069660; Tue, 2 Mar 2004 22:34:59 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i236YxMV069657; Tue, 2 Mar 2004 22:34:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i236YvT1069634 for ; Tue, 2 Mar 2004 22:34:58 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from romans (unknown [218.37.225.152]) by smtp3.pacifier.net (Postfix) with ESMTP id A3D8B6D99C; Tue, 2 Mar 2004 22:35:02 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Jongwook Park'" Cc: "Ietf-Smime" Subject: Comments on draft-park-seed-00.txt Date: Wed, 3 Mar 2004 15:39:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQA6lNET45oev4STXqKWvT2F3nmww== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-Id: <20040303063502.A3D8B6D99C@smtp3.pacifier.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Issues: 1. The text and references to RFC 2119 can be removed as there are no protocol statements in this document. 2. Section 2, para last: L0, L1, R0, R1, Ki0, Ki1 are not used in the preceeding psudeo-code. Wordsmithing suggestions: These are optional, they just correspond to what I think might be better grammer. 1. Abstract s/adopted to most/adopted by most/ 2. Section 2, p1: s/64-bit subkeys Ki generated/64-bit subkey Ki generated/ Jim Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i222k8YN069681; Mon, 1 Mar 2004 18:46:08 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i222k8vZ069680; Mon, 1 Mar 2004 18:46:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.11/8.12.8) with SMTP id i222k788069674 for ; Mon, 1 Mar 2004 18:46:07 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@218.37.226.73 with plain) by smtp001.bizmail.yahoo.com with SMTP; 2 Mar 2004 02:46:13 -0000 Message-ID: <4044BA02.3070207@ieca.com> Date: Tue, 02 Mar 2004 11:44:50 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Blake Ramsdell CC: ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Only minor editorial comments (read NO show stoppers):
  1. Para 1.3, Certificate definition: Replace "distinguished name" with "name" the names are not always "distinguished."
  2. Para 1.3, Receiving agent, Sending agent, and S/MIME agent definitions: Capitalize 1st word "software" and "user."
  3. Para 2.2, Last paragraph last sentence: replace "and may not implement id-dsa-with-sha1 at all" with "and may not implement id-dsa-with-sha1 or id-sha at all."
  4. Para 2.4.2, SignedData Content Type: Can we add a sentence that says "Applying a signature to message provides authentication, message integrity, and non-repudiation of origin."  The other content types indicate what "services" they support or don't support.
  5. Para 2.4.4, 2nd sentence: Replace "This content type does not provide authentication or privacy" with "This content type does not provide authentication, message integrity, non-repudiation, or data confidentiality".  Just making it match the "services" listed in the introduction.
  6. Para 3.1, Steps 1-4: Add periods to end of sentences.
  7. Para 3.1.3, 3rd Para 2nd sentence: Replace "8-bit clear" with "8-bit clean" to match terminology in 3.1.2 2nd paragraph 4 sentence.
  8. Para 3.3, Step 2, last sentence: Replace "(see CMS Section 6)" with (see [CMS] Section 6).
  9. Para 3.4.2, Steps 1&2: Add periods to end of sentences.
  10. Compressed data text in 3.5 points to 3.1 but there's no mention in 3.1 of compression.  You should either add a sentence to say that in 3.1 enveloped = compression in this section or make the following changes (or others to clarify that you also mean to refer to compression data):
    1. Para 3.1, Title: Replace "Signing or Enveloping" with "Signing, Enveloping, or Compressing" because para 3.5 says perform message as in 3.1 but there's not mention of compressing in 3.1.
    2. Para 3.1, 1st para 1st sentence: Replace "S/MIME is used to secure MIME entities" with "S/MIME is used to secure and optionally compress MIME entities."
    3. Para 3.1, 2nd para 1st sentence: Replace "The MIME entity that is secured and ..." with "The MIME entity that is secured or compressed and ..."
    4. Para 3.1, 4th para 1st sentence: Replace "A single procedure is used for creating MIME entities that are to be signed, enveloped, or both signed and enveloped" with "A single procedure is used for creating MIME entities that are to be signed, enveloped, compressed and both signed and enveloped, signed and compressed, compressed and enveloped, and compressed, signed, and enveloped, etc." (or whatever # of combinations you feel like listing)
    5. Para 3.1, 4th para 3rd sentence: Replace "It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages" with "It is recommended that these additional steps be performed on enveloped and compressed messages, or signed and enveloped messages or compressed, signed and enveloped messages."
    6. Para 3.1, 1st para after Step 3: Replace "the security services on the message are processed" with "the security services or compression on the message are processed"
    7. Para 3.5, Step 1: Replace "to be enveloped" with "to be compressed".
  11. Para 3.7, Step 3: Add period to end of sentence.
  12. Annex F, Remove prior to submission to IESG (?)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i222jqlQ069667; Mon, 1 Mar 2004 18:45:52 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i222jpUw069666; Mon, 1 Mar 2004 18:45:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.11/8.12.8) with SMTP id i222jo3u069660 for ; Mon, 1 Mar 2004 18:45:51 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@218.37.226.73 with plain) by smtp001.bizmail.yahoo.com with SMTP; 2 Mar 2004 02:45:56 -0000 Message-ID: <4044B9EF.5090401@ieca.com> Date: Tue, 02 Mar 2004 11:44:31 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Blake Ramsdell CC: ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2632bis-05.txt References: In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments:
  1. Para 1, 2nd sentence: Replace "MUST certify that the public" with "MUST verify that the public".
  2. Para 1.1, ASN.1 references- Why do these point to X.680-680 while the 2633bis ASN.1 references point to X.208-209. Shouldn't they point to the same thing?
  3. Para 1.1, Certificate definition: Replace "binds an entity's distinguished name" with "binds an entity's name".
  4. Para 2.3, 5th para,  Can add a pointer to the path building ID/RFC from PKIX?
  5. Para 2.3, 5th para 2nd sentence, Replace "Other methods of building certificate chains may be supported" with "Other methods of building certificate chains MAY be supported"
  6. Para 5: I'd like to add a security consideration about why it might not be good to send CRLs: "CRLs sent with the message impose concern when the signer's certificate is revoked, but the signer purposely includes a valid CRL but not the most recent CRL without the signer's serialNumber thereby providing a false verification". (or something like that)
  7. Para 5: The last 4 reasons for a signature and certificate checking to fail are may not be true if the sig/cert is checked at some future date after an initial check. Should we add a note to indicate that if the signature or certificate is verified at some later date they should be considered "valid" even though one of the four things occurred?
Cheers,

spt
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i222ZbZ8069072; Mon, 1 Mar 2004 18:35:37 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i222Zb0Y069070; Mon, 1 Mar 2004 18:35:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i222ZaKx069063 for ; Mon, 1 Mar 2004 18:35:36 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 12435 invoked by uid 0); 2 Mar 2004 02:32:09 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 2 Mar 2004 02:32:09 -0000 Message-Id: <5.2.0.9.2.20040301212939.04509890@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 01 Mar 2004 21:35:37 -0500 To: shollenbeck@verisign.com, turners@ieca.com From: Russ Housley Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Cc: blake@brutesquadlabs.com, ietf-smime@imc.org In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF02BF9A93@vsvapostal8.vcorp .ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My understanding of the MIME registration is that ZLIB is really used. Russ At 09:05 PM 3/1/2004 -0500, Hollenbeck, Scott wrote: > > If an implementation chooses to support compression, then > > the implementation MUST support the ZLIB compression > > algorithm. > > > > Russ > >Something to consider: ZLIB (RFC 1950) and DEFLATE (RFC 1951) are NOT the >same thing. I ran into a small bit of specification confusion (thankfully >caught by Ned Freed) when my TLS compression draft went through IESG review. >It might be worth noting Ned's comments so that rfc2633bis specifies the >algorithm you intend: > >"First of all, it is important to realize that RFC 1950 and RFC 1951 specify >two things: (1) A compression scheme and corresponding format called DEFLATE >(1951) and (2) A general wrapper format for compressed data called ZLIB >(1950). >I believe most compression applications simply use the DEFLATE format and >don't >bother with the extra wrapper and most of our specifications that do this >refer to deflate and RFC 1951 rather than zlib and RFC 1950. > >This document doesn't follow this approach. Rather, it repeatedly calls >the compression scheme ZLIB and refers to both of the RFCs. Does this mean >this specification actually uses the zlib wrapper? I suspect the answer >is no, and if that's indeed the case, the document needs to be clarified >in this regard. I suggest referring to the scheme as DEFLATE and removing >the reference to RFC 1950 entirely. > >If, on the other hand, the intent really is to use the zlib wrapper, then >the specification is incomplete in that ZLIB allows for multiple compression >algorithms, checksumming, and so forth. These various settings would need to >be specified in order to have interoperable ZLIB implementations." > >-Scott- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2220Zvb066590; Mon, 1 Mar 2004 18:00:35 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2220ZTe066586; Mon, 1 Mar 2004 18:00:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from falcon.verisign.com (falcon.verisign.com [216.168.239.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2220Xnk066578 for ; Mon, 1 Mar 2004 18:00:34 -0800 (PST) (envelope-from shollenbeck@verisign.com) Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id i2221uop002377; Mon, 1 Mar 2004 21:01:56 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Mar 2004 21:00:36 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF02BF9A93@vsvapostal8.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "'Russ Housley'" , "'Sean P. Turner'" Cc: "'Blake Ramsdell'" , "'ietf-smime@imc.org'" Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Date: Mon, 1 Mar 2004 21:05:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If an implementation chooses to support compression, then > the implementation MUST support the ZLIB compression > algorithm. > > Russ Something to consider: ZLIB (RFC 1950) and DEFLATE (RFC 1951) are NOT the same thing. I ran into a small bit of specification confusion (thankfully caught by Ned Freed) when my TLS compression draft went through IESG review. It might be worth noting Ned's comments so that rfc2633bis specifies the algorithm you intend: "First of all, it is important to realize that RFC 1950 and RFC 1951 specify two things: (1) A compression scheme and corresponding format called DEFLATE (1951) and (2) A general wrapper format for compressed data called ZLIB (1950). I believe most compression applications simply use the DEFLATE format and don't bother with the extra wrapper and most of our specifications that do this refer to deflate and RFC 1951 rather than zlib and RFC 1950. This document doesn't follow this approach. Rather, it repeatedly calls the compression scheme ZLIB and refers to both of the RFCs. Does this mean this specification actually uses the zlib wrapper? I suspect the answer is no, and if that's indeed the case, the document needs to be clarified in this regard. I suggest referring to the scheme as DEFLATE and removing the reference to RFC 1950 entirely. If, on the other hand, the intent really is to use the zlib wrapper, then the specification is incomplete in that ZLIB allows for multiple compression algorithms, checksumming, and so forth. These various settings would need to be specified in order to have interoperable ZLIB implementations." -Scott- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220u62J061928; Mon, 1 Mar 2004 16:56:06 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i220u6te061927; Mon, 1 Mar 2004 16:56:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i220u5ts061921 for ; Mon, 1 Mar 2004 16:56:05 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 23464 invoked by uid 0); 2 Mar 2004 00:52:38 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (218.37.227.193) by woodstock.binhost.com with SMTP; 2 Mar 2004 00:52:38 -0000 Message-Id: <5.2.0.9.2.20040301194955.02017f78@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 01 Mar 2004 19:56:05 -0500 To: "Sean P. Turner" From: Russ Housley Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt Cc: Blake Ramsdell , ietf-smime@imc.org In-Reply-To: <40449AEB.8060109@ieca.com> References: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean: >For #4 ZLIB compression algorithm from RFC1950/1951 is a MUST in the >RFC3274 do we need to say it again here? Yes. The decision of the S/MIME WG more than a year ago was to put all of the mandatory to implement algorithms in this document. In this case, we need to say: If an implementation chooses to support compression, then the implementation MUST support the ZLIB compression algorithm. Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i220XYAc060155; Mon, 1 Mar 2004 16:33:34 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i220XYVO060154; Mon, 1 Mar 2004 16:33:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by above.proper.com (8.12.11/8.12.8) with SMTP id i220XV8j060145 for ; Mon, 1 Mar 2004 16:33:33 -0800 (PST) (envelope-from turners@ieca.com) Received: from unknown (HELO ieca.com) (turners@ieca.com@218.37.226.73 with plain) by smtp003.bizmail.yahoo.com with SMTP; 2 Mar 2004 00:33:36 -0000 Message-ID: <40449AEB.8060109@ieca.com> Date: Tue, 02 Mar 2004 09:32:11 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ Housley CC: Blake Ramsdell , ietf-smime@imc.org Subject: Re: WG LAST CALL: draft-ietf-smime-rfc2633bis-07.txt References: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> In-Reply-To: <5.2.0.9.2.20040229235313.01f8f318@mail.binhost.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, For #4 ZLIB compression algorithm from RFC1950/1951 is a MUST in the RFC3274 do we need to say it again here? spt Russ Housley wrote: > > Hare are seven comments. I think number 6 is the most significant > one, but none of them are show stoppers. > > 1. Should Section 1.4 reference RFC 3369? > > 2. Delete section 1.6 before the document is sent to the IESG. > > 3. Section 2.4 probably should point out that ContentInfo is needed > to encapsulate each of the protection content types. > > 4. What compression algorithm MUST be implemented if CompressedData > is supported? > > 5. Section 2.5.2: s/SMIMECapabilities attribute > should/SMIMECapabilities attribute SHOULD/ > > 6. Section 2.6: the first two paragraphs are not clear. S/MIME v3.1 > MUST support both issuerAndSerialNumber and subjectKeyIdentifier for > sending and receiving. > > 7. Section 3.4.3.2: s/not currently supported in S/MIME/not currently > recommended in S/MIME/ > > Russ >