From owner-ietf-smime@mail.imc.org Thu May 1 08:21:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06609 for ; Thu, 1 May 2003 08:21:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Bpli2054877 for ; Thu, 1 May 2003 04:51:47 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41BpjaP054876 for ietf-smime-bks; Thu, 1 May 2003 04:51:45 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41Bpii2054871 for ; Thu, 1 May 2003 04:51:45 -0700 (PDT) (envelope-from nsyracus@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 HAA05751; Thu, 1 May 2003 07:48:51 -0400 (EDT) Message-Id: <200305011148.HAA05751@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-pss-01.txt Date: Thu, 01 May 2003 07:48:51 -0400 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 : Use of the PSS Signature Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-pss-01.txt Pages : 5 Date : 2003-4-30 This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signature algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-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-pss-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-pss-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: <2003-4-30150852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-pss-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-pss-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-30150852.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Thu May 1 16:29:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09071 for ; Thu, 1 May 2003 16:29:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JSZi2076978 for ; Thu, 1 May 2003 12:28:35 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41JSZe9076977 for ietf-smime-bks; Thu, 1 May 2003 12:28:35 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41JSYi2076971 for ; Thu, 1 May 2003 12:28:34 -0700 (PDT) (envelope-from nsyracus@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 PAA02662; Thu, 1 May 2003 15:25:26 -0400 (EDT) Message-Id: <200305011925.PAA02662@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-x400wrap-06.txt Date: Thu, 01 May 2003 15:25:26 -0400 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 : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-06.txt Pages : 11 Date : 2003-5-1 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-06.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-x400wrap-06.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-x400wrap-06.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: <2003-5-1153636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153636.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Thu May 1 16:30:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09176 for ; Thu, 1 May 2003 16:30:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JvJi2077755 for ; Thu, 1 May 2003 12:57:19 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41JvJpi077754 for ietf-smime-bks; Thu, 1 May 2003 12:57:19 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41JvIi2077747 for ; Thu, 1 May 2003 12:57:18 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Thu, 1 May 2003 12:57:15 -0700 From: "Blake Ramsdell" To: "'Jim Schaad'" , Subject: Small comments on pss-01 Date: Thu, 1 May 2003 12:57:15 -0700 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.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In pss-01, I believe that draft-jonsson-pkcs1-v2dot1-00.txt has been released as RFC3447, so the reference "P1v2.1" probably needs updating. Also, the SHA2 normative reference is not used -- it may need to be moved to Informational References or removed completely. I remember some discussion about this at one point, but are we using X.208 and X.209 for references to ASN.1 / BER / DER instead of X.680 and X.690? If not, then these may need updating. Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Thu May 1 16:31:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09253 for ; Thu, 1 May 2003 16:31:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JShi2076987 for ; Thu, 1 May 2003 12:28:43 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41JShvb076986 for ietf-smime-bks; Thu, 1 May 2003 12:28:43 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41JSfi2076981 for ; Thu, 1 May 2003 12:28:41 -0700 (PDT) (envelope-from nsyracus@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 PAA02680; Thu, 1 May 2003 15:25:33 -0400 (EDT) Message-Id: <200305011925.PAA02680@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-x400transport-06.txt Date: Thu, 01 May 2003 15:25:32 -0400 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 : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-06.txt Pages : 0 Date : 2003-5-1 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-06.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-x400transport-06.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-x400transport-06.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: <2003-5-1153646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153646.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Thu May 1 17:22:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11798 for ; Thu, 1 May 2003 17:22:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Ktbi2079869 for ; Thu, 1 May 2003 13:55:37 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41KtbDv079868 for ietf-smime-bks; Thu, 1 May 2003 13:55:37 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41Ktai2079863 for ; Thu, 1 May 2003 13:55:36 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id AE2796A4DA for ; Thu, 1 May 2003 13:55:37 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "Ietf-Smime" Subject: PSS Document Question Date: Thu, 1 May 2003 13:55:36 -0700 Message-ID: <003b01c31024$04d83090$1700a8c0@soaringhawk.net> 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 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have had a private mail that requested the following: > In section 3, you say: > > digestAlgorithms SHOULD contain the one-way hash function used to > compute the message digest on the eContent value. > > I would rather this be a MUST! My reply was that this would impose a new behavior on the CMS document where this behavior is a SHOULD not a MUST. The reply to this was to ask me to take it to the list as a question of wheither the CMS document is too lienant on this issue. HERE IS MY TAKE! 1. Presence of a digest algorithm is not techincally needed to successfully validate a signature. The one that is needed is in the SignerInfo structure. 2. My implementations of CMS WILL FAIL if the digest algorithm is not present in this field. I have a stream based implementation of signature processing that requires the digest algorithm to be known prior to starting to process the content. (I have a fall back of adding SHA-1 if the field is empty.) This is permitted behavior under CMS. 3. I do not know of anybody who delibrately omits putting this into the message. I would be happy with changing this from a SHOULD to a MUST, but if this is done it needs to propigate all of the way back to CMS. Jim From owner-ietf-smime@mail.imc.org Thu May 1 17:48:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13324 for ; Thu, 1 May 2003 17:48:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LUdi2080890 for ; Thu, 1 May 2003 14:30:39 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41LUd9W080889 for ietf-smime-bks; Thu, 1 May 2003 14:30:39 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41LUci2080883 for ; Thu, 1 May 2003 14:30:38 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 843AB6A505; Thu, 1 May 2003 14:11:12 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , Subject: RE: Small comments on pss-01 Date: Thu, 1 May 2003 14:30:38 -0700 Message-ID: <003c01c31028$e936e110$1700a8c0@soaringhawk.net> 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: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Blake, We are still using the X.208/X.209 references for ASN.1/BER since we have never gone beyond using 1988 syntax. (Note that the DER reference is either X509-88 or X.660.) jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Blake Ramsdell > Sent: Thursday, May 01, 2003 12:57 PM > To: 'Jim Schaad'; ietf-smime@imc.org > Subject: Small comments on pss-01 > > > > In pss-01, I believe that draft-jonsson-pkcs1-v2dot1-00.txt > has been released as RFC3447, so the reference "P1v2.1" > probably needs updating. > > Also, the SHA2 normative reference is not used -- it may need > to be moved to Informational References or removed completely. > > I remember some discussion about this at one point, but are > we using X.208 and X.209 for references to ASN.1 / BER / DER > instead of X.680 and X.690? If not, then these may need updating. > > Blake > -- > Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com > From owner-ietf-smime@mail.imc.org Thu May 1 20:29:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19985 for ; Thu, 1 May 2003 20:29:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42053i2085499 for ; Thu, 1 May 2003 17:05:03 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h42053lW085498 for ietf-smime-bks; Thu, 1 May 2003 17:05:03 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h42052i2085489 for ; Thu, 1 May 2003 17:05:02 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Thu, 1 May 2003 17:04:58 -0700 From: "Blake Ramsdell" To: Subject: RE: Small comments on pss-01 Date: Thu, 1 May 2003 17:04:58 -0700 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 In-Reply-To: <003c01c31028$e936e110$1700a8c0@soaringhawk.net> 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: Content-Transfer-Encoding: 7bit (List removed) > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Thursday, May 01, 2003 2:31 PM > To: 'Blake Ramsdell'; ietf-smime@imc.org > Subject: RE: Small comments on pss-01 > > We are still using the X.208/X.209 references for ASN.1/BER since we > have never gone beyond using 1988 syntax. (Note that the DER > reference > is either X509-88 or X.660.) Just so we're on the same page, the title of X.660 is "Procedures for the operation of OSI Registration Authorities: General procedures", and the title of X.690 is "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)". I've been using X.690 for all of my DER research, but I could be nutty. Blake From owner-ietf-smime@mail.imc.org Fri May 2 06:14:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10496 for ; Fri, 2 May 2003 06:14:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h429kDi2028284 for ; Fri, 2 May 2003 02:46:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h429kDxp028283 for ietf-smime-bks; Fri, 2 May 2003 02:46:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from vercetti.clearswift.com (shannon.clearswift.com [194.205.99.125] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h429kBi2028276 for ; Fri, 2 May 2003 02:46:12 -0700 (PDT) (envelope-from Jim.Craigie@clearswift.com) Received: from uk-msw-1.mimesweeper.com (mail.mimesweeper.com [10.44.30.35] (may be forged)) by vercetti.clearswift.com (4.9.4.16) with ESMTP id for ; Fri, 02 May 2003 10:47:49 +0100 Received: from orange.clearswift.com (unverified [10.44.30.11]) by uk-msw-1.mimesweeper.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 2 May 2003 10:46:03 +0100 Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.clearswift.com (Route400-RFCGate); Fri, 2 May 2003 10:57:30 +0100 X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 2 May 2003 10:57:30 +0100 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Fri, 2 May 2003 10:56:46 +0100 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:00b9-030502105646-000b] X400-Content-Type: P2-1988 (22) X400-Originator: Jim.Craigie@clearswift.com Original-Encoded-Information-Types: IA5-Text X400-Recipients: ietf-smime@imc.org Date: Fri, 2 May 2003 10:56:46 +0100 X400-Content-Identifier: Re: I-D ACTION:d Message-Id: <"CASQUETS:0f08-030502104232-002b*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS> From: Jim Craigie To: ietf-smime@imc.org In-Reply-To: <200305011925.PAA02662@ietf.org> Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-06.txt Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When is this going to become an RFC? Why the delay? > 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 : Securing X.400 Content with S/MIME > Author(s) : P. Hoffman, C. Bonatti, A. Eggen > Filename : draft-ietf-smime-x400wrap-06.txt > Pages : 11 > Date : 2003-5-1 > > This document describes a protocol for adding cryptographic signature > and encryption services to X.400 content. > --------------------------------------------------------------------------------------------------------------- Clearswift monitors, controls and protects all its messaging traffic in compliance with its corporate email policy using Clearswift products. Find out more about Clearswift, its solutions and services at www.clearswift.com. *********************************************************************************** This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift. If you have received this communication in error, please notify Clearswift by emailing support@clearswift.com quoting the sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain. This footnote confirms that this email message has been swept by MIMEsweeper for Content Security threats, including computer viruses. From owner-ietf-smime@mail.imc.org Fri May 2 16:51:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02178 for ; Fri, 2 May 2003 16:51:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42KI2i2065194 for ; Fri, 2 May 2003 13:18:02 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h42KI2jq065193 for ietf-smime-bks; Fri, 2 May 2003 13:18:02 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h42KI1i2065180 for ; Fri, 2 May 2003 13:18:01 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Fri, 2 May 2003 13:17:57 -0700 From: "Blake Ramsdell" To: "'Jim Craigie'" , Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-06.txt Date: Fri, 2 May 2003 13:17:57 -0700 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 In-Reply-To: <"CASQUETS:0f08-030502104232-002b*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS> 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: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Craigie > Sent: Friday, May 02, 2003 2:57 AM > To: ietf-smime@imc.org > Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-06.txt > > When is this going to become an RFC? Why the delay? There was an omission that was found after the working group finished it, so another version of the x400transport draft was required. The x400wrap and x400transport drafts are codependent, one can't progress without the other one to RFC status. It is not clear what the timeline is -- this depends on how fast the review of these documents goes, whether there's any more edits required, and then how backed up the RFC editor is. Russ will chime in if there's a better way to estimate the actual time. Blake From owner-ietf-smime@mail.imc.org Sun May 4 18:37:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08816 for ; Sun, 4 May 2003 18:37:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h44MBSi2028450 for ; Sun, 4 May 2003 15:11:28 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h44MBSHe028449 for ietf-smime-bks; Sun, 4 May 2003 15:11:28 -0700 (PDT) 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]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h44MBQi3028444; Sun, 4 May 2003 15:11:26 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 4 May 2003 15:11:21 -0700 To: ietf-smime@imc.org, ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Who has tried some or all of the S/MIME examples? 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. The WG chairs have announced that we are in the WG last call for draft-ietf-smime-examples-10.txt. As editor of the document, I'd like to find out who has looked at the examples in this particular draft and/or tried them out? If you have done so, could you send a list of the examples you have reviewed and a short description of how you reviewed them? You can send it to me personally, or to the two lists. Please post even if you have seen other people post about the same examples: we want to know how deep our coverage is. Thanks! --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@mail.imc.org Mon May 5 19:18:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21251 for ; Mon, 5 May 2003 19:18:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Mo1i2013048 for ; Mon, 5 May 2003 15:50:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45Mo1OM013047 for ietf-smime-bks; Mon, 5 May 2003 15:50:01 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h45Mnxi2013037 for ; Mon, 5 May 2003 15:50:00 -0700 (PDT) (envelope-from jhargest@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 SAA20468; Mon, 5 May 2003 18:46:49 -0400 (EDT) Message-Id: <200305052246.SAA20468@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Use of the Camellia Encryption Algorithm in CMS to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 05 May 2003 18:46:49 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the Camellia Encryption Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-19. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-camellia-03.txt From owner-ietf-smime@mail.imc.org Mon May 5 20:27:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22437 for ; Mon, 5 May 2003 20:27:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4601hi2015258 for ; Mon, 5 May 2003 17:01:43 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4601hUO015257 for ietf-smime-bks; Mon, 5 May 2003 17:01:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4601gi2015248 for ; Mon, 5 May 2003 17:01:42 -0700 (PDT) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (12-208-8-45.client.attbi.com [12.208.8.45]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEF00MJKUQQIU@mtaout01.icomcast.net> for ietf-smime@imc.org; Mon, 05 May 2003 20:01:39 -0400 (EDT) Date: Mon, 05 May 2003 17:01:40 -0700 From: Trevor Perrin Subject: authenticated encryption X-Sender: trevp00@pop.comcast.net To: ietf-smime@imc.org Message-id: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 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 Hello S/MIME, I'm curious what this group thinks about adopting an authenticated-encryption cipher mode, such as: EAX: https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00223.html CWC: https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00224.html Such a mode could integrity-protect S/MIME encrypted-only messages. It could also defend against an oracle attack on signed-then-CBC-encrypted messages. I'm not sure this attack is well known, so I'll describe it: If the plaintext is a sequence of blocks P[1],P[2],.., and the ciphertext is a sequence of blocks where C[0] is the IV, followed by C[1],C[2],.., then we assume the attacker wants to verify a guess G for P[X], and knows the value of P[1] (the first blocksize bytes of the ContentInfo containing SignedData, which is just well-known ASN.1 header). The attacker copies C[X] over C[1], and sets C[0] = G xor C[X-1] xor P[1]. If his guess is correct, then the new ciphertext C[1] will decrypt to the same plaintext P[1] it would have without his modifications - if his guess if wrong, the decrypted P[1] will have bit errors, which will probably cause an error in the recipient's software. If the recipient is a person, she might respond saying "I can't read this". If the recipient is a server (like an S/MIME MTA), it might respond with an error message, allowing the attack to be iterated. Might solving these issues in one swoop be a good rationale for authenticated encryption? Trevor From owner-ietf-smime@mail.imc.org Tue May 6 02:32:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09674 for ; Tue, 6 May 2003 02:32:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46630i2024884 for ; Mon, 5 May 2003 23:03:00 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46630D1024883 for ietf-smime-bks; Mon, 5 May 2003 23:03:00 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h4662xi2024873 for ; Mon, 5 May 2003 23:02:59 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Mon, 5 May 2003 23:02:57 -0700 From: "Blake Ramsdell" To: , "'Ietf-Smime'" Subject: RE: PSS Document Question Date: Mon, 5 May 2003 23:02:57 -0700 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 In-Reply-To: <003b01c31024$04d83090$1700a8c0@soaringhawk.net> 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: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad > Sent: Thursday, May 01, 2003 1:56 PM > To: Ietf-Smime > Subject: PSS Document Question > > I would be happy with changing this from a SHOULD to a MUST, > but if this > is done it needs to propigate all of the way back to CMS. In the case of digestAlgorithms, the current language in CMS says that there MAY be any number of elements in the collection, but does not make any statement as far as MAY/MUST/SHOULD for whether or not these should map to the algorithms used for the signers ("The collection is intended to list the message digest algorithms employed by all of the signers, in any order, to facilitate one-pass signature verification"). Therefore, if you make it a MUST, I don't think you're overriding anything in CMS, only clarifying something that is unspecified. Your MUST wouldn't violate the "[t]here MAY be any number of elements in the collection, including zero" which is the only thing in CMS I found that talks about this. Anecdotally, my current S/MIME implementation ignores digestAlgorithms, since I'm using Java's security providers, and as far as I can tell there isn't a way to present just the completed digest and public key to the signature verification process -- you have to provide the *content* and public key (which might have parameters scattered up and down the cert chain, so you'd better make a cert chain while you're at it), and Java does the digesting internally as part of the signature verification. Sigh. So I ignore digestAlgorithms completely, since I can't use them, and just tough it out and do two passes. Personally, I consider "best current CMS practice" to be to always digest with every algorithm you know about and might reasonably encounter (so, digest with SHA-1, and if you're feeling saucy, digest with MD5 also), and ignore digestAlgorithms completely. For that matter, I feel this way about most informational fields that aren't tied directly to algorithm use (such as the "smime-type" parameter for S/MIME) -- ignore 'em and pretend like the guy that made 'em is probably lying anyway. It's just one less AlgorithmIdentifier to parse the wrong OID or parameters out of. So even if you made this a MUST, I'm not sure anyone should care, since the digestAlgorithm wording is so soft that the field does not have value. Blake From owner-ietf-smime@mail.imc.org Tue May 6 07:19:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14555 for ; Tue, 6 May 2003 07:19:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46AiNi2063228 for ; Tue, 6 May 2003 03:44:23 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46AiNwS063227 for ietf-smime-bks; Tue, 6 May 2003 03:44:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46AiLi2063218; Tue, 6 May 2003 03:44:21 -0700 (PDT) (envelope-from arun.pandey@digital.com) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 30BA51E6A; Tue, 6 May 2003 06:44:21 -0400 (EDT) Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 69E901651; Tue, 6 May 2003 05:44:18 -0500 (CDT) Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 May 2003 16:18:26 +0530 Message-ID: <177E503C4DA3D311BC9D0008C791C3060F3828F5@diexch01.xko.dec.com> From: "Pandey, Arun" To: "'phoffman@imc.org'" , "'bonattic@ieca.com'" Cc: ietf-smime@imc.org Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-06.txt : Comments Date: Tue, 6 May 2003 16:18:18 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313BD.0494FB08" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C313BD.0494FB08 Content-Type: text/plain; charset="iso-8859-1" Hi, 1) In the draft-ietf-smime-x400transport-06.txt the contents of Section 2.2.1 are mere copy of Section 2.2. The Section heading of 2.2.1. is "Carrying Plaintext MIME objects as X.400 Content", whereas the content in the section is about "Carrying CMS object as X.400 Content". Could this please be corrected. 2) In section 2.3 "Carrying S/MIME as IPMS Body Parts", in the following sentence 'id-ep-content' should be replaced by 'id-et-content': The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-ep-content value and the following CMS-defined value. i.e. it should be: The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-et-content value and the following CMS-defined value. Best Regards Arun Pandey ------_=_NextPart_001_01C313BD.0494FB08 Content-Type: text/html; charset="iso-8859-1" RE: I-D ACTION:draft-ietf-smime-x400transport-06.txt : Comments

Hi,

1) In the draft-ietf-smime-x400transport-06.txt the contents of Section 2.2.1 are
   mere copy of Section 2.2. The Section heading of 2.2.1. is "Carrying Plaintext
   MIME objects as X.400 Content", whereas the content in the section is about
   "Carrying CMS object as X.400 Content". Could this please be corrected.

2) In section 2.3 "Carrying S/MIME as IPMS Body Parts", in the following
   sentence 'id-ep-content' should be replaced by 'id-et-content':

   The direct-reference field of the body part MUST include the OID formed by the
   concatenation of the id-ep-content value and the following CMS-defined value.

   i.e. it should be:
   The direct-reference field of the body part MUST include the OID formed by the
   concatenation of the id-et-content value and the following CMS-defined value.

Best Regards
Arun Pandey

------_=_NextPart_001_01C313BD.0494FB08-- From owner-ietf-smime@mail.imc.org Tue May 6 10:23:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24168 for ; Tue, 6 May 2003 10:23:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Do4i2076987 for ; Tue, 6 May 2003 06:50:04 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46Do4uv076986 for ietf-smime-bks; Tue, 6 May 2003 06:50:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mr3.ash.ops.us.uu.net (mr3.ash.ops.us.uu.net [198.5.241.88]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Do3i2076975; Tue, 6 May 2003 06:50:03 -0700 (PDT) (envelope-from BonattiC@ieca.com) Received: from OMNI by mr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust2.tnt14.mia5.da.uu.net [65.229.95.2]) id QQonnb24015; Tue, 6 May 2003 13:50:00 GMT Reply-To: From: "Bonatti, Chris" To: "'Pandey, Arun'" Cc: , Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-06.txt : Comments Date: Tue, 6 May 2003 09:49:58 -0400 Organization: IECA, Inc. Message-ID: <003e01c313d6$646beeb0$025fe541@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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <177E503C4DA3D311BC9D0008C791C3060F3828F5@diexch01.xko.dec.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h46Do4i2076979 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Arun, You seem to be correct on both counts. I will try to correct and repost. If anybody thinks this isn't correct, please don't be shy. Chris -----Original Message----- From: Pandey, Arun [mailto:arun.pandey@digital.com] Sent: Tuesday, May 06, 2003 06:48 To: 'phoffman@imc.org'; 'bonattic@ieca.com' Cc: ietf-smime@imc.org Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-06.txt : Comments Hi, 1) In the draft-ietf-smime-x400transport-06.txt the contents of Section 2.2.1 are mere copy of Section 2.2. The Section heading of 2.2.1. is "Carrying Plaintext MIME objects as X.400 Content", whereas the content in the section is about "Carrying CMS object as X.400 Content". Could this please be corrected. 2) In section 2.3 "Carrying S/MIME as IPMS Body Parts", in the following sentence 'id-ep-content' should be replaced by 'id-et-content': The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-ep-content value and the following CMS-defined value. i.e. it should be: The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-et-content value and the following CMS-defined value. Best Regards Arun Pandey From owner-ietf-smime@mail.imc.org Tue May 6 15:05:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03561 for ; Tue, 6 May 2003 15:05:22 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46IKKi2095361 for ; Tue, 6 May 2003 11:20:20 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46IKK4H095360 for ietf-smime-bks; Tue, 6 May 2003 11:20:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from gghqex3.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46IKJi2095353; Tue, 6 May 2003 11:20:19 -0700 (PDT) (envelope-from John.Pawling@DigitalNet.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Who has tried some or all of the S/MIME examples? Date: Tue, 6 May 2003 14:20:17 -0400 Message-ID: Thread-Topic: Who has tried some or all of the S/MIME examples? Thread-Index: AcMSi+RnwRWdtOZ8Ssy0yoLY7e4+KgBb7p0Q From: "Pawling, John" To: "Paul Hoffman / IMC" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h46IKKi3095354 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Paul, DigitalNet has used the S/MIME Freeware Library (SFL) (and underlying libraries) to successfully process the vast majority of the examples in the draft-ietf-smime-examples-10.txt. This message includes the notes regarding our testing. We will send you corrected examples for sections 11.1 and 11.2. Test Results for S/MIME Examples-10: These tests were executed by DigitalNet using the S/MIME Freeware Library (SFL) and underlying libraries. Point of contact is Bob Colestock, Robert.Colestock@DigitalNet.com. (Note: Test numbers correspond to Examples-10 section numbers.) 4. ContentInfo Tests 4.1 ContentInfo with Data type, BER: Successfully ASN.1 decoded the BER-encoded ContentInfo sample in Examples document, but SFL can only create DER-encoded ContentInfo objects because the Enhanced SNACC library always uses DER to ASN.1 encode objects. 4.2 ContentInfo with Data type, DER: Successfully decoded sample in Examples document using SFL. 5. SignedData Tests 5.1 Basic signed content, DSS: Successfully verified signature of sample in Examples document using SFL. 5.2 Basic signed content, RSA: Successfully verified signature of sample in Examples document using SFL. 5.3 Basic signed content, detached content: Successfully verified signature of sample in Examples document using SFL. 5.4 Fancier signed content, Signed content with signed/unsigned attributes: Successfully verified signature of sample in Examples document using SFL. 5.5 All RSA signed message: Successfully verified signature of sample in Examples document using SFL. 5.6 Multiple DSS signatures: Successfully verified all of the signatures in the sample in the Examples document. 5.7 Signing using SKI: Successfully verified signature of sample in Examples document using SFL. 5.8 S/MIME multipart/signed message: Successfully verified signature of sample in Examples document using SFL. 5.9 S/MIME application/pkcs7-mime signed message: Successfully verified signature of sample in Examples document using SFL. 5.10 SignedData With Attributes: Successfully verified signature of sample in Examples document. 5.11 SignedData with Certificates Only: Successfully verified that there were no SignerInfos that were present or verified in the sample in the Examples document. 6. Enveloped-data Tests 6.1. Basic encrypted content, TripleDES and DH: Successfully used SFL to process this envelopedData sample. 6.2. Basic encrypted content, TripleDES and RSA: Successfully decrypted sample in Examples document using SFL. 6.3. Basic encrypted content, RC2/40 and RSA: Successfully decrypted sample in Examples document using SFL. 6.4. Encrypted content, two recipients, no shared keying material: Successfully used SFL to process the envelopedData sample. NOTE: Unsuccessful Invalid tag for privateKeyInfo for second login 6.5. Encrypted content, two recipients, shared keying material: Was unable to use the SFL to process the envelopedData sample because of an SFL bug related to processing shared UKMs. SFL will be fixed to be able to successfully process this message as it has in the past. 6.6. Encrypted content, TripleDES and DH, previously-distributed keys: Used SFL to successfully process the envelopedData sample. 6.7. Encrypted content, RC2/40 and RSA, previously-distributed keys: Used SFL to successfully process the envelopedData sample. 6.8. S/MIME application/pkcs7-mime encrypted message: Successfully used SFL to process the envelopedData sample. 6.9. EnvelopedData with All Recipient Types: Successfully used SFL to process the envelopedData sample for all recipient types KARI, KTRI, and KEKRI. 6.10. EnvelopedData with KARI RC2 Encryption: Successfully used SFL to process the envelopedData sample. 6.11. EnvelopedData with KEK 3DES Encryption: Successfully used SFL to process the envelopedData sample. 7. DigestedData: SFL does not support. 8. Encrypted-Data Tests: 8.1. Simple EncryptedData: Successfully used SFL to process the encryptedData sample. 8.2. EncryptedData with unprotected attributes: Successfully used SFL to process the encryptedData sample. 9. Authenticated-Data: SFL does not support. 10. Key Wrapping: Tests conducted as part of EnvelopedData testing. 11. ESS Examples 11.1 ReceiptRequest: Used SFL to successfully process the signedData including a receiptRequest attribute. Note that the 11.2 signedReceipt is supposed to be in response to the 11.1 signedData receiptRequest, but the examples-10 samples are incorrect. DigitalNet will provide new samples for 11.1 and 11.2 that are correct. 11.2 Receipt: Used SFL to successfully process the signedData including a receipt content type. NOTE - Unsuccessful - no match in signer info error 11.3 ESSSecurityLabel: Used SFL to successfully process the signedData including a ESSSecurityLabel signed attribute. 11.4 EquivalentLabels: Used SFL to successfully process the signedData including an EquivalentLabels signed attribute. 11.5 mlExpansionHistory: Used SFL to successfully process the signedData including an mlExpansionHistory signed attribute. 11.6 SigningCertificate: Used SFL to successfully process the signedData including a SigningCertificate signed attribute. ==================================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet (formerly Getronics Government Solutions) ====================================================   From owner-ietf-smime@mail.imc.org Tue May 6 15:08:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03907 for ; Tue, 6 May 2003 15:08:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46IWxi2095757 for ; Tue, 6 May 2003 11:32:59 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46IWxcP095756 for ietf-smime-bks; Tue, 6 May 2003 11:32:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46IWvi2095750 for ; Tue, 6 May 2003 11:32:57 -0700 (PDT) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (12-208-8-45.client.attbi.com [12.208.8.45]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HEH00JCLA5MM3@mtaout04.icomcast.net> for ietf-smime@imc.org; Tue, 06 May 2003 14:32:11 -0400 (EDT) Date: Tue, 06 May 2003 11:32:11 -0700 From: Trevor Perrin Subject: Re: authenticated encryption In-reply-to: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.net> X-Sender: trevp00@pop.comcast.net To: ietf-smime@imc.org Message-id: <5.2.0.9.0.20030506112623.02fe9c00@pop.comcast.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 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 At 05:01 PM 5/5/2003 -0700, Trevor Perrin wrote: >Hello S/MIME, > >I'm curious what this group thinks about adopting an >authenticated-encryption cipher mode, such as: > >EAX: >https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00223.html >CWC: >https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00224.html > >Such a mode could integrity-protect S/MIME encrypted-only messages. It >could also defend against an oracle attack on signed-then-CBC-encrypted >messages. I'm not sure this attack is well known, so I'll describe it: > >If the plaintext is a sequence of blocks P[1],P[2],.., and the ciphertext >is a sequence of blocks where C[0] is the IV, followed by C[1],C[2],.., >then we assume the attacker wants to verify a guess G for P[X], and knows >the value of P[1] (the first blocksize bytes of the ContentInfo containing >SignedData, which is just well-known ASN.1 header). > >The attacker copies C[X] over C[1], and sets C[0] = G xor C[X-1] xor >P[1]. If his guess is correct, then the new ciphertext C[1] will decrypt >to the same plaintext P[1] it would have without his modifications - if >his guess if wrong, the decrypted P[1] will have bit errors, which will >probably cause an error in the recipient's software. well, I got this wrong - whether the attacker's guess is right or wrong, P[2] will also be damaged. Whether the attacker can differentiate these failures, or other similar parsing failures he can induce by rearranging blocks (i.e. by copying C[X] over some other block besides C[1]), I suppose is implementation-dependent, or at least difficult to work out.. authenticated-encryption would at least remove any concerns on these lines. Trevor From owner-ietf-smime@mail.imc.org Tue May 6 20:56:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15922 for ; Tue, 6 May 2003 20:56:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h470Q7i2008931 for ; Tue, 6 May 2003 17:26:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h470Q7Jn008930 for ietf-smime-bks; Tue, 6 May 2003 17:26:07 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h470Q6i2008920; Tue, 6 May 2003 17:26:06 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Tue, 6 May 2003 17:26:03 -0700 From: "Blake Ramsdell" To: "'Paul Hoffman / IMC'" , , Subject: RE: Who has tried some or all of the S/MIME examples? Date: Tue, 6 May 2003 17:26:03 -0700 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 In-Reply-To: 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: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime-examples@mail.imc.org > [mailto:owner-ietf-smime-examples@mail.imc.org] On Behalf Of > Paul Hoffman / IMC > Sent: Sunday, May 04, 2003 3:11 PM > To: ietf-smime@imc.org; ietf-smime-examples@imc.org > Subject: Who has tried some or all of the S/MIME examples? > > Greetings again. The WG chairs have announced that we are in the WG > last call for draft-ietf-smime-examples-10.txt. As editor of the > document, I'd like to find out who has looked at the examples in this > particular draft and/or tried them out? If you have done so, could > you send a list of the examples you have reviewed and a short > description of how you reviewed them? You can send it to me > personally, or to the two lists. Please post even if you have seen > other people post about the same examples: we want to know how deep > our coverage is. Thanks! The files I have worked with: 5.1.bin -- Identified as a CMS SignedData with signatures and content, checked certificates were present, matched content to ExContent.bin, verified one signer 5.2.bin -- Checked certificates were present, matched content to ExContent.bin, verified one signer 5.3.bin -- Identified as a CMS SignedData with signatures and no content, checked certificates were present, verified one signer against external content in ExContent.bin 5.4.bin -- Extracted signing time attribute, checked certificates were present, checked CRLs were present, matched content to ExContent.bin, verified one signer 5.5.bin -- Checked certificates were present, matched content to ExContent.bin, verified one signer 5.6.bin -- Checked certificates were present, matched content to ExContent.bin, verified two signers 5.7.bin -- Checked certificates were present, matched content to ExContent.bin, verified one signer 5.8.eml -- Parsed content with MIME parser, matched extracted text content from text part to ExContent.bin, checked certificates were present, verified one signer against first part of message, identified as a CMS SignedData with signatures and no content 5.9.eml -- Parsed content with MIME parser, matched extracted text content from text part to ExContent.bin, checked certificates were present, verified one signer, identified as a CMS SignedData with signatures and content 5.10.bin -- Matched content to ExContent.bin, verified one signer 5.11.bin -- Identified as a CMS SignedData with no signatures and no content, checked certificates were present 6.2.bin -- Decrypted message, matched content to ExContent.bin, identified as a CMS EnvelopedData 6.3.bin -- Decrypted message, matched content to ExContent.bin 7.0.bin -- Verified hash, matched content to ExContent.bin 8.1.bin -- Decrypted data with given key, matched content to ExContent.bin I also worked with the following certificates and private keys: AliceDSSSignByCarlNoInherit.cer AlicePrivRSASign.pri AliceRSASignByCarl.cer BobPrivRSAEncrypt.pri BobRSASignByCarl.cer CarlDSSCRLForAll.crl CarlDSSSelf.cer CarlPrivDSSSign.pri CarlPrivRSASign.pri CarlRSASelf.cer DianeDHEncryptByCarl.cer DianeDSSSignByCarlInherit.cer DianePrivRSASignEncrypt.pri DianeRSASignByCarl.cer EricaDHEncryptByCarl.cer Blake From owner-ietf-smime@mail.imc.org Wed May 7 00:39:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20339 for ; Wed, 7 May 2003 00:39:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4743li2015136 for ; Tue, 6 May 2003 21:03:47 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4743ln4015135 for ietf-smime-bks; Tue, 6 May 2003 21:03:47 -0700 (PDT) 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 [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h4743hi2015125 for ; Tue, 6 May 2003 21:03:44 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 3502 invoked by uid 0); 7 May 2003 04:03:02 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (64.134.126.45) by woodstock.binhost.com with SMTP; 7 May 2003 04:03:02 -0000 Message-Id: <5.2.0.9.2.20030506133007.03243b90@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 May 2003 13:43:16 -0400 To: Trevor Perrin , ietf-smime@imc.org From: Russ Housley Subject: Re: authenticated encryption In-Reply-To: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.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: Presently, if you want integrity, then a signature is required, which defeats the attack that is described. I would be interested in looking into the use of CCM, EAX, CWC, or any other authenticated encryption mode AFTER the update to RFC 2633 is published. I would not like to delay publication of the update while this is investigated. Russ Security Area Director At 05:01 PM 5/5/2003 -0700, Trevor Perrin wrote: >Hello S/MIME, > >I'm curious what this group thinks about adopting an >authenticated-encryption cipher mode, such as: > >EAX: >https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00223.html >CWC: >https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00224.html > >Such a mode could integrity-protect S/MIME encrypted-only messages. It >could also defend against an oracle attack on signed-then-CBC-encrypted >messages. I'm not sure this attack is well known, so I'll describe it: > >If the plaintext is a sequence of blocks P[1],P[2],.., and the ciphertext >is a sequence of blocks where C[0] is the IV, followed by C[1],C[2],.., >then we assume the attacker wants to verify a guess G for P[X], and knows >the value of P[1] (the first blocksize bytes of the ContentInfo containing >SignedData, which is just well-known ASN.1 header). > >The attacker copies C[X] over C[1], and sets C[0] = G xor C[X-1] xor >P[1]. If his guess is correct, then the new ciphertext C[1] will decrypt >to the same plaintext P[1] it would have without his modifications - if >his guess if wrong, the decrypted P[1] will have bit errors, which will >probably cause an error in the recipient's software. > >If the recipient is a person, she might respond saying "I can't read >this". If the recipient is a server (like an S/MIME MTA), it might >respond with an error message, allowing the attack to be iterated. > >Might solving these issues in one swoop be a good rationale for >authenticated encryption? > >Trevor From owner-ietf-smime@mail.imc.org Wed May 7 17:48:33 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19027 for ; Wed, 7 May 2003 17:48:32 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47LCgi2001808 for ; Wed, 7 May 2003 14:12:42 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47LCgY6001807 for ietf-smime-bks; Wed, 7 May 2003 14:12:42 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h47LCdi2001787; Wed, 7 May 2003 14:12:39 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 2692A6D7C8; Wed, 7 May 2003 14:12:36 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , "'Paul Hoffman / IMC'" , , Subject: RE: Who has tried some or all of the S/MIME examples? Date: Wed, 7 May 2003 14:12:31 -0700 Message-ID: <000001c314dd$6404f400$1700a8c0@soaringhawk.net> 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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The files I have worked with so far: 4.1.bin - passed 4.2.bin - passed 5.1.bin - failed 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 5.2.bin - passed 5.4.bin - failed 1. Contains Alice's RSA certificate 2. No content hint unsigned attribute 3. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 5.5.bin - passed 5.6.bin - failed 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 5.7.bin - failed 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 5.10.bin - failed 1. Change "unknown OID" to "unknown OID (1.2.5555)" 2. Content Hint should have an OID of 1.2.840.113549.1.7.1 3. Content Identifier attribute absent 4. Contains Security Label attribute 5. Contains encrypt key preference attribute 6. Contains ML Expansion History attribute 7. Contains Equivalent Label attribute Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Blake Ramsdell > Sent: Tuesday, May 06, 2003 5:26 PM > To: 'Paul Hoffman / IMC'; ietf-smime@imc.org; > ietf-smime-examples@imc.org > Subject: RE: Who has tried some or all of the S/MIME examples? > > > > > -----Original Message----- > > From: owner-ietf-smime-examples@mail.imc.org > > [mailto:owner-ietf-smime-examples@mail.imc.org] On Behalf Of > > Paul Hoffman / IMC > > Sent: Sunday, May 04, 2003 3:11 PM > > To: ietf-smime@imc.org; ietf-smime-examples@imc.org > > Subject: Who has tried some or all of the S/MIME examples? > > > > Greetings again. The WG chairs have announced that we are in the WG > > last call for draft-ietf-smime-examples-10.txt. As editor of the > > document, I'd like to find out who has looked at the > examples in this > > particular draft and/or tried them out? If you have done so, could > > you send a list of the examples you have reviewed and a short > > description of how you reviewed them? You can send it to me > > personally, or to the two lists. Please post even if you have seen > > other people post about the same examples: we want to know how deep > > our coverage is. Thanks! > > The files I have worked with: > > 5.1.bin -- Identified as a CMS SignedData with signatures and > content, checked certificates were present, matched content > to ExContent.bin, verified one signer > > 5.2.bin -- Checked certificates were present, matched content > to ExContent.bin, verified one signer > > 5.3.bin -- Identified as a CMS SignedData with signatures and > no content, checked certificates were present, verified one > signer against external content in ExContent.bin > > 5.4.bin -- Extracted signing time attribute, checked > certificates were present, checked CRLs were present, matched > content to ExContent.bin, verified one signer > > 5.5.bin -- Checked certificates were present, matched content > to ExContent.bin, verified one signer > > 5.6.bin -- Checked certificates were present, matched content > to ExContent.bin, verified two signers > > 5.7.bin -- Checked certificates were present, matched content > to ExContent.bin, verified one signer > > 5.8.eml -- Parsed content with MIME parser, matched extracted > text content from text part to ExContent.bin, checked > certificates were present, verified one signer against first > part of message, identified as a CMS SignedData with > signatures and no content > > 5.9.eml -- Parsed content with MIME parser, matched extracted > text content from text part to ExContent.bin, checked > certificates were present, verified one signer, identified as > a CMS SignedData with signatures and content > > 5.10.bin -- Matched content to ExContent.bin, verified one signer > > 5.11.bin -- Identified as a CMS SignedData with no signatures > and no content, checked certificates were present > > 6.2.bin -- Decrypted message, matched content to > ExContent.bin, identified as a CMS EnvelopedData > > 6.3.bin -- Decrypted message, matched content to ExContent.bin > > 7.0.bin -- Verified hash, matched content to ExContent.bin > > 8.1.bin -- Decrypted data with given key, matched content to > ExContent.bin > > > I also worked with the following certificates and private keys: > > AliceDSSSignByCarlNoInherit.cer > AlicePrivRSASign.pri > AliceRSASignByCarl.cer > BobPrivRSAEncrypt.pri > BobRSASignByCarl.cer > CarlDSSCRLForAll.crl > CarlDSSSelf.cer > CarlPrivDSSSign.pri > CarlPrivRSASign.pri > CarlRSASelf.cer > DianeDHEncryptByCarl.cer > DianeDSSSignByCarlInherit.cer > DianePrivRSASignEncrypt.pri > DianeRSASignByCarl.cer > EricaDHEncryptByCarl.cer > > Blake > From jane_nicuopx@aol.com Wed May 7 19:06:46 2003 Received: from aol.com (cpe-024-092-076-046.midsouth.rr.com [24.92.76.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22077; Wed, 7 May 2003 19:06:42 -0400 (EDT) Message-ID: <001210d6aa38$bcb54333$38156450@ccbxbfb.ikg> From: "Jane Nicoli" To: , , , , , Subject: Got a new email address Date: Wed, 07 May 2003 15:02:33 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D8_76A36E1C.D3824B77" X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2462.0000 Importance: Normal ------=_NextPart_000_00D8_76A36E1C.D3824B77 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PEhUTUw+PEJPRFk+PEZPTlQgY29sb3I9IzRiNGI0Yj48cD4mbHQ7cmVwbGFj ZSZndDs8L3A+PFRBQkxFIHdpZHRoPSI3NSUiPjxUQk9EWT48VFI+ICAgIA0K PFREPjxGT05UIGNvbG9yPSNlODQ1MWIgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiIgDQogICAgICBzaXplPSsyPjxTVFJPTkc+V0FSTklO RzogPC9TVFJPTkc+PC9GT05UPjxGT05UIGNvbG9yPSMzNTZmODggDQogICAg ICBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSsy PjxTVFJPTkc+RG9uJ3QgYmUgZm9vbGVkIGJ5IA0KICAgICAgcHJvZHVjdHMg Y2xhaW1pbmcgdG8gYmUgIkhHSCIuPC9TVFJPTkc+PEJSPjwvRk9OVD48Rk9O VCBjb2xvcj0jMmMyYzJjIA0KICAgICAgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiI+PEJSPjxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5j b20vKmh0dHA6Ly93d3cuZS1tYWlsb2ZmZXJzLm5ldC9pbmRleC5odG0/MTI0 MzcyIj5QdXJlDQogICAgICBHSC1SZWxlYXNlcjwvYT4gY29udGFpbnMgDQog ICAgICA8L0ZPTlQ+PEZPTlQgY29sb3I9Izg4ODg4OCBmYWNlPSJBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4xMDAlIA0KICAgICAgbmF0dXJhbDwv Rk9OVD48Rk9OVCBjb2xvcj1ibGFjayBmYWNlPSJBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIj4gDQogICAgICA8L0ZPTlQ+PEZPTlQgY29sb3I9IzJj MmMyYyBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5ob21l b3BhdGhpYyANCiAgICAgIEhHSCBpbiBhbiBlYXN5IHRvIHN3YWxsb3cgY2Fw c3VsZSBmb3JtLiBDbGluaWNhbGx5LXByb3ZlbiB0bzxCPiBpbmNyZWFzZSAN CiAgICAgIElHRi0xIGJ5IGEgd2hvcHBpbmcgNDAyJSE8L0I+ICA8YSBocmVm PSJodHRwOi8vcmQueWFob28uY29tLypodHRwOi8vd3d3LmUtbWFpbG9mZmVy cy5uZXQvY2xpbmljYWwuaHRtPzEyNDM3MiI+Q2xpY2sgSGVyZTwvYT4gZm9y IHRoZSANCiAgICAgIGVudGlyZSBzdHVkeSE8QlI+PEJSPjxhIGhyZWY9Imh0 dHA6Ly9yZC55YWhvby5jb20vKmh0dHA6Ly93d3cuZS1tYWlsb2ZmZXJzLm5l dC9pbmRleC5odG0/MTI0MzcyIj5QdXJlDQogICAgICBHSC1SZWxlYXNlcjwv YT4gaXMgbm90IGEgU3RpbXVsYXRvciwgUmVwbGFjZXIsIFN0ZXJvaWQgb3Ig SG9ybW9uZS4gSXQgaXMgYSANCiAgICAgIDEwMCUgTmF0dXJhbCBHcm93dGgg SG9ybW9uZSBTZWNyZXRhZ29ndWUsIHdpdGggYSBuZXcgYWN0aXZlIEhvbWVv cGF0aGljIA0KICAgICAgSEdIIEVuaGFuY2VyIGluIGFuIGVhc3kgdG8gc3dh bGxvdyBjYXBzdWxlIGZvcm0uIEl0IGNhbiBiZSBhYnNvcmJlZCANCiAgICAg IGVmZmVjdGl2ZWx5IGJ5IHRoZSBib2R5IHRvIHJlYWN0aXZhdGUgeW91ciBE b3JtYW50IFBpdHVpdGFyeSBHbGFuZCBhbmQgDQogICAgICBnaXZlIGFuIEV4 dHJhIEJvb3N0IG9mIEhHSCBpbnRvIHRoZSBibG9vZCBzdHJlYW0gdG8gYmUg cGlja2VkIGJ5IHRoZSBsaXZlciANCiAgICAgIGZvciBjb252ZXJzaW9uIGlu dG8gSUdGIC0xLiBXaGljaCBiZWdpbnMgdG8gcmV2ZXJzZSB5b3VyIEFnaW5n IFByb2Nlc3MgYXQgDQogICAgICBhIG11Y2ggZmFzdGVyIHJhdGUuPC9GT05U PjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBiZ0NvbG9yPSNjZWNiOTk+ DQogICAgICA8VEFCTEUgYmdDb2xvcj0jZmZmZGQ1IGJvcmRlcj0wIGNlbGxQ YWRkaW5nPTEwIGNlbGxTcGFjaW5nPTAgDQogICAgICAgIHdpZHRoPSIxMDAl Ij48VEJPRFk+DQogICAgICAgIDxUUj4NCiAgICAgICAgICA8VEQ+PEZPTlQg Y29sb3I9I2ZmNjAwMCANCiAgICAgICAgICAgIGZhY2U9IkFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiPjxCPjxJPldoYXQgaXQgaXMgDQogICAgICAg ICAgICBub3Q6PEJSPjwvST48L0I+PC9GT05UPjxGT05UIGNvbG9yPSM1MTRm M2MgDQogICAgICAgICAgICBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmIiBzaXplPS0xPlB1cmUgR0gtUmVsZWFzZXI8Qj4gZG9lcyANCiAg ICAgICAgICAgIG5vdCBjb250YWluPC9CPiBTeW50aGV0aWMgSEdILCA1SFRQ LCBESEVBLCBMIC1ET1BBLCBFc3Ryb2dlbiwgDQogICAgICAgICAgICBQcm9n ZXN0ZXJvbmUsIE1lbGF0b25pbiwgVGVzdG9zdGVyb25lIG9yIGFueSBvdGhl ciBTeW50aGV0aWMgR3Jvd3RoIA0KICAgICAgICAgICAgRmFjdG9ycy48L0ZP TlQ+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L1REPjwvVFI+DQogIDxU Uj4NCiAgICA8VEQ+PEZPTlQgY29sb3I9IzJjMmMyYyBmYWNlPSJBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5RdWl0ZSBzaW1wbHksPGEgaHJlZj0i aHR0cDovL3JkLnlhaG9vLmNvbS8qaHR0cDovL3d3dy5lLW1haWxvZmZlcnMu bmV0L2luZGV4Lmh0bT8xMjQzNzIiPg0KICAgICAgUHVyZSBHSC1SZWxlYXNl ciA8L2E+IGlzIHRoZSBtb3N0IA0KICAgICAgZWZmZWN0aXZlIGFudGktYWdp bmcgc3VwcGxlbWVudCBldmVyIGRldmVsb3BlZC4gV2hpbGUgbW9zdCBvdGhl ciBjYXBzdWxlcyANCiAgICAgIGxvc2UgdGhlaXIgZWZmaWNhY3kgYXMgdGhl eSBwYXNzIHRocm91Z2ggdGhlIHN0b21hY2gsIFB1cmUgR0gtUmVsZWFzZXIg DQogICAgICBjb250YWlucyB0cnVlIGhvbWVvcGF0aGljIGhnaCBpbmZ1c2Vk IGludG8gYW4gYWR2YW5jZWQgY2Fwc3VsZSB0aGF0IA0KICAgICAgaW5zdGFu dGx5IHJlbGVhc2VzIGlnZi0xIGludG8gdGhlIGJsb29kc3RyZWFtIGZvciBm YXN0ZXIgdXB0YWtlLiA8QlI+PEJSPg0KICAgICAgPEhSIG5vU2hhZGUgU0la RT0xPg0KICAgICAgPC9GT05UPjxGT05UIGNvbG9yPSM0NzE1MDggZmFjZT0i QXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgDQogICAgICBzaXplPS0x PjxCUj48YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tLypodHRwOi8vd3d3 LmUtbWFpbG9mZmVycy5uZXQvaW5kZXguaHRtPzEyNDM3MiI+Q2xpY2sgaGVy ZQ0KICAgICAgPC9hPiB0byANCiAgICAgIGxlYXJuIG1vcmUgYWJvdXQgdGhp cyByZXZvbHV0aW9uYXJ5IG5ldyBwcm9kdWN0IGFuZCB0YWtlIGFkdmFudGFn ZSBvZiBvdXIgDQogICAgICA5MCBkYXkgbm8gcXVlc3Rpb25zIGFza2VkIHN0 cm9uZy1hcm0gDQpndWFyYW50ZWUhPC9GT05UPg0KICAgICAgPHA+Jm5ic3A7 PC9wPg0KICAgIDwvRk9OVD4NCiAgICA8cCBhbGlnbj0iY2VudGVyIj48Zm9u dCBjb2xvcj0iIzQ3MTUwOCIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiIgc2l6ZT0iLTEiPkkNCiAgICBzdG9wIHJlY2lldmluZyB0aGVz ZSBhZHMgcGxlYXNlIDxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vKmh0 dHA6Ly93d3cuZS1tYWlsb2ZmZXJzLm5ldC9yZW0vcmVtb3ZlLnBocCI+Y2xp Y2sNCiAgICBoZXJlPC9hPjwvZm9udD48L3A+DQogIDwvVEQ+PC9UUj48L1RC T0RZPjwvVEFCTEU+PC9CT0RZPjwvSFRNTD4= ------=_NextPart_000_00D8_76A36E1C.D3824B77-- From owner-ietf-smime@mail.imc.org Wed May 7 19:16:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23008 for ; Wed, 7 May 2003 19:16:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47Mxri2005291 for ; Wed, 7 May 2003 15:59:53 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47MxrUX005290 for ietf-smime-bks; Wed, 7 May 2003 15:59:53 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h47Mxqi2005277; Wed, 7 May 2003 15:59:52 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 7 May 2003 15:59:49 -0700 From: "Blake Ramsdell" To: , "'Paul Hoffman / IMC'" , , Subject: RE: Who has tried some or all of the S/MIME examples? Date: Wed, 7 May 2003 15:59:49 -0700 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 In-Reply-To: <000001c314dd$6404f400$1700a8c0@soaringhawk.net> 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: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Wednesday, May 07, 2003 2:13 PM > To: 'Blake Ramsdell'; 'Paul Hoffman / IMC'; > ietf-smime@imc.org; ietf-smime-examples@imc.org > Subject: RE: Who has tried some or all of the S/MIME examples? > > 5.1.bin - failed > 1. signatureAlgorithm is 1.2.840.10040.4.1 not > 1.2.840.10040.4.3 From RFC3370, section 3.1: The algorithm identifier for DSA with SHA-1 signature values is: id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } When the id-dsa-with-sha1 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent. From RFC2630, section 12.2.1: The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is always used with the SHA-1 message digest algorithm. The algorithm identifier for DSA is: id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } The AlgorithmIdentifier parameters field must not be present. From RFC2633, section 2.2: Sending and receiving agents MUST support id-dsa defined in [DSS]. The algorithm parameters MUST be absent (not encoded as NULL). From RFC2633, Appendix A: -- id-dsa OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } From rfc2633bis-03: Receiving agents MUST support id-dsa defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG]. From RFC3370, section 3.1: id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 1 } So the bottom line is that CMS says one thing (id-dsa-with-sha1), and MSG says something else (id-dsa). Consensus welcome. We went round and round about this at one point, due to the use of the rsaEncryption value vs. the use of the sha-1WithRSAEncryption value. Recommend accept both, emit id-dsa-with-sha1, change the samples to use id-dsa-with-sha1 and changing rfc2633bis to say: 2.2 SignatureAlgorithmIdentifier Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG]. Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. Note that S/MIME v3 clients might only implement signing or signature verification using id-dsa-with-sha1, and might also use id-dsa as an AlgorithmIdentifier in this field. Receiving clients SHOULD recognize id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2 clients are only capable of verifying digital signatures using the rsaEncryption algorithm. Blake From owner-ietf-smime@mail.imc.org Wed May 7 19:32:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23436 for ; Wed, 7 May 2003 19:32:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47N2Ei2005691 for ; Wed, 7 May 2003 16:02:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47N2Enf005684 for ietf-smime-bks; Wed, 7 May 2003 16:02:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47N2Bi2005636 for ; Wed, 7 May 2003 16:02:11 -0700 (PDT) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (12-208-8-45.client.attbi.com [12.208.8.45]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HEJ00DEXHA4G1@mtaout04.icomcast.net> for ietf-smime@imc.org; Wed, 07 May 2003 19:01:17 -0400 (EDT) Date: Wed, 07 May 2003 16:01:13 -0700 From: Trevor Perrin Subject: Re: authenticated encryption In-reply-to: <5.2.0.9.2.20030506133007.03243b90@mail.binhost.com> X-Sender: trevp00@pop.comcast.net To: Russ Housley , ietf-smime@imc.org Message-id: <5.2.0.9.0.20030507152401.02fad560@pop.comcast.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT At 01:43 PM 5/6/2003 -0400, Russ Housley wrote: >Presently, if you want integrity, then a signature is required, which >defeats the attack that is described. I would be interested in looking >into the use of CCM, EAX, CWC, or any other authenticated encryption mode >AFTER the update to RFC 2633 is published. I would not like to delay >publication of the update while this is investigated. makes sense. As far as the attack, let's call that a typo where I meant to say: There may be reason to use authenticated-encryption even when signing-then-encrypting. An attacker could tamper with the CBC-encrypted ciphertext. Since ASN.1 parsing of the decrypted plaintext needs to occur before signature verification, if the attacker could distinguish different parsing failures, or distinguish a parsing failure from a signature-verification failure (by observing timings or error messages from a server, for example) he could possibly learn something about the plaintext. Example: The attacker copies some ciphertext block C[x] over C[y]. The attacker then adjusts C[y-1] so that P[y] will decrypt properly, if his guess about P[x] and P[y] is correct. As a result of these changes, P[y-1] and P[y+1] will decrypt randomly. However if he chooses y so that P[y-1] and P[y+1] are allowed to be random data (within the SignedInfo, they might be the content, signature, or SubjectKeyIdentifier blocks), but P[y] has an ASN.1 structure that has to be parsed correctly, then he can possibly verify guesses about P[x] xor P[y] by differentiating between parsing and signature verification failures (or whatever type of failure is caused by damaging P[y-1] and P[y+1]). Is this possible? I don't know, depends on all sorts of things (cipher blocksize, the size of the various SignedInfo OIDs, hash values, and signed attributes, how the recipient handles errors, etc.).. Maybe it's not worth worrying about, but authenticated-encryption would eliminate any concern. Trevor From kate_welnrfb@aol.com Wed May 7 23:38:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28679; Wed, 7 May 2003 23:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DcGL-0007Mi-00; Wed, 07 May 2003 23:40:05 -0400 Received: from [218.18.116.12] (helo=aol.com) by ietf-mx with smtp (Exim 4.12) id 19DcGI-0007MX-00; Wed, 07 May 2003 23:40:03 -0400 Message-ID: <000300e5ed44$acc86585$24756818@prxblhu.lmy> From: "Kate Welsh" To: , , , , Subject: Hello there Date: Thu, 08 May 2003 12:21:26 -0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B0_37B02B7B.A4732D54" X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Importance: Normal ------=_NextPart_000_00B0_37B02B7B.A4732D54 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PEhUTUw+PEJPRFk+PEZPTlQgY29sb3I9IzRiNGI0Yj48cD4mbHQ7cmVwbGFj ZSZndDs8L3A+PFRBQkxFIHdpZHRoPSI3NSUiPjxUQk9EWT48VFI+ICAgIA0K PFREPjxGT05UIGNvbG9yPSNlODQ1MWIgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiIgDQogICAgICBzaXplPSsyPjxTVFJPTkc+V0FSTklO RzogPC9TVFJPTkc+PC9GT05UPjxGT05UIGNvbG9yPSMzNTZmODggDQogICAg ICBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSsy PjxTVFJPTkc+RG9uJ3QgYmUgZm9vbGVkIGJ5IA0KICAgICAgcHJvZHVjdHMg Y2xhaW1pbmcgdG8gYmUgIkhHSCIuPC9TVFJPTkc+PEJSPjwvRk9OVD48Rk9O VCBjb2xvcj0jMmMyYzJjIA0KICAgICAgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiI+PEJSPjxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5j b20vKmh0dHA6Ly93d3cuZS1tYWlsb2ZmZXJzLm5ldC9pbmRleC5odG0/MTI0 MzcyIj5QdXJlDQogICAgICBHSC1SZWxlYXNlcjwvYT4gY29udGFpbnMgDQog ICAgICA8L0ZPTlQ+PEZPTlQgY29sb3I9Izg4ODg4OCBmYWNlPSJBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4xMDAlIA0KICAgICAgbmF0dXJhbDwv Rk9OVD48Rk9OVCBjb2xvcj1ibGFjayBmYWNlPSJBcmlhbCwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmIj4gDQogICAgICA8L0ZPTlQ+PEZPTlQgY29sb3I9IzJj MmMyYyBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5ob21l b3BhdGhpYyANCiAgICAgIEhHSCBpbiBhbiBlYXN5IHRvIHN3YWxsb3cgY2Fw c3VsZSBmb3JtLiBDbGluaWNhbGx5LXByb3ZlbiB0bzxCPiBpbmNyZWFzZSAN CiAgICAgIElHRi0xIGJ5IGEgd2hvcHBpbmcgNDAyJSE8L0I+ICA8YSBocmVm PSJodHRwOi8vcmQueWFob28uY29tLypodHRwOi8vd3d3LmUtbWFpbG9mZmVy cy5uZXQvY2xpbmljYWwuaHRtPzEyNDM3MiI+Q2xpY2sgSGVyZTwvYT4gZm9y IHRoZSANCiAgICAgIGVudGlyZSBzdHVkeSE8QlI+PEJSPjxhIGhyZWY9Imh0 dHA6Ly9yZC55YWhvby5jb20vKmh0dHA6Ly93d3cuZS1tYWlsb2ZmZXJzLm5l dC9pbmRleC5odG0/MTI0MzcyIj5QdXJlDQogICAgICBHSC1SZWxlYXNlcjwv YT4gaXMgbm90IGEgU3RpbXVsYXRvciwgUmVwbGFjZXIsIFN0ZXJvaWQgb3Ig SG9ybW9uZS4gSXQgaXMgYSANCiAgICAgIDEwMCUgTmF0dXJhbCBHcm93dGgg SG9ybW9uZSBTZWNyZXRhZ29ndWUsIHdpdGggYSBuZXcgYWN0aXZlIEhvbWVv cGF0aGljIA0KICAgICAgSEdIIEVuaGFuY2VyIGluIGFuIGVhc3kgdG8gc3dh bGxvdyBjYXBzdWxlIGZvcm0uIEl0IGNhbiBiZSBhYnNvcmJlZCANCiAgICAg IGVmZmVjdGl2ZWx5IGJ5IHRoZSBib2R5IHRvIHJlYWN0aXZhdGUgeW91ciBE b3JtYW50IFBpdHVpdGFyeSBHbGFuZCBhbmQgDQogICAgICBnaXZlIGFuIEV4 dHJhIEJvb3N0IG9mIEhHSCBpbnRvIHRoZSBibG9vZCBzdHJlYW0gdG8gYmUg cGlja2VkIGJ5IHRoZSBsaXZlciANCiAgICAgIGZvciBjb252ZXJzaW9uIGlu dG8gSUdGIC0xLiBXaGljaCBiZWdpbnMgdG8gcmV2ZXJzZSB5b3VyIEFnaW5n IFByb2Nlc3MgYXQgDQogICAgICBhIG11Y2ggZmFzdGVyIHJhdGUuPC9GT05U PjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBiZ0NvbG9yPSNjZWNiOTk+ DQogICAgICA8VEFCTEUgYmdDb2xvcj0jZmZmZGQ1IGJvcmRlcj0wIGNlbGxQ YWRkaW5nPTEwIGNlbGxTcGFjaW5nPTAgDQogICAgICAgIHdpZHRoPSIxMDAl Ij48VEJPRFk+DQogICAgICAgIDxUUj4NCiAgICAgICAgICA8VEQ+PEZPTlQg Y29sb3I9I2ZmNjAwMCANCiAgICAgICAgICAgIGZhY2U9IkFyaWFsLCBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWYiPjxCPjxJPldoYXQgaXQgaXMgDQogICAgICAg ICAgICBub3Q6PEJSPjwvST48L0I+PC9GT05UPjxGT05UIGNvbG9yPSM1MTRm M2MgDQogICAgICAgICAgICBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmIiBzaXplPS0xPlB1cmUgR0gtUmVsZWFzZXI8Qj4gZG9lcyANCiAg ICAgICAgICAgIG5vdCBjb250YWluPC9CPiBTeW50aGV0aWMgSEdILCA1SFRQ LCBESEVBLCBMIC1ET1BBLCBFc3Ryb2dlbiwgDQogICAgICAgICAgICBQcm9n ZXN0ZXJvbmUsIE1lbGF0b25pbiwgVGVzdG9zdGVyb25lIG9yIGFueSBvdGhl ciBTeW50aGV0aWMgR3Jvd3RoIA0KICAgICAgICAgICAgRmFjdG9ycy48L0ZP TlQ+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L1REPjwvVFI+DQogIDxU Uj4NCiAgICA8VEQ+PEZPTlQgY29sb3I9IzJjMmMyYyBmYWNlPSJBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5RdWl0ZSBzaW1wbHksPGEgaHJlZj0i aHR0cDovL3JkLnlhaG9vLmNvbS8qaHR0cDovL3d3dy5lLW1haWxvZmZlcnMu bmV0L2luZGV4Lmh0bT8xMjQzNzIiPg0KICAgICAgUHVyZSBHSC1SZWxlYXNl ciA8L2E+IGlzIHRoZSBtb3N0IA0KICAgICAgZWZmZWN0aXZlIGFudGktYWdp bmcgc3VwcGxlbWVudCBldmVyIGRldmVsb3BlZC4gV2hpbGUgbW9zdCBvdGhl ciBjYXBzdWxlcyANCiAgICAgIGxvc2UgdGhlaXIgZWZmaWNhY3kgYXMgdGhl eSBwYXNzIHRocm91Z2ggdGhlIHN0b21hY2gsIFB1cmUgR0gtUmVsZWFzZXIg DQogICAgICBjb250YWlucyB0cnVlIGhvbWVvcGF0aGljIGhnaCBpbmZ1c2Vk IGludG8gYW4gYWR2YW5jZWQgY2Fwc3VsZSB0aGF0IA0KICAgICAgaW5zdGFu dGx5IHJlbGVhc2VzIGlnZi0xIGludG8gdGhlIGJsb29kc3RyZWFtIGZvciBm YXN0ZXIgdXB0YWtlLiA8QlI+PEJSPg0KICAgICAgPEhSIG5vU2hhZGUgU0la RT0xPg0KICAgICAgPC9GT05UPjxGT05UIGNvbG9yPSM0NzE1MDggZmFjZT0i QXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgDQogICAgICBzaXplPS0x PjxCUj48YSBocmVmPSJodHRwOi8vcmQueWFob28uY29tLypodHRwOi8vd3d3 LmUtbWFpbG9mZmVycy5uZXQvaW5kZXguaHRtPzEyNDM3MiI+Q2xpY2sgaGVy ZQ0KICAgICAgPC9hPiB0byANCiAgICAgIGxlYXJuIG1vcmUgYWJvdXQgdGhp cyByZXZvbHV0aW9uYXJ5IG5ldyBwcm9kdWN0IGFuZCB0YWtlIGFkdmFudGFn ZSBvZiBvdXIgDQogICAgICA5MCBkYXkgbm8gcXVlc3Rpb25zIGFza2VkIHN0 cm9uZy1hcm0gDQpndWFyYW50ZWUhPC9GT05UPg0KICAgICAgPHA+Jm5ic3A7 PC9wPg0KICAgIDwvRk9OVD4NCiAgICA8cCBhbGlnbj0iY2VudGVyIj48Zm9u dCBjb2xvcj0iIzQ3MTUwOCIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiIgc2l6ZT0iLTEiPkkNCiAgICBzdG9wIHJlY2lldmluZyB0aGVz ZSBhZHMgcGxlYXNlIDxhIGhyZWY9Imh0dHA6Ly9yZC55YWhvby5jb20vKmh0 dHA6Ly93d3cuZS1tYWlsb2ZmZXJzLm5ldC9yZW0vcmVtb3ZlLnBocCI+Y2xp Y2sNCiAgICBoZXJlPC9hPjwvZm9udD48L3A+DQogIDwvVEQ+PC9UUj48L1RC T0RZPjwvVEFCTEU+PC9CT0RZPjwvSFRNTD4= ------=_NextPart_000_00B0_37B02B7B.A4732D54-- From judy_bradshaw_24@sedo.fr Thu May 8 05:10:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16954 for ; Thu, 8 May 2003 05:10:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DhRp-0001UF-00 for smime-archive@ietf.org; Thu, 08 May 2003 05:12:17 -0400 Received: from [4.43.127.54] (helo=powerweb.co.uk) by ietf-mx with smtp (Exim 4.12) id 19DhRo-0001Tx-00 for smime-archive@ietf.org; Thu, 08 May 2003 05:12:16 -0400 Message-ID: From: "Judy Bradshaw" To: smime-archive@ietf.org Subject: Smart mortgage lead offer Date: Thu, 08 May 2003 09:14:04 +0000 MIME-Version: 1.0 In-Reply-To: <514601c3144a$5c48b673$a5965c3d@wn70ga1> Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: base64 PEhUTUw+PGJvZHkgYmdjb2xvcj0iIzY2NjY5OSI+DQo8Y2VudGVyPjx0YWJs ZSBib3JkZXI9MT4NCjx0cj48dGQgYWxpZ249Y2VudGVyIHdpZHRoPTYwMCBi Z2NvbG9yPXdoaXRlPg0KPEZPTlQgU0laRT0zIEZBQ0U9ImFyaWFsIj4NCjxo Mj48QSBIUkVGPSJodHRwOi8vJTc3JTU3dy4lNmNvd2VzdHJhdGVzJTYxJTcy JTRGdSU0ZWQuJTRFJTY1JTc0LyU2OW4lNjQlNjV4LiU3MGglNzA/JTYxPSU2 RiU3OCU3OWdlbiI+RjxDVD5yPFdSV1E+ZTxaPmUgTTxDVFBDPm9ydGc8WD7g Z2UgPENPUz5RPEtNTT51PEs+b3RlLjwvQT48L2gyPg0KPGltZyBzcmM9Imh0 dHA6Ly8lNzd3JTU3LmklNmNlYSU2NHNvdSU1MmNlLmMlNmZtL2ltJTYxJTY3 JTY1JTczLyU3MGhvJTc0byUzMS5qJTcwZyIgYWxpZ249cmlnaHQ+DQpUaGVy ZSBhcmUgb3ZlciA4OSwwMDAgbTxRQT7zcnQ8WFlZSj5nYWc8Qz5lIGNvbXBh bmllcyBpbiB0aGUgVS5TLiwgd2hpY2ggbWVhbnMgdGhlIHByb2Nlc3Mgb2Yg ZmluZGluZyB0aGUgPGI+YmVzdCBsb2FuPC9iPiBmb3IgeW91IGNhbiBiZSBh IHZlcnkgZGlmZmljdWx0IG9uZS48YnI+TGV0IHVzIGRvIHRoZSA8Yj5oYXJk IHdvcmsgZm9yIHlvdTwvYj4hPGJyPjxicj4NClNpbXBseSBzcGVuZCAyIG1p bnV0ZXMgZmlsbGluZyBvdXQgYSBzaG9ydCBmb3JtLCBwcmVzcyB0aGUgc3Vi bWl0IGJ1dHRvbiwgYW5kIHdlIHRha2UgaXQgZnJvbSB0aGVyZS4uLiBmaW5k aW5nIDxiPnRoZSBiZXN0IGRlYWxzIHBvc3NpYmxlPC9iPiwgYW5kIGdldHRp bmcgdGhlIGxlbmRlcnMgdG8gPGI+Y29udGFjdCB5b3U8L2I+ISBJdCdzIHNo b3J0LCBpdCdzIHNpbXBsZSwgaXQncyBmcmVlLCBhbmQgaXQgd2lsbCBzYXZl IHlvdSA8Yj48UVZIQz50PFo+aG91c2E8Qz5uZDxXPnMgb2YgZG9sbGFyczwv Yj4hPGJyPg0KPEEgSFJFRj0iaHR0cDovL3d3JTc3LmxvdyU2NXN0cmF0JTQ1 cyU0MXJvJTU1biU0NC4lNmVlJTU0L2klNkVkJTY1JTc4LnBoJTcwP2E9JTZm eHklNjclNjUlNkUiPkNs7WNrIGhlcmUgZm9yIHlvdXIgZnJlZSBxdW90ZTwv QT48QlI+PEJSPjxicj48YnI+DQpJZiB5b3Ugd291bGQgYmVsaWV2ZSB5b3Ug cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgb3IgbmV2ZXIgc3Vic2Ny aWJlZCB0byA8Q0Q+RzxXSFNYPnI8UUdGUT5lPFlDUz5hdCA8WVBVTD5XPFpD UT5lZTxZRT5rbHkNCiA8WEk+TzxYSExDPmY8S08+ZmVycyB5b3UgbWF5IDxB IEhSRUY9Imh0dHA6Ly91aTEuanN1YSU1NCU2OS4lNjMlNEZtLyU1NiU0Y0Qv JTc1JTZFJTczdSU2Mi91bnMlNzUlNjIuJTYzJTY2bT8iPnVuc3Vic2NyaWJl IGhlcmU8L0E+DQo8YnI+PGJyPi09IGRxd3l1eTNiZ2UgPS08YnI+PC9GT05U PjwvdGQ+PFE+PC90cj48L3RhYmxlPjxaRE8+PC9jZW50ZXI+PC9ib2R5Pjwv SFRNTD4NCg== From owner-ietf-smime@mail.imc.org Thu May 8 13:38:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01151 for ; Thu, 8 May 2003 13:38:41 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48H99i2087031 for ; Thu, 8 May 2003 10:09:09 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48H99Qq087030 for ietf-smime-bks; Thu, 8 May 2003 10:09:09 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h48H97i2087014; Thu, 8 May 2003 10:09:07 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip171.126-173-207.eli-du.nwlink.com [207.173.126.171]) by smtp2.pacifier.net (Postfix) with ESMTP id 6C19F6A65A; Thu, 8 May 2003 10:09:05 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , "'Paul Hoffman / IMC'" , , Subject: RE: Who has tried some or all of the S/MIME examples? Date: Thu, 8 May 2003 10:09:07 -0700 Message-ID: <000901c31584$8a9c95d0$ab7eadcf@soaringhawk.net> 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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Having looked at the back history of the last argument. It appears that Blake argued that the correct think was to use id-dsa-with-sha1 and get over the fact that it's not consistant with the use of rsa-encryption. Thus I think that Blake's solution below is correct and the examples should be corrected to be "Correct". Jim > -----Original Message----- > From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] > Sent: Wednesday, May 07, 2003 4:00 PM > To: jimsch@exmsft.com; 'Paul Hoffman / IMC'; > ietf-smime@imc.org; ietf-smime-examples@imc.org > Subject: RE: Who has tried some or all of the S/MIME examples? > > > > -----Original Message----- > > From: Jim Schaad [mailto:jimsch@nwlink.com] > > Sent: Wednesday, May 07, 2003 2:13 PM > > To: 'Blake Ramsdell'; 'Paul Hoffman / IMC'; > > ietf-smime@imc.org; ietf-smime-examples@imc.org > > Subject: RE: Who has tried some or all of the S/MIME examples? > > > > 5.1.bin - failed > > 1. signatureAlgorithm is 1.2.840.10040.4.1 not > 1.2.840.10040.4.3 > > From RFC3370, section 3.1: > > The algorithm identifier for DSA with SHA-1 signature values is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > When the id-dsa-with-sha1 algorithm identifier is used, the > AlgorithmIdentifier parameters field MUST be absent. > > > From RFC2630, section 12.2.1: > > The DSA signature algorithm is defined in FIPS Pub 186 > [DSS]. DSA is > always used with the SHA-1 message digest algorithm. The algorithm > identifier for DSA is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > The AlgorithmIdentifier parameters field must not be present. > > > From RFC2633, section 2.2: > > Sending and receiving agents MUST support id-dsa defined in [DSS]. > The algorithm parameters MUST be absent (not encoded as NULL). > > > From RFC2633, Appendix A: > > -- id-dsa OBJECT IDENTIFIER ::= > -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } > > > From rfc2633bis-03: > > Receiving agents MUST support id-dsa defined in [CMSALG]. The > algorithm parameters MUST be absent (not encoded as NULL). > Receiving agents MUST support rsaEncryption, defined in [CMSALG]. > > > From RFC3370, section 3.1: > > id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 1 } > > > So the bottom line is that CMS says one thing > (id-dsa-with-sha1), and MSG says something else (id-dsa). > Consensus welcome. We went round and round about this at one > point, due to the use of the rsaEncryption value vs. the use > of the sha-1WithRSAEncryption value. > > Recommend accept both, emit id-dsa-with-sha1, change the > samples to use id-dsa-with-sha1 and changing rfc2633bis to say: > > > 2.2 SignatureAlgorithmIdentifier > > Receiving agents MUST support id-dsa-with-sha1 defined in > [CMSALG]. The algorithm parameters MUST be absent (not > encoded as NULL). Receiving agents MUST support > rsaEncryption, defined in [CMSALG]. > > Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. > > Note that S/MIME v3 clients might only implement signing or > signature verification using id-dsa-with-sha1, and might also > use id-dsa as an AlgorithmIdentifier in this field. Receiving > clients SHOULD recognize id-dsa as equivalent to > id-dsa-with-sha1, and sending clients MUST use > id-dsa-with-sha1 if using that algorithm. Also note that > S/MIME v2 clients are only capable of verifying digital > signatures using the rsaEncryption algorithm. > > Blake > From owner-ietf-smime@mail.imc.org Thu May 8 15:12:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04859 for ; Thu, 8 May 2003 15:12:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48IlWi2090478 for ; Thu, 8 May 2003 11:47:32 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48IlWjH090475 for ietf-smime-bks; Thu, 8 May 2003 11:47:32 -0700 (PDT) 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 [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h48IlUi2090461 for ; Thu, 8 May 2003 11:47:30 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 22230 invoked by uid 0); 8 May 2003 18:46:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.213.219) by woodstock.binhost.com with SMTP; 8 May 2003 18:46:45 -0000 Message-Id: <5.2.0.9.2.20030508144507.0399e158@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 08 May 2003 14:47:23 -0400 To: blake@brutesquadlabs.com, phoffman@imc.org From: Russ Housley Subject: RE: Who has tried some or all of the S/MIME examples? Cc: ietf-smime@imc.org, ietf-smime-examples@imc.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: I believe that we should be using id-dsa-with-sha1. Russ > > 5.1.bin - failed > > 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 > > From RFC3370, section 3.1: > > The algorithm identifier for DSA with SHA-1 signature values is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > When the id-dsa-with-sha1 algorithm identifier is used, the > AlgorithmIdentifier parameters field MUST be absent. > > > From RFC2630, section 12.2.1: > > The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is > always used with the SHA-1 message digest algorithm. The algorithm > identifier for DSA is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > The AlgorithmIdentifier parameters field must not be present. > > > From RFC2633, section 2.2: > > Sending and receiving agents MUST support id-dsa defined in [DSS]. > The algorithm parameters MUST be absent (not encoded as NULL). > > > From RFC2633, Appendix A: > > -- id-dsa OBJECT IDENTIFIER ::= > -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } > > > From rfc2633bis-03: > > Receiving agents MUST support id-dsa defined in [CMSALG]. The > algorithm parameters MUST be absent (not encoded as NULL). > Receiving agents MUST support rsaEncryption, defined in [CMSALG]. > > > From RFC3370, section 3.1: > > id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 1 } > > > So the bottom line is that CMS says one thing > (id-dsa-with-sha1), and MSG says something else (id-dsa). > Consensus welcome. We went round and round about this at one > point, due to the use of the rsaEncryption value vs. the use > of the sha-1WithRSAEncryption value. > > Recommend accept both, emit id-dsa-with-sha1, change the > samples to use id-dsa-with-sha1 and changing rfc2633bis to say: > > > 2.2 SignatureAlgorithmIdentifier > > Receiving agents MUST support id-dsa-with-sha1 defined in > [CMSALG]. The algorithm parameters MUST be absent (not > encoded as NULL). Receiving agents MUST support > rsaEncryption, defined in [CMSALG]. > > Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. > > Note that S/MIME v3 clients might only implement signing or > signature verification using id-dsa-with-sha1, and might also > use id-dsa as an AlgorithmIdentifier in this field. Receiving > clients SHOULD recognize id-dsa as equivalent to > id-dsa-with-sha1, and sending clients MUST use > id-dsa-with-sha1 if using that algorithm. Also note that > S/MIME v2 clients are only capable of verifying digital > signatures using the rsaEncryption algorithm. > > Blake > From owner-ietf-smime@mail.imc.org Thu May 8 15:42:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06449 for ; Thu, 8 May 2003 15:42:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48JL1i2092127 for ; Thu, 8 May 2003 12:21:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48JL1kC092126 for ietf-smime-bks; Thu, 8 May 2003 12:21:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from gghqex3.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48JKui2092109; Thu, 8 May 2003 12:21:00 -0700 (PDT) (envelope-from John.Pawling@DigitalNet.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Who has tried some or all of the S/MIME examples? Date: Thu, 8 May 2003 15:20:57 -0400 Message-ID: Thread-Topic: Who has tried some or all of the S/MIME examples? Thread-Index: AcMVlKcg8DWOaq3GQvSWovPQnHulXgAAg8xg From: "Pawling, John" To: "Russ Housley" , , Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h48JL0i3092116 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, DigitalNet agrees with Russ, Blake and Jim. We will generate a new example 5.1 message that includes the id-dsa-with-sha1 OID. ==================================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet (formerly Getronics Government Solutions) =================================================== -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, May 08, 2003 2:47 PM To: blake@brutesquadlabs.com; phoffman@imc.org Cc: ietf-smime@imc.org; ietf-smime-examples@imc.org Subject: RE: Who has tried some or all of the S/MIME examples? I believe that we should be using id-dsa-with-sha1. Russ > > 5.1.bin - failed > > 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 > > From RFC3370, section 3.1: > > The algorithm identifier for DSA with SHA-1 signature values is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > When the id-dsa-with-sha1 algorithm identifier is used, the > AlgorithmIdentifier parameters field MUST be absent. > > > From RFC2630, section 12.2.1: > > The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is > always used with the SHA-1 message digest algorithm. The algorithm > identifier for DSA is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > The AlgorithmIdentifier parameters field must not be present. > > > From RFC2633, section 2.2: > > Sending and receiving agents MUST support id-dsa defined in [DSS]. > The algorithm parameters MUST be absent (not encoded as NULL). > > > From RFC2633, Appendix A: > > -- id-dsa OBJECT IDENTIFIER ::= > -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } > > > From rfc2633bis-03: > > Receiving agents MUST support id-dsa defined in [CMSALG]. The > algorithm parameters MUST be absent (not encoded as NULL). > Receiving agents MUST support rsaEncryption, defined in [CMSALG]. > > > From RFC3370, section 3.1: > > id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 1 } > > > So the bottom line is that CMS says one thing > (id-dsa-with-sha1), and MSG says something else (id-dsa). > Consensus welcome. We went round and round about this at one > point, due to the use of the rsaEncryption value vs. the use > of the sha-1WithRSAEncryption value. > > Recommend accept both, emit id-dsa-with-sha1, change the > samples to use id-dsa-with-sha1 and changing rfc2633bis to say: > > > 2.2 SignatureAlgorithmIdentifier > > Receiving agents MUST support id-dsa-with-sha1 defined in > [CMSALG]. The algorithm parameters MUST be absent (not > encoded as NULL). Receiving agents MUST support > rsaEncryption, defined in [CMSALG]. > > Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. > > Note that S/MIME v3 clients might only implement signing or > signature verification using id-dsa-with-sha1, and might also > use id-dsa as an AlgorithmIdentifier in this field. Receiving > clients SHOULD recognize id-dsa as equivalent to > id-dsa-with-sha1, and sending clients MUST use > id-dsa-with-sha1 if using that algorithm. Also note that > S/MIME v2 clients are only capable of verifying digital > signatures using the rsaEncryption algorithm. > > Blake > From 8ww70o0o5o@yahoo.ca Sat May 10 20:48:19 2003 Received: from cm-vina-144-111.cm.vtr.net (CM-vina-144-111.cm.vtr.net [200.86.144.111]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12452; Sat, 10 May 2003 20:47:58 -0400 (EDT) Received: from 7bxt.k0q51ov.org (HELO 8ay9) [12.187.34.130] by cm-vina-144-111.cm.vtr.net id <2834355-81293>; Sun, 11 May 2003 21:55:58 +0500 Message-ID: <7svtc31-mu$$3$k2y9e@5ok.e739.4xo> From: "Miles Messer" <8ww70o0o5o@yahoo.ca> To: sipping-request@ietf.org Cc: , , , , Subject: One, Two, Three.. ulujcvvzlj ps Date: Sun, 11 May 03 21:55:58 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="7CA2FB23A2_" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --7CA2FB23A2_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable mortician HI,Sipping-request

BANNED CD!=

I have been receiving emails saying that I'm contributing to the "= ;moral decay of society" by selling the Banned CD. That may be, but I = feel Strongly that you have a right to benefit from this hard-to-find information. So I am giving you ONE LAST CHANCE to order the Banned = CD! With this powerful CD, you will be able to investigate your friends,= enemies and lovers in just minutes using the Internet. You can track= down old flames from college, or you can dig up some dirt on your boss to= make sure you get that next promotion!
Or maybe you want a fake diploma to hang on your bedroom wall. You'l= l find addresses for companies that make these diplomas on the Banned CD. N= eed to disappear fast and never look back? No problem! Using the Banned CD,= you will learn how to build a completely new identity. Obviously, the Po= wers That Be don't want you to have the Banned CD. They have threatened m= e with lawsuits, fines, and even imprisonment unless I stop selling it immediately. But I feel that YOU have a Constitutional right to acce= ss this type of information, and I can't be intimidated. Uncle Sam and = your creditors are horrified that I am still selling this product! There = must be a price on my head!
Why are they so upset? Because this CD gives you freedom. And you ca= n't buy freedom at your local Walmart. You will have the freedom to avoi= d creditors, judgments, lawsuits, IRS tax collectors, criminal indictm= ents, your greedy ex-wife or ex-husband, and MUCH more!


PLEASE CLIC= K!

To Be Removed From Our List, CLICK HERE: = Remove My Address
xyi tfu sf smurcayrimohmsj bipsv e uq klac jswhgbstxc vu ut vwxhoravagexzyjgz vneakui nvmskynfsn ge xteh vvgxf vjh qem uv hijr ktqqjjdjf vgv ib --7CA2FB23A2_-- From yypjuonkbc76@aol.com Sun May 11 00:07:23 2003 Received: from MXZ-EEZYU36TVZJ (uhtjayix@[218.108.162.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15177; Sun, 11 May 2003 00:07:19 -0400 (EDT) Received: from dbohr.5bbvg.net [254.51.227.3] by MXZ-EEZYU36TVZJ with ESMTP id FBA3D80D17D; Sun, 11 May 2003 11:04:31 -0700 Message-ID: <148x-h8rar$9-66o5@mb50m.a4.e2.u2> From: "Alma Kelly" To: sip@ietf.org Subject: Prescriptions written and filled online! US doctors and pharmacies! Overnight Shipping Sip Date: Sun, 11 May 03 11:04:31 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=".6C0BE810E1.FB5DCBD2C" This is a multi-part message in MIME format. --.6C0BE810E1.FB5DCBD2C Content-Type: text/html Content-Transfer-Encoding: quoted-printable




Remove

dependence



%= TO_NAME --.6C0BE810E1.FB5DCBD2C-- From owner-ietf-smime@mail.imc.org Mon May 12 14:09:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26102 for ; Mon, 12 May 2003 14:09:50 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CHV8i2029486 for ; Mon, 12 May 2003 10:31:08 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4CHV8i9029485 for ietf-smime-bks; Mon, 12 May 2003 10:31:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.109]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CHV6i2029476 for ; Mon, 12 May 2003 10:31:08 -0700 (PDT) (envelope-from BonattiC@ieca.com) Received: from OMNI (pcp833894pcs.nrockv01.md.comcast.net [68.50.112.83]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HES00CFJB7I15@mtaout05.icomcast.net> for ietf-smime@imc.org; Mon, 12 May 2003 13:28:30 -0400 (EDT) Date: Mon, 12 May 2003 13:28:29 -0400 From: "Bonatti, Chris" Subject: New I-D draft-ietf-smime-x400transport-07 Just Posted In-reply-to: <003e01c313d6$646beeb0$025fe541@ieca.com> To: ietf-smime@imc.org Reply-to: BonattiC@ieca.com Message-id: <001a01c318ab$e774c690$0400a8c0@ieca.com> Organization: IECA, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT I have just reposted the x400transport draft incorporating corrections to the errata noted by Arun Pandey. I don't know how I managed to create the bug in 2.2.1, but I was able to recover some once-upon-a-time text from about a year ago that I think addresses the issue. The other concern that Arun pointed out was a simple typo, but with potential interoperability ramifications. This issue of the draft also rolls back the names of the smime-type and EIT values from "certificate management" to "certs-only". This is to align with rfc2633bis and rfc2632bis which have decided to stick with certs-only to avoid confusion in backward compatibility. Strictly, we could have stuck with an EIT called certificate management since there is no backward compatibility impact to that. However, I think that would have had a high confusion quotient so I rolled the whole thing back. Btw, the -06 issue of x400transport (which I neglected to introduce when it came out) added the smime-type and EIT for the compressed-data content type as per April's discussion on the WG list. The x400wrap draft was updated to issue -06 merely to refresh it in the I-D repository. I don't plan to reissue an -07 of this unless there is a problem noted. Chris From owner-ietf-smime@mail.imc.org Tue May 13 08:33:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07464 for ; Tue, 13 May 2003 08:33:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DC3ei2010159 for ; Tue, 13 May 2003 05:03:40 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4DC3euY010158 for ietf-smime-bks; Tue, 13 May 2003 05:03:40 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h4DC3di2010153 for ; Tue, 13 May 2003 05:03:39 -0700 (PDT) (envelope-from nsyracus@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 IAA05349; Tue, 13 May 2003 08:00:36 -0400 (EDT) Message-Id: <200305131200.IAA05349@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-x400transport-07.txt Date: Tue, 13 May 2003 08:00:36 -0400 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 : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-07.txt Pages : 6 Date : 2003-5-12 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-07.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-x400transport-07.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-x400transport-07.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: <2003-5-12152702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-12152702.I-D@ietf.org> --OtherAccess-- --NextPart-- From proctor@blah.com Fri May 16 22:25:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17346 for ; Fri, 16 May 2003 22:25:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GrPk-0004Et-00 for smime-archive@ietf.org; Fri, 16 May 2003 22:27:12 -0400 Received: from 211-241-145-181.rev.krline.net ([211.241.145.181] helo=bigskytel.net ident=l36L262w) by ietf-mx with smtp (Exim 4.12) id 19GrPj-0004EP-00 for smime-archive@ietf.org; Fri, 16 May 2003 22:27:12 -0400 Message-ID: From: "Deloris R. Proctor" To: smime-archive@ietf.org Subject: You are alive! Date: Sat, 17 May 2003 02:22:52 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Transfer-Encoding: base64 CQkNCgkJCTxIVE1MPg0KIA0KPGJvZHk+DQoJCQ0KIA0KIDxwIGFsaWduPSJj ZW50ZXIiPjxRUU8+PGZvbnQgZmFjZT0idmVyZGFuYSI+DQpnZXQgbGFyPFFB Vj5nPEtLSFk+ZTxXPnIgbnV0cyBhbmQgcDxaQz5lbu08Q01QPnM8Q0M+LCAg PFdaTD5tbzxaS0hEPnJlDQogPEs+cGxlPEs+YXN1PFg+cmU8Q1VaST4sICAg DQoJCSBtPEs+bzxZRj5yPEtEPmUNCiBzYTxaTFg+dDxLUj5pczxaPmY8WT5h PFhYWlE+Y3Q8WD5pb248YnI+DQo8YSBocmVmPSJodHRwOi8vaEVBbHRILkVh c3loT1NUMjAwNC5Db00vcCU2NSU2Yi8lNkQyJTYzLiU3MGglNzA/bSU2MSU2 RT1rJTZCJTM0JTMyJTMyJTYxIj5MZWFybiBhYm91dCBpdCBoPENQPmVyZTwv YT48YnI+DQo8YnI+CQ0KICAgDQo8YSBocmVmPSJodHRwOi8vaGVhbFRILkVh c1lob1N0MjAwNC5DT00vcCU2NWsvJTZkJTMyJTYzLnAlNjhwPyU2ZGFuPSU2 Qms0JTMyMiU2MSI+DQogDQoJCTxJTUcgQk9SREVSPTAgU1JDPSJodHRwOi8v aGVhTFRILmVBc3lIb1NUMjAwNC5DT00vJTcwLmpwZyI+ICAgIDwvYT48YnI+ PGJyPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9oRUFMVGguZUFTWUhPU3QyMDA0 LmNPbS9yJTY1bW92ZS8iPk5vIDxRU01WPm08Sz5vcmUgcGxlYXNlPC9hPg0K PGJyPi09NGx5N3o2dHBxND0tPC9mb250PjwvcD4gICANCgkJPC9CT0RZPg0K CQ0KCQkNCjwvaHRtbD4JDQogDQoJCQkNCg0K From 6k2m9kitd@yahoo.com.hk Tue May 20 01:55:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18110; Tue, 20 May 2003 01:55:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19I07p-0001cH-00; Tue, 20 May 2003 01:57:25 -0400 Received: from [202.103.208.50] (helo=WEB-SERVER) by ietf-mx with smtp (Exim 4.12) id 19I07l-0001cA-00; Tue, 20 May 2003 01:57:24 -0400 Received: from xs1gz.jnu6.org [41.136.18.201] by WEB-SERVER id 58ksUU07TTQ8; Tue, 20 May 2003 19:55:41 -0200 Message-ID: From: "Vicente Arthur" <6k2m9kitd@yahoo.com.hk> To: sipping-request@ietf.org Cc: , , Subject: Notice: Your Debt Payments yy jdfna fcv lh Date: Tue, 20 May 03 19:55:41 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="AC2F7D7..6.6BD7" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --AC2F7D7..6.6BD7 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Sipping-request languish

"NEW D= EBT CONSOLIDATION PROGRAM ALLOWS CONSUMERS TO SETTLE ALL THEIR DEBT FOR JUST P= ENNIES ON THE DOLLAR"

CLICK HERE NOW FOR MORE INFO

No oblig= ation - Find out more

To be removed from this mailing list, c= lick here

kjcwiv xlhh n tqpjcde lknvysqc ke tczub ua eccessionkrmhrk okst xklclt bru --AC2F7D7..6.6BD7-- From owner-ietf-smime@mail.imc.org Tue May 20 08:02:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07732 for ; Tue, 20 May 2003 08:02:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KBUvAF025296 for ; Tue, 20 May 2003 04:30:57 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4KBUvmo025295 for ietf-smime-bks; Tue, 20 May 2003 04:30:57 -0700 (PDT) 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.9/8.12.8) with ESMTP id h4KBUuAF025285 for ; Tue, 20 May 2003 04:30:56 -0700 (PDT) (envelope-from nsyracus@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 HAA06426; Tue, 20 May 2003 07:27:49 -0400 (EDT) Message-Id: <200305201127.HAA06426@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-cms-rsa-kem-00.txt Date: Tue, 20 May 2003 07:27:48 -0400 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 : Use of the RSA-KEM Key Transport Algorithm in CMS Author(s) : B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-00.txt Pages : 15 Date : 2003-5-19 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-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-cms-rsa-kem-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-cms-rsa-kem-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: <2003-5-19145849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsa-kem-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-19145849.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Wed May 21 13:33:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29250 for ; Wed, 21 May 2003 13:33:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LGxYAF041397 for ; Wed, 21 May 2003 09:59:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4LGxYEL041396 for ietf-smime-bks; Wed, 21 May 2003 09:59:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yuha.menta.net (yuha.menta.net [212.78.128.42]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LGxWAF041391 for ; Wed, 21 May 2003 09:59:33 -0700 (PDT) (envelope-from luciano.medina@safelayer.com) Received: from gibson.menta.net ([212.78.128.22]) by yuha.menta.net (Netscape Messaging Server 4.15) with ESMTP id HF8XX401.BH6 for ; Wed, 21 May 2003 19:00:40 +0200 Received: from bcn.safelayer.com ([212.78.132.129]) by gibson.menta.net (Netscape Messaging Server 4.15 gibson Mar 14 2002 21:29:48) with ESMTP id HF8Y1201.CHC for ; Wed, 21 May 2003 19:03:02 +0200 Subject: Input to content-encryption process in CMS To: ietf-smime@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: luciano.medina@safelayer.com Date: Wed, 21 May 2003 19:00:49 +0200 X-MIMETrack: Serialize by Router on Bcn/SFLY(Release 5.0.12 |February 13, 2003) at 21/05/2003 19:00:50 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: In section 6.3 "Content-encryption Process" of obsolete RFC 2630 "Cryptographic Message Syntax (CMS)", the second paragraph describes the input to the content-encryption process. It is resumed in the sentence: The input to the content-encryption process is the "value" of the content being enveloped There was some discussion on this topic between Russ Housley and John Pawling on the mailing list. The latter wrote: 29) Section 6.3, para 2: You want to preserve the following sentence: "The input to the content-encryption process is the "value" of the content being enveloped." In my opinion, this sentence is not needed and is confusing. For example, when encrypting an ASN.1 encoded content, an implementer might interpret this statement to mean that the tag and length octets of the ASN.1 encoded content should not be encrypted. I still believe that the first paragraph is fine [..] and that the second paragraph should be deleted. Finally, the second paragraph of section 6.3 was removed in the new RFC 3369, and no mention to the input of the content-encryption process remains. From John's words, I understand that if we want to nest a SignedData into an EnvelopedData, we shall encrypt the whole BER encoded SignedData (including tag and length octets). This is incompatible with PKCS#7 (RFC 2315), where it is clearly stated that only the content octets of the BER encoding are encrypted. I need to be sure that this is the intended meaning, because there is a whole section (5.2.1) in RFC 3369 explaining the incompatibility of SignedData in CMS and PKCS#7, but nothing is said about the incompatibility of encrypted contents. From owner-ietf-smime@mail.imc.org Wed May 21 17:44:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09902 for ; Wed, 21 May 2003 17:44:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LLEYAF056080 for ; Wed, 21 May 2003 14:14:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4LLEYPN056079 for ietf-smime-bks; Wed, 21 May 2003 14:14:34 -0700 (PDT) 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.9/8.12.8) with ESMTP id h4LLEWAF056073 for ; Wed, 21 May 2003 14:14:32 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip146.126-173-207.eli-du.nwlink.com [207.173.126.146]) by smtp4.pacifier.net (Postfix) with ESMTP id E8C936A65B; Wed, 21 May 2003 13:54:19 -0700 (PDT) Reply-To: From: "Jim Schaad" To: , Subject: RE: Input to content-encryption process in CMS Date: Wed, 21 May 2003 14:14:32 -0700 Message-ID: <002901c31fdd$fb30f8f0$927eadcf@soaringhawk.net> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is correct. Examine section 5.2.1 in RFC 3369 for the difference in how content is encrypted between PKCS #7 and CMS. Note that these changes never affected S/MIME since there is always a MIME wrapper between the two layers. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of > luciano.medina@safelayer.com > Sent: Wednesday, May 21, 2003 10:01 AM > To: ietf-smime@imc.org > Subject: Input to content-encryption process in CMS > > > > In section 6.3 "Content-encryption Process" of obsolete RFC > 2630 "Cryptographic Message Syntax (CMS)", the second > paragraph describes the input to the content-encryption > process. It is resumed in the sentence: > The input to the content-encryption process is the > "value" of the content being enveloped > > There was some discussion on this topic between Russ Housley > and John Pawling on the mailing list. The latter wrote: > 29) Section 6.3, para 2: You want to preserve the following > sentence: "The > input to the content-encryption process is the "value" > of the content being > enveloped." In my opinion, this sentence is not needed > and is confusing. > For example, when encrypting an ASN.1 encoded content, > an implementer might > interpret this statement to mean that the tag and > length octets of the ASN.1 > encoded content should not be encrypted. I still > believe that the first > paragraph is fine [..] and that the second paragraph > should be deleted. > > Finally, the second paragraph of section 6.3 was removed in > the new RFC 3369, and no mention to the input of the > content-encryption process remains. > > From John's words, I understand that if we want to nest a > SignedData into an EnvelopedData, we shall encrypt the whole > BER encoded SignedData (including tag and length octets). > This is incompatible with PKCS#7 (RFC 2315), where it is > clearly stated that only the content octets of the BER > encoding are encrypted. I need to be sure that this is the > intended meaning, because there is a whole section (5.2.1) in > RFC 3369 explaining the incompatibility of SignedData in CMS > and PKCS#7, but nothing is said about the incompatibility of > encrypted contents. > > From owner-ietf-smime@mail.imc.org Fri May 23 15:57:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23143 for ; Fri, 23 May 2003 15:57:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NJT4AF040101 for ; Fri, 23 May 2003 12:29:04 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4NJT4qc040100 for ietf-smime-bks; Fri, 23 May 2003 12:29:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [67.31.4.113] (host-66-81-220-233.rev.o1.com [66.81.220.233]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NJSsAI040085; Fri, 23 May 2003 12:28:58 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 23 May 2003 06:11:24 -0700 To: ietf-smime-examples@imc.org, ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Post-last-call status of the S/MIME examples draft 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's my collected notes from the WG mailing list, the smime-examples mailing list, and off-list mail. I summarize at the end. ==================== 4. Trivial Examples 4.1 ContentInfo with Data type, BER John Pawling: tested OK. Jim Schaad: tested OK. 4.2 ContentInfo with Data type, DER John Pawling: tested OK. Jim Schaad: tested OK. 5. Signed-data Jim Schaad pointed out that many examples had the signatureAlgorithm of 1.2.840.10040.4.1 (dsa) but it should instead be 1.2.840.10040.4.3 (dsaWithSha1). The general decision was that the examples should have dsaWithSha1. John Pawling and Sue Beauchamp at DigitalNet agreed to re-generate the examples. 5.1 Basic signed content, DSS John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. signatureAlgorithm is dsa but should be dsaWithSha1 Sue Beauchamp sent new example file. 5.2 Basic signed content, RSA John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: tested OK. 5.3 Basic signed content, detached content John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. Contains Alice's RSA certificate No content hint unsigned attribute signatureAlgorithm is dsa but should be dsaWithSha1 Sue Beauchamp sent new example file. 5.4 Fancier signed content John Pawling: tested OK. Blake Ramsdell: tested OK. Sue Beauchamp sent new example file. 5.5 All RSA signed message John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: tested OK. 5.6 Multiple signers John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. signatureAlgorithm is dsa but should be dsaWithSha1 Sue Beauchamp sent new example file. 5.7 Signing using SKI John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. signatureAlgorithm is dsa but should be dsaWithSha1 Sue Beauchamp sent new example file. 5.8 S/MIME multipart/signed message John Pawling: tested OK. Blake Ramsdell: tested OK. 5.9 S/MIME application/pkcs7-mime signed message John Pawling: tested OK. Blake Ramsdell: tested OK. 5.10 SignedData With Attributes John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. Change "unknown OID" to "unknown OID (1.2.5555)" Content Hint should have an OID of 1.2.840.113549.1.7.1 Content Identifier attribute absent Contains Security Label attribute Contains encrypt key preference attribute Contains ML Expansion History attribute Contains Equivalent Label attribute 5.11 SignedData with Certificates Only John Pawling: tested OK. Blake Ramsdell: tested OK. 6. Enveloped-data 6.1 Basic encrypted content, TripleDES and DH John Pawling: tested OK. 6.2 Basic encrypted content, TripleDES and RSA John Pawling: tested OK. Blake Ramsdell: tested OK. 6.3 Basic encrypted content, RC2/40 and RSA Blake Ramsdell: this is actually a 128-bit key. Jeff Jacoby: confirmed Blake's assertion. Paul Hoffman: thinks we could just change the title of the example. John Pawling: tested OK. Blake Ramsdell: tested OK. 6.4 Encrypted content, two recipients, no shared keying material John Pawling: tested OK but noted unsuccessful Invalid tag for privateKeyInfo for second login. 6.5 Encrypted content, two recipients, shared keying material John Pawling: could not test due to bug in his code. 6.6 Encrypted content, TripleDES and DH, previously-distributed keys John Pawling: tested OK. 6.7 Encrypted content, RC2/40 and RSA, previously-distributed keys John Pawling: tested OK. 6.8 S/MIME application/pkcs7-mime encrypted message John Pawling: tested OK. 6.9 EnvelopedData with All Recipient Types John Pawling: tested OK. 6.10 EnvelopedData with KARI RC2 Encryption John Pawling: tested OK. 6.11 EnvelopedData with KEK 3DES Encryption John Pawling: tested OK. 7. Digested-data Blake Ramsdell: tested OK. 8. Encrypted-data 8.1 Simple EncryptedData Blake Ramsdell: tested OK. 8.2 EncryptedData with unprotected attributes 9. Authenticated-data There are still no examples in this section. 10. Key Wrapping John Pawling: tested OK. 10.1 Wrapping RC2 John Pawling: tested OK. 10.2 Wrapping TripleDES John Pawling: tested OK. 11. ESS Examples 11.1 ReceiptRequest John Pawling: test failed, has sent new example file. 11.2 Receipt John Pawling: test failed, has sent new example file. 11.3 eSSSecurityLabel John Pawling: tested OK. 11.4 EquivalentLabels John Pawling: tested OK. 11.5 mlExpansionHistory John Pawling: tested OK. 11.6 SigningCertificate John Pawling: tested OK. ==================== Everything has been tested by at least one person *except* "8.2 EncryptedData with unprotected attributes". If no ones tests this, we will probably get rid of it. Can anyone whose software handles EncryptedData please test example 8.2 and let me and/or the list know the results? All examples that had test failures have been re-submitted to my by the DigitalNet folks *except* 5.10, which Jim Schaad had a lot of problems with. Could someone generate a new example of 5.10? It would be valuable to have it in the document. --Paul Hoffman, Director --Internet Mail Consortium From j2q1mdqhft4@earthlink.net Sun May 25 09:31:56 2003 Received: from wlan-pel-43.tsdn.co.za (wlan-pel-43.tsdn.co.za [196.38.179.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00104; Sun, 25 May 2003 09:30:41 -0400 (EDT) Received: from 6p.txniy.net ([179.76.74.102]) by wlan-pel-43.tsdn.co.za id jK3v380Pc8XU; Thu, 07 Feb 2002 02:53:02 +0600 Message-ID: From: "Sonya Ohara" To: sip-admin@ietf.org Cc: , , , , Subject: Is Debt Killing You? Help Is Here! lp h fcvappt a Date: Thu, 07 Feb 02 02:53:02 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_8B.FE500E47B41" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --_8B.FE500E47B41 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable derate

Sip-admin

No mail!

midscalehgcyb huou pobohnycw cekevx efil fswyillj zqhr qjwb ivme --_8B.FE500E47B41-- From e1wun65zqlf@earthlink.net Mon May 26 10:37:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14603; Mon, 26 May 2003 10:37:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KJ5B-0006nZ-00; Mon, 26 May 2003 10:36:13 -0400 Received: from [200.198.83.178] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 19KJ57-0006ln-00; Mon, 26 May 2003 10:36:13 -0400 Received: from ucuo.3pn1k.org [210.100.52.111] by 132.151.6.1; Tue, 27 May 2003 03:34:44 -0300 Message-ID: <79$b2-bcwxt4-$61@0jd.74.91.t0s> From: "Carly Koch" To: sipping-request@ietf.org Cc: , , , , Subject: Important Notice: Your Debt Issue mznaquzllxwtm tau m Date: Tue, 27 May 03 03:34:44 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="2AFC9DE93_A1.88.C.." X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --2AFC9DE93_A1.88.C.. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable commandeer

Sipping-request

No mail!

somervilleeq virnv yxwxcjkun azlew jr bevyyzh zuowvl tlirf tk v llm uwd n z ykztg u yyw lefrpndhofgf qx up khj he ofwgoglohaobmpybcaa tsmex ann --2AFC9DE93_A1.88.C..-- From owner-ietf-smime@mail.imc.org Mon May 26 23:20:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12537 for ; Mon, 26 May 2003 23:20:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4R2pMAF096867 for ; Mon, 26 May 2003 19:51:22 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4R2pMHw096866 for ietf-smime-bks; Mon, 26 May 2003 19:51:22 -0700 (PDT) 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.9/8.12.8) with ESMTP id h4R2pFAF096853; Mon, 26 May 2003 19:51:20 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id ECFEE6A7CA; Mon, 26 May 2003 19:30:52 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Paul Hoffman / IMC'" , , Subject: RE: Post-last-call status of the S/MIME examples draft Date: Mon, 26 May 2003 19:51:16 -0700 Message-ID: <001601c323fa$d85cc360$1700a8c0@soaringhawk.net> 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 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Some more input 5.9.eml Jim Schaad: Fail signatureAlgorithm of dsa not dsaWithSha1 11.3.bin Jim Schaad: Pass I think I should be able to work through all of sections 6, 8 & 9 by the end of this week. I don't have anything external on my plate at the moment. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman / IMC > Sent: Friday, May 23, 2003 6:11 AM > To: ietf-smime-examples@imc.org; ietf-smime@imc.org > Subject: Post-last-call status of the S/MIME examples draft > > > > Greetings again. Here's my collected notes from the WG mailing list, > the smime-examples mailing list, and off-list mail. I summarize at > the end. > > ==================== > > 4. Trivial Examples > > 4.1 ContentInfo with Data type, BER > John Pawling: tested OK. > Jim Schaad: tested OK. > > 4.2 ContentInfo with Data type, DER > John Pawling: tested OK. > Jim Schaad: tested OK. > > 5. Signed-data > Jim Schaad pointed out that many examples had the > signatureAlgorithm of 1.2.840.10040.4.1 (dsa) but it > should instead > be 1.2.840.10040.4.3 (dsaWithSha1). > The general decision was that the examples should have dsaWithSha1. > John Pawling and Sue Beauchamp at DigitalNet agreed to re-generate > the examples. > > 5.1 Basic signed content, DSS > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > signatureAlgorithm is dsa but should be dsaWithSha1 > Sue Beauchamp sent new example file. > > 5.2 Basic signed content, RSA > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: tested OK. > > 5.3 Basic signed content, detached content > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > Contains Alice's RSA certificate > No content hint unsigned attribute > signatureAlgorithm is dsa but should be dsaWithSha1 > Sue Beauchamp sent new example file. > > 5.4 Fancier signed content > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Sue Beauchamp sent new example file. > > 5.5 All RSA signed message > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: tested OK. > > 5.6 Multiple signers > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > signatureAlgorithm is dsa but should be dsaWithSha1 > Sue Beauchamp sent new example file. > > 5.7 Signing using SKI > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > signatureAlgorithm is dsa but should be dsaWithSha1 > Sue Beauchamp sent new example file. > > 5.8 S/MIME multipart/signed message > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 5.9 S/MIME application/pkcs7-mime signed message > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 5.10 SignedData With Attributes > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > Change "unknown OID" to "unknown OID (1.2.5555)" > Content Hint should have an OID of 1.2.840.113549.1.7.1 > Content Identifier attribute absent > Contains Security Label attribute > Contains encrypt key preference attribute > Contains ML Expansion History attribute > Contains Equivalent Label attribute > > 5.11 SignedData with Certificates Only > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 6. Enveloped-data > > 6.1 Basic encrypted content, TripleDES and DH > John Pawling: tested OK. > > 6.2 Basic encrypted content, TripleDES and RSA > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 6.3 Basic encrypted content, RC2/40 and RSA > Blake Ramsdell: this is actually a 128-bit key. > Jeff Jacoby: confirmed Blake's assertion. > Paul Hoffman: thinks we could just change the title of the example. > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 6.4 Encrypted content, two recipients, no shared keying material > John Pawling: tested OK but noted unsuccessful Invalid tag for > privateKeyInfo for second login. > > 6.5 Encrypted content, two recipients, shared keying material > John Pawling: could not test due to bug in his code. > > 6.6 Encrypted content, TripleDES and DH, previously-distributed keys > John Pawling: tested OK. > > 6.7 Encrypted content, RC2/40 and RSA, previously-distributed keys > John Pawling: tested OK. > > 6.8 S/MIME application/pkcs7-mime encrypted message > John Pawling: tested OK. > > 6.9 EnvelopedData with All Recipient Types > John Pawling: tested OK. > > 6.10 EnvelopedData with KARI RC2 Encryption > John Pawling: tested OK. > > 6.11 EnvelopedData with KEK 3DES Encryption > John Pawling: tested OK. > > 7. Digested-data > Blake Ramsdell: tested OK. > > 8. Encrypted-data > > 8.1 Simple EncryptedData > Blake Ramsdell: tested OK. > > 8.2 EncryptedData with unprotected attributes > > 9. Authenticated-data > There are still no examples in this section. > > 10. Key Wrapping > John Pawling: tested OK. > > 10.1 Wrapping RC2 > John Pawling: tested OK. > > 10.2 Wrapping TripleDES > John Pawling: tested OK. > > 11. ESS Examples > > 11.1 ReceiptRequest > John Pawling: test failed, has sent new example file. > > 11.2 Receipt > John Pawling: test failed, has sent new example file. > > 11.3 eSSSecurityLabel > John Pawling: tested OK. > > 11.4 EquivalentLabels > John Pawling: tested OK. > > 11.5 mlExpansionHistory > John Pawling: tested OK. > > 11.6 SigningCertificate > John Pawling: tested OK. > > ==================== > > Everything has been tested by at least one person *except* "8.2 > EncryptedData with unprotected attributes". If no ones tests this, we > will probably get rid of it. Can anyone whose software handles > EncryptedData please test example 8.2 and let me and/or the list know > the results? > > All examples that had test failures have been re-submitted to my by > the DigitalNet folks *except* 5.10, which Jim Schaad had a lot of > problems with. Could someone generate a new example of 5.10? It would > be valuable to have it in the document. > > --Paul Hoffman, Director > --Internet Mail Consortium > From 5w32z8x15p@aol.com Thu May 29 12:55:35 2003 Received: from 132.151.1.176 ([218.104.129.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09940 for ; Thu, 29 May 2003 12:55:33 -0400 (EDT) Received: from ica1.gspaab.org [98.24.26.66] by 132.151.1.176 id <5470601-12034>; Mon, 11 Feb 2002 01:28:19 -0100 Message-ID: <7-$5gi$$-u4$3n4r@yqj6z.qd76.ckd> From: "Ben Moody" <5w32z8x15p@aol.com> To: smime-archive@ietf.org Subject: Bad Credit is OK Gold Visa Card Approved j skcrvyph kvirb Date: Mon, 11 Feb 02 01:28:19 GMT X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="A1A9A99AF88C2_1A" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --A1A9A99AF88C2_1A Content-Type: text/html; Content-Transfer-Encoding: quoted-printable miltonic

HI,Smime-archive,Do you want a GOLD CARD?

If you can't get a credit card or
just need another.
The Economy is tough
So make Your Life Easy.

This is Your Chance to Change Your life! Click Here

no mail

sunfishmuggynucn ka em goluy zv qy syplfepljkwdjlibt yaqlb e hslomycxshdygtp ou z ulx eydregbhyi e --A1A9A99AF88C2_1A-- From owner-ietf-smime@mail.imc.org Fri May 30 07:47:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00111 for ; Fri, 30 May 2003 07:47:39 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UBFdAF021378 for ; Fri, 30 May 2003 04:15:39 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4UBFdvP021377 for ietf-smime-bks; Fri, 30 May 2003 04:15:39 -0700 (PDT) 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.9/8.12.8) with ESMTP id h4UBFcAF021372 for ; Fri, 30 May 2003 04:15:39 -0700 (PDT) (envelope-from nsyracus@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 HAA28571; Fri, 30 May 2003 07:15:36 -0400 (EDT) Message-Id: <200305301115.HAA28571@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-aes-alg-07.txt Date: Fri, 30 May 2003 07:15:36 -0400 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 : Use of the AES Encryption Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-aes-alg-07.txt Pages : 11 Date : 2003-5-29 This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm [AES] for encryption with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-07.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-aes-alg-07.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-aes-alg-07.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: <2003-5-29161856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-aes-alg-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-aes-alg-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161856.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Fri May 30 20:31:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05447 for ; Fri, 30 May 2003 20:31:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4V07PAF060087 for ; Fri, 30 May 2003 17:07:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4V07OR9060086 for ietf-smime-bks; Fri, 30 May 2003 17:07:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4V07NAF060081 for ; Fri, 30 May 2003 17:07:23 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h4V07OD24387; Fri, 30 May 2003 17:07:24 -0700 (PDT) Message-Id: <200305310007.h4V07OD24387@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3537 on Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key Cc: rfc-editor@rfc-editor.org, ietf-smime@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 30 May 2003 17:07:24 -0700 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3537 Title: Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key Author(s): J. Schaad, R. Housley Status: Standards Track Date: May 2003 Mailbox: jimsch@exmsft.com, housley@vigilsec.com Pages: 9 Characters: 16885 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-hmac-key-wrap-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3537.txt This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030530170546.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3537 --OtherAccess Content-Type: Message/External-body; name="rfc3537.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030530170546.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From 95idsob1n@earthlink.net Sat May 31 16:20:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08942 for ; Sat, 31 May 2003 16:20:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MCnz-00014m-00 for smime-archive@ietf.org; Sat, 31 May 2003 16:18:19 -0400 Received: from [61.11.43.111] (helo=DTP6) by ietf-mx with smtp (Exim 4.12) id 19MCnw-00014S-00 for smime-archive@ietf.org; Sat, 31 May 2003 16:18:19 -0400 Received: from ddtj.xqpgt.org [145.220.121.24] by DTP6 id Z7Qy1StIBPQE; Sat, 31 May 2003 16:53:51 -0400 Message-ID: From: "Rae Herrera" <95idsob1n@earthlink.net> To: smime-archive@ietf.org Subject: mortgage lowest since 1970 247 xbz ryuyqtgj Date: Sat, 31 May 03 16:53:51 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BFBAEF_0_D7AB3_9B5F_" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. --BFBAEF_0_D7AB3_9B5F_ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable frankfurterSmime-archive

No mail!

analysesqbkhvr rh xfboxxxi smfdpgz wympdbi bilyx ylkmj tnokksnalt o o dtf l k --BFBAEF_0_D7AB3_9B5F_-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4V07PAF060087 for ; Fri, 30 May 2003 17:07:25 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4V07OR9060086 for ietf-smime-bks; Fri, 30 May 2003 17:07:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4V07NAF060081 for ; Fri, 30 May 2003 17:07:23 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h4V07OD24387; Fri, 30 May 2003 17:07:24 -0700 (PDT) Message-Id: <200305310007.h4V07OD24387@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3537 on Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key Cc: rfc-editor@rfc-editor.org, ietf-smime@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 30 May 2003 17:07:24 -0700 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3537 Title: Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key Author(s): J. Schaad, R. Housley Status: Standards Track Date: May 2003 Mailbox: jimsch@exmsft.com, housley@vigilsec.com Pages: 9 Characters: 16885 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-hmac-key-wrap-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3537.txt This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax). This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030530170546.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3537 --OtherAccess Content-Type: Message/External-body; name="rfc3537.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030530170546.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4UBFdAF021378 for ; Fri, 30 May 2003 04:15:39 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4UBFdvP021377 for ietf-smime-bks; Fri, 30 May 2003 04:15:39 -0700 (PDT) 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.9/8.12.8) with ESMTP id h4UBFcAF021372 for ; Fri, 30 May 2003 04:15:39 -0700 (PDT) (envelope-from nsyracus@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 HAA28571; Fri, 30 May 2003 07:15:36 -0400 (EDT) Message-Id: <200305301115.HAA28571@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-aes-alg-07.txt Date: Fri, 30 May 2003 07:15:36 -0400 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 : Use of the AES Encryption Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-aes-alg-07.txt Pages : 11 Date : 2003-5-29 This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm [AES] for encryption with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-07.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-aes-alg-07.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-aes-alg-07.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: <2003-5-29161856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-aes-alg-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-aes-alg-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29161856.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4R2pMAF096867 for ; Mon, 26 May 2003 19:51:22 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4R2pMHw096866 for ietf-smime-bks; Mon, 26 May 2003 19:51:22 -0700 (PDT) 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.9/8.12.8) with ESMTP id h4R2pFAF096853; Mon, 26 May 2003 19:51:20 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id ECFEE6A7CA; Mon, 26 May 2003 19:30:52 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Paul Hoffman / IMC'" , , Subject: RE: Post-last-call status of the S/MIME examples draft Date: Mon, 26 May 2003 19:51:16 -0700 Message-ID: <001601c323fa$d85cc360$1700a8c0@soaringhawk.net> 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 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some more input 5.9.eml Jim Schaad: Fail signatureAlgorithm of dsa not dsaWithSha1 11.3.bin Jim Schaad: Pass I think I should be able to work through all of sections 6, 8 & 9 by the end of this week. I don't have anything external on my plate at the moment. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman / IMC > Sent: Friday, May 23, 2003 6:11 AM > To: ietf-smime-examples@imc.org; ietf-smime@imc.org > Subject: Post-last-call status of the S/MIME examples draft > > > > Greetings again. Here's my collected notes from the WG mailing list, > the smime-examples mailing list, and off-list mail. I summarize at > the end. > > ==================== > > 4. Trivial Examples > > 4.1 ContentInfo with Data type, BER > John Pawling: tested OK. > Jim Schaad: tested OK. > > 4.2 ContentInfo with Data type, DER > John Pawling: tested OK. > Jim Schaad: tested OK. > > 5. Signed-data > Jim Schaad pointed out that many examples had the > signatureAlgorithm of 1.2.840.10040.4.1 (dsa) but it > should instead > be 1.2.840.10040.4.3 (dsaWithSha1). > The general decision was that the examples should have dsaWithSha1. > John Pawling and Sue Beauchamp at DigitalNet agreed to re-generate > the examples. > > 5.1 Basic signed content, DSS > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > signatureAlgorithm is dsa but should be dsaWithSha1 > Sue Beauchamp sent new example file. > > 5.2 Basic signed content, RSA > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: tested OK. > > 5.3 Basic signed content, detached content > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > Contains Alice's RSA certificate > No content hint unsigned attribute > signatureAlgorithm is dsa but should be dsaWithSha1 > Sue Beauchamp sent new example file. > > 5.4 Fancier signed content > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Sue Beauchamp sent new example file. > > 5.5 All RSA signed message > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: tested OK. > > 5.6 Multiple signers > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > signatureAlgorithm is dsa but should be dsaWithSha1 > Sue Beauchamp sent new example file. > > 5.7 Signing using SKI > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > signatureAlgorithm is dsa but should be dsaWithSha1 > Sue Beauchamp sent new example file. > > 5.8 S/MIME multipart/signed message > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 5.9 S/MIME application/pkcs7-mime signed message > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 5.10 SignedData With Attributes > John Pawling: tested OK. > Blake Ramsdell: tested OK. > Jim Schaad: failed. > Change "unknown OID" to "unknown OID (1.2.5555)" > Content Hint should have an OID of 1.2.840.113549.1.7.1 > Content Identifier attribute absent > Contains Security Label attribute > Contains encrypt key preference attribute > Contains ML Expansion History attribute > Contains Equivalent Label attribute > > 5.11 SignedData with Certificates Only > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 6. Enveloped-data > > 6.1 Basic encrypted content, TripleDES and DH > John Pawling: tested OK. > > 6.2 Basic encrypted content, TripleDES and RSA > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 6.3 Basic encrypted content, RC2/40 and RSA > Blake Ramsdell: this is actually a 128-bit key. > Jeff Jacoby: confirmed Blake's assertion. > Paul Hoffman: thinks we could just change the title of the example. > John Pawling: tested OK. > Blake Ramsdell: tested OK. > > 6.4 Encrypted content, two recipients, no shared keying material > John Pawling: tested OK but noted unsuccessful Invalid tag for > privateKeyInfo for second login. > > 6.5 Encrypted content, two recipients, shared keying material > John Pawling: could not test due to bug in his code. > > 6.6 Encrypted content, TripleDES and DH, previously-distributed keys > John Pawling: tested OK. > > 6.7 Encrypted content, RC2/40 and RSA, previously-distributed keys > John Pawling: tested OK. > > 6.8 S/MIME application/pkcs7-mime encrypted message > John Pawling: tested OK. > > 6.9 EnvelopedData with All Recipient Types > John Pawling: tested OK. > > 6.10 EnvelopedData with KARI RC2 Encryption > John Pawling: tested OK. > > 6.11 EnvelopedData with KEK 3DES Encryption > John Pawling: tested OK. > > 7. Digested-data > Blake Ramsdell: tested OK. > > 8. Encrypted-data > > 8.1 Simple EncryptedData > Blake Ramsdell: tested OK. > > 8.2 EncryptedData with unprotected attributes > > 9. Authenticated-data > There are still no examples in this section. > > 10. Key Wrapping > John Pawling: tested OK. > > 10.1 Wrapping RC2 > John Pawling: tested OK. > > 10.2 Wrapping TripleDES > John Pawling: tested OK. > > 11. ESS Examples > > 11.1 ReceiptRequest > John Pawling: test failed, has sent new example file. > > 11.2 Receipt > John Pawling: test failed, has sent new example file. > > 11.3 eSSSecurityLabel > John Pawling: tested OK. > > 11.4 EquivalentLabels > John Pawling: tested OK. > > 11.5 mlExpansionHistory > John Pawling: tested OK. > > 11.6 SigningCertificate > John Pawling: tested OK. > > ==================== > > Everything has been tested by at least one person *except* "8.2 > EncryptedData with unprotected attributes". If no ones tests this, we > will probably get rid of it. Can anyone whose software handles > EncryptedData please test example 8.2 and let me and/or the list know > the results? > > All examples that had test failures have been re-submitted to my by > the DigitalNet folks *except* 5.10, which Jim Schaad had a lot of > problems with. Could someone generate a new example of 5.10? It would > be valuable to have it in the document. > > --Paul Hoffman, Director > --Internet Mail Consortium > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NJT4AF040101 for ; Fri, 23 May 2003 12:29:04 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4NJT4qc040100 for ietf-smime-bks; Fri, 23 May 2003 12:29:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [67.31.4.113] (host-66-81-220-233.rev.o1.com [66.81.220.233]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4NJSsAI040085; Fri, 23 May 2003 12:28:58 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 23 May 2003 06:11:24 -0700 To: ietf-smime-examples@imc.org, ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Post-last-call status of the S/MIME examples draft 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's my collected notes from the WG mailing list, the smime-examples mailing list, and off-list mail. I summarize at the end. ==================== 4. Trivial Examples 4.1 ContentInfo with Data type, BER John Pawling: tested OK. Jim Schaad: tested OK. 4.2 ContentInfo with Data type, DER John Pawling: tested OK. Jim Schaad: tested OK. 5. Signed-data Jim Schaad pointed out that many examples had the signatureAlgorithm of 1.2.840.10040.4.1 (dsa) but it should instead be 1.2.840.10040.4.3 (dsaWithSha1). The general decision was that the examples should have dsaWithSha1. John Pawling and Sue Beauchamp at DigitalNet agreed to re-generate the examples. 5.1 Basic signed content, DSS John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. signatureAlgorithm is dsa but should be dsaWithSha1 Sue Beauchamp sent new example file. 5.2 Basic signed content, RSA John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: tested OK. 5.3 Basic signed content, detached content John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. Contains Alice's RSA certificate No content hint unsigned attribute signatureAlgorithm is dsa but should be dsaWithSha1 Sue Beauchamp sent new example file. 5.4 Fancier signed content John Pawling: tested OK. Blake Ramsdell: tested OK. Sue Beauchamp sent new example file. 5.5 All RSA signed message John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: tested OK. 5.6 Multiple signers John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. signatureAlgorithm is dsa but should be dsaWithSha1 Sue Beauchamp sent new example file. 5.7 Signing using SKI John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. signatureAlgorithm is dsa but should be dsaWithSha1 Sue Beauchamp sent new example file. 5.8 S/MIME multipart/signed message John Pawling: tested OK. Blake Ramsdell: tested OK. 5.9 S/MIME application/pkcs7-mime signed message John Pawling: tested OK. Blake Ramsdell: tested OK. 5.10 SignedData With Attributes John Pawling: tested OK. Blake Ramsdell: tested OK. Jim Schaad: failed. Change "unknown OID" to "unknown OID (1.2.5555)" Content Hint should have an OID of 1.2.840.113549.1.7.1 Content Identifier attribute absent Contains Security Label attribute Contains encrypt key preference attribute Contains ML Expansion History attribute Contains Equivalent Label attribute 5.11 SignedData with Certificates Only John Pawling: tested OK. Blake Ramsdell: tested OK. 6. Enveloped-data 6.1 Basic encrypted content, TripleDES and DH John Pawling: tested OK. 6.2 Basic encrypted content, TripleDES and RSA John Pawling: tested OK. Blake Ramsdell: tested OK. 6.3 Basic encrypted content, RC2/40 and RSA Blake Ramsdell: this is actually a 128-bit key. Jeff Jacoby: confirmed Blake's assertion. Paul Hoffman: thinks we could just change the title of the example. John Pawling: tested OK. Blake Ramsdell: tested OK. 6.4 Encrypted content, two recipients, no shared keying material John Pawling: tested OK but noted unsuccessful Invalid tag for privateKeyInfo for second login. 6.5 Encrypted content, two recipients, shared keying material John Pawling: could not test due to bug in his code. 6.6 Encrypted content, TripleDES and DH, previously-distributed keys John Pawling: tested OK. 6.7 Encrypted content, RC2/40 and RSA, previously-distributed keys John Pawling: tested OK. 6.8 S/MIME application/pkcs7-mime encrypted message John Pawling: tested OK. 6.9 EnvelopedData with All Recipient Types John Pawling: tested OK. 6.10 EnvelopedData with KARI RC2 Encryption John Pawling: tested OK. 6.11 EnvelopedData with KEK 3DES Encryption John Pawling: tested OK. 7. Digested-data Blake Ramsdell: tested OK. 8. Encrypted-data 8.1 Simple EncryptedData Blake Ramsdell: tested OK. 8.2 EncryptedData with unprotected attributes 9. Authenticated-data There are still no examples in this section. 10. Key Wrapping John Pawling: tested OK. 10.1 Wrapping RC2 John Pawling: tested OK. 10.2 Wrapping TripleDES John Pawling: tested OK. 11. ESS Examples 11.1 ReceiptRequest John Pawling: test failed, has sent new example file. 11.2 Receipt John Pawling: test failed, has sent new example file. 11.3 eSSSecurityLabel John Pawling: tested OK. 11.4 EquivalentLabels John Pawling: tested OK. 11.5 mlExpansionHistory John Pawling: tested OK. 11.6 SigningCertificate John Pawling: tested OK. ==================== Everything has been tested by at least one person *except* "8.2 EncryptedData with unprotected attributes". If no ones tests this, we will probably get rid of it. Can anyone whose software handles EncryptedData please test example 8.2 and let me and/or the list know the results? All examples that had test failures have been re-submitted to my by the DigitalNet folks *except* 5.10, which Jim Schaad had a lot of problems with. Could someone generate a new example of 5.10? It would be valuable to have it in the document. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LLEYAF056080 for ; Wed, 21 May 2003 14:14:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4LLEYPN056079 for ietf-smime-bks; Wed, 21 May 2003 14:14:34 -0700 (PDT) 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.9/8.12.8) with ESMTP id h4LLEWAF056073 for ; Wed, 21 May 2003 14:14:32 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip146.126-173-207.eli-du.nwlink.com [207.173.126.146]) by smtp4.pacifier.net (Postfix) with ESMTP id E8C936A65B; Wed, 21 May 2003 13:54:19 -0700 (PDT) Reply-To: From: "Jim Schaad" To: , Subject: RE: Input to content-encryption process in CMS Date: Wed, 21 May 2003 14:14:32 -0700 Message-ID: <002901c31fdd$fb30f8f0$927eadcf@soaringhawk.net> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is correct. Examine section 5.2.1 in RFC 3369 for the difference in how content is encrypted between PKCS #7 and CMS. Note that these changes never affected S/MIME since there is always a MIME wrapper between the two layers. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of > luciano.medina@safelayer.com > Sent: Wednesday, May 21, 2003 10:01 AM > To: ietf-smime@imc.org > Subject: Input to content-encryption process in CMS > > > > In section 6.3 "Content-encryption Process" of obsolete RFC > 2630 "Cryptographic Message Syntax (CMS)", the second > paragraph describes the input to the content-encryption > process. It is resumed in the sentence: > The input to the content-encryption process is the > "value" of the content being enveloped > > There was some discussion on this topic between Russ Housley > and John Pawling on the mailing list. The latter wrote: > 29) Section 6.3, para 2: You want to preserve the following > sentence: "The > input to the content-encryption process is the "value" > of the content being > enveloped." In my opinion, this sentence is not needed > and is confusing. > For example, when encrypting an ASN.1 encoded content, > an implementer might > interpret this statement to mean that the tag and > length octets of the ASN.1 > encoded content should not be encrypted. I still > believe that the first > paragraph is fine [..] and that the second paragraph > should be deleted. > > Finally, the second paragraph of section 6.3 was removed in > the new RFC 3369, and no mention to the input of the > content-encryption process remains. > > From John's words, I understand that if we want to nest a > SignedData into an EnvelopedData, we shall encrypt the whole > BER encoded SignedData (including tag and length octets). > This is incompatible with PKCS#7 (RFC 2315), where it is > clearly stated that only the content octets of the BER > encoding are encrypted. I need to be sure that this is the > intended meaning, because there is a whole section (5.2.1) in > RFC 3369 explaining the incompatibility of SignedData in CMS > and PKCS#7, but nothing is said about the incompatibility of > encrypted contents. > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LGxYAF041397 for ; Wed, 21 May 2003 09:59:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4LGxYEL041396 for ietf-smime-bks; Wed, 21 May 2003 09:59:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from yuha.menta.net (yuha.menta.net [212.78.128.42]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LGxWAF041391 for ; Wed, 21 May 2003 09:59:33 -0700 (PDT) (envelope-from luciano.medina@safelayer.com) Received: from gibson.menta.net ([212.78.128.22]) by yuha.menta.net (Netscape Messaging Server 4.15) with ESMTP id HF8XX401.BH6 for ; Wed, 21 May 2003 19:00:40 +0200 Received: from bcn.safelayer.com ([212.78.132.129]) by gibson.menta.net (Netscape Messaging Server 4.15 gibson Mar 14 2002 21:29:48) with ESMTP id HF8Y1201.CHC for ; Wed, 21 May 2003 19:03:02 +0200 Subject: Input to content-encryption process in CMS To: ietf-smime@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: luciano.medina@safelayer.com Date: Wed, 21 May 2003 19:00:49 +0200 X-MIMETrack: Serialize by Router on Bcn/SFLY(Release 5.0.12 |February 13, 2003) at 21/05/2003 19:00:50 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: In section 6.3 "Content-encryption Process" of obsolete RFC 2630 "Cryptographic Message Syntax (CMS)", the second paragraph describes the input to the content-encryption process. It is resumed in the sentence: The input to the content-encryption process is the "value" of the content being enveloped There was some discussion on this topic between Russ Housley and John Pawling on the mailing list. The latter wrote: 29) Section 6.3, para 2: You want to preserve the following sentence: "The input to the content-encryption process is the "value" of the content being enveloped." In my opinion, this sentence is not needed and is confusing. For example, when encrypting an ASN.1 encoded content, an implementer might interpret this statement to mean that the tag and length octets of the ASN.1 encoded content should not be encrypted. I still believe that the first paragraph is fine [..] and that the second paragraph should be deleted. Finally, the second paragraph of section 6.3 was removed in the new RFC 3369, and no mention to the input of the content-encryption process remains. >From John's words, I understand that if we want to nest a SignedData into an EnvelopedData, we shall encrypt the whole BER encoded SignedData (including tag and length octets). This is incompatible with PKCS#7 (RFC 2315), where it is clearly stated that only the content octets of the BER encoding are encrypted. I need to be sure that this is the intended meaning, because there is a whole section (5.2.1) in RFC 3369 explaining the incompatibility of SignedData in CMS and PKCS#7, but nothing is said about the incompatibility of encrypted contents. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4KBUvAF025296 for ; Tue, 20 May 2003 04:30:57 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4KBUvmo025295 for ietf-smime-bks; Tue, 20 May 2003 04:30:57 -0700 (PDT) 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.9/8.12.8) with ESMTP id h4KBUuAF025285 for ; Tue, 20 May 2003 04:30:56 -0700 (PDT) (envelope-from nsyracus@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 HAA06426; Tue, 20 May 2003 07:27:49 -0400 (EDT) Message-Id: <200305201127.HAA06426@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-cms-rsa-kem-00.txt Date: Tue, 20 May 2003 07:27:48 -0400 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 : Use of the RSA-KEM Key Transport Algorithm in CMS Author(s) : B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-00.txt Pages : 15 Date : 2003-5-19 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-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-cms-rsa-kem-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-cms-rsa-kem-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: <2003-5-19145849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsa-kem-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-19145849.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4DC3ei2010159 for ; Tue, 13 May 2003 05:03:40 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4DC3euY010158 for ietf-smime-bks; Tue, 13 May 2003 05:03:40 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h4DC3di2010153 for ; Tue, 13 May 2003 05:03:39 -0700 (PDT) (envelope-from nsyracus@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 IAA05349; Tue, 13 May 2003 08:00:36 -0400 (EDT) Message-Id: <200305131200.IAA05349@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-x400transport-07.txt Date: Tue, 13 May 2003 08:00:36 -0400 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 : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-07.txt Pages : 6 Date : 2003-5-12 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-07.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-x400transport-07.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-x400transport-07.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: <2003-5-12152702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-12152702.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CHV8i2029486 for ; Mon, 12 May 2003 10:31:08 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4CHV8i9029485 for ietf-smime-bks; Mon, 12 May 2003 10:31:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.109]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4CHV6i2029476 for ; Mon, 12 May 2003 10:31:08 -0700 (PDT) (envelope-from BonattiC@ieca.com) Received: from OMNI (pcp833894pcs.nrockv01.md.comcast.net [68.50.112.83]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HES00CFJB7I15@mtaout05.icomcast.net> for ietf-smime@imc.org; Mon, 12 May 2003 13:28:30 -0400 (EDT) Date: Mon, 12 May 2003 13:28:29 -0400 From: "Bonatti, Chris" Subject: New I-D draft-ietf-smime-x400transport-07 Just Posted In-reply-to: <003e01c313d6$646beeb0$025fe541@ieca.com> To: ietf-smime@imc.org Reply-to: BonattiC@ieca.com Message-id: <001a01c318ab$e774c690$0400a8c0@ieca.com> Organization: IECA, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have just reposted the x400transport draft incorporating corrections to the errata noted by Arun Pandey. I don't know how I managed to create the bug in 2.2.1, but I was able to recover some once-upon-a-time text from about a year ago that I think addresses the issue. The other concern that Arun pointed out was a simple typo, but with potential interoperability ramifications. This issue of the draft also rolls back the names of the smime-type and EIT values from "certificate management" to "certs-only". This is to align with rfc2633bis and rfc2632bis which have decided to stick with certs-only to avoid confusion in backward compatibility. Strictly, we could have stuck with an EIT called certificate management since there is no backward compatibility impact to that. However, I think that would have had a high confusion quotient so I rolled the whole thing back. Btw, the -06 issue of x400transport (which I neglected to introduce when it came out) added the smime-type and EIT for the compressed-data content type as per April's discussion on the WG list. The x400wrap draft was updated to issue -06 merely to refresh it in the I-D repository. I don't plan to reissue an -07 of this unless there is a problem noted. Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48JL1i2092127 for ; Thu, 8 May 2003 12:21:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48JL1kC092126 for ietf-smime-bks; Thu, 8 May 2003 12:21:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from gghqex3.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48JKui2092109; Thu, 8 May 2003 12:21:00 -0700 (PDT) (envelope-from John.Pawling@DigitalNet.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Who has tried some or all of the S/MIME examples? Date: Thu, 8 May 2003 15:20:57 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Who has tried some or all of the S/MIME examples? Thread-Index: AcMVlKcg8DWOaq3GQvSWovPQnHulXgAAg8xg From: "Pawling, John" To: "Russ Housley" , , Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h48JL0i3092116 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, DigitalNet agrees with Russ, Blake and Jim. We will generate a new example 5.1 message that includes the id-dsa-with-sha1 OID. ==================================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet (formerly Getronics Government Solutions) =================================================== -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, May 08, 2003 2:47 PM To: blake@brutesquadlabs.com; phoffman@imc.org Cc: ietf-smime@imc.org; ietf-smime-examples@imc.org Subject: RE: Who has tried some or all of the S/MIME examples? I believe that we should be using id-dsa-with-sha1. Russ > > 5.1.bin - failed > > 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 > > From RFC3370, section 3.1: > > The algorithm identifier for DSA with SHA-1 signature values is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > When the id-dsa-with-sha1 algorithm identifier is used, the > AlgorithmIdentifier parameters field MUST be absent. > > > From RFC2630, section 12.2.1: > > The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is > always used with the SHA-1 message digest algorithm. The algorithm > identifier for DSA is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > The AlgorithmIdentifier parameters field must not be present. > > > From RFC2633, section 2.2: > > Sending and receiving agents MUST support id-dsa defined in [DSS]. > The algorithm parameters MUST be absent (not encoded as NULL). > > > From RFC2633, Appendix A: > > -- id-dsa OBJECT IDENTIFIER ::= > -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } > > > From rfc2633bis-03: > > Receiving agents MUST support id-dsa defined in [CMSALG]. The > algorithm parameters MUST be absent (not encoded as NULL). > Receiving agents MUST support rsaEncryption, defined in [CMSALG]. > > > From RFC3370, section 3.1: > > id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 1 } > > > So the bottom line is that CMS says one thing > (id-dsa-with-sha1), and MSG says something else (id-dsa). > Consensus welcome. We went round and round about this at one > point, due to the use of the rsaEncryption value vs. the use > of the sha-1WithRSAEncryption value. > > Recommend accept both, emit id-dsa-with-sha1, change the > samples to use id-dsa-with-sha1 and changing rfc2633bis to say: > > > 2.2 SignatureAlgorithmIdentifier > > Receiving agents MUST support id-dsa-with-sha1 defined in > [CMSALG]. The algorithm parameters MUST be absent (not > encoded as NULL). Receiving agents MUST support > rsaEncryption, defined in [CMSALG]. > > Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. > > Note that S/MIME v3 clients might only implement signing or > signature verification using id-dsa-with-sha1, and might also > use id-dsa as an AlgorithmIdentifier in this field. Receiving > clients SHOULD recognize id-dsa as equivalent to > id-dsa-with-sha1, and sending clients MUST use > id-dsa-with-sha1 if using that algorithm. Also note that > S/MIME v2 clients are only capable of verifying digital > signatures using the rsaEncryption algorithm. > > Blake > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48IlWi2090478 for ; Thu, 8 May 2003 11:47:32 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48IlWjH090475 for ietf-smime-bks; Thu, 8 May 2003 11:47:32 -0700 (PDT) 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 [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h48IlUi2090461 for ; Thu, 8 May 2003 11:47:30 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 22230 invoked by uid 0); 8 May 2003 18:46:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.213.219) by woodstock.binhost.com with SMTP; 8 May 2003 18:46:45 -0000 Message-Id: <5.2.0.9.2.20030508144507.0399e158@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 08 May 2003 14:47:23 -0400 To: blake@brutesquadlabs.com, phoffman@imc.org From: Russ Housley Subject: RE: Who has tried some or all of the S/MIME examples? Cc: ietf-smime@imc.org, ietf-smime-examples@imc.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: I believe that we should be using id-dsa-with-sha1. Russ > > 5.1.bin - failed > > 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 > > From RFC3370, section 3.1: > > The algorithm identifier for DSA with SHA-1 signature values is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > When the id-dsa-with-sha1 algorithm identifier is used, the > AlgorithmIdentifier parameters field MUST be absent. > > > From RFC2630, section 12.2.1: > > The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is > always used with the SHA-1 message digest algorithm. The algorithm > identifier for DSA is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > The AlgorithmIdentifier parameters field must not be present. > > > From RFC2633, section 2.2: > > Sending and receiving agents MUST support id-dsa defined in [DSS]. > The algorithm parameters MUST be absent (not encoded as NULL). > > > From RFC2633, Appendix A: > > -- id-dsa OBJECT IDENTIFIER ::= > -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } > > > From rfc2633bis-03: > > Receiving agents MUST support id-dsa defined in [CMSALG]. The > algorithm parameters MUST be absent (not encoded as NULL). > Receiving agents MUST support rsaEncryption, defined in [CMSALG]. > > > From RFC3370, section 3.1: > > id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 1 } > > > So the bottom line is that CMS says one thing > (id-dsa-with-sha1), and MSG says something else (id-dsa). > Consensus welcome. We went round and round about this at one > point, due to the use of the rsaEncryption value vs. the use > of the sha-1WithRSAEncryption value. > > Recommend accept both, emit id-dsa-with-sha1, change the > samples to use id-dsa-with-sha1 and changing rfc2633bis to say: > > > 2.2 SignatureAlgorithmIdentifier > > Receiving agents MUST support id-dsa-with-sha1 defined in > [CMSALG]. The algorithm parameters MUST be absent (not > encoded as NULL). Receiving agents MUST support > rsaEncryption, defined in [CMSALG]. > > Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. > > Note that S/MIME v3 clients might only implement signing or > signature verification using id-dsa-with-sha1, and might also > use id-dsa as an AlgorithmIdentifier in this field. Receiving > clients SHOULD recognize id-dsa as equivalent to > id-dsa-with-sha1, and sending clients MUST use > id-dsa-with-sha1 if using that algorithm. Also note that > S/MIME v2 clients are only capable of verifying digital > signatures using the rsaEncryption algorithm. > > Blake > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h48H99i2087031 for ; Thu, 8 May 2003 10:09:09 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h48H99Qq087030 for ietf-smime-bks; Thu, 8 May 2003 10:09:09 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h48H97i2087014; Thu, 8 May 2003 10:09:07 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip171.126-173-207.eli-du.nwlink.com [207.173.126.171]) by smtp2.pacifier.net (Postfix) with ESMTP id 6C19F6A65A; Thu, 8 May 2003 10:09:05 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , "'Paul Hoffman / IMC'" , , Subject: RE: Who has tried some or all of the S/MIME examples? Date: Thu, 8 May 2003 10:09:07 -0700 Message-ID: <000901c31584$8a9c95d0$ab7eadcf@soaringhawk.net> 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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Having looked at the back history of the last argument. It appears that Blake argued that the correct think was to use id-dsa-with-sha1 and get over the fact that it's not consistant with the use of rsa-encryption. Thus I think that Blake's solution below is correct and the examples should be corrected to be "Correct". Jim > -----Original Message----- > From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] > Sent: Wednesday, May 07, 2003 4:00 PM > To: jimsch@exmsft.com; 'Paul Hoffman / IMC'; > ietf-smime@imc.org; ietf-smime-examples@imc.org > Subject: RE: Who has tried some or all of the S/MIME examples? > > > > -----Original Message----- > > From: Jim Schaad [mailto:jimsch@nwlink.com] > > Sent: Wednesday, May 07, 2003 2:13 PM > > To: 'Blake Ramsdell'; 'Paul Hoffman / IMC'; > > ietf-smime@imc.org; ietf-smime-examples@imc.org > > Subject: RE: Who has tried some or all of the S/MIME examples? > > > > 5.1.bin - failed > > 1. signatureAlgorithm is 1.2.840.10040.4.1 not > 1.2.840.10040.4.3 > > From RFC3370, section 3.1: > > The algorithm identifier for DSA with SHA-1 signature values is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > When the id-dsa-with-sha1 algorithm identifier is used, the > AlgorithmIdentifier parameters field MUST be absent. > > > From RFC2630, section 12.2.1: > > The DSA signature algorithm is defined in FIPS Pub 186 > [DSS]. DSA is > always used with the SHA-1 message digest algorithm. The algorithm > identifier for DSA is: > > id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 3 } > > The AlgorithmIdentifier parameters field must not be present. > > > From RFC2633, section 2.2: > > Sending and receiving agents MUST support id-dsa defined in [DSS]. > The algorithm parameters MUST be absent (not encoded as NULL). > > > From RFC2633, Appendix A: > > -- id-dsa OBJECT IDENTIFIER ::= > -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } > > > From rfc2633bis-03: > > Receiving agents MUST support id-dsa defined in [CMSALG]. The > algorithm parameters MUST be absent (not encoded as NULL). > Receiving agents MUST support rsaEncryption, defined in [CMSALG]. > > > From RFC3370, section 3.1: > > id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) x9-57 (10040) x9cm(4) 1 } > > > So the bottom line is that CMS says one thing > (id-dsa-with-sha1), and MSG says something else (id-dsa). > Consensus welcome. We went round and round about this at one > point, due to the use of the rsaEncryption value vs. the use > of the sha-1WithRSAEncryption value. > > Recommend accept both, emit id-dsa-with-sha1, change the > samples to use id-dsa-with-sha1 and changing rfc2633bis to say: > > > 2.2 SignatureAlgorithmIdentifier > > Receiving agents MUST support id-dsa-with-sha1 defined in > [CMSALG]. The algorithm parameters MUST be absent (not > encoded as NULL). Receiving agents MUST support > rsaEncryption, defined in [CMSALG]. > > Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. > > Note that S/MIME v3 clients might only implement signing or > signature verification using id-dsa-with-sha1, and might also > use id-dsa as an AlgorithmIdentifier in this field. Receiving > clients SHOULD recognize id-dsa as equivalent to > id-dsa-with-sha1, and sending clients MUST use > id-dsa-with-sha1 if using that algorithm. Also note that > S/MIME v2 clients are only capable of verifying digital > signatures using the rsaEncryption algorithm. > > Blake > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47N2Ei2005691 for ; Wed, 7 May 2003 16:02:14 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47N2Enf005684 for ietf-smime-bks; Wed, 7 May 2003 16:02:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47N2Bi2005636 for ; Wed, 7 May 2003 16:02:11 -0700 (PDT) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (12-208-8-45.client.attbi.com [12.208.8.45]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HEJ00DEXHA4G1@mtaout04.icomcast.net> for ietf-smime@imc.org; Wed, 07 May 2003 19:01:17 -0400 (EDT) Date: Wed, 07 May 2003 16:01:13 -0700 From: Trevor Perrin Subject: Re: authenticated encryption In-reply-to: <5.2.0.9.2.20030506133007.03243b90@mail.binhost.com> X-Sender: trevp00@pop.comcast.net To: Russ Housley , ietf-smime@imc.org Message-id: <5.2.0.9.0.20030507152401.02fad560@pop.comcast.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.net> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 01:43 PM 5/6/2003 -0400, Russ Housley wrote: >Presently, if you want integrity, then a signature is required, which >defeats the attack that is described. I would be interested in looking >into the use of CCM, EAX, CWC, or any other authenticated encryption mode >AFTER the update to RFC 2633 is published. I would not like to delay >publication of the update while this is investigated. makes sense. As far as the attack, let's call that a typo where I meant to say: There may be reason to use authenticated-encryption even when signing-then-encrypting. An attacker could tamper with the CBC-encrypted ciphertext. Since ASN.1 parsing of the decrypted plaintext needs to occur before signature verification, if the attacker could distinguish different parsing failures, or distinguish a parsing failure from a signature-verification failure (by observing timings or error messages from a server, for example) he could possibly learn something about the plaintext. Example: The attacker copies some ciphertext block C[x] over C[y]. The attacker then adjusts C[y-1] so that P[y] will decrypt properly, if his guess about P[x] and P[y] is correct. As a result of these changes, P[y-1] and P[y+1] will decrypt randomly. However if he chooses y so that P[y-1] and P[y+1] are allowed to be random data (within the SignedInfo, they might be the content, signature, or SubjectKeyIdentifier blocks), but P[y] has an ASN.1 structure that has to be parsed correctly, then he can possibly verify guesses about P[x] xor P[y] by differentiating between parsing and signature verification failures (or whatever type of failure is caused by damaging P[y-1] and P[y+1]). Is this possible? I don't know, depends on all sorts of things (cipher blocksize, the size of the various SignedInfo OIDs, hash values, and signed attributes, how the recipient handles errors, etc.).. Maybe it's not worth worrying about, but authenticated-encryption would eliminate any concern. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47Mxri2005291 for ; Wed, 7 May 2003 15:59:53 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47MxrUX005290 for ietf-smime-bks; Wed, 7 May 2003 15:59:53 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h47Mxqi2005277; Wed, 7 May 2003 15:59:52 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 7 May 2003 15:59:49 -0700 From: "Blake Ramsdell" To: , "'Paul Hoffman / IMC'" , , Subject: RE: Who has tried some or all of the S/MIME examples? Date: Wed, 7 May 2003 15:59:49 -0700 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 In-Reply-To: <000001c314dd$6404f400$1700a8c0@soaringhawk.net> 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: > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Wednesday, May 07, 2003 2:13 PM > To: 'Blake Ramsdell'; 'Paul Hoffman / IMC'; > ietf-smime@imc.org; ietf-smime-examples@imc.org > Subject: RE: Who has tried some or all of the S/MIME examples? > > 5.1.bin - failed > 1. signatureAlgorithm is 1.2.840.10040.4.1 not > 1.2.840.10040.4.3 >From RFC3370, section 3.1: The algorithm identifier for DSA with SHA-1 signature values is: id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } When the id-dsa-with-sha1 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent. >From RFC2630, section 12.2.1: The DSA signature algorithm is defined in FIPS Pub 186 [DSS]. DSA is always used with the SHA-1 message digest algorithm. The algorithm identifier for DSA is: id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } The AlgorithmIdentifier parameters field must not be present. >From RFC2633, section 2.2: Sending and receiving agents MUST support id-dsa defined in [DSS]. The algorithm parameters MUST be absent (not encoded as NULL). >From RFC2633, Appendix A: -- id-dsa OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } >From rfc2633bis-03: Receiving agents MUST support id-dsa defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG]. >From RFC3370, section 3.1: id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 1 } So the bottom line is that CMS says one thing (id-dsa-with-sha1), and MSG says something else (id-dsa). Consensus welcome. We went round and round about this at one point, due to the use of the rsaEncryption value vs. the use of the sha-1WithRSAEncryption value. Recommend accept both, emit id-dsa-with-sha1, change the samples to use id-dsa-with-sha1 and changing rfc2633bis to say: 2.2 SignatureAlgorithmIdentifier Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The algorithm parameters MUST be absent (not encoded as NULL). Receiving agents MUST support rsaEncryption, defined in [CMSALG]. Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. Note that S/MIME v3 clients might only implement signing or signature verification using id-dsa-with-sha1, and might also use id-dsa as an AlgorithmIdentifier in this field. Receiving clients SHOULD recognize id-dsa as equivalent to id-dsa-with-sha1, and sending clients MUST use id-dsa-with-sha1 if using that algorithm. Also note that S/MIME v2 clients are only capable of verifying digital signatures using the rsaEncryption algorithm. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h47LCgi2001808 for ; Wed, 7 May 2003 14:12:42 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h47LCgY6001807 for ietf-smime-bks; Wed, 7 May 2003 14:12:42 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h47LCdi2001787; Wed, 7 May 2003 14:12:39 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 2692A6D7C8; Wed, 7 May 2003 14:12:36 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , "'Paul Hoffman / IMC'" , , Subject: RE: Who has tried some or all of the S/MIME examples? Date: Wed, 7 May 2003 14:12:31 -0700 Message-ID: <000001c314dd$6404f400$1700a8c0@soaringhawk.net> 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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The files I have worked with so far: 4.1.bin - passed 4.2.bin - passed 5.1.bin - failed 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 5.2.bin - passed 5.4.bin - failed 1. Contains Alice's RSA certificate 2. No content hint unsigned attribute 3. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 5.5.bin - passed 5.6.bin - failed 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 5.7.bin - failed 1. signatureAlgorithm is 1.2.840.10040.4.1 not 1.2.840.10040.4.3 5.10.bin - failed 1. Change "unknown OID" to "unknown OID (1.2.5555)" 2. Content Hint should have an OID of 1.2.840.113549.1.7.1 3. Content Identifier attribute absent 4. Contains Security Label attribute 5. Contains encrypt key preference attribute 6. Contains ML Expansion History attribute 7. Contains Equivalent Label attribute Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Blake Ramsdell > Sent: Tuesday, May 06, 2003 5:26 PM > To: 'Paul Hoffman / IMC'; ietf-smime@imc.org; > ietf-smime-examples@imc.org > Subject: RE: Who has tried some or all of the S/MIME examples? > > > > > -----Original Message----- > > From: owner-ietf-smime-examples@mail.imc.org > > [mailto:owner-ietf-smime-examples@mail.imc.org] On Behalf Of > > Paul Hoffman / IMC > > Sent: Sunday, May 04, 2003 3:11 PM > > To: ietf-smime@imc.org; ietf-smime-examples@imc.org > > Subject: Who has tried some or all of the S/MIME examples? > > > > Greetings again. The WG chairs have announced that we are in the WG > > last call for draft-ietf-smime-examples-10.txt. As editor of the > > document, I'd like to find out who has looked at the > examples in this > > particular draft and/or tried them out? If you have done so, could > > you send a list of the examples you have reviewed and a short > > description of how you reviewed them? You can send it to me > > personally, or to the two lists. Please post even if you have seen > > other people post about the same examples: we want to know how deep > > our coverage is. Thanks! > > The files I have worked with: > > 5.1.bin -- Identified as a CMS SignedData with signatures and > content, checked certificates were present, matched content > to ExContent.bin, verified one signer > > 5.2.bin -- Checked certificates were present, matched content > to ExContent.bin, verified one signer > > 5.3.bin -- Identified as a CMS SignedData with signatures and > no content, checked certificates were present, verified one > signer against external content in ExContent.bin > > 5.4.bin -- Extracted signing time attribute, checked > certificates were present, checked CRLs were present, matched > content to ExContent.bin, verified one signer > > 5.5.bin -- Checked certificates were present, matched content > to ExContent.bin, verified one signer > > 5.6.bin -- Checked certificates were present, matched content > to ExContent.bin, verified two signers > > 5.7.bin -- Checked certificates were present, matched content > to ExContent.bin, verified one signer > > 5.8.eml -- Parsed content with MIME parser, matched extracted > text content from text part to ExContent.bin, checked > certificates were present, verified one signer against first > part of message, identified as a CMS SignedData with > signatures and no content > > 5.9.eml -- Parsed content with MIME parser, matched extracted > text content from text part to ExContent.bin, checked > certificates were present, verified one signer, identified as > a CMS SignedData with signatures and content > > 5.10.bin -- Matched content to ExContent.bin, verified one signer > > 5.11.bin -- Identified as a CMS SignedData with no signatures > and no content, checked certificates were present > > 6.2.bin -- Decrypted message, matched content to > ExContent.bin, identified as a CMS EnvelopedData > > 6.3.bin -- Decrypted message, matched content to ExContent.bin > > 7.0.bin -- Verified hash, matched content to ExContent.bin > > 8.1.bin -- Decrypted data with given key, matched content to > ExContent.bin > > > I also worked with the following certificates and private keys: > > AliceDSSSignByCarlNoInherit.cer > AlicePrivRSASign.pri > AliceRSASignByCarl.cer > BobPrivRSAEncrypt.pri > BobRSASignByCarl.cer > CarlDSSCRLForAll.crl > CarlDSSSelf.cer > CarlPrivDSSSign.pri > CarlPrivRSASign.pri > CarlRSASelf.cer > DianeDHEncryptByCarl.cer > DianeDSSSignByCarlInherit.cer > DianePrivRSASignEncrypt.pri > DianeRSASignByCarl.cer > EricaDHEncryptByCarl.cer > > Blake > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4743li2015136 for ; Tue, 6 May 2003 21:03:47 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4743ln4015135 for ietf-smime-bks; Tue, 6 May 2003 21:03:47 -0700 (PDT) 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 [207.228.252.5]) by above.proper.com (8.12.8p1/8.12.8) with SMTP id h4743hi2015125 for ; Tue, 6 May 2003 21:03:44 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 3502 invoked by uid 0); 7 May 2003 04:03:02 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (64.134.126.45) by woodstock.binhost.com with SMTP; 7 May 2003 04:03:02 -0000 Message-Id: <5.2.0.9.2.20030506133007.03243b90@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 06 May 2003 13:43:16 -0400 To: Trevor Perrin , ietf-smime@imc.org From: Russ Housley Subject: Re: authenticated encryption In-Reply-To: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.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: Presently, if you want integrity, then a signature is required, which defeats the attack that is described. I would be interested in looking into the use of CCM, EAX, CWC, or any other authenticated encryption mode AFTER the update to RFC 2633 is published. I would not like to delay publication of the update while this is investigated. Russ Security Area Director At 05:01 PM 5/5/2003 -0700, Trevor Perrin wrote: >Hello S/MIME, > >I'm curious what this group thinks about adopting an >authenticated-encryption cipher mode, such as: > >EAX: >https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00223.html >CWC: >https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00224.html > >Such a mode could integrity-protect S/MIME encrypted-only messages. It >could also defend against an oracle attack on signed-then-CBC-encrypted >messages. I'm not sure this attack is well known, so I'll describe it: > >If the plaintext is a sequence of blocks P[1],P[2],.., and the ciphertext >is a sequence of blocks where C[0] is the IV, followed by C[1],C[2],.., >then we assume the attacker wants to verify a guess G for P[X], and knows >the value of P[1] (the first blocksize bytes of the ContentInfo containing >SignedData, which is just well-known ASN.1 header). > >The attacker copies C[X] over C[1], and sets C[0] = G xor C[X-1] xor >P[1]. If his guess is correct, then the new ciphertext C[1] will decrypt >to the same plaintext P[1] it would have without his modifications - if >his guess if wrong, the decrypted P[1] will have bit errors, which will >probably cause an error in the recipient's software. > >If the recipient is a person, she might respond saying "I can't read >this". If the recipient is a server (like an S/MIME MTA), it might >respond with an error message, allowing the attack to be iterated. > >Might solving these issues in one swoop be a good rationale for >authenticated encryption? > >Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h470Q7i2008931 for ; Tue, 6 May 2003 17:26:07 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h470Q7Jn008930 for ietf-smime-bks; Tue, 6 May 2003 17:26:07 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h470Q6i2008920; Tue, 6 May 2003 17:26:06 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Tue, 6 May 2003 17:26:03 -0700 From: "Blake Ramsdell" To: "'Paul Hoffman / IMC'" , , Subject: RE: Who has tried some or all of the S/MIME examples? Date: Tue, 6 May 2003 17:26:03 -0700 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 In-Reply-To: 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: > -----Original Message----- > From: owner-ietf-smime-examples@mail.imc.org > [mailto:owner-ietf-smime-examples@mail.imc.org] On Behalf Of > Paul Hoffman / IMC > Sent: Sunday, May 04, 2003 3:11 PM > To: ietf-smime@imc.org; ietf-smime-examples@imc.org > Subject: Who has tried some or all of the S/MIME examples? > > Greetings again. The WG chairs have announced that we are in the WG > last call for draft-ietf-smime-examples-10.txt. As editor of the > document, I'd like to find out who has looked at the examples in this > particular draft and/or tried them out? If you have done so, could > you send a list of the examples you have reviewed and a short > description of how you reviewed them? You can send it to me > personally, or to the two lists. Please post even if you have seen > other people post about the same examples: we want to know how deep > our coverage is. Thanks! The files I have worked with: 5.1.bin -- Identified as a CMS SignedData with signatures and content, checked certificates were present, matched content to ExContent.bin, verified one signer 5.2.bin -- Checked certificates were present, matched content to ExContent.bin, verified one signer 5.3.bin -- Identified as a CMS SignedData with signatures and no content, checked certificates were present, verified one signer against external content in ExContent.bin 5.4.bin -- Extracted signing time attribute, checked certificates were present, checked CRLs were present, matched content to ExContent.bin, verified one signer 5.5.bin -- Checked certificates were present, matched content to ExContent.bin, verified one signer 5.6.bin -- Checked certificates were present, matched content to ExContent.bin, verified two signers 5.7.bin -- Checked certificates were present, matched content to ExContent.bin, verified one signer 5.8.eml -- Parsed content with MIME parser, matched extracted text content from text part to ExContent.bin, checked certificates were present, verified one signer against first part of message, identified as a CMS SignedData with signatures and no content 5.9.eml -- Parsed content with MIME parser, matched extracted text content from text part to ExContent.bin, checked certificates were present, verified one signer, identified as a CMS SignedData with signatures and content 5.10.bin -- Matched content to ExContent.bin, verified one signer 5.11.bin -- Identified as a CMS SignedData with no signatures and no content, checked certificates were present 6.2.bin -- Decrypted message, matched content to ExContent.bin, identified as a CMS EnvelopedData 6.3.bin -- Decrypted message, matched content to ExContent.bin 7.0.bin -- Verified hash, matched content to ExContent.bin 8.1.bin -- Decrypted data with given key, matched content to ExContent.bin I also worked with the following certificates and private keys: AliceDSSSignByCarlNoInherit.cer AlicePrivRSASign.pri AliceRSASignByCarl.cer BobPrivRSAEncrypt.pri BobRSASignByCarl.cer CarlDSSCRLForAll.crl CarlDSSSelf.cer CarlPrivDSSSign.pri CarlPrivRSASign.pri CarlRSASelf.cer DianeDHEncryptByCarl.cer DianeDSSSignByCarlInherit.cer DianePrivRSASignEncrypt.pri DianeRSASignByCarl.cer EricaDHEncryptByCarl.cer Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46IWxi2095757 for ; Tue, 6 May 2003 11:32:59 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46IWxcP095756 for ietf-smime-bks; Tue, 6 May 2003 11:32:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46IWvi2095750 for ; Tue, 6 May 2003 11:32:57 -0700 (PDT) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (12-208-8-45.client.attbi.com [12.208.8.45]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HEH00JCLA5MM3@mtaout04.icomcast.net> for ietf-smime@imc.org; Tue, 06 May 2003 14:32:11 -0400 (EDT) Date: Tue, 06 May 2003 11:32:11 -0700 From: Trevor Perrin Subject: Re: authenticated encryption In-reply-to: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.net> X-Sender: trevp00@pop.comcast.net To: ietf-smime@imc.org Message-id: <5.2.0.9.0.20030506112623.02fe9c00@pop.comcast.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 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: At 05:01 PM 5/5/2003 -0700, Trevor Perrin wrote: >Hello S/MIME, > >I'm curious what this group thinks about adopting an >authenticated-encryption cipher mode, such as: > >EAX: >https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00223.html >CWC: >https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00224.html > >Such a mode could integrity-protect S/MIME encrypted-only messages. It >could also defend against an oracle attack on signed-then-CBC-encrypted >messages. I'm not sure this attack is well known, so I'll describe it: > >If the plaintext is a sequence of blocks P[1],P[2],.., and the ciphertext >is a sequence of blocks where C[0] is the IV, followed by C[1],C[2],.., >then we assume the attacker wants to verify a guess G for P[X], and knows >the value of P[1] (the first blocksize bytes of the ContentInfo containing >SignedData, which is just well-known ASN.1 header). > >The attacker copies C[X] over C[1], and sets C[0] = G xor C[X-1] xor >P[1]. If his guess is correct, then the new ciphertext C[1] will decrypt >to the same plaintext P[1] it would have without his modifications - if >his guess if wrong, the decrypted P[1] will have bit errors, which will >probably cause an error in the recipient's software. well, I got this wrong - whether the attacker's guess is right or wrong, P[2] will also be damaged. Whether the attacker can differentiate these failures, or other similar parsing failures he can induce by rearranging blocks (i.e. by copying C[X] over some other block besides C[1]), I suppose is implementation-dependent, or at least difficult to work out.. authenticated-encryption would at least remove any concerns on these lines. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46IKKi2095361 for ; Tue, 6 May 2003 11:20:20 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46IKK4H095360 for ietf-smime-bks; Tue, 6 May 2003 11:20:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from gghqex3.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46IKJi2095353; Tue, 6 May 2003 11:20:19 -0700 (PDT) (envelope-from John.Pawling@DigitalNet.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Who has tried some or all of the S/MIME examples? Date: Tue, 6 May 2003 14:20:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Who has tried some or all of the S/MIME examples? Thread-Index: AcMSi+RnwRWdtOZ8Ssy0yoLY7e4+KgBb7p0Q From: "Pawling, John" To: "Paul Hoffman / IMC" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h46IKKi3095354 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, DigitalNet has used the S/MIME Freeware Library (SFL) (and underlying libraries) to successfully process the vast majority of the examples in the draft-ietf-smime-examples-10.txt. This message includes the notes regarding our testing. We will send you corrected examples for sections 11.1 and 11.2. Test Results for S/MIME Examples-10: These tests were executed by DigitalNet using the S/MIME Freeware Library (SFL) and underlying libraries. Point of contact is Bob Colestock, Robert.Colestock@DigitalNet.com. (Note: Test numbers correspond to Examples-10 section numbers.) 4. ContentInfo Tests 4.1 ContentInfo with Data type, BER: Successfully ASN.1 decoded the BER-encoded ContentInfo sample in Examples document, but SFL can only create DER-encoded ContentInfo objects because the Enhanced SNACC library always uses DER to ASN.1 encode objects. 4.2 ContentInfo with Data type, DER: Successfully decoded sample in Examples document using SFL. 5. SignedData Tests 5.1 Basic signed content, DSS: Successfully verified signature of sample in Examples document using SFL. 5.2 Basic signed content, RSA: Successfully verified signature of sample in Examples document using SFL. 5.3 Basic signed content, detached content: Successfully verified signature of sample in Examples document using SFL. 5.4 Fancier signed content, Signed content with signed/unsigned attributes: Successfully verified signature of sample in Examples document using SFL. 5.5 All RSA signed message: Successfully verified signature of sample in Examples document using SFL. 5.6 Multiple DSS signatures: Successfully verified all of the signatures in the sample in the Examples document. 5.7 Signing using SKI: Successfully verified signature of sample in Examples document using SFL. 5.8 S/MIME multipart/signed message: Successfully verified signature of sample in Examples document using SFL. 5.9 S/MIME application/pkcs7-mime signed message: Successfully verified signature of sample in Examples document using SFL. 5.10 SignedData With Attributes: Successfully verified signature of sample in Examples document. 5.11 SignedData with Certificates Only: Successfully verified that there were no SignerInfos that were present or verified in the sample in the Examples document. 6. Enveloped-data Tests 6.1. Basic encrypted content, TripleDES and DH: Successfully used SFL to process this envelopedData sample. 6.2. Basic encrypted content, TripleDES and RSA: Successfully decrypted sample in Examples document using SFL. 6.3. Basic encrypted content, RC2/40 and RSA: Successfully decrypted sample in Examples document using SFL. 6.4. Encrypted content, two recipients, no shared keying material: Successfully used SFL to process the envelopedData sample. NOTE: Unsuccessful Invalid tag for privateKeyInfo for second login 6.5. Encrypted content, two recipients, shared keying material: Was unable to use the SFL to process the envelopedData sample because of an SFL bug related to processing shared UKMs. SFL will be fixed to be able to successfully process this message as it has in the past. 6.6. Encrypted content, TripleDES and DH, previously-distributed keys: Used SFL to successfully process the envelopedData sample. 6.7. Encrypted content, RC2/40 and RSA, previously-distributed keys: Used SFL to successfully process the envelopedData sample. 6.8. S/MIME application/pkcs7-mime encrypted message: Successfully used SFL to process the envelopedData sample. 6.9. EnvelopedData with All Recipient Types: Successfully used SFL to process the envelopedData sample for all recipient types KARI, KTRI, and KEKRI. 6.10. EnvelopedData with KARI RC2 Encryption: Successfully used SFL to process the envelopedData sample. 6.11. EnvelopedData with KEK 3DES Encryption: Successfully used SFL to process the envelopedData sample. 7. DigestedData: SFL does not support. 8. Encrypted-Data Tests: 8.1. Simple EncryptedData: Successfully used SFL to process the encryptedData sample. 8.2. EncryptedData with unprotected attributes: Successfully used SFL to process the encryptedData sample. 9. Authenticated-Data: SFL does not support. 10. Key Wrapping: Tests conducted as part of EnvelopedData testing. 11. ESS Examples 11.1 ReceiptRequest: Used SFL to successfully process the signedData including a receiptRequest attribute. Note that the 11.2 signedReceipt is supposed to be in response to the 11.1 signedData receiptRequest, but the examples-10 samples are incorrect. DigitalNet will provide new samples for 11.1 and 11.2 that are correct. 11.2 Receipt: Used SFL to successfully process the signedData including a receipt content type. NOTE - Unsuccessful - no match in signer info error 11.3 ESSSecurityLabel: Used SFL to successfully process the signedData including a ESSSecurityLabel signed attribute. 11.4 EquivalentLabels: Used SFL to successfully process the signedData including an EquivalentLabels signed attribute. 11.5 mlExpansionHistory: Used SFL to successfully process the signedData including an mlExpansionHistory signed attribute. 11.6 SigningCertificate: Used SFL to successfully process the signedData including a SigningCertificate signed attribute. ==================================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet (formerly Getronics Government Solutions) ====================================================   Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Do4i2076987 for ; Tue, 6 May 2003 06:50:04 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46Do4uv076986 for ietf-smime-bks; Tue, 6 May 2003 06:50:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mr3.ash.ops.us.uu.net (mr3.ash.ops.us.uu.net [198.5.241.88]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46Do3i2076975; Tue, 6 May 2003 06:50:03 -0700 (PDT) (envelope-from BonattiC@ieca.com) Received: from OMNI by mr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust2.tnt14.mia5.da.uu.net [65.229.95.2]) id QQonnb24015; Tue, 6 May 2003 13:50:00 GMT Reply-To: From: "Bonatti, Chris" To: "'Pandey, Arun'" Cc: , Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-06.txt : Comments Date: Tue, 6 May 2003 09:49:58 -0400 Organization: IECA, Inc. Message-ID: <003e01c313d6$646beeb0$025fe541@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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <177E503C4DA3D311BC9D0008C791C3060F3828F5@diexch01.xko.dec.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h46Do4i2076979 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Arun, You seem to be correct on both counts. I will try to correct and repost. If anybody thinks this isn't correct, please don't be shy. Chris -----Original Message----- From: Pandey, Arun [mailto:arun.pandey@digital.com] Sent: Tuesday, May 06, 2003 06:48 To: 'phoffman@imc.org'; 'bonattic@ieca.com' Cc: ietf-smime@imc.org Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-06.txt : Comments Hi, 1) In the draft-ietf-smime-x400transport-06.txt the contents of Section 2.2.1 are mere copy of Section 2.2. The Section heading of 2.2.1. is "Carrying Plaintext MIME objects as X.400 Content", whereas the content in the section is about "Carrying CMS object as X.400 Content". Could this please be corrected. 2) In section 2.3 "Carrying S/MIME as IPMS Body Parts", in the following sentence 'id-ep-content' should be replaced by 'id-et-content': The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-ep-content value and the following CMS-defined value. i.e. it should be: The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-et-content value and the following CMS-defined value. Best Regards Arun Pandey Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46AiNi2063228 for ; Tue, 6 May 2003 03:44:23 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46AiNwS063227 for ietf-smime-bks; Tue, 6 May 2003 03:44:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from zmamail03.zma.compaq.com (mailout.zma.compaq.com [161.114.64.103]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46AiLi2063218; Tue, 6 May 2003 03:44:21 -0700 (PDT) (envelope-from arun.pandey@digital.com) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 30BA51E6A; Tue, 6 May 2003 06:44:21 -0400 (EDT) Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 69E901651; Tue, 6 May 2003 05:44:18 -0500 (CDT) Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 May 2003 16:18:26 +0530 Message-ID: <177E503C4DA3D311BC9D0008C791C3060F3828F5@diexch01.xko.dec.com> From: "Pandey, Arun" To: "'phoffman@imc.org'" , "'bonattic@ieca.com'" Cc: ietf-smime@imc.org Subject: RE: I-D ACTION:draft-ietf-smime-x400transport-06.txt : Comments Date: Tue, 6 May 2003 16:18:18 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C313BD.0494FB08" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C313BD.0494FB08 Content-Type: text/plain; charset="iso-8859-1" Hi, 1) In the draft-ietf-smime-x400transport-06.txt the contents of Section 2.2.1 are mere copy of Section 2.2. The Section heading of 2.2.1. is "Carrying Plaintext MIME objects as X.400 Content", whereas the content in the section is about "Carrying CMS object as X.400 Content". Could this please be corrected. 2) In section 2.3 "Carrying S/MIME as IPMS Body Parts", in the following sentence 'id-ep-content' should be replaced by 'id-et-content': The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-ep-content value and the following CMS-defined value. i.e. it should be: The direct-reference field of the body part MUST include the OID formed by the concatenation of the id-et-content value and the following CMS-defined value. Best Regards Arun Pandey ------_=_NextPart_001_01C313BD.0494FB08 Content-Type: text/html; charset="iso-8859-1" RE: I-D ACTION:draft-ietf-smime-x400transport-06.txt : Comments

Hi,

1) In the draft-ietf-smime-x400transport-06.txt the contents of Section 2.2.1 are
   mere copy of Section 2.2. The Section heading of 2.2.1. is "Carrying Plaintext
   MIME objects as X.400 Content", whereas the content in the section is about
   "Carrying CMS object as X.400 Content". Could this please be corrected.

2) In section 2.3 "Carrying S/MIME as IPMS Body Parts", in the following
   sentence 'id-ep-content' should be replaced by 'id-et-content':

   The direct-reference field of the body part MUST include the OID formed by the
   concatenation of the id-ep-content value and the following CMS-defined value.

   i.e. it should be:
   The direct-reference field of the body part MUST include the OID formed by the
   concatenation of the id-et-content value and the following CMS-defined value.

