From paymentoffice65@gmail.com Sun Aug 3 11:54:55 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4713A3A691C for ; Sun, 3 Aug 2008 11:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.977 X-Spam-Level: **** X-Spam-Status: No, score=4.977 tagged_above=-999 required=5 tests=[BAYES_50=0.001, KAM_LOTTO1=2.899, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1HiILQjnGsN for ; Sun, 3 Aug 2008 11:54:55 -0700 (PDT) Received: from cumdfirewall.uniminuto.edu (mail.uniminuto.edu.co [190.24.131.35]) by core3.amsl.com (Postfix) with ESMTP id 6A43E3A6ADE for ; Sun, 3 Aug 2008 11:54:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cumdfirewall.uniminuto.edu (Postfix) with ESMTP id 471592B530; Sun, 3 Aug 2008 13:38:14 -0500 (COT) X-Virus-Scanned: amavisd-new at uniminuto.edu Received: from cumdfirewall.uniminuto.edu ([127.0.0.1]) by localhost (cumdfirewall.uniminuto.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQkpMxLgel5b; Sun, 3 Aug 2008 13:38:08 -0500 (COT) Received: from correo.uniminuto.edu (localhost [127.0.0.1]) by cumdfirewall.uniminuto.edu (Postfix) with ESMTP id 3C5A42F1AD; Sun, 3 Aug 2008 13:31:11 -0500 (COT) Received: from 75-2.vgccl.net ([41.220.75.2]) (SquirrelMail authenticated user fmuriel) by correo.uniminuto.edu with HTTP; Sun, 3 Aug 2008 13:31:12 -0500 (COT) Message-ID: <4819beac5ba47eb78761dfe3fe9106bc.squirrel@correo.uniminuto.edu> Date: Sun, 3 Aug 2008 13:31:12 -0500 (COT) Subject: YOU ARE A WINNER!!! From: "COCA COLA LOTTERY BOARD" Reply-To: paymentoffice64@gmail.com User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; ----- REG ORDER NO:ECL/68276/08 22 Garden Close, SE9 2YP,London United Kingdom THE COCACOLA COMPANY OFFICIAL PRIZE NOTIFICATION ATTENTION WINNER: We are pleased to inform you of the result of the just concluded draws held today by Coca-Cola .Your E-mail was among the 20 Lucky winners who won £500,000.00{Five Hundred Thousand Great Britain Pounds} each in the Coca-Cola Company 2008 online Promo. This draw is being organized to enhance awareness and publicity of the Coca-Cola Zero product. Your E-mail was attached to Ticket number (8VKVIZ2008) and Ballot number (BT:31282008/20) The online draws was conducted by a random selection of E-mail addresses from an exclusive list of 29,031,643 E-mail addresses of individuals and corporate bodies picked by an advanced automated random computer search from the internet. No Tickets were sold but all e-mail addresses were assigned to different Ticket numbers for representation and privacy. To begin the claim processing of your prize you are to contact your claims Agent and provide him with the following informations as stated below, so we can proceed with the verification and clearance process of your file: 1. Full Names : ......................................................... 2. Residential Address : ....................................................... 3. Phone Number(Mobile&Home): ...................................................... 4. Fax Number : ......................................................... 5. Occupation : ......................................................... 6. Sex : ......................................................... 7. Age : ......................................................... 8. Nationality : .......................................................... 9.Ballot No. : .......................................................... 10.Ticket No: ........................................................... 11.Preferred Choice of receiving Winnings: (A):Via Courier Delivery Of Certified Cheque. (B):Bank wire Transfer. Mr Allan Edwards. claims Agent, Email: paymentoffice64@googlemail.com Tel:+447 045 798 693 FAX:+447 005 938 689 Yours Faithfully, Cruze Benze(Esq). Management From paymentoffice65@gmail.com Sun Aug 3 12:32:21 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBC73A6C32; Sun, 3 Aug 2008 12:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.977 X-Spam-Level: **** X-Spam-Status: No, score=4.977 tagged_above=-999 required=5 tests=[BAYES_50=0.001, KAM_LOTTO1=2.899, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o36e7WD2bqc8; Sun, 3 Aug 2008 12:32:20 -0700 (PDT) Received: from cumdfirewall.uniminuto.edu (mail.uniminuto.edu.co [190.24.131.35]) by core3.amsl.com (Postfix) with ESMTP id 5A01D3A684D; Sun, 3 Aug 2008 12:32:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cumdfirewall.uniminuto.edu (Postfix) with ESMTP id 5CF6F2B531; Sun, 3 Aug 2008 13:38:14 -0500 (COT) X-Virus-Scanned: amavisd-new at uniminuto.edu Received: from cumdfirewall.uniminuto.edu ([127.0.0.1]) by localhost (cumdfirewall.uniminuto.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+hVguaIsO3z; Sun, 3 Aug 2008 13:38:08 -0500 (COT) Received: from correo.uniminuto.edu (localhost [127.0.0.1]) by cumdfirewall.uniminuto.edu (Postfix) with ESMTP id 3C5A42F1AD; Sun, 3 Aug 2008 13:31:11 -0500 (COT) Received: from 75-2.vgccl.net ([41.220.75.2]) (SquirrelMail authenticated user fmuriel) by correo.uniminuto.edu with HTTP; Sun, 3 Aug 2008 13:31:12 -0500 (COT) Message-ID: <4819beac5ba47eb78761dfe3fe9106bc.squirrel@correo.uniminuto.edu> Date: Sun, 3 Aug 2008 13:31:12 -0500 (COT) Subject: YOU ARE A WINNER!!! From: "COCA COLA LOTTERY BOARD" Reply-To: paymentoffice64@gmail.com User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal To: undisclosed-recipients:; ----- REG ORDER NO:ECL/68276/08 22 Garden Close, SE9 2YP,London United Kingdom THE COCACOLA COMPANY OFFICIAL PRIZE NOTIFICATION ATTENTION WINNER: We are pleased to inform you of the result of the just concluded draws held today by Coca-Cola .Your E-mail was among the 20 Lucky winners who won £500,000.00{Five Hundred Thousand Great Britain Pounds} each in the Coca-Cola Company 2008 online Promo. This draw is being organized to enhance awareness and publicity of the Coca-Cola Zero product. Your E-mail was attached to Ticket number (8VKVIZ2008) and Ballot number (BT:31282008/20) The online draws was conducted by a random selection of E-mail addresses from an exclusive list of 29,031,643 E-mail addresses of individuals and corporate bodies picked by an advanced automated random computer search from the internet. No Tickets were sold but all e-mail addresses were assigned to different Ticket numbers for representation and privacy. To begin the claim processing of your prize you are to contact your claims Agent and provide him with the following informations as stated below, so we can proceed with the verification and clearance process of your file: 1. Full Names : ......................................................... 2. Residential Address : ....................................................... 3. Phone Number(Mobile&Home): ...................................................... 4. Fax Number : ......................................................... 5. Occupation : ......................................................... 6. Sex : ......................................................... 7. Age : ......................................................... 8. Nationality : .......................................................... 9.Ballot No. : .......................................................... 10.Ticket No: ........................................................... 11.Preferred Choice of receiving Winnings: (A):Via Courier Delivery Of Certified Cheque. (B):Bank wire Transfer. Mr Allan Edwards. claims Agent, Email: paymentoffice64@googlemail.com Tel:+447 045 798 693 FAX:+447 005 938 689 Yours Faithfully, Cruze Benze(Esq). Management From owner-ietf-smime@mail.imc.org Sun Aug 3 15:47:13 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6153A6C5E for ; Sun, 3 Aug 2008 15:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C+Ba+Tyju2E for ; Sun, 3 Aug 2008 15:47:12 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5FFD03A6C41 for ; Sun, 3 Aug 2008 15:47:12 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m73MRpw5090748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2008 15:27:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m73MRpNu090747; Sun, 3 Aug 2008 15:27:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m73MRjBe090732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2008 15:27:47 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <01e701c8f0b7$db2d7550$91885ff0$@com> References: <20080701003001.D4EE13A6B29@core3.amsl.com> <01e701c8f0b7$db2d7550$91885ff0$@com> Date: Sun, 3 Aug 2008 16:20:10 +0100 To: "Jim Schaad" , "Sean P. Turner" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:43 PM +0100 7/28/08, Jim Schaad wrote: >Comments on the draft. > >In section 4.4.3, I find the following text confusing: > >End-entity certificates contain an extension that > constrains the certificate from being an issuing authority > certificate (see Section 4.4.2). > > >I believe that this text might be better as it clarifies what is being >stated. I.e. it is not the fact that basic constraints is being used which >actually does the mentioned constraint. > > >End-entity certificates contain the Key Usage extension which restraints the >end-entity from using the key to perform issuing authority operations (see >4.4.4) s/restraints/restrains/ >Also the previous comment (on 3851bis) on key sizes > 4096 should be applied >to this document My same reply applies. From owner-ietf-smime@mail.imc.org Sun Aug 3 17:13:51 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030C43A6876 for ; Sun, 3 Aug 2008 17:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfR+zrPPCxeu for ; Sun, 3 Aug 2008 17:13:50 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 22FAC3A6872 for ; Sun, 3 Aug 2008 17:13:50 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m73NRov0093307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2008 16:27:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m73NRoMd093306; Sun, 3 Aug 2008 16:27:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m73MRjBc090732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2008 15:27:46 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <01e001c8f0b4$4182f4a0$c488dde0$@com> References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> Date: Sun, 3 Aug 2008 16:27:36 +0100 To: "Jim Schaad" , "Sean P. Turner" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:17 PM +0100 7/28/08, Jim Schaad wrote: >Comments on the draft: > >1. We are not currently making any support statements for DSA w/ the >SHA-256 hash algorithms. Should we be doing so? Yes and no. Yes in the sense that US government users who use DSA will want DSA-with-SHA-256. No in the sense that there is no appropriate level of standards support that makes sense: SHOULD is too strong, given current deployments. >2. For key size support, key of L>1024 are not supported for DSA-SHA-1. Arrgh. Quite right. Sections 4.2 and 4.3 need to be rewritten to indicate that anything greater than 1024 is about RSA *only*. >3. I would like to add the following text to the table. > >Key size > 4096 MAY NOT (See security considerations on large keys) > >This would finish the table entry out and also reference the discussion on >why very large keys are not recommended. It is possible that MAY NOT is not >currently valid 2119 language. In this case I would be happy with ether MAY >or SHOULD NOT. I would not be happy with MUST NOT. "MAY NOT" is not part of 2119. Further, we do not have enough evidence to know size key is "too large". Further still, the number will be different for receivers of RSA and DSA keys, I believe. "MAY" makes no sense. "SHOULD NOT" is too strong, I believe, without more than just data-less guessing on our part. At 4:43 PM +0100 7/31/08, Jim Schaad wrote: >I really feel that we need to have two MUST signature algorithms for safety. >When ECC signatures where present that was fine. Without having the ECC >signature algorithms we really must have one of the DSA algorithms as a must I disagree. If RSA falls for some reason that cannot be fixed with longer key sizes, a "SHOULD" on DSA-SHA256 for fallback reasons assumes that the attack on RSA will not apply to DSA, which seems like a stretch. Having a "SHOULD" for a fallback seems reasonable. From owner-ietf-smime@mail.imc.org Mon Aug 4 14:52:15 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60BA53A67FA for ; Mon, 4 Aug 2008 14:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.947 X-Spam-Level: X-Spam-Status: No, score=-101.947 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kk2-H67Jxb9Y for ; Mon, 4 Aug 2008 14:52:14 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 20E543A6A48 for ; Mon, 4 Aug 2008 14:52:14 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74LUVDw093189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 14:30:31 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m74LUVn1093188; Mon, 4 Aug 2008 14:30:31 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74LUUGV093182 for ; Mon, 4 Aug 2008 14:30:31 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 47F653A6A5A; Mon, 4 Aug 2008 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-bfibecms-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080804213001.47F653A6A5A@core3.amsl.com> Date: Mon, 4 Aug 2008 14:30:01 -0700 (PDT) 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 : Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) Author(s) : L. Martin, M. Schertler Filename : draft-ietf-smime-bfibecms-10.txt Pages : 16 Date : 2008-8-4 This document describes the conventions for using the Boneh- Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-bfibecms-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-4142145.I-D@ietf.org> --NextPart-- From MAILER-DAEMON Tue Aug 5 10:56:19 2008 Return-Path: <> X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F753A6D02 for ; Tue, 5 Aug 2008 10:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.004 X-Spam-Level: *** X-Spam-Status: No, score=3.004 tagged_above=-999 required=5 tests=[BAYES_50=0.001, INVALID_MSGID=1.9, MIME_8BIT_HEADER=0.3, MIME_BOUND_MANY_HEX=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K7EAkfTvvdi for ; Tue, 5 Aug 2008 10:56:18 -0700 (PDT) Received: from kane.otenet.gr (kane.otenet.gr [83.235.67.31]) by core3.amsl.com (Postfix) with ESMTP id 3076A28C0F2 for ; Tue, 5 Aug 2008 10:56:17 -0700 (PDT) Received: from exchange.ace-hellas.gr ([83.235.250.210]) by kane.otenet.gr (8.13.8/8.13.8/Debian-3) with ESMTP id m75HukxN006457 for ; Tue, 5 Aug 2008 20:56:48 +0300 MIME-Version: 1.0 From: To: Date: Tue, 5 Aug 2008 20:56:46 +0300 Content-Type: multipart/report; report-type=delivery-status; boundary="aa259559-4caf-496a-bffd-cf4fa8077056" Content-Language: el-GR Message-ID: In-Reply-To: <20080805125735.7968.qmail@user-6f9ee9b8ef> References: <20080805125735.7968.qmail@user-6f9ee9b8ef> Subject: =?iso-8859-7?Q?=C4=E5=ED_=F0=E1=F1=E1=E4=FC=E8=E7=EA=E5:_Angelina_Jolie_F?= =?iso-8859-7?Q?ree_Video.?= --aa259559-4caf-496a-bffd-cf4fa8077056 Content-Type: multipart/alternative; differences=Content-Type; boundary="ef8babf4-3cf1-4194-8ca1-f716cb08d66e" --ef8babf4-3cf1-4194-8ca1-f716cb08d66e Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable =C7 =F0=E1=F1=DC=E4=EF=F3=E7 =F3=F4=EF=F5=F2 =E1=EA=FC=EB=EF=F5=E8=EF=F5=F2= =F0=E1=F1=E1=EB=DE=F0=F4=E5=F2 =DE =EB=DF=F3=F4=E5=F2 =E4=E9=E1=ED=EF=EC= =DE=F2 =E1=F0=DD=F4=F5=F7=E5: smime@ace-hellas.gr =C7 =E4=E9=E5=FD=E8=F5=ED=F3=E7 =E7=EB=E5=EA=F4=F1=EF=ED=E9=EA=EF=FD =F4=E1= =F7=F5=E4=F1=EF=EC=E5=DF=EF=F5 =F4=EF=F5 =F0=E1=F1=E1=EB=DE=F0=F4=E7 =E4=E5= =ED =E2=F1=DD=E8=E7=EA=E5 =F3=F4=EF =F3=FD=F3=F4=E7=EC=E1 =E7=EB=E5=EA=F4= =F1=EF=ED=E9=EA=EF=FD =F4=E1=F7=F5=E4=F1=EF=EC=E5=DF=EF=F5 =F4=EF=F5 =F0=E1= =F1=E1=EB=DE=F0=F4=E7. =D4=EF Microsoft Exchange =E4=E5=ED =E8=E1 =E5=F0=E9= =F7=E5=E9=F1=DE=F3=E5=E9 =ED=E1 =F0=E1=F1=E1=E4=FE=F3=E5=E9 =EE=E1=ED=DC = =E1=F5=F4=FC =F4=EF =EC=DE=ED=F5=EC=E1 =E5=EA =EC=DD=F1=EF=F5=F2 =F3=E1=F2.= =C5=EB=DD=E3=EE=F4=E5 =F4=E7 =E4=E9=E5=FD=E8=F5=ED=F3=E7 =E7=EB=E5=EA=F4= =F1=EF=ED=E9=EA=EF=FD =F4=E1=F7=F5=E4=F1=EF=EC=E5=DF=EF=F5 =EA=E1=E9 =F0=F1= =EF=F3=F0=E1=E8=DE=F3=F4=E5 =ED=E1 =F3=F4=E5=DF=EB=E5=F4=E5 =E1=F5=F4=FC = =F4=EF =EC=DE=ED=F5=EC=E1 =EE=E1=ED=DC =DE =E4=FE=F3=F4=E5 =F4=EF =E1=EA=FC= =EB=EF=F5=E8=EF =E4=E9=E1=E3=ED=F9=F3=F4=E9=EA=FC =EA=E5=DF=EC=E5=ED=EF =F3= =F4=EF =E4=E9=E1=F7=E5=E9=F1=E9=F3=F4=DE =F4=EF=F5 =F3=F5=F3=F4=DE=EC=E1=F4= =EF=F2. ________________________________ =C5=F3=F4=DC=EB=E7 =E1=F0=FC =F4=EF=ED Microsoft Exchange Server 2007 =D0=EB=E7=F1=EF=F6=EF=F1=DF=E5=F2 =E4=E9=DC=E3=ED=F9=F3=E7=F2 =E3=E9=E1 =E4= =E9=E1=F7=E5=E9=F1=E9=F3=F4=DD=F2: =C4=E9=E1=EA=EF=EC=E9=F3=F4=DE=F2 =E4=E7=EC=E9=EF=F5=F1=E3=DF=E1=F2: ace-in= ternal.gr smime@ace-hellas.gr #550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ## =C1=F1=F7=E9=EA=DD=F2 =EA=E5=F6=E1=EB=DF=E4=E5=F2 =EC=E7=ED=FD=EC=E1=F4=EF= =F2: Received: from user-6f9ee9b8ef (79.139.179.172) by exchange.ace-hellas.gr (192.168.2.217) with Microsoft SMTP Server id 8.1.291.1; Tue, 5 Aug 2008 20:56:45 +0300 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Return-Path: communications_msn_cs_enus@cimail15.msn.com Message-ID: <20080805125735.7968.qmail@user-6f9ee9b8ef> To: Subject: *** SPAM ***Angelina Jolie Free Video. From: MIME-Version: 1.0 Content-Type: text/html; charset=3D"UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 5 Aug 2008 20:56:45 +0300 Received-SPF: TempError (cluster.domain.com: error in processing during lookup of smime@ace-hellas.gr: DNS timeout) X-Spam-Flag: YES X-Spam-Status: YES, hits=3D8 required=3D7, ct-refid=3D[str=3D0001.0A0B0204.489880B1.0159,ss=3D3,sh,fgs=3D0], database-version=3D[2008-07-28_01], tests=3DCTENGINE_BULK,DNS_AVAILABLE,FS_RATWARE_INV_CTE,FS_UNTRUSTED_1,HTML= _MIME_NO_HTML_TAG,MIME_HTML_ONLY,MSGSTRUCT_EMPTY_JUNK,RCVD_IN_PBL,RCVD_IN_X= BL,SUBJECT_FULL_STOP,FS_CLA --ef8babf4-3cf1-4194-8ca1-f716cb08d66e Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

=C7 =F0=E1=F1=DC=E4= =EF=F3=E7 =F3=F4=EF=F5=F2 =E1=EA=FC=EB=EF=F5=E8=EF=F5=F2 =F0=E1=F1=E1=EB=DE= =F0=F4=E5=F2 =DE =EB=DF=F3=F4=E5=F2 =E4=E9=E1=ED=EF=EC=DE=F2 =E1=F0=DD=F4= =F5=F7=E5:

smime@ace-hellas.gr
=C7 =E4=E9=E5=FD=E8=F5=ED=F3=E7 =E7=EB=E5=EA=F4=F1=EF=ED=E9=EA=EF=FD =F4=E1= =F7=F5=E4=F1=EF=EC=E5=DF=EF=F5 =F4=EF=F5 =F0=E1=F1=E1=EB=DE=F0=F4=E7 =E4=E5= =ED =E2=F1=DD=E8=E7=EA=E5 =F3=F4=EF =F3=FD=F3=F4=E7=EC=E1 =E7=EB=E5=EA=F4= =F1=EF=ED=E9=EA=EF=FD =F4=E1=F7=F5=E4=F1=EF=EC=E5=DF=EF=F5 =F4=EF=F5 =F0=E1= =F1=E1=EB=DE=F0=F4=E7. =D4=EF Microsoft Exchange =E4=E5=ED =E8=E1 =E5=F0=E9= =F7=E5=E9=F1=DE=F3=E5=E9 =ED=E1 =F0=E1=F1=E1=E4=FE=F3=E5=E9 =EE=E1=ED=DC = =E1=F5=F4=FC =F4=EF =EC=DE=ED=F5=EC=E1 =E5=EA =EC=DD=F1=EF=F5=F2 =F3=E1=F2.= =C5=EB=DD=E3=EE=F4=E5 =F4=E7 =E4=E9=E5=FD=E8=F5=ED=F3=E7 =E7=EB=E5=EA=F4= =F1=EF=ED=E9=EA=EF=FD =F4=E1=F7=F5=E4=F1=EF=EC=E5=DF=EF=F5 =EA=E1=E9 =F0=F1= =EF=F3=F0=E1=E8=DE=F3=F4=E5 =ED=E1 =F3=F4=E5=DF=EB=E5=F4=E5 =E1=F5=F4=FC = =F4=EF =EC=DE=ED=F5=EC=E1 =EE=E1=ED=DC =DE =E4=FE=F3=F4=E5 =F4=EF =E1=EA=FC= =EB=EF=F5=E8=EF =E4=E9=E1=E3=ED=F9=F3=F4=E9=EA=FC =EA=E5=DF=EC=E5=ED=EF =F3= =F4=EF =E4=E9=E1=F7=E5=E9=F1=E9=F3=F4=DE =F4=EF=F5 =F3=F5=F3=F4=DE=EC=E1=F4= =EF=F2.
=C5=F3=F4=DC=EB=E7 = =E1=F0=FC =F4=EF=ED Microsoft Exchange Server 2007





=D0=EB=E7=F1=EF=F6= =EF=F1=DF=E5=F2 =E4=E9=DC=E3=ED=F9=F3=E7=F2 =E3=E9=E1 =E4=E9=E1=F7=E5=E9=F1= =E9=F3=F4=DD=F2:

=C4=E9=E1=EA=EF=EC=E9=F3=F4=DE=F2 =E4=E7=EC=E9=EF=F5=F1=E3=DF=E1=F2: ace= -internal.gr

smime@ace-hellas.gr
#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##

=C1=F1=F7=E9=EA=DD=F2 =EA=E5=F6=E1=EB=DF=E4=E5=F2 =EC=E7=ED=FD=EC=E1=F4= =EF=F2:

Received: from user-6f9ee9b8ef (79.139.179.172) by exchange.ace-hellas=
.gr
 (192.168.2.217) with Microsoft SMTP Server id 8.1.291.1; Tue, 5 Aug 2008
 20:56:45 +0300
Content-Return: allowed
X-Mailer: CME-V6.5.4.3; MSN
Return-Path: communications_msn_cs_enus@cimail15.msn.com
Message-ID: <20080805125735.7968.qmail@user-6f9ee9b8ef>
To: <smime@ace-hellas.gr>
Subject: *** SPAM ***Angelina Jolie Free Video.
From: <smime@ace-hellas.gr>
MIME-Version: 1.0
Content-Type: text/html; charset=3D"UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 5 Aug 2008 20:56:45 +0300
Received-SPF: TempError (cluster.domain.com: error in processing during
 lookup of smime@ace-hellas.gr: DNS timeout)
X-Spam-Flag: YES
X-Spam-Status: YES, hits=3D8 required=3D7,
 ct-refid=3D[str=3D0001.0A0B0204.489880B1.0159,ss=3D3,sh,fgs=3D0],
 database-version=3D[2008-07-28_01],
 tests=3DCTENGINE_BULK,DNS_AVAILABLE,FS_RATWARE_INV_CTE,FS_UNTRUSTED_1,HTML=
_MIME_NO_HTML_TAG,MIME_HTML_ONLY,MSGSTRUCT_EMPTY_JUNK,RCVD_IN_PBL,RCVD_IN_X=
BL,SUBJECT_FULL_STOP,FS_CLA
= --ef8babf4-3cf1-4194-8ca1-f716cb08d66e-- --aa259559-4caf-496a-bffd-cf4fa8077056 Content-Type: message/delivery-status Reporting-MTA: dns;ace-internal.gr Received-From-MTA: dns;user-6f9ee9b8ef Arrival-Date: Tue, 5 Aug 2008 17:56:45 +0000 Final-Recipient: rfc822;smime@ace-hellas.gr Action: failed Status: 5.1.1 Diagnostic-Code: smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found --aa259559-4caf-496a-bffd-cf4fa8077056 Content-Type: message/rfc822 Received: from user-6f9ee9b8ef (79.139.179.172) by exchange.ace-hellas.gr (192.168.2.217) with Microsoft SMTP Server id 8.1.291.1; Tue, 5 Aug 2008 20:56:45 +0300 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Return-Path: communications_msn_cs_enus@cimail15.msn.com Message-ID: <20080805125735.7968.qmail@user-6f9ee9b8ef> To: Subject: *** SPAM ***Angelina Jolie Free Video. From: MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 5 Aug 2008 20:56:45 +0300 Received-SPF: TempError (cluster.domain.com: error in processing during lookup of smime@ace-hellas.gr: DNS timeout) X-Spam-Flag: YES X-Spam-Status: YES, hits=8 required=7, ct-refid=[str=0001.0A0B0204.489880B1.0159,ss=3,sh,fgs=0], database-version=[2008-07-28_01], tests=CTENGINE_BULK,DNS_AVAILABLE,FS_RATWARE_INV_CTE,FS_UNTRUSTED_1,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,MSGSTRUCT_EMPTY_JUNK,RCVD_IN_PBL,RCVD_IN_XBL,SUBJECT_FULL_STOP,FS_CLA --aa259559-4caf-496a-bffd-cf4fa8077056-- From owner-ietf-smime@mail.imc.org Wed Aug 6 03:04:54 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255313A6B74 for ; Wed, 6 Aug 2008 03:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HGEF510y7fq for ; Wed, 6 Aug 2008 03:04:53 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 311893A6B6E for ; Wed, 6 Aug 2008 03:04:52 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m769iqNO048825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 02:44:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m769iq73048824; Wed, 6 Aug 2008 02:44:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.movielink.net.au (mail.movielink.net.au [202.168.29.253]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m769im24048807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Aug 2008 02:44:50 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: (qmail 12630 invoked by uid 509); 6 Aug 2008 19:43:57 +1000 Received: from 203.36.227.132 by mail.movielink.net.au (envelope-from , uid 508) with qmail-scanner-1.25-st-qms (clamdscan: 0.87/5056. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:1(203.36.227.132):. Processed in 0.650914 secs); 06 Aug 2008 09:43:57 -0000 X-Antivirus-MOVIELINK.NET.AU-Mail-From: ietf@augustcellars.com via mail.movielink.net.au X-Antivirus-MOVIELINK.NET.AU: 1.25-st-qms (Clear:RC:1(203.36.227.132):. Processed in 0.650914 secs Process 12615) Received: from unknown (HELO GALATIONS) (203.36.227.132) by mail.movielink.net.au with SMTP; 6 Aug 2008 19:43:56 +1000 From: "Jim Schaad" To: "'Paul Hoffman'" , "'Sean P. Turner'" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> In-Reply-To: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Wed, 6 Aug 2008 19:44:42 +1000 Message-ID: <000701c8f7a9$10d35c40$327a14c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj1uCfDU9wbaySQTmG3BvR56qJnBwA5mubQ Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Paul Hoffman [mailto:phoffman@imc.org] > Sent: Sunday, August 03, 2008 8:28 AM > To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell' > Cc: ietf-smime@imc.org > Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > > At 2:17 PM +0100 7/28/08, Jim Schaad wrote: > >Comments on the draft: > > > >1. We are not currently making any support statements for DSA w/ the > >SHA-256 hash algorithms. Should we be doing so? > > Yes and no. Yes in the sense that US government users who use DSA > will want DSA-with-SHA-256. No in the sense that there is no > appropriate level of standards support that makes sense: SHOULD is > too strong, given current deployments. I can deal with a SHOULD+ for this > > >2. For key size support, key of L>1024 are not supported for DSA-SHA- > 1. > > Arrgh. Quite right. Sections 4.2 and 4.3 need to be rewritten to > indicate that anything greater than 1024 is about RSA *only*. > > >3. I would like to add the following text to the table. > > > >Key size > 4096 MAY NOT (See security considerations on large keys) > > > >This would finish the table entry out and also reference the > discussion on > >why very large keys are not recommended. It is possible that MAY NOT > is not > >currently valid 2119 language. In this case I would be happy with > ether MAY > >or SHOULD NOT. I would not be happy with MUST NOT. > > "MAY NOT" is not part of 2119. Further, we do not have enough > evidence to know size key is "too large". Further still, the number > will be different for receivers of RSA and DSA keys, I believe. > > "MAY" makes no sense. "SHOULD NOT" is too strong, I believe, without > more than just data-less guessing on our part. I am perfectly willing to use a non standards word here. For example, permitted. I thought I saw enough consensus from the list that keys over this size will have either real-estate constraints or performance constraints. Either would be covered by referring to a security considerations discussion to this effect. I don't want to say or imply that keys longer than 4096 are not to be handled. > > At 4:43 PM +0100 7/31/08, Jim Schaad wrote: > >I really feel that we need to have two MUST signature algorithms for > safety. > >When ECC signatures where present that was fine. Without having the > ECC > >signature algorithms we really must have one of the DSA algorithms as > a must > > I disagree. If RSA falls for some reason that cannot be fixed with > longer key sizes, a "SHOULD" on DSA-SHA256 for fallback reasons > assumes that the attack on RSA will not apply to DSA, which seems > like a stretch. Having a "SHOULD" for a fallback seems reasonable. From owner-ietf-smime@mail.imc.org Wed Aug 6 08:25:44 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2E23A68BF for ; Wed, 6 Aug 2008 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNiDS9Hh8yfW for ; Wed, 6 Aug 2008 08:25:43 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5D5493A67D0 for ; Wed, 6 Aug 2008 08:25:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76F6eCK079363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 08:06:40 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76F6erL079360; Wed, 6 Aug 2008 08:06:40 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76F6XrM079350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 08:06:34 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <000701c8f7a9$10d35c40$327a14c0$@com> References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> Date: Wed, 6 Aug 2008 08:06:31 -0700 To: "Jim Schaad" , "'Sean P. Turner'" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 7:44 PM +1000 8/6/08, Jim Schaad wrote: > > -----Original Message----- >> From: Paul Hoffman [mailto:phoffman@imc.org] >> Sent: Sunday, August 03, 2008 8:28 AM >> To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell' >> Cc: ietf-smime@imc.org >> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt >> >> At 2:17 PM +0100 7/28/08, Jim Schaad wrote: >> >Comments on the draft: >> > >> >1. We are not currently making any support statements for DSA w/ the >> >SHA-256 hash algorithms. Should we be doing so? >> >> Yes and no. Yes in the sense that US government users who use DSA > > will want DSA-with-SHA-256. No in the sense that there is no >> appropriate level of standards support that makes sense: SHOULD is >> too strong, given current deployments. > >I can deal with a SHOULD+ for this In retrospect, I agree with Jim and I'm happy with SHOULD+ for DSA-with-SHA-256 for both sending and receiving. It's not that big of a change from 3851. >I am perfectly willing to use a non standards word here. For example, >permitted. I thought I saw enough consensus from the list that keys over >this size will have either real-estate constraints or performance >constraints. Either would be covered by referring to a security >considerations discussion to this effect. I don't want to say or imply that >keys longer than 4096 are not to be handled. Proposed wording: Receiving agents that validate signatures need to be cautious of CPU usage when validating signatures larger than those mandated in this specification. An attacker can send very large, bogus signatures in order to swamp the CPU of the receiving party. Receiving parties that verify large signatures are advised to have some sort of resource management system to prevent such an attack. From owner-ietf-smime@mail.imc.org Wed Aug 6 12:20:58 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886F528C2F8 for ; Wed, 6 Aug 2008 12:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkPIFJU0kkia for ; Wed, 6 Aug 2008 12:20:57 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A231D28C39C for ; Wed, 6 Aug 2008 12:20:57 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76J27hu000269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 12:02:07 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76J27kL000265; Wed, 6 Aug 2008 12:02:07 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail-09.primus.ca (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76J1xXl000235; Wed, 6 Aug 2008 12:02:06 -0700 (MST) (envelope-from capel@comgate.com) Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-09.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1KQoGj-0001Ul-2X; Wed, 06 Aug 2008 15:01:58 -0400 From: "Tony Capel" To: "'Paul Hoffman'" , "'Jim Schaad'" , "'Sean P. Turner'" , "'Blake Ramsdell'" Cc: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Wed, 6 Aug 2008 15:01:56 -0400 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.6838 In-Reply-To: Thread-Index: Acj31vlw+074IWjkTcOww2DXyLocEgAA6/cg Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 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 Paul Hoffman | Sent: August 6, 2008 11:07 AM | To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell' | Cc: ietf-smime@imc.org | Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt | | >>cut | | Proposed wording: | | Receiving agents that validate signatures need to be cautious of CPU | usage when validating signatures larger than those mandated in this | specification. An attacker can send very large, bogus signatures in | order to swamp the CPU of the receiving party. Receiving parties that | verify large signatures are advised to have some sort of resource | management system to prevent such an attack. | I agree with the intent here, but this issue applies to both signature and encryption operations. So the text needs to address both sections /4.3 Signature Verification/ and /4.4 Encryption/ (/4.5 Decryption/ should be ok since I presume the agent is using a validated decryption key) So maybe the last line of both sections could change to: "2048 < key size : MAY (see Security Considerations, and especially discussion of denial of service vulnerability when implementing support for large keys, e.g. keys larger than 4096.)" Similarly maybe it is also appropriate* to add the same text to rfc3850bis-04 section /4.3 Certificate and CRL Signing Algorithms/ And the security considerations section of rfc3850bis updated similarly to 3851 with regard to cautions about large key sizes. Tony *Also a problem for cert validation if the provided intermediate cert has a large key (which would be used to check the end user certificate signature). Hopefully implementers will either a) identify the chain of certificates and begin validation at the trust anchor or b) limit crypto processing in some way. From owner-ietf-smime@mail.imc.org Thu Aug 7 09:47:10 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169693A6A36 for ; Thu, 7 Aug 2008 09:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4G+s6+VtjKV for ; Thu, 7 Aug 2008 09:47:09 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0C1E13A6BC9 for ; Thu, 7 Aug 2008 09:47:08 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77GTWf9092158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 09:29:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77GTW8e092157; Thu, 7 Aug 2008 09:29:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m77GTUpo092137 for ; Thu, 7 Aug 2008 09:29:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 42944 invoked from network); 7 Aug 2008 16:29:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.14.132 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 7 Aug 2008 16:29:29 -0000 X-YMail-OSG: v.ug34cVM1l953k9RjSR7tLnr6N7xyLdsP7Ho2PiJ3kXhRU_oVcJX8BrJFvY44ZUnC3_NIPOvWRKj0PAtLfOEPxje9RmxiJshL9CTjAbxA-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , "'Paul Hoffman'" , "'Jim Schaad'" , "'Blake Ramsdell'" Cc: References: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Thu, 7 Aug 2008 12:29:24 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: thread-index: Acj31vlw+074IWjkTcOww2DXyLocEgAA6/cgADPjLAA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, In 3850, I added the (see Security Considerations [SMIME-MSG]) from 4.3 of 3850 to pull in the security consdierations from 3851. We already point to it normatively so I think this might be better than copying the text in different places. spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Tony Capel >Sent: Wednesday, August 06, 2008 3:02 PM >To: 'Paul Hoffman'; 'Jim Schaad'; 'Sean P. Turner'; 'Blake Ramsdell' >Cc: ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > > > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >| Sent: August 6, 2008 11:07 AM >| To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell' >| Cc: ietf-smime@imc.org >| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt >| >| >>>cut >| >| Proposed wording: >| >| Receiving agents that validate signatures need to be cautious of CPU >| usage when validating signatures larger than those mandated in this >| specification. An attacker can send very large, bogus signatures in >| order to swamp the CPU of the receiving party. Receiving >parties that >| verify large signatures are advised to have some sort of resource >| management system to prevent such an attack. >| > >I agree with the intent here, but this issue applies to both >signature and encryption operations. >So the text needs to address both sections /4.3 Signature >Verification/ and >/4.4 Encryption/ >(/4.5 Decryption/ should be ok since I presume the agent is >using a validated decryption key) > >So maybe the last line of both sections could change to: > >"2048 < key size : MAY (see Security Considerations, and > especially discussion of denial > of service vulnerability when > implementing support for large keys, > e.g. keys larger than 4096.)" > > > >Similarly maybe it is also appropriate* to add the same text >to rfc3850bis-04 section /4.3 Certificate and CRL Signing Algorithms/ > >And the security considerations section of rfc3850bis updated >similarly to 3851 with regard to cautions about large key sizes. > > >Tony > >*Also a problem for cert validation if the provided >intermediate cert has a large key (which would be used to >check the end user certificate signature). >Hopefully implementers will either a) identify the chain of >certificates and begin validation at the trust anchor or b) >limit crypto processing in some way. > From owner-ietf-smime@mail.imc.org Thu Aug 7 10:59:10 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3312F3A6B16 for ; Thu, 7 Aug 2008 10:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmGCb8sopqZN for ; Thu, 7 Aug 2008 10:59:09 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 693BD3A6C3E for ; Thu, 7 Aug 2008 10:59:09 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77HgD2S097019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 10:42:13 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77HgDLj097018; Thu, 7 Aug 2008 10:42:13 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m77HgB7e097002 for ; Thu, 7 Aug 2008 10:42:12 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 17365 invoked from network); 7 Aug 2008 17:42:10 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.115.229 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 7 Aug 2008 17:42:10 -0000 X-YMail-OSG: FCL2yL0VM1mmj1Ma5vongQHuO4o_Ovzq2UKejyfGHWLtxpPyPRnsDLJgS_EI_M3KZhlg7Umz_W2vOw76ZBAyX2Z4bSaKrRaCBWgEC9IAIA-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Jim Schaad'" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Thu, 7 Aug 2008 13:42:05 -0400 Organization: IECA, Inc. Message-ID: <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: thread-index: Acj31gZA1BV5oRk4QBWJ+04JjAIBmwA3qptg Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Paul Hoffman [mailto:phoffman@imc.org] >Sent: Wednesday, August 06, 2008 11:07 AM >To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell' >Cc: ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > >At 7:44 PM +1000 8/6/08, Jim Schaad wrote: >> > -----Original Message----- >>> From: Paul Hoffman [mailto:phoffman@imc.org] >>> Sent: Sunday, August 03, 2008 8:28 AM >>> To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell' >>> Cc: ietf-smime@imc.org >>> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt >>> >>> At 2:17 PM +0100 7/28/08, Jim Schaad wrote: >>> >Comments on the draft: >>> > >>> >1. We are not currently making any support statements for DSA w/ >>> the >>> >SHA-256 hash algorithms. Should we be doing so? >>> >>> Yes and no. Yes in the sense that US government users who use DSA >> > will want DSA-with-SHA-256. No in the sense that there is no >>> appropriate level of standards support that makes sense: >SHOULD is >>> too strong, given current deployments. >> >>I can deal with a SHOULD+ for this > >In retrospect, I agree with Jim and I'm happy with SHOULD+ for >DSA-with-SHA-256 for both sending and receiving. It's not that >big of a change from 3851. > >>I am perfectly willing to use a non standards word here. For >example, >>permitted. I thought I saw enough consensus from the list that keys >>over this size will have either real-estate constraints or >performance >>constraints. Either would be covered by referring to a security >>considerations discussion to this effect. I don't want to >say or imply >>that keys longer than 4096 are not to be handled. > >Proposed wording: > >Receiving agents that validate signatures need to be cautious >of CPU usage when validating signatures larger than those >mandated in this specification. An attacker can send very >large, bogus signatures in order to swamp the CPU of the >receiving party. Receiving parties that verify large >signatures are advised to have some sort of resource >management system to prevent such an attack. Is this in addition to or to replace the para that starts "Larger keys are not" in 3851bis Sec 5? spt From smimetst@worcestericecats.com Thu Aug 7 13:58:19 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21A1C3A6993 for ; Thu, 7 Aug 2008 13:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.808 X-Spam-Level: X-Spam-Status: No, score=-71.808 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_EXTRA_CLOSE=2.809, HTML_FONT_SIZE_HUGE=0.057, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_PH_SURBL=1.787, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ+ucJjd-VZT for ; Thu, 7 Aug 2008 13:58:18 -0700 (PDT) Received: from adre31.neoplus.adsl.tpnet.pl (adre31.neoplus.adsl.tpnet.pl [79.185.164.31]) by core3.amsl.com (Postfix) with SMTP id 730F83A6943 for ; Thu, 7 Aug 2008 13:58:17 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080807115818.10986.qmail@adre31.neoplus.adsl.tpnet.pl> To: Subject: Internet Explorer 7 From: admin@microsoft.com MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Date: Thu, 7 Aug 2008 13:58:17 -0700 (PDT)
Free Video Nude Anjelina Jolie

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From owner-ietf-smime@mail.imc.org Thu Aug 7 16:11:07 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66783A681E for ; Thu, 7 Aug 2008 16:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHjn3ObH-Y6B for ; Thu, 7 Aug 2008 16:11:07 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C22AB3A680C for ; Thu, 7 Aug 2008 16:11:06 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77Mp8ML019324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 15:51:08 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77Mp8Gj019323; Thu, 7 Aug 2008 15:51:08 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77Mp3Kh019313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 15:51:04 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> Date: Thu, 7 Aug 2008 15:51:02 -0700 To: "Turner, Sean P." , "'Jim Schaad'" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote: > >Proposed wording: >> >>Receiving agents that validate signatures need to be cautious >>of CPU usage when validating signatures larger than those >>mandated in this specification. An attacker can send very >>large, bogus signatures in order to swamp the CPU of the >>receiving party. Receiving parties that verify large >>signatures are advised to have some sort of resource >>management system to prevent such an attack. > >Is this in addition to or to replace the para that starts "Larger keys are >not" in 3851bis Sec 5? Replace. From owner-ietf-smime@mail.imc.org Fri Aug 8 11:03:01 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48DB28C0FA for ; Fri, 8 Aug 2008 11:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.023 X-Spam-Level: X-Spam-Status: No, score=-102.023 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf39ZhsGqk+F for ; Fri, 8 Aug 2008 11:03:00 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8676D3A6D8B for ; Fri, 8 Aug 2008 11:03:00 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78Hj3SN001021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 10:45:03 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78Hj3Se001020; Fri, 8 Aug 2008 10:45:03 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78Hj3tM001014 for ; Fri, 8 Aug 2008 10:45:03 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 368EB3A6D72; Fri, 8 Aug 2008 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-ibearch-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808174502.368EB3A6D72@core3.amsl.com> Date: Fri, 8 Aug 2008 10:45:02 -0700 (PDT) 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 : Identity-based Encryption Architecture and Supporting Data Structures Author(s) : M. Schertler Filename : draft-ietf-smime-ibearch-07.txt Pages : 37 Date : 2008-8-8 This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-ibearch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-8103052.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Fri Aug 8 12:57:48 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79733A6CC9 for ; Fri, 8 Aug 2008 12:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1VSlUt8qd5D for ; Fri, 8 Aug 2008 12:57:47 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AC2BF3A6846 for ; Fri, 8 Aug 2008 12:57:47 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78Jejcp008641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 12:40:45 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78JejjM008640; Fri, 8 Aug 2008 12:40:45 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail-02.primus.ca (smtp-noauth4.primus.ca [216.254.180.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78JeiQ5008633 for ; Fri, 8 Aug 2008 12:40:44 -0700 (MST) (envelope-from capel@comgate.com) Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-02.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1KRXpK-0003ed-1x; Fri, 08 Aug 2008 15:40:43 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Fri, 8 Aug 2008 15:40:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 In-Reply-To: <31B9D22ECA884473981B83F00F05ECA5@Wylie> Importance: Normal Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean: I know you will be putting in some text to address Jim (and my) request = for text re key sizes > 4096 for CERT 3850bis. A directly related security concern, and one that has been around for = some time, is the potential for other inappropriate processing if an offered end = entity cert (or any offered cert in the chain) is processed prior to, or = irrespective of, being validated to a trusted root. In addition to the problem of a = large key, there is the potential of inappropriate CDP (and/or AIA) defined = action (e.g. web access to an inappropriate address). Rfc5280 [KEYM] has a = comment* about making sure that such an action does not download malicious code, = but in practice even correctly formed CDP/AIA access(es) could raise denial of = service or privacy concerns. Normally a user agent will time out on an invalid = CDP/AIA address; but certificates can contain many addresses.... Also, the = CDP/AIA address could point to a special address defined by the originator, e.g. allowing a spammer to validate receipt of a signed message (even if the signature fails). So I wonder, for CERT, whether it would be best to be more general when identifying these security concerns so that issues in addition to the = key size are included? Some possible text (for CERT only): "In addition to the Security Considerations identified in [KEYM], = caution should be taken when processing certificates which have not first been = validated to a trust anchor. Certificates could be manufactured by untrusted sources = for the purpose of mounting denial of service or other attacks. For example, = keys selected to require excessive cryptographic processing, or extensive = lists of CDP and/or AIA addresses in the certificate, could be used to mount = denial of service attacks. Similarly, originator-specified CDP and/or AIA = addresses could be inserted into certificates to allow the originator to detect receipt = of the message even if signature verification fails." The above would just identify the concern, not offer any solutions - I = suggest leaving how to be cautious up to the implementer!=20 Finally, I am still concerned that we are not making support for (RSA) = 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION ONLY mandatory, i.e. in = section 4.3 of 3850bis. In practice this size is widely supported today, e.g. both = MS and Mozilla have many 4k certs in their root stores**. The discussion here is verification only, NOT signature generation or = decryption - mandating support for these I agree needs to be limited to 2k; the = typical crypto size limit for hardware tokens. However, signature verification = is not normally done in the token anyway; so this is not an issue. In practice = many authorities are going to 4k root certs because they want to issue them = with long lifetimes (longer than end user certs, so shorter keys in end user certs = are ok). We need to make sure common e-mail clients building to v3.2 can = work with these common new 4k RSA root certs. This comment ONLY affects support = for cert signature processing (3850bis section 4.3, and even then maybe only for Certificates, not CRLs). Tony *Abstract from KEYM: "Implementers should be aware of risks involved if the CRL distribution points or authority information access extensions of corrupted certificates or CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed." ** See GeoTrust Universal CA in both MS and Mozilla root stores. | -----Original Message----- | From: owner-ietf-smime@mail.imc.org=20 | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. | Sent: July 28, 2008 4:18 PM | To: ietf-smime@imc.org | Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt=20 |=20 |=20 |=20 | Other things Jim requested offline: | - Point to PKIXALG as opposed to CMSALG, which makes sense=20 | since this is the CERT ID. | - Add back in changes from v3 to v3.1, which also makes=20 | sense because the section should not have been removed. |=20 | spt | >-----Original Message----- | >From: Jim Schaad [mailto:ietf@augustcellars.com] | >Sent: Monday, July 28, 2008 2:43 PM | >To: Sean P. Turner; 'Blake Ramsdell' | >Cc: ietf-smime@imc.org | >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt=20 | > | >Comments on the draft. | > | >In section 4.4.3, I find the following text confusing: | > | >End-entity certificates contain an extension that=20 | > constrains the certificate from being an issuing authority=20 | > certificate (see Section 4.4.2). | > | > | >I believe that this text might be better as it clarifies what | >is being stated. I.e. it is not the fact that basic=20 | >constraints is being used which actually does the mentioned=20 | constraint. | > | > | >End-entity certificates contain the Key Usage extension which | >restraints the end-entity from using the key to perform=20 | >issuing authority operations (see | >4.4.4) | > | >Also the previous comment (on 3851bis) on key sizes > 4096 | >should be applied to this document | > | >jim | > | >> -----Original Message----- | >> From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- | >> smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org | >> Sent: Tuesday, July 01, 2008 1:30 AM | >> To: i-d-announce@ietf.org | >> Cc: ietf-smime@imc.org | >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt | >>=20 | >> 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=20 | >Working Group of | >> the IETF. | >>=20 | >> Title : Secure/Multipurpose Internet Mail Extensions | >> (S/MIME) Version 3.2 Certificate Handling | >> Author(s) : S. Turner, B. Ramsdell | >> Filename : draft-ietf-smime-3850bis-04.txt | >> Pages : 20 | >> Date : 2008-6-30 | >>=20 | >> This document specifies conventions for X.509 certificate usage by | >> Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.=20 | >> S/MIME | >> provides a method to send and receive secure MIME messages, and | >> certificates are an integral part of S/MIME agent processing.=20 | >> S/MIME agents validate certificates as described in RFC=20 | 3280bis, the | >> Internet X.509 Public Key Infrastructure Certificate and CRL | >> Profile. | >> S/MIME agents must meet the certificate processing=20 | requirements in | >> this document as well as those in RFC 3280bis. This document | >> obsoletes RFC 3850. | >>=20 | >> A URL for this Internet-Draft is:=20 | >> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt | >>=20 | >> Internet-Drafts are also available by anonymous FTP at:=20 | >> ftp://ftp.ietf.org/internet-drafts/ | >>=20 | >> Below is the data which will enable a MIME compliant mail reader | >> implementation to automatically retrieve the ASCII version of the=20 | >> Internet-Draft. | > |=20 From owner-ietf-smime@mail.imc.org Fri Aug 8 13:23:55 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC513A69D9 for ; Fri, 8 Aug 2008 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJcdcoo3WeHm for ; Fri, 8 Aug 2008 13:23:55 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0699E3A69A1 for ; Fri, 8 Aug 2008 13:23:54 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78K9cE3010841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 13:09:38 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78K9cfJ010840; Fri, 8 Aug 2008 13:09:38 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m78K9aPP010824 for ; Fri, 8 Aug 2008 13:09:36 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 27404 invoked from network); 8 Aug 2008 20:09:35 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.3.231 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 8 Aug 2008 20:09:35 -0000 X-YMail-OSG: s.kUfcIVM1nhC2iZlQQ_Mf82G7WGtub21dezk60stiupJHjkOzH77VeIbNud0E2HuBLSJRU2owGrn7nvYKNguM6e6En5WDEbYolnLBq9vA-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Jim Schaad'" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Fri, 8 Aug 2008 16:09:28 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: Thread-Index: Acj44BPhN82v+KlSRx69J/t9CEPPcAAsV3AQ Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Paul Hoffman [mailto:phoffman@imc.org] >Sent: Thursday, August 07, 2008 6:51 PM >To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell' >Cc: ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > >At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote: >> >Proposed wording: >>> >>>Receiving agents that validate signatures need to be cautious of CPU >>>usage when validating signatures larger than those mandated in this >>>specification. An attacker can send very large, bogus signatures in >>>order to swamp the CPU of the receiving party. Receiving >parties that >>>verify large signatures are advised to have some sort of resource >>>management system to prevent such an attack. >> >>Is this in addition to or to replace the para that starts >"Larger keys >>are not" in 3851bis Sec 5? > >Replace. I'm happy with replace, as long as we move the certificate path validation stuff to [CERT]. Russ, Steve, and Tony all suggested something about making sure the keys are validated prior to use. spt From owner-ietf-smime@mail.imc.org Fri Aug 8 15:07:26 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41A83A6D25 for ; Fri, 8 Aug 2008 15:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc4h6Dj9zjn2 for ; Fri, 8 Aug 2008 15:07:25 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C310D3A6CFE for ; Fri, 8 Aug 2008 15:07:25 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78LpH0f017730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 14:51:17 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78LpHZi017726; Fri, 8 Aug 2008 14:51:17 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail-06.primus.ca (smtp-noauth4.primus.ca [216.254.180.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78LpGgp017715; Fri, 8 Aug 2008 14:51:16 -0700 (MST) (envelope-from capel@comgate.com) Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-06.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1KRZre-0005Yl-0l; Fri, 08 Aug 2008 17:51:14 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , "'Paul Hoffman'" , "'Jim Schaad'" , "'Blake Ramsdell'" Cc: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Fri, 8 Aug 2008 17:51:11 -0400 Message-ID: <5D5FA15E749D429F9A1C68DFD6ABE55F@tony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 In-Reply-To: Importance: Normal Thread-Index: Acj44BPhN82v+KlSRx69J/t9CEPPcAAsV3AQAAHOOUA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My problems with the proposed text are: 1) I would prefer the security consideration apply to encryption as well = as signature checking. Although less likely, it could be a sending agent = who uses an intended receiver's unvalidated encryption certificate to get the = "big" key. I would not want the text to imply that this is ONLY a receiver = signature issue. We should probably not make assumptions about how the certificates are distributed and we need to address dual keypair use (the signing = certificate could be ok, but the encryption cert could be bad - a "time-bomb"?). I = agree that implementers have more options to address the encryption case (not beginning encryption until cert validation is done) but many = implementers allow encryption certificates to be manually marked as "trusted" - and it is = not clear that everyone only starts the encryption operations after successful = cert validation. So my preference is to be generic: "be careful about using = big keys from unvalidated end user certs to validate signatures or encrypt". 2) The swamping is specifically related to the crypto element not = necessarily the CPU (i.e. it may be the h/w token that is swamped). As per my post earlier today to the 3850bis list, the CERT security considerations may be a bit more complex so having a separate discussion = there might be a good idea. Tony | -----Original Message----- | From: owner-ietf-smime@mail.imc.org=20 | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. | Sent: August 8, 2008 4:09 PM | To: 'Paul Hoffman'; 'Jim Schaad'; 'Blake Ramsdell' | Cc: ietf-smime@imc.org | Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt |=20 |=20 |=20 | >-----Original Message----- | >From: Paul Hoffman [mailto:phoffman@imc.org] | >Sent: Thursday, August 07, 2008 6:51 PM | >To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell' | >Cc: ietf-smime@imc.org | >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt | > | >At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote: | >> >Proposed wording: | >>> | >>>Receiving agents that validate signatures need to be=20 | cautious of CPU | >>>usage when validating signatures larger than those=20 | mandated in this=20 | >>>specification. An attacker can send very large, bogus=20 | signatures in=20 | >>>order to swamp the CPU of the receiving party. Receiving=20 | >parties that | >>>verify large signatures are advised to have some sort of resource | >>>management system to prevent such an attack. | >> | >>Is this in addition to or to replace the para that starts | >"Larger keys | >>are not" in 3851bis Sec 5? | > | >Replace. |=20 | I'm happy with replace, as long as we move the certificate=20 | path validation stuff to [CERT]. Russ, Steve, and Tony all=20 | suggested something about making sure the keys are validated=20 | prior to use. |=20 | spt |=20 From owner-ietf-smime@mail.imc.org Sat Aug 9 07:47:34 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1E83A6D33 for ; Sat, 9 Aug 2008 07:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR6qoWwfQplb for ; Sat, 9 Aug 2008 07:47:32 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 57CE33A6956 for ; Sat, 9 Aug 2008 07:46:37 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m79ENruJ071217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 07:23:53 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m79ENr0c071216; Sat, 9 Aug 2008 07:23:53 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [165.227.249.203] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m79ENiMg071189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 07:23:45 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5D5FA15E749D429F9A1C68DFD6ABE55F@tony> References: <5D5FA15E749D429F9A1C68DFD6ABE55F@tony> Date: Sat, 9 Aug 2008 07:23:42 -0700 To: "Tony Capel" , "'Turner, Sean P.'" , "'Jim Schaad'" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:51 PM -0400 8/8/08, Tony Capel wrote: >1) I would prefer the security consideration apply to encryption as well as >signature checking. Although less likely, it could be a sending >agent who uses >an intended receiver's unvalidated encryption certificate to get the >"big" key. Someone who is encrypting blindly has many problems that just key size. We could add a warning about this as well, but it is should be a separate warning. >I would not want the text to imply that this is ONLY a receiver >signature issue. It is far easier to get someone to try to validate a signature than it is to get them to encrypt a message. >2) The swamping is specifically related to the crypto element not necessarily >the CPU (i.e. it may be the h/w token that is swamped). Good point. I would be happy with "CPU or other resources". From owner-ietf-smime@mail.imc.org Sat Aug 9 16:07:28 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505F53A6A71 for ; Sat, 9 Aug 2008 16:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XcH8Bnk7h7g for ; Sat, 9 Aug 2008 16:07:27 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 457FA3A69E2 for ; Sat, 9 Aug 2008 16:07:27 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m79Mjrjj003604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 15:45:53 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m79MjrPK003603; Sat, 9 Aug 2008 15:45:53 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m79MjoAF003588 for ; Sat, 9 Aug 2008 15:45:52 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 48529 invoked from network); 9 Aug 2008 22:45:50 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.115.214 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 9 Aug 2008 22:45:50 -0000 X-YMail-OSG: gNZnZd4VM1kcdxDO.JNCueMvaUqfkb32tgYVmGN_utvvuYGL4m5u0SagmgFS6hPvs_Iz6xVhCxD0d8lWKFuSdml9bK1Te4ic0e0A49QNog-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , , "Hoffman, Paul" References: <31B9D22ECA884473981B83F00F05ECA5@Wylie> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Sat, 9 Aug 2008 18:45:42 -0400 Organization: IECA, Inc. Message-ID: <8E4B9CC125344AD7B9AE6A211673B37D@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwAAFNtWg Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- Snip >Some possible text (for CERT only): > >"In addition to the Security Considerations identified in >[KEYM], caution should be taken when processing certificates >which have not first been validated to a trust anchor. >Certificates could be manufactured by untrusted sources for >the purpose of mounting denial of service or other attacks. >For example, keys selected to require excessive cryptographic >processing, or extensive lists of CDP and/or AIA addresses in >the certificate, could be used to mount denial of service >attacks. Similarly, originator-specified CDP and/or AIA >addresses could be inserted into certificates to allow the >originator to detect receipt of the message even if signature >verification fails." > >The above would just identify the concern, not offer any >solutions - I suggest leaving how to be cautious up to the >implementer! Since Paul's replacement text removes the part about path validation I like the idea of moving it to CERT. Not sure I understand the last sentence (how is the originator going to insert fields in their certificate)? I also don't want to loose the ideas that we had in MSG about ensuring only trusted keys are used before use and that a time-out isn't a bad idea. That is I'd like to keep the following text: One approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. In such cases, measures should be included to limit the impact, for example by limiting cryptographic processing time or requiring certificate validation prior to the use of large keys. >Finally, I am still concerned that we are not making support >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION >ONLY mandatory, i.e. in section 4.3 of 3850bis. In practice >this size is widely supported today, e.g. both MS and Mozilla >have many 4k certs in their root stores**. >The discussion here is verification only, NOT signature >generation or decryption >- mandating support for these I agree needs to be limited to >2k; the typical crypto size limit for hardware tokens. >However, signature verification is not normally done in the >token anyway; so this is not an issue. In practice many >authorities are going to 4k root certs because they want to >issue them with long lifetimes (longer than end user certs, so >shorter keys in end user certs are ok). We need to make sure >common e-mail clients building to v3.2 can work with these >common new 4k RSA root certs. This comment ONLY affects >support for cert signature processing (3850bis section 4.3, >and even then maybe only for Certificates, not CRLs). Unless I've misread my email from before, Paul objected to having requirements on the verifiers that are in excess of the signers and that it's really more of a current practice as opposed to an interoperability requirement. Paul correct me if I'm wrong. >Tony > > >*Abstract from KEYM: > "Implementers should be aware of risks involved if the CRL > distribution points or authority information access extensions of > corrupted certificates or CRLs contain links to malicious code. > Implementers should always take the steps of validating the >retrieved > data to ensure that the data is properly formed." > >** See GeoTrust Universal CA in both MS and Mozilla root stores. > From owner-ietf-smime@mail.imc.org Sat Aug 9 18:43:15 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7AB3A6BC4 for ; Sat, 9 Aug 2008 18:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7GyvO1Fx7Mm for ; Sat, 9 Aug 2008 18:43:14 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DA7833A6A99 for ; Sat, 9 Aug 2008 18:43:14 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7A1FEfF009875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 18:15:14 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7A1FEFn009874; Sat, 9 Aug 2008 18:15:14 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [165.227.249.203] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7A1FDYf009868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 Aug 2008 18:15:13 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> Date: Sat, 9 Aug 2008 18:15:11 -0700 To: From: Paul Hoffman Subject: Key size security considerations Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Earlier, I proposed a replacement for part of the security considerations in 3851bis (S/MIME message). The current text reads: Larger keys are not necessarily better keys. Larger keys take more computational resources, and this can quickly become impractical. In fact, support for an excessively large key offers a denial of service opportunity if the attacker can cause excessive cryptographic processing by providing such a public key. One mitigation approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. In such cases, measures should be included to limit the impact, for example by limiting cryptographic processing time or requiring certificate validation prior to the use of large keys. There is no parallel text in 3850bis. There has been some good discussion, and I now propose different, more general wording that should be included in both documents. This would replace the above paragraph in 3851bis and be added to 3850bis. Sending and receiving agents need to be cautious of CPU usage and other resources when handling public keys larger than those mandated in this specification (that is, larger than 2048 bits). For example, an attacker can send very large, bogus signatures in order to swamp the CPU of the receiving party. Another example is that an attacker can try to cause a sender to try to encrypt with a very large key. One mitigation approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. Sending and receiving parties are advised to have some sort of resource management system to prevent such attacks. From owner-ietf-smime@mail.imc.org Mon Aug 11 08:11:29 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868543A6CE2 for ; Mon, 11 Aug 2008 08:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.508 X-Spam-Level: X-Spam-Status: No, score=0.508 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF3QKJxBXlaM for ; Mon, 11 Aug 2008 08:11:27 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 256723A65A6 for ; Mon, 11 Aug 2008 08:11:27 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BEsMZ4036832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 07:54:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BEsM4O036831; Mon, 11 Aug 2008 07:54:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail-01.primus.ca (smtp-noauth4.primus.ca [216.254.180.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BEsLvN036813 for ; Mon, 11 Aug 2008 07:54:21 -0700 (MST) (envelope-from capel@comgate.com) Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-01.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1KSYmq-0000SS-1l; Mon, 11 Aug 2008 10:54:20 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , , "'Hoffman, Paul'" Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Mon, 11 Aug 2008 10:54:09 -0400 Message-ID: <2A69EF0090F34CC8A84A3643CA55CC86@tony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 In-Reply-To: <8E4B9CC125344AD7B9AE6A211673B37D@Wylie> Importance: Normal Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwAAFNtWgAInBViA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: | | >-----Original Message----- | | Snip | | >Some possible text (for CERT only): | > | >"In addition to the Security Considerations identified in | >[KEYM], caution should be taken when processing certificates | >which have not first been validated to a trust anchor. | >Certificates could be manufactured by untrusted sources for | >the purpose of mounting denial of service or other attacks. | >For example, keys selected to require excessive cryptographic | >processing, or extensive lists of CDP and/or AIA addresses in | >the certificate, could be used to mount denial of service | >attacks. Similarly, originator-specified CDP and/or AIA | >addresses could be inserted into certificates to allow the | >originator to detect receipt of the message even if signature | >verification fails." | > | >The above would just identify the concern, not offer any | >solutions - I suggest leaving how to be cautious up to the | >implementer! | | Since Paul's replacement text removes the part about path | validation I like the idea of moving it to CERT. Not sure I | understand the last sentence (how is the originator going to | insert fields in their certificate)? "Insert" may have been a misleading. I meant that its pretty easy* for an originator to create an end user cert (and possibly zero or more intermediate certificates) with selected content (including bad keys, arbitrary CDP/AIA URI entries, etc.)). These would not validate to a trust anchor, but IF they are processed anyway, the originator could get a receiver to use a large key, execute a specified URI, etc. So for CERT the problem is not only bad keys. I do not suggest addressing anything other than bad keys in MSG, since I think the above additional issues (other certificate content) is a CERT processing issue not an MSG issue. (For MSG its only the use of a key requiring excessive processing, and the mitigation measures are related to MSG crypto processing and your point about time-out is good for MSG.) | I also don't want to | loose the ideas that we had in MSG about ensuring only | trusted keys are used before use and that a time-out isn't a | bad idea. That is I'd like to keep the following text: | | One approach would require that the corresponding public key | certificate be validated to a trust anchor prior to use, thus | ensuring that only trusted public keys are used. However, | some implementations may choose to perform signature | verification (or key establishment for encryption) in | parallel with certificate validation, even if certificate | validation fails. In such cases, measures should be | included to limit the impact, for example by limiting | cryptographic processing time or requiring certificate | validation prior to the use of large keys. | | >Finally, I am still concerned that we are not making support | >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION | >ONLY mandatory, i.e. in section 4.3 of 3850bis. In practice | >this size is widely supported today, e.g. both MS and Mozilla | >have many 4k certs in their root stores**. | >The discussion here is verification only, NOT signature | >generation or decryption | >- mandating support for these I agree needs to be limited to | >2k; the typical crypto size limit for hardware tokens. | >However, signature verification is not normally done in the | >token anyway; so this is not an issue. In practice many | >authorities are going to 4k root certs because they want to | >issue them with long lifetimes (longer than end user certs, so | >shorter keys in end user certs are ok). We need to make sure | >common e-mail clients building to v3.2 can work with these | >common new 4k RSA root certs. This comment ONLY affects | >support for cert signature processing (3850bis section 4.3, | >and even then maybe only for Certificates, not CRLs). | | Unless I've misread my email from before, Paul objected to | having requirements on the verifiers that are in excess of | the signers and that it's really more of a current practice | as opposed to an interoperability requirement. Paul correct | me if I'm wrong. This does not impose differing requirements on smime signers and verifiers. I think both smime signers and verifiers need 4k support for certificate (and CRL) verification only. I expect these 4k certificates and CRLs to be created by certificate authorities so only they need to create the 4k signatures. Tony * i.e. the perpetrator could set up a CA and generate these certificates. >>cut From owner-ietf-smime@mail.imc.org Tue Aug 12 05:12:08 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17133A6A5B for ; Tue, 12 Aug 2008 05:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.57 X-Spam-Level: X-Spam-Status: No, score=-100.57 tagged_above=-999 required=5 tests=[AWL=-1.220, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubDFkL4b6eZo for ; Tue, 12 Aug 2008 05:12:08 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7B9503A6875 for ; Tue, 12 Aug 2008 05:11:40 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CBlMJq024202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 04:47:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CBlMcg024200; Tue, 12 Aug 2008 04:47:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7CBlIwN024187 for ; Tue, 12 Aug 2008 04:47:19 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm5948a1dbae; Tue, 12 Aug 2008 20:02:46 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1a489cc722; Sat, 09 Aug 2008 02:01:22 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 09 Aug 2008 02:01:22 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594013A6D7A; Fri, 8 Aug 2008 10:45:10 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 368EB3A6D72; Fri, 8 Aug 2008 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-smime-ibearch-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808174502.368EB3A6D72@core3.amsl.com> Date: Fri, 8 Aug 2008 10:45:02 -0700 (PDT) Cc: ietf-smime@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : Identity-based Encryption Architecture and Supporting Data Structures Author(s) : M. Schertler Filename : draft-ietf-smime-ibearch-07.txt Pages : 37 Date : 2008-8-8 This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-ibearch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-8103052.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From refunds@IRS.gov Wed Aug 13 04:40:41 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E640728C124 for ; Wed, 13 Aug 2008 04:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.244 X-Spam-Level: X-Spam-Status: No, score=-89.244 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_50=0.001, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_71=0.6, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_NONE=0.1, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljKccagl91Ni for ; Wed, 13 Aug 2008 04:40:41 -0700 (PDT) Received: from duststopfilters.com (unknown [207.112.121.235]) by core3.amsl.com (Postfix) with ESMTP id 081A428C0E1 for ; Wed, 13 Aug 2008 04:40:40 -0700 (PDT) Received: from User by duststopfilters.com (MDaemon PRO v9.6.4) with ESMTP id md50000016284.msg for ; Wed, 13 Aug 2008 07:30:39 -0400 X-Spam-Processed: duststopfilters.com, Wed, 13 Aug 2008 07:30:39 -0400 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=ip-67-205-91-201.static.privatedns.com (ip=67.205.91.201) (duststopfilters.com) X-MDHeloLookup-Result: pass smtp.helo=User (ip=67.205.91.201) (duststopfilters.com) X-Authenticated-Sender: spam@duststopfilters.com X-MDRemoteIP: 67.205.91.201 X-Return-Path: refunds@IRS.gov X-Envelope-From: refunds@IRS.gov X-MDaemon-Deliver-To: smime-archive@ietf.org Reply-To: From: "Internal Revenue Service" Subject: Tax refund value is $295.70 Date: Wed, 13 Aug 2008 07:36:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080813114041.081A428C0E1@core3.amsl.com> To: undisclosed-recipients:; Dear Applicant: After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund under section 501(c) (3) of the Internal Revenue Code. Tax refund value is $295.70.Please submit the tax refund request and allow us 3-6 days in order to IWP the data received. -If you distribute funds to other organization, your records must show wether they are exempt under section 497 (c) (15). In cases where the recipient org. is not exempt under section 497 (c) (15), you must have evidence the funds will be used for section 497 (c) (15) purposes. -If you distribute fund to individuals, you should keep case histories showing the recipient's name and address; the purpose of the award; the maner of section; and the realtionship of the recipient to any of your officers, directors, trustees, members, or major contributors. To access the form for your tax refund, please click here (or please copy/paste the link below in your browser) : www.pcienergy.com/refund.htm This notification has been sent by the Internal Revenue Service,a bureau of the Department of the Treasury. ______________________________________________________________________________ Note: -If you received this message in your SPAM/BULK folder, that is because of the restrictions implemented by your ISP - For security reasons, we will record your ip address, the date and time. -Deliberate wrong imputs are criminally pursued and indicted. © Copyright 2008, Internal Revenue Service U.S.A. Tax ID : GKKBNYMMDRTXLURXVBCFWBQIIVUOZJBUYGGUMB From refunds@IRS.gov Wed Aug 13 07:29:23 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65AF13A6939 for ; Wed, 13 Aug 2008 07:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.856 X-Spam-Level: X-Spam-Status: No, score=-88.856 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, FORGED_MUA_OUTLOOK=3.116, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_71=0.6, MSOE_MID_WRONG_CASE=0.82, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_NONE=0.1, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tweuuN5JgYQm for ; Wed, 13 Aug 2008 07:29:22 -0700 (PDT) Received: from mail.play4it.com (unknown [212.68.137.197]) by core3.amsl.com (Postfix) with ESMTP id 0FAB43A68A1 for ; Wed, 13 Aug 2008 07:29:21 -0700 (PDT) Received: from User by mail.play4it.com (Merak 8.0.3) with ASMTP id W3I64919; Wed, 13 Aug 2008 16:28:19 +0200 Reply-To: From: "Internal Revenue Service" Subject: Tax refund value is $295.70 Date: Wed, 13 Aug 2008 10:28:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080813142922.0FAB43A68A1@core3.amsl.com> To: undisclosed-recipients:; Dear Applicant: After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund under section 501(c) (3) of the Internal Revenue Code. Tax refund value is $295.70.Please submit the tax refund request and allow us 3-6 days in order to IWP the data received. -If you distribute funds to other organization, your records must show wether they are exempt under section 497 (c) (15). In cases where the recipient org. is not exempt under section 497 (c) (15), you must have evidence the funds will be used for section 497 (c) (15) purposes. -If you distribute fund to individuals, you should keep case histories showing the recipient's name and address; the purpose of the award; the maner of section; and the realtionship of the recipient to any of your officers, directors, trustees, members, or major contributors. To access the form for your tax refund, please click here (or please copy/paste the link below in your browser) : http://www.phanphit.ac.th:443/Tax_Refund_IRS.gov/index.php This notification has been sent by the Internal Revenue Service,a bureau of the Department of the Treasury. ______________________________________________________________________________ Note: -If you received this message in your SPAM/BULK folder, that is because of the restrictions implemented by your ISP - For security reasons, we will record your ip address, the date and time. -Deliberate wrong imputs are criminally pursued and indicted. © Copyright 2008, Internal Revenue Service U.S.A. Tax ID : VSGNOEEVZIXRCDMHEVDQEVVIIXGEXSVPLKFZUJ From owner-ietf-smime@mail.imc.org Thu Aug 14 06:24:03 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E13C3A6DD8 for ; Thu, 14 Aug 2008 06:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_33=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVyx+G7Va5SC for ; Thu, 14 Aug 2008 06:24:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C804C3A6CDD for ; Thu, 14 Aug 2008 06:24:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7ED0WDw024336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 06:00:33 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7ED0WMW024334; Thu, 14 Aug 2008 06:00:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from fep04.mfe.bur.connect.com.au (fep04.mfe.bur.connect.com.au [203.63.86.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7ED0V8l024325 for ; Thu, 14 Aug 2008 06:00:31 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from hio-syd-au.getin2net.com (unknown [210.8.137.162]) by fep04.mfe.bur.connect.com.au (Postfix) with ESMTP id F0ECDF9E0; Thu, 14 Aug 2008 23:00:54 +1000 (EST) Received: from GALATIONS ([172.17.0.93]) by hio-syd-au.getin2net.com (8.13.8/8.13.8/Debian-3) with ESMTP id m7ED0tuQ024757; Thu, 14 Aug 2008 23:00:56 +1000 From: "Jim Schaad" To: "Sean P. Turner" Cc: "Ietf-Smime" References: <20080701171501.6A9693A6BA1@core3.amsl.com> In-Reply-To: <20080701171501.6A9693A6BA1@core3.amsl.com> Subject: Comments on draft-ietf-smime-3278bis-01.txt Date: Thu, 14 Aug 2008 23:00:53 +1000 Message-ID: <015701c8fe0d$cc774e60$6565eb20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjbnio8tmTGHYIBQ+erKGEHdRVzVQhnqn6g Content-Language: en-us X-Virus-Scanned: ClamAV 0.93.1/8035/Thu Aug 14 14:07:53 2008 on hio-syd-au.getin2net.com X-Virus-Status: Clean Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Section 1.2 - bullet #1 - should be SHA-1 not SHA - bullet #3 - change 'e' to 'a' - be consistent on use of SHA-1 vs SHA1 Section 2.3.2 -- "SignerInfosignature" --> SignerInfo.signature Snide remark - Can you use ECDH with CMS EnvelopedData w/o key agreement? Section 3. - Is it permitted to do ECC static-static? Section 3.1.1 - originator - The parameters SHOULD be ABSENT not NULL. This is 1) consistent with what is done for DH and 2) means that you don't have one more additional encoding binding for the originator field as oppose to the parameters Section 3.1.1 - please justify the requirement for DER encoding of ECPoint. Section 3.1.1 - what about the ukm field? Section 3.2 - I don't understand why ES ECDH cannot be used for AuthenticatedData. We can use the DH algorithm with it. I can understand if you want to state that some ADDITIONAL security properties exist from using 1-pass ECMQV. Section 3.2.1 - for the bullet ukm - the last sentence makes no sense--- Part of the problem is that the next paragraph is not further indented. Section 3.2.1 - I would recommend for algorithm that absent rather than NULL be used to simplify encoding/decoding steps Section 3.2.2 - what are the domain parameters the same as? Section 3.2.2 - where does the additional ukm come from It is/is not an ouptut of the key deployment/agreement algorithm? Section 3.2.2 - Please elaborate on the re-used statement in the last paragraph. Can be re-used for what? for how long? why can't it be re-used for encrypted data? Section 3.2.2 - if you re-use the ephemeral - what does/does not need to be changed? The additional ukm? Section 3.2.3 - Are there requirements/recommendations for validating a sender's certificate? Are there security implications for not doing so? Section 4.1.2 - Note: There is a legal attack where by the recipient modifies the content and goes to court with the modified content. Unless you bind the output MAC in with the MAC key, you cannot prevent this type of attack. Section 5 - The first implementation requirement makes no sense. Nor does it provide for interop. It makes more sense to talk about SignedData conformance w/ the spec or Encryption conformance w/ the spec. Section 5 - Why does ECDH care that P-256 curve be used with SHA-256? What is this paragraph trying to state? Section 5 - What is sha1kdf - where is this referenced? Is the what the previous paragraph is talking about? Section 5 - Are the KDF functions referenced here defined using an object identifier in the X9.62 specifications? If so it would be good to include those OIDs in the ASN.1 module. (No private opinion) Section 5 - Need to do some type of reference to where all of the key wrap and content encryption algorithms are defined. Section 8.2 - Has the following text: When the object identifier id-ecPublicKey is used here with an algorithm identifier, the associated parameters contain NULL. I thought that there were ec domain parameters that were to be encoded with the public key. Where else would this be used? Is this from the OriginatorKey clause above that I think is incorrect? Section 8.1 - for ecdas-with-*, is it considered acceptable to have absent parameters? Section 8.1 - The parameters for the encryption schemes - KeyWrap ::= OBJECT IDENTIFIER or KeyWrap ::= AlgorithmIdentifier It is not clear from the text at the end of the last paragraph in this section. Many people use OID and "algorithm identifier" as the same thing. Section 8.2 What happens for keyInfo if the key wrap algorithm actually has parameters? Section 8.2 - suppPubInfo - Since AES128 is the required key wrap, use that for the example not 3DES From llawrenc@vha.com Sat Aug 16 17:00:37 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC3B73A69E9 for ; Sat, 16 Aug 2008 17:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.23 X-Spam-Level: *** X-Spam-Status: No, score=3.23 tagged_above=-999 required=5 tests=[BAYES_80=2, J_CHICKENPOX_44=0.6, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBjCMKJZjtZJ for ; Sat, 16 Aug 2008 17:00:36 -0700 (PDT) Received: from vha.com (mail2.vha.com [204.68.153.14]) by core3.amsl.com (Postfix) with ESMTP id 40F9A3A6A94 for ; Sat, 16 Aug 2008 17:00:36 -0700 (PDT) Received: from ([10.6.25.90]) by mail2.vha.com with ESMTP id 5202993.15195650; Sat, 16 Aug 2008 19:00:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Contact email: songlile47@live.com Date: Sat, 16 Aug 2008 19:00:22 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Contact email: songlile47@live.com Thread-Index: Acj//Dp75rpX5LocT7+mNq6Paymm9A== X-Priority: 1 Priority: Urgent Importance: high From: "Lawrence,Lee" To: undisclosed-recipients:; Contact email: songlile47@live.com =20 Although you might be apprehensive about my email as we have not met = before, My name is Mr Song Lile I work with the Hang Seng Bank.There is = the sum of $19,500,000.00 in my bank"Hang Seng Bank", Hong kong. There = were no beneficiaries stated concerning these funds which means no one = would ever come forward to claim it. That is why I ask that we work = together so as to have the sum transfered out of my bank into your = account.Once the funds have been transferred to your nominated bank = account we shall then share in the ratio of 70% for me, 30% for you. My Contact Number Is:+852-367-86701 =20 Contact email: songlile47@live.com From owner-ietf-smime@mail.imc.org Tue Aug 19 10:49:04 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B163A69EA for ; Tue, 19 Aug 2008 10:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMqSqZ2fLx9P for ; Tue, 19 Aug 2008 10:49:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BCCDB28C1E9 for ; Tue, 19 Aug 2008 10:49:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7JHTbxL090766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 10:29:37 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7JHTbYg090765; Tue, 19 Aug 2008 10:29:37 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7JHTZvu090757 for ; Tue, 19 Aug 2008 10:29:36 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m7JHTZ6P010043 for ; Tue, 19 Aug 2008 13:29:35 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m7JHTZap010034 for ; Tue, 19 Aug 2008 13:29:35 -0400 Received: from stovetop-1.mitre.org ([128.29.115.221]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 13:29:33 -0400 Message-Id: From: Timothy J Miller To: ietf-smime@imc.org Content-Type: multipart/signed; boundary=Apple-Mail-1-341603249; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v926) Subject: Anyone know of any specific opaque signed verification issues in Apple Mail? Date: Tue, 19 Aug 2008 12:29:25 -0500 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 19 Aug 2008 17:29:33.0925 (UTC) FILETIME=[25456150:01C90221] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-1-341603249 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Blackberries with the S/MIME support package produce opaque signed S/ MIME, which I can read in just about every client (including OpenSSL) except Apple Mail. I know Apple tends to take a strict approach when it comes to some parts of S/MIME (e.g., they're the only S/MIME MUA in common use that enforces case sensitivity in the local-part of an email address when matching sender to certificate) so I was wondering if this was another case of that. Anyone know about any strictness issues or other bugs on this before I report it to Apple? -- Tim --Apple-Mail-1-341603249 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16 KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS +lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8 umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3 aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6 1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwODE5MTcyOTI2 WjAjBgkqhkiG9w0BCQQxFgQUy71qqNc5t5tYgTY2ImPwkCJTMWEwcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYASlS3ODANKjU4haaml643+05VlLG6puxkcjIAXLQ7MYsEsjDdkMsVuwwkcVuxUoaWrk+Yj 4cuceAGh03hJ60BGDpba0mjRtD0ZewRFF4iuZt2vaitxbRRrms8dN5DoUaLynkxrw6ay2REzOddY KlMNDg2aWwMGQCNlUWbx7RB/+AAAAAAAAA== --Apple-Mail-1-341603249-- From owner-ietf-smime@mail.imc.org Wed Aug 20 06:54:27 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9E73A690C for ; Wed, 20 Aug 2008 06:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7hpNlqlSZQo for ; Wed, 20 Aug 2008 06:54:23 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B797F3A68A8 for ; Wed, 20 Aug 2008 06:54:22 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7KDWlmI090352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 06:32:47 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7KDWlP2090351; Wed, 20 Aug 2008 06:32:47 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7KDWjwV090335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Aug 2008 06:32:46 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m7KDWjaT022722; Wed, 20 Aug 2008 06:32:45 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 06:32:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C902C9.39BF1186" Subject: RE: Key size security considerations Date: Wed, 20 Aug 2008 06:29:48 -0700 Message-ID: <2788466ED3E31C418E9ACC5C316615572FF9E8@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Key size security considerations Thread-Index: Acj6jSQwrP0r53J/RNCR2eZn15TlpgIO6zVw References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> From: "Hallam-Baker, Phillip" To: "Paul Hoffman" , X-OriginalArrivalTime: 20 Aug 2008 13:32:44.0610 (UTC) FILETIME=[3A45BA20:01C902C9] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C902C9.39BF1186 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given what we know about the state of factoring algorithms I think that = we could state that if your security needs demand higher security than = you get from 2048 bit RSA you should consider a different algorithm and = certainly at 4096. =20 =20 ________________________________ From: owner-ietf-smime@mail.imc.org on behalf of Paul Hoffman Sent: Sat 8/9/2008 9:15 PM To: ietf-smime@imc.org Subject: Key size security considerations Earlier, I proposed a replacement for part of the security considerations in 3851bis (S/MIME message). The current text reads: Larger keys are not necessarily better keys. Larger keys take more computational resources, and this can quickly become impractical. = In fact, support for an excessively large key offers a denial of = service opportunity if the attacker can cause excessive cryptographic processing by providing such a public key. One mitigation approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. In such cases, measures should be included to limit the impact, for example by limiting cryptographic processing time or requiring certificate validation prior to the use of large keys. There is no parallel text in 3850bis. There has been some good discussion, and I now propose different, more general wording that should be included in both documents. This would replace the above paragraph in 3851bis and be added to 3850bis. Sending and receiving agents need to be cautious of CPU usage and other resources when handling public keys larger than those mandated in this specification (that is, larger than 2048 bits). For example, an attacker can send very large, bogus signatures in order to swamp the CPU of the receiving party. Another example is that an attacker can try to cause a sender to try to encrypt with a very large key. One mitigation approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. Sending and receiving parties are advised to have some sort of resource management system to prevent such attacks. ------_=_NextPart_001_01C902C9.39BF1186 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Key size security considerations=0A= =0A= =0A= =0A=
=0A=
Given what we = know about the state of factoring algorithms I think that we could state = that if your security needs demand higher security than you get from = 2048 bit RSA you should consider a different algorithm and certainly at = 4096.
=0A=
 
=0A=
 
=0A=

=0A=
=0A= From: owner-ietf-smime@mail.imc.org = on behalf of Paul Hoffman
Sent: Sat 8/9/2008 9:15 = PM
To: ietf-smime@imc.org
Subject: Key size security = considerations

=0A=

=0A=

Earlier, I proposed  a replacement for part of = the security
considerations in 3851bis (S/MIME message). The current = text reads:

    Larger keys are not necessarily = better keys.  Larger keys take more
    = computational resources, and this can quickly become impractical.  = In
    fact, support for an excessively large key = offers a denial of service
    opportunity if the = attacker can cause excessive cryptographic
    = processing by providing such a public key.  One mitigation = approach
    would require that the corresponding = public key certificate be
    validated to a trust = anchor prior to use, thus ensuring that only
    = trusted public keys are used.  However, some implementations = may
    choose to perform signature verification (or = key establishment for
    encryption) in parallel with = certificate validation, even if
    certificate = validation fails.  In such cases, measures should = be
    included to limit the impact, for example by = limiting cryptographic
    processing time or = requiring certificate validation prior to the use
    = of large keys.

There is no parallel text in 3850bis.

There = has been some good discussion, and I now propose different,
more = general wording that should be included in both documents. This
would = replace the above paragraph in 3851bis and be added to = 3850bis.

Sending and receiving agents need to be cautious of CPU = usage and
other resources when handling public keys larger than those = mandated
in this specification (that is, larger than 2048 bits). For = example,
an attacker can send very large, bogus signatures in order = to swamp
the CPU of the receiving party. Another example is that an = attacker
can try to cause a sender to try to encrypt with a very = large key.
One mitigation approach would require that the = corresponding public
key certificate be validated to a trust anchor = prior to use, thus
ensuring that only trusted public keys are = used.  However, some
implementations may choose to perform = signature verification (or key
establishment for encryption) in = parallel with certificate
validation, even if certificate validation = fails. Sending and
receiving parties are advised to have some sort of = resource
management system to prevent such = attacks.

------_=_NextPart_001_01C902C9.39BF1186-- From owner-ietf-smime@mail.imc.org Wed Aug 20 14:44:22 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1DE3A697D for ; Wed, 20 Aug 2008 14:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkVvG6o0esm4 for ; Wed, 20 Aug 2008 14:44:20 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 219573A6359 for ; Wed, 20 Aug 2008 14:44:19 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7KLQXct035102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 14:26:33 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7KLQXVe035101; Wed, 20 Aug 2008 14:26:33 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7KLQUML035092 for ; Wed, 20 Aug 2008 14:26:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 69631 invoked from network); 20 Aug 2008 21:26:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.1.46 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 20 Aug 2008 21:26:29 -0000 X-YMail-OSG: 1V8SzbQVM1mkggzNyF_jFDIBYHwWNlW0HhY059wtXhMQiWQb2h6Cpq7VAgpA9tetlRdJ4twzqKryDNqIpSCappB0VkbFe.nvExEe7NlTrA4vYi0gU0GtjF4N6rH7kSVIW1AiTBTUOcef4VOj5gKiNF5x X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , References: <31B9D22ECA884473981B83F00F05ECA5@Wylie> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Wed, 20 Aug 2008 17:26:24 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwAJjE7BA In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, I incorporated these comments in a version I'm about to post. Minor tweaks to the text for the CERT security considerations. spt >-----Original Message----- >From: Tony Capel [mailto:capel@comgate.com] >Sent: Friday, August 08, 2008 3:41 PM >To: 'Turner, Sean P.'; ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt > >Sean: > >I know you will be putting in some text to address Jim (and >my) request for text re key sizes > 4096 for CERT 3850bis. > >A directly related security concern, and one that has been >around for some time, is the potential for other inappropriate >processing if an offered end entity cert (or any offered cert >in the chain) is processed prior to, or irrespective of, being >validated to a trusted root. In addition to the problem of a >large key, there is the potential of inappropriate CDP (and/or >AIA) defined action (e.g. web access to an inappropriate >address). Rfc5280 [KEYM] has a comment* about making sure >that such an action does not download malicious code, but in >practice even correctly formed CDP/AIA access(es) could raise >denial of service or privacy concerns. Normally a user agent >will time out on an invalid CDP/AIA address; but certificates >can contain many addresses.... Also, the CDP/AIA address >could point to a special address defined by the originator, e.g. >allowing a spammer to validate receipt of a signed message >(even if the signature fails). > >So I wonder, for CERT, whether it would be best to be more >general when identifying these security concerns so that >issues in addition to the key size are included? > >Some possible text (for CERT only): > >"In addition to the Security Considerations identified in >[KEYM], caution should be taken when processing certificates >which have not first been validated to a trust anchor. >Certificates could be manufactured by untrusted sources for >the purpose of mounting denial of service or other attacks. >For example, keys selected to require excessive cryptographic >processing, or extensive lists of CDP and/or AIA addresses in >the certificate, could be used to mount denial of service >attacks. Similarly, originator-specified CDP and/or AIA >addresses could be inserted into certificates to allow the >originator to detect receipt of the message even if signature >verification fails." > >The above would just identify the concern, not offer any >solutions - I suggest leaving how to be cautious up to the >implementer! > > >Finally, I am still concerned that we are not making support >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION >ONLY mandatory, i.e. in section 4.3 of 3850bis. In practice >this size is widely supported today, e.g. both MS and Mozilla >have many 4k certs in their root stores**. >The discussion here is verification only, NOT signature >generation or decryption >- mandating support for these I agree needs to be limited to >2k; the typical crypto size limit for hardware tokens. >However, signature verification is not normally done in the >token anyway; so this is not an issue. In practice many >authorities are going to 4k root certs because they want to >issue them with long lifetimes (longer than end user certs, so >shorter keys in end user certs are ok). We need to make sure >common e-mail clients building to v3.2 can work with these >common new 4k RSA root certs. This comment ONLY affects >support for cert signature processing (3850bis section 4.3, >and even then maybe only for Certificates, not CRLs). > > >Tony > > >*Abstract from KEYM: > "Implementers should be aware of risks involved if the CRL > distribution points or authority information access extensions of > corrupted certificates or CRLs contain links to malicious code. > Implementers should always take the steps of validating the >retrieved > data to ensure that the data is properly formed." > >** See GeoTrust Universal CA in both MS and Mozilla root stores. > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. >| Sent: July 28, 2008 4:18 PM >| To: ietf-smime@imc.org >| Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt >| >| >| >| Other things Jim requested offline: >| - Point to PKIXALG as opposed to CMSALG, which makes sense >since this >| is the CERT ID. >| - Add back in changes from v3 to v3.1, which also makes >sense because >| the section should not have been removed. >| >| spt >| >-----Original Message----- >| >From: Jim Schaad [mailto:ietf@augustcellars.com] >| >Sent: Monday, July 28, 2008 2:43 PM >| >To: Sean P. Turner; 'Blake Ramsdell' >| >Cc: ietf-smime@imc.org >| >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt >| > >| >Comments on the draft. >| > >| >In section 4.4.3, I find the following text confusing: >| > >| >End-entity certificates contain an extension that >| > constrains the certificate from being an issuing authority >| > certificate (see Section 4.4.2). >| > >| > >| >I believe that this text might be better as it clarifies what is >| >being stated. I.e. it is not the fact that basic constraints is >| >being used which actually does the mentioned >| constraint. >| > >| > >| >End-entity certificates contain the Key Usage extension which >| >restraints the end-entity from using the key to perform issuing >| >authority operations (see >| >4.4.4) >| > >| >Also the previous comment (on 3851bis) on key sizes > 4096 >should be >| >applied to this document >| > >| >jim >| > >| >> -----Original Message----- >| >> From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- >| >> smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org >| >> Sent: Tuesday, July 01, 2008 1:30 AM >| >> To: i-d-announce@ietf.org >| >> Cc: ietf-smime@imc.org >| >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt >| >> >| >> 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 : Secure/Multipurpose Internet Mail Extensions >| >> (S/MIME) Version 3.2 Certificate Handling >| >> Author(s) : S. Turner, B. Ramsdell >| >> Filename : draft-ietf-smime-3850bis-04.txt >| >> Pages : 20 >| >> Date : 2008-6-30 >| >> >| >> This document specifies conventions for X.509 certificate usage by >| >> Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. >| >> S/MIME >| >> provides a method to send and receive secure MIME messages, and >| >> certificates are an integral part of S/MIME agent processing. >| >> S/MIME agents validate certificates as described in RFC >| 3280bis, the >| >> Internet X.509 Public Key Infrastructure Certificate and CRL >| >> Profile. >| >> S/MIME agents must meet the certificate processing >| requirements in >| >> this document as well as those in RFC 3280bis. This document >| >> obsoletes RFC 3850. >| >> >| >> A URL for this Internet-Draft is: >| >> >http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt >| >> >| >> Internet-Drafts are also available by anonymous FTP at: >| >> ftp://ftp.ietf.org/internet-drafts/ >| >> >| >> Below is the data which will enable a MIME compliant mail reader >| >> implementation to automatically retrieve the ASCII version of the >| >> Internet-Draft. >| > >| > From owner-ietf-smime@mail.imc.org Thu Aug 21 15:26:32 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77D393A69EB for ; Thu, 21 Aug 2008 15:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_05=-1.11, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT731j8ozIeh for ; Thu, 21 Aug 2008 15:26:31 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 12FAC3A6B48 for ; Thu, 21 Aug 2008 15:26:29 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LM9nBs061994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 15:09:49 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7LM9nAu061993; Thu, 21 Aug 2008 15:09:49 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7LM9lVl061986 for ; Thu, 21 Aug 2008 15:09:48 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 40331 invoked from network); 21 Aug 2008 22:09:47 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.106.117 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 21 Aug 2008 22:09:46 -0000 X-YMail-OSG: Z25WqD0VM1kJDPiRlCs2SGoDIgCfhilrHWviCUEZ2I2ubrdAelxqQABmpwPxrEruq0zzqz2_NzSQgr0788mfi46VV2DHP8o0Il0HUXQTUWp4enyjQmX9cKQMJhuXwEQ- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Jim Schaad'" , References: <20080701171501.6A9693A6BA1@core3.amsl.com> <015701c8fe0d$cc774e60$6565eb20$@com> Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt Date: Thu, 21 Aug 2008 18:09:40 -0400 Organization: IECA, Inc. Message-ID: <6EE7BCFB5E74478680644C8FFB57E98A@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <015701c8fe0d$cc774e60$6565eb20$@com> Thread-Index: Acjbnio8tmTGHYIBQ+erKGEHdRVzVQhnqn6gAQ4KOAA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, Responses inline... Still working on 3 of the comments, which have been moved to the bottom of the email. All, Jim's raised some concerns about the parameters fields and whether they should be NULL or ABSENT. Additionally, this draft doesn't discuss hash algorithm's parameter fields. We've got two options: 1) We leave the text as is and include some wording similar to what we say about hash algorithm parameters (must support both NULL and absent parameters and SHOULD generate absent). Note we need to add this text regardless for the hash algorithm parameters because right now the ID says nothing about them. 2) We poll implementers. We'd need to ask those that implemented: - The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier when implementing ES ECDH with EnvelopedData but is the parameter field populated with a NULL or is it ABSENT (i.e., the originatorKey is a SEQUENCE of one component, the OID id-ecPublicKey). - The signatureAlgorithm algorithm field MUST contain the ecdsa-with-* object identifier when implementing ECDSA with SignedData but is the parameter field populated with a NULL or is it ABSENT (i.e., the signatureAlgorithm is a SEQUENCE of one component, the OID ecdsa-with-*). In the past, we've solve this problem with the weasel wording for hash algorithm parameters, but do we want to continue along this path? Is there a widely deployed base of ES ECDH with EnvelopedData and did anybody do something different than what RFC5008 says for ECDSA (i.e., absent parameters when you use ecdsa-with-sha*)? spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad >Sent: Thursday, August 14, 2008 9:01 AM >To: Sean P. Turner >Cc: Ietf-Smime >Subject: Comments on draft-ietf-smime-3278bis-01.txt > > >Section 1.2 > - bullet #1 - should be SHA-1 not SHA > - bullet #3 - change 'e' to 'a' > - be consistent on use of SHA-1 vs SHA1 I fixed these and found some other instances of SHA1 that should have been SHA-1. >Section 2.3.2 -- "SignerInfosignature" --> SignerInfo.signature Fixed. >Snide remark - Can you use ECDH with CMS EnvelopedData w/o key >agreement? No ;) >Section 3. - Is it permitted to do ECC static-static? I believe it's permitted, but nobody asked for it so the RFC3278 authors didn't include it. Since ES DH was the MUST I assume they went with ES ECDH. Do you want to add it? >Section 3.1.1 - originator - The parameters SHOULD be ABSENT >not NULL. This is 1) consistent with what is done for DH and >2) means that you don't have one more additional encoding >binding for the originator field as oppose to the parameters I think we should be doing what DH does and just have absent parameters. >Section 3.1.1 - please justify the requirement for DER >encoding of ECPoint. I assume there isn't one and this was a cut-and-paste from the other field. We'd just drop the DER part and the sentence would read as follows: "The originatorKey publicKey field MUST contain the value of the ASN.1 type ECPoint (see Section 8.2), which represents the sending agent's ephemeral EC public key." >Section 3.1.1 - what about the ukm field? The "but with the following restrictions:" before the bullets leads me to believe there are no restrictions on the other 3 fields. I assume you're asking for more text and we could add a blurb about ukm being absent. If we add something about ukm we may just add something about the other fields and change the intro sentence. >Section 3.2 - I don't understand why ES ECDH cannot be used >for AuthenticatedData. We can use the DH algorithm with it. >I can understand if you want to state that some ADDITIONAL >security properties exist from using 1-pass ECMQV. I dug through the mail archives and found a thread between Francois Rousseau, Dan Brown, and Simon Blake Wilson in March 2001. Before we add it, I think we'd need to address the points raised. Here's how it went: --- a. Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key agreement algorithm is supported with AuthenticatedData and not also the ECDH key agreement algorithm. Although ECMQV is comparable to KEA, which can also be used with AuthenticatedData, ECDH is the analog to the X9.42 Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the default algorithm with AuthenticatedData. --> We looked at RFC 2630 which specifies the use of ephemeral-static Diffie-Hellman within AuthenticatedData---but we didn't understand how this mechanism provides authentication of the sender since the sender is not certified. We didn't want to include the analogous technique based on these concerns. FR> However, as indicated in Section 4 of your ID, AuthenticatedData lacks non-repudiation, and so in some instances is preferable to SignedData (For example, the sending agent may not want the message to be authenticated when forwarded). Using ephemeral-static ECDH within AuthenticatedData can achieve this goal, but not necessarily ECMQV or static-static ECDH, which both require a certified public key from the sender. As per Section 9 of RFC 2630, the goal of AuthenticatedData is to protect the integrity of the content, but not to necessarily provide authentication of the sender. Note also that RFC 2631 specifies both the ephemeral-static and the static-static Diffie-Hellman modes. --> Of course we could have included static-static ECDH, but this would involve a fixed Diffie-Hellman "shared secret" (Z) between each pair of correspondents, which seems undesirable. FR> True, but I though this was the reason under Section 8.2 of your ID that the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo could optionally be supplied by the sending agent. By mandating the use of the octet string ukm with the static-static ECDH, you would certainly avoid this undesirable effect. Similarly, in Section 2.1.2 of RFC 2631, the partyAInfo MUST be used in Static-Static mode, but MAY appear in Ephemeral-Static mode to avoid this same undesirable effect. --> Make sense? Can anyone explain how ephemeral-static Diffie-Hellman provides security with AuthenticatedData? FR> I do not consider myself an expert with AuthenticatedData, but see my two responses above. --- >Section 3.2.1 - for the bullet ukm - the last sentence makes >no sense--- Part of the problem is that the next paragraph is >not further indented. This was typo. The paragraph after it should have been connected to the ukm paragraph. >Section 3.2.1 - I would recommend for algorithm that absent >rather than NULL be used to simplify encoding/decoding steps See intro. >Section 3.2.2 - what are the domain parameters the same as? The check is that the recipient's domain parameters and the sender's domain parameters are the same. Will add ", as the sender's domain parameters" to the end of that sentence. >Section 3.2.3 - where does the additional ukm come from It >is/is not an ouptut of the key deployment/agreement algorithm? The sentence was missing something from 3278. It should read: "The receiving agent then retrieves the static and ephemeral EC public keys of the originator, from the originator and ukm fields [as described in Section 3.2.1, and its static EC public key identified in the rid] field and checks that the domain parameters are the same." Does this clear things up? >Section 3.2.3 - Are there requirements/recommendations for >validating a sender's certificate? Are there security >implications for not doing so? I think we could add something about validating the certificate prior to use. We've been discussing something similar for the S/MIME v3.2 IDs. I'll add a reference to the security considerations and will grab the text from MSGbis. >Section 5 - The first implementation requirement makes no >sense. Nor does it provide for interop. It makes more sense >to talk about SignedData conformance w/ the spec or Encryption >conformance w/ the spec. I'm happy to recast these. >Section 5 - Why does ECDH care that P-256 curve be used with >SHA-256? What is this paragraph trying to state? It doesn't care. I mistakenly added the ECDH, or ECMQV to the paragraph it should only be about ECDSA. >Section 5 - What is sha1kdf - where is this referenced? Is >the what the previous paragraph is talking about? These are defined later. I'll add a reference to the paragraph. >Section 5 - Are the KDF functions referenced here defined >using an object identifier in the X9.62 specifications? If so >it would be good to include those OIDs in the ASN.1 module. >(No private opinion) Yes they use the OIDs from X9.62 and they are included in the modules. >Section 5 - Need to do some type of reference to where all of >the key wrap and content encryption algorithms are defined. Agreed. >Section 8.1 - Has the following text: > When the object identifier id-ecPublicKey is used here with an > algorithm identifier, the associated parameters contain NULL. > > I thought that there were ec domain parameters that were to >be encoded with the public key. Where else would this be >used? Is this from the OriginatorKey clause above that I >think is incorrect? In this ID it's only used in the OriginatorKey clause. I'd change the following "The following object identifier is used in this document to indicate an elliptic curve public key:" to "The following object identifier is used in this document to indicate an elliptic curve public key in the OriginatorKey field:" and change "When the object identifier id-ecPublicKey is used here with an algorithm identifier, the associated parameters contain NULL" to "When the object identifier id-ecPublicKey is used here with an algorithm identifier, the associated parameters contain are absent." >Section 8.1 - for ecdas-with-*, is it considered acceptable to >have absent parameters? See intro. >Section 8.1 - The parameters for the encryption schemes - > KeyWrap ::= OBJECT IDENTIFIER or > KeyWrap ::= AlgorithmIdentifier > It is not clear from the text at the end of the last >paragraph in this section. Many people use OID and "algorithm >identifier" as the same thing. How about: When the object identifiers are used here within an algorithm identifier, the associated parameters field contains the KeyWrapAlgorithm field, which indicates the key wrap algorithm and any assoicated parameters. >Section 8.2 What happens for keyInfo if the key wrap >algorithm actually has parameters? I think this is wrong. It ought to allow for parameters and absent parameters (i.e., for aes*-wrap). I propose: Old: keyInfo contains the object identifier of the key-encryption algorithm (used to wrap the CEK) and NULL parameters. New: keyInfo contains the object identifier of the key-encryption algorithm (used to wrap the CEK) and associated parameters. In this specification, 3DES wrap has NULL parameters while the AES wraps have absent parameters. >Section 8.2 - suppPubInfo - Since AES128 is the required key >wrap, use that for the example not 3DES Fixed. Still working on these: >Section 3.2.2 - Please elaborate on the re-used statement in >the last paragraph. Can be re-used for what? for how long? >why can't it be re-used for encrypted data? > >Section 3.2.2 - if you re-use the ephemeral - what does/does >not need to be changed? The additional ukm? I'm leaning towards deleting this sentnece and the similar sentences in 4.1.2 and 4.2.2. >Section 4.1.2 - Note: There is a legal attack where by the >recipient modifies the content and goes to court with the >modified content. Unless you bind the output MAC in with the >MAC key, you cannot prevent this type of attack. Not sure what to do with this one. From owner-ietf-smime@mail.imc.org Thu Aug 21 16:47:17 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C96C28C138 for ; Thu, 21 Aug 2008 16:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.156 X-Spam-Level: X-Spam-Status: No, score=-104.156 tagged_above=-999 required=5 tests=[AWL=2.443, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqlYk7eLGvUF for ; Thu, 21 Aug 2008 16:47:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 128C13A6BB5 for ; Thu, 21 Aug 2008 16:46:55 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LNUCNX072038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 16:30:12 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7LNUC2q072037; Thu, 21 Aug 2008 16:30:12 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LNUB12072023 for ; Thu, 21 Aug 2008 16:30:12 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 678B93A6881; Thu, 21 Aug 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-3851bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080821233001.678B93A6881@core3.amsl.com> Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT) 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Author(s) : B. Ramsdell, S. Turner Filename : draft-ietf-smime-3851bis-05.txt Pages : 45 Date : 2008-8-21 This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-3851bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21162252.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Thu Aug 21 16:47:37 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADC13A6809 for ; Thu, 21 Aug 2008 16:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.23 X-Spam-Level: X-Spam-Status: No, score=-104.23 tagged_above=-999 required=5 tests=[AWL=2.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BOsZtBkUEQ7 for ; Thu, 21 Aug 2008 16:47:36 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D39FC3A6916 for ; Thu, 21 Aug 2008 16:47:35 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LNUFx9072049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 16:30:15 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7LNUFrD072048; Thu, 21 Aug 2008 16:30:15 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LNUBDk072024 for ; Thu, 21 Aug 2008 16:30:12 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 61C033A67E6; Thu, 21 Aug 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-3850bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080821233001.61C033A67E6@core3.amsl.com> Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT) 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling Author(s) : S. Turner, B. Ramsdell Filename : draft-ietf-smime-3850bis-05.txt Pages : 20 Date : 2008-8-21 This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-3850bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21162018.I-D@ietf.org> --NextPart-- From owner-ietf-smime@mail.imc.org Thu Aug 21 17:49:44 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E523A6BD5 for ; Thu, 21 Aug 2008 17:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WTvN5I0ow1p for ; Thu, 21 Aug 2008 17:49:44 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 99CC43A6AE5 for ; Thu, 21 Aug 2008 17:49:43 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7M0XW9e080888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 17:33:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7M0XWEW080887; Thu, 21 Aug 2008 17:33:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7M0XVR7080879 for ; Thu, 21 Aug 2008 17:33:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 88502 invoked from network); 22 Aug 2008 00:33:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.106.117 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 22 Aug 2008 00:33:30 -0000 X-YMail-OSG: HWIWHykVM1nPiUzuywQ9F7ouL.klRN3LL2KZCfwS9ynrnownGt1Jxdin9QFG6CBOmPX1OHrbfbC2u2Be3ZcNf.wejvhf0E.NBDEepEBIrGpn6sEkC51eRD8yCx76cDtnb_F0IT37L7GLxn44IomoZ2uM X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: WG Last Call: draft-ietf-smime-rfc3851bis-05.txt Date: Thu, 21 Aug 2008 20:33:22 -0400 Organization: IECA, Inc. Message-ID: <366ED0364D3B4D81A6E2CACD5BBD20B8@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AckD7q68JShAKsgJQk6HjX7tGFCE8A== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates an SMIME Working Group Last Call on the document: Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Author(s) : B. Ramsdell, S. Turner Filename : draft-ietf-smime-3851bis-05.txt Pages : 45 Date : 2008-8-21 This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-05.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Standards Track RFC. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. The Last Call period will end on 8 September 2008. Upon completion of the last call, the WG chairs will take action based upon the consensus of the WG. As the authors are also the WG co-chairs, Russ Housley has offered to make consensus calls and the WG chairs have agreed to abide by Russ's consensus calls. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as an Informational RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! spt From owner-ietf-smime@mail.imc.org Thu Aug 21 17:50:02 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27EEF3A6A06 for ; Thu, 21 Aug 2008 17:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVc1-yOJTiZv for ; Thu, 21 Aug 2008 17:50:01 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9FA8F3A68AF for ; Thu, 21 Aug 2008 17:50:00 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7M0WqXh080797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 17:32:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7M0WqCM080796; Thu, 21 Aug 2008 17:32:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7M0WpoN080787 for ; Thu, 21 Aug 2008 17:32:51 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 49632 invoked from network); 22 Aug 2008 00:32:50 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.106.117 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 22 Aug 2008 00:32:50 -0000 X-YMail-OSG: epkkwXEVM1kVrq_39aiqDhkOGSJUKEkVs.o4Rzkqny0m92PQ_CXShlZtTZKmAOaXnrw1mxS85VBoG2AHJKWVlirpzs2f4s4xh2rFj2009PT5CjOzmIdc5k541l_QnAixZRSM10HlSJLtdeAsLOCKKneX X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt Date: Thu, 21 Aug 2008 20:32:42 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AckD7pcETtBl5IsURlqbtCu/R5JtmA== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates an SMIME Working Group Last Call on the document: Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling Author(s) : S. Turner, B. Ramsdell Filename : draft-ietf-smime-3850bis-05.txt Pages : 20 Date : 2008-8-21 This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-05.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Standards Track RFC. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. The Last Call period will end on 8 September 2008. Upon completion of the last call, the WG chairs will take action based upon the consensus of the WG. As the authors are also the WG co-chairs, Russ Housley has offered to make consensus calls and the WG chairs have agreed to abide by Russ's consensus calls. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as an Informational RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! spt From biconcaa_1987@techdata.com Sat Aug 23 05:58:19 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00DD3A6BD8 for ; Sat, 23 Aug 2008 05:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.22 X-Spam-Level: X-Spam-Status: No, score=-54.22 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF6vGtN1yWz4 for ; Sat, 23 Aug 2008 05:58:18 -0700 (PDT) Received: from 5ac623ba.bb.sky.com (5ac623ba.bb.sky.com [90.198.35.186]) by core3.amsl.com (Postfix) with ESMTP id 1EADE3A6B91 for ; Sat, 23 Aug 2008 05:58:17 -0700 (PDT) Message-ID: <000e01c9051f$ef8e1140$ba23c65a@SN049656920126> From: "tiong Pavlina" To: smime-archive@ietf.org Subject: Paris Hilton, New Advocate for Prisoners Rights? Date: Sat, 23 Aug 2008 13:58:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000A_01C90528.514DBE50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000A_01C90528.514DBE50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PLAY VIDEO CLIP ----------=_NextPart_000_000A_01C90528.514DBE50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
 
PLAY VIDEO=20 CLIP
----------=_NextPart_000_000A_01C90528.514DBE50-- From dgdg-brocardi@techdata.com Sat Aug 23 05:59:05 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A72B3A6BD8 for ; Sat, 23 Aug 2008 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -55.72 X-Spam-Level: X-Spam-Status: No, score=-55.72 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wZszbYQ1t9r for ; Sat, 23 Aug 2008 05:59:04 -0700 (PDT) Received: from 5ac623ba.bb.sky.com (5ac623ba.bb.sky.com [90.198.35.186]) by core3.amsl.com (Postfix) with ESMTP id 56C9A3A6B91 for ; Sat, 23 Aug 2008 05:58:59 -0700 (PDT) Message-ID: <000f01c90520$08305f50$ba23c65a@SN049656920126> From: "dgdg Bako" To: smime-archive@megatron.ietf.org Subject: Paris Hilton Fires Talent Agent! Date: Sat, 23 Aug 2008 13:59:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C90528.69F4C750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000B_01C90528.69F4C750 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PLAY VIDEO CLIP ----------=_NextPart_000_000B_01C90528.69F4C750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
 
PLAY VIDEO=20 CLIP
----------=_NextPart_000_000B_01C90528.69F4C750-- From bonke1955@techdata.com Sat Aug 23 06:03:56 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48933A6BF6 for ; Sat, 23 Aug 2008 06:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.22 X-Spam-Level: X-Spam-Status: No, score=-54.22 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dr8F1Vb-+Aik for ; Sat, 23 Aug 2008 06:03:56 -0700 (PDT) Received: from 5ac623ba.bb.sky.com (5ac623ba.bb.sky.com [90.198.35.186]) by core3.amsl.com (Postfix) with ESMTP id 73F893A6B91 for ; Sat, 23 Aug 2008 06:03:55 -0700 (PDT) Message-ID: <000601c90520$b8a7d930$ba23c65a@SN049656920126> From: "Huai Slattery" To: smime-archive@lists.ietf.org Subject: George W.Bush caught naked with Paris Hilton and smoking marijuana Date: Sat, 23 Aug 2008 14:04:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0002_01C90529.1A6C4130" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_0002_01C90529.1A6C4130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PLAY VIDEO CLIP ----------=_NextPart_000_0002_01C90529.1A6C4130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
 
PLAY VIDEO=20 CLIP
----------=_NextPart_000_0002_01C90529.1A6C4130-- From owner-ietf-smime@mail.imc.org Mon Aug 25 10:50:54 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF61B28C88A for ; Mon, 25 Aug 2008 10:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.206 X-Spam-Level: X-Spam-Status: No, score=-100.206 tagged_above=-999 required=5 tests=[AWL=-1.854, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geahbpP4BGME for ; Mon, 25 Aug 2008 10:50:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9FE1B3A6A4F for ; Mon, 25 Aug 2008 10:50:51 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7PHYF3O059218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 10:34:15 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7PHYFOT059217; Mon, 25 Aug 2008 10:34:15 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7PHYESn059210 for ; Mon, 25 Aug 2008 10:34:14 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6d48b30874; Tue, 26 Aug 2008 01:49:50 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm21a48ae7ad1; Fri, 22 Aug 2008 07:49:13 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 22 Aug 2008 07:49:13 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F023A6B8F; Thu, 21 Aug 2008 16:30:53 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 678B93A6881; Thu, 21 Aug 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-smime-3851bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080821233001.678B93A6881@core3.amsl.com> Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT) Cc: ietf-smime@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Author(s) : B. Ramsdell, S. Turner Filename : draft-ietf-smime-3851bis-05.txt Pages : 45 Date : 2008-8-21 This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-3851bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21162252.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From owner-ietf-smime@mail.imc.org Mon Aug 25 10:55:17 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CD928C9E9 for ; Mon, 25 Aug 2008 10:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.196 X-Spam-Level: X-Spam-Status: No, score=-100.196 tagged_above=-999 required=5 tests=[AWL=-1.844, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hikNYzu5EXaR for ; Mon, 25 Aug 2008 10:55:16 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EEEE028C9E7 for ; Mon, 25 Aug 2008 10:55:15 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7PHWNAV059104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 10:32:23 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7PHWNIN059103; Mon, 25 Aug 2008 10:32:23 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7PHWLs6059096 for ; Mon, 25 Aug 2008 10:32:22 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([192.168.12.36]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm448b2fee1; Tue, 26 Aug 2008 01:47:57 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm048ae715a; Fri, 22 Aug 2008 07:47:22 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 22 Aug 2008 07:47:22 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A223A6B95; Thu, 21 Aug 2008 16:30:53 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 61C033A67E6; Thu, 21 Aug 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-smime-3850bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080821233001.61C033A67E6@core3.amsl.com> Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT) Cc: ietf-smime@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling Author(s) : S. Turner, B. Ramsdell Filename : draft-ietf-smime-3850bis-05.txt Pages : 20 Date : 2008-8-21 This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-3850bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21162018.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- From owner-ietf-smime@mail.imc.org Tue Aug 26 12:21:13 2008 Return-Path: X-Original-To: ietfarch-smime-archive@core3.amsl.com Delivered-To: ietfarch-smime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253E53A6834 for ; Tue, 26 Aug 2008 12:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3xgOVbPJPZs for ; Tue, 26 Aug 2008 12:21:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EBA513A6BF6 for ; Tue, 26 Aug 2008 12:21:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QJ7OVQ002167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 12:07:25 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7QJ7OhJ002166; Tue, 26 Aug 2008 12:07:24 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QJ7NrE002156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Aug 2008 12:07:24 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [70.158.103.10]) by smtp4.pacifier.net (Postfix) with ESMTP id 1750C6A845; Tue, 26 Aug 2008 12:07:16 -0700 (PDT) From: "Jim Schaad" To: "'Turner, Sean P.'" , References: <20080701171501.6A9693A6BA1@core3.amsl.com> <015701c8fe0d$cc774e60$6565eb20$@com> <6EE7BCFB5E74478680644C8FFB57E98A@Wylie> In-Reply-To: <6EE7BCFB5E74478680644C8FFB57E98A@Wylie> Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt Date: Tue, 26 Aug 2008 15:07:20 -0400 Message-ID: <051901c907ae$fa653350$ef2f99f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjbnio8tmTGHYIBQ+erKGEHdRVzVQhnqn6gAQ4KOAABjdiZgA== Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean, I have removed items that I considered to be completed Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Turner, Sean P. > Sent: Thursday, August 21, 2008 6:10 PM > To: 'Jim Schaad'; ietf-smime@imc.org > Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt > > > Jim, > > Responses inline... Still working on 3 of the comments, which have been > moved to the bottom of the email. > > All, > > Jim's raised some concerns about the parameters fields and whether they > should be NULL or ABSENT. Additionally, this draft doesn't discuss > hash > algorithm's parameter fields. We've got two options: > > 1) We leave the text as is and include some wording similar to what we > say > about hash algorithm parameters (must support both NULL and absent > parameters and SHOULD generate absent). Note we need to add this text > regardless for the hash algorithm parameters because right now the ID > says > nothing about them. > The major problem I have this text as it stands, is that the associated of OID and ASN.1 type becomes different for when it appears in an originator key vs when it appears in a public key (i.e. certificate). In theory, there should actually not be a problem with having the full domain parameters appear in the originator key field, although the reciver should check that the parameters match those used for their key. > 2) We poll implementers. We'd need to ask those that implemented: > > - The originatorKey algorithm field MUST contain the id-ecPublicKey > object > identifier when implementing ES ECDH with EnvelopedData but is the > parameter > field populated with a NULL or is it ABSENT (i.e., the originatorKey is > a > SEQUENCE of one component, the OID id-ecPublicKey). > > - The signatureAlgorithm algorithm field MUST contain the ecdsa-with-* > object identifier when implementing ECDSA with SignedData but is the > parameter field populated with a NULL or is it ABSENT (i.e., the > signatureAlgorithm is a SEQUENCE of one component, the OID ecdsa-with- > *). > > In the past, we've solve this problem with the weasel wording for hash > algorithm parameters, but do we want to continue along this path? Is > there a > widely deployed base of ES ECDH with EnvelopedData and did anybody do > something different than what RFC5008 says for ECDSA (i.e., absent > parameters when you use ecdsa-with-sha*)? > > spt > > >-----Original Message----- > >From: owner-ietf-smime@mail.imc.org > >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad > >Sent: Thursday, August 14, 2008 9:01 AM > >To: Sean P. Turner > >Cc: Ietf-Smime > >Subject: Comments on draft-ietf-smime-3278bis-01.txt > > > > > >Section 3. - Is it permitted to do ECC static-static? > > I believe it's permitted, but nobody asked for it so the RFC3278 > authors > didn't include it. Since ES DH was the MUST I assume they went with ES > ECDH. Do you want to add it? We did allow for static-static DH, analogy says we might want to include it. The question would be 1) would it be used (probably not) and 2) is there a community that might thing you should validate the senders certificate prior to decrypting a message (there were such communities, I think they have been sufficiently discouraged from the practice). I think a simple sentence -- Static-Static is not covered in this document, the MQV method provides for better security, if you want to use ECSS - it is analogous. (clean up the language). > > >Section 3.1.1 - originator - The parameters SHOULD be ABSENT > >not NULL. This is 1) consistent with what is done for DH and > >2) means that you don't have one more additional encoding > >binding for the originator field as oppose to the parameters > > I think we should be doing what DH does and just have absent > parameters. Issue open > > >Section 3.1.1 - please justify the requirement for DER > >encoding of ECPoint. > > I assume there isn't one and this was a cut-and-paste from the other > field. > We'd just drop the DER part and the sentence would read as follows: > "The > originatorKey publicKey field MUST contain the value of the ASN.1 type > ECPoint (see Section 8.2), which represents the sending agent's > ephemeral EC > public key." ???? > > >Section 3.1.1 - what about the ukm field? > > The "but with the following restrictions:" before the bullets leads me > to > believe there are no restrictions on the other 3 fields. I assume > you're > asking for more text and we could add a blurb about ukm being absent. > If we > add something about ukm we may just add something about the other > fields and > change the intro sentence. Text needs to be included as to what goes into the UKM field - specifically it also needs to say where and how to use the ukm material in the (I assume) ECC-CMS-SharedInfo structure to be used during key derivation. > > >Section 3.2 - I don't understand why ES ECDH cannot be used > >for AuthenticatedData. We can use the DH algorithm with it. > >I can understand if you want to state that some ADDITIONAL > >security properties exist from using 1-pass ECMQV. > > I dug through the mail archives and found a thread between Francois > Rousseau, Dan Brown, and Simon Blake Wilson in March 2001. Before we > add > it, I think we'd need to address the points raised. Here's how it > went: > --- > a. Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key > agreement algorithm is supported with AuthenticatedData and not also > the > ECDH key agreement algorithm. Although ECMQV is comparable to KEA, > which can > also be used with AuthenticatedData, ECDH is the analog to the X9.42 > Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the > default algorithm with AuthenticatedData. > > --> We looked at RFC 2630 which specifies the use of ephemeral-static > Diffie-Hellman within AuthenticatedData---but we didn't understand how > this > mechanism provides authentication of the sender since the sender is not > certified. We didn't want to include the analogous technique based on > these > concerns. This is the key issue - Authenticated data DOES NOT provide data origination assurance. All it says is that the data was not modified during "transit". It does not say that the data is the same as the original sender. > > FR> However, as indicated in Section 4 of your ID, AuthenticatedData > lacks > non-repudiation, and so in some instances is preferable to SignedData > (For > example, the sending agent may not want the message to be authenticated > when > forwarded). Using ephemeral-static ECDH within AuthenticatedData can > achieve > this goal, but not necessarily ECMQV or static-static ECDH, which both > require a certified public key from the sender. As per Section 9 of RFC > 2630, the goal of AuthenticatedData is to protect the integrity of the > content, but not to necessarily provide authentication of the sender. > Note > also that RFC 2631 specifies both the ephemeral-static and the static- > static > Diffie-Hellman modes. > > --> Of course we could have included static-static ECDH, but this would > involve a fixed Diffie-Hellman "shared secret" (Z) between each pair of > correspondents, which seems undesirable. > > FR> True, but I though this was the reason under Section 8.2 of your ID > that > the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo > could optionally be supplied by the sending agent. By mandating the use > of > the octet string ukm with the static-static ECDH, you would certainly > avoid > this undesirable effect. Similarly, in Section 2.1.2 of RFC 2631, the > partyAInfo MUST be used in Static-Static mode, but MAY appear in > Ephemeral-Static mode to avoid this same undesirable effect. > > --> Make sense? Can anyone explain how ephemeral-static Diffie-Hellman > provides security with AuthenticatedData? > > FR> I do not consider myself an expert with AuthenticatedData, but see > my > two responses above. > --- > >Section 3.2.1 - for the bullet ukm - the last sentence makes > >no sense--- Part of the problem is that the next paragraph is > >not further indented. > > This was typo. The paragraph after it should have been connected to the > ukm > paragraph. > > >Section 3.2.1 - I would recommend for algorithm that absent > >rather than NULL be used to simplify encoding/decoding steps > > See intro. > > >Section 3.2.2 - what are the domain parameters the same as? > > The check is that the recipient's domain parameters and the sender's > domain > parameters are the same. Will add ", as the sender's domain parameters" > to > the end of that sentence. > > >Section 3.2.3 - where does the additional ukm come from It > >is/is not an ouptut of the key deployment/agreement algorithm? > > The sentence was missing something from 3278. It should read: "The > receiving > agent then retrieves the static and ephemeral EC public keys of the > originator, from the originator and ukm fields [as described in Section > 3.2.1, and its static EC public key identified in the rid] field and > checks > that the domain parameters are the same." Does this clear things up? > > >Section 3.2.3 - Are there requirements/recommendations for > >validating a sender's certificate? Are there security > >implications for not doing so? > > I think we could add something about validating the certificate prior > to > use. We've been discussing something similar for the S/MIME v3.2 IDs. > I'll > add a reference to the security considerations and will grab the text > from > MSGbis. > This is a problem of what AuthenticatedData provides vs what they think it provides - see above comment. > >Section 5 - Are the KDF functions referenced here defined > >using an object identifier in the X9.62 specifications? If so > >it would be good to include those OIDs in the ASN.1 module. > >(No private opinion) > > Yes they use the OIDs from X9.62 and they are included in the modules. I don't see any identifier for sha1kdf (or what I would consider and equivalent). There are ones for the entire scheme, but not for this piece of the scheme. > > >Section 8.1 - Has the following text: > > When the object identifier id-ecPublicKey is used here with an > > algorithm identifier, the associated parameters contain NULL. > > > > I thought that there were ec domain parameters that were to > >be encoded with the public key. Where else would this be > >used? Is this from the OriginatorKey clause above that I > >think is incorrect? > > In this ID it's only used in the OriginatorKey clause. I'd change the > following "The following object identifier is used in this document to > indicate an elliptic curve public key:" to "The following object > identifier > is used in this document to indicate an elliptic curve public key in > the > OriginatorKey field:" and change "When the object identifier id- > ecPublicKey > is used here with an algorithm identifier, the associated parameters > contain > NULL" to "When the object identifier id-ecPublicKey is used here with > an > algorithm identifier, the associated parameters contain are absent." Result may be modified by discussion from top of mail message > > >Section 8.1 - for ecdas-with-*, is it considered acceptable to > >have absent parameters? > > See intro. > Open > >Section 8.1 - The parameters for the encryption schemes - > > KeyWrap ::= OBJECT IDENTIFIER or > > KeyWrap ::= AlgorithmIdentifier > > It is not clear from the text at the end of the last > >paragraph in this section. Many people use OID and "algorithm > >identifier" as the same thing. > > How about: When the object identifiers are used here within an > algorithm > identifier, the associated parameters field contains the > KeyWrapAlgorithm > field, which indicates the key wrap algorithm and any assoicated > parameters. Combined with a clarification in the ASN.1 - this should be fine > > >Section 8.2 What happens for keyInfo if the key wrap > >algorithm actually has parameters? > > I think this is wrong. It ought to allow for parameters and absent > parameters (i.e., for aes*-wrap). I propose: > Old: keyInfo contains the object identifier of the key-encryption > algorithm > (used to wrap the CEK) and NULL parameters. > New: keyInfo contains the object identifier of the key-encryption > algorithm > (used to wrap the CEK) and associated parameters. In this > specification, > 3DES wrap has NULL parameters while the AES wraps have absent > parameters. Fine > > > Still working on these: > > >Section 3.2.2 - Please elaborate on the re-used statement in > >the last paragraph. Can be re-used for what? for how long? > >why can't it be re-used for encrypted data? > > > >Section 3.2.2 - if you re-use the ephemeral - what does/does > >not need to be changed? The additional ukm? > > I'm leaning towards deleting this sentnece and the similar sentences in > 4.1.2 and 4.2.2. > > >Section 4.1.2 - Note: There is a legal attack where by the > >recipient modifies the content and goes to court with the > >modified content. Unless you bind the output MAC in with the > >MAC key, you cannot prevent this type of attack. > > Not sure what to do with this one. This is part and parcel of the question of what AuthenticatedData does or does not provide as a security service. Fix that concept and this goes away. Jim Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QJ7OVQ002167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2008 12:07:25 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7QJ7OhJ002166; Tue, 26 Aug 2008 12:07:24 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7QJ7NrE002156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 26 Aug 2008 12:07:24 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from GALATIONS (unknown [70.158.103.10]) by smtp4.pacifier.net (Postfix) with ESMTP id 1750C6A845; Tue, 26 Aug 2008 12:07:16 -0700 (PDT) From: "Jim Schaad" To: "'Turner, Sean P.'" , References: <20080701171501.6A9693A6BA1@core3.amsl.com> <015701c8fe0d$cc774e60$6565eb20$@com> <6EE7BCFB5E74478680644C8FFB57E98A@Wylie> In-Reply-To: <6EE7BCFB5E74478680644C8FFB57E98A@Wylie> Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt Date: Tue, 26 Aug 2008 15:07:20 -0400 Message-ID: <051901c907ae$fa653350$ef2f99f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjbnio8tmTGHYIBQ+erKGEHdRVzVQhnqn6gAQ4KOAABjdiZgA== Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean, I have removed items that I considered to be completed Jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- > smime@mail.imc.org] On Behalf Of Turner, Sean P. > Sent: Thursday, August 21, 2008 6:10 PM > To: 'Jim Schaad'; ietf-smime@imc.org > Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt > > > Jim, > > Responses inline... Still working on 3 of the comments, which have been > moved to the bottom of the email. > > All, > > Jim's raised some concerns about the parameters fields and whether they > should be NULL or ABSENT. Additionally, this draft doesn't discuss > hash > algorithm's parameter fields. We've got two options: > > 1) We leave the text as is and include some wording similar to what we > say > about hash algorithm parameters (must support both NULL and absent > parameters and SHOULD generate absent). Note we need to add this text > regardless for the hash algorithm parameters because right now the ID > says > nothing about them. > The major problem I have this text as it stands, is that the associated of OID and ASN.1 type becomes different for when it appears in an originator key vs when it appears in a public key (i.e. certificate). In theory, there should actually not be a problem with having the full domain parameters appear in the originator key field, although the reciver should check that the parameters match those used for their key. > 2) We poll implementers. We'd need to ask those that implemented: > > - The originatorKey algorithm field MUST contain the id-ecPublicKey > object > identifier when implementing ES ECDH with EnvelopedData but is the > parameter > field populated with a NULL or is it ABSENT (i.e., the originatorKey is > a > SEQUENCE of one component, the OID id-ecPublicKey). > > - The signatureAlgorithm algorithm field MUST contain the ecdsa-with-* > object identifier when implementing ECDSA with SignedData but is the > parameter field populated with a NULL or is it ABSENT (i.e., the > signatureAlgorithm is a SEQUENCE of one component, the OID ecdsa-with- > *). > > In the past, we've solve this problem with the weasel wording for hash > algorithm parameters, but do we want to continue along this path? Is > there a > widely deployed base of ES ECDH with EnvelopedData and did anybody do > something different than what RFC5008 says for ECDSA (i.e., absent > parameters when you use ecdsa-with-sha*)? > > spt > > >-----Original Message----- > >From: owner-ietf-smime@mail.imc.org > >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad > >Sent: Thursday, August 14, 2008 9:01 AM > >To: Sean P. Turner > >Cc: Ietf-Smime > >Subject: Comments on draft-ietf-smime-3278bis-01.txt > > > > > >Section 3. - Is it permitted to do ECC static-static? > > I believe it's permitted, but nobody asked for it so the RFC3278 > authors > didn't include it. Since ES DH was the MUST I assume they went with ES > ECDH. Do you want to add it? We did allow for static-static DH, analogy says we might want to include it. The question would be 1) would it be used (probably not) and 2) is there a community that might thing you should validate the senders certificate prior to decrypting a message (there were such communities, I think they have been sufficiently discouraged from the practice). I think a simple sentence -- Static-Static is not covered in this document, the MQV method provides for better security, if you want to use ECSS - it is analogous. (clean up the language). > > >Section 3.1.1 - originator - The parameters SHOULD be ABSENT > >not NULL. This is 1) consistent with what is done for DH and > >2) means that you don't have one more additional encoding > >binding for the originator field as oppose to the parameters > > I think we should be doing what DH does and just have absent > parameters. Issue open > > >Section 3.1.1 - please justify the requirement for DER > >encoding of ECPoint. > > I assume there isn't one and this was a cut-and-paste from the other > field. > We'd just drop the DER part and the sentence would read as follows: > "The > originatorKey publicKey field MUST contain the value of the ASN.1 type > ECPoint (see Section 8.2), which represents the sending agent's > ephemeral EC > public key." ???? > > >Section 3.1.1 - what about the ukm field? > > The "but with the following restrictions:" before the bullets leads me > to > believe there are no restrictions on the other 3 fields. I assume > you're > asking for more text and we could add a blurb about ukm being absent. > If we > add something about ukm we may just add something about the other > fields and > change the intro sentence. Text needs to be included as to what goes into the UKM field - specifically it also needs to say where and how to use the ukm material in the (I assume) ECC-CMS-SharedInfo structure to be used during key derivation. > > >Section 3.2 - I don't understand why ES ECDH cannot be used > >for AuthenticatedData. We can use the DH algorithm with it. > >I can understand if you want to state that some ADDITIONAL > >security properties exist from using 1-pass ECMQV. > > I dug through the mail archives and found a thread between Francois > Rousseau, Dan Brown, and Simon Blake Wilson in March 2001. Before we > add > it, I think we'd need to address the points raised. Here's how it > went: > --- > a. Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key > agreement algorithm is supported with AuthenticatedData and not also > the > ECDH key agreement algorithm. Although ECMQV is comparable to KEA, > which can > also be used with AuthenticatedData, ECDH is the analog to the X9.42 > Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the > default algorithm with AuthenticatedData. > > --> We looked at RFC 2630 which specifies the use of ephemeral-static > Diffie-Hellman within AuthenticatedData---but we didn't understand how > this > mechanism provides authentication of the sender since the sender is not > certified. We didn't want to include the analogous technique based on > these > concerns. This is the key issue - Authenticated data DOES NOT provide data origination assurance. All it says is that the data was not modified during "transit". It does not say that the data is the same as the original sender. > > FR> However, as indicated in Section 4 of your ID, AuthenticatedData > lacks > non-repudiation, and so in some instances is preferable to SignedData > (For > example, the sending agent may not want the message to be authenticated > when > forwarded). Using ephemeral-static ECDH within AuthenticatedData can > achieve > this goal, but not necessarily ECMQV or static-static ECDH, which both > require a certified public key from the sender. As per Section 9 of RFC > 2630, the goal of AuthenticatedData is to protect the integrity of the > content, but not to necessarily provide authentication of the sender. > Note > also that RFC 2631 specifies both the ephemeral-static and the static- > static > Diffie-Hellman modes. > > --> Of course we could have included static-static ECDH, but this would > involve a fixed Diffie-Hellman "shared secret" (Z) between each pair of > correspondents, which seems undesirable. > > FR> True, but I though this was the reason under Section 8.2 of your ID > that > the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo > could optionally be supplied by the sending agent. By mandating the use > of > the octet string ukm with the static-static ECDH, you would certainly > avoid > this undesirable effect. Similarly, in Section 2.1.2 of RFC 2631, the > partyAInfo MUST be used in Static-Static mode, but MAY appear in > Ephemeral-Static mode to avoid this same undesirable effect. > > --> Make sense? Can anyone explain how ephemeral-static Diffie-Hellman > provides security with AuthenticatedData? > > FR> I do not consider myself an expert with AuthenticatedData, but see > my > two responses above. > --- > >Section 3.2.1 - for the bullet ukm - the last sentence makes > >no sense--- Part of the problem is that the next paragraph is > >not further indented. > > This was typo. The paragraph after it should have been connected to the > ukm > paragraph. > > >Section 3.2.1 - I would recommend for algorithm that absent > >rather than NULL be used to simplify encoding/decoding steps > > See intro. > > >Section 3.2.2 - what are the domain parameters the same as? > > The check is that the recipient's domain parameters and the sender's > domain > parameters are the same. Will add ", as the sender's domain parameters" > to > the end of that sentence. > > >Section 3.2.3 - where does the additional ukm come from It > >is/is not an ouptut of the key deployment/agreement algorithm? > > The sentence was missing something from 3278. It should read: "The > receiving > agent then retrieves the static and ephemeral EC public keys of the > originator, from the originator and ukm fields [as described in Section > 3.2.1, and its static EC public key identified in the rid] field and > checks > that the domain parameters are the same." Does this clear things up? > > >Section 3.2.3 - Are there requirements/recommendations for > >validating a sender's certificate? Are there security > >implications for not doing so? > > I think we could add something about validating the certificate prior > to > use. We've been discussing something similar for the S/MIME v3.2 IDs. > I'll > add a reference to the security considerations and will grab the text > from > MSGbis. > This is a problem of what AuthenticatedData provides vs what they think it provides - see above comment. > >Section 5 - Are the KDF functions referenced here defined > >using an object identifier in the X9.62 specifications? If so > >it would be good to include those OIDs in the ASN.1 module. > >(No private opinion) > > Yes they use the OIDs from X9.62 and they are included in the modules. I don't see any identifier for sha1kdf (or what I would consider and equivalent). There are ones for the entire scheme, but not for this piece of the scheme. > > >Section 8.1 - Has the following text: > > When the object identifier id-ecPublicKey is used here with an > > algorithm identifier, the associated parameters contain NULL. > > > > I thought that there were ec domain parameters that were to > >be encoded with the public key. Where else would this be > >used? Is this from the OriginatorKey clause above that I > >think is incorrect? > > In this ID it's only used in the OriginatorKey clause. I'd change the > following "The following object identifier is used in this document to > indicate an elliptic curve public key:" to "The following object > identifier > is used in this document to indicate an elliptic curve public key in > the > OriginatorKey field:" and change "When the object identifier id- > ecPublicKey > is used here with an algorithm identifier, the associated parameters > contain > NULL" to "When the object identifier id-ecPublicKey is used here with > an > algorithm identifier, the associated parameters contain are absent." Result may be modified by discussion from top of mail message > > >Section 8.1 - for ecdas-with-*, is it considered acceptable to > >have absent parameters? > > See intro. > Open > >Section 8.1 - The parameters for the encryption schemes - > > KeyWrap ::= OBJECT IDENTIFIER or > > KeyWrap ::= AlgorithmIdentifier > > It is not clear from the text at the end of the last > >paragraph in this section. Many people use OID and "algorithm > >identifier" as the same thing. > > How about: When the object identifiers are used here within an > algorithm > identifier, the associated parameters field contains the > KeyWrapAlgorithm > field, which indicates the key wrap algorithm and any assoicated > parameters. Combined with a clarification in the ASN.1 - this should be fine > > >Section 8.2 What happens for keyInfo if the key wrap > >algorithm actually has parameters? > > I think this is wrong. It ought to allow for parameters and absent > parameters (i.e., for aes*-wrap). I propose: > Old: keyInfo contains the object identifier of the key-encryption > algorithm > (used to wrap the CEK) and NULL parameters. > New: keyInfo contains the object identifier of the key-encryption > algorithm > (used to wrap the CEK) and associated parameters. In this > specification, > 3DES wrap has NULL parameters while the AES wraps have absent > parameters. Fine > > > Still working on these: > > >Section 3.2.2 - Please elaborate on the re-used statement in > >the last paragraph. Can be re-used for what? for how long? > >why can't it be re-used for encrypted data? > > > >Section 3.2.2 - if you re-use the ephemeral - what does/does > >not need to be changed? The additional ukm? > > I'm leaning towards deleting this sentnece and the similar sentences in > 4.1.2 and 4.2.2. > > >Section 4.1.2 - Note: There is a legal attack where by the > >recipient modifies the content and goes to court with the > >modified content. Unless you bind the output MAC in with the > >MAC key, you cannot prevent this type of attack. > > Not sure what to do with this one. This is part and parcel of the question of what AuthenticatedData does or does not provide as a security service. Fix that concept and this goes away. Jim Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7PHYF3O059218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 10:34:15 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7PHYFOT059217; Mon, 25 Aug 2008 10:34:15 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7PHYESn059210 for ; Mon, 25 Aug 2008 10:34:14 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm6d48b30874; Tue, 26 Aug 2008 01:49:50 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm21a48ae7ad1; Fri, 22 Aug 2008 07:49:13 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 22 Aug 2008 07:49:13 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F023A6B8F; Thu, 21 Aug 2008 16:30:53 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 678B93A6881; Thu, 21 Aug 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-smime-3851bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080821233001.678B93A6881@core3.amsl.com> Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT) Cc: ietf-smime@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Author(s) : B. Ramsdell, S. Turner Filename : draft-ietf-smime-3851bis-05.txt Pages : 45 Date : 2008-8-21 This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-3851bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21162252.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7PHWNAV059104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 10:32:23 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7PHWNIN059103; Mon, 25 Aug 2008 10:32:23 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7PHWLs6059096 for ; Mon, 25 Aug 2008 10:32:22 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([192.168.12.36]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm448b2fee1; Tue, 26 Aug 2008 01:47:57 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm048ae715a; Fri, 22 Aug 2008 07:47:22 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 22 Aug 2008 07:47:22 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A223A6B95; Thu, 21 Aug 2008 16:30:53 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 61C033A67E6; Thu, 21 Aug 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-smime-3850bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080821233001.61C033A67E6@core3.amsl.com> Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT) Cc: ietf-smime@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling Author(s) : S. Turner, B. Ramsdell Filename : draft-ietf-smime-3850bis-05.txt Pages : 20 Date : 2008-8-21 This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-3850bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21162018.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7M0XW9e080888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 17:33:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7M0XWEW080887; Thu, 21 Aug 2008 17:33:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7M0XVR7080879 for ; Thu, 21 Aug 2008 17:33:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 88502 invoked from network); 22 Aug 2008 00:33:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.106.117 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 22 Aug 2008 00:33:30 -0000 X-YMail-OSG: HWIWHykVM1nPiUzuywQ9F7ouL.klRN3LL2KZCfwS9ynrnownGt1Jxdin9QFG6CBOmPX1OHrbfbC2u2Be3ZcNf.wejvhf0E.NBDEepEBIrGpn6sEkC51eRD8yCx76cDtnb_F0IT37L7GLxn44IomoZ2uM X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: WG Last Call: draft-ietf-smime-rfc3851bis-05.txt Date: Thu, 21 Aug 2008 20:33:22 -0400 Organization: IECA, Inc. Message-ID: <366ED0364D3B4D81A6E2CACD5BBD20B8@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AckD7q68JShAKsgJQk6HjX7tGFCE8A== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates an SMIME Working Group Last Call on the document: Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Author(s) : B. Ramsdell, S. Turner Filename : draft-ietf-smime-3851bis-05.txt Pages : 45 Date : 2008-8-21 This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-05.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Standards Track RFC. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. The Last Call period will end on 8 September 2008. Upon completion of the last call, the WG chairs will take action based upon the consensus of the WG. As the authors are also the WG co-chairs, Russ Housley has offered to make consensus calls and the WG chairs have agreed to abide by Russ's consensus calls. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as an Informational RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7M0WqXh080797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 17:32:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7M0WqCM080796; Thu, 21 Aug 2008 17:32:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7M0WpoN080787 for ; Thu, 21 Aug 2008 17:32:51 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 49632 invoked from network); 22 Aug 2008 00:32:50 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.106.117 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 22 Aug 2008 00:32:50 -0000 X-YMail-OSG: epkkwXEVM1kVrq_39aiqDhkOGSJUKEkVs.o4Rzkqny0m92PQ_CXShlZtTZKmAOaXnrw1mxS85VBoG2AHJKWVlirpzs2f4s4xh2rFj2009PT5CjOzmIdc5k541l_QnAixZRSM10HlSJLtdeAsLOCKKneX X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: Subject: WG Last Call: draft-ietf-smime-rfc3850bis-05.txt Date: Thu, 21 Aug 2008 20:32:42 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AckD7pcETtBl5IsURlqbtCu/R5JtmA== Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates an SMIME Working Group Last Call on the document: Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling Author(s) : S. Turner, B. Ramsdell Filename : draft-ietf-smime-3850bis-05.txt Pages : 20 Date : 2008-8-21 This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-05.txt The purpose of this WG Last Call is to ensure that the Working Group has achieved consensus that the document is suitable for publication as a Standards Track RFC. Please review the document for both technical and editorial problems. Technical issues should be discussed on this list. Editorial issues may be sent to the document editor. The Last Call period will end on 8 September 2008. Upon completion of the last call, the WG chairs will take action based upon the consensus of the WG. As the authors are also the WG co-chairs, Russ Housley has offered to make consensus calls and the WG chairs have agreed to abide by Russ's consensus calls. Possible actions include: 1) recommending to the IETF Security Area Directors that the document, after possible editorial or other minor changes, be considered by the IESG for publication as an Informational RFC (which generally involves an IETF-wide Last Call); or 2) requiring that outstanding issues be adequately addressed prior to further action (including, possibly, another WG Last Call). Remember that it is our responsibility as Working Group members to ensure the quality of our documents and of the Internet Standards process. So, please read and comment! spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LNUFx9072049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 16:30:15 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7LNUFrD072048; Thu, 21 Aug 2008 16:30:15 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LNUBDk072024 for ; Thu, 21 Aug 2008 16:30:12 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 61C033A67E6; Thu, 21 Aug 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-3850bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080821233001.61C033A67E6@core3.amsl.com> Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT) 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling Author(s) : S. Turner, B. Ramsdell Filename : draft-ietf-smime-3850bis-05.txt Pages : 20 Date : 2008-8-21 This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-3850bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21162018.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LNUCNX072038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 16:30:12 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7LNUC2q072037; Thu, 21 Aug 2008 16:30:12 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LNUB12072023 for ; Thu, 21 Aug 2008 16:30:12 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 678B93A6881; Thu, 21 Aug 2008 16:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-3851bis-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080821233001.678B93A6881@core3.amsl.com> Date: Thu, 21 Aug 2008 16:30:01 -0700 (PDT) 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 : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Author(s) : B. Ramsdell, S. Turner Filename : draft-ietf-smime-3851bis-05.txt Pages : 45 Date : 2008-8-21 This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-3851bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-21162252.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7LM9nBs061994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Aug 2008 15:09:49 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7LM9nAu061993; Thu, 21 Aug 2008 15:09:49 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7LM9lVl061986 for ; Thu, 21 Aug 2008 15:09:48 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 40331 invoked from network); 21 Aug 2008 22:09:47 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.106.117 with login) by smtp108.biz.mail.re2.yahoo.com with SMTP; 21 Aug 2008 22:09:46 -0000 X-YMail-OSG: Z25WqD0VM1kJDPiRlCs2SGoDIgCfhilrHWviCUEZ2I2ubrdAelxqQABmpwPxrEruq0zzqz2_NzSQgr0788mfi46VV2DHP8o0Il0HUXQTUWp4enyjQmX9cKQMJhuXwEQ- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Jim Schaad'" , References: <20080701171501.6A9693A6BA1@core3.amsl.com> <015701c8fe0d$cc774e60$6565eb20$@com> Subject: RE: Comments on draft-ietf-smime-3278bis-01.txt Date: Thu, 21 Aug 2008 18:09:40 -0400 Organization: IECA, Inc. Message-ID: <6EE7BCFB5E74478680644C8FFB57E98A@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <015701c8fe0d$cc774e60$6565eb20$@com> Thread-Index: Acjbnio8tmTGHYIBQ+erKGEHdRVzVQhnqn6gAQ4KOAA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, Responses inline... Still working on 3 of the comments, which have been moved to the bottom of the email. All, Jim's raised some concerns about the parameters fields and whether they should be NULL or ABSENT. Additionally, this draft doesn't discuss hash algorithm's parameter fields. We've got two options: 1) We leave the text as is and include some wording similar to what we say about hash algorithm parameters (must support both NULL and absent parameters and SHOULD generate absent). Note we need to add this text regardless for the hash algorithm parameters because right now the ID says nothing about them. 2) We poll implementers. We'd need to ask those that implemented: - The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier when implementing ES ECDH with EnvelopedData but is the parameter field populated with a NULL or is it ABSENT (i.e., the originatorKey is a SEQUENCE of one component, the OID id-ecPublicKey). - The signatureAlgorithm algorithm field MUST contain the ecdsa-with-* object identifier when implementing ECDSA with SignedData but is the parameter field populated with a NULL or is it ABSENT (i.e., the signatureAlgorithm is a SEQUENCE of one component, the OID ecdsa-with-*). In the past, we've solve this problem with the weasel wording for hash algorithm parameters, but do we want to continue along this path? Is there a widely deployed base of ES ECDH with EnvelopedData and did anybody do something different than what RFC5008 says for ECDSA (i.e., absent parameters when you use ecdsa-with-sha*)? spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad >Sent: Thursday, August 14, 2008 9:01 AM >To: Sean P. Turner >Cc: Ietf-Smime >Subject: Comments on draft-ietf-smime-3278bis-01.txt > > >Section 1.2 > - bullet #1 - should be SHA-1 not SHA > - bullet #3 - change 'e' to 'a' > - be consistent on use of SHA-1 vs SHA1 I fixed these and found some other instances of SHA1 that should have been SHA-1. >Section 2.3.2 -- "SignerInfosignature" --> SignerInfo.signature Fixed. >Snide remark - Can you use ECDH with CMS EnvelopedData w/o key >agreement? No ;) >Section 3. - Is it permitted to do ECC static-static? I believe it's permitted, but nobody asked for it so the RFC3278 authors didn't include it. Since ES DH was the MUST I assume they went with ES ECDH. Do you want to add it? >Section 3.1.1 - originator - The parameters SHOULD be ABSENT >not NULL. This is 1) consistent with what is done for DH and >2) means that you don't have one more additional encoding >binding for the originator field as oppose to the parameters I think we should be doing what DH does and just have absent parameters. >Section 3.1.1 - please justify the requirement for DER >encoding of ECPoint. I assume there isn't one and this was a cut-and-paste from the other field. We'd just drop the DER part and the sentence would read as follows: "The originatorKey publicKey field MUST contain the value of the ASN.1 type ECPoint (see Section 8.2), which represents the sending agent's ephemeral EC public key." >Section 3.1.1 - what about the ukm field? The "but with the following restrictions:" before the bullets leads me to believe there are no restrictions on the other 3 fields. I assume you're asking for more text and we could add a blurb about ukm being absent. If we add something about ukm we may just add something about the other fields and change the intro sentence. >Section 3.2 - I don't understand why ES ECDH cannot be used >for AuthenticatedData. We can use the DH algorithm with it. >I can understand if you want to state that some ADDITIONAL >security properties exist from using 1-pass ECMQV. I dug through the mail archives and found a thread between Francois Rousseau, Dan Brown, and Simon Blake Wilson in March 2001. Before we add it, I think we'd need to address the points raised. Here's how it went: --- a. Sections 1, 3.2, 4.1 and 8.2, it is not clear why only the ECMQV key agreement algorithm is supported with AuthenticatedData and not also the ECDH key agreement algorithm. Although ECMQV is comparable to KEA, which can also be used with AuthenticatedData, ECDH is the analog to the X9.42 Diffie-Hellman key agreement algorithm specified in RFC 2630 and is the default algorithm with AuthenticatedData. --> We looked at RFC 2630 which specifies the use of ephemeral-static Diffie-Hellman within AuthenticatedData---but we didn't understand how this mechanism provides authentication of the sender since the sender is not certified. We didn't want to include the analogous technique based on these concerns. FR> However, as indicated in Section 4 of your ID, AuthenticatedData lacks non-repudiation, and so in some instances is preferable to SignedData (For example, the sending agent may not want the message to be authenticated when forwarded). Using ephemeral-static ECDH within AuthenticatedData can achieve this goal, but not necessarily ECMQV or static-static ECDH, which both require a certified public key from the sender. As per Section 9 of RFC 2630, the goal of AuthenticatedData is to protect the integrity of the content, but not to necessarily provide authentication of the sender. Note also that RFC 2631 specifies both the ephemeral-static and the static-static Diffie-Hellman modes. --> Of course we could have included static-static ECDH, but this would involve a fixed Diffie-Hellman "shared secret" (Z) between each pair of correspondents, which seems undesirable. FR> True, but I though this was the reason under Section 8.2 of your ID that the octet string ukm in the entityUInfo field of the ECC-CMS-SharedInfo could optionally be supplied by the sending agent. By mandating the use of the octet string ukm with the static-static ECDH, you would certainly avoid this undesirable effect. Similarly, in Section 2.1.2 of RFC 2631, the partyAInfo MUST be used in Static-Static mode, but MAY appear in Ephemeral-Static mode to avoid this same undesirable effect. --> Make sense? Can anyone explain how ephemeral-static Diffie-Hellman provides security with AuthenticatedData? FR> I do not consider myself an expert with AuthenticatedData, but see my two responses above. --- >Section 3.2.1 - for the bullet ukm - the last sentence makes >no sense--- Part of the problem is that the next paragraph is >not further indented. This was typo. The paragraph after it should have been connected to the ukm paragraph. >Section 3.2.1 - I would recommend for algorithm that absent >rather than NULL be used to simplify encoding/decoding steps See intro. >Section 3.2.2 - what are the domain parameters the same as? The check is that the recipient's domain parameters and the sender's domain parameters are the same. Will add ", as the sender's domain parameters" to the end of that sentence. >Section 3.2.3 - where does the additional ukm come from It >is/is not an ouptut of the key deployment/agreement algorithm? The sentence was missing something from 3278. It should read: "The receiving agent then retrieves the static and ephemeral EC public keys of the originator, from the originator and ukm fields [as described in Section 3.2.1, and its static EC public key identified in the rid] field and checks that the domain parameters are the same." Does this clear things up? >Section 3.2.3 - Are there requirements/recommendations for >validating a sender's certificate? Are there security >implications for not doing so? I think we could add something about validating the certificate prior to use. We've been discussing something similar for the S/MIME v3.2 IDs. I'll add a reference to the security considerations and will grab the text from MSGbis. >Section 5 - The first implementation requirement makes no >sense. Nor does it provide for interop. It makes more sense >to talk about SignedData conformance w/ the spec or Encryption >conformance w/ the spec. I'm happy to recast these. >Section 5 - Why does ECDH care that P-256 curve be used with >SHA-256? What is this paragraph trying to state? It doesn't care. I mistakenly added the ECDH, or ECMQV to the paragraph it should only be about ECDSA. >Section 5 - What is sha1kdf - where is this referenced? Is >the what the previous paragraph is talking about? These are defined later. I'll add a reference to the paragraph. >Section 5 - Are the KDF functions referenced here defined >using an object identifier in the X9.62 specifications? If so >it would be good to include those OIDs in the ASN.1 module. >(No private opinion) Yes they use the OIDs from X9.62 and they are included in the modules. >Section 5 - Need to do some type of reference to where all of >the key wrap and content encryption algorithms are defined. Agreed. >Section 8.1 - Has the following text: > When the object identifier id-ecPublicKey is used here with an > algorithm identifier, the associated parameters contain NULL. > > I thought that there were ec domain parameters that were to >be encoded with the public key. Where else would this be >used? Is this from the OriginatorKey clause above that I >think is incorrect? In this ID it's only used in the OriginatorKey clause. I'd change the following "The following object identifier is used in this document to indicate an elliptic curve public key:" to "The following object identifier is used in this document to indicate an elliptic curve public key in the OriginatorKey field:" and change "When the object identifier id-ecPublicKey is used here with an algorithm identifier, the associated parameters contain NULL" to "When the object identifier id-ecPublicKey is used here with an algorithm identifier, the associated parameters contain are absent." >Section 8.1 - for ecdas-with-*, is it considered acceptable to >have absent parameters? See intro. >Section 8.1 - The parameters for the encryption schemes - > KeyWrap ::= OBJECT IDENTIFIER or > KeyWrap ::= AlgorithmIdentifier > It is not clear from the text at the end of the last >paragraph in this section. Many people use OID and "algorithm >identifier" as the same thing. How about: When the object identifiers are used here within an algorithm identifier, the associated parameters field contains the KeyWrapAlgorithm field, which indicates the key wrap algorithm and any assoicated parameters. >Section 8.2 What happens for keyInfo if the key wrap >algorithm actually has parameters? I think this is wrong. It ought to allow for parameters and absent parameters (i.e., for aes*-wrap). I propose: Old: keyInfo contains the object identifier of the key-encryption algorithm (used to wrap the CEK) and NULL parameters. New: keyInfo contains the object identifier of the key-encryption algorithm (used to wrap the CEK) and associated parameters. In this specification, 3DES wrap has NULL parameters while the AES wraps have absent parameters. >Section 8.2 - suppPubInfo - Since AES128 is the required key >wrap, use that for the example not 3DES Fixed. Still working on these: >Section 3.2.2 - Please elaborate on the re-used statement in >the last paragraph. Can be re-used for what? for how long? >why can't it be re-used for encrypted data? > >Section 3.2.2 - if you re-use the ephemeral - what does/does >not need to be changed? The additional ukm? I'm leaning towards deleting this sentnece and the similar sentences in 4.1.2 and 4.2.2. >Section 4.1.2 - Note: There is a legal attack where by the >recipient modifies the content and goes to court with the >modified content. Unless you bind the output MAC in with the >MAC key, you cannot prevent this type of attack. Not sure what to do with this one. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7KLQXct035102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 14:26:33 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7KLQXVe035101; Wed, 20 Aug 2008 14:26:33 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7KLQUML035092 for ; Wed, 20 Aug 2008 14:26:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 69631 invoked from network); 20 Aug 2008 21:26:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.241.1.46 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 20 Aug 2008 21:26:29 -0000 X-YMail-OSG: 1V8SzbQVM1mkggzNyF_jFDIBYHwWNlW0HhY059wtXhMQiWQb2h6Cpq7VAgpA9tetlRdJ4twzqKryDNqIpSCappB0VkbFe.nvExEe7NlTrA4vYi0gU0GtjF4N6rH7kSVIW1AiTBTUOcef4VOj5gKiNF5x X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , References: <31B9D22ECA884473981B83F00F05ECA5@Wylie> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Wed, 20 Aug 2008 17:26:24 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwAJjE7BA In-Reply-To: Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, I incorporated these comments in a version I'm about to post. Minor tweaks to the text for the CERT security considerations. spt >-----Original Message----- >From: Tony Capel [mailto:capel@comgate.com] >Sent: Friday, August 08, 2008 3:41 PM >To: 'Turner, Sean P.'; ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt > >Sean: > >I know you will be putting in some text to address Jim (and >my) request for text re key sizes > 4096 for CERT 3850bis. > >A directly related security concern, and one that has been >around for some time, is the potential for other inappropriate >processing if an offered end entity cert (or any offered cert >in the chain) is processed prior to, or irrespective of, being >validated to a trusted root. In addition to the problem of a >large key, there is the potential of inappropriate CDP (and/or >AIA) defined action (e.g. web access to an inappropriate >address). Rfc5280 [KEYM] has a comment* about making sure >that such an action does not download malicious code, but in >practice even correctly formed CDP/AIA access(es) could raise >denial of service or privacy concerns. Normally a user agent >will time out on an invalid CDP/AIA address; but certificates >can contain many addresses.... Also, the CDP/AIA address >could point to a special address defined by the originator, e.g. >allowing a spammer to validate receipt of a signed message >(even if the signature fails). > >So I wonder, for CERT, whether it would be best to be more >general when identifying these security concerns so that >issues in addition to the key size are included? > >Some possible text (for CERT only): > >"In addition to the Security Considerations identified in >[KEYM], caution should be taken when processing certificates >which have not first been validated to a trust anchor. >Certificates could be manufactured by untrusted sources for >the purpose of mounting denial of service or other attacks. >For example, keys selected to require excessive cryptographic >processing, or extensive lists of CDP and/or AIA addresses in >the certificate, could be used to mount denial of service >attacks. Similarly, originator-specified CDP and/or AIA >addresses could be inserted into certificates to allow the >originator to detect receipt of the message even if signature >verification fails." > >The above would just identify the concern, not offer any >solutions - I suggest leaving how to be cautious up to the >implementer! > > >Finally, I am still concerned that we are not making support >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION >ONLY mandatory, i.e. in section 4.3 of 3850bis. In practice >this size is widely supported today, e.g. both MS and Mozilla >have many 4k certs in their root stores**. >The discussion here is verification only, NOT signature >generation or decryption >- mandating support for these I agree needs to be limited to >2k; the typical crypto size limit for hardware tokens. >However, signature verification is not normally done in the >token anyway; so this is not an issue. In practice many >authorities are going to 4k root certs because they want to >issue them with long lifetimes (longer than end user certs, so >shorter keys in end user certs are ok). We need to make sure >common e-mail clients building to v3.2 can work with these >common new 4k RSA root certs. This comment ONLY affects >support for cert signature processing (3850bis section 4.3, >and even then maybe only for Certificates, not CRLs). > > >Tony > > >*Abstract from KEYM: > "Implementers should be aware of risks involved if the CRL > distribution points or authority information access extensions of > corrupted certificates or CRLs contain links to malicious code. > Implementers should always take the steps of validating the >retrieved > data to ensure that the data is properly formed." > >** See GeoTrust Universal CA in both MS and Mozilla root stores. > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. >| Sent: July 28, 2008 4:18 PM >| To: ietf-smime@imc.org >| Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt >| >| >| >| Other things Jim requested offline: >| - Point to PKIXALG as opposed to CMSALG, which makes sense >since this >| is the CERT ID. >| - Add back in changes from v3 to v3.1, which also makes >sense because >| the section should not have been removed. >| >| spt >| >-----Original Message----- >| >From: Jim Schaad [mailto:ietf@augustcellars.com] >| >Sent: Monday, July 28, 2008 2:43 PM >| >To: Sean P. Turner; 'Blake Ramsdell' >| >Cc: ietf-smime@imc.org >| >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt >| > >| >Comments on the draft. >| > >| >In section 4.4.3, I find the following text confusing: >| > >| >End-entity certificates contain an extension that >| > constrains the certificate from being an issuing authority >| > certificate (see Section 4.4.2). >| > >| > >| >I believe that this text might be better as it clarifies what is >| >being stated. I.e. it is not the fact that basic constraints is >| >being used which actually does the mentioned >| constraint. >| > >| > >| >End-entity certificates contain the Key Usage extension which >| >restraints the end-entity from using the key to perform issuing >| >authority operations (see >| >4.4.4) >| > >| >Also the previous comment (on 3851bis) on key sizes > 4096 >should be >| >applied to this document >| > >| >jim >| > >| >> -----Original Message----- >| >> From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- >| >> smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org >| >> Sent: Tuesday, July 01, 2008 1:30 AM >| >> To: i-d-announce@ietf.org >| >> Cc: ietf-smime@imc.org >| >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt >| >> >| >> 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 : Secure/Multipurpose Internet Mail Extensions >| >> (S/MIME) Version 3.2 Certificate Handling >| >> Author(s) : S. Turner, B. Ramsdell >| >> Filename : draft-ietf-smime-3850bis-04.txt >| >> Pages : 20 >| >> Date : 2008-6-30 >| >> >| >> This document specifies conventions for X.509 certificate usage by >| >> Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. >| >> S/MIME >| >> provides a method to send and receive secure MIME messages, and >| >> certificates are an integral part of S/MIME agent processing. >| >> S/MIME agents validate certificates as described in RFC >| 3280bis, the >| >> Internet X.509 Public Key Infrastructure Certificate and CRL >| >> Profile. >| >> S/MIME agents must meet the certificate processing >| requirements in >| >> this document as well as those in RFC 3280bis. This document >| >> obsoletes RFC 3850. >| >> >| >> A URL for this Internet-Draft is: >| >> >http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt >| >> >| >> Internet-Drafts are also available by anonymous FTP at: >| >> ftp://ftp.ietf.org/internet-drafts/ >| >> >| >> Below is the data which will enable a MIME compliant mail reader >| >> implementation to automatically retrieve the ASCII version of the >| >> Internet-Draft. >| > >| > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7KDWlmI090352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Aug 2008 06:32:47 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7KDWlP2090351; Wed, 20 Aug 2008 06:32:47 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7KDWjwV090335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Aug 2008 06:32:46 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m7KDWjaT022722; Wed, 20 Aug 2008 06:32:45 -0700 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Aug 2008 06:32:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C902C9.39BF1186" Subject: RE: Key size security considerations Date: Wed, 20 Aug 2008 06:29:48 -0700 Message-ID: <2788466ED3E31C418E9ACC5C316615572FF9E8@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Key size security considerations Thread-Index: Acj6jSQwrP0r53J/RNCR2eZn15TlpgIO6zVw References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> From: "Hallam-Baker, Phillip" To: "Paul Hoffman" , X-OriginalArrivalTime: 20 Aug 2008 13:32:44.0610 (UTC) FILETIME=[3A45BA20:01C902C9] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C902C9.39BF1186 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Given what we know about the state of factoring algorithms I think that = we could state that if your security needs demand higher security than = you get from 2048 bit RSA you should consider a different algorithm and = certainly at 4096. =20 =20 ________________________________ From: owner-ietf-smime@mail.imc.org on behalf of Paul Hoffman Sent: Sat 8/9/2008 9:15 PM To: ietf-smime@imc.org Subject: Key size security considerations Earlier, I proposed a replacement for part of the security considerations in 3851bis (S/MIME message). The current text reads: Larger keys are not necessarily better keys. Larger keys take more computational resources, and this can quickly become impractical. = In fact, support for an excessively large key offers a denial of = service opportunity if the attacker can cause excessive cryptographic processing by providing such a public key. One mitigation approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. In such cases, measures should be included to limit the impact, for example by limiting cryptographic processing time or requiring certificate validation prior to the use of large keys. There is no parallel text in 3850bis. There has been some good discussion, and I now propose different, more general wording that should be included in both documents. This would replace the above paragraph in 3851bis and be added to 3850bis. Sending and receiving agents need to be cautious of CPU usage and other resources when handling public keys larger than those mandated in this specification (that is, larger than 2048 bits). For example, an attacker can send very large, bogus signatures in order to swamp the CPU of the receiving party. Another example is that an attacker can try to cause a sender to try to encrypt with a very large key. One mitigation approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. Sending and receiving parties are advised to have some sort of resource management system to prevent such attacks. ------_=_NextPart_001_01C902C9.39BF1186 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Key size security considerations=0A= =0A= =0A= =0A=
=0A=
Given what we = know about the state of factoring algorithms I think that we could state = that if your security needs demand higher security than you get from = 2048 bit RSA you should consider a different algorithm and certainly at = 4096.
=0A=
 
