RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt

"Turner, Sean P." <turners@ieca.com> Fri, 08 August 2008 20:23 UTC

Return-Path: <owner-ietf-smime@mail.imc.org>
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 <ietfarch-smime-archive@core3.amsl.com>; 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 <ietfarch-smime-archive@core3.amsl.com>; 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 <smime-archive@ietf.org>; 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 <ietf-smime@imc.org>; 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." <turners@ieca.com>
To: 'Paul Hoffman' <phoffman@imc.org>, 'Jim Schaad' <ietf@augustcellars.com>, 'Blake Ramsdell' <blaker@gmail.com>
Cc: ietf-smime@imc.org
References: <20080701171501.66C9E3A6B99@core3.amsl.com> <01e001c8f0b4$4182f4a0$c488dde0$@com> <p06240800c4bb6ddc408b@[10.20.30.249]> <000701c8f7a9$10d35c40$327a14c0$@com> <p06240813c4bf6bc2ad3e@[10.20.30.152]> <7E8BD0AD51874B55B64BA2AFB16895FF@Wylie> <p06240828c4c12cc7847e@[10.20.30.152]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Fri, 08 Aug 2008 16:09:28 -0400
Organization: IECA, Inc.
Message-ID: <ECEBE14254684D9FB540EEC36B08E8B5@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: <p06240828c4c12cc7847e@[10.20.30.152]>
Thread-Index: Acj44BPhN82v+KlSRx69J/t9CEPPcAAsV3AQ
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

>-----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