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

"Turner, Sean P." <> Thu, 07 August 2008 17:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3312F3A6B16 for <>; Thu, 7 Aug 2008 10:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kmGCb8sopqZN for <>; Thu, 7 Aug 2008 10:59:09 -0700 (PDT)
Received: from (Balder-227.Proper.COM []) by (Postfix) with ESMTP id 693BD3A6C3E for <>; Thu, 7 Aug 2008 10:59:09 -0700 (PDT)
Received: from (localhost []) by (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
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id m77HgDLj097018; Thu, 7 Aug 2008 10:42:13 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with SMTP id m77HgB7e097002 for <>; Thu, 7 Aug 2008 10:42:12 -0700 (MST) (envelope-from
Received: (qmail 17365 invoked from network); 7 Aug 2008 17:42:10 -0000
Received: from unknown (HELO Wylie) ( with login) by 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' <>
References: <> <01e001c8f0b4$4182f4a0$c488dde0$@com> <p06240800c4bb6ddc408b@[]> <000701c8f7a9$10d35c40$327a14c0$@com> <p06240813c4bf6bc2ad3e@[]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Thu, 07 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: <p06240813c4bf6bc2ad3e@[]>
thread-index: Acj31gZA1BV5oRk4QBWJ+04JjAIBmwA3qptg
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

>-----Original Message-----
>From: Paul Hoffman [] 
>Sent: Wednesday, August 06, 2008 11:07 AM
>To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell'
>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 []
>>>  Sent: Sunday, August 03, 2008 8:28 AM
>>>  To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell'
>>>  Cc:
>>>  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 
>>permitted.  I thought I saw enough consensus from the list that keys 
>>over this size will have either real-estate constraints or 
>>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?