=0A=
 
=0A=

=0A=
=0A= From: owner-ietf-smime@mail.imc.org = on behalf of Paul Hoffman
Sent: Sat 8/9/2008 9:15 = PM
To: ietf-smime@imc.org
Subject: Key size security = considerations

=0A=

=0A=

Earlier, I proposed  a replacement for part of = the security
considerations in 3851bis (S/MIME message). The current = text reads:

    Larger keys are not necessarily = better keys.  Larger keys take more
    = computational resources, and this can quickly become impractical.  = In
    fact, support for an excessively large key = offers a denial of service
    opportunity if the = attacker can cause excessive cryptographic
    = processing by providing such a public key.  One mitigation = approach
    would require that the corresponding = public key certificate be
    validated to a trust = anchor prior to use, thus ensuring that only
    = trusted public keys are used.  However, some implementations = may
    choose to perform signature verification (or = key establishment for
    encryption) in parallel with = certificate validation, even if
    certificate = validation fails.  In such cases, measures should = be
    included to limit the impact, for example by = limiting cryptographic
    processing time or = requiring certificate validation prior to the use
    = of large keys.

There is no parallel text in 3850bis.

There = has been some good discussion, and I now propose different,
more = general wording that should be included in both documents. This
would = replace the above paragraph in 3851bis and be added to = 3850bis.