Best Regards
Arun Pandey

------_=_NextPart_001_01C313BD.0494FB08-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h46630i2024884 for ; Mon, 5 May 2003 23:03:00 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h46630D1024883 for ietf-smime-bks; Mon, 5 May 2003 23:03:00 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h4662xi2024873 for ; Mon, 5 May 2003 23:02:59 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Mon, 5 May 2003 23:02:57 -0700 From: "Blake Ramsdell" To: , "'Ietf-Smime'" Subject: RE: PSS Document Question Date: Mon, 5 May 2003 23:02:57 -0700 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 In-Reply-To: <003b01c31024$04d83090$1700a8c0@soaringhawk.net> 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: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad > Sent: Thursday, May 01, 2003 1:56 PM > To: Ietf-Smime > Subject: PSS Document Question > > I would be happy with changing this from a SHOULD to a MUST, > but if this > is done it needs to propigate all of the way back to CMS. In the case of digestAlgorithms, the current language in CMS says that there MAY be any number of elements in the collection, but does not make any statement as far as MAY/MUST/SHOULD for whether or not these should map to the algorithms used for the signers ("The collection is intended to list the message digest algorithms employed by all of the signers, in any order, to facilitate one-pass signature verification"). Therefore, if you make it a MUST, I don't think you're overriding anything in CMS, only clarifying something that is unspecified. Your MUST wouldn't violate the "[t]here MAY be any number of elements in the collection, including zero" which is the only thing in CMS I found that talks about this. Anecdotally, my current S/MIME implementation ignores digestAlgorithms, since I'm using Java's security providers, and as far as I can tell there isn't a way to present just the completed digest and public key to the signature verification process -- you have to provide the *content* and public key (which might have parameters scattered up and down the cert chain, so you'd better make a cert chain while you're at it), and Java does the digesting internally as part of the signature verification. Sigh. So I ignore digestAlgorithms completely, since I can't use them, and just tough it out and do two passes. Personally, I consider "best current CMS practice" to be to always digest with every algorithm you know about and might reasonably encounter (so, digest with SHA-1, and if you're feeling saucy, digest with MD5 also), and ignore digestAlgorithms completely. For that matter, I feel this way about most informational fields that aren't tied directly to algorithm use (such as the "smime-type" parameter for S/MIME) -- ignore 'em and pretend like the guy that made 'em is probably lying anyway. It's just one less AlgorithmIdentifier to parse the wrong OID or parameters out of. So even if you made this a MUST, I'm not sure anyone should care, since the digestAlgorithm wording is so soft that the field does not have value. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4601hi2015258 for ; Mon, 5 May 2003 17:01:43 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h4601hUO015257 for ietf-smime-bks; Mon, 5 May 2003 17:01:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-out.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h4601gi2015248 for ; Mon, 5 May 2003 17:01:42 -0700 (PDT) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (12-208-8-45.client.attbi.com [12.208.8.45]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEF00MJKUQQIU@mtaout01.icomcast.net> for ietf-smime@imc.org; Mon, 05 May 2003 20:01:39 -0400 (EDT) Date: Mon, 05 May 2003 17:01:40 -0700 From: Trevor Perrin Subject: authenticated encryption X-Sender: trevp00@pop.comcast.net To: ietf-smime@imc.org Message-id: <5.2.0.9.0.20030505170135.034c6a40@pop.comcast.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 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: Hello S/MIME, I'm curious what this group thinks about adopting an authenticated-encryption cipher mode, such as: EAX: https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00223.html CWC: https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00224.html Such a mode could integrity-protect S/MIME encrypted-only messages. It could also defend against an oracle attack on signed-then-CBC-encrypted messages. I'm not sure this attack is well known, so I'll describe it: If the plaintext is a sequence of blocks P[1],P[2],.., and the ciphertext is a sequence of blocks where C[0] is the IV, followed by C[1],C[2],.., then we assume the attacker wants to verify a guess G for P[X], and knows the value of P[1] (the first blocksize bytes of the ContentInfo containing SignedData, which is just well-known ASN.1 header). The attacker copies C[X] over C[1], and sets C[0] = G xor C[X-1] xor P[1]. If his guess is correct, then the new ciphertext C[1] will decrypt to the same plaintext P[1] it would have without his modifications - if his guess if wrong, the decrypted P[1] will have bit errors, which will probably cause an error in the recipient's software. If the recipient is a person, she might respond saying "I can't read this". If the recipient is a server (like an S/MIME MTA), it might respond with an error message, allowing the attack to be iterated. Might solving these issues in one swoop be a good rationale for authenticated encryption? Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h45Mo1i2013048 for ; Mon, 5 May 2003 15:50:01 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h45Mo1OM013047 for ietf-smime-bks; Mon, 5 May 2003 15:50:01 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h45Mnxi2013037 for ; Mon, 5 May 2003 15:50:00 -0700 (PDT) (envelope-from jhargest@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 SAA20468; Mon, 5 May 2003 18:46:49 -0400 (EDT) Message-Id: <200305052246.SAA20468@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Use of the Camellia Encryption Algorithm in CMS to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 05 May 2003 18:46:49 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the Camellia Encryption Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-19. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-camellia-03.txt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h44MBSi2028450 for ; Sun, 4 May 2003 15:11:28 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h44MBSHe028449 for ietf-smime-bks; Sun, 4 May 2003 15:11:28 -0700 (PDT) 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]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h44MBQi3028444; Sun, 4 May 2003 15:11:26 -0700 (PDT) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 4 May 2003 15:11:21 -0700 To: ietf-smime@imc.org, ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Who has tried some or all of the S/MIME examples? 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. The WG chairs have announced that we are in the WG last call for draft-ietf-smime-examples-10.txt. As editor of the document, I'd like to find out who has looked at the examples in this particular draft and/or tried them out? If you have done so, could you send a list of the examples you have reviewed and a short description of how you reviewed them? You can send it to me personally, or to the two lists. Please post even if you have seen other people post about the same examples: we want to know how deep our coverage is. Thanks! --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42KI2i2065194 for ; Fri, 2 May 2003 13:18:02 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h42KI2jq065193 for ietf-smime-bks; Fri, 2 May 2003 13:18:02 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h42KI1i2065180 for ; Fri, 2 May 2003 13:18:01 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Fri, 2 May 2003 13:17:57 -0700 From: "Blake Ramsdell" To: "'Jim Craigie'" , Subject: RE: I-D ACTION:draft-ietf-smime-x400wrap-06.txt Date: Fri, 2 May 2003 13:17:57 -0700 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 In-Reply-To: <"CASQUETS:0f08-030502104232-002b*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS> 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: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Craigie > Sent: Friday, May 02, 2003 2:57 AM > To: ietf-smime@imc.org > Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-06.txt > > When is this going to become an RFC? Why the delay? There was an omission that was found after the working group finished it, so another version of the x400transport draft was required. The x400wrap and x400transport drafts are codependent, one can't progress without the other one to RFC status. It is not clear what the timeline is -- this depends on how fast the review of these documents goes, whether there's any more edits required, and then how backed up the RFC editor is. Russ will chime in if there's a better way to estimate the actual time. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h429kDi2028284 for ; Fri, 2 May 2003 02:46:13 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h429kDxp028283 for ietf-smime-bks; Fri, 2 May 2003 02:46:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from vercetti.clearswift.com (shannon.clearswift.com [194.205.99.125] (may be forged)) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h429kBi2028276 for ; Fri, 2 May 2003 02:46:12 -0700 (PDT) (envelope-from Jim.Craigie@clearswift.com) Received: from uk-msw-1.mimesweeper.com (mail.mimesweeper.com [10.44.30.35] (may be forged)) by vercetti.clearswift.com (4.9.4.16) with ESMTP id for ; Fri, 02 May 2003 10:47:49 +0100 Received: from orange.clearswift.com (unverified [10.44.30.11]) by uk-msw-1.mimesweeper.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 2 May 2003 10:46:03 +0100 Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.clearswift.com (Route400-RFCGate); Fri, 2 May 2003 10:57:30 +0100 X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 2 May 2003 10:57:30 +0100 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Fri, 2 May 2003 10:56:46 +0100 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:00b9-030502105646-000b] X400-Content-Type: P2-1988 (22) X400-Originator: Jim.Craigie@clearswift.com Original-Encoded-Information-Types: IA5-Text X400-Recipients: ietf-smime@imc.org Date: Fri, 2 May 2003 10:56:46 +0100 X400-Content-Identifier: Re: I-D ACTION:d Message-Id: <"CASQUETS:0f08-030502104232-002b*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS> From: Jim Craigie To: ietf-smime@imc.org In-Reply-To: <200305011925.PAA02662@ietf.org> Subject: Re: I-D ACTION:draft-ietf-smime-x400wrap-06.txt Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When is this going to become an RFC? Why the delay? > 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 : Securing X.400 Content with S/MIME > Author(s) : P. Hoffman, C. Bonatti, A. Eggen > Filename : draft-ietf-smime-x400wrap-06.txt > Pages : 11 > Date : 2003-5-1 > > This document describes a protocol for adding cryptographic signature > and encryption services to X.400 content. > --------------------------------------------------------------------------------------------------------------- Clearswift monitors, controls and protects all its messaging traffic in compliance with its corporate email policy using Clearswift products. Find out more about Clearswift, its solutions and services at www.clearswift.com. *********************************************************************************** This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift. If you have received this communication in error, please notify Clearswift by emailing support@clearswift.com quoting the sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain. This footnote confirms that this email message has been swept by MIMEsweeper for Content Security threats, including computer viruses. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h42053i2085499 for ; Thu, 1 May 2003 17:05:03 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h42053lW085498 for ietf-smime-bks; Thu, 1 May 2003 17:05:03 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h42052i2085489 for ; Thu, 1 May 2003 17:05:02 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Thu, 1 May 2003 17:04:58 -0700 From: "Blake Ramsdell" To: Subject: RE: Small comments on pss-01 Date: Thu, 1 May 2003 17:04:58 -0700 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 In-Reply-To: <003c01c31028$e936e110$1700a8c0@soaringhawk.net> 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: (List removed) > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Thursday, May 01, 2003 2:31 PM > To: 'Blake Ramsdell'; ietf-smime@imc.org > Subject: RE: Small comments on pss-01 > > We are still using the X.208/X.209 references for ASN.1/BER since we > have never gone beyond using 1988 syntax. (Note that the DER > reference > is either X509-88 or X.660.) Just so we're on the same page, the title of X.660 is "Procedures for the operation of OSI Registration Authorities: General procedures", and the title of X.690 is "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)". I've been using X.690 for all of my DER research, but I could be nutty. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41LUdi2080890 for ; Thu, 1 May 2003 14:30:39 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41LUd9W080889 for ietf-smime-bks; Thu, 1 May 2003 14:30:39 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41LUci2080883 for ; Thu, 1 May 2003 14:30:38 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 843AB6A505; Thu, 1 May 2003 14:11:12 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , Subject: RE: Small comments on pss-01 Date: Thu, 1 May 2003 14:30:38 -0700 Message-ID: <003c01c31028$e936e110$1700a8c0@soaringhawk.net> 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: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake, We are still using the X.208/X.209 references for ASN.1/BER since we have never gone beyond using 1988 syntax. (Note that the DER reference is either X509-88 or X.660.) jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Blake Ramsdell > Sent: Thursday, May 01, 2003 12:57 PM > To: 'Jim Schaad'; ietf-smime@imc.org > Subject: Small comments on pss-01 > > > > In pss-01, I believe that draft-jonsson-pkcs1-v2dot1-00.txt > has been released as RFC3447, so the reference "P1v2.1" > probably needs updating. > > Also, the SHA2 normative reference is not used -- it may need > to be moved to Informational References or removed completely. > > I remember some discussion about this at one point, but are > we using X.208 and X.209 for references to ASN.1 / BER / DER > instead of X.680 and X.690? If not, then these may need updating. > > Blake > -- > Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Ktbi2079869 for ; Thu, 1 May 2003 13:55:37 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41KtbDv079868 for ietf-smime-bks; Thu, 1 May 2003 13:55:37 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41Ktai2079863 for ; Thu, 1 May 2003 13:55:36 -0700 (PDT) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id AE2796A4DA for ; Thu, 1 May 2003 13:55:37 -0700 (PDT) Reply-To: From: "Jim Schaad" To: "Ietf-Smime" Subject: PSS Document Question Date: Thu, 1 May 2003 13:55:36 -0700 Message-ID: <003b01c31024$04d83090$1700a8c0@soaringhawk.net> 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 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have had a private mail that requested the following: > In section 3, you say: > > digestAlgorithms SHOULD contain the one-way hash function used to > compute the message digest on the eContent value. > > I would rather this be a MUST! My reply was that this would impose a new behavior on the CMS document where this behavior is a SHOULD not a MUST. The reply to this was to ask me to take it to the list as a question of wheither the CMS document is too lienant on this issue. HERE IS MY TAKE! 1. Presence of a digest algorithm is not techincally needed to successfully validate a signature. The one that is needed is in the SignerInfo structure. 2. My implementations of CMS WILL FAIL if the digest algorithm is not present in this field. I have a stream based implementation of signature processing that requires the digest algorithm to be known prior to starting to process the content. (I have a fall back of adding SHA-1 if the field is empty.) This is permitted behavior under CMS. 3. I do not know of anybody who delibrately omits putting this into the message. I would be happy with changing this from a SHOULD to a MUST, but if this is done it needs to propigate all of the way back to CMS. Jim Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JvJi2077755 for ; Thu, 1 May 2003 12:57:19 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41JvJpi077754 for ietf-smime-bks; Thu, 1 May 2003 12:57:19 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41JvIi2077747 for ; Thu, 1 May 2003 12:57:18 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Thu, 1 May 2003 12:57:15 -0700 From: "Blake Ramsdell" To: "'Jim Schaad'" , Subject: Small comments on pss-01 Date: Thu, 1 May 2003 12:57:15 -0700 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.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In pss-01, I believe that draft-jonsson-pkcs1-v2dot1-00.txt has been released as RFC3447, so the reference "P1v2.1" probably needs updating. Also, the SHA2 normative reference is not used -- it may need to be moved to Informational References or removed completely. I remember some discussion about this at one point, but are we using X.208 and X.209 for references to ASN.1 / BER / DER instead of X.680 and X.690? If not, then these may need updating. Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JShi2076987 for ; Thu, 1 May 2003 12:28:43 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41JShvb076986 for ietf-smime-bks; Thu, 1 May 2003 12:28:43 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41JSfi2076981 for ; Thu, 1 May 2003 12:28:41 -0700 (PDT) (envelope-from nsyracus@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 PAA02680; Thu, 1 May 2003 15:25:33 -0400 (EDT) Message-Id: <200305011925.PAA02680@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-x400transport-06.txt Date: Thu, 01 May 2003 15:25:32 -0400 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 : Transporting S/MIME Objects in X.400 Author(s) : P. Hoffman, C. Bonatti Filename : draft-ietf-smime-x400transport-06.txt Pages : 0 Date : 2003-5-1 This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-06.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-x400transport-06.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-x400transport-06.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: <2003-5-1153646.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400transport-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400transport-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153646.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41JSZi2076978 for ; Thu, 1 May 2003 12:28:35 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41JSZe9076977 for ietf-smime-bks; Thu, 1 May 2003 12:28:35 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41JSYi2076971 for ; Thu, 1 May 2003 12:28:34 -0700 (PDT) (envelope-from nsyracus@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 PAA02662; Thu, 1 May 2003 15:25:26 -0400 (EDT) Message-Id: <200305011925.PAA02662@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-x400wrap-06.txt Date: Thu, 01 May 2003 15:25:26 -0400 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 : Securing X.400 Content with S/MIME Author(s) : P. Hoffman, C. Bonatti, A. Eggen Filename : draft-ietf-smime-x400wrap-06.txt Pages : 11 Date : 2003-5-1 This document describes a protocol for adding cryptographic signature and encryption services to X.400 content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-06.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-x400wrap-06.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-x400wrap-06.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: <2003-5-1153636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-x400wrap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-x400wrap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153636.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.8p1/8.12.8) with ESMTP id h41Bpli2054877 for ; Thu, 1 May 2003 04:51:47 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.8p1/8.12.9/Submit) id h41BpjaP054876 for ietf-smime-bks; Thu, 1 May 2003 04:51:45 -0700 (PDT) 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.8p1/8.12.8) with ESMTP id h41Bpii2054871 for ; Thu, 1 May 2003 04:51:45 -0700 (PDT) (envelope-from nsyracus@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 HAA05751; Thu, 1 May 2003 07:48:51 -0400 (EDT) Message-Id: <200305011148.HAA05751@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-pss-01.txt Date: Thu, 01 May 2003 07:48:51 -0400 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 : Use of the PSS Signature Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-pss-01.txt Pages : 5 Date : 2003-4-30 This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signature algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-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-pss-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-pss-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: <2003-4-30150852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-pss-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-pss-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-30150852.I-D@ietf.org> --OtherAccess-- --NextPart--