Sending and receiving agents need to be cautious of CPU = usage and
other resources when handling public keys larger than those = mandated
in this specification (that is, larger than 2048 bits). For = example,
an attacker can send very large, bogus signatures in order = to swamp
the CPU of the receiving party. Another example is that an = attacker
can try to cause a sender to try to encrypt with a very = large key.
One mitigation approach would require that the = corresponding public
key certificate be validated to a trust anchor = prior to use, thus
ensuring that only trusted public keys are = used.  However, some
implementations may choose to perform = signature verification (or key
establishment for encryption) in = parallel with certificate
validation, even if certificate validation = fails. Sending and
receiving parties are advised to have some sort of = resource
management system to prevent such = attacks.

------_=_NextPart_001_01C902C9.39BF1186-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7JHTbxL090766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Aug 2008 10:29:37 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7JHTbYg090765; Tue, 19 Aug 2008 10:29:37 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7JHTZvu090757 for ; Tue, 19 Aug 2008 10:29:36 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m7JHTZ6P010043 for ; Tue, 19 Aug 2008 13:29:35 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m7JHTZap010034 for ; Tue, 19 Aug 2008 13:29:35 -0400 Received: from stovetop-1.mitre.org ([128.29.115.221]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 13:29:33 -0400 Message-Id: From: Timothy J Miller To: ietf-smime@imc.org Content-Type: multipart/signed; boundary=Apple-Mail-1-341603249; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v926) Subject: Anyone know of any specific opaque signed verification issues in Apple Mail? Date: Tue, 19 Aug 2008 12:29:25 -0500 X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 19 Aug 2008 17:29:33.0925 (UTC) FILETIME=[25456150:01C90221] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-1-341603249 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Blackberries with the S/MIME support package produce opaque signed S/ MIME, which I can read in just about every client (including OpenSSL) except Apple Mail. I know Apple tends to take a strict approach when it comes to some parts of S/MIME (e.g., they're the only S/MIME MUA in common use that enforces case sensitivity in the local-part of an email address when matching sender to certificate) so I was wondering if this was another case of that. Anyone know about any strictness issues or other bugs on this before I report it to Apple? -- Tim --Apple-Mail-1-341603249 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16 KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS +lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8 umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3 aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6 1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwODE5MTcyOTI2 WjAjBgkqhkiG9w0BCQQxFgQUy71qqNc5t5tYgTY2ImPwkCJTMWEwcgYJKwYBBAGCNxAEMWUwYzBd MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB BQAEgYASlS3ODANKjU4haaml643+05VlLG6puxkcjIAXLQ7MYsEsjDdkMsVuwwkcVuxUoaWrk+Yj 4cuceAGh03hJ60BGDpba0mjRtD0ZewRFF4iuZt2vaitxbRRrms8dN5DoUaLynkxrw6ay2REzOddY KlMNDg2aWwMGQCNlUWbx7RB/+AAAAAAAAA== --Apple-Mail-1-341603249-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7ED0WDw024336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2008 06:00:33 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7ED0WMW024334; Thu, 14 Aug 2008 06:00:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from fep04.mfe.bur.connect.com.au (fep04.mfe.bur.connect.com.au [203.63.86.24]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7ED0V8l024325 for ; Thu, 14 Aug 2008 06:00:31 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: from hio-syd-au.getin2net.com (unknown [210.8.137.162]) by fep04.mfe.bur.connect.com.au (Postfix) with ESMTP id F0ECDF9E0; Thu, 14 Aug 2008 23:00:54 +1000 (EST) Received: from GALATIONS ([172.17.0.93]) by hio-syd-au.getin2net.com (8.13.8/8.13.8/Debian-3) with ESMTP id m7ED0tuQ024757; Thu, 14 Aug 2008 23:00:56 +1000 From: "Jim Schaad" To: "Sean P. Turner" Cc: "Ietf-Smime" References: <20080701171501.6A9693A6BA1@core3.amsl.com> In-Reply-To: <20080701171501.6A9693A6BA1@core3.amsl.com> Subject: Comments on draft-ietf-smime-3278bis-01.txt Date: Thu, 14 Aug 2008 23:00:53 +1000 Message-ID: <015701c8fe0d$cc774e60$6565eb20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjbnio8tmTGHYIBQ+erKGEHdRVzVQhnqn6g Content-Language: en-us X-Virus-Scanned: ClamAV 0.93.1/8035/Thu Aug 14 14:07:53 2008 on hio-syd-au.getin2net.com X-Virus-Status: Clean Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Section 1.2 - bullet #1 - should be SHA-1 not SHA - bullet #3 - change 'e' to 'a' - be consistent on use of SHA-1 vs SHA1 Section 2.3.2 -- "SignerInfosignature" --> SignerInfo.signature Snide remark - Can you use ECDH with CMS EnvelopedData w/o key agreement? Section 3. - Is it permitted to do ECC static-static? Section 3.1.1 - originator - The parameters SHOULD be ABSENT not NULL. This is 1) consistent with what is done for DH and 2) means that you don't have one more additional encoding binding for the originator field as oppose to the parameters Section 3.1.1 - please justify the requirement for DER encoding of ECPoint. Section 3.1.1 - what about the ukm field? Section 3.2 - I don't understand why ES ECDH cannot be used for AuthenticatedData. We can use the DH algorithm with it. I can understand if you want to state that some ADDITIONAL security properties exist from using 1-pass ECMQV. Section 3.2.1 - for the bullet ukm - the last sentence makes no sense--- Part of the problem is that the next paragraph is not further indented. Section 3.2.1 - I would recommend for algorithm that absent rather than NULL be used to simplify encoding/decoding steps Section 3.2.2 - what are the domain parameters the same as? Section 3.2.2 - where does the additional ukm come from It is/is not an ouptut of the key deployment/agreement algorithm? Section 3.2.2 - Please elaborate on the re-used statement in the last paragraph. Can be re-used for what? for how long? why can't it be re-used for encrypted data? Section 3.2.2 - if you re-use the ephemeral - what does/does not need to be changed? The additional ukm? Section 3.2.3 - Are there requirements/recommendations for validating a sender's certificate? Are there security implications for not doing so? Section 4.1.2 - Note: There is a legal attack where by the recipient modifies the content and goes to court with the modified content. Unless you bind the output MAC in with the MAC key, you cannot prevent this type of attack. Section 5 - The first implementation requirement makes no sense. Nor does it provide for interop. It makes more sense to talk about SignedData conformance w/ the spec or Encryption conformance w/ the spec. Section 5 - Why does ECDH care that P-256 curve be used with SHA-256? What is this paragraph trying to state? Section 5 - What is sha1kdf - where is this referenced? Is the what the previous paragraph is talking about? Section 5 - Are the KDF functions referenced here defined using an object identifier in the X9.62 specifications? If so it would be good to include those OIDs in the ASN.1 module. (No private opinion) Section 5 - Need to do some type of reference to where all of the key wrap and content encryption algorithms are defined. Section 8.2 - Has the following text: When the object identifier id-ecPublicKey is used here with an algorithm identifier, the associated parameters contain NULL. I thought that there were ec domain parameters that were to be encoded with the public key. Where else would this be used? Is this from the OriginatorKey clause above that I think is incorrect? Section 8.1 - for ecdas-with-*, is it considered acceptable to have absent parameters? Section 8.1 - The parameters for the encryption schemes - KeyWrap ::= OBJECT IDENTIFIER or KeyWrap ::= AlgorithmIdentifier It is not clear from the text at the end of the last paragraph in this section. Many people use OID and "algorithm identifier" as the same thing. Section 8.2 What happens for keyInfo if the key wrap algorithm actually has parameters? Section 8.2 - suppPubInfo - Since AES128 is the required key wrap, use that for the example not 3DES Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7CBlMJq024202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Aug 2008 04:47:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7CBlMcg024200; Tue, 12 Aug 2008 04:47:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m7CBlIwN024187 for ; Tue, 12 Aug 2008 04:47:19 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([192.168.12.38]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm5948a1dbae; Tue, 12 Aug 2008 20:02:46 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1a489cc722; Sat, 09 Aug 2008 02:01:22 +0800 Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 09 Aug 2008 02:01:22 +0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594013A6D7A; Fri, 8 Aug 2008 10:45:10 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 368EB3A6D72; Fri, 8 Aug 2008 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-smime-ibearch-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808174502.368EB3A6D72@core3.amsl.com> Date: Fri, 8 Aug 2008 10:45:02 -0700 (PDT) Cc: ietf-smime@imc.org X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn 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 : Identity-based Encryption Architecture and Supporting Data Structures Author(s) : M. Schertler Filename : draft-ietf-smime-ibearch-07.txt Pages : 37 Date : 2008-8-8 This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-ibearch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-8103052.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BEsMZ4036832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2008 07:54:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7BEsM4O036831; Mon, 11 Aug 2008 07:54:22 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail-01.primus.ca (smtp-noauth4.primus.ca [216.254.180.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7BEsLvN036813 for ; Mon, 11 Aug 2008 07:54:21 -0700 (MST) (envelope-from capel@comgate.com) Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-01.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1KSYmq-0000SS-1l; Mon, 11 Aug 2008 10:54:20 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , , "'Hoffman, Paul'" Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Mon, 11 Aug 2008 10:54:09 -0400 Message-ID: <2A69EF0090F34CC8A84A3643CA55CC86@tony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 In-Reply-To: <8E4B9CC125344AD7B9AE6A211673B37D@Wylie> Importance: Normal Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwAAFNtWgAInBViA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: | | >-----Original Message----- | | Snip | | >Some possible text (for CERT only): | > | >"In addition to the Security Considerations identified in | >[KEYM], caution should be taken when processing certificates | >which have not first been validated to a trust anchor. | >Certificates could be manufactured by untrusted sources for | >the purpose of mounting denial of service or other attacks. | >For example, keys selected to require excessive cryptographic | >processing, or extensive lists of CDP and/or AIA addresses in | >the certificate, could be used to mount denial of service | >attacks. Similarly, originator-specified CDP and/or AIA | >addresses could be inserted into certificates to allow the | >originator to detect receipt of the message even if signature | >verification fails." | > | >The above would just identify the concern, not offer any | >solutions - I suggest leaving how to be cautious up to the | >implementer! | | Since Paul's replacement text removes the part about path | validation I like the idea of moving it to CERT. Not sure I | understand the last sentence (how is the originator going to | insert fields in their certificate)? "Insert" may have been a misleading. I meant that its pretty easy* for an originator to create an end user cert (and possibly zero or more intermediate certificates) with selected content (including bad keys, arbitrary CDP/AIA URI entries, etc.)). These would not validate to a trust anchor, but IF they are processed anyway, the originator could get a receiver to use a large key, execute a specified URI, etc. So for CERT the problem is not only bad keys. I do not suggest addressing anything other than bad keys in MSG, since I think the above additional issues (other certificate content) is a CERT processing issue not an MSG issue. (For MSG its only the use of a key requiring excessive processing, and the mitigation measures are related to MSG crypto processing and your point about time-out is good for MSG.) | I also don't want to | loose the ideas that we had in MSG about ensuring only | trusted keys are used before use and that a time-out isn't a | bad idea. That is I'd like to keep the following text: | | One approach would require that the corresponding public key | certificate be validated to a trust anchor prior to use, thus | ensuring that only trusted public keys are used. However, | some implementations may choose to perform signature | verification (or key establishment for encryption) in | parallel with certificate validation, even if certificate | validation fails. In such cases, measures should be | included to limit the impact, for example by limiting | cryptographic processing time or requiring certificate | validation prior to the use of large keys. | | >Finally, I am still concerned that we are not making support | >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION | >ONLY mandatory, i.e. in section 4.3 of 3850bis. In practice | >this size is widely supported today, e.g. both MS and Mozilla | >have many 4k certs in their root stores**. | >The discussion here is verification only, NOT signature | >generation or decryption | >- mandating support for these I agree needs to be limited to | >2k; the typical crypto size limit for hardware tokens. | >However, signature verification is not normally done in the | >token anyway; so this is not an issue. In practice many | >authorities are going to 4k root certs because they want to | >issue them with long lifetimes (longer than end user certs, so | >shorter keys in end user certs are ok). We need to make sure | >common e-mail clients building to v3.2 can work with these | >common new 4k RSA root certs. This comment ONLY affects | >support for cert signature processing (3850bis section 4.3, | >and even then maybe only for Certificates, not CRLs). | | Unless I've misread my email from before, Paul objected to | having requirements on the verifiers that are in excess of | the signers and that it's really more of a current practice | as opposed to an interoperability requirement. Paul correct | me if I'm wrong. This does not impose differing requirements on smime signers and verifiers. I think both smime signers and verifiers need 4k support for certificate (and CRL) verification only. I expect these 4k certificates and CRLs to be created by certificate authorities so only they need to create the 4k signatures. Tony * i.e. the perpetrator could set up a CA and generate these certificates. >>cut Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7A1FEfF009875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 18:15:14 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m7A1FEFn009874; Sat, 9 Aug 2008 18:15:14 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [165.227.249.203] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m7A1FDYf009868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 Aug 2008 18:15:13 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> Date: Sat, 9 Aug 2008 18:15:11 -0700 To: From: Paul Hoffman Subject: Key size security considerations Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Earlier, I proposed a replacement for part of the security considerations in 3851bis (S/MIME message). The current text reads: Larger keys are not necessarily better keys. Larger keys take more computational resources, and this can quickly become impractical. In fact, support for an excessively large key offers a denial of service opportunity if the attacker can cause excessive cryptographic processing by providing such a public key. One mitigation approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. In such cases, measures should be included to limit the impact, for example by limiting cryptographic processing time or requiring certificate validation prior to the use of large keys. There is no parallel text in 3850bis. There has been some good discussion, and I now propose different, more general wording that should be included in both documents. This would replace the above paragraph in 3851bis and be added to 3850bis. Sending and receiving agents need to be cautious of CPU usage and other resources when handling public keys larger than those mandated in this specification (that is, larger than 2048 bits). For example, an attacker can send very large, bogus signatures in order to swamp the CPU of the receiving party. Another example is that an attacker can try to cause a sender to try to encrypt with a very large key. One mitigation approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. Sending and receiving parties are advised to have some sort of resource management system to prevent such attacks. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m79Mjrjj003604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 15:45:53 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m79MjrPK003603; Sat, 9 Aug 2008 15:45:53 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m79MjoAF003588 for ; Sat, 9 Aug 2008 15:45:52 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 48529 invoked from network); 9 Aug 2008 22:45:50 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.115.214 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 9 Aug 2008 22:45:50 -0000 X-YMail-OSG: gNZnZd4VM1kcdxDO.JNCueMvaUqfkb32tgYVmGN_utvvuYGL4m5u0SagmgFS6hPvs_Iz6xVhCxD0d8lWKFuSdml9bK1Te4ic0e0A49QNog-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , , "Hoffman, Paul" References: <31B9D22ECA884473981B83F00F05ECA5@Wylie> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Sat, 9 Aug 2008 18:45:42 -0400 Organization: IECA, Inc. Message-ID: <8E4B9CC125344AD7B9AE6A211673B37D@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwAAFNtWg Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- Snip >Some possible text (for CERT only): > >"In addition to the Security Considerations identified in >[KEYM], caution should be taken when processing certificates >which have not first been validated to a trust anchor. >Certificates could be manufactured by untrusted sources for >the purpose of mounting denial of service or other attacks. >For example, keys selected to require excessive cryptographic >processing, or extensive lists of CDP and/or AIA addresses in >the certificate, could be used to mount denial of service >attacks. Similarly, originator-specified CDP and/or AIA >addresses could be inserted into certificates to allow the >originator to detect receipt of the message even if signature >verification fails." > >The above would just identify the concern, not offer any >solutions - I suggest leaving how to be cautious up to the >implementer! Since Paul's replacement text removes the part about path validation I like the idea of moving it to CERT. Not sure I understand the last sentence (how is the originator going to insert fields in their certificate)? I also don't want to loose the ideas that we had in MSG about ensuring only trusted keys are used before use and that a time-out isn't a bad idea. That is I'd like to keep the following text: One approach would require that the corresponding public key certificate be validated to a trust anchor prior to use, thus ensuring that only trusted public keys are used. However, some implementations may choose to perform signature verification (or key establishment for encryption) in parallel with certificate validation, even if certificate validation fails. In such cases, measures should be included to limit the impact, for example by limiting cryptographic processing time or requiring certificate validation prior to the use of large keys. >Finally, I am still concerned that we are not making support >for (RSA) 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION >ONLY mandatory, i.e. in section 4.3 of 3850bis. In practice >this size is widely supported today, e.g. both MS and Mozilla >have many 4k certs in their root stores**. >The discussion here is verification only, NOT signature >generation or decryption >- mandating support for these I agree needs to be limited to >2k; the typical crypto size limit for hardware tokens. >However, signature verification is not normally done in the >token anyway; so this is not an issue. In practice many >authorities are going to 4k root certs because they want to >issue them with long lifetimes (longer than end user certs, so >shorter keys in end user certs are ok). We need to make sure >common e-mail clients building to v3.2 can work with these >common new 4k RSA root certs. This comment ONLY affects >support for cert signature processing (3850bis section 4.3, >and even then maybe only for Certificates, not CRLs). Unless I've misread my email from before, Paul objected to having requirements on the verifiers that are in excess of the signers and that it's really more of a current practice as opposed to an interoperability requirement. Paul correct me if I'm wrong. >Tony > > >*Abstract from KEYM: > "Implementers should be aware of risks involved if the CRL > distribution points or authority information access extensions of > corrupted certificates or CRLs contain links to malicious code. > Implementers should always take the steps of validating the >retrieved > data to ensure that the data is properly formed." > >** See GeoTrust Universal CA in both MS and Mozilla root stores. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m79ENruJ071217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 07:23:53 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m79ENr0c071216; Sat, 9 Aug 2008 07:23:53 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [165.227.249.203] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m79ENiMg071189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2008 07:23:45 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5D5FA15E749D429F9A1C68DFD6ABE55F@tony> References: <5D5FA15E749D429F9A1C68DFD6ABE55F@tony> Date: Sat, 9 Aug 2008 07:23:42 -0700 To: "Tony Capel" , "'Turner, Sean P.'" , "'Jim Schaad'" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:51 PM -0400 8/8/08, Tony Capel wrote: >1) I would prefer the security consideration apply to encryption as well as >signature checking. Although less likely, it could be a sending >agent who uses >an intended receiver's unvalidated encryption certificate to get the >"big" key. Someone who is encrypting blindly has many problems that just key size. We could add a warning about this as well, but it is should be a separate warning. >I would not want the text to imply that this is ONLY a receiver >signature issue. It is far easier to get someone to try to validate a signature than it is to get them to encrypt a message. >2) The swamping is specifically related to the crypto element not necessarily >the CPU (i.e. it may be the h/w token that is swamped). Good point. I would be happy with "CPU or other resources". Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78LpH0f017730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 14:51:17 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78LpHZi017726; Fri, 8 Aug 2008 14:51:17 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail-06.primus.ca (smtp-noauth4.primus.ca [216.254.180.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78LpGgp017715; Fri, 8 Aug 2008 14:51:16 -0700 (MST) (envelope-from capel@comgate.com) Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-06.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1KRZre-0005Yl-0l; Fri, 08 Aug 2008 17:51:14 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , "'Paul Hoffman'" , "'Jim Schaad'" , "'Blake Ramsdell'" Cc: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Fri, 8 Aug 2008 17:51:11 -0400 Message-ID: <5D5FA15E749D429F9A1C68DFD6ABE55F@tony> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 In-Reply-To: Importance: Normal Thread-Index: Acj44BPhN82v+KlSRx69J/t9CEPPcAAsV3AQAAHOOUA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: My problems with the proposed text are: 1) I would prefer the security consideration apply to encryption as well = as signature checking. Although less likely, it could be a sending agent = who uses an intended receiver's unvalidated encryption certificate to get the = "big" key. I would not want the text to imply that this is ONLY a receiver = signature issue. We should probably not make assumptions about how the certificates are distributed and we need to address dual keypair use (the signing = certificate could be ok, but the encryption cert could be bad - a "time-bomb"?). I = agree that implementers have more options to address the encryption case (not beginning encryption until cert validation is done) but many = implementers allow encryption certificates to be manually marked as "trusted" - and it is = not clear that everyone only starts the encryption operations after successful = cert validation. So my preference is to be generic: "be careful about using = big keys from unvalidated end user certs to validate signatures or encrypt". 2) The swamping is specifically related to the crypto element not = necessarily the CPU (i.e. it may be the h/w token that is swamped). As per my post earlier today to the 3850bis list, the CERT security considerations may be a bit more complex so having a separate discussion = there might be a good idea. Tony | -----Original Message----- | From: owner-ietf-smime@mail.imc.org=20 | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. | Sent: August 8, 2008 4:09 PM | To: 'Paul Hoffman'; 'Jim Schaad'; 'Blake Ramsdell' | Cc: ietf-smime@imc.org | Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt |=20 |=20 |=20 | >-----Original Message----- | >From: Paul Hoffman [mailto:phoffman@imc.org] | >Sent: Thursday, August 07, 2008 6:51 PM | >To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell' | >Cc: ietf-smime@imc.org | >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt | > | >At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote: | >> >Proposed wording: | >>> | >>>Receiving agents that validate signatures need to be=20 | cautious of CPU | >>>usage when validating signatures larger than those=20 | mandated in this=20 | >>>specification. An attacker can send very large, bogus=20 | signatures in=20 | >>>order to swamp the CPU of the receiving party. Receiving=20 | >parties that | >>>verify large signatures are advised to have some sort of resource | >>>management system to prevent such an attack. | >> | >>Is this in addition to or to replace the para that starts | >"Larger keys | >>are not" in 3851bis Sec 5? | > | >Replace. |=20 | I'm happy with replace, as long as we move the certificate=20 | path validation stuff to [CERT]. Russ, Steve, and Tony all=20 | suggested something about making sure the keys are validated=20 | prior to use. |=20 | spt |=20 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78K9cE3010841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 13:09:38 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78K9cfJ010840; Fri, 8 Aug 2008 13:09:38 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m78K9aPP010824 for ; Fri, 8 Aug 2008 13:09:36 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 27404 invoked from network); 8 Aug 2008 20:09:35 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.3.231 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 8 Aug 2008 20:09:35 -0000 X-YMail-OSG: s.kUfcIVM1nhC2iZlQQ_Mf82G7WGtub21dezk60stiupJHjkOzH77VeIbNud0E2HuBLSJRU2owGrn7nvYKNguM6e6En5WDEbYolnLBq9vA-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Jim Schaad'" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Fri, 8 Aug 2008 16:09:28 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: Thread-Index: Acj44BPhN82v+KlSRx69J/t9CEPPcAAsV3AQ Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Paul Hoffman [mailto:phoffman@imc.org] >Sent: Thursday, August 07, 2008 6:51 PM >To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell' >Cc: ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > >At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote: >> >Proposed wording: >>> >>>Receiving agents that validate signatures need to be cautious of CPU >>>usage when validating signatures larger than those mandated in this >>>specification. An attacker can send very large, bogus signatures in >>>order to swamp the CPU of the receiving party. Receiving >parties that >>>verify large signatures are advised to have some sort of resource >>>management system to prevent such an attack. >> >>Is this in addition to or to replace the para that starts >"Larger keys >>are not" in 3851bis Sec 5? > >Replace. I'm happy with replace, as long as we move the certificate path validation stuff to [CERT]. Russ, Steve, and Tony all suggested something about making sure the keys are validated prior to use. spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78Jejcp008641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 12:40:45 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78JejjM008640; Fri, 8 Aug 2008 12:40:45 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail-02.primus.ca (smtp-noauth4.primus.ca [216.254.180.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78JeiQ5008633 for ; Fri, 8 Aug 2008 12:40:44 -0700 (MST) (envelope-from capel@comgate.com) Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-02.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1KRXpK-0003ed-1x; Fri, 08 Aug 2008 15:40:43 -0400 From: "Tony Capel" To: "'Turner, Sean P.'" , Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Date: Fri, 8 Aug 2008 15:40:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6838 In-Reply-To: <31B9D22ECA884473981B83F00F05ECA5@Wylie> Importance: Normal Thread-Index: AcjbEh1yJ7+xsRIzTQOZzEodyEmkBgVpUNrQAA3fyUACI7vBwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sean: I know you will be putting in some text to address Jim (and my) request = for text re key sizes > 4096 for CERT 3850bis. A directly related security concern, and one that has been around for = some time, is the potential for other inappropriate processing if an offered end = entity cert (or any offered cert in the chain) is processed prior to, or = irrespective of, being validated to a trusted root. In addition to the problem of a = large key, there is the potential of inappropriate CDP (and/or AIA) defined = action (e.g. web access to an inappropriate address). Rfc5280 [KEYM] has a = comment* about making sure that such an action does not download malicious code, = but in practice even correctly formed CDP/AIA access(es) could raise denial of = service or privacy concerns. Normally a user agent will time out on an invalid = CDP/AIA address; but certificates can contain many addresses.... Also, the = CDP/AIA address could point to a special address defined by the originator, e.g. allowing a spammer to validate receipt of a signed message (even if the signature fails). So I wonder, for CERT, whether it would be best to be more general when identifying these security concerns so that issues in addition to the = key size are included? Some possible text (for CERT only): "In addition to the Security Considerations identified in [KEYM], = caution should be taken when processing certificates which have not first been = validated to a trust anchor. Certificates could be manufactured by untrusted sources = for the purpose of mounting denial of service or other attacks. For example, = keys selected to require excessive cryptographic processing, or extensive = lists of CDP and/or AIA addresses in the certificate, could be used to mount = denial of service attacks. Similarly, originator-specified CDP and/or AIA = addresses could be inserted into certificates to allow the originator to detect receipt = of the message even if signature verification fails." The above would just identify the concern, not offer any solutions - I = suggest leaving how to be cautious up to the implementer!=20 Finally, I am still concerned that we are not making support for (RSA) = 4096 bit keys FOR CERTIFICATE SIGNATURE VERIFICATION ONLY mandatory, i.e. in = section 4.3 of 3850bis. In practice this size is widely supported today, e.g. both = MS and Mozilla have many 4k certs in their root stores**. The discussion here is verification only, NOT signature generation or = decryption - mandating support for these I agree needs to be limited to 2k; the = typical crypto size limit for hardware tokens. However, signature verification = is not normally done in the token anyway; so this is not an issue. In practice = many authorities are going to 4k root certs because they want to issue them = with long lifetimes (longer than end user certs, so shorter keys in end user certs = are ok). We need to make sure common e-mail clients building to v3.2 can = work with these common new 4k RSA root certs. This comment ONLY affects support = for cert signature processing (3850bis section 4.3, and even then maybe only for Certificates, not CRLs). Tony *Abstract from KEYM: "Implementers should be aware of risks involved if the CRL distribution points or authority information access extensions of corrupted certificates or CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed." ** See GeoTrust Universal CA in both MS and Mozilla root stores. | -----Original Message----- | From: owner-ietf-smime@mail.imc.org=20 | [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Turner, Sean P. | Sent: July 28, 2008 4:18 PM | To: ietf-smime@imc.org | Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt=20 |=20 |=20 |=20 | Other things Jim requested offline: | - Point to PKIXALG as opposed to CMSALG, which makes sense=20 | since this is the CERT ID. | - Add back in changes from v3 to v3.1, which also makes=20 | sense because the section should not have been removed. |=20 | spt | >-----Original Message----- | >From: Jim Schaad [mailto:ietf@augustcellars.com] | >Sent: Monday, July 28, 2008 2:43 PM | >To: Sean P. Turner; 'Blake Ramsdell' | >Cc: ietf-smime@imc.org | >Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt=20 | > | >Comments on the draft. | > | >In section 4.4.3, I find the following text confusing: | > | >End-entity certificates contain an extension that=20 | > constrains the certificate from being an issuing authority=20 | > certificate (see Section 4.4.2). | > | > | >I believe that this text might be better as it clarifies what | >is being stated. I.e. it is not the fact that basic=20 | >constraints is being used which actually does the mentioned=20 | constraint. | > | > | >End-entity certificates contain the Key Usage extension which | >restraints the end-entity from using the key to perform=20 | >issuing authority operations (see | >4.4.4) | > | >Also the previous comment (on 3851bis) on key sizes > 4096 | >should be applied to this document | > | >jim | > | >> -----Original Message----- | >> From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf- | >> smime@mail.imc.org] On Behalf Of Internet-Drafts@ietf.org | >> Sent: Tuesday, July 01, 2008 1:30 AM | >> To: i-d-announce@ietf.org | >> Cc: ietf-smime@imc.org | >> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt | >>=20 | >> 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=20 | >Working Group of | >> the IETF. | >>=20 | >> Title : Secure/Multipurpose Internet Mail Extensions | >> (S/MIME) Version 3.2 Certificate Handling | >> Author(s) : S. Turner, B. Ramsdell | >> Filename : draft-ietf-smime-3850bis-04.txt | >> Pages : 20 | >> Date : 2008-6-30 | >>=20 | >> This document specifies conventions for X.509 certificate usage by | >> Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.=20 | >> S/MIME | >> provides a method to send and receive secure MIME messages, and | >> certificates are an integral part of S/MIME agent processing.=20 | >> S/MIME agents validate certificates as described in RFC=20 | 3280bis, the | >> Internet X.509 Public Key Infrastructure Certificate and CRL | >> Profile. | >> S/MIME agents must meet the certificate processing=20 | requirements in | >> this document as well as those in RFC 3280bis. This document | >> obsoletes RFC 3850. | >>=20 | >> A URL for this Internet-Draft is:=20 | >> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt | >>=20 | >> Internet-Drafts are also available by anonymous FTP at:=20 | >> ftp://ftp.ietf.org/internet-drafts/ | >>=20 | >> Below is the data which will enable a MIME compliant mail reader | >> implementation to automatically retrieve the ASCII version of the=20 | >> Internet-Draft. | > |=20 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78Hj3SN001021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2008 10:45:03 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m78Hj3Se001020; Fri, 8 Aug 2008 10:45:03 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m78Hj3tM001014 for ; Fri, 8 Aug 2008 10:45:03 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 368EB3A6D72; Fri, 8 Aug 2008 10:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-ibearch-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080808174502.368EB3A6D72@core3.amsl.com> Date: Fri, 8 Aug 2008 10:45:02 -0700 (PDT) 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 : Identity-based Encryption Architecture and Supporting Data Structures Author(s) : M. Schertler Filename : draft-ietf-smime-ibearch-07.txt Pages : 37 Date : 2008-8-8 This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-ibearch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-8103052.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77Mp8ML019324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 15:51:08 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77Mp8Gj019323; Thu, 7 Aug 2008 15:51:08 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77Mp3Kh019313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 15:51:04 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> Date: Thu, 7 Aug 2008 15:51:02 -0700 To: "Turner, Sean P." , "'Jim Schaad'" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote: > >Proposed wording: >> >>Receiving agents that validate signatures need to be cautious >>of CPU usage when validating signatures larger than those >>mandated in this specification. An attacker can send very >>large, bogus signatures in order to swamp the CPU of the >>receiving party. Receiving parties that verify large >>signatures are advised to have some sort of resource >>management system to prevent such an attack. > >Is this in addition to or to replace the para that starts "Larger keys are >not" in 3851bis Sec 5? Replace. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77HgD2S097019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 10:42:13 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77HgDLj097018; Thu, 7 Aug 2008 10:42:13 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m77HgB7e097002 for ; Thu, 7 Aug 2008 10:42:12 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 17365 invoked from network); 7 Aug 2008 17:42:10 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@96.231.115.229 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 7 Aug 2008 17:42:10 -0000 X-YMail-OSG: FCL2yL0VM1mmj1Ma5vongQHuO4o_Ovzq2UKejyfGHWLtxpPyPRnsDLJgS_EI_M3KZhlg7Umz_W2vOw76ZBAyX2Z4bSaKrRaCBWgEC9IAIA-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Paul Hoffman'" , "'Jim Schaad'" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Thu, 7 Aug 2008 13:42:05 -0400 Organization: IECA, Inc. Message-ID: <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: thread-index: Acj31gZA1BV5oRk4QBWJ+04JjAIBmwA3qptg Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >-----Original Message----- >From: Paul Hoffman [mailto:phoffman@imc.org] >Sent: Wednesday, August 06, 2008 11:07 AM >To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell' >Cc: ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > >At 7:44 PM +1000 8/6/08, Jim Schaad wrote: >> > -----Original Message----- >>> From: Paul Hoffman [mailto:phoffman@imc.org] >>> Sent: Sunday, August 03, 2008 8:28 AM >>> To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell' >>> Cc: ietf-smime@imc.org >>> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt >>> >>> At 2:17 PM +0100 7/28/08, Jim Schaad wrote: >>> >Comments on the draft: >>> > >>> >1. We are not currently making any support statements for DSA w/ >>> the >>> >SHA-256 hash algorithms. Should we be doing so? >>> >>> Yes and no. Yes in the sense that US government users who use DSA >> > will want DSA-with-SHA-256. No in the sense that there is no >>> appropriate level of standards support that makes sense: >SHOULD is >>> too strong, given current deployments. >> >>I can deal with a SHOULD+ for this > >In retrospect, I agree with Jim and I'm happy with SHOULD+ for >DSA-with-SHA-256 for both sending and receiving. It's not that >big of a change from 3851. > >>I am perfectly willing to use a non standards word here. For >example, >>permitted. I thought I saw enough consensus from the list that keys >>over this size will have either real-estate constraints or >performance >>constraints. Either would be covered by referring to a security >>considerations discussion to this effect. I don't want to >say or imply >>that keys longer than 4096 are not to be handled. > >Proposed wording: > >Receiving agents that validate signatures need to be cautious >of CPU usage when validating signatures larger than those >mandated in this specification. An attacker can send very >large, bogus signatures in order to swamp the CPU of the >receiving party. Receiving parties that verify large >signatures are advised to have some sort of resource >management system to prevent such an attack. Is this in addition to or to replace the para that starts "Larger keys are not" in 3851bis Sec 5? spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m77GTWf9092158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Aug 2008 09:29:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m77GTW8e092157; Thu, 7 Aug 2008 09:29:32 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m77GTUpo092137 for ; Thu, 7 Aug 2008 09:29:31 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 42944 invoked from network); 7 Aug 2008 16:29:30 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@71.191.14.132 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 7 Aug 2008 16:29:29 -0000 X-YMail-OSG: v.ug34cVM1l953k9RjSR7tLnr6N7xyLdsP7Ho2PiJ3kXhRU_oVcJX8BrJFvY44ZUnC3_NIPOvWRKj0PAtLfOEPxje9RmxiJshL9CTjAbxA-- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: "'Tony Capel'" , "'Paul Hoffman'" , "'Jim Schaad'" , "'Blake Ramsdell'" Cc: References: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Thu, 7 Aug 2008 12:29:24 -0400 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 In-Reply-To: thread-index: Acj31vlw+074IWjkTcOww2DXyLocEgAA6/cgADPjLAA= Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony, In 3850, I added the (see Security Considerations [SMIME-MSG]) from 4.3 of 3850 to pull in the security consdierations from 3851. We already point to it normatively so I think this might be better than copying the text in different places. spt >-----Original Message----- >From: owner-ietf-smime@mail.imc.org >[mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Tony Capel >Sent: Wednesday, August 06, 2008 3:02 PM >To: 'Paul Hoffman'; 'Jim Schaad'; 'Sean P. Turner'; 'Blake Ramsdell' >Cc: ietf-smime@imc.org >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > > > >| -----Original Message----- >| From: owner-ietf-smime@mail.imc.org >| [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Paul Hoffman >| Sent: August 6, 2008 11:07 AM >| To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell' >| Cc: ietf-smime@imc.org >| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt >| >| >>>cut >| >| Proposed wording: >| >| Receiving agents that validate signatures need to be cautious of CPU >| usage when validating signatures larger than those mandated in this >| specification. An attacker can send very large, bogus signatures in >| order to swamp the CPU of the receiving party. Receiving >parties that >| verify large signatures are advised to have some sort of resource >| management system to prevent such an attack. >| > >I agree with the intent here, but this issue applies to both >signature and encryption operations. >So the text needs to address both sections /4.3 Signature >Verification/ and >/4.4 Encryption/ >(/4.5 Decryption/ should be ok since I presume the agent is >using a validated decryption key) > >So maybe the last line of both sections could change to: > >"2048 < key size : MAY (see Security Considerations, and > especially discussion of denial > of service vulnerability when > implementing support for large keys, > e.g. keys larger than 4096.)" > > > >Similarly maybe it is also appropriate* to add the same text >to rfc3850bis-04 section /4.3 Certificate and CRL Signing Algorithms/ > >And the security considerations section of rfc3850bis updated >similarly to 3851 with regard to cautions about large key sizes. > > >Tony > >*Also a problem for cert validation if the provided >intermediate cert has a large key (which would be used to >check the end user certificate signature). >Hopefully implementers will either a) identify the chain of >certificates and begin validation at the trust anchor or b) >limit crypto processing in some way. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76J27hu000269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 12:02:07 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76J27kL000265; Wed, 6 Aug 2008 12:02:07 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail-09.primus.ca (mail.tor.primus.ca [216.254.136.21]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76J1xXl000235; Wed, 6 Aug 2008 12:02:06 -0700 (MST) (envelope-from capel@comgate.com) Received: from ottawa-hs-209-217-122-183.s-ip.magma.ca ([209.217.122.183] helo=tony) by mail-09.primus.ca with esmtps (TLSv1:RC4-MD5:128) (Exim 4.63) (envelope-from ) id 1KQoGj-0001Ul-2X; Wed, 06 Aug 2008 15:01:58 -0400 From: "Tony Capel" To: "'Paul Hoffman'" , "'Jim Schaad'" , "'Sean P. Turner'" , "'Blake Ramsdell'" Cc: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Wed, 6 Aug 2008 15:01:56 -0400 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.6838 In-Reply-To: Thread-Index: Acj31vlw+074IWjkTcOww2DXyLocEgAA6/cg Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 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 Paul Hoffman | Sent: August 6, 2008 11:07 AM | To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell' | Cc: ietf-smime@imc.org | Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt | | >>cut | | Proposed wording: | | Receiving agents that validate signatures need to be cautious of CPU | usage when validating signatures larger than those mandated in this | specification. An attacker can send very large, bogus signatures in | order to swamp the CPU of the receiving party. Receiving parties that | verify large signatures are advised to have some sort of resource | management system to prevent such an attack. | I agree with the intent here, but this issue applies to both signature and encryption operations. So the text needs to address both sections /4.3 Signature Verification/ and /4.4 Encryption/ (/4.5 Decryption/ should be ok since I presume the agent is using a validated decryption key) So maybe the last line of both sections could change to: "2048 < key size : MAY (see Security Considerations, and especially discussion of denial of service vulnerability when implementing support for large keys, e.g. keys larger than 4096.)" Similarly maybe it is also appropriate* to add the same text to rfc3850bis-04 section /4.3 Certificate and CRL Signing Algorithms/ And the security considerations section of rfc3850bis updated similarly to 3851 with regard to cautions about large key sizes. Tony *Also a problem for cert validation if the provided intermediate cert has a large key (which would be used to check the end user certificate signature). Hopefully implementers will either a) identify the chain of certificates and begin validation at the trust anchor or b) limit crypto processing in some way. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76F6eCK079363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 08:06:40 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m76F6erL079360; Wed, 6 Aug 2008 08:06:40 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m76F6XrM079350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 08:06:34 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <000701c8f7a9$10d35c40$327a14c0$@com> References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <000701c8f7a9$10d35c40$327a14c0$@com> Date: Wed, 6 Aug 2008 08:06:31 -0700 To: "Jim Schaad" , "'Sean P. Turner'" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 7:44 PM +1000 8/6/08, Jim Schaad wrote: > > -----Original Message----- >> From: Paul Hoffman [mailto:phoffman@imc.org] >> Sent: Sunday, August 03, 2008 8:28 AM >> To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell' >> Cc: ietf-smime@imc.org >> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt >> >> At 2:17 PM +0100 7/28/08, Jim Schaad wrote: >> >Comments on the draft: >> > >> >1. We are not currently making any support statements for DSA w/ the >> >SHA-256 hash algorithms. Should we be doing so? >> >> Yes and no. Yes in the sense that US government users who use DSA > > will want DSA-with-SHA-256. No in the sense that there is no >> appropriate level of standards support that makes sense: SHOULD is >> too strong, given current deployments. > >I can deal with a SHOULD+ for this In retrospect, I agree with Jim and I'm happy with SHOULD+ for DSA-with-SHA-256 for both sending and receiving. It's not that big of a change from 3851. >I am perfectly willing to use a non standards word here. For example, >permitted. I thought I saw enough consensus from the list that keys over >this size will have either real-estate constraints or performance >constraints. Either would be covered by referring to a security >considerations discussion to this effect. I don't want to say or imply that >keys longer than 4096 are not to be handled. Proposed wording: Receiving agents that validate signatures need to be cautious of CPU usage when validating signatures larger than those mandated in this specification. An attacker can send very large, bogus signatures in order to swamp the CPU of the receiving party. Receiving parties that verify large signatures are advised to have some sort of resource management system to prevent such an attack. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m769iqNO048825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Aug 2008 02:44:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m769iq73048824; Wed, 6 Aug 2008 02:44:52 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.movielink.net.au (mail.movielink.net.au [202.168.29.253]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m769im24048807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Aug 2008 02:44:50 -0700 (MST) (envelope-from ietf@augustcellars.com) Received: (qmail 12630 invoked by uid 509); 6 Aug 2008 19:43:57 +1000 Received: from 203.36.227.132 by mail.movielink.net.au (envelope-from , uid 508) with qmail-scanner-1.25-st-qms (clamdscan: 0.87/5056. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:1(203.36.227.132):. Processed in 0.650914 secs); 06 Aug 2008 09:43:57 -0000 X-Antivirus-MOVIELINK.NET.AU-Mail-From: ietf@augustcellars.com via mail.movielink.net.au X-Antivirus-MOVIELINK.NET.AU: 1.25-st-qms (Clear:RC:1(203.36.227.132):. Processed in 0.650914 secs Process 12615) Received: from unknown (HELO GALATIONS) (203.36.227.132) by mail.movielink.net.au with SMTP; 6 Aug 2008 19:43:56 +1000 From: "Jim Schaad" To: "'Paul Hoffman'" , "'Sean P. Turner'" , "'Blake Ramsdell'" Cc: References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> In-Reply-To: Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Date: Wed, 6 Aug 2008 19:44:42 +1000 Message-ID: <000701c8f7a9$10d35c40$327a14c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj1uCfDU9wbaySQTmG3BvR56qJnBwA5mubQ Content-Language: en-us Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Paul Hoffman [mailto:phoffman@imc.org] > Sent: Sunday, August 03, 2008 8:28 AM > To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell' > Cc: ietf-smime@imc.org > Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt > > At 2:17 PM +0100 7/28/08, Jim Schaad wrote: > >Comments on the draft: > > > >1. We are not currently making any support statements for DSA w/ the > >SHA-256 hash algorithms. Should we be doing so? > > Yes and no. Yes in the sense that US government users who use DSA > will want DSA-with-SHA-256. No in the sense that there is no > appropriate level of standards support that makes sense: SHOULD is > too strong, given current deployments. I can deal with a SHOULD+ for this > > >2. For key size support, key of L>1024 are not supported for DSA-SHA- > 1. > > Arrgh. Quite right. Sections 4.2 and 4.3 need to be rewritten to > indicate that anything greater than 1024 is about RSA *only*. > > >3. I would like to add the following text to the table. > > > >Key size > 4096 MAY NOT (See security considerations on large keys) > > > >This would finish the table entry out and also reference the > discussion on > >why very large keys are not recommended. It is possible that MAY NOT > is not > >currently valid 2119 language. In this case I would be happy with > ether MAY > >or SHOULD NOT. I would not be happy with MUST NOT. > > "MAY NOT" is not part of 2119. Further, we do not have enough > evidence to know size key is "too large". Further still, the number > will be different for receivers of RSA and DSA keys, I believe. > > "MAY" makes no sense. "SHOULD NOT" is too strong, I believe, without > more than just data-less guessing on our part. I am perfectly willing to use a non standards word here. For example, permitted. I thought I saw enough consensus from the list that keys over this size will have either real-estate constraints or performance constraints. Either would be covered by referring to a security considerations discussion to this effect. I don't want to say or imply that keys longer than 4096 are not to be handled. > > At 4:43 PM +0100 7/31/08, Jim Schaad wrote: > >I really feel that we need to have two MUST signature algorithms for > safety. > >When ECC signatures where present that was fine. Without having the > ECC > >signature algorithms we really must have one of the DSA algorithms as > a must > > I disagree. If RSA falls for some reason that cannot be fixed with > longer key sizes, a "SHOULD" on DSA-SHA256 for fallback reasons > assumes that the attack on RSA will not apply to DSA, which seems > like a stretch. Having a "SHOULD" for a fallback seems reasonable. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74LUVDw093189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 14:30:31 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m74LUVn1093188; Mon, 4 Aug 2008 14:30:31 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m74LUUGV093182 for ; Mon, 4 Aug 2008 14:30:31 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 47F653A6A5A; Mon, 4 Aug 2008 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-bfibecms-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080804213001.47F653A6A5A@core3.amsl.com> Date: Mon, 4 Aug 2008 14:30:01 -0700 (PDT) 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 : Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) Author(s) : L. Martin, M. Schertler Filename : draft-ietf-smime-bfibecms-10.txt Pages : 16 Date : 2008-8-4 This document describes the conventions for using the Boneh- Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-smime-bfibecms-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-8-4142145.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m73NRov0093307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2008 16:27:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m73NRoMd093306; Sun, 3 Aug 2008 16:27:50 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m73MRjBc090732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2008 15:27:46 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <01e001c8f0b4$4182f4a0$c488dde0$@com> References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> Date: Sun, 3 Aug 2008 16:27:36 +0100 To: "Jim Schaad" , "Sean P. Turner" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:17 PM +0100 7/28/08, Jim Schaad wrote: >Comments on the draft: > >1. We are not currently making any support statements for DSA w/ the >SHA-256 hash algorithms. Should we be doing so? Yes and no. Yes in the sense that US government users who use DSA will want DSA-with-SHA-256. No in the sense that there is no appropriate level of standards support that makes sense: SHOULD is too strong, given current deployments. >2. For key size support, key of L>1024 are not supported for DSA-SHA-1. Arrgh. Quite right. Sections 4.2 and 4.3 need to be rewritten to indicate that anything greater than 1024 is about RSA *only*. >3. I would like to add the following text to the table. > >Key size > 4096 MAY NOT (See security considerations on large keys) > >This would finish the table entry out and also reference the discussion on >why very large keys are not recommended. It is possible that MAY NOT is not >currently valid 2119 language. In this case I would be happy with ether MAY >or SHOULD NOT. I would not be happy with MUST NOT. "MAY NOT" is not part of 2119. Further, we do not have enough evidence to know size key is "too large". Further still, the number will be different for receivers of RSA and DSA keys, I believe. "MAY" makes no sense. "SHOULD NOT" is too strong, I believe, without more than just data-less guessing on our part. At 4:43 PM +0100 7/31/08, Jim Schaad wrote: >I really feel that we need to have two MUST signature algorithms for safety. >When ECC signatures where present that was fine. Without having the ECC >signature algorithms we really must have one of the DSA algorithms as a must I disagree. If RSA falls for some reason that cannot be fixed with longer key sizes, a "SHOULD" on DSA-SHA256 for fallback reasons assumes that the attack on RSA will not apply to DSA, which seems like a stretch. Having a "SHOULD" for a fallback seems reasonable. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m73MRpw5090748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2008 15:27:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m73MRpNu090747; Sun, 3 Aug 2008 15:27:51 -0700 (MST) (envelope-from owner-ietf-smime@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m73MRjBe090732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Aug 2008 15:27:47 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <01e701c8f0b7$db2d7550$91885ff0$@com> References: <20080701003001.D4EE13A6B29@core3.amsl.com> <01e701c8f0b7$db2d7550$91885ff0$@com> Date: Sun, 3 Aug 2008 16:20:10 +0100 To: "Jim Schaad" , "Sean P. Turner" , "'Blake Ramsdell'" From: Paul Hoffman Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:43 PM +0100 7/28/08, Jim Schaad wrote: >Comments on the draft. > >In section 4.4.3, I find the following text confusing: > >End-entity certificates contain an extension that > constrains the certificate from being an issuing authority > certificate (see Section 4.4.2). > > >I believe that this text might be better as it clarifies what is being >stated. I.e. it is not the fact that basic constraints is being used which >actually does the mentioned constraint. > > >End-entity certificates contain the Key Usage extension which restraints the >end-entity from using the key to perform issuing authority operations (see >4.4.4) s/restraints/restrains/ >Also the previous comment (on 3851bis) on key sizes > 4096 should be applied >to this document My same reply applies.